Gagner 700 millions de wons en hackant Google avec l’IA

• Cas d’un chercheur en sécurité qui a demandé à une IA de sonder automatiquement sans relâche les API de Google, et a ainsi obtenu 500 000 dollars de bug bounty en 3 mois
• En combinant des clés API récupérées dans plus de 60 000 applications Android avec les spécifications d’API de Google (discovery documents), il a réuni plus de 1 500 API à tester, y compris des API peu connues du public
• Il a relié à une IA basée sur Claude un outil de test d’API afin qu’elle envoie des requêtes comme un humain et trouve automatiquement des vulnérabilités de contrôle d’accès dues à l’absence de vérification des autorisations
• De nombreuses failles graves ont été découvertes : compromission de comptes Google Voice, fuite de vidéos privées YouTube, exposition de clés DRM Widevine, traçage de l’identité des propriétaires d’appareils Nest, etc.
• La plupart ne venaient pas d’attaques sophistiquées, mais d’erreurs de base répétées : absence de contrôle des autorisations, API sans authentification, environnements de test exposant directement des données réelles

---

Point de départ de la recherche

• En octobre 2025, une invitation à bugSWAT Mexico l’a poussé à se reconcentrer sur Google, avec en plus l’attrait de pouvoir jeter un œil à une partie du code source de Google
• Après avoir créé de petits projets avec Claude pendant l’année écoulée, il a jugé qu’il y avait un fort potentiel pour automatiser à grande échelle les tests d’API Google avec l’IA
• Le point d’entrée clé était le discovery document — l’équivalent Google d’une documentation Swagger décrivant de manière lisible par machine tous les endpoints, paramètres et méthodes
  • Certains sont publics, comme l’API YouTube Data, mais il en existe aussi pour des API internes comme l’Internal People API
  • Certains sont directement accessibles, mais la plupart exigent une clé API valide

Collecter des clés API

• Une clé trouvée sur un service est souvent active sur plusieurs autres API du même projet GCP ; plus on collecte de clés, plus la surface d’API accessible s’élargit
• La collecte a été menée avec son ami Michael
  • Téléchargement de 61 200 APK Android contenant toutes les versions de toutes les applications Google, puis décompression et recherche de clés API
  • Utilisation d’une extension fondée sur la Chrome Debugger API pour intercepter le trafic et récupérer les clés en temps réel lors de la visite de plus de 2 800 domaines web Google connus
  • Déchiffrement d’apps Google iOS (IPA) et analyse des binaires Google accessibles en parallèle

• Filtrer uniquement les clés Google

  • Pour rester dans le périmètre du VRP, il a interrogé les informations de projet liées à chaque clé via la Cloud Marketplace API afin d’éliminer les clés non Google
  • Quand on utilise une clé sur une API sans autorisation, l’erreur retournée expose le numéro de projet (ex. : ...in project 244648151629...)
  • En interrogeant ce numéro, le champ company indique le domaine du propriétaire du projet, ce qui permet d’écarter tout ce qui n’appartient pas à google.com (ainsi que nest.com, fitbit.com, wing.com, etc., pour les sociétés acquises)

Trouver des domaines d’API Google actifs

• Les domaines candidats ont été obtenus en combinant ceux enregistrés par l’extension, de la génération brute-force par mots-clés et les journaux de transparence des certificats (certificate transparency)
• Une requête était envoyée à chaque domaine ; si l’en-tête Server valait ESF, GSE ou scaffolding on HTTPServer2, il était considéré comme une API Google active et valide

Récupérer jusqu’aux spécifications cachées

• En juillet 2025, Google a supprimé le chemin /$discovery/rest de la plupart des API, mais certains contournements restaient possibles

• Endpoints cachés via Visibility Label

  • Certains projets activent un visibility label, ce qui permet d’accéder à des endpoints cachés uniquement si l’on fournit le paramètre labels
  • Sans label, la spécification de la Service Management API pèse 253 KB ; avec ?labels=GOOGLE_INTERNAL, elle monte à 329 KB, révélant une grande quantité de documentation cachée
  • Comme un seul label est accepté à la fois, cela impose un volume massif de requêtes pour tester toutes les combinaisons de labels, clés et API
• Il a ainsi réuni les spécifications de plus de 1 500 API, puis les a fusionnées avec des documents accumulés lors de recherches précédentes pour préparer les tests automatiques par IA

Résoudre le problème de l’authentification

• Les clés API réglaient la question des « autorisations », mais de nombreux endpoints exigeaient aussi une authentification séparée pour vérifier l’identité de l’appelant
• Les bearer tokens sont liés à un projet GCP ; les mélanger avec une clé API provoque une erreur de type « projets différents », sans contournement connu

