Apache APISIX EUVD-2026-90769

Exploitation requires a very specific configuration: a route using the openid-connect plugin configured for remote introspection, pointed at an authorization server that serves MULTIPLE issuers, running an affected APISIX version (3.12.0 through 3.18.0). The attacker must already possess a valid token that introspects as active for at least one issuer (PR:L / authenticated). The flaw is that APISIX does not re-validate the token's issuer against the issuer the target route is restricted to, so a token good for one issuer is accepted on routes meant for another. Limiting factors: single-issuer auth servers, non-OIDC routes, local JWT validation instead of remote introspection, and versions at or above 3.19.0 are not affected; the required multi-issuer setup (AT:P) meaningfully narrows the exposed population.

This is a genuine authorization/authentication-boundary flaw in Apache APISIX but a moderate, conditional priority rather than a widespread emergency. The vendor-supplied CVSS 4.0 vector (5.1, CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N) tells a consistent story: network-reachable (AV:N) and low attack complexity (AC:L), but gated by a specific attack requirement (AT:P - the auth server must serve multiple issuers) and requiring the attacker to already hold a valid token (PR:L, authenticated). The impact is modeled entirely on the subsequent system (SC:H/SI:L) with no impact to the gateway itself (VC:N/VI:N/VA:N), reflecting that APISIX is a proxy: the real damage is unauthorized access to a protected backend/route the attacker should not reach. There is no EPSS score, no CISA KEV listing, and no public exploit code in the provided data, so there is no evidence of active or automated exploitation - this points to targeted, opportunistic risk against specifically misconfigured multi-issuer deployments rather than mass exploitation. Note a known scoring tension: because CVSS 3.1 treats this as a scope change (vulnerable auth plugin -> impacted backend) with high confidentiality, a 3.1 vector lands notably higher (~7.x) than the vendor's 4.0 score of 5.1, which handles subsequent-system impact more conservatively; the 4.0 framing is the more realistic real-world severity.

In an APISIX deployment where the openid-connect plugin uses remote introspection against an authorization server that serves multiple issuers, an attacker holds a legitimate OIDC token valid for issuer A (e.g., a low-privilege tenant). They replay that token against a route configured to be restricted to issuer B; the token introspects as 'active' and APISIX accepts it, granting access to the issuer-B-protected backend. No public exploit code is identified at time of analysis, and the attacker must already be an authenticated principal of one issuer.