Full Report
The author was browsing through Google one day when they decided to turn off JavaScript. To their surprise, the account recovery page still worked, since it was just a form. The username recovery form allows to check if a recovery email or phone number is associated with a specific display name. The authors initial question is whether or not this can be brute forced. There is a Captcha after a while which prevents the attack. How does this Captcha work? The JS form contains a bot guard token. When making the request from the form, this is set to disabled though. When the botguard token is used on the No-JS form, there is no rate limiting! By doing this, they were able to brute force phone numbers associated with accounts. There are two limitations though: the country code must be known and it requires a known display name. The first one can be determined based upon the phone mask in many cases. For the second one, it's a tad more tricky. In 2023, Google changed their policy to only show display names if you have a direct interaction with the user. By 2024, almost all services were removing this. After some effort, they found that Looker Studio transfer ownership functionality still leaked this! Overall, great find on the bug to steal phone numbers! Privacy is hard to get correct and this is a good example of that. I enjoyed the usage of IPv6 and mixing of flows for the bypass.
Analysis Summary
# Vulnerability: Google Account Recovery Phone Number Enumeration
## CVE Details
- **CVE ID**: Not Assigned (Verified by Google VRP)
- **CVSS Score**: N/A (Google Internal Severity: High Impact / Medium Likelihood)
- **CWE**: CWE-307 (Improper Restriction of Rendered Process Attempts), CWE-201 (Insertion of Sensitive Information into Sent Data)
## Affected Systems
- **Products**: Google Accounts (Authentication/Recovery System), Looker Studio.
- **Versions**: Legacy No-JS (JavaScript-disabled) recovery endpoints.
- **Configurations**: Any Google account where a recovery phone number is linked and the display name is discoverable.
## Vulnerability Description
The flaw exists in the Google "Username Recovery" workflow when JavaScript is disabled. While the standard JavaScript-enabled form enforces rate limiting and CAPTCHAs via a **BotGuard** token (`bgRequest`), the No-JS version of the form (`signin/usernamerecovery/lookup`) accepted a manually injected BotGuard token while maintaining a state of `bgresponse=js_disabled`.
By combining this token bypass with a massive IPv6 rotation (using /64 subnets to provide unique source IPs), an attacker could bypass rate limits entirely. This allowed for high-speed brute-forcing of phone numbers to check if they matched a specific display name.
## Exploitation
- **Status**: PoC available; rewarded via Google Vulnerability Reward Program ($5,000).
- **Complexity**: Medium (Requires display name discovery and IPv6 rotation logic).
- **Attack Vector**: Network.
- **Pre-requisites**:
1. The victim's full display name (leaked via Looker Studio "Transfer Ownership" or similar legacy features).
2. The phone number mask/suffix (available via the standard "Forgot Password" hint).
## Impact
- **Confidentiality**: High. Allows an attacker to de-anonymize a Google user's full mobile phone number.
- **Integrity**: None.
- **Availability**: None.
## Remediation
### Patches
- **Vendor Fix**: Google has fully deprecated and decommissioned the No-JS username recovery endpoint as of June 2024.
- **Service Update**: Looker Studio and other auxiliary services have been updated to prevent the leakage of display names to unauthorized users.
### Workarounds
- Users are encouraged to use **Security Keys (FIDO2)** and review their "About Me" privacy settings to limit display name exposure.
## Detection
- **Indicators of Compromise**: High-volume POST requests to `accounts.google.com/signin/usernamerecovery/lookup` originating from rotating IPv6 addresses.
- **Detection Methods**: Security teams should monitor for "Account Recovery" spikes associated with specific display names or small sets of phone number suffixes.
## References
- **Original Research**: [https://brutecat[.]com/articles/leaking-google-phones]
- **Google VRP**: Information disclosed via Google's Bug Bounty program (2025).