• First Party Authentication (FPA)

  • Beaucoup d’API prennent en charge le mécanisme propriétaire de Google FPA, qui fonctionne avec des clés API
  • Les requêtes web incluent un Cookie de session et une valeur Authorization calculée à partir de celui-ci, puis sont envoyées vers des hôtes *.clients6.google.com
  • Certaines API comme drivefrontend-pa exigent un en-tête FPA v2 plus complet, incluant dans le hachage un identifiant utilisateur tel que l’adresse e-mail
  • Michael a trouvé un sourcemap que Google avait laissé fuiter par erreur pendant un temps, ce qui a permis de récupérer dans la bibliothèque interne gapix le code générant les en-têtes FPA v2

• Structure du token et Gaia ID

  • Le format du token est <timestamp>_<hash>_<clé_identifiant>, et l’entrée SHA1 est email:gaiaId timestamp sessionCookie origin
  • La clé d’identifiant n’accepte que e (e-mail), u (Gaia ID obfusqué) et a (domaine Workspace) ; toute autre lettre est ignorée par le backend
  • Gaia signifie « Google Accounts and ID Administration » et chaque compte possède un Gaia ID non obfusqué séquentiel (ex. : 131337133377) ainsi qu’un long identifiant obfusqué

• Liste blanche d’origines et restrictions des clés

  • Beaucoup d’API ont une liste d’Origin autorisées ; utiliser une origine non autorisée renvoie l’erreur SESSION_COOKIE_INVALID, qui donne à tort l’impression d’un problème de cookie
  • Les clés peuvent avoir quatre types de restriction : Server, Browser, Android, iOS. Pour Browser, il faut un Referer valide ; pour iOS, X-Ios-Bundle-Identifier ; pour Android, X-Android-Package et l’empreinte du certificat
  • Ces valeurs ont été stockées pendant la collecte des clés afin d’intégrer aussi leur brute-force dans le même programme
  • Les origines *.corp.google.com n’avaient pas de restriction ; ces API avaient donc de fortes chances d’être des API internes non destinées à être publiques, et elles contenaient de nombreux bugs — un cas a rapporté 9 000 dollars grâce à une faille de contrôle d’accès

Cartographier le flux des requêtes et créer son propre outil de test

• Il a développé un programme capable de classifier à quelle étape une requête était rejetée (résolution de méthode → validité de la clé → restriction de clé → authentification → contrôle d’origine → label, etc.), afin d’obtenir une table de correspondance des clés fonctionnant sur chaque API
• L’API Explorer de Google ne prend en charge que les API publiques et n’étant pas disponible pour cet usage, il a créé en environ une semaine son propre API Explorer avec prise en charge jusqu’à FPA v2
  • Les spécifications sont analysées côté client pour générer automatiquement des JSON de requête/réponse valides et fournir une interface où tester rapidement des payloads arbitraires
  • L’endpoint montré en démo fuyait des assignedTams (technical account managers) via un bug de contrôle d’accès, ce qui a rapporté 6 000 dollars

Mise en place des tests automatiques par IA

• L’objectif était que l’IA découvre automatiquement des problèmes de contrôle d’accès basiques, qu’un humain pourrait ensuite approfondir en vulnérabilités plus graves
• Le code de parsing JSON du frontend a été relié à l’IA comme outil MCP afin qu’elle teste les API comme le ferait une personne

• Plus rigoureux, plus discret

  • Au début, l’IA faisait quelques tentatives puis s’arrêtait trop tôt ; une Ralph Wiggum loop a donc été ajoutée pour l’obliger à tester au moins une fois chaque endpoint avant de pouvoir terminer
  • Les endpoints ont d’abord été classés en groupes logiques pour être testés par groupe, en partageant les découvertes des groupes précédents avec les suivants
  • L’entrée de probe_api a été simplifiée autour de endpoint, path et body, tandis que l’authentification FPA complexe était gérée par le backend pour que l’IA se concentre uniquement sur la rédaction des payloads
  • Comme les réponses peuvent varier selon la clé utilisée, la même requête était automatiquement envoyée avec toutes les clés, puis les réponses identiques regroupées par hachage
  • Les erreurs ambiguës comme « Method not found » ont été traduites en MISSING_REQUIRED_VISIBILITY_LABEL et autres codes explicites pour éviter de perturber l’IA

