Twilio Authy: 33M Phone Numbers from an Unauth API

Threat Intelligence

An unauthenticated Authy API endpoint validated whether a phone number was an Authy user. ShinyHunters built a list of 33 million from that single bit of information.

By Arjun Raghavan, Security & Systems Lead, BIPI · May 19, 2024 · 7 min read

On July 1, 2024, Twilio confirmed that an unauthenticated API endpoint in its Authy 2FA service had been abused to enumerate phone numbers belonging to Authy users. The threat actor cluster known as ShinyHunters published a list of approximately 33 million phone numbers extracted via this method. The leak is conceptually small: a phone number, plus a confirmed bit that the phone is registered with Authy. That tiny piece of context turns out to be very valuable downstream.

Timeline

June 27: ShinyHunters posts the 33 million phone number list on BreachForums with a sample. June 28-30: Independent researchers confirm the data is plausible by spot-checking against known Authy users. July 1: Twilio confirms the data was collected via abuse of an unauthenticated endpoint and pushes app updates (Authy iOS 26.1.0 and Android 25.1.0) that require authentication for the endpoint. July 2: Twilio recommends users update their Authy app and watch for SMS phishing.

Root cause: an unauth endpoint that validated existence

The endpoint at the center of this leak accepted a phone number as input and returned a yes-or-no answer to 'is this phone number registered as an Authy user'. That is sometimes called a user enumeration oracle. The endpoint had been there for a long time, did not require authentication, did not rate limit per-IP effectively, and was discoverable to anyone who reverse-engineered the Authy mobile app.

Why the data matters

A list of confirmed Authy users is a high-precision phishing target list. Why? Because anyone using Authy is, by definition, security-conscious enough to use a software 2FA app. Many of them use it because their employer requires 2FA, which means many of them are professionals at companies with valuable accounts. ShinyHunters and downstream phishing operators can use this list to send pretexted SMS messages that reference Authy specifically, mimic Twilio support, or impersonate services known to use Authy as their MFA provider. The conversion rate on phishing this list will be substantially higher than on a generic phone number dump.

Attacker actions and downstream use

In the weeks after the leak, security researchers tracked spikes in SMS phishing campaigns referencing Authy, Twilio, and a range of crypto exchanges that famously use Authy or Twilio Verify for MFA. Some campaigns attempted to direct recipients to fake Authy login pages that harvested MFA tokens in real time. Others were more generic 'your account is being accessed' lures relying on the phone-number-to-Authy-user mapping as a precision signal. The downstream impact is hard to quantify, but the data set's continued circulation means the leak's tail risk extends well beyond July.

Detection

From Twilio's side, the detective control that should have caught this earlier was per-IP and per-prefix rate limiting on a no-auth endpoint that returns existence answers. The volume to extract 33 million records via this endpoint is large but bounded; with effective rate limits, the enumeration would have taken months or been visible in API logs as an obvious outlier pattern (single IP or small set of IPs hitting the endpoint at high rates against sequential or wordlist-driven phone numbers).

The 2FA-app irony

There is something genuinely ironic about a multi-factor authentication app leaking the list of people who use multi-factor authentication. The irony is not just narrative; it has operational consequences. Authy users moved their phone numbers and identities specifically to add security. They received in return a high-precision targeting list for downstream attackers. Companies that offer security tooling are held to a higher implicit standard because their users have an above-average expectation of security hygiene. Failing that standard publicly damages the trust the product was built to provide.

Lessons

First, attack surface is not just authenticated APIs. The unauthenticated endpoints are often forgotten in security reviews because they are 'just lookups'. Every existence-check endpoint, every public 'is this username taken' API, every email-validation endpoint is a free intelligence source. Build a registry. Rate limit. Require auth where you can. Second, security vendors are targets first. Customers of Twilio, Authy, Okta, Cloudflare, and every other security infrastructure provider should evaluate vendor incident response history alongside product capability. The vendor's security posture is part of the product.

The BIPI take

The Authy leak is a low-complexity, high-impact case study in API attack surface management. There was no zero-day. There was no insider. There was an endpoint that did one tiny thing without auth, and a motivated adversary who turned that tiny thing into 33 million data points. The defensive lesson is to audit every public endpoint your product exposes with the question: what does this confirm or deny about a user, and is it confirming for someone with bad intent?

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.