CVE-2026-94300 is a high-severity vulnerability in ISC BIND 9 that involves a double free memory corruption triggered by replaying GSS-TSIG signed UDP messages. An attacker capable of capturing a previously signed UDP message can replay it while the TSIG key remains valid. By sending crafted queries to a zone controlled by the attacker, remote code execution may be possible. This affects multiple BIND 9 versions including 9.11.0 through 9.18.50, 9.20.0 through 9.20.29, and 9.21.0 through 9.21.26, including certain S1 variants.
CVE-2026-87849 is an out-of-bounds read vulnerability in Apache bRPC versions prior to 1.18.0. The issue arises because the Discovery naming-service reply parser uses RapidJSON object-only accessors on JSON values without verifying they are objects. Malformed Discovery responses with non-object entries can cause the bRPC client to read memory out of bounds and potentially crash. The vulnerability is fixed in version 1.18.0 by adding validation checks on JSON data before access.
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().
Apache bRPC versions prior to 1.18.0 contain vulnerabilities allowing remote attackers to control file paths and cause resource exhaustion. Attackers can exploit the builtin /flags service to create directories and overwrite files with server process privileges by manipulating dump path flags. Additionally, the /pprof service allows unbounded profiling durations, potentially causing denial of service by holding profiling resources indefinitely. These issues affect any bRPC server exposing builtin services to untrusted networks.
Apache bRPC versions prior to 1.18.0 contain an interpretation conflict in HTTP path handling that allows remote attackers to bypass access control rules enforced by a front proxy. This occurs because the server collapses consecutive slashes in request paths, treating distinct paths as equivalent, contrary to RFC 3986. Additionally, the HTTP/2 implementation fails to validate the :path pseudo-header properly, allowing malformed requests. These issues enable attackers to access resources that the front proxy intended to block.
Use-after-free in the RTMP protocol implementation in Apache bRPC (version < 1.18.0) on all platforms allows a malicious RTMP peer to crash the process or potentially corrupt memory via a crafted Abort message.
Root Cause:
When processing an RTMP Abort (protocol control message type 2), the RTMP policy implementation deleted the target RtmpChunkStream object. The send path (RtmpUnsentMessage::AppendAndDestroySelf -> RtmpChunkStream::SerializeMessage) runs concurrently on sender threads and dereferences the same RtmpChunkStream object without synchronization. If a remote peer sends an Abort message naming a chunk stream that is concurrently being used to serialize an outgoing message, the stream object is freed while still in use, resulting in a use-after-free. Additionally, deleting the chunk stream discarded its previous message header, so subsequent compressed (type-3) chunk headers on that stream could no longer be decoded.
Affected Scenarios:
Any application using the bRPC RTMP protocol implementation (rtmp policy), either as an RTMP server or as an RTMP client, where the remote endpoint is untrusted. The attacker needs to send an Abort message targeting a chunk stream id that is concurrently used for sending, which can crash the process or lead to memory corruption.
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/3515
CVE-2026-82953 is a medium-severity vulnerability in Apache bRPC versions prior to 1.18.0. It involves a NULL pointer dereference in the RTMP protocol implementation that can be triggered remotely by sending a crafted createStream command and then closing the connection prematurely. This causes the server process to crash, resulting in a denial of service.
A race condition vulnerability (CWE-362) exists in Apache bRPC versions prior to 1.18.0 when RDMA support is enabled. This flaw allows a remote unauthenticated client to cause a denial of service by crashing the server process due to improper synchronization of shared input buffers during RDMA handshake and message processing. The issue occurs only if the server is built and run with RDMA enabled and accepts connections from untrusted clients. Upgrading to version 1.18.0 or applying the provided patch mitigates the vulnerability.
A reachable assertion in Apache bRPC (version < 1.18.0) on all platforms allows a malicious remote peer to crash the process, resulting in denial of service.
Root Cause:
When a Socket with health checking enabled fails, Socket::WaitAndReset closes its file descriptor while the event dispatcher may still be delivering an input event (EPOLLIN/EVFILT_READ) that was fetched for the just-closed fd. If the health check then succeeds and revives the Socket, Socket::Address succeeds again while the fd is still -1 (the next write reconnects on demand). In that window, Socket::OnInputEvent hits CHECK(!(events & EPOLLIN)) (or the kqueue equivalent) because the Socket is addressable but has no fd. CHECK failures terminate the process when bRPC is built with glog or when the gflag -crash_on_fatal_log is enabled (CHECK always terminates in OFFICIAL_BUILD/NDEBUG builds as well).
Affected Scenarios:
Applications using bRPC clients with health check enabled (-health_check_interval). A malicious remote peer that the client connects to can deliberately abort connections and immediately accept the health check probes, racing connection teardown against health check revival to trigger the assertion and abort the process.
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/3510
Note:
After applying the fix, stale input events on a Socket revived without an fd are silently dropped instead of triggering the assertion. No user-visible interface or wire protocol is changed.
A Thrift client in Apache bRPC (version < 1.18.0, built with WITH_THRIFT which is off by default) can be crashed by the server peer it talks to. When the server returns a T_EXCEPTION reply whose exception struct is malformed, the client decodes it without catching what Apache Thrift throws (TProtocolException, TTransportException or std::length_error). The exception unwinds out of the bthread task function and the process calls std::terminate(), terminating the whole process along with every other in-flight RPC.
This is the client response path, so the adversary is the server peer, which THREAT_MODEL.md treats as untrusted. It requires a WITH_THRIFT build (off by default).
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/3500
Uncontrolled recursion in the mcpack2pb component in Apache bRPC (version < 1.18.0) on all platforms allows remote attackers to make the server crash via sending deeply nested mcpack data.
Root Cause:
The bRPC mcpack2pb parser (used to serve nshead_mcpack / ubrpc / public_pbrpc requests) recursively parses nested objects and arrays without any depth limit. For a protobuf message that references itself (e.g. a repeated message field), the generated parser recurses once per nesting level of the incoming mcpack object. A deeply nested request makes the recursion grow unbounded, overflow the stack and crash the process.
Affected Scenarios:
Use bRPC server with a recursive-schema protobuf message to serve nshead_mcpack / ubrpc / public_pbrpc requests from untrusted network.
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/3499
Note:
No matter which option you choose, you should know that the fix enforces the documented parsing depth limit MAX_DEPTH (128) on the parse path, the same limit the serializer already applies. If your requests contain mcpack messages nested deeper than 128 levels, the request will be failed after applying the fix.
Enforceable assertion in the streaming feature of Apache bRPC (version < 1.18.0) on all platforms allows a remote attacker to crash the server process by sending a malformed stream feedback frame.
Root Cause:
When handling FRAME_TYPE_FEEDBACK frames, bRPC calls Stream::SetRemoteConsumed() which contains CHECK(_cur_buf_size > 0) and unconditionally asserts CHECK(buf.IsEmpty()) on the frame payload. A feedback frame that carries an unexpected payload, or a feedback frame received on a stream where flow control is disabled (cur_buf_size == 0), reaches these assertions. On failure, CHECK failures abort the process, allowing an unauthenticated single client (once a stream is established) to terminate the server and cause a denial of service.
Affected Scenarios:
Use bRPC server with the streaming control feature (Stream API) served from untrusted network.
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/3494
The fix rejects malformed feedback frames with EPROTO and closes only the affected stream instead of crashing the whole process, and it bounds buffer shrinking so cur_buf_size never drops to 0 while flow control is enabled.
Apache bRPC versions prior to 1.18.0 contain a vulnerability where unbounded memory accumulation occurs in the stream message reassembly process. Remote attackers can exploit this by sending an endless sequence of continuation data frames, causing the server to exhaust memory and potentially crash or become unavailable. The issue arises because fragmented stream messages accumulate continuation frames without limits, and default flow-control settings do not throttle the sending rate. The vulnerability affects services accepting streams from untrusted clients using the built-in streaming protocol. The issue is fixed in version 1.18.0 by limiting the accumulated payload to max_body_size (default 64MB), closing streams that exceed this limit with an error. Adjusting max_body_size is possible to accommodate legitimate large messages.
Apache bRPC versions prior to 1.18.0 have a missing authentication vulnerability in the streaming RPC path. This flaw allows remote attackers to bypass server authentication and inject or deliver streaming frames when the server is configured with an Authenticator. The issue arises because streaming RPC frames bypass the authentication hook, enabling unauthenticated peers to exchange frames. The vulnerability affects servers configured with authentication that serve streaming RPC from untrusted networks or where foreign connections can impersonate streams by ID. The issue is fixed in version 1.18.0.
Apache bRPC versions before 1.18.0 have a vulnerability where the client TLS peer verification validates the server certificate chain but does not verify that the certificate matches the expected DNS name or IP address. This allows a network attacker with a valid certificate for a different name to impersonate the intended TLS endpoint. The issue is fixed in version 1.18.0 by enabling proper hostname verification during the TLS handshake.
CVE-2026-56388 is an out-of-bounds write vulnerability in Apache bRPC's Redis server command parser. It occurs when the parser accepts an empty RESP array as a command header, allowing a remote unauthenticated attacker to cause a crash by sending a malformed command. The issue affects deployments with Redis service enabled that accept Redis protocol traffic from untrusted clients. The vulnerability is fixed in bRPC version 1.18.0.
CVE-2026-56387 is a vulnerability in Apache bRPC's RTMP AMF parser where untrusted input can specify excessive string lengths or array counts, leading to excessive memory allocation or resource consumption. This affects deployments with the bRPC RTMP server enabled and accepting RTMP traffic from untrusted clients. The issue is fixed in Apache bRPC version 1.18.0 by introducing configurable limits on AMF string size and array element count.
Integer underflow and out-of-bounds read in the HTTP/2 server DATA frame parser in Apache bRPC allows an unauthenticated remote attacker to cause denial of service by sending a malformed DATA frame with the PADDED flag set and a zero-length payload.
Root Cause:
The HTTP/2 DATA frame handler computed the fragment size from the attacker-controlled payload length and, when the PADDED flag was present, decremented the fragment size before ensuring that the frame contained the mandatory pad length byte. A zero-length padded DATA frame could therefore underflow the unsigned fragment size and read the pad length byte past the end of the frame buffer.
Affected Scenarios:
Apache bRPC servers that accept HTTP/2 traffic are affected when a remote client can send crafted HTTP/2 frames to the server. HTTP/2 may be reached through cleartext h2c detection on an HTTP port or through TLS ALPN negotiation.
How to Fix:
(Choose one of the following options)
1. Upgrade Apache bRPC to version 1.18.0, which fixes this issue.
2. Apply this patch: https://github.com/apache/brpc/pull/3325
Note:
The fix validates that a padded DATA frame has enough payload bytes for the pad length field before decrementing the fragment size or reading the pad length byte. Malformed zero-length padded DATA frames are rejected with HTTP/2 FRAME_SIZE_ERROR.
Apache bRPC versions up to 1.17.0 contain an improper authentication vulnerability that allows remote unauthenticated attackers to bypass authentication on protected non-builtin HTTP endpoints. This occurs when ServerOptions.auth is enabled and builtin HTTP services are exposed on the public listener. An attacker can send a builtin HTTP request first on an HTTP/1.1 keep-alive connection, causing the connection to be treated as authenticated for subsequent requests. The issue is fixed in Apache bRPC version 1.18.0.