A security researcher has revealed a technique for brute-forcing the full phone numbers linked to Google accounts using a now-deprecated JavaScript-disabled username recovery form.
The proof-of-concept attack exploited lax rate-limiting and token validation mechanisms to systematically identify phone numbers tied to specific display names.
The issue was first investigated by the researcher in early 2025 during an experiment to evaluate which Google services still functioned without JavaScript. Surprisingly, the username recovery flow was still accessible in this mode. This legacy interface, originally designed for users with limited browser capabilities, lacked modern anti-abuse protections like CAPTCHA enforcement and relied instead on BotGuard tokens in JavaScript-enabled environments.
The core of the attack involved a two-step HTTP request process: first, submitting a phone number to receive an ESS session token, and then using that token alongside a guessed display name to determine whether the input matched a valid Google account. By observing redirect behavior, either to a “no accounts found” or a challenge page, the attacker could infer whether a specific combination of phone number and name existed.
Google attempted to mitigate abuse through IP rate-limiting and CAPTCHA challenges. However, the researcher circumvented these protections using IPv6. With access to a /64 IPv6 subnet, the attacker could generate billions of unique IPs, effectively bypassing rate limits. When this was not sufficient due to CAPTCHAs targeting datacenter IPs, they further refined the approach by incorporating valid BotGuard tokens from the JavaScript-based version of the form into their no-JS requests.
The researcher created a custom tool, gpb, written in Rust, which automated this process at scale. By feeding it masked phone number hints (like •• ••••••03) from Google's password recovery flow and leveraging known mobile number patterns for countries using Google's own libphonenumber library, the tool could scan through plausible number combinations at a rate of up to 40,000 checks per second on a modest cloud server.
The most critical enabler of this attack was the ability to obtain the target's display name. While Google had gradually removed unauthenticated access to account names throughout 2023 and 2024, the researcher found a residual leak: by creating a Looker Studio document and transferring its ownership to the target's email, the victim's display name would appear on the attacker's dashboard, without any interaction from the victim.
With this information, the attacker could:
- Identify the display name via Looker Studio.
- Retrieve the phone number hint using Google's password recovery form.
- Use gpb to brute-force the remaining digits and confirm a match based on server responses.
Google was informed of the issue on April 14, 2025, and acknowledged and triaged the report the following day. After some back-and-forth on reward eligibility, Google raised the bounty to $5,000 and, by June 6, confirmed that they had fully deprecated the vulnerable no-JavaScript recovery form globally. Interim mitigations had been deployed earlier on May 22.
Google accounts are used by over 1.5 billion people globally, making the implications of this attack far-reaching, particularly for those who rely on phone numbers as primary account recovery methods. It is recommended to use email-based recovery if possible, enable two-factor authentication, and review your account recovery settings via Google's Security Checkup to remove outdated or unnecessary information.
Leave a Reply