CVE-2026-84748 in bRPC
Summary
by MITRE • 10/21/2026
Improper authorization in Apache bRPC (versions < 1.18.0) on all platforms allows remote attackers to access builtin services through the public port.
Root Cause: ServerOptions.internal_port is documented to make builtin services (and Tabbed services) reachable only from the internal port, and the HTTP/h2 dispatch path enforced this. However, all protobuf-based protocol dispatch paths (baidu_std, hulu_pbrpc, sofa_pbrpc, and the nshead-based protocols public_pbrpc, nshead_mcpack, nova_pbrpc and ubrpc2pb) computed the security_mode flag but never enforced it between method resolution and method invocation. Since builtin services share the method map with user services, a client able to reach the public port could invoke builtin services such as brpc.vars or hotspots by name over these pb protocols and disclose sensitive runtime information (metrics, flags, profiler data) that the operator intended to expose only via the internal port.
Affected Scenarios: Use a bRPC server with ServerOptions.internal_port configured (or with builtin/Tabbed services otherwise expected to be gated by it) while the public port is reachable from an untrusted network and any pb-based protocol is enabled.
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/3511
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 improper authorization flaw that allows remote attackers to access internal builtin services through the public-facing network port. This issue stems from an inconsistency in how security modes are enforced across different protocol dispatch paths within the framework. While the HTTP and h2 protocols correctly restrict access to built-in services based on the ServerOptions.internal_port configuration, other protobuf-based protocols fail to apply this restriction effectively. The root cause lies in the method resolution logic for these specific protocols, including baidu_std, hulu_pbrpc, sofa_pbrpc, public_pbrpc, nshead_mcpack, nova_pbrpc, and ubrpc2pb. Although these paths compute a security_mode flag intended to distinguish between internal and external access contexts, they do not enforce this distinction before invoking methods. Consequently, any client capable of reaching the public port can invoke builtin services by name, bypassing the administrative boundary established by the operator.
This architectural oversight results in significant operational impact as it exposes sensitive runtime information that was explicitly intended to remain isolated from untrusted networks. Attackers leveraging this flaw can interact with internal endpoints such as brpc.vars and hotspots through standard protobuf-based RPC calls. These services provide detailed insights into the server's state, including performance metrics, configuration flags, profiler data, and other diagnostic information. The disclosure of such data facilitates further reconnaissance efforts, allowing adversaries to map the infrastructure, identify potential weaknesses in service configurations, and potentially plan more targeted attacks against the underlying application logic or dependent systems. This scenario is particularly dangerous when bRPC servers are deployed with internal ports configured for administrative tasks while simultaneously exposing public ports to external networks without adequate protocol-level filtering.
From a classification perspective, this vulnerability aligns with CWE-269, which denotes Improper Privilege Management, specifically regarding the failure to enforce authorization boundaries between different access contexts. It also maps to MITRE ATT&CK technique T1504, Weak or Missing Authentication, as it involves bypassing intended security controls through protocol-specific implementation gaps rather than a complete absence of authentication mechanisms. The flaw highlights the risk inherent in microservice architectures where internal communication channels are assumed secure but lack rigorous validation when exposed via shared code paths that handle both public and private traffic types.
To mitigate this vulnerability, organizations must take immediate action to either upgrade their Apache bRPC installations or apply specific patches addressing the dispatch logic inconsistency. The recommended solution is to upgrade to version 1.18.0 or later, which includes corrections ensuring that security modes are consistently enforced across all protocol handlers regardless of whether they utilize HTTP/h2 or protobuf-based protocols. Alternatively, if upgrading is not immediately feasible, administrators can apply a patch available via the Apache bRPC pull request number 3511 on GitHub. This patch modifies the method invocation logic to properly check and enforce internal access restrictions for builtin services across all affected protocol implementations. Additionally, network-level controls such as firewall rules should be reviewed to ensure that public ports are not inadvertently accessible from untrusted networks while relying solely on application-layer security measures.