Actualité & Menaces 6 août 2026 · 12 min de lecture

3 CVE ajoutées au KEV en une journée — celle qui m’a fait couper un serveur d’IA interne le soir même

Écran de supervision de sécurité affichant des alertes réseau dans une salle sombre

Le 4 août 2026, la CISA a ajouté trois vulnérabilités à son catalogue des failles activement exploitées. Deux d’entre elles concernent des logiciels que vous inventoriez déjà. La troisième concerne un outil que vous ne savez probablement pas avoir installé — et c’est celle-là qui m’a fait débrancher une machine à 21 h.

Nicolas Aubry

Nicolas Aubry

Responsable réponse à incident · WebGuard Agency

Résumer cet article : ChatGPT Claude Perplexity

TL;DR — l’essentiel en 30 secondes

  • • Le 4 août 2026, la CISA a ajouté trois CVE à son catalogue KEV : CVE-2026-9198 (injection de code, IBM Langflow), CVE-2026-34486 (défaut de chiffrement de données sensibles, Apache Tomcat) et CVE-2026-18556 (contournement d’authentification, N-able N-central).
  • • « Ajouté au KEV » ne signifie pas « grave ». Cela signifie exploité pour de vrai, maintenant. C’est un critère de priorisation, pas de sévérité.
  • • La faille Langflow est la plus difficile à traiter non pas techniquement, mais parce que l’outil est rarement dans votre inventaire — installé par une équipe data ou métier pour prototyper.
  • • Ordre de traitement recommandé : ce qui est exposé sur internet d’abord, la recherche des installations non déclarées ensuite, les services internes en dernier.

Les trois vulnérabilités, sans le bruit

Le communiqué de la CISA du 4 août 2026 est laconique, comme toujours. Trois entrées, trois identifiants, une phrase chacune. Voici ce qu’il faut en retenir.

CVE-2026-9198 — IBM Langflow, injection de code. Langflow est un outil de composition visuelle de flux d’IA : on y assemble des chaînes de traitement, des appels de modèles et des connecteurs de données. Une injection de code y signifie l’exécution arbitraire sur la machine hôte. Or cette machine détient presque toujours des clés d’API de modèles, souvent des identifiants de bases de données, parfois des jetons d’accès à des dépôts de code.

CVE-2026-34486 — Apache Tomcat, absence de chiffrement de données sensibles. Tomcat est partout, et c’est là toute la difficulté : rarement en frontal, souvent en couche applicative interne, fréquemment embarqué dans un progiciel dont vous ignorez qu’il en contient une version. Le défaut permet à un attaquant déjà présent sur le réseau de récupérer des données qui auraient dû être protégées.

CVE-2026-18556 — N-able N-central, contournement d’authentification par chemin alternatif. Les outils de supervision et de gestion à distance sont une cible de premier choix : ils disposent, par conception, d’un accès privilégié à l’ensemble du parc. Nous avions déjà traité l’exploitation de la faille voisine sur ce même produit ; cette entrée confirme que la famille est activement travaillée par les attaquants.

LES 3 CVE DU 4 AOÛT 2026 — EXPOSITION vs VISIBILITÉ Présence dans votre inventaire → Exposition Langflow CVE-2026-9198 invisible + exécution de code N-central CVE-2026-18556 connu, exposé, corrigeable vite Tomcat CVE-2026-34486 Le danger réel se lit en haut à gauche : forte exposition, faible visibilité.

Notre avis d’expert n°1 : le KEV est un filtre, pas une échelle de gravité

La confusion la plus coûteuse que nous rencontrons en clientèle consiste à lire le catalogue KEV comme un classement de dangerosité. Ce n’en est pas un. Une entrée au KEV signifie une seule chose : la CISA dispose de preuves que cette faille est exploitée dans la vraie vie.

La différence est décisive quand on répartit un budget de correctifs. Une faille notée 9,8 mais jamais exploitée est un risque théorique ; une faille notée 7,2 mais activement utilisée est un risque en cours. Si vous devez choisir aujourd’hui, la seconde passe devant — toujours.

