CVE-2026-74757
Apache bRPC: Uncontrolled Memory Allocation via Malicious mcpack Array Item Count
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)
- Upgrade bRPC to version 1.18.0, which fixes this issue.
- 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.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- None
- Integrity
- None
- Availability
- High
Exploit likelihood
What each source reports
CVE List Score used
Apache bRPC: Uncontrolled Memory Allocation via Malicious mcpack Array Item Count
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)
- Upgrade bRPC to version 1.18.0, which fixes this issue.
- 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.
- Record
CVE-2026-74757- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - Weakness
- CWE-770
- Updated
- 2026-11-02
EUVDEUVD-2026-107181
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)
- Upgrade bRPC to version 1.18.0, which fixes this issue.
- 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.
- Record
EUVD-2026-107181- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-px5f-q4rm-r7jp
Uncontrolled resource allocation in the mcpack2pb component in Apache bRPC (version < 1.18.0) on...
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)
- Upgrade bRPC to version 1.18.0, which fixes this issue.
- 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.
- Record
GHSA-px5f-q4rm-r7jp- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - Weakness
- CWE-770
- Updated
- 2026-11-02
NVD
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)
- Upgrade bRPC to version 1.18.0, which fixes this issue.
- 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.
- Record
CVE-2026-74757- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - Weakness
- CWE-770
- Updated
- 2026-11-02
Affected products
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | CVE List, EUVD, GitHub Advisories, NVD |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2026-74757 is a high vulnerability (CVSS 7.5) in Apache Software Foundation Brpc, published October 21, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.63%, the 50th percentile. No source names a fixed version.