CVE-2026-56387 in bRPC
Summary
by MITRE • 10/21/2026
The RTMP AMF parser in Apache bRPC accepts AMF string lengths and array counts directly from untrusted input. A remote unauthenticated attacker who can reach a bRPC server with RTMP enabled can send a small AMF payload with an excessive declared long string length or array count, causing excessive memory allocation or resource consumption before the parser rejects the incomplete payload.
Root Cause: The AMF long string parser resized the destination string to the declared 32-bit length before validating that the stream contained that many bytes. ECMA array and strict array parsers also accepted 32-bit element counts without a configurable upper bound.
Affected Scenarios: Deployments that enable the bRPC RTMP server component and accept RTMP traffic from untrusted clients. Direct uses of the AMF parser on untrusted data are also affected.
How to Fix: 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3353
Note: The fix introduces configurable AMF parsing limits. The default maximum string size is 64 MiB and the default maximum array element count is 1,048,576. Payloads above these limits are rejected. The limits can be adjusted with amf_max_string_size and amf_max_array_size.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in Apache bRPC involves a critical flaw within the Real-Time Messaging Protocol (RTMP) Adaptive Message Format (AMF) parser, specifically affecting deployments that enable the RTMP server component to accept traffic from untrusted sources. This issue allows remote, unauthenticated attackers to trigger excessive memory allocation or resource consumption by sending crafted AMF payloads with artificially inflated string lengths or array counts. The core technical flaw stems from a lack of input validation prior to resource commitment; specifically, the parser for long strings resizes the destination buffer based on the declared 32-bit length field before verifying that the incoming stream actually contains sufficient data bytes to fulfill that allocation. Similarly, parsers for ECMA arrays and strict arrays accept element counts defined by 32-bit integers without enforcing a configurable upper bound or sanity check against available system resources. This design oversight means that an attacker can request massive memory allocations with minimal network bandwidth usage, as the server attempts to allocate space for data that does not yet exist in the stream.
From an operational perspective, this vulnerability poses a significant risk of Denial of Service (DoS) against affected systems. By exploiting the pre-allocation behavior, an adversary can exhaust available heap memory or CPU cycles associated with parsing and buffer management, potentially causing service crashes or severe performance degradation for legitimate users. The attack vector is particularly dangerous because it requires no authentication and leverages standard RTMP traffic patterns, making it difficult to distinguish from benign activity without deep packet inspection or strict rate limiting. This aligns with Common Weakness Enumeration (CWE) categories such as CWE-789: Memory Allocation with Excessive Size Value and CWE-400: Uncontrolled Resource Consumption. Furthermore, the exploitation technique maps to MITRE ATT&CK tactics related to Impact, specifically resource hijacking or service disruption through application layer attacks.
The root cause is fundamentally a failure in input validation logic where trust assumptions are incorrectly applied to untrusted network inputs. The parser assumes that if an AMF header specifies a certain size, the subsequent data will match it, leading to premature memory allocation. This violates the principle of least privilege and secure coding standards which dictate that resource-intensive operations should only occur after full validation of input integrity and bounds. In environments where bRPC is exposed to public networks or untrusted internal segments, this flaw can be leveraged repeatedly to maintain persistent denial-of-service conditions without requiring high bandwidth, making it an efficient attack vector for malicious actors seeking to disrupt services.
To mitigate this vulnerability, organizations must upgrade Apache bRPC to version 1.18.0 or later, which implements the necessary fixes introduced in pull request #3353 on GitHub. The updated parser introduces configurable limits that enforce strict boundaries on resource consumption; by default, it restricts maximum string sizes to 64 MiB and array element counts to 1,048,576 elements. Any payload exceeding these thresholds is rejected before significant memory allocation occurs. Administrators can further tune these security controls using the amf_max_string_size and amf_max_array_size configuration parameters to align with their specific application requirements while maintaining a robust defense against excessive resource consumption attacks. Additionally, deploying network-level protections such as rate limiting or deep packet inspection for RTMP traffic can provide an additional layer of defense against exploitation attempts from untrusted clients.