CVE-2026-38969: 
Ruby Analyse et atténuation des vulnérabilités

CVE-2026-38969 is an HTTP request smuggling vulnerability in Ruby's WEBrick web server library (through v1.9.2) caused by improper handling of chunked transfer encoding trailers. WEBrick incorrectly reparses trailer Content-Length headers into the canonical request state, allowing attackers to forge request metadata visible to the application. The vulnerability was reported on March 24, 2026, publicly disclosed on July 2, 2026, and affects all WEBrick versions up to and including v1.9.2. It carries a CVSS v3.1 base score of 6.5 (Medium/High) (GitHub Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-444 (Inconsistent Interpretation of HTTP Requests / HTTP Request Smuggling). In lib/webrick/httprequest.rb, the read_chunked method calls read_header to parse chunked trailers, which merges trailer fields directly into the main @header hash. Because meta_vars derives CONTENT_LENGTH from this merged header map, a trailer-supplied Content-Length value is promoted to authoritative request metadata — overriding the actual body size. A crafted chunked request with a 1-byte body and a trailer declaring Content-Length: 5 causes the application to observe req['content-length'] == "5" and req.meta_vars['CONTENT_LENGTH'] == "5" while the real body is only 1 byte, creating a trust-boundary violation exploitable for request smuggling or cache poisoning (WEBrick Issue #198, GitHub Advisory).

Successful exploitation allows an unauthenticated network attacker to inject malicious payloads that bypass security controls by manipulating how WEBrick interprets request boundaries. Concrete consequences include bypassing request filtering or WAF rules, injecting forged requests intended for backend systems, and poisoning shared caches affecting multiple users. Integrity is the primary impact (rated HIGH in CVSS), with limited availability impact and no direct confidentiality impact, though chained attacks could escalate to broader compromise of backend services (Feedly Intelligence, Red Hat Bugzilla).

1. Identify target: Locate applications running Ruby WEBrick v1.9.2 or earlier, particularly those deployed behind a reverse proxy or load balancer that forwards chunked requests without stripping trailers.
2. Craft malicious chunked request: Construct an HTTP/1.1 POST request using Transfer-Encoding: chunked with a minimal body (e.g., 1 byte) followed by a terminating chunk (0\r\n) and a trailer header Content-Length: <forged_value>\r\n\r\n.
3. Send the request: Transmit the crafted request directly to the WEBrick server (e.g., using a raw socket or curl --raw):

POST / HTTP/1.1\r\nHost: target\r\nTransfer-Encoding: chunked\r\nConnection: close\r\n\r\n1\r\na\r\n0\r\nContent-Length: 5\r\n\r\n

4. Observe metadata confusion: The application receives req['content-length'] == "5" and req.meta_vars['CONTENT_LENGTH'] == "5" while the actual body is 1 byte, confirming the smuggling primitive.
5. Exploit downstream trust: Leverage the forged Content-Length to bypass security filters, inject a second request into a pipelined connection, or poison shared caches by causing downstream systems to misinterpret request boundaries (WEBrick Issue #198).

• Network: HTTP POST requests using Transfer-Encoding: chunked that include a Content-Length header in the trailer section (after the terminating 0\r\n chunk); unusual discrepancies between reported Content-Length and actual body size in proxy logs.
• Logs: WEBrick access logs showing chunked POST requests where the logged content length does not match the actual transferred bytes; repeated requests to the same endpoint with varying trailer-supplied Content-Length values.
• Application Behavior: Backend applications or CGI scripts receiving CONTENT_LENGTH environment variables that do not match the actual request body size; unexpected cache entries with mismatched content lengths in shared caching layers.

The fix is available via a pending pull request (WEBrick PR #199) by Jeremy Evans, which restricts allowed trailer headers to an explicit allowlist and explicitly blocks Content-Length from being promoted from trailer to canonical header state. Users should update WEBrick to a patched version beyond v1.9.2 once released. As an immediate workaround, implement strict Content-Length validation at a reverse proxy or WAF layer, reject requests with conflicting or trailer-supplied Content-Length headers, and avoid exposing WEBrick directly to untrusted networks (GitHub Advisory, Red Hat Bugzilla).

Red Hat has filed a tracking bug (Bug 2496708) and assigned medium severity, with 24 CC'd users indicating active internal triage across multiple product teams. The upstream WEBrick maintainer Jeremy Evans responded promptly with a proposed fix (PR #199) within one day of the original bug report, noting the issue relates to the same trust-boundary problem as the historical CVE-2015-7519. No significant broader media coverage or social media discussion has been observed at this time (Red Hat Bugzilla, WEBrick PR #199).