C’est aussi pourquoi le rythme des ajouts compte plus que leur nombre. Trois entrées le 4 août, trois autres le 5 : ce n’est pas une vague exceptionnelle, c’est la cadence normale d’un catalogue qui suit l’activité réelle. Le suivre chaque semaine coûte dix minutes. Ne pas le suivre coûte de corriger dans le désordre.

💡 Ce que nous appliquons en interne

« Toute entrée KEV qui correspond à un produit présent chez un client déclenche une notification sous deux heures, quel que soit son score. Nous avons abandonné le tri par CVSS il y a trois ans : il produisait des files d’attente parfaitement ordonnées et parfaitement déconnectées de ce que faisaient les attaquants. »

Notre avis d’expert n°2 : pourquoi Langflow nous a coûté une soirée

Mardi soir, après lecture du bulletin, nous avons lancé une recherche croisée sur les parcs que nous supervisons. Résultat en quarante minutes : deux instances Langflow chez deux clients différents, aucune des deux déclarée, aucune des deux à jour.

La première tournait sur un poste de travail d’une analyste, sous un compte utilisateur standard, sans exposition réseau au-delà du poste. Risque contenu, correction planifiée le lendemain.

La seconde tournait sur une machine virtuelle de l’environnement de recette, avec un port ouvert sur l’ensemble du réseau interne, et — le point qui a décidé de la coupure — un fichier de configuration contenant une clé d’API de production et les identifiants d’une base de données en lecture. Nous avons isolé la machine à 21 h 10, avant même de savoir si elle avait été touchée.

L’analyse du lendemain n’a montré aucune trace d’exploitation. Tant mieux. Mais la question n’est pas là : cette machine était exploitable depuis des semaines et personne dans l’organisation ne savait qu’elle existait. Le correctif a pris huit minutes. La trouver a pris quarante. Décider quoi faire, une heure.

Savez-vous quels outils d’IA tournent sur votre réseau ?

Nous réalisons un balayage d’inventaire ciblé sur les outils installés hors du circuit informatique — environnements de prototypage, serveurs de modèles, connecteurs de données. Résultat sous 48 h, sans agent à déployer.

Discutons-en →

Sans engagement · Réponse sous 24h

Notre avis d’expert n°3 : l’informatique parallèle de l’IA est le vrai sujet

CVE-2026-9198 n’est pas remarquable techniquement. Une injection de code sur une application web est un classique. Ce qui est nouveau, c’est la catégorie de logiciel touchée et la manière dont elle entre dans les entreprises.

Les outils d’IA se déploient par le bas. Une équipe marketing veut tester une chaîne de résumé documentaire, une équipe data veut prototyper un agent. L’installation prend dix minutes, ne coûte rien, et ne passe par aucune validation. Six mois plus tard, la démonstration est devenue un service utilisé quotidiennement, sans propriétaire, sans suivi de correctifs, avec des secrets en clair dans un fichier de configuration.

Ce schéma n’est pas nouveau — c’est celui de l’informatique parallèle, que nous documentons depuis des années. Ce qui change, c’est la densité de secrets par machine. Un tableur non déclaré contient des données ; un serveur de flux d’IA non déclaré contient des clés d’accès à vos modèles, vos bases et parfois votre dépôt de code. La valeur pour un attaquant n’est pas comparable.

C’est exactement la même mécanique que celle observée sur les serveurs de connexion d’agents, où la surface d’attaque se concentre sur les permissions accordées plutôt que sur le modèle lui-même — un sujet que nos confrères de Plug-Tech ont analysé en détail cette semaine. Et côté organisation des équipes techniques, la question du propriétaire identifié pour chaque composant est traitée par D-Open.

Comment prioriser concrètement cette semaine

Quatre actions, dans cet ordre, exécutables par une petite équipe.

