6 min. de lecture<\/p>\n
Une faille critique dans Splunk Enterprise permet \u00e0 des attaquants de cr\u00e9er et de supprimer des fichiers sur le serveur sans s’authentifier. L’agence am\u00e9ricaine CISA la r\u00e9pertorie comme activement exploit\u00e9e depuis le 18 juin. Plus de 1.400 instances sont expos\u00e9es publiquement sur Internet dans le monde, dont 223 en Europe.<\/strong><\/p>\n Les points cl\u00e9s en bref<\/p>\n \u00c0 lire aussi :<\/span>Priorisation des correctifs : pourquoi le CVSS seul freine votre SOC<\/a> \/<\/span> Ing\u00e9nierie de la d\u00e9tection sans verrouillage fournisseur<\/a><\/p>\n Qu’est-ce que la CVE-2026-20253 ?<\/strong> Il s’agit d’une vuln\u00e9rabilit\u00e9 critique dans le sidecar PostgreSQL de Splunk Enterprise. Elle contourne l’authentification, permettant ainsi \u00e0 des attaquants de cr\u00e9er et de supprimer des fichiers sur le serveur sans s’identifier. Son score CVSS s’\u00e9l\u00e8ve \u00e0 9,8 sur 10.<\/p>\n Splunk Enterprise int\u00e8gre un sidecar PostgreSQL depuis plusieurs versions. Ce service s’ex\u00e9cute parall\u00e8lement au processus principal de Splunk et fournit une base de donn\u00e9es relationnelle \u00e0 l’Edge Processor, au protocole de t\u00e9l\u00e9m\u00e9trie OpAmp et aux pipelines de donn\u00e9es SPL2, entre autres. C’est pr\u00e9cis\u00e9ment \u00e0 cet endroit que se trouve la faille.<\/p>\n La CVE-2026-20253 correspond \u00e0 une v\u00e9rification d’authentification manquante. Un attaquant n’a pas besoin de se connecter, de poss\u00e9der un compte ou de pr\u00e9senter une session valide. Il peut cr\u00e9er et supprimer des fichiers sur le syst\u00e8me via le service expos\u00e9.<\/p>\n Cela peut sembler moins grave qu’une ex\u00e9cution de code \u00e0 distance classique. Le potentiel de dommage reste n\u00e9anmoins \u00e9lev\u00e9. La capacit\u00e9 \u00e0 cr\u00e9er et supprimer des fichiers sans authentification permet de paralyser des composants ou de supprimer des journaux. Selon l’environnement, un tel acc\u00e8s peut \u00eatre exploit\u00e9 pour mener des attaques plus pouss\u00e9es. Le score CVSS de 9,8 sur 10 classe cette faille comme critique, principalement en raison de sa facilit\u00e9 d’exploitation sans authentification.<\/p>\n L’escalade s’est produite en quelques jours. Le Splunk Product Security Incident Response Team a confirm\u00e9 les premi\u00e8res attaques d\u00e8s le d\u00e9but du mois de juin. Le tournant a \u00e9t\u00e9 marqu\u00e9 par la publication d’un Proof-of-Concept.<\/p>\n Six jours entre l’exploit public et l’ajout dans le KEV sont une fen\u00eatre tr\u00e8s \u00e9troite. D\u00e8s qu’un Proof-of-Concept circule, l’obstacle pour les scans massifs contre les syst\u00e8mes expos\u00e9s diminue consid\u00e9rablement. Celui qui attend le prochain cycle de maintenance r\u00e9gulier planifie trop tard.<\/p>\n Splunk collecte des logs provenant de tout le r\u00e9seau et est donc souvent largement r\u00e9pandu. Une partie des instances est directement connect\u00e9e \u00e0 Internet, souvent par commodit\u00e9 dans le cadre de sites distants.<\/p>\n Chacune de ces instances expos\u00e9es est une cible directe. Les serveurs accessibles internement restent \u00e9galement vuln\u00e9rables d\u00e8s qu’une personne se trouve sur le r\u00e9seau, par exemple apr\u00e8s un succ\u00e8s de phishing. L’exposition \u00e0 Internet doit \u00eatre ferm\u00e9e en premier, suivie imm\u00e9diatement des instances internes.<\/p>\n La priorit\u00e9 est claire. Splunk propose un correctif. Les builds concern\u00e9s ainsi que la version \u00e0 partir de laquelle la vuln\u00e9rabilit\u00e9 est corrig\u00e9e figurent dans l’avis de s\u00e9curit\u00e9 Splunk relatif \u00e0 la CVE-2026-20253. Celui qui g\u00e8re Splunk Enterprise v\u00e9rifie son niveau de version et applique la mise \u00e0 jour. C\u2019est la seule mesure qui permet effectivement de fermer la vuln\u00e9rabilit\u00e9.<\/p>\n Si une mise \u00e0 jour imm\u00e9diate n\u2019est pas possible, il reste le recours d\u2019urgence : d\u00e9sactiver le PostgreSQL-Sidecar. Cela arr\u00eate le service vuln\u00e9rable, mais cela a un co\u00fbt. Edge Processor, OpAmp et les pipelines de donn\u00e9es SPL2 ne fonctionneront plus. Pour de nombreuses environnements, cela repr\u00e9sente une perte de fonctionnalit\u00e9 notable, adapt\u00e9e uniquement comme solution temporaire.<\/p>\n Ind\u00e9pendamment du statut de mise \u00e0 jour, l\u2019exposition \u00e0 Internet doit \u00eatre examin\u00e9e. Un SIEM n\u2019a rarement de raison d\u2019\u00eatre accessible directement depuis Internet. Celui qui limite l\u2019acc\u00e8s aux r\u00e9seaux internes et au VPN r\u00e9duit imm\u00e9diatement la surface d\u2019attaque.<\/p>\n Les r\u00e8gles de d\u00e9tection s’appuient sur les logs du SIEM. Il collecte les protocoles de l’ensemble du r\u00e9seau \u00e0 un seul endroit. Si cette plateforme tombe en panne ou est manipul\u00e9e, le SOC perd sa source d’information la plus importante.<\/p>\n La possibilit\u00e9 de supprimer des fichiers rend la situation encore plus grave. Un attaquant qui supprime les logs efface ses traces exactement l\u00e0 o\u00f9 elles devraient normalement se faire remarquer. Une faille dans le syst\u00e8me de d\u00e9tection est donc plus dangereuse qu’une m\u00eame faille sur un syst\u00e8me p\u00e9riph\u00e9rique. Elle frappe l’instance qui devrait normalement signaler l’attaque.<\/p>\n Pour la pratique, cela signifie que cette vuln\u00e9rabilit\u00e9 n’est pas un simple correctif parmi d’autres. Elle concerne la composante dont d\u00e9pend la cr\u00e9dibilit\u00e9 de tous les autres alertes.<\/p>\n La faille dans le Sidecar PostgreSQL de Splunk Enterprise contourne l’authentification. Un attaquant peut cr\u00e9er et supprimer des fichiers sur le syst\u00e8me sans donn\u00e9es d’identification valides. Selon l’environnement, cela permet de d\u00e9sactiver des composants ou de supprimer des logs.<\/p>\n Oui. La date limite de CISA impose uniquement aux autorit\u00e9s f\u00e9d\u00e9rales am\u00e9ricaines de traiter le risque technique, mais ce risque est identique partout. Splunk est utilis\u00e9 dans de nombreux SOC DACH, et les 223 instances expos\u00e9es en Europe montrent que des syst\u00e8mes restent vuln\u00e9rables ici aussi. Qui utilise Splunk doit traiter le 21 juin comme une date cl\u00e9.<\/p>\n Splunk recommande, en tant que solution temporaire, d’arr\u00eater le service du Sidecar PostgreSQL. Cela met ainsi le service vuln\u00e9rable hors ligne, mais entra\u00eene la perte des processeurs Edge, des OpAmp et des pipelines de donn\u00e9es SPL2. Cette mesure est uniquement pr\u00e9vue comme solution d’urgence jusqu’\u00e0 ce que le patch soit appliqu\u00e9.<\/p>\n L’indicateur le plus rapide est la reachabilit\u00e9 depuis l’ext\u00e9rieur : v\u00e9rifiez si le service du Sidecar PostgreSQL r\u00e9pond depuis Internet ou depuis des segments non fiables. Puisque depuis le 12 juin un exploit public circule, toute instance expos\u00e9e est actuellement en danger. Le Splunk Advisory fournit des r\u00e8gles de d\u00e9tection bas\u00e9es sur des mod\u00e8les d’attaque confirm\u00e9s ; en compl\u00e9ment, il est utile de consulter les logs pour d\u00e9tecter des op\u00e9rations inattendues sur les fichiers.<\/p>\n Le SIEM fournit les logs pour chaque d\u00e9tection. Si celui-ci est manipul\u00e9, l’\u00e9quipe de s\u00e9curit\u00e9 perd la visibilit\u00e9 sur son propre r\u00e9seau. En effet, cette faille permet \u00e9galement de supprimer des fichiers, ce qui permet \u00e0 un attaquant d’effacer ses traces exactement l\u00e0 o\u00f9 elles devraient normalement \u00eatre d\u00e9couvertes.<\/p>\n Plus de contenus du r\u00e9seau MBF Media<\/p>\n\n
Ce que cette faille permet techniquement<\/h2>\n
Du Proof-of-Concept \u00e0 l’utilisation active<\/h2>\n
Combien de syst\u00e8mes sont d\u00e9sormais expos\u00e9s<\/h2>\n
Mettre \u00e0 jour, d\u00e9sactiver ou isoler<\/h2>\n
\n
Pourquoi le SIEM est-il un objectif particuli\u00e8rement d\u00e9licat<\/h2>\n
Foire aux questions<\/h2>\n
Quelle est exactement la vuln\u00e9rabilit\u00e9 couverte par CVE-2026-20253 ?<\/h3>\n
Les entreprises DACH sont-elles concern\u00e9es, m\u00eame si la date limite de CISA ne concerne que les autorit\u00e9s am\u00e9ricaines ?<\/h3>\n
Que faire si un patch imm\u00e9diat n’est pas possible ?<\/h3>\n
Comment savoir si ma instance Splunk est expos\u00e9e ?<\/h3>\n
Pourquoi une faille dans le SIEM est-elle particuli\u00e8rement critique ?<\/h3>\n
Les conseils de lecture de la r\u00e9daction<\/h3>\n
\n