What the WhatsApp API Vulnerability Teaches Us About Rate Limiting and Information Disclosure

In November 2025, a research team from the University of Vienna and SBA Research (Gegenhuber et al., 2025) publicly disclosed an API vulnerability in WhatsApp’s contact discovery feature. As a reminder, this module automatically finds your phone contacts who use WhatsApp, making it easier to connect with them.

The vulnerability occurred on the backend, where WhatsApp’s servers process API calls. The researchers found that an authenticated WhatsApp user could send millions of queries to enumerate other accounts without being rate-limited, throttled, blocked, or challenged in any meaningful way. That allowed them to:

• Enumerate 3.5 billion active WhatsApp accounts across 245 countries.
• Scrape associated phone numbers and publicly available metadata, such as profile pictures, “About” text, and mobile phone models (Android or iOS), making it richly detailed for potential targeted exploitation.

As a result of the responsible disclosure and collaboration between the researchers and Meta, WhatsApp’s parent company, the security gap was mitigated.

However, it remains telling evidence of the importance of timely and appropriate API security measures. And considering that the researchers used adversarial testing at scale, it perfectly illustrated why approaching and (pen)testing APIs the same way malicious actors view and abuse them is essential.

The Anatomy of the Vulnerability: When Trust Overwhelms Logic

The root cause of the incident was a server-side contact-discovery API design issue: the absence of abuse control and detection mechanisms, which are implementation weaknesses. The researchers were able to send virtually unlimited queries to WhatsApp’s servers from five authenticated accounts, only from a single IP address.

What really happened?

The research team paired a small number of WhatsApp accounts with the open-source client whatsmeow. The client could interact directly with WhatsApp’s XMPP backend, bypassing the UI throttling that standard users encounter.

Whatsmeow allowed the research team to expose raw XMPP backend API endpoints that the official app normally abstracts. These were undocumented API endpoints that the researchers managed to reverse-engineer.

Once authenticated, they were able to call four API endpoints—IsOnWhatsapp, GetDeviceList, GetUserInfo, and GetPrekeys—which returned:

• A Boolean indicating whether an account existed
• Device lists (main plus companion devices)
• Profile photo URLs
• “About” text and timestamps
• X25519 identity keys, signed prekeys, and one-time prekeys
• Metadata allowing inference of OS, account age, and session behavior

The problem was not the endpoints themselves; they were necessary for WhatsApp to function correctly. It was, instead, that the app placed excessive trust in authenticated clients, losing sight of the possibility that they could display malicious intent and act as attackers.

The indicator?

The missing rate limiting, even at an extreme scale. The researchers were able to:

• Carry out 7,000 account lookups per second per session
• Query 50,000 phone numbers per batch
• Launch 5 concurrent sessions from 1 server

Table adapted from: Gegenhuber et al., “Hey there! You are using WhatsApp: Enumerating Three Billion Accounts for Security and Privacy,” 2025. Retrieved from https://github.com/sbaresearch/whatsapp-census

During the enumeration, they did not encounter any:

• IP bans
• Account bans
• Noticeable request throttling
• Security prompts such as CAPTCHA
• Friction
• Behavioral security boundaries

The end-to-end encryption remained intact; the researchers never had access to the messages. However, as noted earlier, the existing security weaknesses enabled the enumeration of approximately 3.5 billion accounts via API calls—something that should have been impossible if the API had proper abuse controls.

It’s also worth noting that metadata isn’t simply privacy trivia. When you’re able to query device- and key-related endpoints at scale, you can pivot from broad enumeration into target-level profiling.

The security researcher Tal Be’ery showed how WhatsApp device/prekey signals can be used for passive fingerprinting—down to whether a target likely uses companion devices simple backend responses into actionable intelligence.

Mass Enumeration: Probing 63 Billion Phone Numbers

Enumeration vulnerabilities occur when APIs allow malicious actors to:

1. Probe identifiers, such as phone numbers, emails, and usernames
2. Receive a deterministic “exists/doesn’t exist” response
3. Reiterate the process on a large scale

WhatsApp’s contact discovery API, as designed, allowed exactly that. The researchers generated a global phone number candidate set—63 billion numbers, reduced from 646 billion via libphonenumber—and systematically probed them.

The app’s architectural assumption appeared to be that enumeration at a global scale was infeasible due to user trustworthiness and platform safeguards. However, the research disproved this assumption, showing that neither WhatsApp had effective safeguards nor were authenticated users to be trusted by default.

