CVE-2022-24112 is an authentication bypass vulnerability in Apache APISIX. CISA added it to the Known Exploited Vulnerabilities catalogue on 25 August 2022, which means attackers have used it in real attacks. Apache APISIX contains an authentication bypass vulnerability that allows for remote code execution.
What this vulnerability means for Apache APISIX
CVE-2022-24112 is an authentication bypass in Apache APISIX, and the practical significance is that an attacker can reach functionality that should have been behind a trust boundary. In an API gateway, that is especially dangerous because the gateway is often the first enforcement point for upstream services, so a bypass can become a direct path into internal APIs and control paths.
Authentication bypass flaws are not just “login bugs”. They can let an attacker impersonate a trusted caller, skip policy checks, and interact with protected routes or administrative functions. In gateway software, that can turn a single exposed component into a high-value pivot point for the wider environment.
For authoritative version and patch details, readers should rely on the CVE Program record and the vendor advisory rather than reproducing unofficial version ranges here.
Why authentication bypass is dangerous in an API gateway
API gateways sit between users, services, and upstream applications, so they concentrate authentication, routing, and access control. If a bypass occurs there, the attacker may not need to break into each backend service individually. Instead, they can exploit the gateway’s trusted position and inherit access that should have been denied at the edge.
That matters because gateway compromise often affects more than one application. A bypass can expose internal endpoints, privileged administrative functions, or service-to-service workflows that were assumed to be reachable only by authenticated clients. In practice, the blast radius is often larger than the vulnerable component itself.
This is why gateway flaws are usually treated as exposure issues, not just software defects. The security question is not only whether the product is vulnerable, but whether the gateway is internet-facing, what routes it protects, and what trust relationships it brokers for upstream systems.
How organisations assess exposure and prioritise remediation
The first step is asset inventory: identify every Apache APISIX deployment, confirm where it sits in the request path, and determine whether it is externally reachable. A gateway that fronts production APIs, admin interfaces, or sensitive service meshes deserves immediate attention because the risk is driven by exposure and privilege concentration, not just the presence of the CVE.
Teams should then check vendor advisories and the NIST National Vulnerability Database for the authoritative record, while also verifying whether the affected instance is internet-facing or reachable from untrusted networks. If patching cannot happen immediately, compensating controls should focus on reducing reachability and tightening access paths around the gateway.
That usually means temporarily constraining exposure, watching for unusual authentication failures or unexpected route access, and reviewing whether the gateway is the only control protecting sensitive backends. In parallel, organisations should search for evidence that the bypass was already used before remediation, because an exploited gateway can leave behind valid sessions, altered routes, or other post-breach traces.
What to review after patching or suspected exploitation
Patching closes the known flaw, but it does not answer whether the environment was already compromised. If exploitation is suspected, review gateway logs, upstream service logs, and any management or admin actions that occurred during the exposure window. The key question is whether the bypass was used to reach routes, issue commands, or obtain access that should not have been available.
If the gateway mediated privileged service authentication, treat related credentials, tokens, and API keys as potentially exposed. In that case, session review and credential rotation may be part of recovery, because an authentication bypass can lead to stolen access rather than just a one-time request.
Post-patch validation should also confirm that the authentication control is still enforcing the intended policy after remediation, especially for routes that depend on layered checks such as upstream authorisation, service tokens, or administrative guards.
Risk and Threat Considerations
An authentication bypass in an API gateway can convert a perimeter control into a trust shortcut for attackers. Because gateways often protect many services at once, successful exploitation can expose internal APIs, administrative interfaces, and downstream secrets or sessions that were assumed to be protected by the gateway.
Failure mechanism: The attacker reaches a code path where authentication is skipped or incorrectly accepted, then uses the gateway’s trusted position to access protected routes or pivot into backend services.
Impact: The result can be unauthorised API access, service abuse, data exposure, and in some cases remote code execution or broader compromise of connected systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | APISIX auth bypass directly maps to API authentication failure. |
| Recommendation — Harden API authentication checks and verify every gateway path enforces them. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Gateway admin and operator access depends on strong authentication controls. |
| IA-9 — Identification and Authentication (Non-Organizational Users) | External clients and service callers must be authenticated before gateway trust is granted. | |
| SC-7 — Boundary Protection | An API gateway is a boundary control whose failure exposes internal services. | |
| Recommendation — Enforce strong authentication for privileged gateway administration and access. Authenticate external callers before permitting access through the gateway. Treat the gateway as a boundary control and constrain exposed paths accordingly. | ||
Practitioner Guidance
Why practitioners should care: Gateway authentication defects should be treated as high-priority exposure events because they can undermine every backend system that relies on the gateway for enforcement. Remediation is usually more urgent than for a single application bug, because the affected trust boundary is shared.
What to watch for: Focus on internet exposure, privileged routes, and evidence of access that does not fit normal caller patterns. After any suspected exploitation, review whether credentials, sessions, or API keys tied to the gateway or its protected services need rotation.
Practitioner takeaway: For API gateways, the real question is not only whether the patch is applied, but whether the trust boundary was already crossed before the fix.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org