Pagebreak Trouve Plus De 500 Failles Xss Chez Google

Plus de cinq cents failles de scripts intersites confirmées sur les propres applications web de Google, ce n’est pas un communiqué anodin. C’est le signal qu’un agent d’audit, nourri de modèles de langage et encadré par des validateurs indépendants, est désormais capable de transformer une suspicion en preuve d’exécution. L’annonce, datée du 25 septembre 2026, ne nomme pas les produits touchés. Elle insiste en revanche sur une idée plus dérangeante pour toute équipe qui gère de l’argent, des sessions ou des clés : une description d’attaque peut sembler brillante et rester totalement inopérante.

Ce Que Change Vraiment PageBreak

Le projet a d’abord vécu en pilote dès novembre 2025, puis a basculé en programme formel en janvier 2026. Il ne se contente pas de lire du code. Il interroge des applications vivantes, s’appuie sur le dépôt interne, relie une page vue dans le trafic réel à sa source, et tente ensuite de faire tourner un payload. Cette boucle, banale à écrire, est rare à tenir à grande échelle. Elle explique pourquoi le volume annoncé dépasse largement ce qu’un chercheur extérieur peut raisonnablement démontrer sans accès authentifié.

Le XSS, ou cross-site scripting, reste un classique. Une application laisse s’exécuter le script d’un tiers dans le navigateur d’un autre utilisateur. Selon le contexte, cela peut voler une session, afficher un écran de collecte, ou agir au nom de la victime. Google n’a pas publié de ventilation par gravité. Le chiffre global, « plus de 500 », recouvre l’ensemble de ses applications web de première partie, pas seulement les services grand public.

Une piste d’attaque convaincante n’est pas un bug. Tant qu’un script n’a pas réellement tourné, le rapport reste une hypothèse de travail.

Équipe sécurité produit de Google

Une validation qui refuse le théâtre

Le point le plus utile de la démarche n’est pas le modèle. C’est le filtre placé après lui. Chaque candidat XSS passe par un validateur distinct. Celui-ci injecte un payload JavaScript, charge la page concernée, puis vérifie si le script s’exécute vraiment. Google affirme que ce filet maintient le taux de faux positifs proche de zéro. Les équipes produit ne reçoivent donc pas une nouvelle de science-fiction. Elles reçoivent un cas déjà éprouvé.

Le même principe s’étend à d’autres classes de défauts. Un validateur observe si une entrée altère une requête de base de données. Un autre cherche une traversée de chemin qui livrerait un fichier. Un troisième teste l’exécution de code. Un dernier surveille les appels vers des services internes. Rien de cela n’est rédigé par l’agent. Les validateurs restent des outils maîtrisés, écrits et entretenus par des humains.

Cette architecture répond à une fatigue déjà connue des équipes de sécurité. Les rapports générés par des modèles savent raconter un enchaînement impeccable. Ils citent des fonctions, imaginent des redirections, décrivent un cookie volé. Puis la reproduction échoue. Le code n’est jamais atteint. La condition d’entrée n’existe plus. Le contexte d’authentification n’est pas celui décrit. PageBreak conserve ces pistes à l’intérieur du flux sécurité. Elles nourrissent les scans suivants ou aident à concevoir de nouveaux validateurs. Elles ne partent pas comme bugs confirmés.

Gemini scanne, l’humain encadre encore

La plupart des passages s’appuient sur des modèles Gemini, notamment Gemini 3.1 Pro et Gemini 3.5 Flash. L’agent n’est pas collé à une seule famille. Google précise qu’il peut changer de modèle. Cette souplesse n’efface pas une contrainte plus triviale : un modèle s’entête parfois dans une voie stérile. D’où les tentatives répétées. On relance, on recadre, on laisse une autre trajectoire émerger. Ce n’est pas de la magie. C’est de l’itération coûteuse, assumée.

Les ressources internes font le reste. Le dépôt de code permet de suivre un flux d’un service à l’autre. Les données de trafic relient une URL demandée au fichier qui la sert. Des scanners déjà en place donnent un accès authentifié à des sites internes que rarement un chercheur externe pourra inspecter. Ces leviers expliquent le volume. Ils interdisent aussi une lecture naïve : lancer le même modèle hors de Google ne reproduira pas le même tableau de chasse.

