Researchers at the University of Vienna demonstrated a powerful account‑enumeration technique against WhatsApp that allowed them to check hundreds of millions of phone numbers per hour and map roughly 3.5 billion registered accounts. Meta has since deployed mitigations, the academics deleted their dataset, and there is no evidence the flaw was abused in the wild. The experiment highlights a wider class of scraping and enumeration risks that large, phone‑centric platforms must defend against — and that organisations and individuals should understand.
What the researchers did, in plain language
- They generated large sets of plausible phone‑number permutations covering many countries and submitted automated queries to WhatsApp’s lookup service to learn whether each number was registered.
- The system returned lightweight public metadata (timestamps, public keys and, for some public accounts, profile pictures and “about” text).
- Due to an implementation gap in rate limiting and anti‑scraping controls, the team could issue extremely high request volumes (reported at >100 million numbers per hour during tests), enabling continent‑scale enumeration.
- Reported responsibly, the researchers progressively informed Meta; mitigations rolled out from September through October 2025 and the collected dataset was deleted.
Why this matters — impacts and risks
- Account mapping at scale: enumerating who uses a platform by phone number turns phonebooks into an index for targeted abuse — spam campaigns, targeted phishing, SIM‑swap precursors, and linkages to other leaked datasets.
- Metadata can be valuable: even non‑private fields (public profile pictures, “about” text, timestamps, public keys) combine with other breaches to create richer attacker profiles.
- Privacy choices matter, but defaults and UI complexity hurt: users who set profile visibility to “everyone” expose more, and many users are unaware of that choice or its consequences.
- Systemic risk for phone‑centric identity: many services still rely on phone numbers for discovery and recovery; enumeration weakens the confidentiality and uniqueness assumptions of that identity factor.
High‑level technical root cause
- The vulnerability was not a bug in cryptography or data leakage of private messages; it was an operational weakness in server‑side abuse controls.
- Effective enumeration required only the normal, public lookup API behaviour combined with insufficient rate‑limiting, lack of strong fingerprinting/blocking, and permissive response content for public profiles.
- The research shows how “intended” API behaviour (resolve number → is‑registered / return public metadata) becomes dangerous at extreme scale if throttling, progressive challenge, or behavioural analysis are absent.
Practical mitigations for platforms and implementers
- Harden lookup APIs
- Enforce identity‑weighted rate limits and progressive throttling by origin, account, and inferred actor reputation.
- Apply challenge‑response (CAPTCHA / puzzle) escalations at abnormal request rates and require stronger proofs for bulk queries.
- Reduce fingerprintable metadata per anonymous query
- Limit returned metadata for unauthenticated queries; return minimal yes/no and require authenticated, rate‑limited endpoints for any richer information.
- Monitor and profile mass enumeration patterns
- Use anomaly detection tuned for large, structured enumeration (predictable number sequences, country‑wide sweeps, sequential patterns).
- Make privacy defaults protective
- Default profile visibility to contacts only; make “everyone” a deliberate, clearly explained opt‑in with friction.
- Protect downstream risks
- Harden recovery paths that rely on phone numbers (add second‑factor or out‑of‑band confirmations), and detect mass recon attempts that follow enumeration campaigns.
Practical steps for organisations and users
- Organisations that rely on phone identity should assume numbers can be enumerated and avoid using phone‑only recovery or account linking for high‑value operations.
- Security teams should monitor for correlated external attacks after public enumeration research — phishing spikes, credential stuffing attempts, or SIM‑swap patterns targeting employees.
- Users should audit WhatsApp privacy settings and set profile photo/about visibility to “contacts” where feasible, and enable additional protections on services that use their phone number.
Responsible disclosure and the research tradeoff
This paper demonstrates the value of adversarial testing: the research exposed a weakness before it was weaponised widely, and Meta rolled mitigations. Responsible researchers deleted the dataset once mitigations were in place, which preserved academic value while limiting abuse risk. That pattern — coordinated disclosure, staged mitigation, controlled data retention — is the right balance between understanding systemic weaknesses and protecting users.
Final thought
The WhatsApp enumeration case is a reminder that seemingly small API behaviours can scale into major privacy and security problems when the platform meets automation. Defenders must treat discovery APIs and phone‑based identity as high‑risk attack surfaces: minimize public metadata, enforce progressive throttles and challenges, and assume motivated adversaries will automate at extreme scale.
Leave a Reply