En bref

  • CVE-2026-20253 : RCE non-authentifiée CVSS 9.8 dans Splunk Enterprise, inscrite au KEV de la CISA le 5 août 2026
  • Versions affectées : Splunk Enterprise 10.0.0–10.0.6 et 10.2.0–10.2.3 ; Splunk Cloud patchée automatiquement par l'éditeur
  • Action immédiate : mise à jour vers 10.0.7, 10.2.4 ou 10.4.0 — délai BOD 22-01 CISA fixé au 26 août 2026

Les faits

Le 5 août 2026, la CISA a officiellement inscrit CVE-2026-20253 dans son catalogue Known Exploited Vulnerabilities (KEV), confirmant une exploitation active en conditions réelles. La faille, initialement divulguée le 10 juin 2026 dans l'advisory officiel de Splunk Inc., atteint un score CVSS v3.1 de 9.8 — niveau maximal du palier critique — et permet à un attaquant non authentifié d'exécuter du code arbitraire sur les serveurs Splunk Enterprise accessibles en réseau. Aucun compte, aucune interaction utilisateur, aucune élévation de privilège préalable n'est nécessaire.

Techniquement, CVE-2026-20253 est classée CWE-306 (Missing Authentication for Critical Function). Le composant vulnérable est un endpoint de récupération du service sidecar PostgreSQL intégré nativement à Splunk Enterprise. Ce service interne, conçu pour des opérations de maintenance de la base de données embarquée, est proxifié par Splunk Web et expose des fonctionnalités de création et de troncature de fichiers sans aucun mécanisme de vérification d'identité. Dans des conditions documentées et reproductibles, cette capacité d'écriture arbitraire sur le système de fichiers peut être chaînée avec d'autres primitives pour aboutir à une exécution de code à distance (RCE) sous les privilèges du compte de service Splunk.

Le 18 juin 2026, Splunk a mis à jour son advisory initial pour signaler une exploitation « limitée dans la nature ». Deux jours plus tard, les chercheurs de watchTowr Labs ont publié une analyse technique approfondie accompagnée d'un proof-of-concept (PoC) fonctionnel. Selon les données de Zscaler ThreatLabz, les premières tentatives d'exploitation automatisée ont été détectées dans leurs honeypots dès le 20 juin 2026, soit moins de 48 heures après la mise en ligne du PoC sur GitHub. Ce délai illustre l'effondrement des timelines d'exploitation documenté par le rapport Rapid7 2026 Global Threat Landscape : la médiane entre divulgation et exploitation active est désormais descendue à 5 jours, avec des cas extrêmes inférieurs à 72 heures pour les cibles à fort impact.

La dangerosité particulière de CVE-2026-20253 ne tient pas seulement à son score CVSS ou à la simplicité de son exploitation. Elle tient surtout à la nature de la cible. Splunk Enterprise est le SIEM qui surveille l'ensemble des systèmes d'une organisation : il agrège les logs de tous les équipements réseau, serveurs, applications et endpoints. Un Splunk compromis, c'est un attaquant qui peut lire l'intégralité des événements de sécurité, identifier précisément les règles de détection en place pour les contourner, modifier ou supprimer a posteriori les traces de sa propre intrusion, et opérer en invisibilité totale au sein d'une infrastructure dont il connaît désormais l'architecture complète. Pour un groupe APT ou un opérateur ransomware, c'est une cible de valeur stratégique exceptionnelle.

Les versions concernées sont clairement délimitées : Splunk Enterprise 10.0.0 jusqu'à 10.0.6, corrigée dans la version 10.0.7 ; et Splunk Enterprise 10.2.0 jusqu'à 10.2.3, corrigée dans la version 10.2.4. La dernière branche stable 10.4.0 intègre également le correctif. Les instances Splunk Cloud Platform ont été patchées automatiquement par Splunk Inc. sans intervention client. En revanche, tous les déploiements on-premise restent entièrement à la charge des équipes IT internes — et c'est là que se concentre l'essentiel du risque résiduel.

Orca Security a répertorié, via Shodan et Censys, plusieurs dizaines d'instances Splunk Enterprise exposées directement sur Internet sans WAF ni restriction IP dans les semaines suivant la divulgation. Un nombre significatif affichaient encore des versions non corrigées lors des scans effectués fin juillet 2026. SOCRadar estime à plus de 4 000 le nombre de déploiements Splunk Enterprise identifiables depuis Internet, bien que la majorité bénéficient de couches de protection réseau supplémentaires. Chaque instance non patchée directement accessible constitue un vecteur d'intrusion immédiat pour n'importe quel acteur disposant du PoC public.

