CVE-2024-47220

What it actually does

WEBrick versions through 1.8.1 can parse ambiguous HTTP requests incorrectly when a request contains both Content-Length and Transfer-Encoding headers. This enables HTTP request smuggling: a front-end proxy, load balancer, or intermediary may interpret the request boundary differently than WEBrick, allowing attacker-controlled bytes to be treated as a second, separate HTTP request. The result can be request routing confusion, bypass of access controls enforced by a front end, cache poisoning, credential/session confusion, or unauthorized access to endpoints that the attacker should not be able to reach directly.

Why it matters to the business

Applications using WEBrick in exposed or production-like deployments may be vulnerable to traffic manipulation that bypasses normal request handling and security controls. Although EPSS is currently low and this CVE is not in the CISA KEV catalog, request smuggling vulnerabilities can have high operational impact when WEBrick sits behind a proxy or gateway, especially for administrative paths, internal APIs, or authentication-protected functionality. The supplier notes that WEBrick should not be used in production, so continued production exposure also represents an architectural risk beyond this specific flaw.

How an attack unfolds

An attacker sends a crafted HTTP request to a service path handled by WEBrick, typically through a front-end proxy or load balancer. The request includes both Content-Length and Transfer-Encoding headers and embeds a second HTTP request inside the body of the first request, for example placing a request for an administrative endpoint after a seemingly benign request. If the intermediary and WEBrick disagree about where the first request ends, the embedded bytes may be queued or processed by WEBrick as a separate request. Depending on routing and authentication behavior, this can let the attacker reach restricted endpoints, poison responses, desynchronize client connections, or cause another user's request to be paired with attacker-controlled content. Exploitation generally requires network access to the HTTP service and a deployment topology where WEBrick receives requests that have not been normalized or rejected by an upstream component.

How to fix it

Do not use WEBrick for production Internet-facing services. Replace WEBrick with a production-grade Ruby application server or place the application behind an HTTP component that rejects malformed or ambiguous requests before they reach WEBrick. Upgrade the WEBrick gem/package to a version newer than 1.8.1, such as a vendor-provided patched release, where available. If immediate replacement or upgrade is not possible, configure upstream proxies, load balancers, and web application firewalls to reject any request containing both Content-Length and Transfer-Encoding headers, reject malformed chunked encoding, disable unsafe connection reuse where practical, and ensure administrative or internal endpoints are not reachable through the same public listener. Also review Ruby dependency lockfiles and container images to ensure vulnerable WEBrick versions are not bundled indirectly.

How to confirm the fix worked

Confirm that no runtime dependency resolves to WEBrick 1.8.1 or earlier by checking Gemfile.lock, gem inventory, container image manifests, and operating-system package metadata. Send a safe validation request in a controlled test environment containing both Content-Length and Transfer-Encoding headers and verify that the request is rejected by the front end with a 400-class response and is not forwarded to WEBrick. Confirm that upstream proxies normalize or block ambiguous framing and that backend access logs do not show an embedded second request being processed. Re-run application integration tests for authentication, admin routes, reverse proxy behavior, keep-alive handling, and caching after any server or proxy change.

Typical attack path

1. Identify an HTTP service implemented with or backed by Ruby WEBrick, especially one exposed behind a reverse proxy, load balancer, API gateway, or cache.
2. Send probing requests that include both Content-Length and Transfer-Encoding headers to test whether the front end and WEBrick parse request boundaries differently.
3. Craft a request where a benign outer request contains an embedded second request such as an administrative path, internal API path, or authenticated endpoint.
4. Use connection reuse or proxy behavior to cause WEBrick to process the embedded request as a separate HTTP request.
5. Observe response desynchronization, unexpected status codes, cache behavior, access to restricted routes, or impact on subsequent users' requests.
6. Iterate on header ordering, transfer encoding, body length, and connection handling to reliably bypass controls or poison traffic.

How to detect it

Look for evidence of HTTP request smuggling probes or successful request desynchronization. Useful sources include reverse proxy logs, load balancer logs, WAF events, raw packet captures, Ruby application logs, WEBrick access/error logs, and authentication or administrative endpoint audit logs. Hunt for requests where both Content-Length and Transfer-Encoding are present, especially when followed by unusual 400/408/502 responses, connection resets, unexpected keep-alive behavior, or backend requests that have no matching front-end log entry. Investigate any logs showing HTTP request lines embedded in request bodies, repeated chunked-transfer anomalies, access to administrative paths immediately after malformed requests from the same source, mismatched status codes between front end and backend, or cache responses associated with unexpected users. If raw headers are not retained, correlate front-end and backend request IDs, timestamps, source addresses, and connection reuse patterns to find backend requests that appear without a corresponding valid client request.

• Content-Length:
• Transfer-Encoding: chunked
• Content-Length: 0\r\nTransfer-Encoding: chunked
• Transfer-Encoding: chunked\r\nContent-Length:
• \r\n0\r\n\r\nGET /
• \r\n0\r\n\r\nPOST /
• GET /admin HTTP/1.1
• POST /admin HTTP/1.1
• 400 Bad Request
• Bad Request-Line
• invalid chunk size
• malformed chunked encoding
• WEBrick

What your security team should do

• Inventory all Ruby services, development tools, internal utilities, containers, and appliances that include or start WEBrick, prioritizing any network-exposed listener.
• Remove WEBrick from production request paths; migrate to a production-grade Ruby server or ensure a hardened reverse proxy rejects ambiguous HTTP framing before forwarding traffic.
• Upgrade WEBrick to a patched version newer than 1.8.1 wherever the gem is present, including transitive dependencies and base images.
• Add proxy/WAF rules to block requests containing both Content-Length and Transfer-Encoding headers and alert on repeated attempts.
• Review access logs and raw HTTP telemetry for request smuggling probes, especially requests targeting administrative paths or containing embedded HTTP request lines inside request bodies.
• Limit exposure of administrative and internal routes with network controls and independent authentication checks that do not rely solely on a front-end proxy.
• Because no public exploit maturity is indicated and EPSS is low, prioritize remediation by exposure: Internet-facing and proxy-backed WEBrick deployments first, then internal-only development or test instances.