Is CVE-2022-24112 (Apache APISIX Authentication Bypass) being exploited in the wild?

Yes. CISA added CVE-2022-24112 to its Known Exploited Vulnerabilities catalogue on 25 August 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Apache APISIX contains an authentication bypass vulnerability that allows for remote code execution. Any organisation running the affected product should treat remediation as urgent.

What the KEV listing tells you about exploitation

CISA only adds a CVE to the Known Exploited Vulnerabilities catalogue when it has reliable evidence that attackers are already using it. For this question, that makes the answer operational rather than theoretical: the issue should be treated as an active threat, not a future possibility. The practical question is no longer whether exploitation is possible, but whether your Apache APISIX exposure has been eliminated or contained.

For a page like this, the right follow-up is exposure confirmation. Identify every internet-facing and internally reachable APISIX deployment, then verify which ones are still running the vulnerable build or unpatched equivalent configuration. If APISIX sits behind another gateway or is embedded in a platform team’s stack, ownership and asset inventory matter as much as the patch itself because hidden deployments are a common reason KEV items stay exposed.

Read the vendor advisory for version-specific remediation guidance, and use the CISA Known Exploited Vulnerabilities Catalog as the prioritisation signal. If your vulnerability process already tracks KEV items, this CVE should be treated as a top-tier exception until fixed or formally mitigated.

Why authentication bypass in an API gateway is dangerous

An authentication bypass in an API gateway is especially serious because the gateway often sits in front of multiple services, so one flaw can expose more than one application boundary. When a bypass is paired with remote code execution, the issue can move from unauthorised access to full control of the gateway host or the traffic path it protects. That makes blast radius assessment an essential part of the response.

In practice, the risk is not limited to one endpoint. A compromised gateway may let an attacker inspect requests, reach internal APIs that were never meant to be directly exposed, or pivot into adjacent systems that trust the gateway. Zero-Day and Exploited Vulnerabilities Guide is useful here because it frames the difference between merely vulnerable software and software already under active attack.

If APISIX is carrying authentication or routing decisions for production traffic, assume the security boundary has been weakened until you can prove otherwise. That means checking not only the gateway host, but also the services, tokens, credentials and administrative paths that the gateway could reach if abused.

What to do if patching is delayed

When immediate patching is not possible, the goal is to reduce exposure fast enough to buy time without pretending the risk is gone. Put the instance behind stricter network controls, remove unnecessary public exposure, and restrict administrative access to the smallest possible set of trusted sources. If the gateway cannot be isolated, treat the delay as a temporary exception with a named owner and a short expiry.

Prioritisation should be based on exposure, not convenience. If the affected APISIX deployment fronts customer traffic, internal admin functions, or systems with sensitive data, it moves ahead of less exposed instances. The Vulnerability Management Guide is relevant because it emphasises KEV-driven triage, verification and exception handling rather than relying on severity labels alone.

If you must defer remediation, capture compensating controls and evidence that they are in place, including access restrictions, detection coverage and a date for revisit. Do not leave the issue as an open-ended backlog item; active exploitation means the exposure window is part of the risk.

Risk and Threat Considerations

An exploited API gateway can become both an entry point and a visibility gap. Attackers may use the bypass to reach internal services, harvest credentials or pivot further into the environment, especially where the gateway is trusted by downstream applications.

Failure mechanism: The attacker abuses the authentication bypass to cross a trust boundary, then leverages code execution or privileged request handling to extend access beyond the original entry point.

Impact: The likely consequences include unauthorised access, service compromise, lateral movement, exposure of internal APIs and accelerated follow-on exploitation if the gateway is internet-facing.

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 SP 800-53 Rev 5, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes KEV triage and remediation prioritisation central.
Recommendation — Prioritise and remediate the APISIX flaw through continuous vulnerability management.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The answer depends on finding exposed instances and confirming remediation status.
	SI-2 — Flaw Remediation	An exploited authentication bypass requires urgent flaw remediation or mitigation.
Recommendation — Scan for exposed APISIX deployments and track remediation to closure. Apply remediation or approved mitigation for the affected APISIX instance.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerabilities Are Identified and Recorded	Readers must identify which APISIX assets remain vulnerable and exposed.
Recommendation — Identify and record all vulnerable APISIX assets before deciding the response.
OWASP ASVS	V6 — Authentication	The CVE is an authentication bypass, so auth verification and control are directly implicated.
Recommendation — Reassess APISIX authentication handling and remove any bypass condition.

Practitioner Guidance

What to verify: Confirm every APISIX instance, its deployment owner, and whether it is internet-facing, internally reachable, or embedded in another platform. Then verify patch state, compensating controls and whether any exposed instance has already been abused.

What to prioritise: Fix the highest-exposure gateway first, then work outward to less exposed instances. If patching must wait, prioritise network restriction, administrative access reduction and detection coverage over broad architecture changes.

Practitioner takeaway: Treat KEV status as an operational alarm, not a scoring hint, and assume the exposure matters until the vulnerable gateway is either remediated or convincingly contained.