Cloudanix VulnDB

CVE-2026-23527

High · 8.9

CVSS

8.9

EPSS

0.6%

Published

Jan 15, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

Some web applications may misread specially formatted web requests, allowing an attacker to confuse the server into handling requests incorrectly or bypassing protections.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
High
Impact
Full Compromise
Component
Web Framework
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The flaw is an HTTP request smuggling issue in H3 before 1.15.5 caused by case-sensitive parsing of the Transfer-Encoding header. H3 specifically checked for the lowercase value "chunked" instead of treating the header value case-insensitively as required by HTTP standards. When H3 is deployed behind a proxy, load balancer, CDN, or other HTTP intermediary that interprets mixed-case Transfer-Encoding values correctly, the frontend and backend can disagree about where one HTTP request ends and the next begins. That parsing mismatch can allow an unauthenticated remote attacker to desynchronize the connection and cause backend request confusion, potentially enabling request routing bypass, cache poisoning, credential or response hijacking, unauthorized access to internal routes, and limited denial of service.

Why it matters to the business

Internet-facing applications built on vulnerable H3 versions may be exposed to attacks that bypass normal routing, authentication, or proxy-layer controls. The most serious outcomes are unauthorized access to user data, account actions performed in the context of another user, poisoned cached content, or disruption of application availability. Although the EPSS score is currently low, the CVSS score is high, the issue has been public for 206 days, and HTTP request smuggling flaws are commonly targeted once reliable deployment-specific techniques are developed, so remediation should be prioritized for externally reachable services and applications behind reverse proxies or CDNs.

How an attack unfolds

An attacker first identifies an application using a vulnerable H3-based HTTP stack, especially one deployed behind a proxy or load balancer. They then send crafted HTTP/1.1 requests that contain ambiguous body framing, commonly involving both Content-Length and Transfer-Encoding headers, with the Transfer-Encoding value using non-lowercase variants such as "Chunked" or "CHUNKED". The frontend intermediary may honor the header as chunked encoding, while the vulnerable H3 backend fails to recognize it because of the case-sensitive comparison. This creates a disagreement about request boundaries. The attacker abuses that disagreement to leave bytes queued on the backend connection so that the next request is interpreted incorrectly, potentially prefixing or altering another request, reaching backend-only paths, poisoning shared caches, or forcing error conditions. Successful exploitation is highly dependent on the exact proxy, connection reuse, HTTP version handling, and application routing behavior.

How to fix it

Upgrade H3 to version 1.15.5 or later. For source-based deployments, ensure the code includes fix commit 24231b9c448aa852b15b889c53253a783f67a126 or a later commit containing the same correction. For SUSE Linux Enterprise Live Patching 15 SP6 RT Update 1, update kernel-livepatch-SLE15-SP6-RT_Update_1 to version 11-150600.2.1 or later where applicable. Rebuild and redeploy all applications, containers, serverless packages, and bundled dependencies that include H3. As compensating controls, configure proxies, CDNs, WAFs, ingress controllers, and API gateways to reject ambiguous HTTP/1.1 requests, especially requests containing both Content-Length and Transfer-Encoding, duplicate Content-Length headers, malformed chunked encoding, or unusual Transfer-Encoding values. Prefer HTTP/2 or HTTP/3 between trusted layers where feasible, but do not rely on protocol translation alone unless the intermediary strictly normalizes and validates request framing. Disable backend connection reuse only as a temporary mitigation because it may reduce, but not fully remove, smuggling risk and can materially affect performance.

How to confirm the fix worked

Confirm all dependency manifests and lockfiles resolve H3 to 1.15.5 or later, or to a fixed commit at or after 24231b9c448aa852b15b889c53253a783f67a126. Use package tooling such as npm, pnpm, yarn, or software composition analysis to identify transitive H3 usage in applications and container images. For SUSE systems, verify the installed livepatch package version is 11-150600.2.1 or later where that package is present. In a controlled non-production environment, send benign HTTP/1.1 requests with mixed-case Transfer-Encoding values and confirm the application, proxy, and backend reject or consistently normalize ambiguous request framing rather than producing desynchronized responses. Validate that edge controls block requests containing both Content-Length and Transfer-Encoding. Review deployed artifacts after remediation to ensure old containers, cached serverless bundles, and inactive but reachable service versions were not left behind.

