Is CVE-2024-39891 (Twilio Authy Information Disclosure) being exploited in the wild?

Yes. CISA added CVE-2024-39891 to its Known Exploited Vulnerabilities catalogue on 23 July 2024, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Twilio Authy contains an information disclosure vulnerability in its API that allows an unauthenticated endpoint to accept a request containing a phone number and respond with information about whether the phone number was registered with Authy.

How to read “exploited in the wild” for this CVE

For a CVE like CVE-2024-39891, “exploited in the wild” means there is credible evidence that attackers have used the flaw outside a lab or proof-of-concept setting. In practice, CISA’s KEV inclusion is the clearest operational signal to treat the issue as active, not hypothetical, and to prioritise it ahead of ordinary backlog work.

That matters here because the flaw is an information disclosure issue in an API, not a crash or obvious takeover path. Disclosure bugs often look modest until they are used for enumeration, targeting, account correlation, or follow-on abuse. The right question is therefore not just whether the bug exists, but whether exposure can be confirmed and whether the disclosed data creates a useful attack path.

When you need the authoritative vulnerability record and current public status, use the CVE Program entry alongside the CISA Known Exploited Vulnerabilities Catalog. Those sources tell you whether the identifier is formally tracked and whether it has crossed into confirmed exploitation territory.

What the disclosed Authy API data can enable

The disclosed response tells an unauthenticated caller whether a phone number is registered with Authy. That is not the same as full account access, but it is still security-relevant because it can support validation, targeting, and user discovery at scale. Attackers value small bits of identity-linked data when they help confirm which numbers or accounts are worth pursuing next.

This kind of disclosure is especially useful when combined with phishing, smishing, SIM-swap preparation, or account-recovery abuse. Even a binary yes or no response can reduce attacker uncertainty and improve the efficiency of follow-on social engineering or credential attacks. The control objective is to prevent the API from revealing state that an unauthenticated requester should never learn.

If you need broader context on how attackers turn exposed data into compromise paths, NHIMG’s State of NHI & AI Agent Breach Report 2026 shows how exposed tokens, keys, and account material often become the first step in a larger intrusion chain. For this CVE, the same logic applies at a smaller scale: a disclosure bug can still create real operational risk when it reveals which accounts exist and which targets are worth pursuing.

What to do if you cannot patch immediately

When a KEV-listed issue cannot be removed at once, the priority is to reduce exposure to the vulnerable endpoint and watch for signs of enumeration or abuse. That usually means restricting where the API can be reached from, reviewing any upstream gateway or WAF rules, and checking whether the disclosed field can be suppressed or mediated without breaking legitimate workflows.

At the same time, confirm whether the exposed data has already been harvested. Look for unusual request volume, repeated lookups against phone-number patterns, and correlated attempts against newly identified users. For public-facing disclosure flaws, compromise assessment often matters more than the patch itself because attackers may already have used the information to prepare later activity.

For operational triage, NHIMG’s Zero-Day and Exploited Vulnerabilities Guide is the closest internal playbook for KEV-driven response, prioritisation, and post-patch hunting. It fits this case because the problem is not just remediation timing, but how quickly you can determine exposure, reduce blast radius, and validate that the vulnerable behaviour is no longer reachable.

Risk and Threat Considerations

Information disclosure bugs are often underestimated because they do not look like direct compromise. The risk is that even limited account-state leakage can materially improve an attacker’s targeting, correlation, and phishing success, especially when the data is tied to phone numbers or recovery workflows.

Failure mechanism: An unauthenticated endpoint reveals whether a phone number is enrolled, allowing large-scale enumeration and target selection before any visible account abuse occurs.

Impact: Attackers can use the disclosed information to support phishing, smishing, recovery abuse, or broader profiling of users and organisations, increasing the chance of successful follow-on compromise.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-17 — Incident Response Management	KEV-listed exploitation requires rapid validation and response coordination.
Recommendation — Triage the exposure as an active incident and coordinate containment, investigation, and recovery.
NIST CSF 2.0	DE.CM-01 — Network Monitoring	Monitoring request patterns helps detect enumeration and abuse of the exposed endpoint.
	RS.MA-1 — Incident Mitigation	Confirmed exploitation calls for rapid containment of the vulnerable service path.
Recommendation — Monitor API traffic for repeated lookups and anomalous enumeration patterns. Contain the vulnerable endpoint and reduce exposure while remediation is pending.
NIST SP 800-53 Rev 5	SI-4 — System Monitoring	System monitoring supports detection of exploitation or enumeration against the API.
	AC-4 — Information Flow Enforcement	Restricting access paths limits who can reach the disclosure-prone API.
Recommendation — Instrument the service to detect suspicious lookup patterns and abuse. Enforce flow restrictions around the exposed endpoint until it is fixed.

Practitioner Guidance

What to verify: Confirm whether any internet-facing path can still query the vulnerable Authy API behaviour, and validate whether the response is actually returning registration status without an authentication gate. If the answer is yes, treat the exposure as active even if you have not yet seen abuse.

Decision rule: If patching is delayed, prioritize containment and monitoring over broad remediation theatre. The highest-value checks are request telemetry, repeated number enumeration, and whether any downstream workflows rely on the leaked state in a way that could magnify impact.

Practitioner takeaway: For KEV-listed disclosure issues, the operational question is not whether the flaw seems modest, but whether it can still be queried and whether the leaked signal helps attackers choose better targets.