Introduction
Dans l'écosystème de la sécurité informatique, les outils de surveillance jouent un rôle central : ils agrègent les journaux d'événements, détectent les comportements anormaux et donnent aux équipes SOC une visibilité sur l'ensemble du périmètre. C'est précisément pourquoi la vulnérabilité CVE-2026-20253, divulguée publiquement le 12 juin 2026, mérite une attention particulière. Elle touche Splunk Enterprise, l'une des plateformes SIEM les plus déployées dans les organisations, et permet à un attaquant non authentifié d'exécuter du code arbitraire sur le serveur ciblé. Score CVSS : 9.8.
Un composant interne livré sans protection
La chaîne d'exploitation repose sur un service annexe introduit avec Splunk Enterprise version 10 : le PostgreSQL Sidecar. Ce composant gère les opérations de sauvegarde et de restauration de la base de données interne via une API HTTP exposant notamment les endpoints /v1/postgres/recovery/backup et /v1/postgres/recovery/restore. Le problème est architectural : aucune vérification d'identité n'est opérée au niveau applicatif. L'authentification est entièrement déléguée à la couche base de données elle-même, créant une faille béante entre les deux niveaux.
Le service écoute sur des ports internes liés à l'interface locale, mais reste accessible de l'extérieur via le port 8000 de l'interface web Splunk, qui sert de proxy transparent. Tout attaquant capable de joindre l'interface d'administration peut donc interagir avec ce service sans fournir le moindre identifiant.
Une exploitation en quatre étapes, aucun compte requis
Le cabinet watchTowr Labs a documenté une chaîne d'attaque complète. Dans un premier temps, l'attaquant envoie une requête à l'endpoint de sauvegarde en injectant un paramètre de connexion PostgreSQL pointant vers un serveur qu'il contrôle — le champ database accepte des chaînes de connexion complètes, y compris le paramètre hostaddr qui écrase l'adresse cible par défaut.
Depuis ce serveur malveillant, l'attaquant peut ensuite restaurer un dump contenant des fonctions PL/pgSQL conçues pour écrire des fichiers arbitraires sur le système hôte. L'étape suivante consiste à récupérer les identifiants locaux stockés dans un fichier .pgpass — suffisant pour s'authentifier à la base Splunk locale. Enfin, l'écrasement d'un script Python exécuté régulièrement par la plateforme aboutit à une exécution de code en tant qu'utilisateur splunk. Aucune élévation de privilèges préalable, aucun compte sur la plateforme : un simple accès réseau au port 8000 suffit.
AWS particulièrement exposé par défaut
Un facteur aggravant distingue ce cas des vulnérabilités classiques : le service PostgreSQL Sidecar est activé par défaut dans les déploiements Splunk Enterprise sur AWS, mais reste inactif ou absent dans la majorité des installations on-premise sous Windows. Les environnements cloud ont donc été exposés dès la mise en service, sans action supplémentaire de la part de l'opérateur.
Ce détail illustre un risque souvent sous-estimé : la surface d'attaque d'un déploiement cloud peut différer significativement de son équivalent on-premise, pour le même éditeur et le même produit. Les politiques de durcissement pensées pour des serveurs physiques ne se transposent pas automatiquement vers le cloud, et les composants activés par défaut en environnement managé méritent un audit spécifique.
Ce que cela implique pour les équipes
Splunk a publié des versions corrigées dès le 10 juin 2026 : les branches 10.4.0, 10.2.4, 10.0.7, 9.4.12 et 9.3.13 intègrent le correctif. La mise à jour s'impose en priorité pour toute organisation opérant Splunk sur AWS, où le service était actif sans que les équipes en aient nécessairement conscience.
Plus largement, cet incident rappelle que les outils de sécurité eux-mêmes doivent faire l'objet du même niveau de rigueur que n'importe quel composant critique : inventaire des services exposés, audit des endpoints internes, et vérification que l'architecture d'authentification ne délègue pas de responsabilités à des sous-composants non filtrés. Surveiller l'ensemble du système informatique ne suffit pas si l'outil de surveillance lui-même n'est pas à l'épreuve.