Typical attack path

  1. Identify an H3-based application reachable over HTTP/1.1, preferably behind a reverse proxy, CDN, ingress controller, or load balancer.
  2. Probe for request parsing inconsistencies using benign ambiguous requests with both Content-Length and Transfer-Encoding headers.
  3. Vary the capitalization of the Transfer-Encoding value, such as Chunked, CHUNKED, or mixed-case forms, to determine whether the frontend and backend disagree.
  4. Confirm connection desynchronization by observing delayed responses, unexpected 400/502 errors, response queueing, or backend requests being interpreted out of order.
  5. Craft a smuggled request fragment that targets sensitive routes, cacheable content, or actions normally protected by frontend controls.
  6. Use connection reuse timing to cause the backend to combine the smuggled fragment with a subsequent request, potentially impacting another user or trusted internal flow.
  7. Attempt to exfiltrate responses, poison cache entries, bypass access controls, or disrupt service depending on the application and intermediary behavior.

How to detect it

Detection should focus on both direct evidence of ambiguous HTTP requests and secondary signs of request desynchronization. Review CDN, WAF, reverse proxy, load balancer, ingress controller, and application access logs for HTTP/1.1 requests containing both Content-Length and Transfer-Encoding, especially where Transfer-Encoding uses mixed or uppercase forms such as Chunked, CHUNKED, or cHuNkEd. Search for duplicate Content-Length headers, malformed chunk sizes, requests with unusual bodies on methods that normally do not carry bodies, and abnormal sequences where a malformed request is followed by an unexpected request to an administrative, internal, authentication, or cacheable route on the same backend connection. Correlate spikes in 400, 408, 421, 502, and 503 responses with suspicious header patterns. On Node.js or JavaScript application hosts, review runtime and application logs for HTTP parser errors, unexpected end-of-stream errors, aborted requests, and route handling anomalies. Cache logs should be reviewed for unexpected cache keys, unusual cacheable responses, or content served under the wrong path or host. Because request smuggling evidence is often removed or normalized by intermediate systems, prioritize log sources that preserve raw request headers.

  • Transfer-Encoding: Chunked
  • Transfer-Encoding: CHUNKED
  • Transfer-Encoding: chunked
  • Transfer-Encoding: cHuNkEd
  • Transfer-Encoding: Chunked\r\nContent-Length:
  • Transfer-Encoding: CHUNKED\r\nContent-Length:
  • Content-Length: 0\r\nTransfer-Encoding: Chunked
  • Content-Length: 0\r\nTransfer-Encoding: CHUNKED
  • Content-Length: 0\r\nTransfer-Encoding: cHuNkEd
  • Transfer-Encoding: gzip, chunked
  • Transfer-Encoding: chunked\r\nTransfer-Encoding:
  • duplicate Content-Length
  • both Content-Length and Transfer-Encoding
  • HPE_INVALID_TRANSFER_ENCODING
  • HPE_UNEXPECTED_CONTENT_LENGTH
  • Parse Error: Invalid header value char
  • Parse Error: Content-Length can't be present with Transfer-Encoding
  • client sent invalid chunked body
  • upstream prematurely closed connection
  • invalid chunk size
  • 400 Bad Request
  • 502 Bad Gateway

What your security team should do

  • Inventory all applications and services that use H3 directly or transitively, including Nuxt/Nitro-based deployments and bundled JavaScript server runtimes.
  • Prioritize externally reachable H3 applications, especially those behind reverse proxies, CDNs, ingress controllers, or load balancers that reuse backend HTTP/1.1 connections.
  • Upgrade H3 to 1.15.5 or later and redeploy affected services; verify fixed commit 24231b9c448aa852b15b889c53253a783f67a126 or later for source-pinned builds.
  • Apply SUSE package updates to kernel-livepatch-SLE15-SP6-RT_Update_1 version 11-150600.2.1 or later where applicable.
  • Add or verify edge rules that reject requests with both Content-Length and Transfer-Encoding, duplicate Content-Length headers, malformed chunked bodies, or non-standard Transfer-Encoding values.
  • Search historical proxy, WAF, CDN, and application logs for suspicious mixed-case Transfer-Encoding traffic and desynchronization symptoms.
  • Increase monitoring for unusual 400, 408, 502, and 503 spikes, backend parse errors, cache anomalies, and requests to sensitive routes immediately following malformed HTTP requests.
  • If suspicious activity is found, preserve raw HTTP logs, proxy connection logs, application access logs, and cache logs before rotation for forensic review.

The record

H3 is a minimal H(TTP) framework built for high performance and portability. Prior to 1.15.5, there is a critical HTTP Request Smuggling vulnerability. readRawBody is doing a strict case-sensitive check for the Transfer-Encoding header. It explicitly looks for "chunked", but per the RFC, this header should be case-insensitive. This vulnerability is fixed in 1.15.5.

Affected packages

Ecosystem Package Introduced Fixed
npm h3 0 1.15.5

Related vulnerabilities