• Réduire le bruit et valider

  • Au départ, les vrais bugs étaient noyés dans 90 % de bruit ; deux problèmes principaux sont alors apparus : la difficulté de validation et le taux excessif de faux positifs
  • Un operation ID pointant vers la requête réelle a été ajouté aux rapports, de façon à permettre une reproduction via « Play » dans le frontend et à fournir une preuve infalsifiable
  • Pendant plus d’un mois, le system prompt a été affiné pour clarifier les critères de signalement : seuls l’accès aux données d’un autre utilisateur ou des réponses 2xx là où un 4xx devrait apparaître étaient retenus, tandis que la simple énumération d’existence était exclue des vulnérabilités
  • L’IA s’est ensuite mise à découvrir des bugs en masse avec plus de 50 % de précision, la seule vraie limite devenant la quantité de clés API disponibles

Principales vulnérabilités découvertes

• En moins de 3 mois, des bugs représentant 500 000 dollars ont été trouvés ; voici quelques cas emblématiques déjà corrigés

• Compromission de comptes Google Voice

  • gfibervoice-pa n’avait absolument aucun contrôle d’accès : avec une seule ligne de curl sans authentification, il suffisait de connaître le Gaia ID non obfusqué de la victime pour vider toutes ses PII, y compris son numéro de téléphone et ses adresses de notification
  • La réponse permettait aussi de voir le numéro de téléphone de récupération du compte Google de la victime (uniquement dans certaines conditions, que Google ne détaille pas)
  • Un endpoint permettait aussi d’assigner de force un numéro Voice à n’importe quel compte (même si l’API renvoyait une erreur 500, le numéro était bien ajouté), et un autre endpoint laissant envisager un SIM swap a également été trouvé
  • Classé P0/S0, corrigé en quelques heures, avec une récompense de 20 000 dollars
  • Juste après le correctif, l’exposition de zhandler réservés à l’intranet, comme /btz, a été découverte ; atteindre /flagz permettait d’extraire des clés API du service en cours d’exécution

• Compromission de comptes AdExchange

  • Un endpoint permettant de vider la liste complète des comptes AdExchange a été découvert avec une seule requête
  • Un endpoint de compte bloqué en production fonctionnait sans contrôle d’accès sur l’environnement de staging, lequel pointait en réalité vers des données de production
  • Il était aussi possible de s’ajouter comme ADMIN à n’importe quel compte ; les deux signalements ont rapporté 30 000 dollars au total

• eldar.corp.google.com

  • L’API d’Eldar, un site interne réservé aux Googlers pour gérer des évaluations de confidentialité, était exposée à l’extérieur, permettant à des non-Googlers de consulter des informations sensibles comme des demandes d’accès à des journaux internes
  • Après le blocage, il a encore signalé qu’elle restait accessible via d’autres adresses sandbox, pour un total de 26 674 dollars

• Fuite de vidéos privées YouTube

  • Les noms d’assets créés lors d’un upload vidéo suivent le format Auto generated asset - <video_id> ; une simple recherche suffisait donc à fuiter l’ID de vidéos privées et à les visionner
  • Avec une requête toutes les 30 secondes, il était possible d’obtenir un flux en temps réel de vidéos privées mises en ligne par des partenaires — une menace réelle exploitable pour parier avec une information privilégiée sur des marchés prédictifs, des entreprises mettant parfois en ligne à l’avance des annonces produit en mode privé
  • Récompense de 12 000 dollars (qualité du rapport saluée)

• Exposition des clés DRM Widevine

  • L’API du portail partenaire de Widevine, le plus grand système DRM au monde utilisé notamment par Disney et Netflix, était publiquement accessible
  • Il était possible de vider la liste complète des organisations, de consulter et déchiffrer leurs clés PGP et AES, puis de s’ajouter à une organisation arbitraire pour gérer ses appareils
  • Récompense de 16 004,40 dollars (qualité du rapport saluée)

• plx.corp.google.com

  • La DataHub API sous-jacente à PLX, une plateforme d’analyse interne réservée aux employés, était exposée et permettait de consulter les métadonnées des tables d’informations sur les employés actifs
  • Sur l’API de staging, il était possible de s’ajouter comme admin du dataset via setIamPolicy, puis de vider des données YouTube confidentielles, y compris des tables allant jusqu’à 2,1 PB
  • Les deux vulnérabilités ont été reconnues P0/S0 en moins d’une heure et ont rapporté 12 000 dollars chacune

Vulnérabilités cross-tenant dans Translation Hub

