CVE-2026-74757 in bRPC
Summary
by MITRE • 10/21/2026
Uncontrolled resource allocation in the mcpack2pb component in Apache bRPC (version < 1.18.0) on all platforms allows remote attackers to make the server allocate a large amount of memory via sending a crafted mcpack request with a huge array item count.
Root Cause: The bRPC mcpack2pb parser trusts the item count stored in the mcpack array header without validating it against the actual payload size. The code generated by the mcpack2pb protoc plugin uses this count to preallocate memory for repeated protobuf fields via Reserve(). A malformed request declaring item_count = 0x7fffffff can force the server to preallocate about 16GB of virtual memory, which may abort the process (SIGABRT) on memory-constrained hosts.
Affected Scenarios: Use a bRPC server that wires a NsheadService to UbrpcMcpack2Adaptor (the Baidu ubrpc deployment pattern) and parses requests with code generated by the mcpack2pb protoc plugin. The request body is parsed before authentication.
How to Fix: (Choose one of the following options) 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3451
Note: No matter which option you choose, you should know that the fix caps the array item count to the remaining bytes of the array payload.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in Apache bRPC versions prior to 1.18.0 represents a critical uncontrolled resource allocation flaw within the mcpack2pb component. This issue allows remote attackers to trigger excessive memory consumption on affected servers by sending specially crafted MCPack requests containing an artificially inflated array item count. The core technical deficiency lies in the parsing logic of the mcpack2pb parser, which operates under a trust-based assumption regarding metadata integrity. Specifically, when processing arrays within the MCPack protocol format, the parser reads the item count field from the message header and immediately uses this value to preallocate memory for repeated protobuf fields via the Reserve method. The code generated by the mcpack2pb protoc plugin does not perform any validation checks to ensure that the declared number of items is consistent with the actual size of the payload data provided in the request body. This lack of boundary checking creates a direct path for resource exhaustion attacks, as the server blindly allocates memory based on untrusted input values rather than verifying them against physical constraints or remaining buffer sizes.
The operational impact of this vulnerability is severe, particularly for services deployed using specific architectural patterns such as wiring an NsheadService to UbrpcMcpack2Adaptor, which is a common deployment model in Baidu ubrpc environments. In these scenarios, the request body parsing occurs before any authentication or authorization checks are performed. This sequence allows unauthenticated remote attackers to exploit the flaw without needing valid credentials. By sending a crafted request with an item count value of 0x7fffffff, an attacker can force the server process to attempt preallocation of approximately sixteen gigabytes of virtual memory. On systems with limited available RAM or strict resource limits, this massive allocation demand typically causes the operating system to terminate the offending process via a SIGABRT signal due to out-of-memory conditions. This results in immediate service disruption and potential denial of service for all users relying on that server instance, effectively compromising availability without requiring any prior access privileges.
From a classification perspective, this vulnerability aligns with CWE-770: Allocation of Resources Without Limits or Throttling, as the application fails to restrict the amount of resources consumed by user input. It also maps to MITRE ATT&CK technique T1496: Resource Hijacking, where an attacker consumes significant system resources to degrade performance or cause a denial of service. The root cause is fundamentally a failure in input validation and boundary checking during protocol parsing. To mitigate this risk, organizations running Apache bRPC versions below 1.18.0 must take immediate action. The recommended remediation strategy involves upgrading the framework to version 1.18.0 or later, which incorporates fixes that cap the array item count based on the remaining bytes of the array payload rather than trusting the header value alone. Alternatively, if an upgrade is not immediately feasible, administrators can apply a specific patch available through Apache bRPC pull request number 3451. This patch enforces strict validation by ensuring that the allocated memory size does not exceed the actual data length present in the request, thereby preventing the excessive allocation behavior and restoring system stability against such attacks.