I Found Google’s Blind Spot. They Called It “Not a Vulnerability.” I’m 19.

At 19, everyone tells you to stay in your place. I chose to look into Google's blind spot and discover that their "secrets" weren't really that protected.

A month confronting the engineers of Mountain View. While they thought they had everything under control, I was finding the internal discussions left by mistake by their engineers, mapping the private paths of the servers and the logic of their production. No attack, no forcing. Just the patience to connect the dots they had forgotten around.

They pretended nothing happened, but at night they were running to hide the files and change the locks, hoping I'd let go. I love it when giants pretend they're not sweating cold.

Perfect systems don't exist. Only those who know how to look where others don't see.

This is the full technical record of what I found, how I found it, and what happened next.

1. Reconnaissance & Methodology

On April 14, 2026, a commit titled "Set up MCP servers for GBL development" was pushed to the public Android Open Source Project Gerrit instance at android-review.googlesource.com. The commit was 4035168, change ID Ic6b3f2d8a9d26bb05b98acc05726871fa2f618f7.

While analyzing network traffic on the Gerrit interface, I observed that API endpoints returned extensive JSON metadata about code changes. To dig deeper, I developed a custom JavaScript scraper designed to execute in the browser console and query the /changes/{id}/comments endpoint directly.

The script bypassed Google's anti-XSSI (Cross-Site Script Inclusion) magic string )]}' and extracted data that was otherwise invisible on the frontend UI.

The Extraction Script:

javascript

async function invisibleCommentScraper() {
    const changes = ["4035084", "4035185", "4035168"];
    for (let id of changes) {
        const url = `${window.location.origin}/changes/${id}/comments`;
        try {
            let res = await fetch(url);
            let text = await res.text();
            let data = JSON.parse(text.replace(")]}'", ""));
            // Hunting for secrets, paths, or internal tokens in the cache
            for (let file in data) {
                data[file].forEach(c => {
                    if (c.message.match(/bin|google|token|key|password|loas|blade/i)) {
                        console.log(`[!!!] SECRET FOUND IN CACHE (Change ${id}, File: ${file})`);
                    }
                });
            }
        } catch (e) { /* Error handling */ }
    }
}
invisibleCommentScraper();

async function invisibleCommentScraper() {
    const changes = ["4035084", "4035185", "4035168"];
    for (let id of changes) {
        const url = `${window.location.origin}/changes/${id}/comments`;
        try {
            let res = await fetch(url);
            let text = await res.text();
            let data = JSON.parse(text.replace(")]}'", ""));
            // Hunting for secrets, paths, or internal tokens in the cache
            for (let file in data) {
                data[file].forEach(c => {
                    if (c.message.match(/bin|google|token|key|password|loas|blade/i)) {
                        console.log(`[!!!] SECRET FOUND IN CACHE (Change ${id}, File: ${file})`);
                    }
                });
            }
        } catch (e) { /* Error handling */ }
    }
}
invisibleCommentScraper();

Figure 2: The custom JavaScript scraper bypassing the XSSI protection to extract hidden metadata from the public Gerrit endpoint.

Additionally, the primary leaked file was accessible via a simple curl command with zero authentication:

bash

curl -s "https://android-review.googlesource.com/changes/platform%2Fbootable%2Flibbootloader~4035168/revisions/current/files/gbl%2Fgemini%2Fsettings.json/content" | sed "s/)]}'//" | base64 -d

curl -s "https://android-review.googlesource.com/changes/platform%2Fbootable%2Flibbootloader~4035168/revisions/current/files/gbl%2Fgemini%2Fsettings.json/content" | sed "s/)]}'//" | base64 -d

2. The Leaked Data

The data exposed through these public endpoints provided a complete blueprint of highly restricted internal environments.

A. Production Endpoints and Authentication Flags

The commit added a file named gbl/gemini/settings.json which contained configurations for Google's internal systems:

