CVE-2026-54426 in bRPC
Summary
by MITRE • 10/22/2026
Uncontrolled recursion in the Redis reply parser in Apache bRPC < 1.18.0 allows a remote Redis server peer to crash a bRPC Redis client process by returning a deeply nested RESP array reply. The parser recursed once for each nested array level without enforcing a depth limit. The fix adds a configurable Redis reply depth limit with default value 128 and rejects replies exceeding that limit.
Affected Scenarios: Applications using bRPC as a Redis client with ChannelOptions.protocol="redis" and receiving replies from an untrusted or faulty Redis server peer.
How to Fix: 1. Upgrade Apache bRPC to 1.18.0. 2. Apply the patch from PR https://github.com/apache/brpc/pull/3344 .
Note: After applying the fix, Redis replies with array nesting deeper than redis_max_reply_depth are rejected.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Apache bRPC versions prior to 1.18.0 represents a critical uncontrolled recursion flaw within the protocol buffer RPC framework's implementation of the Redis client interface. This issue specifically affects applications that utilize bRPC as a Redis client by configuring ChannelOptions with the protocol set to redis. The core technical deficiency lies in the reply parser, which is responsible for decoding Remote Procedure Call (RESP) arrays returned by Redis servers. When processing these replies, the parser employs a recursive algorithm to traverse nested array structures without implementing any mechanism to enforce a maximum depth limit. This architectural oversight allows an attacker or a faulty server to exploit the lack of boundary checks by constructing deeply nested RESP array responses.
From a technical perspective, each level of nesting in the RESP protocol triggers another invocation of the parsing function within the bRPC library. Because there is no counter or threshold to halt this recursion after a certain depth, the call stack grows linearly with the complexity of the input data. In standard computing environments, memory allocated for the call stack is finite and relatively small compared to heap memory. Consequently, when an untrusted Redis server peer returns a reply containing arrays nested beyond the available stack space, it results in a stack overflow condition. This leads directly to the termination or crash of the bRPC client process, effectively causing a denial of service against any application relying on this specific configuration for database connectivity.
The operational impact of this vulnerability is significant for systems that interact with external or untrusted Redis instances. An adversary controlling a compromised Redis server can remotely trigger this stack overflow simply by sending maliciously crafted responses during normal query operations. This does not require authentication bypasses or complex exploitation chains; the mere act of receiving the malformed reply is sufficient to crash the client application. For high-availability systems, such crashes can lead to service interruptions, data inconsistency if transactions are left in an undefined state, and increased operational overhead due to frequent process restarts. The vulnerability aligns with CWE-675, which describes operations that do not limit recursion depth, a common pattern leading to resource exhaustion vulnerabilities.
Mitigation strategies focus primarily on software updates and configuration adjustments. The definitive solution is to upgrade Apache bRPC to version 1.18.0 or later, where the developers have introduced a configurable maximum reply depth parameter named redis_max_reply_depth. This fix ensures that any RESP array exceeding this limit is rejected before it can trigger recursive processing, thereby preventing stack exhaustion. For environments unable to immediately patch, applying the specific changes from pull request 3344 on the Apache bRPC GitHub repository provides an alternative remediation path. Additionally, organizations should consider implementing network-level controls or proxying Redis traffic through a trusted intermediary that validates response structures before they reach the application layer, adding defense in depth against malformed inputs from potentially compromised backend services. This incident also highlights the importance of validating external data streams according to ATT&CK technique T1496, Resource Hijacking, specifically regarding denial-of-service via resource exhaustion.