Le Threat Intelligence Group de Google (GTIG) affirme avoir, pour la première fois, vu un acteur malveillant utiliser un exploit zero-day qu'il pense avoir été construit avec l'aide d'un modèle d'IA. L'exploit était un script Python qui contournait l'authentification à deux facteurs sur un outil d'administration open source. Google a tu à la fois l'acteur et le produit pour protéger le correctif.
Le titre s'écrit tout seul, mais il pointe dans la mauvaise direction. Le vrai changement n'est pas un phishing plus intelligent ni des appâts mieux rédigés. C'est la compression du cycle d'exploitation : l'IA réduit le temps et les compétences qu'il faut pour trouver une vulnérabilité et la transformer en exploit fonctionnel. Pour quelque chose d'aussi vaste et d'aussi exposé qu'un navigateur web, cela change l'équation.
Ce que Google a réellement trouvé
Le rapport du GTIG, publié le 2026-05-11, est prudent sur ce qu'il affirme. Il ne dit pas que l'IA a écrit l'exploit. Il dit que Google a une grande confiance, sur la base de la structure du code, dans le fait que l'acteur a utilisé un modèle d'IA pour aider à découvrir et à militariser le bug. Les indices étaient dans le code source : des docstrings dignes d'un manuel, une mise en page Pythonic étrangement digne d'un tutoriel et un score CVSS halluciné qu'aucun chercheur humain n'inventerait. Google note aussi que son propre modèle, Gemini, n'était probablement pas celui utilisé.
Le même rapport décrit trois autres schémas qu'il convient de distinguer du battage médiatique :
- La génération d'exploits assistée par IA, où les modèles accélèrent la recherche et la militarisation plutôt que de remplacer l'attaquant.
- Des logiciels malveillants plus autonomes, encore expérimentaux, où une charge utile interroge un modèle à l'exécution pour lire l'état du système et choisir son action suivante au lieu de suivre une logique codée en dur. Google cite des familles au stade de recherche comme PROMPTSPY et PROMPTFLUX.
- L'abus industrialisé de l'accès aux modèles premium, où des criminels utilisent des intergiciels et des pipelines d'inscription automatisés pour contourner les limites d'utilisation.
Rien de tout cela n'est « l'IA remplace les hackers ». C'est « l'IA rend plus rapides les parties lentes et coûteuses ». C'est cette partie que les défenseurs devraient anticiper.
Le vrai changement est la compression du cycle d'exploitation
Trouver une vulnérabilité sérieuse et écrire un exploit fiable a toujours été la partie coûteuse d'une attaque. Cela demande des compétences rares, du temps et de la patience. Le texte de phishing n'a jamais été le goulot d'étranglement.
La compression s'attaque à ce goulot d'étranglement. Quand un modèle aide un acteur de niveau intermédiaire à lire du code source inconnu, à repérer un chemin de code faible et à échafauder une preuve de concept fonctionnelle, l'écart entre « un bug existe » et « un bug est exploité à grande échelle » se réduit. Le cas de Google est un point de données. C'est la tendance qui compte : recherche plus rapide, militarisation plus rapide, tempo opérationnel plus élevé.
Cela importe surtout pour les logiciels qui sont énormes, en évolution rapide et omniprésents. Le navigateur en est l'exemple le plus clair.
Pourquoi le navigateur est la plus grande cible
Les navigateurs sont des systèmes vastes et multicomposants
Un navigateur moderne n'est pas un seul programme. Chromium, le moteur derrière Chrome, Edge, Brave, Opera et bien d'autres, atteint des dizaines de millions de lignes de code et intègre plus de 200 bibliothèques tierces. Beaucoup d'entre elles sont open source et maintenues par des équipes distinctes :
- V8 exécute JavaScript et WebAssembly.
- Blink affiche la page.
- Skia dessine les graphiques 2D.
- ANGLE traduit les appels graphiques pour le GPU.
- libwebp décode les images WebP.
- WebRTC gère l'audio et la vidéo en temps réel.
Chacun d'eux est une surface d'attaque. Un seul bug mémoire dans l'un d'eux peut devenir une exécution de code à distance. L'open source est un atout pour la revue et la rapidité, mais cela signifie aussi que le code exact qu'un attaquant étudie est le même code qui est livré à des milliards d'appareils.
De nouvelles fonctionnalités sortent en permanence, et de nouveaux zero-days suivent
Chrome livre une nouvelle version majeure environ toutes les quatre semaines, et la plateforme web ne cesse de croître : nouvelles API, nouveaux codecs, nouveaux chemins GPU. Plus de fonctionnalités signifient plus de code, et plus de code signifie plus de bugs. Le résultat est constant, pas occasionnel. Google a corrigé environ neuf zero-days Chrome activement exploités en 2024 et environ huit en 2025, et ils se concentrent dans les mêmes composants complexes :
- Confusion de type dans V8 : CVE-2025-10585 et CVE-2025-13223.
- Validation ANGLE et GPU : CVE-2025-6558.
- À nouveau Skia et V8 en 2026 : CVE-2026-3909 et CVE-2026-3910, tous deux exploités dans la nature.
Les zero-days dans le navigateur ne sont pas des événements rares pour lesquels se préparer. Ce sont une condition récurrente autour de laquelle concevoir.
Un seul composant open source, un rayon d'impact transécosystème
L'avertissement le plus clair est venu de libwebp. La CVE-2023-4863 était un dépassement de tampon de tas dans cette seule bibliothèque de décodage d'images, exploitable avec un unique fichier WebP forgé. Elle a d'abord été notée 8.8 en tant que bug Chrome, puis réévaluée à 10.0 une fois la portée comprise, parce que libwebp est partout. (Un second identifiant, CVE-2023-5129, a ensuite été regroupé comme doublon.)
Le même bug a touché Chrome, Firefox, Signal, 1Password, Telegram et, de façon critique, presque toutes les applications construites sur Electron. Une bibliothèque, une faille, et le rayon d'impact couvrait une large partie des logiciels que les gens utilisent tous les jours.
Les zero-days ne s'arrêtent pas à l'onglet du navigateur
C'est là que la compression devient dangereuse. Le bac à sable du navigateur existe pour une raison : un onglet est censé être un environnement hostile, isolé du reste de votre machine. Mais le même moteur qui propulse votre navigateur est aussi livré à l'intérieur d'applications de bureau.
Electron embarque sa propre copie de Chromium afin que les développeurs web puissent construire des applications au rendu natif. VS Code, Slack, Discord et l'application de bureau Claude d'Anthropic sont toutes des applications Electron. Chacune embarque sa propre build de Chromium, et ces builds accusent un retard sur l'amont. Quand Google corrige un zero-day de V8, chaque application Electron reste vulnérable jusqu'à ce qu'elle intègre le correctif et publie une mise à jour, ce qui peut prendre des semaines.
Combinez maintenant deux faits. Premièrement, ces applications héritent des zero-days du navigateur. Deuxièmement, elles s'exécutent en dehors du bac à sable du navigateur, souvent avec un accès complet au système de fichiers, et dans le cas des agents de codage IA, la capacité d'exécuter des commandes shell. Un bug du moteur de navigateur qui serait un problème confiné et isolé dans un onglet devient bien plus grave à l'intérieur d'une application locale qui peut lire vos fichiers et exécuter du code. Le cas libwebp a déjà prouvé que les applications Electron héritent de ces failles. À mesure que les applications de bureau IA et les agents de codage se répandent, la population de logiciels à privilèges élevés embarquant Chromium sur les machines des développeurs ne cesse de croître, et le gain potentiel d'un seul zero-day du moteur de navigateur aussi.
Les dépendances empoisonnées s'exécutent dans le même navigateur
La compression a un second front : la chaîne d'approvisionnement. La même IA qui accélère la recherche d'exploits accélère la découverte et l'abus de dépendances faibles, et le code des dépendances s'exécute exactement là où vous ne pouvez pas voir depuis le serveur.
L'écosystème npm l'a rendu concret en 2025. Le 2025-09-08, des attaquants ont hameçonné un mainteneur et publié des versions malveillantes de paquets extrêmement populaires, dont chalk et debug. La charge utile injectée était un crypto-clipper ciblant le navigateur : il interceptait window.ethereum et les appels réseau pour échanger silencieusement les adresses de portefeuille dans le navigateur de la victime. Quelques jours plus tard, le ver auto-réplicant « Shai-Hulud » a compromis des centaines de paquets et a volé des identifiants de développeurs au fur et à mesure de sa propagation.
C'est le schéma Magecart généralisé. Le code tiers malveillant n'a pas besoin d'un bug mémoire. Il lui suffit de se charger, et une fois qu'il le fait, il s'exécute dans le même contexte que votre page, avec accès aux formulaires, aux jetons et à tout ce que l'utilisateur saisit.
Pourquoi le scan préalable à la mise en production ne suffit pas
La plupart des budgets de sécurité se situent encore avant le déploiement : analyse statique, scan des dépendances, une étape de revue, puis livraison. Ces contrôles sont nécessaires, mais ils partagent un même angle mort. Ils inspectent un instantané d'un code que vous connaissez déjà, à un moment précédant son exécution.
Les zero-days sont, par définition, les bugs que personne n'a encore répertoriés. Les dépendances compromises changent souvent après avoir passé la revue, troquant du code propre contre du code malveillant lors d'un chargement ultérieur. Les scripts tiers se mettent à jour eux-mêmes en production sans rien demander. Et la compression du cycle d'exploitation raccourcit la fenêtre entre le moment où une faille devient connue et celui où elle est utilisée. Scanner un instantané préalable à la mise en production ne peut pas attraper une charge utile qui n'apparaît qu'à l'exécution, dans le navigateur, une fois votre pipeline terminé.
Cet écart n'est pas une défaillance d'outillage. C'est une défaillance de visibilité. Vous ne pouvez pas scanner votre chemin jusqu'à voir ce qui s'exécute dans la session de navigateur de quelqu'un d'autre.
Que faire cette semaine
- Inventoriez chaque script tiers sur votre site, y compris ceux chargés par d'autres scripts.
- Surveillez le comportement des scripts à l'exécution, pas seulement au déploiement : ce qui se charge, ce qui a changé, ce que chaque script lit et où il envoie les données.
- Resserrez la cadence des correctifs pour les navigateurs et pour les applications Electron que votre équipe utilise. Traitez un zero-day Chromium comme une échéance pour VS Code, Slack et les outils similaires, pas seulement pour le navigateur.
- Appliquez une Content Security Policy qui limite d'où les scripts peuvent se charger et où les données peuvent être envoyées.
- Alertez sur les anomalies : un script connu qui contacte soudain un nouveau domaine, lit des champs de paiement ou modifie sa charge utile.
Comment cside s'intègre
cside surveille la couche que le reste de votre stack ne peut pas voir : la session de navigateur en direct. Elle vous donne une visibilité runtime sur chaque script qui s'exécute sur votre site, ce qu'il charge, comment il a changé depuis la dernière version, les données qu'il touche et où ces données vont.
Cela compte dans un monde de cycles d'exploitation comprimés, car cela ne dépend pas de la connaissance préalable de l'exploit. Quand un script de confiance commence à se comporter différemment, quand une dépendance substitue du nouveau code après le déploiement, ou quand une charge utile commence à exfiltrer des données de formulaire, le changement est visible à l'exécution, même si la vulnérabilité sous-jacente est toute nouvelle. Le scan préalable à la mise en production vous renseigne sur le code que vous avez livré. cside vous dit ce qui s'exécute réellement en ce moment.
Commencez par la sécurité côté client pour une surveillance runtime complète des scripts, ou par Privacy Watch pour voir exactement ce que les scripts tiers collectent et envoient.
Pour aller plus loin sur cside
- Compromission de la chaîne d'approvisionnement du Web SDK d'AppsFlyer
- Les plus grandes attaques Magecart de l'histoire (à ce jour)
- Attaque de la chaîne d'approvisionnement web via un jQuery trojanisé
- Comment des scripts tiers compromis peuvent injecter des prompts aux agents IA
- Bonnes pratiques pour sécuriser les scripts tiers
Au 2026-06-03. Les décomptes de zero-days Chrome et les conclusions du GTIG reflètent les informations disponibles à cette date.
À propos de l'auteur
Simon Wijckmans est le fondateur et CEO de cside. Il écrit sur la sécurité côté client, les menaces au niveau du navigateur, les scripts tiers et le travail de normalisation nécessaire pour rendre le web plus sûr.
