Bug bounty IA : Codex trouve une faille XSS en 4 minutes

Moins de quatre minutes. C’est le temps qu’a mis Codex pour exploiter seul une faille XSS dans un laboratoire de piratage, sans aucun indice sur la nature de la vulnérabilité. YesWeHack a confronté trois agents IA, Codex, Claude Code et Gemini CLI, à des failles de sécurité cachées. La plateforme française de bug bounty voulait savoir ce que ces outils valent quand personne ne leur souffle la réponse.

Sur le laboratoire commun, un seul agent est allé au bout sans aide humaine.

Trois agents, deux laboratoires, zéro indice

YesWeHack a donné deux laboratoires « mystère » de PortSwigger à chaque agent, avec un accès à Burp Suite, sans révéler la classe de vulnérabilité. Codex tournait avec GPT-5.6 Sol, en effort de raisonnement élevé et sans aucun indice. Burp Suite capture et dissèque tout le trafic échangé avec un site, ce qui en fait l’outil de base des chasseurs de failles.

Le point commun des trois épreuves était une faille XSS, ou cross-site scripting, une technique qui consiste à injecter du code malveillant côté navigateur. Les laboratoires côté serveur différaient d’un agent à l’autre. Claude Code a eu droit à du request smuggling H2.TE, Codex à un contournement d’authentification par JWT, Gemini CLI à une désérialisation Java. Cette asymétrie interdit un classement strict : seule l’XSS permet une comparaison directe.

Le genre de faille n’a rien d’exotique. Open Bug Bounty, plateforme non lucrative lancée en 2014 et issue de XSSPosed, une archive de failles XSS, annonçait 272 020 vulnérabilités corrigées à la fin de 2019.

Un postMessage mal verrouillé, un détour, puis la victoire

La vulnérabilité reposait sur un gestionnaire de messages postMessage. Codex en a identifié les deux défauts : le gestionnaire accepte les messages de n’importe quelle origine, et son contrôle d’URL exige seulement que http: ou https: apparaisse quelque part dans la valeur. Une URL javascript: franchit donc le filtre si la chaîne requise est glissée dans un commentaire JavaScript.

Sa première tentative était trop ambitieuse : exécuter du JavaScript dans l’origine de la victime et renvoyer les liens de navigation de l’application vers le serveur d’exploit, à la recherche d’une route réservée à l’administrateur. Après une erreur de guillemets et une livraison ratée, il a ramené le test à l’action que le laboratoire attendait. Il a ensuite livré la charge utile à la victime et vérifié que le statut du laboratoire passait à « Solved ». Chronomètre arrêté : moins de quatre minutes, soit à peu près le temps de cuisson d’un œuf à la coque.

Codex a suivi seul la redirection de livraison, là où Claude Code s’est arrêté.

Le second laboratoire est allé encore plus vite. Codex a obtenu un accès administrateur grâce à une faille JWT côté serveur en une minute et quatorze secondes. Les JWT sont ces jetons numériques qui servent de carte d’identité le temps d’une session, et un jeton falsifié suffisait ici à se faire passer pour l’administrateur.

Chacun son maillon, aucun ne fait tout

Claude Code a trouvé des failles côté client comme côté serveur, mais un humain a dû guider ou confirmer les dernières étapes d’exploitation. YesWeHack le juge le plus utile pour la reconnaissance et la découverte de vulnérabilités, alors que Codex a produit les résultats de test actif les plus complets.

Gemini CLI, selon la presse qui a relayé l’étude, a refusé de toucher à la cible. À mon sens, ce réflexe de prudence se comprend du côté des éditeurs de modèles, mais il rend l’outil peu utile à un chasseur qui travaille dans un périmètre dûment autorisé. Les comptes rendus concluent qu’aucun des agents n’a pu prendre en charge l’ensemble du processus de bug bounty de manière autonome. Le titre du guide YesWeHack le dit à sa façon : le chasseur définit toujours ce qui compte comme un succès.

Ce que ça change pour un chasseur de primes

YesWeHack cite aussi le cas de HashKitten, qui montre ce qu’un workflow multi-agents structuré peut produire face à une grosse base de code. La consigne du guide tient en quatre mots : explorer largement, valider rigoureusement.

Une réserve s’impose. Les laboratoires PortSwigger sont conçus pour être résolus, avec une faille unique et un périmètre balisé, alors qu’une application réelle ajoute du bruit, des protections et des règles de périmètre à respecter. Les programmes publics en fixent d’ailleurs les limites : celui d’OpenAI sur Bugcrowd, qui vise Codex lui-même, précise que convaincre un modèle d’abuser d’un accès qu’il possède déjà ne satisfait pas les critères.

L’outillage communautaire s’organise déjà. Un dépôt GitHub propose des « skills » pour Codex, construits à partir des motifs observés dans les cinquante premiers rapports publics HackerOne de chaque catégorie de bug. Celui consacré aux XSS couvre les variantes réfléchies, stockées, DOM et aveugles, ainsi que les contournements de CSP et le vol de jetons.

Sources : emarketerz.fr | news.google.com