Apache APISIX EUVD-2026-90763

Requires running the specifically affected Apache APISIX version 3.17.0 (earlier and later releases are not in scope per the advisory). The leak only occurs 'under a certain response structure,' so it is conditional rather than universal - this is reflected as the CVSS AT:P attack requirement. Exploitation further requires that an actor can read the configured log sink (local log files or a downstream log pipeline) and that logging is enabled in a way that captures the affected header; the attacker must hold at least low-level privileges (PR:L) and local/log access (AV:L). Limiting factors: the narrow single-version exposure, dependence on log-sink readability, and the conditional response trigger all constrain real-world impact.

This is a genuinely low-to-moderate priority information-disclosure issue, not a high-urgency flaw. The vendor CVSS 4.0 score of 5.7 (AV:L/AC:L/AT:P/PR:L/UI:N/VC:H) is internally consistent with the description: a sensitive header value that should be masked gets written in plaintext to the log sink, but only 'under a certain response structure' (reflected as AT:P, an attack requirement) and disclosure requires an actor with access to the log destination (AV:L/PR:L). Confidentiality impact is real (VC:H) because the leaked header could be an authorization token or other secret, but there is no integrity or availability impact (VI:N/VA:N). No EPSS score, no CISA KEV listing, and no public proof-of-concept were provided, so exploitation status is 'no public exploit identified at time of analysis.' There is no conflict between the vector and description - both point to a local, conditional, log-exposure problem rather than remote mass exploitation. Net: patch it in due course, but it does not warrant emergency response unless your log sinks are broadly readable or shipped to lower-trust systems.

An operator or attacker with low-level access to Apache APISIX 3.17.0 and visibility into the configured log sink (local log files, or a downstream logging/SIEM pipeline) observes that, for responses matching a specific structure, a header value that should have been masked is recorded in cleartext. By reading those logs they recover the sensitive header (e.g., an auth token or credential) for reuse. No public exploit code is known at time of analysis.