Apache Software Foundation Apache APISIX: route-level authorization bypass through path normalization mismatch

Interpretation Conflict, resulting in (Incorrect Authorization) vulnerability in Apache APISIX. An unauthenticated client can reach upstream paths protected by a route-level auth plugin when a route without auth exists on the same upstream and the upstream does not collapse encoded dot segments. This issue affects Apache APISIX: from 0.9 through 3.19.0. Users are recommended to upgrade to version 3.20.0, which fixes the issue.

• Apache APISIX from 0.9 through 3.19.0 is affected according to the CNA record.
• The vulnerable deployment pattern requires the same upstream to have a route protected by route-level auth and another route without auth, while the upstream does not collapse encoded dot segments.
• Apache APISIX 3.20.0 is identified as fixing the issue. The supplied evidence does not establish the status of other release branches or parallel branches.

The affected boundary is between APISIX route processing and the upstream's interpretation of the forwarded path. APISIX can associate route-level auth with one route while the request path is interpreted or forwarded in a way that reaches a protected upstream path through another route on the same upstream that has no auth. The condition requires an upstream that does not collapse encoded dot segments. The attacker is an unauthenticated network client, with no prior privileges or user interaction required. The supplied facts classify the weakness as CWE-436 resulting in CWE-863. The record and advisory do not identify the exact encoding, request form, route-matcher implementation, specific plugin name, or upstream software, so those details should not be assumed.

• Reachability: network.
• Authentication: the attacker does not need to authenticate.
• User interaction: none required.
• Complexity: low, but the route/upstream configuration and path-normalization condition must be present.
• Known status: the normalized data does not record a public exploit; active exploitation status is not established.

The record does not provide a weaponized request or exact path encoding.

The technical outcome is an authorization bypass at the gateway boundary: an unauthenticated request can reach an upstream path protected by route-level auth. The protected endpoint's behavior determines whether this enables unauthorized disclosure, state-changing actions, or both; the record does not identify the endpoint or data involved. The flaw alone does not establish code execution, service outage, or compromise of every upstream. Scope is limited to deployments that meet the route and upstream-normalization conditions.

The flaw can break the intended separation between public and authenticated API routes at the gateway. If affected protected paths expose sensitive records or state-changing operations, an attacker could access or alter those functions without valid credentials, subject to the upstream's own controls. The record does not confirm a breach, a specific victim, or that every upstream is affected. Exposure depends on route configuration and upstream path-normalization behavior, not merely on product installation.

1. Upgrade Apache APISIX to version 3.20.0, which the record identifies as fixing the issue.
2. Before upgrading, inventory routes that share upstreams and separately assess route pairs where one route requires auth and another does not. If an upgrade cannot be completed immediately, reduce untrusted access to routes meeting these conditions using controls already available in the deployment; this is precautionary risk reduction, not a vendor-confirmed workaround.
3. After the change, verify the route matrix, auth-plugin configuration, and upstream normalization behavior. Do not treat other release branches as confirmed fixed without direct supporting evidence.

1. Inventory deployed Apache APISIX versions and compare them with the confirmed affected and fixed boundaries.
2. Enumerate routes that share an upstream, identifying which routes use a route-level auth plugin and which do not.
3. Determine whether each upstream collapses encoded dot segments. If this behavior cannot be confirmed, treat the exposure condition as unresolved.
4. Review APISIX and upstream access logs for unauthenticated requests that reached endpoints intended to require auth, especially requests containing encoded dot-segment representations.
5. Correlate gateway and upstream logs to identify differences between the selected route and the path actually forwarded. The absence of matching log evidence does not prove that the deployment is safe.