Pwn2Own Ireland 2026 s'est terminé avec un bilan record : 98 zero-days exploités, 1 262 000 dollars de primes versées, et pour la première fois dans l'histoire du concours, des outils d'intelligence artificielle figurent parmi les cibles effectivement compromises. La Zero Day Initiative (ZDI), organisatrice de Pwn2Own, a ouvert une catégorie « AI tools » incluant des passerelles LLM, des agents de codage et des bases de données vectorielles.
La compétition, qui a débuté le 6 octobre 2026, a vu des chercheurs en sécurité exploiter OpenAI Codex, LiteLLM, NVIDIA Dynamo, Chroma et Oracle Autonomous AI Database. Les techniques utilisées ne sont pas nouvelles — injection d'arguments, SSRF, injection de code — mais leur application réussie sur des outils IA en production confirme ce que beaucoup suspectaient : les passerelles LLM et les agents de codage cloud sont désormais des cibles actives, et leurs chaînes de défense ont les mêmes lacunes que n'importe quelle application web mal auditée.
Cet article décrypte les exploits connus, ce qu'ils révèlent sur la surface d'attaque réelle des agents IA, et les mesures concrètes à prendre si vous utilisez ces outils en production ou si vous déployez des architectures similaires.
LiteLLM et OpenAI Codex : les exploits en détail
Deux outils IA ont concentré l'essentiel de l'attention de la communauté sécurité lors de cette édition.
LiteLLM : SSRF combinée à l'injection de code
Taisic Yun, de l'équipe Xint, a exploité LiteLLM en combinant une faille d'injection de code avec une validation d'entrée incorrecte pour obtenir un reverse shell sur le serveur hébergeant la passerelle. La prime versée s'élève à 40 000 dollars. Une deuxième équipe, Out of Bounds, a exploité LiteLLM via une chaîne de quatre vulnérabilités dont deux failles déjà connues, pour une prime de 15 000 dollars.
LiteLLM est un proxy open source largement utilisé dans les architectures multi-modèles pour uniformiser les appels API vers OpenAI, Anthropic, Mistral et d'autres fournisseurs. Sa popularité en fait une cible à fort impact : une compromission du proxy donne potentiellement accès aux clés API de tous les fournisseurs configurés, ainsi qu'aux prompts et aux réponses transitant par le service.
OpenAI Codex : une seule faille d'injection d'arguments
L'équipe Ikotas Labs a compromis OpenAI Codex — l'agent de codage cloud d'OpenAI — avec une unique faille d'injection d'arguments, pour une prime de 40 000 dollars. La ZDI n'a pas divulgué les détails complets de l'exploit dans son rapport de premier jour, conformément à sa politique de non-divulgation de 90 jours accordée aux vendeurs pour patcher.
Ce qui est notable ici n'est pas la complexité de l'exploit — une seule faille a suffi — mais ce qu'il révèle sur la surface d'attaque : un agent cloud qui exécute du code possède par définition des capacités d'exécution à distance, et la frontière entre le code légitime qu'il produit et le code qu'un attaquant peut lui faire exécuter est mince si l'injection d'arguments n'est pas correctement filtrée.
NVIDIA Dynamo, Chroma et Oracle AI Database
Au-delà de LiteLLM et OpenAI Codex, trois autres outils de l'écosystème IA ont été compromis lors du concours. Les détails techniques restent sous embargo de 90 jours, mais leur présence dans la liste des cibles est en elle-même instructive.
NVIDIA Dynamo
NVIDIA Dynamo est un framework d'inférence distribué conçu pour les clusters GPU à grande échelle. Sa compromission lors de Pwn2Own confirme que l'infrastructure d'inférence IA — pas seulement les interfaces applicatives — est désormais dans le périmètre des audits de sécurité offensifs. Une vulnérabilité dans Dynamo peut impacter l'ensemble des workloads IA exécutés sur le cluster.
Chroma
Chroma est une base de données vectorielle open source très répandue dans les architectures RAG (Retrieval-Augmented Generation). Sa présence dans le concours signale que les composants de l'infrastructure IA — bases vectorielles, pipelines d'embedding — font désormais l'objet d'une recherche de vulnérabilités active. Une compromission d'une base vectorielle peut exposer l'intégralité des documents indexés, souvent des données internes sensibles.
Oracle Autonomous AI Database
Oracle a intégré des fonctionnalités IA directement dans sa base de données gérée. La compromission de l'Oracle Autonomous AI Database élargit le périmètre des risques IA aux systèmes de gestion de données traditionnels augmentés par des capacités d'IA. Les organisations qui ont activé ces fonctionnalités dans leurs environnements Oracle existants doivent surveiller les bulletins de sécurité Oracle publiés d'ici début janvier 2027, date de fin de la période de non-divulgation.
Bilan final du concours
L'édition 2026 de Pwn2Own Ireland a établi plusieurs records. Au total, 98 zero-days ont été démontrés pour un total de 1 262 000 dollars versés, selon BleepingComputer. Le premier jour seul avait vu 32 zero-days pour 388 500 dollars.
L'équipe Ikotas Labs a remporté le titre de « Master of Pwn » avec 42,5 points et 361 000 dollars de gains cumulés, dont 300 000 dollars pour une chaîne multi-bugs ayant compromis le Google Pixel 10. L'équipe Xint a terminé deuxième avec 240 000 dollars, et Team ZyGoat troisième avec 125 000 dollars.
La politique de la ZDI prévoit un délai de non-divulgation de 90 jours, pendant lequel les vendeurs concernés reçoivent les détails techniques complets des exploits pour préparer leurs correctifs. Pour LiteLLM et OpenAI Codex, cette fenêtre court jusqu'à début janvier 2027. D'ici là, les détails des chaînes d'exploitation ne seront pas publiés publiquement — mais des chercheurs indépendants peuvent avoir découvert les mêmes failles.
Ce que révèle Pwn2Own sur la surface d'attaque des agents IA
Les résultats de Pwn2Own Ireland 2026 confirment trois tendances que la communauté sécurité anticipait mais qui n'avaient pas encore été prouvées dans un cadre de compétition officiel.
Les passerelles LLM sont des cibles à fort impact
LiteLLM, OpenRouter et leurs équivalents jouent le rôle de proxy entre votre application et les API des fournisseurs de modèles. Ils centralisent toutes les clés API, tous les prompts et toutes les réponses. Une compromission de ce composant donne accès à l'intégralité du trafic IA de l'organisation. Si vous utilisez LiteLLM en production, vérifiez votre version et appliquez les mises à jour publiées après le 6 octobre dès leur disponibilité.
Les techniques classiques fonctionnent sur les nouvelles infrastructures IA
Les exploits réussis — injection d'arguments, SSRF, injection de code — ne sont pas spécifiques à l'IA. Ce sont des classes de vulnérabilités connues depuis des décennies, appliquées à des logiciels récents qui n'ont pas bénéficié des mêmes cycles d'audit que les applications web matures. L'outillage IA évolue très vite, mais les équipes de développement n'ont souvent pas le temps de faire des revues de sécurité en profondeur avant de mettre en production. Cela laisse des fenêtres d'exploitation prévisibles.
Les bases de données vectorielles entrent dans le périmètre des audits offensifs
La présence de Chroma dans la liste des cibles est un signal fort : les composants intermédiaires de l'infrastructure IA — bases vectorielles, pipelines RAG, stores d'embeddings — doivent être intégrés aux audits de sécurité au même titre que les API et les bases de données traditionnelles. Ils contiennent souvent les données internes les plus sensibles de l'organisation, indexées et prêtes à être requêtées. Pour comprendre comment sécuriser vos déploiements d'agents, voir notre article sur les agents IA comme vecteurs d'attaque.
Mesures pratiques pour vos déploiements
Si vous utilisez LiteLLM, OpenAI Codex, Chroma ou un système similaire en production, voici les actions à prioriser avant la publication des détails techniques en début 2027.
Mettre à jour LiteLLM immédiatement
Surveillez le dépôt GitHub LiteLLM et les annonces de l'équipe BerriAI pour les correctifs publiés après le 6 octobre 2026. La mise à jour vers la dernière version stable dès sa disponibilité est la mesure la plus directe. Si vous ne pouvez pas mettre à jour immédiatement, restreignez l'accès réseau au proxy LiteLLM aux seules sources légitimes via votre pare-feu ou vos règles réseau.
Auditer les permissions réseau de vos passerelles LLM
Les exploits SSRF exploitent la capacité d'une application à initier des requêtes vers des ressources réseau internes. Vérifiez que votre passerelle LLM ne peut pas initier de connexions vers votre réseau interne (metadata d'instance cloud, services internes) au-delà des API LLM qu'elle est censée appeler. Une politique de sortie réseau stricte (allowlist par défaut) réduit significativement la surface d'exploitation.
Limiter l'exécution de code dans les agents de codage
Pour les agents de codage (Codex ou équivalents), l'exécution de code doit se faire dans un environnement isolé : sandbox, conteneur éphémère, sans accès au réseau interne de production. C'est exactement ce que décrit notre article sur les sandboxes pour agents IA. Un agent de codage qui peut exécuter directement du code sur votre infrastructure de production est un risque inacceptable, indépendamment des résultats de Pwn2Own.
Intégrer les outils IA dans vos audits de sécurité réguliers
Les LLM gateways, les bases vectorielles et les agents de codage doivent figurer dans le scope de vos pentest et audits de sécurité périodiques. Ce n'est plus une option : Pwn2Own 2026 a officialisé leur statut de cibles réelles. Pour concevoir une architecture d'agent IA avec les bons niveaux d'isolation dès le départ, contactez notre équipe.
FAQ — Pwn2Own Ireland 2026 : LiteLLM percé par injection de code, OpenAI Codex tombé en une faille — 98 zero-days, 1,26 M$ et les agents IA comme nouvelle surface d'attaque
Dois-je désactiver LiteLLM en production en attendant les correctifs officiels ?
Pas nécessairement, mais prenez des mesures immédiates. Mettez à jour vers la dernière version disponible, restreignez l'accès réseau au proxy aux seules sources autorisées, et désactivez toute exposition directe sur l'internet public. Si votre déploiement est exposé sans authentification ni filtrage réseau strict, une mise hors ligne temporaire vaut mieux qu'une compromission complète des clés API.
LiteLLM est open source — les correctifs seront-ils publiés avant la fin des 90 jours de la ZDI ?
Les 90 jours de la ZDI sont accordés au vendeur pour préparer ses correctifs, mais rien n'empêche BerriAI (l'équipe derrière LiteLLM) de publier des correctifs avant la fin de cette période. Suivez le dépôt GitHub LiteLLM et les communications officielles de l'équipe pour les mises à jour de sécurité. La ZDI peut aussi accélérer la divulgation si elle constate que la faille est activement exploitée.
Comment savoir si ma base de données vectorielle Chroma est vulnérable ?
Les détails de l'exploit Chroma ne seront pas publics avant début janvier 2027 au plus tôt. En attendant, les mesures de bon sens s'appliquent : Chroma ne devrait jamais être exposée directement sur internet, l'accès devrait être restreint au réseau applicatif via des règles pare-feu, et l'authentification devrait être activée. Vérifiez régulièrement le dépôt officiel Chroma pour les annonces de sécurité.
Ces vulnérabilités touchent-elles les offres cloud gérées ou seulement les déploiements self-hosted ?
Cela dépend de l'outil. LiteLLM est principalement self-hosted, donc les clients qui gèrent leur propre instance sont directement concernés. OpenAI Codex est une offre cloud gérée par OpenAI, qui est responsable du correctif côté serveur. Pour Oracle Autonomous AI Database, Oracle est également responsable de la correction. Dans tous les cas, surveillez les bulletins de sécurité des vendeurs concernés et appliquez les mises à jour disponibles.