CVE-2024-23452: Apache bRPC Request Smuggling Vulnerability

CVE-2024-23452 Overview

CVE-2024-23452 is an HTTP request smuggling vulnerability in the HTTP server component of Apache bRPC versions 0.9.5 through 1.7.0. The flaw resides in the http_parser implementation, which does not comply with the RFC-7230 HTTP/1.1 specification regarding the handling of messages that contain both Transfer-Encoding and Content-Length headers. Attackers can leverage this parsing discrepancy to smuggle requests through a frontend proxy into a bRPC backend across a shared persistent connection. The vulnerability is classified under [CWE-444] (Inconsistent Interpretation of HTTP Requests) and affects all platforms running vulnerable bRPC releases.

Critical Impact
Remote, unauthenticated attackers can smuggle HTTP requests into backend bRPC servers, bypassing frontend security controls and poisoning request queues on shared connections.

Affected Products

Apache bRPC 0.9.5 through 1.7.0
Services exposing bRPC HTTP servers behind a reverse proxy or frontend that parses Transfer-Encoding: chunked
Applications that rely on bRPC for HTTP-based RPC endpoints on any platform

Discovery Timeline

2024-02-08 - CVE-2024-23452 published to NVD and disclosed on the Openwall OSS Security mailing list
2025-06-04 - Last updated in NVD database

Technical Details for CVE-2024-23452

Vulnerability Analysis

The vulnerability stems from non-compliant HTTP message parsing inside the bRPC HTTP server. RFC-7230 requires that when a request contains both Transfer-Encoding and Content-Length headers, the Content-Length must be ignored or the request rejected. The bRPC http_parser does not enforce this rule consistently with frontend proxies, which creates a desynchronization condition on persistent (keep-alive) connections. An attacker can craft a single TCP payload that the frontend interprets as one request while bRPC interprets it as two. The second, smuggled request is then injected into the backend's request stream, bypassing access controls and authentication enforced at the proxy layer.

Root Cause

The http_parser component in bRPC versions 0.9.5 through 1.7.0 deviates from RFC-7230 when reconciling conflicting Transfer-Encoding and Content-Length header values. Frontends that detect the substring chunked in the Transfer-Encoding field will frame the message using chunked encoding, while bRPC may fall back to Content-Length framing. This parser disagreement is the fundamental enabler of CL.TE-class smuggling attacks against bRPC backends.

Attack Vector

Exploitation requires no authentication and is performed over the network against an exposed HTTP endpoint. The attacker sends a single HTTP request containing both Transfer-Encoding: chunked and a Content-Length header through a frontend that pools persistent connections to the bRPC backend. The frontend forwards what it considers one request, but bRPC interprets the remaining bytes as the start of a second request. That smuggled request is then prepended to the next legitimate user's traffic, enabling cache poisoning, credential theft, request hijacking, and bypass of frontend security policies. Refer to the Apache mailing list discussion and the upstream pull request #2518 for technical details of the parser fix.

No verified public exploit code is available for this issue. The vulnerability mechanism follows the well-documented CL.TE request smuggling pattern: a request body framed using Content-Length by the backend is interpreted as a complete chunked message by the frontend, leaving residual bytes that form the prefix of a smuggled request.

Detection Methods for CVE-2024-23452

Indicators of Compromise

HTTP requests arriving at bRPC endpoints that contain both Transfer-Encoding and Content-Length headers
Anomalous chunked encoding values such as Transfer-Encoding: xchunked, duplicated Transfer-Encoding headers, or whitespace-obfuscated header names
Unexpected request methods, paths, or Host headers appearing on connections that previously served unrelated clients
Log entries showing two HTTP requests parsed from a single upstream connection in a timeframe inconsistent with normal pipelining

Detection Strategies

Inspect proxy and bRPC access logs for requests carrying both framing headers and flag them as suspicious
Compare frontend and backend request counts per connection to identify desynchronization
Deploy a Web Application Firewall (WAF) signature for known smuggling patterns including malformed Transfer-Encoding values
Run differential parser tests between the deployed bRPC version and a reference RFC-7230 parser to enumerate exploitable payloads

Monitoring Recommendations

Enable verbose HTTP request logging on both the frontend reverse proxy and bRPC backend, then correlate by connection ID
Alert on HTTP/1.1 responses that do not map to any logged client request, which indicates a smuggled request was serviced
Track the bRPC service version in software inventory and trigger alerts for any host still running versions 0.9.5 through 1.7.0

How to Mitigate CVE-2024-23452

Immediate Actions Required

Upgrade Apache bRPC to version 1.8.0 or later, available from the bRPC 1.8.0 release page
If upgrading is not immediately possible, apply the upstream patch from pull request #2518 and rebuild bRPC from source
Audit frontend proxies (Nginx, Envoy, HAProxy) to ensure they reject requests containing both Transfer-Encoding and Content-Length headers before forwarding
Review access logs for the period prior to patching to identify potential smuggling attempts

Patch Information

The fix is included in Apache bRPC 1.8.0. The patch corrects the http_parser so that requests containing both Transfer-Encoding and Content-Length headers are handled in compliance with RFC-7230, eliminating the parsing disagreement with upstream proxies. Source code and release notes are available at the official bRPC 1.8.0 release, and the corresponding code change is documented in GitHub pull request #2518.

Workarounds

Configure the frontend proxy to strip or reject ambiguous Transfer-Encoding and Content-Length header combinations
Disable HTTP/1.1 connection reuse (keep-alive) between the frontend proxy and bRPC backend to prevent cross-request contamination
Terminate HTTP at a compliant gateway and forward requests to bRPC over a strictly normalized internal protocol
Restrict network access to bRPC HTTP endpoints so that only trusted, RFC-compliant frontends can reach them