And WhatsApp confirmed the vulnerability in its public statement:

“A novel enumeration technique… surpassed our intended limits, allowing researchers to scrape publicly available information.” (SBA Research, 2025)

But it was not a novel technique that could’ve ended in a breach. It was a standard API enumeration in action. What was novel was the enumeration scale that WhatsApp’s backend allowed.

Source: For more detailed statistical breakdowns and geographic insights, refer to Mobile Hacker’s “WhatsApp by the Numbers”

Bypassing the Interface: Why UI Limits Fail at the API Layer

A subtle and valuable lesson emerges here.

WhatsApp implemented contact upload batching, background-process prioritization, OS-level constraints, and, most importantly, UI-level throttling. However, security controls at the UI layer mean very little when:

• Users can access the API without the user interface.
• APIs lack backend enforcement.
• Attackers can use automation and bypass the frontend or even the official app to induce unexpected behavior.

The obvious corollary is that if the backend implicitly trusts the client, the attacker wins effortlessly.

Mapping the WhatsApp Vulnerability to OWASP API Top 10

The WhatsApp API security vulnerability falls primarily within the API2: Broken Authentication category. In addition, it overlaps partially with API4: Unrestricted Resource Consumption and API1: Broken Object Level Authorization (BOLA).

API2: Broken Authentication

API2 refers to issues where the API fails to properly authenticate or restrict how clients interact with protected functionality.

WhatsApp’s vulnerability stemmed from:

• Trusting authenticated sessions without enforcing sufficient limits on their actions.
• Allowing automated requests from a small number of accounts without rate limiting.

WhatsApp had authenticated users correctly, but the lack of behavioral enforcement made it possible for researchers to abuse legitimate sessions and carry out mass enumeration.

API4: Unrestricted Resource Consumption

API4 focuses on missing rate limiting, quotas, and usage thresholds.

In WhatsApp’s case, the system failed to implement these, allowing the researchers to flood the API with thousands of requests per second, unlimited requests from a single IP, and billions of lookups without being blocked.

However, API2 remains the primary category because the issue was more about unauthorized access and enumeration than resource exhaustion.

API1: Broken Object Level Authorization (BOLA)

WhatsApp allowed authenticated users to query any phone number globally without verifying whether they were authorized to access the associated metadata.

This flaw resembles a BOLA vulnerability, but since it’s primarily about bulk data enumeration rather than unauthorized access to specific objects, the overlap is partial.

Adopt Adversarial Mindset

This WhatsApp API vulnerability exemplifies a seemingly naive negligence that, in reality, can be a highly destructive security weakness—an insufficient or complete lack of rate limiting.

It allows attackers to automate massive discovery attempts, such as phone number enumeration, with ease. And it can only get worse as computational power and network speed continue to increase.

The way we see it, an adversarial approach to API security testing is by far the most effective way to prevent insufficient rate limiting from escalating into a full-blown data breach.

In the researchers’ own words:

“[E]mpirical testing is the most reliable method to assess the feasibility and effectiveness of phone number enumeration in instant messaging applications.” (Gegenhuber et al., 2025, p. 14)

This methodology aligns perfectly with Equixly’s core principles and capabilities.

Equixly’s guiding methodological principle is to approach and (pen)test APIs with an attacker’s mindset, focusing on inconspicuous implementation flaws that give hackers the upper hand in real-life scenarios. For that purpose, it carries out:

• High-volume, adversarial testing: The platform subjects APIs to reverse-engineering, high-volume bursts, and systematic enumeration, simulating continuous adversarial pressure.

  Equixly’s agentic AI models are trained to think and act like human attackers—looking far beyond the user interface, surface-level abstractions, and even standard technical vulnerabilities—and deconstruct elusive logic issues.

• Rate limit stress-testing: Equixly explicitly tests for the absence or ineffectiveness of rate limits across various parameters, including per-IP request counts, session behavior, and endpoint-specific traffic patterns.

• Metadata leak detection: The Agentic AI Hacker identifies soft leakage by analyzing API responses for excessive data exposure, such as profile information or key metadata. It also flags Boolean oracle vulnerabilities, that is, endpoints that return a simple ‘true/false’ on an account’s existence, which attackers can weaponize for mass enumeration.

By integrating continuous, automated penetration testing assisted by proprietary AI agents into the development life cycle, Equixly enables you to move past the flawed assumption that your existing security measures, such as obscurity or basic limits, will hold under adversarial abuse pressure.

