NGINX Open Source CVE-2026-42926

Exploitation requires BOTH of the following conditions to be true in the NGINX configuration: (1) proxy_http_version must be explicitly set to 2 in the same location or upstream block handling the target request, AND (2) proxy_set_body directive must be active in that same context, modifying the request body with attacker-influenced data. This is NOT a default configuration - standard NGINX reverse proxies use HTTP/1.1 (proxy_http_version 1.1) by default and do not use proxy_set_body unless explicitly configured for header/body transformation use cases. Exploitation is limited to requests routed through locations with both directives present. NGINX configurations using HTTP/2 proxying without proxy_set_body, or using proxy_set_body without HTTP/2 proxying, are not vulnerable.

CVSS 5.8 with network vector, zero complexity, and no privilege requirement indicates broad exposure. However, exploitation requires two specific configuration conditions: proxy_http_version 2 must be active AND proxy_set_body must be in use simultaneously - this is not a default NGINX configuration. The integrity impact is confined to upstream peer perception (Scope:Changed, Integrity:Low), suggesting header/payload injection rather than arbitrary code execution. Without EPSS data or CISA KEV confirmation, real-world risk depends heavily on deployment prevalence of the specific configuration combination. Organizations using HTTP/2 proxying with body modification are at genuine risk; those using standard reverse proxy configurations without proxy_set_body are unaffected. This is not a false alarm despite moderate CVSS, but also not a widespread critical issue.

An attacker controlling input to a proxy_set_body statement (e.g., via URL parameters, headers, or upstream response data that feeds into body modification logic) crafts a payload containing HTTP/2 frame markers. When NGINX serializes the outbound HTTP/2 stream to an upstream server, the injected frame bytes are included verbatim, causing the upstream peer to interpret attacker-controlled octets as legitimate HTTP/2 frames. This allows header injection, request smuggling against the upstream server, or cache poisoning if the upstream is a caching layer. Exploitation requires network access to NGINX but no authentication or user interaction.