CVE-2025-6442

What it actually does

The flaw is an HTTP request smuggling vulnerability in Ruby WEBrick’s header parsing logic, specifically in read_headers. WEBrick and an upstream HTTP proxy can disagree about where HTTP headers end because they parse header terminators differently. When WEBrick is deployed behind a proxy with compatible parsing behavior, a remote attacker can craft one ambiguous HTTP request that the proxy interprets one way and WEBrick interprets as containing an additional, attacker-controlled request. The smuggled request may bypass proxy-layer routing, access-control, caching, or request normalization assumptions. Exploitability depends on the exact proxy, connection reuse, and HTTP parsing behavior in front of WEBrick.

Why it matters to the business

Successful exploitation can allow an external attacker to send hidden requests into an application path that operators expect to be protected or normalized by a front-end proxy. Depending on application behavior, this may lead to authentication bypass, unauthorized actions, cache poisoning, request misrouting, exposure of internal endpoints, or user session impact. The vulnerability is not currently in CISA KEV, is not marked as ransomware-used, has low EPSS, and has no indicated mature public exploit, so urgency is lower than actively exploited internet-scale issues; however, exposure should still be remediated because request smuggling flaws are often highly environment-dependent and can become serious when WEBrick is used behind reverse proxies in production.

How an attack unfolds

An attacker first identifies an application or service using Ruby WEBrick behind an HTTP proxy or reverse proxy. They then test how the proxy and WEBrick handle malformed or ambiguous HTTP header termination, especially cases where the proxy believes the request has ended but WEBrick continues parsing or vice versa. If a parsing difference exists, the attacker sends a crafted HTTP request over a keep-alive connection that contains both a front request accepted by the proxy and a second embedded request intended for WEBrick. The proxy forwards what it believes is a valid request stream, while WEBrick desynchronizes and treats attacker-controlled bytes as a separate HTTP request. The attacker can then attempt to reach normally restricted paths, poison a response queue, affect another user’s request on the same backend connection, or trigger application-specific actions without the expected proxy-layer controls. No named threat actors or mature public exploit activity were provided for this issue.

How to fix it

Upgrade Ruby WEBrick to a version that includes the upstream fix commit 0fb9de6788a3ba5fe903e63d778a0fb8c1dce786 or install the vendor package that incorporates this patch. Where distribution packages are used, apply the relevant vendor security update; the provided fixed package data also lists libgd on Mageia 6 fixed in 2.2.5-2.3.mga6, but teams should confirm applicability against their vendor advisory because the described vulnerability is in Ruby WEBrick. If immediate upgrade is not possible, reduce exposure by avoiding WEBrick for internet-facing production traffic, disabling unnecessary proxy-to-backend connection reuse where feasible, enforcing strict HTTP/1.1 request validation at the edge, rejecting malformed header terminators, normalizing or dropping ambiguous requests at the proxy/WAF, and ensuring internal/admin-only routes are not protected solely by reverse-proxy assumptions.

How to confirm the fix worked

Confirm that deployed WEBrick code includes commit 0fb9de6788a3ba5fe903e63d778a0fb8c1dce786 or a vendor release containing that fix. Inventory applications that use the webrick gem or bundled Ruby WEBrick and identify any deployments behind reverse proxies, load balancers, API gateways, service meshes, or caching layers. In staging, send controlled malformed HTTP requests with unusual header termination and embedded request bytes through the same proxy path and confirm the proxy rejects them or that WEBrick does not process a second request. Review proxy configuration for strict HTTP parsing and request normalization settings. Validate package-level remediation with package manager output, dependency lockfiles, container image manifests, and runtime gem/version checks.

Typical attack path

1. Identify a Ruby WEBrick service reachable through an HTTP proxy, load balancer, gateway, or reverse proxy.
2. Fingerprint proxy and backend behavior using harmless malformed HTTP requests to determine whether header terminators are parsed inconsistently.
3. Craft an HTTP request with ambiguous header termination and an embedded second HTTP request.
4. Send the request over a connection where the proxy forwards traffic to WEBrick using persistent backend connections.
5. Cause WEBrick to interpret the embedded bytes as a separate request that the proxy did not independently authorize or normalize.
6. Use the smuggled request to access sensitive routes, bypass proxy controls, poison cached responses, or interfere with another request stream, depending on application behavior.

How to detect it

To assess possible prior exploitation, review raw HTTP logs from reverse proxies, load balancers, WAFs, API gateways, and WEBrick access/error logs for malformed requests, ambiguous header endings, embedded request lines inside request bodies, and unexpected request sequencing on persistent connections. Pay particular attention to requests that combine unusual line endings with keep-alive behavior, repeated or conflicting message framing headers, sudden 400-level parsing errors followed by successful access to sensitive paths, and backend requests that have no corresponding clean front-end request. If packet captures or full HTTP request logging are available, search for requests containing a complete second HTTP method after an apparent header/body terminator. Correlate proxy connection IDs with backend connection IDs where possible to identify desynchronization. Also investigate any unexpected access to admin, internal, debug, cacheable, or authenticated endpoints around the time malformed HTTP parsing errors occurred.

• Transfer-Encoding: chunked
• Content-Length: 0
• Content-Length: 1
• Connection: keep-alive
• \r\n0\r\n\r\nGET
• \r\n0\r\n\r\nPOST
• \n\nGET
• \n\nPOST
• \r\n\r\nGET /admin
• \r\n\r\nPOST /admin
• \r\n\r\nGET /internal
• \r\n\r\nPOST /internal
• \r\n\r\nGET /debug
• \r\n\r\nPOST /debug
• GET http://
• POST http://
• WEBrick
• Bad Request

What your security team should do

• Prioritize remediation for any internet-facing or partner-facing WEBrick deployment behind a reverse proxy, load balancer, API gateway, cache, or WAF.
• Upgrade WEBrick to a build containing commit 0fb9de6788a3ba5fe903e63d778a0fb8c1dce786; apply any relevant vendor package updates, including Mageia libgd 2.2.5-2.3.mga6 only where the vendor advisory confirms applicability.
• Search application inventories, containers, CI manifests, Gemfiles, Gemfile.lock files, and runtime package lists for WEBrick usage, especially in services assumed to be non-production but reachable.
• Harden edge proxies to reject malformed HTTP requests, ambiguous line endings, conflicting message framing, and unexpected request bodies on methods that should not have them.
• Temporarily increase logging at proxies and WEBrick backends for malformed requests, connection reuse anomalies, unexpected 400 responses, and requests to sensitive routes.
• Review access controls on admin, debug, internal, and health endpoints to ensure they do not rely solely on proxy-layer restrictions.
• Because EPSS is low and the issue is not KEV-listed, schedule remediation based on exposure, but do not defer internet-facing proxy-backed deployments indefinitely.