Cross-issuer authentication bypass in Apache APISIX

Improper Authentication vulnerability in Apache APISIX. On a route using openid-connect plugin with remote introspection against an authorization server that serves multiple issuers, a token that introspects as active for one issuer may get accepted on a route restricted to another. This issue affects Apache APISIX: from 3.12.0 through 3.18.0. Users are recommended to upgrade to version 3.19.0, which fixes the issue.

• Apache Software Foundation Apache APISIX: affected from 3.12.0 through 3.18.0 under semver.
• The record recommends 3.19.0 as the release that fixes the issue.
• The structured record marks the default status as unaffected outside the listed affected interval, but it does not provide separate analysis for parallel branches or third-party packaged builds.

This is a CWE-287 authentication flaw in the Apache APISIX openid-connect plugin when remote introspection is used. The relevant configuration involves an authorization server that serves multiple issuers and a route restricted to a specific issuer. A token that introspects as active for one issuer may nevertheless be accepted on a route restricted to another issuer. The described behavior indicates that the introspection result is not correctly bound to the route's issuer restriction before the request is accepted. The supplied scoring metadata describes network reachability, low privileges required, low complexity, and no user interaction, while a configuration precondition remains necessary. The record does not identify the exact implementation location, configuration key, or request and response fields involved.

The attack path is reachable over the network through a route protected by the affected plugin. The supplied scoring metadata describes low privileges required, low attack complexity, and no user interaction. The necessary precondition is a remote-introspection deployment using an authorization server with multiple issuers, together with a token that is active for an issuer different from the route's restriction. The supplied record does not identify a public exploit, while the associated SSVC data records exploitation as none; this status does not prove that exploitation is impossible.

Successful abuse can bypass issuer-specific authentication at the route boundary. This may allow a token from one issuer context to access a route intended for another, undermining the access scope expected from the authentication design. Further consequences depend on the route permissions and backend actions available to an accepted request, and may affect tenant isolation or business authorization. The available evidence does not describe arbitrary code execution, compromise of the Apache APISIX host, or service disruption.

The flaw can weaken trust boundaries between issuers or tenants protected by the same authorization server. A token valid in one issuer context may be used to pass the issuer check for a route belonging to another issuer. The operational effect depends on the permissions assigned to the route and the actions allowed by the backend, and may include unauthorized access to protected functions or data. The record does not identify a specific victim, campaign, or breach.

1. Upgrade Apache APISIX to 3.19.0, the release identified by Apache as fixing the issue.
2. Before deployment, inventory routes using the openid-connect plugin, remote introspection, and authorization servers with multiple issuers to establish the full exposure scope.
3. After upgrading, perform a controlled validation that a token active for one issuer is rejected on a route restricted to another issuer.
4. If an upgrade cannot be completed immediately, do not assume that the existing configuration provides a sufficient workaround; the supplied evidence documents no official mitigation. Obtain vendor guidance and avoid relying on the affected route pattern until the fix is deployed.
5. For Apache APISIX builds supplied by another distributor, verify that the packaged build includes the relevant fix rather than relying only on a package label.

1. Inventory Apache APISIX deployments and identify those using the openid-connect plugin with remote introspection.
2. Map the authorization servers, issuers, route restrictions, and permitted issuer for each protected route.
3. In a controlled test environment, verify that a token introspected as active for one issuer is rejected by a route restricted to another issuer.
4. Review authentication and request logs for accepted requests where the token issuer does not match the issuer required by the route. Treat this as precautionary monitoring, not as a confirmed IOC.
5. Compare deployed releases with the affected version interval. The absence of matching log records does not prove that the deployment is safe.