Google Account Vulnerability Exposed Users’ Phone Numbers Through Legacy Recovery System
Google Patches Vulnerability That Could Expose Private Phone Numbers in Minutes – Google Updates Account Recovery System Following Responsible Security Disclosure
A researcher found that a legacy no-JavaScript recovery page could leak any Google user's private number. Google has fixed it - here is what happened and how to protect your accounts.
A legacy Google account-recovery form, missing modern anti-abuse protections, let attackers brute-force the private phone number behind any Google account.
The flaw is a textbook example of how a forgotten corner of a huge platform becomes a real threat. The recovery page still worked with JavaScript turned off - a version built years ago for limited browsers - and that older path never got the protections the modern forms did. Google has since removed it, but the incident is worth understanding because the risk it created, and the fix it points to, apply to every business.
What Happened
A chain of small weaknesses that added up to a real one.
By combining a leaked display name, masked phone-number hints, and IPv6 rotation to bypass rate limits, the researcher tested about 40,000 phone numbers per second.
The researcher, known as BruteCat, chained three steps. First, obtain the target's Google display name - which could be leaked through Looker Studio by transferring document ownership to the victim, with no interaction needed. Second, use the normal forgot-password flow, which showed a masked hint of the phone number's last digits. Third, run a custom tool that brute-forces the full number against the known display name. Google's rate limits were bypassed by rotating IPv6 addresses per request and supplying valid BotGuard tokens - reaching roughly 40,000 attempts per second on hardware costing about $0.30 an hour. How fast a number fell depended mostly on the country.
The attack needed no prerequisites and left the victim no way to notice. BruteCat - the same researcher who earlier exposed private emails behind YouTube accounts - reported it to Google on April 14, 2025. Google first rated the risk low, then upgraded it to medium severity, applied interim mitigations, and paid a $5,000 bounty. By June 6, 2025, it had fully deprecated the vulnerable no-JavaScript form worldwide, with no confirmed malicious exploitation reported.
Why It Was Dangerous
A phone number is not just contact info - it is often a key.
A leaked phone number fuels convincing voice-phishing and, worse, SIM-swap attacks that hijack SMS-based two-factor codes.
Armed with a verified phone number, an attacker can run vishing (voice phishing) calls that sound legitimate because they already have your real details. The bigger threat is SIM swapping: convincing a mobile carrier to move your number to a device the attacker controls. Because so many services still use SMS as a second factor, whoever controls your number can often reset passwords and take over email, banking, and social accounts. The episode also highlights two broader points: forgotten legacy endpoints can quietly reopen risks that were supposedly closed, and IP-based rate limiting is weak against attackers who can rotate through large blocks of IPv6 addresses.
A Checklist to Protect Your Accounts
You cannot fix Google's code, but you can remove your phone number as a single point of failure.
The fix that outlasts this one bug: stop trusting SMS for security, and lock down the number you already have.
- Move off SMS two-factor authentication. Use an authenticator app or, better, a hardware security key or passkeys - so a stolen number cannot open your accounts.
- Set a carrier port-out / SIM PIN. Ask your mobile carrier to add a port-out PIN or lock so no one can transfer your number without it.
- Limit where you share your number. Treat your primary mobile number as sensitive; use a separate number for public listings and low-trust signups.
- Watch for vishing. Be skeptical of urgent calls, even ones that cite real details - verify through a known channel before acting.
- Use unique passwords and a password manager. So a SIM-swap that resets one account does not cascade into others.
- Audit legacy and forgotten access. Review old accounts, endpoints, and recovery options - the same "forgotten form" risk applies to your own systems.
- Monitor for exposure. Use breach and dark-web monitoring so you know if your data is circulating and can react quickly.
Still Relying on SMS for Security?
CinchOps rolls out phishing-resistant MFA, carrier and identity protections, and dark-web monitoring - so a leaked phone number does not become an account takeover.
Talk to CinchOpsTake Phone Numbers Out of Your Security Chain
CinchOps deploys phishing-resistant MFA, identity and access management, and 24/7 monitoring so a leaked number or SIM swap does not open the door - as part of everyday cybersecurity and managed IT.
Explore CinchOps cybersecurity →How CinchOps Helps Secure Your Business
CinchOps is a Katy, Texas managed IT services provider serving businesses across the Houston metro, hardening the identity layer that attacks like this one target.
- Phishing-resistant MFA. Enterprise MFA that does not rely on SMS or phone-based codes, so a compromised number does not compromise access.
- Identity and access management. Controls that stop attackers from moving laterally even if one account is taken.
- Security awareness training. Teaching staff to recognize the vishing that follows a phone-number leak.
- Threat monitoring and dark-web monitoring. Watching for unusual access and for your data appearing where it should not.
- Risk assessment and incident response. Finding exposed paths before attackers do, with tested plans for when accounts are compromised.
Do not let a single leaked number unravel your accounts. Contact CinchOps to build identity security that does not depend on your phone.
The scary part was not the clever brute-forcing - it was that your phone number, which opens half your accounts through SMS codes, could be pulled from a page everyone forgot existed. The lesson for every business is simple: stop letting a phone number be a password.
Frequently Asked Questions
What was the Google account vulnerability?
It was a flaw in a legacy, JavaScript-disabled version of Google's username recovery form that lacked modern anti-abuse protections. By chaining a leaked display name with masked phone hints and rotating IPv6 addresses to dodge rate limits, a researcher could brute-force the private phone number tied to any Google account.
Is the Google phone number bug still exploitable?
No. Google fully deprecated the vulnerable no-JavaScript recovery form worldwide by June 6, 2025, which removed the attack vector. Google reported no confirmed malicious exploitation of the flaw in the wild.
Why is a leaked phone number dangerous?
A phone number enables convincing voice-phishing (vishing) and, more seriously, SIM-swap attacks. If an attacker takes over your number, they can intercept SMS two-factor codes and reset passwords for email, banking, and other accounts that rely on text-message verification.
How can I protect myself from SIM-swap attacks?
Move off SMS-based two-factor authentication to an authenticator app, hardware security key, or passkeys. Add a port-out or SIM PIN with your mobile carrier, limit where you share your primary number, use unique passwords with a password manager, and stay alert to vishing calls.
What is the broader lesson for businesses?
Forgotten legacy endpoints can quietly reintroduce risk, so security reviews should cover every accessible interface - even old ones. And because IP-based rate limiting can be bypassed with IPv6 rotation, anti-abuse controls must be applied consistently. Most practically: reduce reliance on phone numbers as an authentication factor.
Discover More
Sources
