A vulnerability could allow recovery of the phone number associated with a Google account by carrying out a brute force attack.
The security researcher who goes online with the moniker “brutecat” discovered that it is possible to brute force the phone number of any Google abusing an issue in the company’s account recovery feature.
A now-deprecated, JavaScript-disabled version of Google’s username recovery page lacked anti-abuse protections.
A few months ago, the researcher disabled JavaScript in his browser to test which Google services still functioned without it. Interestingly, the username recovery form continued to work.
The username recovery form on Google’s site allowed users to check if a recovery email or phone number was linked to a specific display name. This was done through two HTTP POST requests. The first request submitted the phone number, returning a unique ess value. The second request, using this ess and a display name like “John Smith,” would indicate whether an account existed by redirecting to either a “no account found” or “challenge” page.
“The username recovery form seemed to allow you to check if a recovery email or phone number was associated with a specific display name.” reads the report published by the researcher.
The researcher investigated whether Google’s deprecated, JavaScript-disabled username recovery form could be brute-forced. He reported that initial attempts were blocked by rate limits and CAPTCHAs. The expert considered using proxies and IPv6 address rotation (via a /64 subnet) to bypass restrictions. Although a proof-of-concept (PoC) was built, datacenter IPs always triggered CAPTCHAs. Eventually, the author found that using a BotGuard token from the JS-enabled form on the non-JS form bypassed these checks, allowing for successful brute-forcing of phone number endings linked to specific display names. To filter false positives, they validated hits with randomized last names.
Attackers could bypass CAPTCHA rate limits to rapidly test combinations of a user’s phone number, making it possible to guess the full number in seconds or minutes, depending on its length. This flaw allowed potential abuse of the form to reveal recovery details linked to a Google account display name like “John Smith.”
Once a working proof of concept was built to brute-force Google account recovery data, some challenges remained: identifying a victim’s country code and display name. The country code can be inferred from the masked phone format Google shows during password recovery, using patterns from libphonenumbers. Display names are harder to get, but one was leaked by transferring a Looker Studio doc to the target. With valid display name and phone mask, the brute-force tool can pinpoint the full phone number using optimized validation and BotGuard tokens.
“We basically have the full attack chain, we just have to put it together.” continues the report.
- “Run the
gpbprogram with the display name and masked phone to bruteforce the phone number” - Leak the Google account display name via Looker Studio
- Go through forgot password flow for that email and get the masked phone”
Using a $0.30/hour server (16 vCPUs), the attacker achieved ~40,000 brute-force checks per second. With only the last two digits of a phone number (from Google’s password hint), it takes:
- 20 mins for US numbers
- 4 mins for UK
- 15 secs for Netherlands
- 5 secs for Singapore
Time drops significantly if more digits are revealed by other services like PayPal, which often show more of the number.
Below is the timeline for this issue:
- 2025-04-14 – Report sent to vendor
- 2025-04-15 – Vendor triaged report
- 2025-04-25 –
Nice catch! - 2025-05-15 – Panel awards $1,337 + swag. Rationale: Exploitation likelihood is low. (lol)
Issue qualified as an abuse-related methodology with high impact. - 2025-05-15 – Appeal reward reason: As per the Abuse VRP table, probability/exploitability is decided based on pre-requisites required for this attack and whether the victim can discover exploitation. For this attack, there are no pre-requisites and it cannot be discovered by the victim.
- 2025-05-22 – Panel awards an additional $3,663. Rationale: Thanks for your feedback on our initial reward. We took your points into consideration and discussed at some length. We’re happy to share that we’ve upgraded likelihood to medium and adjusted the reward to a total of $5,000 (plus the swag code we’ve already sent). Thanks for the report, and we look forward to your next one.
- 2025-05-22 – Vendor confirms they have rolled out inflight mitigations while endpoint deprecation rolls out worldwide.
- 2025-05-22 – Coordinates disclosure with vendor for 2025-06-09
- 2025-06-06 – Vendor confirms that the No-JS username recovery form has been fully deprecated
- 2025-06-09 – Report disclosed
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
Pierluigi Paganini
(SecurityAffairs – hacking, brute force)
