Loading vulnerability…
CVE-2026-42926 is an HTTP/2 request injection vulnerability in NGINX Open Source affecting the HTTP proxy path when NGINX is configured to proxy upstream traffic over HTTP/2. When proxy_http_version is set to 2 and proxy_set_body is used, a remote unauthenticated attacker can cause NGINX to inject arbitrary HTTP/2 frame headers and payload bytes into the upstream connection. The issue affects the ngx_http_proxy_v2_module/ngx_http_proxy_module HTTP/2 proxying logic and results in improper construction or forwarding of upstream HTTP/2 data under that configuration. This can allow attacker-controlled bytes to be introduced into the proxied upstream stream, creating a request injection condition against the upstream peer.
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.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos (1 hidden).
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.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
8 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
An NGINX ngx_http_proxy_v2_module vulnerability that allows arbitrary HTTP/2 frame header and payload byte injection into the upstream connection, enabling desynchronization with the upstream HTTP/2 peer.
Уязвимость повреждения памяти в nginx при использовании proxy_set_body вместе с HTTP/2 upstream/proxying.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.