• De multiples problèmes de contrôle d’accès ont été trouvés dans Translation Hub, un produit de gestion de traduction de documents à grande échelle
• ListOperations fonctionnait sans token OAuth et fuyait des noms de comptes de service internes, des noms de buckets GCS et des noms de tables internes
• Avec le simple bearer token de n’importe quel compte Google, il était possible de consulter des données d’autres projets, comme les adresses e-mail de traducteurs ou les noms de fichiers confidentiels de travaux
• En modifiant la configuration de la victime via UpdateProjectConfig pour pointer vers un chemin GCS arbitraire, il devenait possible d’exfiltrer des objets GCS privés en base64 en abusant des permissions d’un compte de service partagé
• Les trois bugs ont rapporté au total 36 500 dollars

YouTube TV CMS

• Dans une API destinée aux comptes YouTube CMS permettant de strike, claim ou monétiser des vidéos arbitraires, les endpoints de campagne ne vérifiaient absolument pas la relation avec l’appelant
• GET /v1/campaigns vidait toutes les campagnes du système sans aucun scoping, et il était aussi possible de les modifier, copier ou supprimer simplement via leur ID
• En prime, des e-mails sensibles de comptes CMS ont fuité, pour une récompense de 24 000 dollars (qualité du rapport saluée)

Vertex AI Search for Commerce

• Le paramètre conversationalSearchCustomizationConfig de ce produit de recherche et recommandation retail permettait, sans contrôle d’accès, de lire et modifier la configuration de projets arbitraires
• En lecture, il exposait les system prompts (model preambles) des clients ainsi que des exemples de classification annotés avec des notes de politique interne
• En écriture, il permettait d’injecter une charge de prompt injection dans le system prompt de l’IA de recherche visible côté client, pour une récompense de 30 000 dollars

GraphQL de la Cloud Console

• Des services internes non exposés publiquement sur Internet restaient indirectement accessibles via une surface proxy, et la Cloud Console (nom de code Pantheon) proxifie des backends gRPC via GraphQL

• Contournement de la vérification de signature

  • Chaque requête vérifie normalement une signature de requête (querySignature), rendant la manipulation difficile, mais il a découvert que les requêtes non authentifiées en staging ne vérifiaient pas cette signature
  • Via l’introspection, il a extrait 3 448 schémas, les a archivés sur GitHub, puis a introduit la notion de « query path » pour intégrer GraphQL à son infrastructure existante de fuzzing par IA

• Journaux de requêtes App Engine

  • GetDashboardAppStats renvoyait les logs App Engine des 24 dernières heures pour n’importe quel projet sans vérification IAM, sans même nécessiter d’authentification
  • Comme les URL de requête peuvent contenir des liens de réinitialisation de mot de passe ou des tokens, cela a valu 18 000 dollars et l’attribution du CVE-2026-8934

• Vertex Assistant

  • En analysant 5 GB de JavaScript frontend, il a identifié une fonctionnalité expérimentale cachée, Vertex Assistant, puis forcé son activation via feature flag dans DevTools
  • Toutes les requêtes associées fonctionnaient sans authentification avec le seul userId ; connaître l’e-mail de la cible suffisait pour consulter et modifier la liste de sessions ainsi que l’historique complet des conversations, ce qui a rapporté 30 000 dollars

• Crédits de facturation Maps Platform

  • ListBillingAccountCredits fonctionnait sans contrôle d’autorisation et renvoyait via wildcard les informations de crédit de nombreux clients
  • Les PII client saisies par des employés Google lors de la validation apparaissaient telles quelles dans le champ justification, pour une récompense de 12 000 dollars

Conclusion et enseignements

• En 3 mois, cette configuration a permis d’obtenir plus de 500 000 dollars de bug bounty, et ce qui a été publié ne représente qu’une partie du total
• La plupart des bugs chez Google ne relèvent pas d’exploits sophistiqués : la clé, c’est surtout la persévérance, les mêmes schémas cassés se répétant partout — contrôles IAM manquants, GraphQL sans authentification, endpoints de debug en production, sandboxes pointant vers des données réelles
• Le rôle de l’IA n’est pas d’être inventive, mais de vérifier inlassablement l’évidence sur une surface trop vaste pour qu’un humain l’épuise jusqu’au bout
• Points clés
  • Le système de reproduction par operation_id a été l’élément décisif pour rendre le workflow productif — sans vérification en un clic, la sortie d’une IA n’est qu’un bruit inutile
  • Une fois les discovery docs, GraphQL SDL et proto récupérés, l’IA peut comprendre quels inputs tester de manière pertinente
  • La surface serveur de Google est très standardisée ; en abstrahant les particularités d’infrastructure côté IA, on peut mieux concentrer l’effort sur les tests d’API proprement dits

[j2sus91]

C’est vraiment un nouveau concept de revenu avec le vibe coding.