Apache bRPC CVE-2026-54426

Requires the target application to use Apache bRPC as a Redis client with ChannelOptions.protocol="redis" AND to receive replies from an untrusted, compromised, or faulty Redis server peer - the attacker must control or tamper with the Redis server side of the connection, not merely reach the client over the network. Exploitation is limited to this reverse trust scenario: deployments that connect only to trusted, operator-controlled Redis instances are effectively not exposed. No special client-side configuration is needed beyond use of the Redis protocol, and no authentication or user interaction on the client is required to trigger the crash once a malicious reply is delivered.

No CVSS vector, EPSS score, KEV listing, or POC is provided in the input, so quantitative exploitation signals are entirely absent and the assessment rests on the description and CWE-674 (uncontrolled recursion). This is a denial-of-service-only flaw: a deeply nested RESP array reply exhausts the stack via unbounded recursion, crashing the bRPC Redis client process. Critically, the threat actor is the Redis *server peer*, not an arbitrary internet attacker - exploitation requires the vulnerable bRPC client to connect to a malicious, compromised, or faulty Redis server (or an attacker positioned to tamper with server replies). This inverts the usual client-server trust model and substantially narrows real-world risk: deployments pointing bRPC only at trusted, controlled Redis instances are largely insulated. There is no confidentiality or integrity impact and no code execution - impact is limited to availability (process crash). My independent read is that this is a genuine but moderate-priority availability bug, not a high-urgency RCE; it warrants patching on normal cadence, prioritized where bRPC clients talk to untrusted or multi-tenant Redis endpoints. Authentication requirements cannot be confirmed because no CVSS vector is supplied.

An application using Apache bRPC (< 1.18.0) as a Redis client with ChannelOptions.protocol="redis" connects to a Redis endpoint that an attacker controls or has compromised. The malicious server returns a RESP reply containing a deeply nested array, and the client's reply parser recurses once per nesting level with no depth limit, exhausting the stack and crashing the client process. No public exploit was identified at time of analysis.