Apache APISIX CVE-2026-82806

Exploitation requires the route to be running the authz-keycloak plugin in a supported configuration - this is the explicit prerequisite named in the advisory ('Under a supported authz-keycloak configuration'). The attacker must be able to send authenticated requests through the affected route (PR:L), and the flaw manifests only when multiple requests share the same route state so that one request's authorization scope bleeds into a later request. LIMITING FACTORS: deployments not using the Keycloak authorization plugin are not affected; affected versions are APISIX 2.3.0 up to (not including) 3.7.0; and the unintended scope inheritance depends on request timing/ordering on a shared route rather than a single self-contained request.

This is a genuine access-control defect but a modest-severity one. The vendor CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N, 5.3) models no impact on the vulnerable gateway itself (VC/VI/VA:N) but low confidentiality and integrity impact on subsequent systems (SC:L/SI:L) - correctly capturing that the flaw is an authorization-scope bleed across requests rather than code execution or data theft on APISIX itself. Authentication is required per the vector (PR:L), and the attack is network-reachable with low complexity. There is no EPSS score, no CISA KEV listing, and no public exploit identified at time of analysis, so this is no public exploit identified at time of analysis - a 'patch promptly, not drop-everything' item. The real-world risk is bounded by a hard configuration gate: it only manifests under a supported authz-keycloak configuration. Severity is MEDIUM and realistic risk is lower still for the majority of APISIX deployments that do not use the Keycloak authz plugin. No conflicting signals of note; the main caveat is that the single reference is an Apache mailing-list thread rather than a structured advisory with CPE data.

On an APISIX route protected by the authz-keycloak plugin, an authenticated client sends a request whose authorization scope is computed and then improperly retained in shared/reused state. A subsequent request on the same route - potentially from a different, lower-privileged principal - inherits the earlier request's broader scope, gaining access it should not have. No public proof-of-concept is known; exploitation is network-based and low-complexity but requires the specific Keycloak authz configuration and authenticated traffic.