Deux failles seulement dans les cadres renforcés

Le détail le plus intéressant n’est pas le total. C’est le sous-ensemble. Parmi des centaines d’applications construites sur les frameworks web dits à haute assurance de Google, PageBreak n’avait recensé que deux XSS au 4 septembre. Les deux cas tenaient à des applications internes ou à des points de débogage dont les protections n’étaient pas complètes. Autrement dit, le cadre tient. Les écarts apparaissent là où l’on relâche volontairement une barrière pour investiguer plus vite.

Cette mesure donne à l’entreprise un banc d’essai. On peut scanner encore et encore les mêmes bases et voir si l’architecture cède. Un chiffre global impressionne. Un chiffre conditionné par un cadre de conception renseigne. Les équipes qui bâtissent des portefeuilles, des ponts ou des consoles d’administration devraient retenir cette distinction. Le volume brut dit peu si l’on ignore sur quel socle l’application a été posée.

Deux XSS sur des centaines d’applications protégées, c’est moins un échec qu’une cartographie des zones où l’on a choisi d’ouvrir une fenêtre.

Lecture interne du résultat frameworks

Le même fardeau existe déjà dans le crypto

Les équipes qui écrivent des protocoles, des clients légers ou des bibliothèques pair-à-pair connaissent déjà cette inflation de rapports plausibles. En juillet, des travaux de recherche en sécurité autour d’Ethereum ont décrit un schéma voisin : des agents formulent des pistes, des relecteurs tentent de les reproduire. Une faille confirmée dans libp2p a ensuite été publiée sous l’identifiant CVE-2026-34219. Le reste du flux contenait des chemins morts, du code inatteignable, des préconditions qui ne tiennent pas dans le déploiement réel.

Un autre exercice, mené en août par une équipe présentée comme Bitcoin Red Team, a consigné 7 958 constats sur 501 projets open source après 108 heures de scan. À ce stade, 24,7 % des éléments avaient une preuve reproductible. Le total n’équivalait donc pas à 7 958 vulnérabilités exploitables. Quiconque lit un tableau de bord d’audit sans cette fraction se trompe de combat. Il gère du bruit avec le sérieux dû à une brèche.

Les programmes de primes subissent la même poussée. Cosmos Labs avait indiqué en avril que les soumissions à son programme avaient grimpé de 900 % sur un an, mélange de dossiers valides et de dossiers vides. PageBreak, lui, reste un outil interne. Google n’a pas annoncé de mise à disposition pour des projets crypto. La leçon, pourtant, circule déjà : la valeur d’un agent se mesure après reproduction, pas au moment où le modèle rédige sa prose.

Pourquoi le XSS reste un risque d’argent

Dans une interface de portefeuille, un script tiers peut viser la session, le presse-papiers, ou un écran de confirmation. Dans une console d’échange, il peut déclencher une action déjà authentifiée. Dans un explorateur de blocs mal isolé, il peut afficher une adresse de destination qui n’est pas celle lue dans la transaction. Rien de cela n’exige de casser une signature. Il suffit que le navigateur fasse confiance à une page qui mélange données et code.

Les équipes crypto ont longtemps privilégié l’audit de contrats. C’est légitime. Une erreur dans un contrat peut vider un pool. Mais l’utilisateur final ne signe presque jamais depuis le bytecode. Il signe depuis une page, une extension, une application mobile hybride. Si cette surface laisse passer un script, la solidité de la primitive cryptographique n’empêche pas le détournement du geste humain. PageBreak, en ciblant le web vivant, rappelle cette évidence trop souvent reléguée derrière les discussions sur les audits de Solidity.

Le XSS stocké, le XSS réfléchi, le XSS fondé sur le DOM n’ont pas le même délai. Un champ enregistré peut frapper plus tard, quand un opérateur ouvre un ticket. Un paramètre d’URL peut frapper tout de suite. Une construction côté client peut échapper aux filtres serveur. Les validateurs de Google ne racontent pas ces taxonomies. Ils tranchent une question plus rude : le script tourne-t-il ? Pour un protocole qui déplace de la valeur, cette question suffit à prioriser.

