En bref

  • CVE-2026-20253 (CVSS 9.8, CWE-306) : Splunk Enterprise expose un service PostgreSQL sidecar sans authentification permettant une exécution de code arbitraire en cinq requêtes HTTP
  • Systèmes affectés : Splunk Enterprise 10.0.0–10.0.6 et 10.2.0–10.2.3 ; aucun workaround disponible — mise à jour obligatoire vers 10.0.7, 10.2.4 ou 10.4.0
  • CISA a ajouté cette CVE au catalogue KEV le 18 juin 2026 — première vulnérabilité Splunk jamais inscrite dans ce catalogue

Les faits

CVE-2026-20253 est une vulnérabilité de type authentification manquante (CWE-306, Missing Authentication for Critical Function) dans Splunk Enterprise. Elle a été divulguée via l'advisory Splunk SVD-2026-0603 en juin 2026 et assignée un score CVSS 3.1 de 9.8 avec le vecteur AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Le 18 juin 2026, la CISA l'a ajoutée à son catalogue des vulnérabilités exploitées connues (KEV), faisant de CVE-2026-20253 la première vulnérabilité Splunk jamais inscrite dans ce catalogue. Splunk a confirmé une exploitation limitée dans la nature.

Vecteur technique — le service PostgreSQL sidecar : Splunk Enterprise inclut un composant auxiliaire baptisé PostgreSQL sidecar service, conçu pour gérer des fonctionnalités avancées d'indexation et de recherche. Ce service expose une interface d'administration sur un port local, mais sans aucun mécanisme d'authentification. Dans les déploiements AWS Marketplace (où Splunk Enterprise est déployé via AMI), ce service est installé et activé par défaut, ce qui le rend directement accessible si les règles de sécurité réseau ne le restreignent pas. Sur les installations Windows avec sidecar, le service est installé mais désactivé par défaut.

Chaîne d'exploitation en cinq étapes : Le chercheur watchTowr Labs a publié une analyse technique le 12 juin 2026 décrivant la chaîne complète. La première étape consiste à identifier les endpoints d'administration exposés du service sidecar via des requêtes HTTP non authentifiées. La deuxième étape exploite l'absence d'authentification pour interagir avec l'interface de gestion PostgreSQL. La troisième étape enchaîne sur l'utilisation des fonctionnalités PostgreSQL pour écrire des fichiers arbitraires sur le système de fichiers (technique COPY TO/FROM). La quatrième étape consiste à déposer un fichier malveillant (script Python, extension PostgreSQL, ou fichier de configuration) dans un répertoire exécuté automatiquement par Splunk. La cinquième et dernière étape déclenche l'exécution du code malveillant via un redémarrage de composant ou une action administrative légitime. L'ensemble de la chaîne peut être réalisé en quelques minutes avec un accès réseau au port concerné.

Versions affectées et corrigées : Les versions de Splunk Enterprise affectées sont 10.0.0 à 10.0.6 et 10.2.0 à 10.2.3. Les versions corrigées sont 10.0.7, 10.2.4 et 10.4.0 (qui introduit également de nouvelles fonctionnalités). La situation est plus nuancée pour Splunk Cloud Platform : les versions antérieures à 10.2.2510.14 sont concernées selon Resecurity, tandis que d'autres sources indiquent que Splunk Cloud n'est pas affecté en raison de l'absence du sidecar PostgreSQL dans leur architecture SaaS. Les équipes de sécurité utilisant Splunk Cloud doivent vérifier auprès du support Splunk l'état de leur instance spécifique.

Aucun workaround disponible : Contrairement à de nombreuses vulnérabilités pour lesquelles des règles WAF ou des configurations alternatives permettent de réduire le risque sans patch immédiat, CVE-2026-20253 ne dispose d'aucune atténuation partielle documentée par Splunk. L'advisory SVD-2026-0603 est explicite : la seule remédiation est la mise à jour vers une version corrigée. Le blocage réseau du port du service sidecar peut réduire la surface d'attaque externe, mais ne constitue pas une correction de la vulnérabilité elle-même.

Contexte stratégique — Splunk au cœur des SIEM : Splunk Enterprise est l'un des SIEM (Security Information and Event Management) les plus déployés dans les grandes entreprises et les organisations gouvernementales. Sa compromission est particulièrement grave car Splunk ingère et agrège les logs de sécurité de l'ensemble de l'infrastructure : pare-feux, serveurs, endpoints, applications. Un attaquant ayant accès à Splunk peut lire des événements de sécurité sensibles, identifier des vulnérabilités dans d'autres systèmes, effacer des traces d'intrusion ou manipuler des alertes SIEM pour masquer des activités malveillantes. La compromission d'un SIEM transforme l'outil de détection lui-même en vecteur de persistance.

Exploitation confirmée et attribution : Splunk a mis à jour son advisory SVD-2026-0603 le 18 juin 2026 pour indiquer qu'une exploitation limitée dans la nature avait été identifiée. Aucun groupe APT spécifique n'a été publiquement attribué à cette exploitation, mais la nature de la cible — des environnements SIEM d'entreprise — correspond aux profils de menace des acteurs étatiques et des groupes de ransomware à haute sophistication qui ciblent systématiquement les outils de sécurité pour désactiver la détection avant une attaque de grande ampleur.

