Splunk Enterprise : une faille 9,8 permet d’exécuter des commandes sans compte

Le 7 octobre 2026, l’avis de sécurité de Splunk a présenté les correctifs de CVE-2026-76268, une faille de Splunk Enterprise notée 9,8 sur l’échelle CVSS 3.1. Sur les branches 10.2 avant 10.2.7 et 10.4 avant 10.4.3, une personne sans compte peut exécuter des commandes du système d’exploitation si elle dispose d’un accès réseau à l’API REST Patroni d’un membre du cluster de recherche. La version installée et l’accès à cette interface déterminent donc ensemble le périmètre d’exposition.

Le bulletin du Centre canadien pour la cybersécurité, diffusé le 8 octobre 2026, recense des mises à jour pour plusieurs branches de Splunk Enterprise, dont 10.0.10 et 9.4.15. Ces deux versions répondent à d’autres vulnérabilités du même lot : les branches 10.0.x et 9.4.x ne sont pas touchées par CVE-2026-76268. Pour cette faille précise, les versions minimales corrigées sont 10.2.7 et 10.4.3, selon la branche utilisée.

Les versions concernées, branche par branche

Le tableau général des produits corrigés couvre l’ensemble du bulletin, tandis que la description de CVE-2026-76268 limite cette vulnérabilité aux branches 10.2 et 10.4. La distinction évite d’attribuer à toutes les installations à mettre à jour le même risque d’exécution de commandes sans authentification. Voici le périmètre utile pour identifier la version corrective :

• Branche 10.4 : les versions 10.4.0 à 10.4.2 sont concernées. La première version corrigée de cette branche est 10.4.3.
• Branche 10.2 : les versions 10.2.0 à 10.2.6 sont concernées. La première version corrigée de cette branche est 10.2.7.
• Branche 10.0 : elle n’est pas affectée par CVE-2026-76268. La version 10.0.10 contient des correctifs pour d’autres failles du bulletin.
• Branche 9.4 : elle n’est pas affectée par CVE-2026-76268. La version 9.4.15 traite les autres failles qui la concernent.

Une installation ancienne de la branche 10.0 ou 9.4 peut ainsi nécessiter une mise à jour sans relever de l’alerte Patroni. À l’inverse, la présence d’une version touchée sur un membre du cluster de recherche appelle une attention particulière dès lors que son API REST Patroni est joignable. Le nom du produit seul ne permet pas de départager ces situations : il faut connaître la branche, la version exacte et le rôle du serveur dans le déploiement.

Pourquoi l’accès à Patroni change le risque

La faiblesse porte sur des opérations critiques de configuration de l’API REST Patroni qui ne demandent pas d’authentification. Le scénario publié vise cette interface sur un membre du cluster de recherche, aussi appelé search head cluster. Si un acteur peut lui envoyer des requêtes sur une version vulnérable, il peut lui faire exécuter des commandes du système d’exploitation qu’il contrôle, sans identifiant Splunk ni action préalable d’un utilisateur.

Le qualificatif « distant » de la fiche CVE-2026-76268 désigne ici un accès par le réseau à l’interface concernée. Dans un déploiement donné, le chemin jusqu’à Patroni compte autant que la version du logiciel pour apprécier l’exposition immédiate. Un accès depuis un réseau interne reste un accès réseau ; inversement, une interface que l’acteur ne peut pas joindre ne lui offre pas cette voie d’attaque.

Le score CVSS décrit la gravité technique du scénario : attaque par le réseau, faible complexité, aucun privilège requis, aucune interaction d’un utilisateur et effets potentiellement élevés sur la confidentialité, l’intégrité et la disponibilité. Il ne mesure pas la proportion de clusters dont l’API est effectivement accessible. C’est pourquoi le score élevé et la condition d’accès doivent être lus ensemble, sans supposer que chaque installation de Splunk Enterprise présente le même point d’entrée.

Correctif et contournement pour les branches touchées

La correction logicielle consiste à installer au minimum 10.2.7 sur la branche 10.2 ou 10.4.3 sur la branche 10.4, ou une version ultérieure de la branche correspondante. Cette correspondance par branche évite de confondre les quatre numéros publiés pour l’ensemble des vulnérabilités avec quatre correctifs nécessaires à CVE-2026-76268. Elle s’applique aux membres du cluster de recherche concernés par la faille.

Splunk prévoit aussi un contournement lorsque le déploiement n’utilise ni Edge Processor, ni OpAmp, ni les pipelines de données SPL2. Il consiste à désactiver le composant PostgreSQL sidecar en réglant « disabled = true » dans la section « [postgres] » du fichier « $SPLUNK_HOME/etc/system/local/server.conf », puis à redémarrer Splunk Enterprise. Cette condition d’usage importe : le sidecar participe aux fonctions citées, et sa désactivation n’est donc pas une solution interchangeable avec la mise à jour pour tous les environnements.

Restreindre les réseaux capables d’atteindre Patroni peut également réduire l’exposition pendant le déploiement du correctif, puisque l’accès à l’API est une condition de l’attaque décrite. Cette restriction dépend toutefois de la configuration réseau réelle et ne modifie pas la version installée. Le correctif de la branche reste la réponse publiée à la vulnérabilité.

Les autres failles du bulletin suivent des scénarios différents

Le même avis traite notamment d’un accès indu aux informations de tâches de recherche appartenant à d’autres utilisateurs. Dans ce cas, l’acteur dispose d’un compte sans les rôles « admin » ou « power » et exploite un contrôle insuffisant de l’appartenance de la tâche. La faille Patroni se distingue par l’absence d’authentification et par l’exécution possible de commandes du système d’exploitation, sous réserve d’atteindre l’API du membre de cluster.

Une autre vulnérabilité du lot concerne certaines mises à niveau de paquets Splunk Enterprise sous Linux. Elle suppose qu’un utilisateur local puisse déjà exécuter des commandes sous le compte faisant fonctionner Splunk, modifie le contenu de l’installation, puis qu’une mise à niveau de paquet affectée soit lancée avec les privilèges root. Ces prérequis diffèrent de ceux de CVE-2026-76268 ; leur coexistence dans un bulletin ne transforme pas les branches 10.0 et 9.4 en branches vulnérables à Patroni.

Le bulletin prévoit par ailleurs des étapes supplémentaires pour certaines autres CVE après la mise à niveau. Pour les administrateurs d’un cluster de recherche en 10.2 ou 10.4, la conséquence immédiate est plus ciblée : la version corrective doit correspondre à leur branche, tandis que l’accès réseau à Patroni détermine qui pourrait exploiter la faille avant son installation.

À lire aussi :

• GitLab : la faille critique peut lire des secrets sans authentification
• NetScaler : une faille corrigée en juin mène jusqu’à l’exécution de code
• PACT veut distinguer humains et robots sans compte ni CAPTCHA