CVE-2026-42926

What it actually does

This vulnerability affects NGINX Open Source deployments that proxy traffic to an upstream peer using HTTP/2 via `proxy_http_version 2` and also rewrite or set the proxied request body with `proxy_set_body`. Under those configuration conditions, insufficient validation can allow attacker-controlled bytes to be forwarded in a way that the upstream HTTP/2 peer interprets as frame headers and frame payload data rather than ordinary request body content. The primary technical consequence is upstream HTTP/2 frame injection, which can lead to request/stream confusion or limited integrity impact against the upstream service. The issue requires a specific configuration and does not, by itself, imply code execution, credential theft, or direct service-wide compromise.

Why it matters to the business

Organizations using NGINX as a reverse proxy in front of HTTP/2-capable upstream services could have backend requests altered or corrupted if the vulnerable configuration is present. This may result in incorrect application behavior, transaction integrity issues, confusing audit trails, or security-control bypasses in services that trust the proxy-to-upstream HTTP/2 stream. The CVSS score is moderate, EPSS is low and stable, no public exploit maturity is reported, and the issue is not listed in CISA KEV, so broad active exploitation is not currently indicated; however, exposed reverse proxies with the exact configuration should still be reviewed because successful exploitation occurs remotely without authentication once the configuration prerequisite is met.

How an attack unfolds

An attacker first identifies an NGINX reverse proxy that accepts network requests and forwards them to an upstream server using HTTP/2. Exploitation depends on the proxy being configured with `proxy_http_version 2` and `proxy_set_body`, which causes NGINX to construct or replace the request body sent upstream. The attacker then sends a crafted request containing byte sequences that survive body construction and are forwarded to the upstream connection. Because of improper input validation in this proxying path, those bytes may be interpreted by the upstream HTTP/2 peer as frame headers and frame payload data. The attacker’s goal is not to compromise NGINX directly, but to influence what the upstream peer believes it received on the HTTP/2 connection, potentially causing stream desynchronization, request confusion, or limited unauthorized modification of upstream request semantics.

How to fix it

Upgrade NGINX Open Source to a vendor-fixed release as soon as an applicable fixed version is available for the deployed branch. No exact fixed versions were provided in the input, so operators should consult the official NGINX security advisory and package repositories for the corrected version applicable to their distribution. As an immediate mitigation, remove the vulnerable configuration combination where possible: avoid using `proxy_http_version 2` together with `proxy_set_body`, proxy to upstreams over HTTP/1.1 if acceptable, or avoid rewriting the request body for HTTP/2 upstream proxying. Restrict access to affected reverse proxy routes, enforce strict request validation at the edge, and consider WAF or application-layer controls for endpoints that accept attacker-controlled body content. Systems on NGINX versions that have reached End of Technical Support should be migrated to supported releases because they may not receive evaluation or fixes.

How to confirm the fix worked

Confirm exposure by reviewing NGINX configuration files and included snippets for both `proxy_http_version 2` and `proxy_set_body` within the same effective proxying context, including inherited directives from `http`, `server`, and `location` blocks. Validate remediation by confirming the deployed NGINX build is a vendor-fixed version or that the risky directive combination has been removed. Run `nginx -T` to inspect the fully rendered configuration and verify no active location proxies HTTP/2 upstream traffic while setting the body. After changes, reload NGINX and test affected routes with representative requests to ensure upstream functionality remains correct. Where packet inspection is available between NGINX and the upstream peer, verify that attacker-controlled request body bytes are not emitted as independent HTTP/2 frame headers or unexpected frames.

Typical attack path

1. Identify an internet-facing or reachable NGINX Open Source reverse proxy.
2. Determine whether the proxy forwards to an upstream peer over HTTP/2, commonly indicated by behavior, protocol negotiation, application stack, or configuration leakage.
3. Find a route where NGINX uses `proxy_set_body` to construct or replace the upstream request body.
4. Send crafted unauthenticated HTTP requests containing byte sequences designed to become HTTP/2 frame headers or frame payload data after proxy body rewriting.
5. Observe upstream behavior for signs of frame injection, such as anomalous responses, stream errors, request confusion, or inconsistent backend application processing.
6. Refine payloads to influence upstream HTTP/2 stream handling or backend request interpretation.

How to detect it

To determine whether exploitation has already occurred, start by identifying exposed locations using the risky configuration combination, then correlate NGINX access logs, NGINX error logs, upstream application logs, and any east-west packet captures between NGINX and upstream peers. NGINX default access logs usually do not include request bodies, so they may only show suspicious timing, routes, methods, status-code shifts, spikes in 4xx/5xx responses, or unusual request sizes. NGINX error logs and upstream logs are more useful for detecting side effects such as HTTP/2 protocol errors, malformed frame handling, stream resets, unexpected connection closures, or backend parsing failures following requests to affected routes. If HTTP/2 telemetry is available from the upstream service, search for frame parsing errors, invalid frame sizes, protocol errors, and resets on streams associated with requests proxied by NGINX. Where full packet capture, reverse-proxy debug logging, WAF body inspection, or application request-body logging exists, look for binary sequences resembling HTTP/2 frame headers or injected frame payload bytes inside client-supplied request bodies sent to routes that use `proxy_set_body`. No named threat actors or ransomware campaigns are reported for this issue in the input, and exploitation maturity is listed as none, so detection should focus on configuration-specific anomaly hunting rather than known campaign indicators.

• proxy_http_version 2
• proxy_set_body
• HTTP/2 protocol error
• PROTOCOL_ERROR
• FRAME_SIZE_ERROR
• RST_STREAM
• GOAWAY
• malformed HTTP/2 frame
• invalid HTTP/2 frame
• unexpected HTTP/2 frame
• upstream prematurely closed connection
• upstream reset stream
• client intended to send too large body
• nginx -T

What your security team should do

• Inventory NGINX Open Source reverse proxies and prioritize those that proxy to upstream services over HTTP/2.
• Search rendered NGINX configurations for the combination of `proxy_http_version 2` and `proxy_set_body`; treat matching locations as potentially exposed.
• Patch to the vendor-corrected NGINX release when available, or remove the vulnerable configuration combination as an immediate mitigation.
• Prioritize externally reachable proxies, authentication gateways, API gateways, and proxies in front of transaction-processing or security-sensitive upstream services.
• Enable or increase logging around affected routes, including request IDs that correlate NGINX access logs, NGINX error logs, and upstream application logs.
• Review upstream service logs for HTTP/2 protocol errors, malformed frames, stream resets, and unexplained request parsing anomalies since publication.
• If body logging or packet capture is legally and operationally acceptable, use it temporarily in a controlled manner for high-risk endpoints to look for suspicious binary frame-like payloads.
• Monitor vendor advisories, Linux distribution security trackers, and NGINX package updates for exact fixed versions because none were provided in the input.