CVEs connexes dans le même advisory : L'advisory SVD-2026-0603 de Splunk couvre également CVE-2026-20251 (CVSS 8.8, désérialisation non sécurisée dans l'application Splunk Secure Gateway, pouvant mener à une RCE avec authentification), CVE-2026-20252 (CVSS 7.6, SSRF dans l'export PDF de Dashboard Studio) et CVE-2026-20258 (CVSS 7.1, XSS stocké dans les dashboards classiques). Ces vulnérabilités supplémentaires renforcent l'urgence de la mise à jour, même pour les déploiements ne disposant pas du sidecar PostgreSQL.

Deadline fédérale BOD 26-04 : Dans le cadre de la directive opérationnelle BOD 26-04, les agences fédérales américaines (FCEB) avaient jusqu'au 21 juin 2026 pour corriger CVE-2026-20253, soit seulement trois jours après son ajout au catalogue KEV. Cette fenêtre de remédiation extrêmement courte reflète la gravité de la menace. Les organisations non fédérales sont fortement encouragées par la CISA à traiter les entrées KEV avec la même priorité.

Impact et exposition

Les organisations les plus exposées sont celles qui déploient Splunk Enterprise sur AWS Marketplace (où le sidecar est activé par défaut) et dont les groupes de sécurité AWS ou les règles pare-feu n'isolent pas le port du service PostgreSQL. Dans les déploiements on-premise, le risque est présent si le service sidecar est actif et si le réseau interne permet des connexions directes aux ports Splunk depuis des zones non maîtrisées.

L'exploitation réussie de CVE-2026-20253 accorde à l'attaquant une exécution de code avec les droits du compte de service Splunk. Dans de nombreux déploiements, ce compte dispose de droits élevés sur le système hôte (accès aux fichiers de log, aux clés d'API, aux certificats TLS) et parfois de droits réseau permettant d'accéder à des sources de données comme des bases de données SQL, des LDAP ou des APIs internes. Le SIEM étant connecté à l'ensemble de l'infrastructure pour la collecte de logs, sa compromission constitue un pivot idéal vers d'autres systèmes.

Pour les équipes de sécurité utilisant Splunk comme principal outil de détection, la compromission du SIEM peut entraîner une cécité opérationnelle totale : suppression d'alertes, modification de dashboards, désactivation de règles de corrélation. Les attaquants sophistiqués ciblent spécifiquement les SIEM pour effacer les traces de leur intrusion avant de lancer leur attaque principale — une technique documentée dans plusieurs rapports d'incidents récents.

La présence de CVE-2026-20253 dans le catalogue KEV avec une exploitation active confirmée signifie que des outils d'exploitation sont disponibles dans des kits d'attaque professionnels. Les acteurs de menace ciblant des entreprises et des institutions dont Splunk est connu pour être un composant de l'infrastructure ont tous les moyens techniques pour exploiter cette faille sur des déploiements non patchés.

Recommandations immédiates

  • Mettre à jour Splunk Enterprise vers 10.0.7, 10.2.4 ou 10.4.0 — advisory Splunk SVD-2026-0603 (sans délai, aucun workaround disponible)
  • Vérifier si le service PostgreSQL sidecar est actif : splunk show config server | grep -i postgresql ou consulter les services système (systemctl list-units | grep splunk)
  • En attendant le patch : isoler réseau le port du sidecar PostgreSQL via règles de sécurité AWS, ACL réseau ou pare-feu local
  • Auditer les logs d'accès Splunk pour des connexions non authentifiées au service sidecar depuis des IP externes ou inhabituelles
  • Vérifier l'intégrité des fichiers de configuration Splunk et l'absence de scripts ou extensions inattendus dans les répertoires Splunk
  • Activer la surveillance des modifications de fichiers sur les répertoires Splunk avec un outil de FIM (File Integrity Monitoring)
  • Vérifier les autres CVE de SVD-2026-0603 (CVE-2026-20251, CVE-2026-20252, CVE-2026-20258) et patcher simultanément

⚠️ Exploitation active confirmée — CISA KEV

CVE-2026-20253 est inscrite au catalogue KEV de la CISA avec une exploitation active confirmée. Splunk Enterprise non patché est une cible prioritaire pour des acteurs malveillants qui cherchent à compromettre les SIEM d'entreprise afin d'effacer leurs traces. Toute organisation utilisant Splunk Enterprise 10.0.x ou 10.2.x non mis à jour doit considérer ce risque comme une urgence absolue et planifier le patch dans les 24 heures.

Comment vérifier si mon déploiement Splunk est vulnérable ?

Vérifiez votre version de Splunk Enterprise : splunk version. Si elle est comprise entre 10.0.0 et 10.0.6 ou entre 10.2.0 et 10.2.3, vous êtes dans le périmètre. Pour savoir si le sidecar PostgreSQL est actif, cherchez un processus postgres lancé par l'utilisateur Splunk (ps aux | grep postgres). Si le processus est présent et que votre réseau n'isole pas ce service, votre installation est directement exposée. Sur AWS, vérifiez vos groupes de sécurité pour les ports associés au sidecar Splunk.

Votre infrastructure est-elle exposée ?

Ayi NEDJIMI réalise des audits ciblés pour identifier et corriger vos vulnérabilités.

Demander un audit