CVE-2024-39891

What it actually does

The flaw is an information disclosure/user-enumeration issue in the Twilio Authy API. An unauthenticated network-accessible endpoint accepted submitted phone numbers and returned whether each number was registered with Authy. This exposed account-registration metadata but did not disclose Authy credentials, authentication tokens, one-time codes, or account contents, and did not directly allow account takeover. The CVSS impact is confidentiality-only and low severity technically, but exploitation was confirmed in the wild and the issue is listed in CISA KEV.

Why it matters to the business

Attackers can build lists of people or phone numbers that use Authy, which can increase the success of targeted phishing, smishing, SIM-swap attempts, credential-theft campaigns, and social-engineering attacks against employees or customers. Although Authy accounts were not directly compromised, the exposed registration status is useful for adversary targeting. Because this vulnerability is in CISA KEV, was exploited in June 2024, and had a CISA remediation due date of 2024-08-13, organizations should treat lingering exposure or outdated affected software as overdue risk even though the CVSS score is moderate.

How an attack unfolds

An attacker starts with a list of phone numbers from public sources, prior breaches, data brokers, or generated number ranges. They then send unauthenticated API requests containing those phone numbers to the vulnerable Authy endpoint. For each submitted number, the service response reveals whether the number is associated with an Authy account. The attacker aggregates positive results into a validated target list of Authy users. That list can then be used for follow-on activity such as smishing, help-desk impersonation, SIM-swap attempts, credential-harvesting pages referencing Authy, or other social-engineering campaigns. The exploitation does not require credentials, user interaction, or prior access, and public reporting confirms exploitation in the wild.

How to fix it

Upgrade affected Authy clients and any inventory records that map to this vulnerability. Authy Android should be updated to version 25.1.0 or later, and Authy iOS should be updated to version 26.1.0 or later. If Debian 11 package tracking flags this CVE through the linux package metadata supplied in the advisory feed, update the Debian 11 linux package to 5.10.216-1 or later. Because the vulnerable behavior was primarily API-side, also ensure vendor-side mitigations are in place by using supported current Authy releases and relying only on maintained versions. Mitigations include blocking or rate-limiting unauthenticated enumeration patterns, preventing bulk phone-number lookups, monitoring for automated high-volume requests, and treating known Authy-user phone-number exposure as sensitive targeting information.

How to confirm the fix worked

Confirm that Authy Android installations are version 25.1.0 or later and Authy iOS installations are version 26.1.0 or later. Where vulnerability scanners report Debian 11 linux package exposure, verify that installed package versions are 5.10.216-1 or later. Test the vulnerable behavior only in an authorized manner: unauthenticated requests should not be able to determine whether arbitrary phone numbers are registered with Authy, and bulk enumeration should be blocked, rate-limited, or return non-differentiating responses. Validate that mobile application management, endpoint inventory, app-store telemetry, and vulnerability-management tools no longer report affected versions.

Typical attack path

1. Collect or purchase large lists of phone numbers to test.
2. Send unauthenticated requests to the vulnerable Authy API endpoint with batches or streams of phone numbers.
3. Parse API responses to identify which phone numbers are registered with Authy.
4. Store and enrich the confirmed Authy-user phone-number list with other open-source or breached data.
5. Use the confirmed list for targeted phishing, smishing, SIM-swap, account-recovery abuse, or other social-engineering attempts.

How to detect it

To determine whether this was already exploited, review API gateway, WAF, CDN, reverse-proxy, and application logs for unauthenticated high-volume requests to Authy phone-number lookup or registration-check functionality, especially around June and July 2024. Look for request patterns involving many distinct phone numbers, sequential or generated number ranges, repeated requests from the same source IPs or autonomous systems, abnormal 200/4xx response ratios, missing authentication context, scripted user agents, and sustained request rates inconsistent with normal mobile-app behavior. If only endpoint or mobile-management telemetry is available, identify devices running Authy Android before 25.1.0 or Authy iOS before 26.1.0 during the exposure window. For follow-on abuse, correlate confirmed or suspected exposed phone numbers with increases in smishing reports, SIM-swap attempts, help-desk MFA reset requests, account-recovery attempts, and suspicious phone-number change events. There are no reliable public file, process, registry, or payload indicators for this vulnerability because the observed abuse was API enumeration rather than malware execution.

What your security team should do

• Prioritize remediation as KEV-overdue because exploitation was confirmed in the wild and the CISA due date was 2024-08-13.
• Identify and update all Authy Android clients below 25.1.0 and Authy iOS clients below 26.1.0.
• If scanners flag Debian 11 linux package exposure for this CVE, update to linux 5.10.216-1 or later and confirm the scanner finding clears.
• Notify fraud, help-desk, identity, and SOC teams that exposed Authy-registration status can be used to make phishing and SIM-swap attempts more convincing.
• Increase monitoring for smishing, phone-based social engineering, suspicious account-recovery attempts, and help-desk requests involving phone-number changes or MFA reset requests.
• Review MFA reset and phone-number change workflows for strong identity proofing and out-of-band verification.
• Search for signs of prior enumeration if API gateway, WAF, CDN, or application logs for Authy-related integrations are available.
• Do not treat this issue as evidence that Authy accounts, tokens, or one-time passcodes were compromised without additional indicators.