Hacking Google Support: Leaking millions of customer records ($14k bounty)

by

Author: Michael Dalton
Published: March 31, 2026 (reported to Google June 1, 2025)
Source: https://michaeldalton.au/posts/hacking-google-support

Summary

Michael Dalton documents a missing-authorization flaw in Google’s Real-time Support platform (the backend behind Google’s support chat/phone widgets) that exposed large volumes of support-case data. Starting from an API key hardcoded in Google’s client-side support-widget JavaScript, the researcher reached the API’s discovery document, enumerated its methods, and found one — changes:list — that returned broad system-state dumps without a proper authorization check. The issue was reported to Google’s VRP, accepted as P1/S1, and fixed; Google awarded $14,337 ($13,337 base + a $1,000 bonus). No CVE is associated with the report. The findings are described as verified: the author states he made four successful API calls to confirm the exposure before disclosure.

Technical Details

The entry point was an API key embedded in Google’s support chat widget JavaScript. Google’s own guidance (which the article cites) treats an API-key leak as not, by itself, a security vulnerability — the key merely provided project context to call the API. The real flaw was authorization. Using the key, the researcher retrieved the Real-time Support discovery document (a machine-readable list of ~93 API methods) and probed them. Most methods correctly enforced permission checks, but /v2/changes:list (accessed via realtimesupport.clients6.google.com, described as “get list of changes for specified time period and pools”) did not validate whether the caller was authorized to see the returned data. Per the writeup, the platform leaned on global middleware that only enforced authorization on requests carrying a resource identifier in the path; because changes:list took its scope from query parameters (a time period and pools) rather than a path resource ID, it fell through that gate and returned data unchecked. The realtimesupport.json discovery document the author published shows the method surface (schema field names such as customer name, phone number, and email — i.e. definitions, not records).

Impact

The changes:list responses reportedly included: support-agent names, @google.com email addresses, and detailed activity/status history; customer names for chat cases; unredacted phone numbers for phone-support customers; and case IDs, pool identifiers, and agent-to-customer linkages. The author estimated a minimum of ~30 million cases were accessible (Google declined to confirm exact figures). Beyond the raw PII exposure, the agent-customer linkages and case metadata would materially enable targeted, convincing phishing against Google support customers. This is a data-exposure / broken-authorization issue rather than code execution, and no product versions apply since it is a server-side Google service.

Mitigation

The issue was reported and remediated through Google’s VRP; there is no user-side patch. Timeline as documented: reported June 1, 2025 (tracked as b/421705403); triaged P1/S1 on June 2; $14,337 awarded June 10, 2025; re-testing on Sept 27, 2025 confirmed it was still live; Google marked it fixed on Nov 12, 2025 (164 days after report); public disclosure March 31, 2026. Google also removed public access to the discovery document. Transferable defensive lessons: enforce authorization at the application layer on every method, not via path-pattern middleware that assumes a resource ID is present — query-scoped “list/changes” endpoints are a classic blind spot; do not rely on the secrecy of client-side API keys for access control; and treat verbose discovery documents as attack-surface enumeration aids that should not be publicly exposed for internal APIs.

References

Leave a Comment