Google Flaw Exposed Phone Numbers: Old Recovery Form Allowed SIM Swap & Phishing Attacks!

A vulnerability in an outdated version of Google’s username recovery form allowed malicious actors to deduce a full phone number linked to an account by knowing only the display name and a partial number. This loophole significantly heightened the risk of targeted attacks, ranging from phishing to SIM-swapping.

The flaw was uncovered by a researcher operating under the pseudonym BruteCat, previously known for exposing hidden email addresses of YouTube account holders. This time, he discovered a method to bypass the limitations of Google’s username recovery form designed for browsers lacking JavaScript support. Unlike the current version, the legacy form lacked modern safeguards against automated actions and remained accessible to queries.

BruteCat observed that the form would reveal whether a given phone number was associated with a specific Google account when supplied with the correct profile name and part of the number. By submitting a series of POST requests with varying combinations, he successfully circumvented the basic attempt-limiting mechanism. To do so, he utilized scalable IPv6 address rotation — leveraging /64 subnets to generate an effectively limitless pool of unique IP addresses, thereby evading rate-limiting triggers.

Additionally, the researcher devised a method to bypass CAPTCHA protection by assigning a valid BotGuard token to the bgresponse=js_disabled parameter — a token extracted from the JavaScript-enabled version of the same form. He automated this process using a headless Chrome browser and a custom script to generate the required tokens.

These techniques were consolidated into a tool called gpb, which iterated through phone numbers based on country-specific patterns, using Google’s libphonenumber library and a precompiled database of formatting masks. Operating at a speed of 40,000 requests per second, the tool could deduce a complete U.S. phone number in approximately 20 minutes, a UK number in 4 minutes, and a Dutch number in under 15 seconds.

To initiate an attack, an attacker would first need the victim’s email address — a hurdle BruteCat also overcame. By creating a document in Looker Studio and transferring ownership to the target’s account, he was able to retrieve the username associated with the recipient’s email address without requiring any interaction from the victim.

Final confirmation of the phone number was achieved through auxiliary services. For instance, attempting a password reset on PayPal would reveal more digits of the phone number than Google, allowing for rapid narrowing of possibilities. In this way, BruteCat compiled complete phone numbers tied to accounts — which, according to him, were in the vast majority of cases the users’ primary numbers.

Such information empowered threat actors to launch precision-targeted attacks — from social engineering schemes to SIM hijacking via telecom providers. The danger of this method was especially pronounced when combined with previously leaked email addresses and other compromised personal data.

The vulnerability was reported to Google on April 14, 2025. Initially assessed as low risk, the threat level was later revised to medium on May 22, prompting the introduction of interim protective measures. For his findings, BruteCat was awarded a $5,000 bug bounty.

On June 6, Google permanently disabled the vulnerable recovery form, rendering further exploitation impossible. However, it remains unclear whether this technique had been employed by others before the flaw’s closure.