CVE-2025-54472: Apache bRPC · Uncontrolled Resource Consumption
Affects Apache bRPCSource CVE Database V5
Not known to be exploited · CVSS 7.5 High.
Data as of 26 Oct 2026, 14:05 UTC
- EPSS
- 1.2% chance of exploitation in 30 days – higher than 69% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HExploitation evidence
Disclosed: evidence found.
CVE published 14 Aug 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| Apache Software Foundation Apache bRPC | Affected
| Fixed in– |
AI-suggested
European organizations should immediately assess their use of Apache bRPC, particularly in Redis-related deployments. The primary mitigation is to upgrade all bRPC instances to version 1.14.1 or later, which contains a robust fix for the uncontrolled memory allocation issue. If upgrading is not immediately feasible, organizations should apply the official patch from the Apache bRPC GitHub repository (PR #3050) to enforce memory allocation limits. It is critical to review and adjust the redis_max_allocation_size configuration flag if legitimate Redis requests or responses exceed the default 64MB limit to avoid service disruptions post-patch. Network-level mitigations include restricting access to bRPC services to trusted clients only, implementing strict firewall rules, and deploying intrusion detection/prevention systems to monitor for anomalous Redis protocol traffic. Additionally, organizations should conduct thorough testing in staging environments to validate the patch and configuration changes before production deployment. Monitoring service logs for memory allocation errors or crashes can help detect attempted exploitation. Finally, maintaining up-to-date software inventories and vulnerability management processes will ensure timely response to similar future threats.
Description
Unlimited memory allocation in redis protocol parser in Apache bRPC (all versions < 1.14.1) on all platforms allows attackers to crash the service via network. Root Cause: In the bRPC Redis protocol parser code, memory for arrays or strings of corresponding sizes is allocated based on the integers read from the network. If the integer read from the network is too large, it may cause a bad alloc error and lead to the program crashing. Attackers can exploit this feature by sending special data packets to the bRPC service to carry out a denial-of-service attack on it. The bRPC 1.14.0 version tried to fix this issue by limited the memory allocation size, however, the limitation checking code is not well implemented that may cause integer overflow and evade such limitation. So the 1.14.0 version is also vulnerable, although the integer range that affect version 1.14.0 is different from that affect version < 1.14.0. Affected scenarios: Using bRPC as a Redis server to provide network services to untrusted clients, or using bRPC as a Redis client to call untrusted Redis services. How to Fix: we provide two methods, you can choose one of them: 1. Upgrade bRPC to version 1.14.1.2. Apply this patch ( https://github.com/apache/brpc/pull/3050 ) manually. No matter you choose which method, you should note that the patch limits the maximum length of memory allocated for each time in the bRPC Redis parser. The default limit is 64M. If some of you redis request or response have a size larger than 64M, you might encounter error after upgrade. For such case, you can modify the gflag redis_max_allocation_size to set a larger limit.