CVE-2026-58055: 
npm vulnerability analysis and mitigation

CVE-2026-58055 is an HTTP request/response smuggling vulnerability in nghttp2's nghttpx reverse proxy component, classified as CWE-444 (Inconsistent Interpretation of HTTP Requests). The flaw affects nghttpx through version 1.69.0, where the proxy forwards HTTP/1.1 Upgrade requests carrying both a Content-Length header and body onto reusable keep-alive backend connections, re-adding Upgrade and Connection headers while passing Content-Length verbatim. This creates an ambiguous HTTP message that a susceptible backend may resolve in the attacker's favor, enabling cross-client response-queue poisoning. The vulnerability was published on June 28, 2026, with a CVSS v3.1 score of 5.4 (Medium) and a CVSS v4.0 score of 6.3 (Medium) (Github Advisory, VulnCheck).

The root cause (CWE-444) lies in nghttpx's HTTP/1.1 frontend parser accepting Upgrade requests that carry a Content-Length header and body, then forwarding both the Upgrade/Connection headers and the body bytes verbatim to a reusable keep-alive backend connection via HttpDownstreamConnection::push_request_headers() and process_blocked_request_buf(). An Upgrade-aware backend may treat bytes after the header terminator as the start of a new HTTP request rather than as a body, effectively queuing an attacker-controlled request on the shared backend connection. When nghttpx subsequently reuses that backend connection for a different frontend client, the delayed response to the attacker's smuggled request is delivered to the victim client instead of the legitimate response. The upstream fix (commit ab28105) explicitly rejects Upgrade or CONNECT requests carrying Transfer-Encoding or Content-Length with a 400 Bad Request, and defers body forwarding until after a successful Upgrade tunnel is established (nghttp2 commit, PoC repo).

A successful exploit allows an unauthenticated network attacker to inject attacker-controlled responses into the response queue of other clients sharing the same backend connection, achieving cross-client response-queue poisoning. This can be used to serve attacker-controlled same-origin content to victim users, confuse application routing logic, poison intermediate caches that trust nghttpx response boundaries, or deliver responses belonging to attacker-selected backend routes under victim requests. Confidentiality and integrity are both partially impacted — the attacker can read or manipulate data intended for other clients — while availability is not directly affected (Github Advisory, VulnCheck).

A public proof-of-concept exploit (poc.py) exists in the bikini/exploitarium repository and has been verified end-to-end against a real nghttpx binary from nghttp2 v1.69.0, demonstrating successful response-queue poisoning (PoC repo). Despite the PoC's availability, there is currently no evidence of in-the-wild exploitation or threat actor attribution. The EPSS score is approximately 0.202%, indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA KEV catalog, and NVD's SSVC assessment classifies exploitation as "none" at this time (Github Advisory).

1. Reconnaissance: Identify internet-facing nghttpx instances (part of nghttp2 ≤ 1.69.0) proxying HTTP/1.1 backends with keep-alive connection reuse enabled, using tools like Shodan or Censys.
2. Craft the smuggling request: Construct an HTTP/1.1 Upgrade request to a backend route whose response can be delayed, embedding a complete smuggled HTTP request in the body with a matching Content-Length header:

GET /upgrade HTTP/1.1
Host: target
Connection: Upgrade
Upgrade: websocket
Content-Length: 43

GET /poisoned HTTP/1.1
Host: backend

3. Send the attacker request: Submit the crafted request to the nghttpx HTTP/1.1 frontend. nghttpx forwards both the Upgrade headers and the body bytes to the backend on a keep-alive connection.
4. Backend parses smuggled request: An Upgrade-aware backend treats bytes after the header terminator as a new HTTP request (GET /poisoned), queues a delayed response, and replies to the Upgrade attempt with a rejection (e.g., UPGRADE-REJECT).
5. Victim request arrives: A second client sends a legitimate request (e.g., GET /victim). nghttpx reuses the same backend connection.
6. Response queue poisoning: The backend's delayed response to /poisoned (containing attacker-controlled content) is read by nghttpx as the response to the victim's GET /victim request, delivering the attacker's payload to the victim client (PoC repo).

• Network: Unexpected HTTP/1.1 Upgrade requests to nghttpx frontends carrying both Upgrade/Connection headers and a non-zero Content-Length body; backend connections receiving multiple distinct HTTP requests within a single keep-alive session where the first is an Upgrade request.
• Logs: nghttpx access logs showing Upgrade requests immediately followed by unrelated backend requests on the same connection; victim clients receiving unexpected response bodies not matching their request path; log entries for HTTP callback error or transfer-encoding and content-length are not allowed in CONNECT or upgrade request (present only after patching).
• Application Behavior: Clients reporting receiving responses intended for other users or unexpected same-origin content; cache entries containing attacker-controlled data under legitimate resource paths (PoC repo, VulnCheck).

Upgrade nghttp2 to a version beyond 1.69.0 containing the upstream fix at commit ab28105c4a0197da24f8bfc414bc116055249e1e, which rejects Upgrade and CONNECT requests carrying Transfer-Encoding or Content-Length headers with a 400 Bad Request response. As a configuration-based workaround, disable backend keep-alive connection reuse in nghttpx to prevent the poisoned connection from being shared with other clients, though this has performance implications. Additionally, implement strict HTTP message validation and normalization at both proxy and backend layers to reject ambiguous Upgrade requests (nghttp2 commit, VulnCheck).

The vulnerability was assigned by VulnCheck and covered in their advisory. The bikini/exploitarium repository (3.9k stars, 1.1k forks) published a detailed PoC, drawing attention from the security community on platforms including Bluesky and Mastodon/infosec.exchange. Infosecurity Magazine covered the broader exploitarium project in relation to this and similar CVEs. The Yocto Project security mailing list also flagged the issue for embedded Linux maintainers (Infosecurity Magazine, PoC repo).