Apache bRPC CVE-2026-61902

Exploitation requires the affected process to use one of the specific parsing paths that fail to enforce max_body_size: non-progressive HTTP/1 parsing, non-progressive HTTP/2 parsing, or memcache/couchbase response parsing - i.e., a bRPC service acting as an HTTP/1, HTTP/2, memcache, or couchbase endpoint reachable by the attacker. The condition is that the server uses non-progressive (fully-buffered) reading; the advisory explicitly notes that progressive HTTP reading is NOT affected because it uses bounded buffering, so deployments relying solely on progressive reads are not exposed. The primary limiting factor for defenders is network exposure of these specific bRPC parsers to untrusted peers; per the vendor the attack needs no authentication, but this is not confirmed by a CVSS vector in the available data.

This is a remotely-triggerable denial-of-service flaw (CWE-400, uncontrolled resource consumption) in Apache bRPC prior to 1.18.0. No CVSS score or vector is provided in the input, so attack-vector/complexity/privilege signals cannot be independently corroborated from a vendor-supplied vector - however, the Apache advisory description explicitly characterizes the attacker as a 'remote unauthenticated peer', which aligns with a network-reachable, no-auth, low-complexity DoS. There is NO EPSS score, NO CISA KEV listing, and NO public POC referenced in the provided data, so there is no public exploit identified at time of analysis and no evidence of active exploitation. Because impact is confined to availability (memory exhaustion / process crash) with no confidentiality or integrity consequence, this is a moderate-severity operational-reliability issue rather than a top-tier emergency: real but not a drop-everything priority. The absence of EPSS/KEV/POC combined with the DoS-only impact and the relatively specialized deployment profile of bRPC suggests limited widespread automated exploitation risk, though the low exploitation complexity means any bRPC service directly exposed to untrusted clients using the affected parsers should be patched promptly. Key caveat: auth requirement is stated in the advisory prose but not confirmed by a CVSS vector - verify against the Apache advisory before treating 'unauthenticated' as definitive for your deployment.

A remote attacker connects to a bRPC-based service that exposes HTTP/1, HTTP/2, memcache, or couchbase endpoints and sends a message whose declared or streamed body exceeds the configured max_body_size using a non-progressive parsing path. Because the limit is not consistently enforced on these paths, the server buffers the oversized payload in memory, and repeated or large requests exhaust available memory and crash or hang the process, denying service to legitimate clients. No public exploit code is identified at time of analysis, and the attack appears to require no authentication per the vendor description.