Production Buganizer MCP server command: /google/bin/releases/corp-mcp-proxy/server.par
Internal Buganizer production environment: --mcp_server=blade:devtools.buganizer.mcpservice-prod
Internal LOAS authentication flag: --use_loas_transact_dat=True
Platform and Devices MCP server path: /google/bin/releases/pnd-swe-agents/mcp/mcp_server_local.par

Buganizer is Google's internal bug tracking system. It contains zero-day vulnerability reports, confidential engineering discussions, and incident response operations. The -prod suffix confirms this was the production environment. LOAS (Low Overhead Authentication System) is Google's internal production identity and access management mechanism.

B. Internal AI Prompts and Architecture (GBL Monorepo)

Multiple markdown files acting as operational instructions for Google's internal Gemini CLI were exposed:

gbl/gemini/root_gemini.md revealed that the Generic Boot Loader (GBL) is a UEFI application encapsulating the Android and Fuchsia OS boot processes.
Internal instructions explicitly mapped monorepo boundaries and listed the tech stack: Rust for core safety-critical logic, C for hardware interactions, Bazel for the build system, and Clang for the compiler.
gbl-engineering-standards/SKILL.md detailed strict bare-metal UEFI constraints, such as mandating #![cfg_attr(not(test), no_std)] for Rust production code and strictly forbidding the use of panic!, unwrap(), or expect() to prevent silent hangs in UEFI.
gbl-building-testing/SKILL.md detailed commands for building EFI applications and running unit tests via Bazel (bazel.sh).

C. The Full Engineering Roster, Internal Workflows & CI/CD Pipelines

The leak did not just expose an isolated file; the metadata contained a massive, unredacted JSON payload revealing internal identities, email addresses, and real-time code-review workflows of the entire libbootloader development team.

By parsing the attention_set, reviewers, and reviewer_updates objects, I extracted the complete roster of at least five Google engineers, exposing their internal _account_ids, @google.com email addresses, and internal avatar URLs. The leak provided a minute-by-minute timeline of their internal operations:

[Engineer 1 — The Owner]: (_account_id: 1893074, [REDACTED]@google.com). Created the commit on 2026-04-14 23:47:23.000000000. Later intervened to block the submission with a Code-Review-2 vote on 2026-04-15 16:31:29.000000000.
[Engineer 2 — The Approver]: (_account_id: 1466604, [REDACTED]@google.com). Granted a Code-Review+2 (Looks good to me, approved) on 2026-04-15 15:20:11.000000000.
[Engineer 3]: (_account_id: 1337669, [REDACTED]@google.com). The payload leaked the internal profile status emoji ("🤔") set by this developer.
[Engineers 4 & 5]: (_account_id: 1078119 and 1710792). Listed actively in the attention_set and CC'd on the project.

Using the custom scraper, I extracted cached internal comments between these specific engineers discussing an undocumented cross-project AI risk:

[Engineer 1] discussed a phenomenon called "context pollution," noting that a project-level GEMINI.md file was propagating into the gemini-cli context of every monorepo containing the GBL project (most notably GKI).
This specific comment leaked the engineer's local workstation directory structure verbatim: /usr/local/google/home/[REDACTED]/android/common-android-mainline/bootable/libbootloader/gbl/GEMINI.md.
[Engineer 3] replied, confirming that this was the intended behavior of gemini-cli, as the system actively discovers context from files in the tree.

Beyond human engineers, the payload mapped Google's internal automated testing infrastructure, revealing exact service accounts and their internal logic triggers:

CrystalBall Performance Presubmit ([REDACTED]@google.com): Granted a Performance+2 vote at 2026-04-15 15:21:08.000000000.
TreeHugger/Workplan Finisher ([REDACTED]@system.gserviceaccount.com): Triggered a Presubmit-Verified+2 ("Presubmit finished: 24 passed") referencing the internal Workplan ID L79300030103386846 at 2026-04-15 15:42:09.000000000.
AyeAye Linting System ([REDACTED]@google.com): Handled automated Lint+1 and Open-Source-Licensing+1 verifications.
Stale Change Watcher ([REDACTED]@system.gserviceaccount.com): Automated bot that eventually voided the presubmit verification.

