Skip to main content
Mallory
MediumPublic exploit

HTTP/2 request injection in NGINX ngx_http_proxy_module

IdentifiersCVE-2026-42926CWE-444

CVE-2026-42926 is an HTTP/2 request injection vulnerability in NGINX Open Source/NGINX affecting the ngx_http_proxy_module when NGINX is configured to proxy upstream traffic over HTTP/2 using proxy_http_version 2 and also uses the proxy_set_body directive. Under these conditions, an unauthenticated remote attacker can cause NGINX to inject arbitrary HTTP/2 frame headers and payload bytes to the upstream peer. The issue is described by NGINX as affecting HTTP/2 proxying in conjunction with request-body rewriting via proxy_set_body. Fixed releases include nginx 1.30.1 (stable) and 1.31.0 (mainline).

Share:
For your environment

Are you exposed to this one?

Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.

ANALYST BRIEF

Impact, mitigation & remediation

What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.

Impact

What an attacker gets, and what they’ve been doing with it.

Successful exploitation allows an unauthenticated attacker to manipulate the HTTP/2 byte stream sent from NGINX to the upstream server, injecting attacker-controlled frame headers and payload bytes. This can compromise the integrity of proxied upstream requests, potentially enabling request smuggling/request injection against the upstream application or intermediary, altering upstream request semantics, and causing unauthorized actions or bypass of trust assumptions between NGINX and the upstream peer. The provided content does not specify broader impacts such as code execution or memory corruption for this CVE.

Mitigation

If you can’t patch tonight, do this now.

If immediate patching is not possible, avoid the vulnerable configuration combination by not using proxy_set_body together with proxy_http_version 2 for upstream proxying. Where operationally feasible, proxy to upstreams using HTTP/1.1 instead of HTTP/2, or remove/replace the proxy_set_body usage on affected locations. Limit exposure of untrusted client traffic to affected reverse-proxy paths until patched.

Remediation

Patch, then assume compromise.

Upgrade NGINX to a fixed version: 1.30.1 or later on the stable branch, or 1.31.0 or later on the mainline branch. Apply vendor-provided fixes for CVE-2026-42926 in ngx_http_proxy_module. Software versions that have reached End of Technical Support are noted as not evaluated.
PUBLIC EXPLOITS

Exploits

1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.

VALID 1 / 1 TOTALView more in app
CVE2026-42926MaturityPoCVerified exploit

This repository is a self-contained lab and validation harness for CVE-2026-42926, described as an NGINX HTTP/2 frame injection issue caused by a vulnerable proxy configuration rather than remote code execution. The main exploit logic is in cve_2026_42926_lab.php, which classifies the NGINX version, verifies that the supplied configuration contains the required vulnerable pattern, constructs a crafted HTTP/2 DATA-frame-like header plus a unique marker, sends the payload to a target URL such as /exploit, and then inspects upstream JSON logs to decide whether injected frame evidence was observed. The exploit capability is therefore protocol-level injection validation against a reverse proxy path, not post-exploitation. Repository structure: the PHP script is the primary validator/exploit driver; nginx_config_verify.sh checks whether the target config uses proxy_http_version 2, proxy_set_body with a variable, and sufficient client_max_body_size; upstream_frame_logger.py is a raw TCP/HTTP2-aware listener that parses frame headers, records payloads, flags suspicious injected frames, and writes frames_<timestamp>.json logs; run_lab_comparison.sh automates side-by-side testing of a vulnerable and patched NGINX binary using separate log directories and result files; nginx_vulnerable.conf and docker/nginx_vulnerable.docker.conf provide the intentionally vulnerable proxy pattern for local and Docker use; Dockerfile and docker-compose.yml build and orchestrate the lab environment. Primary network targets/endpoints are the exposed NGINX listener (/exploit and /version), and the upstream logger on 127.0.0.1:8081 or upstream:8081. In Docker, nginx listens on 8080 and is exposed to the host as localhost:8080. The code also references local artifact paths for logs and results. Overall, this is an operational proof-of-concept lab that actively sends a crafted payload and validates whether upstream frame injection occurs under specific NGINX versions and configurations.

ikarolabordaDisclosed Jun 6, 2026phppythonnetworkweb
EXPOSURE SURFACE

Affected products & vendors

Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.

VendorProductType
F5Nginxapplication
NginxNginxapplication

Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.

What this page doesn’t show

The version that knows your environment.

This page is what’s public. Mallory adds the parts that aren’t: which of your assets are affected, which adversaries are exploiting it right now, which detections to deploy, and what to do tonight.
Exposure mapping

Query your assets running an affected version, and investigate the blast radius.

Threat actor evidence

Every observed campaign linking this CVE to a named adversary.

Associated malware

Malware families riding this exploit, with evidence and IOCs.

Detection signatures

YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.

Vendor-by-vendor mapping

Cross-references every affected SKU, including bundled OEM variants.

Social activity3

Community discussion across Reddit, Mastodon, and other social sources.