CodeMender, ou le rêve de jumeler preuve et rustine

Même en filtrant les faux positifs, Google reconnaît que ses équipes produit reçoivent encore un volume élevé. D’où le rapprochement prévu avec CodeMender, un agent chargé de proposer des correctifs. L’intention est simple à formuler et difficile à tenir : présenter à un ingénieur, dans le même dossier, la preuve d’exploitation et une rustine candidate. Le gain n’est pas seulement de vitesse. C’est de réduire le temps où une faille confirmée attend une file de tickets.

Dans l’open source crypto, ce jumelage n’existe presque jamais sous une forme aussi intégrée. Un rapport arrive. Un mainteneur reproduira, ou non. Un correctif suivra, ou attendra la prochaine version. Pendant ce délai, des forks, des ponts et des bibliothèques avalent le code vulnérable. Relier découverte et réparation n’est pas un luxe de grande entreprise. C’est le seul moyen d’empêcher qu’un constat vrai ne pourrisse dans une file publique.

Il faudra toutefois juger CodeMender à l’aune de la même discipline. Une rustine générée peut compiler, passer des tests unitaires et casser un invariant plus subtil. Le validateur d’exploit ne dit rien de la qualité du correctif. Il dit seulement que le problème existait. La revue humaine reste le goulot. PageBreak accélère la preuve. Il n’abolit pas la responsabilité de fusionner un changement.

Ce que les équipes web3 peuvent copier sans copier Google

Personne n’a le dépôt de Google, ni son trafic authentifié, ni ses frameworks maison. On peut pourtant reprendre la séparation des rôles. Un agent cherche. Un outil distinct tente l’exploit. Un humain décide si le dossier sort. Cette séparation coûte moins cher qu’un second audit complet. Elle évite surtout de transformer une messagerie interne en décharge de récits d’attaque.

• Séparer génération et preuve
• Garder les pistes non reproduites dans un silo de recherche
• Mesurer le taux de reproduction, pas seulement le volume de tickets
• Relier chaque page exposée à son code réel
• Réserver l’alerte produit aux cas déjà exécutés

Les projets qui exposent une interface d’administration, un explorateur, un tableau de bord de validateur ou une page de gouvernance sont les premiers concernés. Ces surfaces mélangent données on-chain et rendu HTML. Elles authentifient des opérateurs. Elles affichent des montants. Un XSS y a un rendement immédiat. Scanner uniquement le contrat, c’est inspecter le coffre et laisser la serrure de la boutique ouverte.

Une autre habitude utile consiste à rejouer les scans. Google le fait parce qu’un modèle peut rater une voie puis la trouver plus tard. Dans un dépôt qui bouge chaque semaine, un passage unique fige un état déjà faux le lendemain. La répétition n’est pas un caprice de laboratoire. C’est la seule façon d’accompagner un code qui mute.

Le piège du volume et la politique des primes

Quand les soumissions explosent, un programme de bug bounty se met à ressembler à un centre d’appels. Chaque dossier demande du temps. Chaque dossier plausible vole du temps aux dossiers vrais. Les 900 % d’augmentation cités côté Cosmos illustrent le phénomène sans le résoudre. Si l’on paie à la piste et non à la preuve, on subventionne la prose. Si l’on exige d’emblée une reproduction filmée, on écarte des chercheurs sérieux qui n’ont pas l’environnement interne.

PageBreak contourne ce dilemme parce qu’il est interne. Il possède déjà l’environnement. Un projet public n’a pas ce luxe. Il peut néanmoins publier une grille claire : reproduction minimale attendue, comptes de test, journaux acceptés, délai de premier tri. Sans cette grille, l’IA ne fait qu’accélérer l’arrivée du courrier. Elle n’améliore pas le tri.

Les fondations et les laboratoires qui financent des agents devraient aussi publier leur taux de confirmation. Un chiffre brut de « findings » impressionne une newsletter. Un pourcentage de preuves dit si l’outil travaille ou s’il décore. L’exercice Bitcoin Red Team, en donnant 24,7 %, a au moins le mérite de l’honnêteté. Trop de tableaux de bord s’arrêtent au numérateur.

