Envoy Proxy CVE-2026-47775

Exploitation requires that the target Envoy instance has the OAuth2 HTTP filter explicitly configured - deployments not using this filter are completely unaffected regardless of Envoy version. The attacker must independently obtain two artifacts prior to oracle execution: (1) the victim's encrypted CodeVerifier cookie from an active OAuth2 session, and (2) the corresponding OAuth authorization code, both of which must belong to the same authentication flow. The victim must be actively engaged in an OAuth2 authorization flow at the time of attack (confirmed by UI:R in the CVSS vector). The attacker requires network-level access to submit queries to the Envoy /callback endpoint; if this endpoint is not internet-exposed, exploitation is limited to network-adjacent attackers. High attack complexity (AC:H from CVSS) is confirmed by the multi-step prerequisite of simultaneous cookie and code acquisition before the oracle phase begins. Non-PKCE OAuth2 flows or deployments using external identity proxies rather than Envoy's built-in filter are not affected.

The CVSS 6.8 score with AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N accurately reflects the attack's dual prerequisites - obtaining the encrypted cookie and a stolen authorization code - which together constitute the AC:H classification, and the requirement for an active victim OAuth session (UI:R). Despite the moderate composite score, the practical real-world impact is severe: success yields full account takeover via OAuth token theft. The ~100-second oracle execution window is operationally significant - it is fast enough to be exploitable within a single OAuth session's validity period, making the AC:H complexity real but not prohibitive for a motivated attacker in a network position to observe cookies. No EPSS data was provided in the input, preventing quantitative exploitation probability comparison. No CISA KEV listing exists, so active exploitation is unconfirmed. No POC code is identified in the references, making these distinct signals: the vulnerability is well-documented mechanically but not yet publicly weaponized as of this analysis. Deployments not using Envoy's OAuth2 HTTP filter are entirely unaffected - this is a non-default feature, which substantially reduces the exposed population relative to Envoy's full deployment footprint.

An attacker targeting a user authenticating through an Envoy-fronted application intercepts or steals the victim's encrypted CodeVerifier cookie alongside the OAuth authorization code - for example, via a network-adjacent position or cookie-theft XSS on the initiating application. The attacker then submits approximately 6,200 byte-manipulated ciphertexts to Envoy's /callback endpoint over roughly 100 seconds, using the HTTP 302/401 differential responses as a padding oracle to recover the plaintext PKCE code_verifier. With both the recovered code_verifier and the stolen authorization code, the attacker completes the PKCE exchange against the authorization server and obtains the victim's OAuth access token, achieving full account takeover.