Le 7 octobre 2026, NVD a publié CVE-2026-76285 sur Splunk Enterprise, notée 9.8. Ce n'est pas une faille unique, c'est un lot de vulnérabilités découvertes en interne par Splunk, regroupées sous un même identifiant.
Je le dis d'entrée : on ne connaît pas le détail technique. La description NVD ne décrit aucun mécanisme. Ce qu'on sait, en revanche, suffit à décider quoi faire.
| Champ | Valeur |
|---|---|
| CVSS 3.1 | 9.8 (CRITICAL) |
| Vecteur | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| Publication NVD | 2026-10-07 |
| CISA KEV | non (à la date de rédaction) |
| Versions corrigées | 10.4.3, 10.2.7, 10.0.10, 9.4.15 |
Ce que dit NVD
Splunk addressed multiple internally identified vulnerabilities in Splunk Enterprise versions 10.4.3, 10.2.7, 10.0.10, and 9.4.15. The vulnerabilities are grouped by Common Weakness Enumeration (CWE), with one Common Vulnerabilities and Exposures (CVE) identifier assigned to each group.
La catégorie annoncée est Improper Adherence to Coding Standards : un défaut de respect des règles de codage. C'est une étiquette très large, qui ne dit rien de la nature précise des bugs. Splunk renvoie à la section « Details » de son avis pour la suite.
C'est le même schéma que l'on voit de plus en plus chez les grands éditeurs : une revue de code interne, une release qui corrige plusieurs défauts, et un identifiant par catégorie de faiblesse plutôt qu'un par bug.
Ce qu'on ne sait pas
- Quels composants de Splunk Enterprise sont concernés (interface web, API REST, port de gestion, réception de données).
- Les conditions d'exploitation réelles. Le vecteur dit « réseau, sans privilège, sans interaction », mais il s'applique au groupe, pas forcément à chaque faille.
- Si d'autres produits Splunk sont touchés. NVD ne liste que Splunk Enterprise.
Je ne vais pas combler ces trous par des hypothèses. L'avis Splunk fait foi.
Pourquoi c'est à traiter vite malgré tout
Un SIEM n'est pas une application comme les autres :
- Il reçoit les journaux de tout le parc : un attaquant qui le contrôle voit ce que voit l'équipe de sécurité.
- Il peut les modifier ou les ignorer : effacer ses traces au cœur même de l'outil censé les conserver.
- Il détient souvent des identifiants vers d'autres systèmes : comptes de collecte, clés d'API, intégrations.
Un 9.8 sans authentification sur ce type de cible justifie une mise à jour prioritaire, même sans détail technique.
Versions
NVD liste les versions 10.4.3, 10.2.7, 10.0.10 et 9.4.15 : la description les présente explicitement comme celles qui corrigent les failles. Chacune correspond à une branche. Mets à jour vers la version corrigée de ta branche, ou ultérieure.
Si tu es sur une branche qui n'apparaît pas dans cette liste, consulte l'avis Splunk : NVD ne dit rien de son statut.
Détection
Sans détail technique, la détection reste générique :
- Inventaire : version exacte de chaque instance Splunk Enterprise (search heads, indexers, deployment server, heavy forwarders), via l'interface ou
splunk version. - Exposition : l'interface web et le port de gestion sont-ils joignables depuis des réseaux autres que l'administration ?
- Comptes : utilisateurs ou rôles créés récemment, changements de rôle non expliqués.
- Applications : apps installées récemment sans changement documenté.
- Processus : processus enfants inattendus du service Splunk.
- Intégrité des journaux : trous inexpliqués dans l'ingestion, index supprimés ou modifiés.
Mitigation
- Mettre à jour Splunk Enterprise vers 10.4.3, 10.2.7, 10.0.10 ou 9.4.15 selon ta branche, en commençant par les instances les plus exposées.
- Restreindre l'accès à l'interface web et au port de gestion au réseau d'administration.
- Revoir les comptes et les rôles : supprimer les comptes inutilisés, réduire les rôles administrateurs au strict nécessaire.
- Lire l'avis Splunk pour vérifier si des mesures complémentaires sont recommandées pour ta configuration.
- En cas de doute sur une compromission : faire tourner les identifiants et clés stockés dans Splunk, et considérer que les journaux de la période ne sont plus fiables à eux seuls.
Pourquoi surveiller en continu tes outils de sécurité
Les outils de sécurité sont des cibles parce qu'ils voient tout. Quand une CVE critique les touche sans détail technique, le seul levier fiable est de savoir exactement quelle version tourne sur chaque instance.
Avec cveo.tech, déclare tes outils de sécurité avec leur version exacte, et reçois une alerte dès qu'une CVE critique les concerne.