CVE-2026-86249: Apache bRPC: Authentication bypass when a server sets ServerOptions.internal_port and ServerOptions.auth
On a brpc::Server that sets both ServerOptions.auth and ServerOptions.internalport, the HTTP built-in service exemption on internalport can be abused to bypass authentication entirely. VerifyHttpRequest() returns true without checking any credential when a built-in service is requested on internalport, and this verdict is not per - request: verification runs only for the first message of a connection and the result latches the connection. Sending a request such as GET /status to internalport first authenticates the whole connection, after which every subsequent request dispatched on the same connection is handled without ever calling VerifyHttpRequest(). This lets a remote attacker reach ordinary (non-built-in, non-tabbed) authenticated services without supplying valid credentials whenever the server uses ServerOptions.internalport together with an Authenticator. The fix restricts internalport so that it carries only built-in and Tabbed services; requests for ordinary services sent to internalport are rejected with EPREM / HTTP 403.
Mitigation / Fix: upgrade to 1.18.0 or apply PR https://github.com/apache/brpc/pull/3525 .
Users who rely on serving normal services on internalport must move those requests to the port passed to Server::Start().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Apache bRPCto a version that resolves this vulnerability.Fixed in 1.18.0 - Configuration
Move requests for normal services from internal_port to the port passed to Server::Start(); internal_port is restricted to built-in and Tabbed services.
Apache bRPC Server ServerOptions.internal_port
Event History
Frequently Asked Questions
Which deployments are exposed to this bypass?
A remotely reachable brpc::Server is affected when it configures both ServerOptions.auth and ServerOptions.internal_port, and ordinary authenticated services are available through that server. The issue relies on normal services being dispatched on internal_port.
What does an attacker need to do to bypass authentication?
The attacker must open a connection to internal_port and first request a built-in HTTP service, such as GET /status. That initial request is exempt from credential verification, and the successful result is then retained for subsequent requests on the same connection.
What should be done if upgrading is not immediately possible?
Apply the referenced PR if possible. Otherwise, avoid serving ordinary services on internal_port; the described fix enforces this by allowing only built-in and Tabbed services there and rejecting ordinary-service requests with EPERM or HTTP 403.