The overarching goal is to discover business logic flaws and design-level API weaknesses before malicious actors exploit them in the wild.

Conclusion

The WhatsApp vulnerability represents a case study in why backend API security cannot rely on a presumed good behavior of authenticated users.

By bypassing the UI and interacting directly with raw XMPP endpoints, researchers demonstrated that even the world’s most widely used messaging platform could be systematically enumerated when the backend lacks strong behavioral controls. At its core, this was not a failure of encryption, but a failure of API design and logic.

This security vulnerability highlights a critical intersection of the OWASP API Top 10 risks:

• API2:2023 – Broken Authentication: The researchers acted as legitimate users, but the system failed to constrain what the authenticated sessions could do, allowing a handful of accounts to act as massive data-scraping engines.
• API4:2023 – Unrestricted Resource Consumption: The absence of IP throttling, per-user quotas, and anti-automation mechanisms made it possible for the researchers to flood the WhatsApp API with billions of queries without triggering a single security challenge.
• API1:2023 – Broken Object-Level Authorization (BOLA): By allowing any authenticated user to query metadata for any phone number globally, the API essentially served as a public directory for billions of private records.

The most important takeaway for security teams is that “authenticated” does not mean “benign.”

Traditional UI-level throttling is a superficial barrier that vanishes the moment an attacker interacts directly with the API. To protect modern architectures, organizations must adopt an adversarial mindset, assuming that every endpoint will be probed and tested for flaws in logic and implementation.

Equixly is built precisely for this. It emulates adversarial high-volume pressure to identify subtle rate-limiting gaps and “Boolean oracles” that scanners typically miss. This way, it enables you to defend against the very techniques that compromised WhatsApp’s user information.

In an API-driven world, the only way to bolster security is to find your design weaknesses before an attacker turns your 3-billion-user platform into the world’s largest data map.

Get in touch with our team of experts and learn how Equixly helps you remediate the OWASP API Security Top 10 risks.

FAQs

What is the tangible business risk of mass enumeration if our customer data is already encrypted?

Encryption protects the content of communications, but enumeration targets the identity and metadata of your user base. That leads to a three-fold risk:

• Downstream attacks: A leaked list of active phone numbers or email addresses is a gold mine for high-precision phishing and social engineering campaigns targeting your users, for which your brand will be held responsible.
• Reputation and trust damage: If an attacker can scrape a verified list of your customer base, it proves that your privacy controls are subpar.
• Competitive intelligence: Competitors or state actors can use enumeration to map your market penetration, user growth, and geographic distribution.

Why did WhatsApp’s existing security measures fail to stop the attack?

The problem was that WhatsApp enforced security on the client side (UI), but the attack occurred on the server side (API). WhatsApp had friction mechanisms built into the app, but did not enforce equivalent behavioral quotas on the raw XMPP endpoints.

The researchers used an open-source client to call the backend directly, bypassing the UI entirely. And if your rate limiting doesn’t account for direct API calls made via automation or reverse-engineered clients, your frontend limits are merely surface-level security.

How do we justify the cost of adversarial testing over standard automated vulnerability scanning?

Technically speaking, adversarial testing, such as that provided by Equixly during the SDLC (software development life cycle), uses AI to simulate behavioral abuse and identify architectural and implementation issues that static scans cannot see.

In terms of business ROI, finding a design flaw during development costs significantly less than a post-breach mitigation. In WhatsApp’s case, the cost avoided through the responsible disclosure of researchers was the exposure of 3.5 billion records, specifically the legal and monetary consequences of a mass account enumeration and data-scraping incident.

As a reminder, Meta has already been fined €265 million for a similar incident.

Zoran Gorgiev

Technical Content Specialist

Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing.

Alessio Dalla Piazza

CTO & FOUNDER

Former Founder & CTO of CYS4, he embarked on active digital surveillance work in 2014, collaborating with global and local law enforcement to combat terrorism and organized crime. He designed and utilized advanced eavesdropping technologies, identifying Zero-days in products like Skype, VMware, Safari, Docker, and IBM WebSphere. In June 2016, he transitioned to a research role at an international firm, where he crafted tools for automated offensive security and vulnerability detection. He discovered multiple vulnerabilities that, if exploited, would grant complete control. His expertise served the banking, insurance, and industrial sectors through Red Team operations, Incident Management, and Advanced Training, enhancing client security.