La CISA a fixé aux agences fédérales américaines couvertes par la directive BOD 22-01 un délai de remédiation au 26 août 2026. En Europe, les obligations NIS 2 et les clauses standard des contrats de cyber-assurance incitent fortement au traitement en urgence de toute faille inscrite au catalogue KEV. Les opérateurs MSSP disposant de clients sous Splunk on-premise ont généralement déclenché leurs procédures de patch d'urgence dès le 5 août, avec notification immédiate et ouverture de fenêtres de maintenance anticipées.

CVE-2026-20253 s'inscrit dans une dynamique plus large : selon Rapid7 2026 Global Threat Landscape, les vulnérabilités critiques et élevées effectivement exploitées ont bondi de 105% entre 2024 et 2025 (71 → 146). La fenêtre entre publication d'un PoC et exploitation active est passée de plusieurs semaines en 2022 à moins de 72 heures en 2026 pour les cibles à fort impact. Pour les équipes maintenant encore des cycles de patching mensuels, ce rythme est structurellement incompatible avec la réalité du paysage des menaces actuel.

Impact et exposition

Splunk Enterprise est déployé par plus de 22 000 organisations dans le monde, dont la quasi-totalité des entreprises Fortune 500, de nombreuses administrations publiques et des opérateurs d'infrastructures critiques. En France, des acteurs bancaires, télécoms et énergétiques s'appuient sur Splunk comme SIEM principal. Un attaquant exploitant CVE-2026-20253 sur une instance vulnérable peut, sans aucune authentification :

  • Créer ou écraser des fichiers arbitraires sur le système hôte (vecteur initial vers RCE)
  • Exécuter du code à distance sous les privilèges du compte de service Splunk
  • Lire l'intégralité des index de logs stockés sur la plateforme
  • Identifier et désactiver les règles d'alerting et de corrélation actives
  • Supprimer ou altérer des événements passés pour effacer ses propres traces
  • Utiliser le serveur Splunk comme pivot réseau vers l'infrastructure interne

L'exploitation requiert uniquement un accès réseau au port HTTP/HTTPS de Splunk Web (8000/TCP par défaut). Les instances exposées sans restriction sur Internet sont immédiatement vulnérables à tout acteur disposant du PoC public.

Recommandations

  • Priorité absolue : mettre à jour vers Splunk Enterprise 10.0.7, 10.2.4 ou 10.4.0 immédiatement
  • Si le patch immédiat est impossible : bloquer via pare-feu l'accès réseau aux endpoints de récupération PostgreSQL sidecar (restriction localhost uniquement)
  • Auditer les logs HTTP sur le port 8000 pour détecter des requêtes anomales vers les paths /services/postgres depuis le 18 juin 2026
  • Vérifier l'intégrité des règles de détection et des index Splunk critiques pour toute modification non autorisée
  • Restreindre l'accès à Splunk Web aux seules plages IP internes ou VPN — jamais d'exposition directe sur Internet
  • Activer la supervision d'intégrité des fichiers (FIM) sur le serveur hôte Splunk

Alerte critique

CVE-2026-20253 est activement exploitée depuis le 18 juin 2026 et inscrite au KEV de la CISA depuis le 5 août 2026. Un Splunk compromis offre à l'attaquant visibilité totale sur l'infrastructure et capacité d'effacer ses propres traces en temps réel. Toute instance non patchée doit être considérée comme potentiellement compromise. Agissez immédiatement.

Comment détecter une tentative d'exploitation de CVE-2026-20253 dans mes logs Splunk ?

Recherchez dans l'index _internal Splunk des requêtes HTTP GET ou POST vers les paths contenant les termes postgres, recovery ou sidecar depuis des IP non référencées comme administrateurs. Corrélez avec des événements de création ou modification de fichiers sur le système hôte dans la même fenêtre temporelle. watchTowr Labs a publié des signatures Sigma et YARA pour cette détection. Vérifiez également si des règles d'alerting ont été modifiées ou désactivées depuis le 18 juin 2026.

Votre infrastructure est-elle exposée ?

Ayi NEDJIMI réalise des audits de sécurité ciblés pour identifier et corriger vos vulnérabilités avant qu'elles ne soient exploitées.

Demander un audit