L'agent IA PageBreak de Google a trouvé plus de 500 failles XSS dans ses propres applications

Google a détaillé PageBreak, un agent d'IA interne qui traque les failles de sécurité dans les applications web de l'entreprise. Déployé à très grande échelle, il a mis au jour plus de 500 vulnérabilités de type cross-site scripting (XSS) dans les applications web propres à Google, dont certaines sur des domaines sensibles, écrit l'ingénieur sécurité de Google Michał Bentkowski sur le blog de l'entreprise ; iThome rapporte les mêmes chiffres.

Le cross-site scripting est une catégorie de vulnérabilité dans laquelle un attaquant parvient à injecter du code JavaScript dans une page web consultée par un autre utilisateur, ce qui peut lui permettre d'agir dans la session de la victime. C'est l'une des failles les plus répandues dans les applications web.

Le problème que PageBreak veut résoudre : le bruit de l'IA

Recourir aux grands modèles de langage pour analyser le code a transformé la gestion des vulnérabilités, mais a aussi créé du bruit, explique Google. De nombreuses équipes de sécurité sont submergées parce qu'une part importante des signalements qu'elles reçoivent sont des hypothèses non vérifiées ou des faux positifs produits par des modèles utilisés comme analyseurs statiques de code, ce que l'entreprise appelle l'AI slop. Distinguer une faille réelle et exploitable d'une hallucination convaincante est devenu un défi majeur, qui alourdit souvent la charge des équipes produit.

PageBreak a démarré comme pilote en novembre 2025 et est devenu un projet à part entière en janvier 2026. Il peut fonctionner avec différents modèles, mais s'appuie surtout sur des modèles Gemini comme Gemini 3.1 Pro et Gemini 3.5 Flash, selon Google.

Comment fonctionnent les validateurs

Le choix de conception central est la validation déterministe. Quand l'agent repère une faille potentielle, il transmet son hypothèse à un validateur spécialisé, écrit sans IA, qui exécute une véritable charge contre un environnement en fonctionnement pour confirmer l'exploitation. Les candidats non vérifiés ne sont jamais transmis aux équipes produit. Google affirme obtenir ainsi un taux de faux positifs proche de zéro, un point que souligne aussi iThome.

• XSS : injecte une charge JavaScript, charge l'URL dans un environnement de rendu et vérifie si le code injecté s'exécute réellement.
• Injection SQL : vérifie si les requêtes à la base de données peuvent être manipulées en observant la réponse ou le temps de réponse.
• Traversée de répertoires : crée un fichier dans un emplacement lisible par tous et vérifie si l'application peut le lire.
• Exécution de code à distance : tente des techniques comme un délai d'attente, l'écriture d'un fichier ou le déclenchement d'une requête DNS ou HTTP sortante.
• Falsification de requête côté serveur : détecte si l'application envoie une requête vers un service interne.

Google reconnaît que ses validateurs ne couvrent pas encore tous les types de vulnérabilités ni tous les scénarios complexes, ce qui crée un risque de failles manquées. Les résultats non vérifiés sont donc conservés en interne : ils servent de point de départ à des analyses plus poussées lors des passes suivantes, montrent où de nouveaux validateurs sont nécessaires, et l'agent signale les capacités ou les accès qui lui ont manqué pour confirmer une découverte.

Des failles que les humains n'avaient pas vues

Google a aussi décrit trois cas de gravité élevée découverts par PageBreak dans des applications déjà examinées par ses ingénieurs sécurité et par des chasseurs de bugs externes sans que ces failles aient été trouvées, rapporte iThome. Dans l'un d'eux, l'agent a trouvé une XSS sur admin.google.com qui exigeait une signature valide sur la requête ; il a ensuite trouvé un autre point d'accès qui amenait l'application à générer une signature valide pour un paramètre malveillant, ce qui permettait de construire une URL d'exploitation contournant la protection par signature. Selon Google, ces cas montrent que les modèles de langage sont de plus en plus capables de trouver des vulnérabilités dont l'exploitation demande plusieurs étapes.

Google a publié les détails techniques de ces exploitations dans un article complémentaire sur son blog Bug Hunters. On y trouve notamment une faille complexe d'empoisonnement de cache, due à la mauvaise configuration d'un service, et un cas où l'agent a contourné entièrement seul des protections cryptographiques, selon l'entreprise. Ces exemples comptent parce qu'ils dépassent les schémas d'injection simples que les scanners classiques détectent déjà.

L'agent a aussi profité d'atouts propres à Google, indique l'entreprise : un dépôt de code unique de plusieurs milliards de lignes, des signaux de sécurité qui relient le trafic HTTP réel à des lignes de code source, et un scanner existant capable de s'authentifier sur presque toutes les applications web de Google. Pour augmenter ses chances, Google lance les agents avec des graines identiques sur de nombreuses itérations.

Ce que changent les frameworks sécurisés dès la conception

Le résultat le plus frappant concerne les applications construites sur les frameworks web à haut niveau d'assurance de Google, conçus pour éliminer par défaut les vulnérabilités web exploitables. Au 4 septembre 2026, PageBreak n'avait trouvé que 2 failles XSS sur des centaines d'applications construites sur ces frameworks, toutes deux limitées à des applications internes ou à des points de débogage insuffisamment durcis, écrit Google. Même vérifiés, les signalements arrivent en volume inédit : PageBreak travaille donc avec d'autres agents comme CodeMender, qui génèrent des correctifs automatiques, afin de réduire à terme le rôle des équipes produit à la validation des correctifs proposés.

Ce que cela change pour les entreprises françaises

Pour les éditeurs de logiciels et les équipes de sécurité internes qui reçoivent désormais des signalements de vulnérabilités générés par l'IA, l'approche de Google fournit une règle pratique : ne pas agir sur un soupçon de modèle tant qu'un test déterministe n'a pas reproduit l'exploitation. Le résultat sur les frameworks est tout aussi utile : la façon la moins coûteuse de résister à des attaquants automatisés est de bâtir les applications web sur des frameworks qui bloquent par défaut des catégories entières de failles, plutôt que de traquer les bugs un par un après coup.