Splunk a divulgué CVE-2026-76268, touchant les versions de Splunk Enterprise antérieures à 10.4.3 et 10.2.7. Un attaquant non authentifié disposant d'un accès réseau à l'API REST Patroni sur un membre du cluster de têtes de recherche peut exécuter les commandes du système d'exploitation de son choix. Les versions 10.0.x et 9.4.x ne sont pas affectées.

Voici ce qui me dérange dans ce cas précis : l'API Patroni est exposée sans authentification pour ce que l'avis appelle des « opérations de configuration critiques ». Il ne s'agit pas d'une mauvaise configuration que vous avez introduite. C'est un choix de conception intégré au produit. Vos contrôles périmètriques et votre segmentation réseau sont les seules choses qui séparent un attaquant de l'exécution de commandes au niveau OS sur un nœud qui, dans la plupart des environnements, a accès à des données de journaux et de sécurité sensibles.

D'un point de vue IAM, il s'agit d'un échec d'authentification des comptes de service et des API selon les règles de l'art. Toute API acceptant des modifications de configuration devrait exiger des justificatifs d'identité, sans exception. Aucune dérogation pour les interfaces « internes ». D'après mon expérience, ce sont exactement ces API « internes » qui servent de pivot aux attaquants une fois qu'ils ont franchi le périmètre. L'interface Patroni n'a visiblement jamais intégré ce principe. Vos outils de détection ne savaient probablement pas qu'il fallait la surveiller non plus, car personne ne s'attendait à ce qu'elle constitue une surface d'attaque.

Les clusters de têtes de recherche Splunk ne sont pas des déploiements marginaux. Ils sont courants dans les entreprises de taille moyenne à grande qui exécutent des charges de travail SIEM, ce qui signifie que le rayon d'impact peut être considérable. Si un attaquant exécute des commandes OS sur une tête de recherche, il peut altérer l'ingestion des journaux, effacer ses traces ou utiliser le nœud comme point de départ. L'accès que Splunk détient sur le reste de votre environnement aggrave la situation par rapport à une compromission applicative ordinaire.

Si vous exécutez une version affectée, appliquez le correctif vers la version 10.4.3 ou 10.2.7 immédiatement. Pendant que vous planifiez cette fenêtre de maintenance, vérifiez si le port de l'API Patroni est accessible depuis autre chose que les nœuds du cluster lui-même. La segmentation réseau ne corrige pas la vulnérabilité, mais elle réduit votre fenêtre d'exposition avant l'application du correctif. Après la mise à jour, examinez les journaux d'accès du point de terminaison Patroni et recherchez tout appel inattendu. Si vous ne pouvez pas obtenir ces journaux, c'est un problème distinct qui mérite d'être traité.