La faille Splunk qui supprime des fichiers sans connexion

6 min. de lecture

Une faille critique dans Splunk Enterprise permet à des attaquants de créer et de supprimer des fichiers sur le serveur sans s’authentifier. L’agence américaine CISA la répertorie comme activement exploitée depuis le 18 juin. Plus de 1.400 instances sont exposées publiquement sur Internet dans le monde, dont 223 en Europe.

Les points clés en bref

CVSS 9,8, aucune connexion requise. La vulnérabilité CVE-2026-20253 se trouve dans le sidecar PostgreSQL de Splunk Enterprise et permet de créer et de supprimer des fichiers sans authentification.
Les attaques sont déjà en cours. Après la publication du code d’exploitation le 12 juin, la CISA a ajouté cette faille à sa liste des vulnérabilités activement exploitées le 18 juin, avec une deadline de correctif au 21 juin pour les agences fédérales américaines.
La solution de contournement entraîne une perte de fonctionnalités. Si vous ne pouvez pas appliquer le correctif immédiatement, la désactivation du sidecar PostgreSQL entraîne la perte de l’Edge Processor, d’OpAmp et des pipelines de données SPL2.

Ce que cette faille permet techniquement

Qu’est-ce que la CVE-2026-20253 ? Il s’agit d’une vulnérabilité critique dans le sidecar PostgreSQL de Splunk Enterprise. Elle contourne l’authentification, permettant ainsi à des attaquants de créer et de supprimer des fichiers sur le serveur sans s’identifier. Son score CVSS s’élève à 9,8 sur 10.

Splunk Enterprise intègre un sidecar PostgreSQL depuis plusieurs versions. Ce service s’exécute parallèlement au processus principal de Splunk et fournit une base de données relationnelle à l’Edge Processor, au protocole de télémétrie OpAmp et aux pipelines de données SPL2, entre autres. C’est précisément à cet endroit que se trouve la faille.

La CVE-2026-20253 correspond à une vérification d’authentification manquante. Un attaquant n’a pas besoin de se connecter, de posséder un compte ou de présenter une session valide. Il peut créer et supprimer des fichiers sur le système via le service exposé.

Cela peut sembler moins grave qu’une exécution de code à distance classique. Le potentiel de dommage reste néanmoins élevé. La capacité à créer et supprimer des fichiers sans authentification permet de paralyser des composants ou de supprimer des journaux. Selon l’environnement, un tel accès peut être exploité pour mener des attaques plus poussées. Le score CVSS de 9,8 sur 10 classe cette faille comme critique, principalement en raison de sa facilité d’exploitation sans authentification.

Du Proof-of-Concept à l’utilisation active

L’escalade s’est produite en quelques jours. Le Splunk Product Security Incident Response Team a confirmé les premières attaques dès le début du mois de juin. Le tournant a été marqué par la publication d’un Proof-of-Concept.

Du Exploit à la période des autorités

Début juin

Splunk PSIRT confirme les premières attaques sur la vulnérabilité.

12 juin

WatchTowr Labs publie un Proof-of-Concept fonctionnel.

18 juin

La CISA ajoute la CVE-2026-20253 au catalogue Known-Exploited-Vulnerabilities.

21 juin

Délai pour les administrations fédérales américaines de fermer la faille.

Six jours entre l’exploit public et l’ajout dans le KEV sont une fenêtre très étroite. Dès qu’un Proof-of-Concept circule, l’obstacle pour les scans massifs contre les systèmes exposés diminue considérablement. Celui qui attend le prochain cycle de maintenance régulier planifie trop tard.

Combien de systèmes sont désormais exposés

Splunk collecte des logs provenant de tout le réseau et est donc souvent largement répandu. Une partie des instances est directement connectée à Internet, souvent par commodité dans le cadre de sites distants.

223

instances Splunk directement accessibles depuis Internet en Europe, sur plus de 1 400 mondialement.

Source : données de scan publiques concernant la vulnérabilité, juin 2026

Chacune de ces instances exposées est une cible directe. Les serveurs accessibles internement restent également vulnérables dès qu’une personne se trouve sur le réseau, par exemple après un succès de phishing. L’exposition à Internet doit être fermée en premier, suivie immédiatement des instances internes.

Mettre à jour, désactiver ou isoler