Ce que l’annonce ne dit pas

Google n’identifie pas les applications touchées. On ne sait pas combien de cas étaient exploitables depuis Internet, combien exigeaient un compte interne, combien tenaient à un endpoint de debug oublié. On ne sait pas non plus comment les 500 se répartissent dans le temps. Un stock ancien découvert d’un coup n’a pas la même lecture qu’un flux mensuel stable.

L’entreprise ne publie pas davantage le coût de calcul, le nombre de tentatives moyennes par candidat, ni la part des pistes abandonnées. Ces absences sont compréhensibles. Elles empêchent pourtant de juger si la méthode est exportable. Un laboratoire plus petit pourrait obtenir dix vrais cas et deux cents récits. Sans ces ratios, copier le discours sans copier l’usine n’apporte rien.

Enfin, rien n’indique que PageBreak soit proposé hors de Google. Les équipes crypto qui attendent un bouton unique devront continuer à assembler leurs propres validateurs. C’est moins spectaculaire. C’est aussi plus sain. Un outil opaque qui déclare « confirmé » sans montrer l’exécution ne vaut pas mieux qu’un modèle bavard.

Une lecture utile pour 2026

L’année 2026 n’est plus celle où l’on s’étonne qu’un modèle lise un dépôt. L’étonnement s’est déplacé. Il porte sur la capacité à dire non à un rapport séduisant. PageBreak, vu sous cet angle, n’est pas une démonstration de puissance brute. C’est une démonstration de discipline. Le chiffre de 500 frappe. La règle qui empêche d’envoyer les 4 000 autres hypothèses aux équipes produit devrait frapper davantage.

Pour un protocole, une société de garde ou un éditeur de portefeuille, la question n’est plus « faut-il un agent ? ». Elle est « qui a le droit de déclarer qu’un agent a raison ? ». Tant que la réponse reste « le modèle lui-même », le flux de travail restera saturé. Quand la réponse devient « un validateur qui exécute », le travail redevient possible.

Les frameworks à haute assurance de Google, avec seulement deux XSS relevées dans un parc immense, rappellent une autre leçon. L’agent trouve surtout là où l’architecture a été relâchée. Avant d’acheter plus de scan, il peut être plus rentable de réduire le nombre de pages où HTML, données utilisateur et privilèges se mélangent sans garde-fou. Moins de surface, moins de théâtre, moins de rustines.

Le prochain avantage compétitif en sécurité web ne sera pas d’avoir plus d’agents. Ce sera d’avoir moins de rapports non reproduits.

Note de lecture pour les équipes web3

Ce qu’il faut retenir sans se payer de mots

Google a officialisé un agent capable de confirmer des XSS sur ses propres applications, avec un volume annoncé supérieur à cinq cents cas. Le dispositif sépare clairement la recherche, la preuve et l’alerte produit. Les modèles Gemini occupent la phase de scan. Des outils non générés par l’agent tranchent l’exécution. Les frameworks internes tiennent mieux que le reste du parc. Le lien prévu avec CodeMender vise à coller une rustine à chaque preuve. Rien de cela n’est livré clé en main au secteur crypto, qui affronte pourtant le même déluge de pistes plausibles.

La suite se jouera moins dans les communiqués que dans les files d’attente. Si les équipes produit voient arriver des dossiers déjà exécutés et des correctifs discutables mais concrets, la méthode aura tenu sa promesse. Si le volume confirmé déborde encore la capacité de revue, on n’aura fait que déplacer le goulot. Pour les projets qui déplacent de la valeur, ce goulot n’est pas un détail d’organisation. C’est le temps pendant lequel une session reste volable.

On peut discuter longtemps des modèles, des versions, des noms commerciaux. La question opérationnelle tient en une phrase. Avant d’ouvrir un ticket, a-t-on vu le script tourner ? PageBreak répond oui plus de cinq cents fois. Le reste de l’industrie ferait bien de poser la même exigence, y compris quand le rapport arrive rédigé dans un français impeccable, ou dans un anglais de laboratoire, et qu’il donne envie d’y croire trop tôt.