An independent researcher has discovered a vulnerability that allows a phone number to be guessed for any Google account. The problem creates serious risks of phishing attacks and SIM-swapping attacks.
The vulnerability was discovered by an information security researcher known under the pseudonym BruteCat. Let us recall that earlier this year he reported another bug , thanks to which it was possible to find out the email address for any YouTube account.
The specialist's new attack is built around the use of an outdated Google form with disabled JavaScript (accounts.google[.]com/signin/usernamerecovery), which lacked modern mechanisms to protect against abuse.
This page was created to help users check if a recovery email address or phone number is associated with a specific display name (e.g. "John Smith").
As BruteCat explains in its report, the new attack allows you to find out the phone number that a person used when setting up recovery for a Google account. In the vast majority of cases, this number matches the victim's primary phone number.
The old, non-JavaScript form allowed you to find out if a specific phone number was associated with a Google account using a couple of queries based on the user's display name.
The researcher easily bypassed the primitive bulk request protection implemented in this form by using IPv6 address rotation to generate trillions of unique IPs across /64 subnets.
We managed to bypass the CAPTCHA that was displayed during requests by substituting a valid BotGuard token taken from a form with JS support into the bgresponse=js_disabled parameter.
As a result, the specialist created a brute-force tool that iterated through ranges of numbers using formats typical for different countries and filtered out false positives.
BruteCat also used Google's libphonenumber solution to generate correct number formats, created a database of phone number masks from different countries to determine number formats by region, and wrote a script to generate BotGuard tokens via headless Chrome.
The resulting solution was capable of searching at a rate of about 40,000 queries per second. This meant that searching for phone numbers in the US took about 20 minutes, in the UK - 4 minutes, in the Netherlands - less than 15 seconds, and in Singapore - less than 5 seconds.
To carry out an attack against a specific person, it was necessary to perform several additional steps. The fact is that just a few years ago, it was not difficult to find out someone else's display name, but since 2023, Google developers began to hide the display name if there was no interaction between the victim and the attacker before that, and in 2024, they almost completely disabled the display of the display name for most services.
BruteCat discovered that to bypass these restrictions, a Looker Studio document could be created and the victim made the owner (using their Gmail address). In this case, the Google account display name would appear in Looker Studio, where the user would become the owner of the document, without any interaction from the victim.
Armed with the information obtained, the attacker was able to perform repeated queries to extract all phone numbers associated with a specific display name.
Since there could be thousands of accounts with the same display name, the researcher narrowed down his search using the target’s partial phone number. To find the victim’s partial phone number, he used Google’s “account recovery” feature (https://g[.]co/AccountRecoveryRequest), which allows you to see the last two digits of the number used for recovery (e.g., ** ******03).
"The [brute force] time can be significantly reduced by using phone number hints taken from password reset procedures in other services (e.g. PayPal) that show a few more digits (e.g. +14*****1779)," BruteCat notes.
A video demonstration of this vulnerability being exploited can be seen here .
BruteCat initially reported the issue to Google via a bug bounty program in April 2025. However, Google developers considered the vulnerability to be of low risk at the time, and it was not until May 22, 2025, that the company upgraded the severity of the issue to “medium” and implemented temporary measures to fix it. BruteCat ultimately received a $5,000 reward for his discovery.
At the end of last week, on June 6, 2025, Google finally closed access to the vulnerable endpoint without JavaScript. That is, it is no longer possible to carry out the attack described by the researcher, but it is unknown whether the problems discovered by BruteCat were used by attackers earlier.