Google Addresses Vulnerability Exposing Account-Linked Phone Numbers

A recently identified vulnerability within Google’s account recovery system has been rectified, which could have enabled malicious actors to execute a brute-force attack to disclose recovery phone numbers associated with user accounts. By leveraging a user’s public profile name and a readily accessible partial phone number, the flaw exposed significant potential for phishing and SIM-swapping attacks.

The exploitation mechanism relied upon an outdated JavaScript-disabled version of Google’s username recovery form, which lacked contemporary anti-abuse measures.

This vulnerability was discovered by a security researcher known as BruteCat, who earlier revealed another flaw permitting the exposure of private email addresses linked to YouTube accounts.

According to BruteCat, the brute-forcing method extracted recovery phone numbers configured by users for Google accounts, which in most instances corresponded to the account holder’s primary phone number.

Brute-forcing Methodology

BruteCat accessed the deprecated no-JavaScript username recovery form, which functioned as anticipated for its original purpose.

This form permitted querying whether a specific phone number was linked to a Google account by utilizing a user’s display name through two POST requests.

By exploiting the limited rate-limiting measures in place, the researcher executed a technique that involved IPv6 address rotation to generate an extensive array of unique source IPs via /64 subnets for these requests.

Sophisticated CAPTCHA challenges encountered during multiple requests were circumvented by replacing the ‘bgresponse=js_disabled’ parameter with a valid BotGuard token derived from the JavaScript-enabled version of the form.

With the prerequisite techniques established, BruteCat developed a brute-forcing tool named gpb, which systematically iterated through potential phone number ranges using regional-specific formats while also filtering out false positives.

The researcher utilized Google’s ‘libphonenumber’ library to generate legitimate number formats, built a country-specific mask database to identify appropriate phone formats, and devised a script to create BotGuard tokens using headless Chrome.

This brute-forcing methodology, with an operational rate of 40,000 requests per second, suggested that retrieving US numbers would require approximately 20 minutes, UK numbers about 4 minutes, and Dutch numbers less than 15 seconds.

The initiation of an attack necessitated the target’s email address for the recovery form; however, Google had concealed this information since the previous year.

BruteCat discovered that by creating a Looker Studio document and transferring document ownership to the target’s Gmail address, he could reveal the target’s Google display name on his Looker Studio dashboard without necessitating any interaction from the target.

Once equipped with this email address, he was able to conduct recurring queries to uncover all phone numbers related to the profile name.

Due to the possibility of multiple accounts sharing the same profile name, the researcher employed a partial phone number to refine the search.

The partial phone number was obtained through Google’s “account recovery” procedure, which discloses two digits from the set recovery phone number.

BruteCat noted that this time frame could also be substantially abbreviated by utilizing phone number hints from password reset protocols implemented by various services such as PayPal, which can reveal several additional digits.

The exposure of recovery phone numbers linked with Google accounts poses a severe security risk, compelling users to be susceptible to targeted vishing attacks or SIM swap schemes.

A demonstration of the exploitation of this flaw has been provided in the accompanying video.

Resolution and Fixes

BruteCat formally disclosed his findings to Google via the Vulnerability Reward Program (VRP) on April 14, 2025. Initially, Google assessed the exploit as low risk; however, on May 22, 2025, the severity classification was escalated to medium after implementing interim mitigations and issuing a $5,000 reward for the submission.

On June 6, 2025, Google confirmed the complete deprecation of the vulnerable no-JS recovery endpoint.

Although the attack vector is no longer accessible, it remains uncertain whether it was ever exploited for malicious purposes.