---
id: "CVE-2026-86249"
kind: "vulnerability"
aliases: ["CVE-2026-86249"]
title: "Apache bRPC: internal_port lets requests skip authentication on a shared connection"
severity: "high"
cvss: null
epss: 0.00325
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["brpc", "c++", "package", "self-hosted"]
not_affected_if: ["default-config", "no-internal-port"]
published_at: "2026-10-21T13:20:04+00:00"
first_seen_at: "2026-10-23T21:57:28+00:00"
updated_at: "2026-10-25T05:02:20+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-86249", "first_seen_at": "2026-10-23T21:57:28+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-86249", "first_seen_at": "2026-10-24T13:15:54+00:00"}]
---

# Apache bRPC: internal_port lets requests skip authentication on a shared connection

When a bRPC server sets both an Authenticator and internal_port, a request for a built-in page on internal_port marks the whole connection as authenticated. Later requests on that connection reach ordinary services without credentials.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Look for `ServerOptions.internal_port` and `ServerOptions.auth` set together in the server startup code
- Check the bRPC version in the build file or lockfile; unknown if the sources do not give a range

## Fix

- Upgrade bRPC to `1.18.0` or later
- Or apply the fix from PR https://github.com/apache/brpc/pull/3525
- Move normal service traffic off internal_port onto the port passed to Server::Start()

## Timeline

- 2026-10-23T21:57:28+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-86249
- 2026-10-24T13:15:54+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-86249

## From the sources

On a brpc::Server that sets both ServerOptions.auth and ServerOptions.internal_port, the HTTP built-in service exemption on internal_port can be abused to bypass authentication entirely. VerifyHttpRequest() returns true without checking any credential when a built-in service is requested on internal_port, 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 internal_port 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.internal_port together with an Authenticator. The fix restricts internal_port so that it carries only built-in and Tabbed services; requests for ordinary services sent to internal_port 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 internal_port must move those requests to the port passed to Server::Start().

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_