1. Aujourd’hui — corriger ce qui est joignable depuis internet. Une instance N-central ou un Tomcat exposé se traite dans la journée. Vérifiez d’abord votre surface externe réelle, qui diffère souvent de celle documentée.

2. Cette semaine — chercher Langflow, et plus largement les outils d’IA non déclarés. Trois sources suffisent : les journaux du résolveur DNS interne, les relevés de dépenses par carte d’entreprise, et un balayage des ports applicatifs courants sur le réseau interne. Comptez une demi-journée.

3. Cette semaine — traiter les Tomcat internes, y compris ceux embarqués dans des progiciels tiers. C’est le poste le plus laborieux : l’éditeur du progiciel doit souvent fournir la mise à jour, ce qui décale l’échéance. Documentez les cas bloqués plutôt que de les oublier.

4. Ce mois-ci — instaurer la revue hebdomadaire du KEV. Dix minutes le lundi, croisées avec votre inventaire. C’est la mesure la moins spectaculaire de cette liste et la plus rentable sur douze mois. Si votre organisation relève de la directive NIS2, cette revue alimente directement votre dossier — voir notre page audit de périmètre NIS2.

OÙ PASSE RÉELLEMENT LE TEMPS — CAS LANGFLOW, 4 AOÛT Trouver les instances 40 min Décider (isoler ou patcher) 60 min Appliquer le correctif 8 min Le correctif n’est jamais le goulot d’étranglement. L’inventaire l’est toujours.

FAQ

Qu’est-ce que le catalogue KEV de la CISA et pourquoi le suivre depuis la France ?
Le catalogue KEV (Known Exploited Vulnerabilities) recense les vulnérabilités pour lesquelles la CISA dispose de preuves d’exploitation réelle, et non seulement théorique. Son intérêt pour une entreprise française n’est pas réglementaire — il est opérationnel. Sur les dizaines de milliers de CVE publiées chaque année, le KEV isole les quelques centaines effectivement utilisées par des attaquants. C’est le meilleur filtre gratuit disponible pour décider quoi corriger en premier, et il fonctionne quelle que soit la juridiction.
Pourquoi CVE-2026-9198 sur Langflow est-elle plus préoccupante que les deux autres ?
Parce que le logiciel concerné échappe souvent à l’inventaire. Langflow est un outil de composition de flux d’IA, généralement installé par une équipe métier ou data pour prototyper, sans passer par la direction informatique. Une faille d’injection de code sur ce type d’outil combine trois facteurs défavorables : exécution de code, absence de suivi des correctifs, et accès fréquent à des clés d’API et des bases internes. Tomcat et N-central sont plus dangereux en volume, mais ils sont dans les inventaires.
Dans quel ordre corriger ces trois vulnérabilités ?
L’ordre dépend de votre exposition, pas de la gravité affichée. Commencez par ce qui est joignable depuis internet : une instance N-central ou un Tomcat exposé se corrige dans la journée. Traitez ensuite Langflow, en commençant par déterminer s’il existe chez vous — étape qui prend souvent plus de temps que le correctif lui-même. Enfin, les Tomcat internes, qui restent exploitables en déplacement latéral après une compromission initiale.
Comment savoir si un outil d’IA a été installé hors du circuit informatique ?
Trois sources donnent un résultat rapide sans outillage coûteux : les journaux du résolveur DNS interne, où apparaissent les téléchargements de dépendances et les appels sortants vers les fournisseurs de modèles ; les relevés de dépenses par carte bancaire d’entreprise, qui font remonter les abonnements API ; et un simple balayage des ports applicatifs courants sur le réseau interne. La combinaison des trois révèle en général l’essentiel du parc non déclaré.

Le correctif prend 8 minutes. Le trouver prend 40.

Nous croisons chaque semaine le catalogue KEV avec l’inventaire réel de nos clients et déclenchons l’alerte sous deux heures. Sans tri par score, sans file d’attente théorique.

Discutons-en →

🛡️ Audit de sécurité gratuit — réponse en 24h, sans engagement

Obtenir mon audit gratuit →