Apache bRPC’s mcpack2pb parser does not validate the item count read from an mcpack array header before using it to preallocate memory for repeated protobuf fields via Reserve(). A malicious request that sets item_count to 0x7fffffff can cause the server to request roughly 16 GB of virtual memory, potentially aborting the process (SIGABRT) on hosts with limited resources. This flaw allows remote attackers to trigger a denial‑of‑service by exhausting memory or terminating the service. The weakness is an example of CWE‑770: Uncontrolled Resource Consumption.

Versions of Apache bRPC earlier than 1.18.0 that incorporate the mcpack2pb protoc plugin are affected. The vulnerability manifests when a bRPC server wires a NsheadService to UbrpcMcpack2Adaptor, uses the generated code to parse incoming mcpack requests, and performs parsing before authentication. The issue is platform‑agnostic, affecting any system where this deployment pattern is in use.

Because the flaw can be triggered purely by a crafted mcpack message and does not require authentication, attackers can execute it over the network against exposed bRPC services. The CVSS score of 7.5 indicates a high severity, and the EPSS score of 0.242% indicates a very low but non‑zero likelihood of exploitation, while the flaw is not listed in CISA’s KEV catalog. This vulnerability can cause a server crash and memory exhaustion, leading to denial‑of‑service. The typical exploitation chain involves an attacker sending a malformed mcpack request with an enormous array item count, causing the server to allocate excessive memory and terminate; the lack of rate limiting or input validation exacerbates the risk.