3. Security Impact & The Policy Contradiction

Information Disclosure is often underestimated. In the hands of a motivated Threat Actor, the paths to internal binaries (corp-mcp-proxy/server.par), the specific LOAS authentication flags, and the explicit workstation paths (/usr/local/google/home/[REDACTED]/...) provide a perfect map for highly targeted spear-phishing campaigns and lateral movement within Google's corporate network.

Google's own published VRP rules contain a section titled "Common precedents / Upgrades and downgrades." Under "Incidents," it explicitly lists:

Incidents Amount: $500 Reasoning: "Security issues that are not technical vulnerabilities. For example, a Googler accidentally sharing a confidential document publicly."

This is an exact description of what happened. I cited this rule in my appeal. Google's final response did not address it.

Furthermore, uncovering the undocumented "context pollution" AI risk aligned perfectly with their Novelty bonus criteria:

Novelty Amount: +$1,000 — +$5,000 Reasoning: "A bonus for truly unique reports that caused our security teams to think differently about a problem."

Both were ignored.

4. Google's Final Response (Verbatim)

On June 22, 2026, a Google representative wrote:

"We've decided that the issue you reported is not severe enough for us to track it as a security bug. When we file a security vulnerability to product teams, we impose monitoring and escalation processes for teams to follow, and the security risk described in this report does not meet the threshold that we require for this type of escalation on behalf of the security team. Regarding VRP, we feel that the submission falls outside of the intended program scope, since we require submissions to demonstrate technical security vulnerabilities with a sufficient severity. For example, Google VRP covers only submissions that 'substantially affect the confidentiality or integrity of user data'. This is the final assessment."

On June 23, 2026, regarding my request for confirmation that no confidentiality obligations apply:

"The decision on what to disclose and when to disclose it is yours."

5. What I Asked For

I did not initially ask for money. My requests were:

Hall of Fame or Honorable Mention — a public acknowledgment that costs Google nothing. Refused.
A reward in line with the "Incidents" policy ($500) — the exact amount their own rules describe for this scenario. Refused.
A Novelty bonus for uncovering a previously unknown cross-project AI risk. Ignored.

6. Disclosure Timeline

DateEventApr 14, 2026Commit 4035168 pushed to public AOSP Gerrit by [REDACTED]@google.comApr 17, 2026I submitted a detailed VRP report with PoCs, screenshots, and impact analysisApr 18, 2026Android Security Team confirmed they filed an internal reportApr 19, 2026I submitted additional findings: AI prompts, workstation path, context pollutionMay 21, 2026Google stated: _"The remediation efforts are moving forward smoothly"_Jun 6, 2026I noticed the change was now returning HTTP 404. Access had been restrictedJun 8, 2026Google closed the report: "Won't Fix (Infeasible)"Jun 9, 2026Ticket reopened and assigned. Priority raised to P3Jun 22, 2026Final decision: "Won't Fix (Infeasible)" — no reward, no Hall of FameJun 23, 2026Google confirmed: "The decision on what to disclose is yours"

7. Why I Am Publishing This

Google used my report to identify and remediate a real exposure. They restricted access to the leaked data. Then they told me it was not a security issue and refused to acknowledge my work in any form.

This is not how a vulnerability reward program should operate. Researchers who invest time and expertise in good-faith coordinated disclosure deserve transparency and fair application of published policies.

I am not seeking anything further from Google. I am making the facts public so the security community can draw its own conclusions.

8. All Evidence

Leaked files:

LEAK1.txt — Initial leak summary
LEAK2.txt — Full Gerrit change metadata
LEAK3.txt — AI prompt file extraction output
LEAK 4.txt — Cached engineer comments

Screenshots:

settings.json content
Gerrit change publicly accessible
Gerrit change returning 404 after report
Context pollution comment by [REDACTED]@google.com
Workstation path exposed
VRP Incidents policy ($500)
VRP Novelty bonus policy
The "fantastic partner" betrayal On May 21, 2026, after weeks of patient waiting, the Android Security Team wrote to me: