CISA KEV : 3 failles sur 7 ciblent l'infrastructure IA, dont LiteLLM MCP

Pour la première fois, trois entrées KEV sur sept ciblent des outils d'infrastructure IA

Le 2 septembre 2026, la CISA (Cybersecurity and Infrastructure Security Agency) a publié une mise à jour de son catalogue KEV (Known Exploited Vulnerabilities), ajoutant sept nouvelles vulnérabilités pour lesquelles des preuves d'exploitation active ont été identifiées. Ce qui rend cette mise à jour particulièrement notable, c'est la composition du lot : trois de ces sept failles — soit 43 % — concernent des outils de l'écosystème IA, une première dans l'histoire du catalogue KEV selon plusieurs observateurs de la communauté sécurité.

La vulnérabilité la plus médiatisée est CVE-2026-59822, une faille d'authentification incorrecte dans LiteLLM, le proxy open source de BerriAI massivement utilisé pour agréger et router des requêtes vers différents fournisseurs de modèles (OpenAI, Anthropic, Azure OpenAI, etc.). La faille affecte l'endpoint MCP Streamable HTTP de LiteLLM dans toutes les versions antérieures à 1.84.0. Elle permet à un attaquant non authentifié de soumettre une requête avec un header Authorization forgé contenant n'importe quel token Bearer, déclenchant un chemin de repli OAuth2 qui remplace la validation de clé LiteLLM par un objet UserAPIKeyAuth() vide. En clair, la requête malveillante atteint les outils MCP sans présenter de clé LiteLLM valide.

Le vecteur d'attaque est réseau, sans interaction utilisateur requise, et la complexité d'exploitation est jugée faible. Ces caractéristiques, combinées au score CVSS de 8.8 (élevé), expliquent l'ajout en urgence au KEV. LiteLLM est présent dans des dizaines de milliers de déploiements IA, des prototypes de startups aux infrastructures d'entreprise, ce qui confère à cette faille un périmètre d'exposition très large.

Les deux autres vulnérabilités IA ajoutées au KEV concernent Kestra, la plateforme d'orchestration de workflows IA et données, et Starlette, le framework ASGI Python sur lequel reposent de nombreuses applications IA (notamment des applications FastAPI). Les détails techniques de ces deux CVE n'ont pas été intégralement rendus publics au moment de l'annonce KEV, mais leur inclusion confirme une tendance : les outils périphériques de l'écosystème IA — proxies, orchestrateurs, frameworks d'API — deviennent des cibles de choix pour les attaquants.

Les quatre autres entrées KEV du 2 septembre 2026 couvrent des catégories plus classiques. CVE-2026-82329, une faille de contournement d'authentification exploitée quelques jours seulement après sa divulgation publique, témoigne de la fenêtre d'exploitation qui se rétrécit entre publication et exploitation massive. CVE-2026-19949, une injection SQL sévère permettant une exécution de code à distance non authentifiée, complète ce panorama. La CISA n'a pas précisé les secteurs ou les typologies d'organisations touchées par ces exploitations actives.

La particularité des failles IA au KEV est qu'elles touchent des composants très peu inventoriés dans les programmes de gestion des actifs (CMDB) traditionnels. LiteLLM, Kestra ou Starlette sont souvent déployés par des équipes data ou ML de façon autonome, sans passer par les processus habituels de validation de la sécurité informatique. Ils n'apparaissent pas dans les outils de scan réseau classiques si les services ne sont pas exposés directement sur le réseau d'entreprise. Cette invisibilité opérationnelle est précisément ce qui les rend attractifs pour les attaquants et dangereux du point de vue de la gestion des risques.

La CISA a fixé une date limite de remédiation au 23 septembre 2026 pour les agences fédérales américaines soumises à la directive BOD 22-01. Pour les organisations privées, le catalogue KEV n'est pas juridiquement contraignant, mais il est largement reconnu comme un référentiel de priorisation des patchs par les équipes de sécurité opérationnelle. Les assureurs cyber commencent également à intégrer le respect des délais KEV dans leurs critères d'éligibilité et de tarification des polices.

La correction de CVE-2026-59822 est disponible depuis la version 1.84.0 de LiteLLM, publiée avant l'ajout au KEV. Les organisations qui maintiennent LiteLLM dans leurs environnements doivent vérifier leur version actuelle, appliquer le patch, et auditer leur configuration MCP pour s'assurer qu'aucun endpoint n'est exposé sans contrôle d'accès supplémentaire (pare-feu applicatif, authentification en amont, réseau privé).

L'infrastructure IA, nouvel angle mort de la cybersécurité d'entreprise

L'inclusion de trois failles IA dans un seul lot KEV en septembre 2026 marque un tournant symbolique. Cela fait plusieurs années que les chercheurs en sécurité alertent sur la surface d'attaque spécifique aux outils MLOps et IA : des projets open source souvent maintenus par des équipes réduites, avec des pratiques de développement sécurisé moins matures que dans l'industrie logicielle traditionnelle, et des déploiements rapides qui court-circuitent les processus de validation sécurité.

LiteLLM illustre parfaitement cette dynamique. Lancé en 2023, le projet a connu une croissance explosive portée par l'essor de l'IA générative. Des milliers d'organisations l'ont intégré comme couche d'abstraction entre leurs applications et les API des fournisseurs de modèles. La vitesse d'adoption a précédé la maturité sécuritaire. CVE-2026-59822 n'est pas la première faille critique dans LiteLLM : CVE-2026-35029, une prise de contrôle de l'API d'administration, avait déjà été corrigée quelques mois plus tôt, selon les informations publiées par AiCybr.

Pour les RSSI, cette évolution impose une extension du périmètre de gouvernance des vulnérabilités. Les politiques de patch management doivent explicitement couvrir l'écosystème MLOps : LiteLLM, LangChain, LangGraph, LlamaIndex, Kestra, Airflow IA, les serveurs MCP maison, et les frameworks d'API sous-jacents comme FastAPI/Starlette. L'inventaire de ces composants est souvent lacunaire car ils sont installés dans des environnements Python virtuels, des conteneurs Docker ou des namespaces Kubernetes gérés par les équipes data en dehors des workflows ITIL classiques.

La montée en puissance des protocoles MCP (Model Context Protocol, standardisé par Anthropic en 2024) ajoute une dimension supplémentaire. MCP permet aux agents IA d'interagir avec des outils et des données via des interfaces standardisées. Si un endpoint MCP est compromis via une faille comme CVE-2026-59822, l'attaquant peut potentiellement piloter l'agent IA, lui faire exfiltrer des données, exécuter des outils arbitraires ou intercepter des conversations sensibles. Le champ des conséquences dépasse largement une simple fuite de données : c'est le comportement de l'agent IA lui-même qui peut être détourné.

Les régulateurs européens, dans le cadre de l'AI Act entré en application progressive depuis 2025, commencent à formuler des exigences sur la sécurité des systèmes IA à haut risque. Les failles dans l'infrastructure sous-jacente (proxies, orchestrateurs, endpoints MCP) entrent dans le périmètre de ces exigences pour les systèmes classifiés comme critiques. Les organisations qui déploient des agents IA dans des contextes réglementés — santé, finance, infrastructures critiques — doivent intégrer la sécurité de l'infrastructure IA dans leur programme de conformité, au même titre que la sécurité des données ou la traçabilité des décisions algorithmiques.

Ce qu'il faut retenir

• La CISA a ajouté 7 CVE au KEV le 2 septembre 2026, dont 3 dans l'écosystème IA (LiteLLM, Kestra, Starlette) — une première notable qui reflète la croissance de la surface d'attaque IA.
• CVE-2026-59822 (LiteLLM, CVSS 8.8) permet un accès non authentifié aux sessions MCP via un token arbitraire : migrer vers la version 1.84.0 est urgent.
• Les RSSI doivent étendre leur inventaire de vulnérabilités et leur politique de patch management à l'ensemble de l'écosystème MLOps, souvent déployé hors des processus ITIL classiques.