Apache APISIX CVE-2026-94269

Exploitable only when the APISIX route configuration contains a permissive (public) route that overlaps the path space of a protected route, so that a non-canonical/encoded path is authorized against the permissive route but resolves to the protected upstream (the AT:P Attack Requirement). No authentication or user interaction is required (PR:N/UI:N) and the attack is fully remote over HTTP (AV:N). The limiting factor is the non-default overlapping-route configuration: deployments without such overlapping permissive-and-protected routes are not affected. Fixed by upgrading to Apache APISIX 3.19.0.

This is a genuine but conditional authorization-bypass flaw (CWE-647, Use of Non-Canonical URL Paths for Authorization Decisions) in Apache APISIX. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) confirms a network-reachable, unauthenticated vulnerability (PR:N) with low attack complexity but a specific Attack Requirement (AT:P) - namely a routing configuration in which a permissive route overlaps a protected one. Impact is scoped to the subsequent/upstream system (SC:L/SI:L) with no direct impact on the gateway itself (VC:N/VI:N/VA:N), yielding a Medium 6.3 score. There is no EPSS score, no CISA KEV listing, and no public exploit identified at time of analysis, so this is not evidence of active or widespread exploitation. The real priority is moderate: the unauthenticated network vector is attractive, but exploitation is gated by a non-default route-overlap configuration (AT:P) and the impact is limited to reaching a single protected upstream endpoint rather than full compromise. The 'Information Disclosure' tag understates the issue - SI:L indicates the bypass can also reach write/state-changing upstream endpoints, making this broken access control rather than pure disclosure. No key signals conflict with the description; the main caveat is that affected-version detail comes only from the single Apache mailing-list advisory.

An attacker identifies an APISIX deployment where a permissive (public) route and a protected (policy-enforced) route share overlapping path space. They send an unauthenticated HTTP request containing a crafted percent-encoded/non-canonical path that matches the permissive route for authorization purposes but resolves to the protected upstream endpoint, which is then served despite being out of policy scope. No public exploit code is known, and success depends on the specific overlapping-route configuration being present.