La priorité est claire. Splunk propose un correctif. Les builds concernés ainsi que la version à partir de laquelle la vulnérabilité est corrigée figurent dans l’avis de sécurité Splunk relatif à la CVE-2026-20253. Celui qui gère Splunk Enterprise vérifie son niveau de version et applique la mise à jour. C’est la seule mesure qui permet effectivement de fermer la vulnérabilité.

Si une mise à jour immédiate n’est pas possible, il reste le recours d’urgence : désactiver le PostgreSQL-Sidecar. Cela arrête le service vulnérable, mais cela a un coût. Edge Processor, OpAmp et les pipelines de données SPL2 ne fonctionneront plus. Pour de nombreuses environnements, cela représente une perte de fonctionnalité notable, adaptée uniquement comme solution temporaire.

Indépendamment du statut de mise à jour, l’exposition à Internet doit être examinée. Un SIEM n’a rarement de raison d’être accessible directement depuis Internet. Celui qui limite l’accès aux réseaux internes et au VPN réduit immédiatement la surface d’attaque.

Immédiatement : Vérifier le niveau de version, appliquer le correctif.
Si aucun correctif n’est possible : Désactiver le PostgreSQL-Sidecar, prévoir un dysfonctionnement.
Dans tous les cas : Examiner l’exposition à Internet, limiter l’accès au réseau interne et au VPN.
Puis : Analyser les logs pour détecter des opérations de fichiers inattendues et des entrées supprimées.

Pourquoi le SIEM est-il un objectif particulièrement délicat

Les règles de détection s’appuient sur les logs du SIEM. Il collecte les protocoles de l’ensemble du réseau à un seul endroit. Si cette plateforme tombe en panne ou est manipulée, le SOC perd sa source d’information la plus importante.

La possibilité de supprimer des fichiers rend la situation encore plus grave. Un attaquant qui supprime les logs efface ses traces exactement là où elles devraient normalement se faire remarquer. Une faille dans le système de détection est donc plus dangereuse qu’une même faille sur un système périphérique. Elle frappe l’instance qui devrait normalement signaler l’attaque.

Pour la pratique, cela signifie que cette vulnérabilité n’est pas un simple correctif parmi d’autres. Elle concerne la composante dont dépend la crédibilité de tous les autres alertes.

Foire aux questions

Quelle est exactement la vulnérabilité couverte par CVE-2026-20253 ?

La faille dans le Sidecar PostgreSQL de Splunk Enterprise contourne l’authentification. Un attaquant peut créer et supprimer des fichiers sur le système sans données d’identification valides. Selon l’environnement, cela permet de désactiver des composants ou de supprimer des logs.

Les entreprises DACH sont-elles concernées, même si la date limite de CISA ne concerne que les autorités américaines ?

Oui. La date limite de CISA impose uniquement aux autorités fédérales américaines de traiter le risque technique, mais ce risque est identique partout. Splunk est utilisé dans de nombreux SOC DACH, et les 223 instances exposées en Europe montrent que des systèmes restent vulnérables ici aussi. Qui utilise Splunk doit traiter le 21 juin comme une date clé.

Que faire si un patch immédiat n’est pas possible ?

Splunk recommande, en tant que solution temporaire, d’arrêter le service du Sidecar PostgreSQL. Cela met ainsi le service vulnérable hors ligne, mais entraîne la perte des processeurs Edge, des OpAmp et des pipelines de données SPL2. Cette mesure est uniquement prévue comme solution d’urgence jusqu’à ce que le patch soit appliqué.

Comment savoir si ma instance Splunk est exposée ?

L’indicateur le plus rapide est la reachabilité depuis l’extérieur : vérifiez si le service du Sidecar PostgreSQL répond depuis Internet ou depuis des segments non fiables. Puisque depuis le 12 juin un exploit public circule, toute instance exposée est actuellement en danger. Le Splunk Advisory fournit des règles de détection basées sur des modèles d’attaque confirmés ; en complément, il est utile de consulter les logs pour détecter des opérations inattendues sur les fichiers.

Pourquoi une faille dans le SIEM est-elle particulièrement critique ?

Le SIEM fournit les logs pour chaque détection. Si celui-ci est manipulé, l’équipe de sécurité perd la visibilité sur son propre réseau. En effet, cette faille permet également de supprimer des fichiers, ce qui permet à un attaquant d’effacer ses traces exactement là où elles devraient normalement être découvertes.