{ "from_raw": "Weibing Wang ", "from": "Weibing Wang ", "gravatar": "3cae01a7b21fec8e241965f32765e206", "to": "an...@apache.org,\n de...@brpc.apache.org", "subject": "Apache bRPC security advisory: 35 vulnerabilities fixed in 1.18.0", "message-id": "", "mid": "2pf15ojj0vr7rtx95677kgtl1mx3gdgb", "permalinks": [ "2pf15ojj0vr7rtx95677kgtl1mx3gdgb", "rce269394a2ed1d4d783cfa66d728462178fe3278de7aadad9ae579af@" ], "dbid": "deb1747e2db682ef3d2015fb61d2ddf4073a8bc18c732078d8839b8c16e3e95b", "cc": "", "epoch": 1792551616, "list": "", "list_raw": "", "date": "2026/10/21 03:00:16", "private": false, "references": "", "in-reply-to": "", "body": "Hi, all\n\nWe have released the Apache bRPC 1.18.0, with 35 vulnerabilities fixed\n(16 high, 19 moderate) . The vulnerabilities descriptions are below:\n\n### CVE-2026-48830: Apache bRPC: HTTP builtin request can mark a\nconnection authenticated and bypass auth for later requests\n\nSeverity: high\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nImproper authentication in Apache bRPC through 1.17.0 allows a remote\nunauthenticated attacker to bypass authentication for protected\nnon-builtin HTTP endpoints by first sending a builtin HTTP request on\nthe same HTTP/1.1 keep-alive connection.\n\nWhen ServerOptions.auth is enabled and builtin HTTP services are\nexposed on the public listener, a builtin request received as the\nfirst message on a socket may cause the connection to be treated as\nauthenticated for later requests on that socket. Users are recommended\nto upgrade to version 1.18.0, which fixes this issue, or apply this PR\nseparately: https://github.com/apache/brpc/pull/3308\n\nCredit:\n\nBrubbish of VARAS@IIE (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-48830\n\n### CVE-2026-54425: Apache bRPC: Stack Exhaustion via Recursive HPACK\nDynamic Table Size Update Decoding\n\nSeverity: high\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nUncontrolled recursion in the HTTP/2 HPACK decoder in Apache bRPC\nbefore 1.18.0 allows remote attackers to cause denial of service by\nsending a crafted HTTP/2 header block containing many consecutive\nDynamic Table Size Update entries. Each update was decoded by\nrecursively invoking the HPACK decoder, which could exhaust the thread\nstack before a header field or end of input was reached.\n\nRoot Cause:\nThe bRPC HPACK decoder recursively decoded the next entry after\nprocessing a Dynamic Table Size Update. The decoder did not bound the\nrecursion depth, so a long sequence of update entries could consume\nexcessive stack space.\n\nAffected Scenarios:\nUse bRPC with the built-in HTTP/2 implementation to accept HTTP/2\ntraffic from an untrusted network.\n\nHow to Fix:\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3343\n\nNote:\nThe fix changes HPACK Dynamic Table Size Update decoding to use\niterative parsing instead of recursive parsing.\n\nCredit:\n\n\u9ec4\u5b8f\u6d0b(Huang Hongyang) (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-54425\n\n### CVE-2026-54426: Apache bRPC: Stack Exhaustion via Unbounded\nRecursion in Redis Reply Parser\n\nSeverity: high\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nUncontrolled recursion in the Redis reply parser in Apache bRPC <\n1.18.0 allows a remote Redis server peer to crash a bRPC Redis client\nprocess by returning a deeply nested RESP array reply. The parser\nrecursed once for each nested array level without enforcing a depth\nlimit. The fix adds a configurable Redis reply depth limit with\ndefault value 128 and rejects replies exceeding that limit.\n\nAffected Scenarios:\nApplications using bRPC as a Redis client with\nChannelOptions.protocol=\"redis\" and receiving replies from an\nuntrusted or faulty Redis server peer.\n\nHow to Fix:\n1. Upgrade Apache bRPC to 1.18.0.\n2. Apply the patch from PR https://github.com/apache/brpc/pull/3344 .\n\nNote:\nAfter applying the fix, Redis replies with array nesting deeper than\nredis_max_reply_depth are rejected.\n\nCredit:\n\nNikko Enggaliano Pratama (nikkoenggaliano@gmail.com) on Github (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-54426\n\n### CVE-2026-54427: Apache bRPC: Stack Exhaustion via Unbounded\nRecursion in AMF Parser\n\nSeverity: high\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nUncontrolled recursion in the AMF parser in Apache bRPC < 1.18.0\nallows a remote RTMP peer to crash a bRPC process by sending deeply\nnested AMF objects or arrays. The parser recursively processed nested\nAMF containers without enforcing a depth limit, which could exhaust\nthe native stack.\n\nAffected Scenarios:\nApplications using bRPC RTMP support and parsing AMF data from an\nuntrusted RTMP peer. This includes RTMP servers parsing client command\nmessages, RTMP clients parsing server responses or status messages,\nand either side parsing inbound AMF script data such as metadata or\ncue points. Direct callers of ReadAMFObject or ReadAMFArray on\nuntrusted input are also affected.\n\nHow to Fix:\n1. Upgrade Apache bRPC to 1.18.0.\n2. Apply the patch from PR https://github.com/apache/brpc/pull/3344 .\n\nNote:\nThe fix introduces a configurable AMF nesting depth limit with default\nvalue 128. AMF objects or arrays deeper than amf_max_depth are\nrejected after applying the fix.\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-54427\n\n### CVE-2026-56386: Apache bRPC: Integer Underflow and Out-of-Bounds\nRead in HTTP/2 DATA Frame Parser\n\nSeverity: high\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nInteger underflow and out-of-bounds read in the HTTP/2 server DATA\nframe parser in Apache bRPC allows an unauthenticated remote attacker\nto cause denial of service by sending a malformed DATA frame with the\nPADDED flag set and a zero-length payload.\n\nRoot Cause:\nThe HTTP/2 DATA frame handler computed the fragment size from the\nattacker-controlled payload length and, when the PADDED flag was\npresent, decremented the fragment size before ensuring that the frame\ncontained the mandatory pad length byte. A zero-length padded DATA\nframe could therefore underflow the unsigned fragment size and read\nthe pad length byte past the end of the frame buffer.\n\nAffected Scenarios:\nApache bRPC servers that accept HTTP/2 traffic are affected when a\nremote client can send crafted HTTP/2 frames to the server. HTTP/2 may\nbe reached through cleartext h2c detection on an HTTP port or through\nTLS ALPN negotiation.\n\nHow to Fix:\n(Choose one of the following options)\n1. Upgrade Apache bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3325\n\nNote:\nThe fix validates that a padded DATA frame has enough payload bytes\nfor the pad length field before decrementing the fragment size or\nreading the pad length byte. Malformed zero-length padded DATA frames\nare rejected with HTTP/2 FRAME_SIZE_ERROR.\n\nCredit:\n\nNikko Enggaliano Pratama (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-56386\n\n### CVE-2026-56387: Apache bRPC: Remote Memory Exhaustion in RTMP AMF Parser\n\nSeverity: high\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nThe RTMP AMF parser in Apache bRPC accepts AMF string lengths and\narray counts directly from untrusted input. A remote unauthenticated\nattacker who can reach a bRPC server with RTMP enabled can send a\nsmall AMF payload with an excessive declared long string length or\narray count, causing excessive memory allocation or resource\nconsumption before the parser rejects the incomplete payload.\n\nRoot Cause:\nThe AMF long string parser resized the destination string to the\ndeclared 32-bit length before validating that the stream contained\nthat many bytes. ECMA array and strict array parsers also accepted\n32-bit element counts without a configurable upper bound.\n\nAffected Scenarios:\nDeployments that enable the bRPC RTMP server component and accept RTMP\ntraffic from untrusted clients. Direct uses of the AMF parser on\nuntrusted data are also affected.\n\nHow to Fix:\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3353\n\nNote:\nThe fix introduces configurable AMF parsing limits. The default\nmaximum string size is 64 MiB and the default maximum array element\ncount is 1,048,576. Payloads above these limits are rejected. The\nlimits can be adjusted with amf_max_string_size and\namf_max_array_size.\n\nCredit:\n\nNikko Enggaliano Pratama (finder)\n73Lab of Qingteng.cn (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-56387\n\n### CVE-2026-56388: Apache bRPC: Out-of-Bounds Write in Redis Command Parser\n\nSeverity: high\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nThe Redis server command parser in Apache bRPC accepts an empty RESP\narray as a command header. A remote unauthenticated attacker who can\nreach a bRPC server with Redis service enabled can send an empty array\nheader followed by a bulk string, causing an out-of-bounds write in\nthe parser and crashing the process.\n\nRoot Cause:\nRedisCommandParser::ConsumeImpl rejected negative RESP array counts\nbut accepted zero. It resized the command argument vector to zero\nelements and continued parsing. When a following bulk string was\nparsed, the only index guard was a CHECK. In configurations where\nfatal logs do not abort immediately, execution could continue and\nwrite to _args[0] even though the vector was empty.\n\nAffected Scenarios:\nDeployments that enable ServerOptions.redis_service and accept Redis\nprotocol traffic from untrusted clients. The issue is reached during\nparsing before command handling or authentication.\n\nHow to Fix:\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3354\n\nNote:\nThe fix rejects empty RESP arrays as invalid Redis commands and\nreplaces the internal index CHECK with an explicit parse error so\nmalformed command streams cannot fall through to an indexed vector\nwrite.\n\nCredit:\n\nNikko Enggaliano Pratama (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-56388\n\n### CVE-2026-58064: Apache bRPC: Denial of Service via Unbounded Redis\nInline Command Allocation\n\nSeverity: high\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nThe Redis protocol implementation in Apache bRPC allowed inline\ncommand parsing to allocate and copy the full connection buffer before\na complete CRLF-terminated command was available. A remote attacker\nwith access to a Redis-protocol bRPC service could send long inline\ninputs without a terminating CRLF to increase memory usage and CPU\ncopy overhead, potentially causing denial of service.\n\n\nRoot Cause:\nThe Redis inline command parser allocated memory based on the current\ninput buffer size and copied the entire buffer before determining the\ncurrent inline command boundary. The existing\nredis_max_allocation_size limit was applied to RESP bulk strings and\narrays, but not effectively to the inline command path before\nallocation.\n\n\nAffected Scenarios:\nUse Apache bRPC server with Redis protocol enabled and reachable by\nuntrusted clients.\n\n\nHow to Fix:\n1. Upgrade Apache bRPC to version 1.18.0, which fixes this issue.\n2. Apply the patch from PR https://github.com/apache/brpc/pull/3363 .\n\n\nNote:\nThe fix applies redis_max_allocation_size to Redis inline command\nlines and scans for CRLF before allocating parser arena memory. Inline\ncommand lines exceeding this limit are rejected.\n\nCredit:\n\n73Lab of Qingteng.cn (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-58064\n\n### CVE-2026-61902: Apache bRPC: Memory Exhaustion Through\nInconsistent Message Body Limits\n\nSeverity: medium\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nApache bRPC versions before 1.18.0 do not consistently enforce the\nconfigured max_body_size limit in non-progressive HTTP/1 and HTTP/2\nparsing and in memcache and couchbase response parsing.\n\nA remote unauthenticated peer can cause an affected process to buffer\nmessage data beyond the configured limit, which may lead to memory\nexhaustion and denial of service.\nUsers should upgrade to 1.18.0 or apply the patch from PR\nhttps://github.com/apache/brpc/pull/3382 . The fix rejects oversized\nbuffered HTTP bodies, returns HTTP 413 for HTTP/1 requests, resets\noversized HTTP/2 streams, and rejects oversized memcache and couchbase\nresponses from their declared lengths. Progressive HTTP reading\nremains supported because it uses bounded buffering.\n\nCredit:\n\nBeaCox (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-61902\n\n### CVE-2026-61916: Apache bRPC: Out-of-bounds Read in URL and Header\nLookup Tables on Unsigned-char Platforms\n\nSeverity: moderate\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nOut-of-bounds reads in URL parsing and case-insensitive header lookup\nin Apache bRPC before version 1.18.0 on platforms where plain char is\nunsigned, such as ARM64, allow remote attackers to cause a process\ncrash and denial of service by sending crafted input containing bytes\nwith the high bit set.\n\nRoot Cause:\nTwo 256-entry lookup tables are accessed through pointers biased by\n128 so that valid indices are in the range -128 to 127. Input bytes\nare promoted from plain char to int without first normalizing them to\nthe signed-char range. On affected platforms, bytes in the range 0x80\nto 0xFF therefore become indices 128 to 255 and read up to 127 bytes\nbeyond the end of the underlying tables.\n\nAffected Scenarios:\nA remotely accessible bRPC HTTP server on an affected platform can\nreach the vulnerable URL lookup through an unauthenticated request URI\ncontaining a high-bit byte. The case-insensitive lookup is also\nreachable when untrusted header names are processed through APIs such\nas the HTTP/2 HPACK path. HTTP/1 header names containing high-bit\nbytes are rejected by the HTTP/1 parser before reaching the vulnerable\nlookup. Builds where plain char is signed, which commonly include\nx86_64 builds, are not affected by this issue.\n\nHow to Fix:\nChoose one of the following options:\n1. Upgrade Apache bRPC to version 1.18.0 or later.\n2. Apply the patch from https://github.com/apache/brpc/pull/3376 .\n\nThe fix normalizes lookup-table indices to the signed-char range\nbefore accessing the biased tables.\n\nCredit:\n\nUbeddulla Khan (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-61916\n\n### CVE-2026-66392: Apache bRPC: TLS Client Accepts Certificates for\nMismatched Peer Names\n\nSeverity: medium\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nApache bRPC versions before 1.18.0 validate the server certificate\nchain when client TLS peer verification is enabled, but do not bind\nthe certificate to an expected DNS name or IP address. A network\nattacker who can redirect or intercept a connection and who possesses\na certificate issued by a CA trusted by the client for another name\nmay impersonate the requested TLS endpoint.\n\n\nAffected Scenarios:\nApplications use a bRPC client Channel to connect to an untrusted\nnetwork with certificate verification enabled and trust a CA that can\nissue certificates for identities other than the intended endpoint.\n\n\nHow to Fix:\nUpgrade to Apache bRPC 1.18.0 and enable VERIFY_PEER with a positive\nverify_depth. HTTPS Channels automatically verify the certificate\nagainst the host in the Channel URL. Callers may set\nVerifyOptions::expected_peer_name explicitly when the certificate\nidentity differs from the URL host. Alternatively, apply the patch\nfrom https://github.com/apache/brpc/pull/3408 .\n\nNote:\nThe new option performs DNS SAN or IP SAN verification during the TLS\nhandshake. Configurations that set expected_peer_name while peer\nverification is disabled are rejected.\n\nCredit:\n\nZenDuk (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-66392\n\n### CVE-2026-74755: Apache bRPC: Integer Underflow in mcpack2pb Parser\nLeading to Denial of Service\n\nSeverity: moderate\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nAn integer underflow in the mcpack2pb component of Apache bRPC\n(version < 1.18.0) on all platforms allows remote attackers to crash a\nbRPC server by sending a request containing a string field with a zero\nvalue_size. The UnparsedValue::as_string() function computes `_size -\n1` without validating `_size`; when value_size is 0 the expression\nunderflows to SIZE_MAX, resize() throws std::length_error, and because\nthe exception is not caught on the request parsing path the process\naborts (SIGABRT).\n\nRoot Cause:\nIn src/mcpack2pb/parser.cpp, UnparsedValue::as_string() resizes the\noutput string to `_size - 1`, where `_size` is the value_size of a\nstring field taken directly from the network data. A value_size of 0\nunderflows the unsigned size_t, and the subsequent resize() throws an\nexception that is not caught.\n\nAffected Scenarios:\nbRPC servers that accept nshead frames wired to the ubrpc mcpack2\nadaptor (for example the NsheadService + UbrpcMcpack2Adaptor\ndeployment pattern) can be crashed by a single unauthenticated\nrequest. Stock open-source bRPC registers the ubrpc/nshead_mcpack\nprotocols as client-only, so default server configurations are not\naffected.\n\nHow to Fix:\n1. Upgrade bRPC to a version that includes this fix.\n2. Apply the patch in PR https://github.com/apache/brpc/pull/3450\n\nCredit:\n\nFeng Zhijie (Independent security researcher) (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-74755\n\n### CVE-2026-74757: Apache bRPC: Uncontrolled Memory Allocation via\nMalicious mcpack Array Item Count\n\nSeverity: high\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nUncontrolled resource allocation in the mcpack2pb component in Apache\nbRPC (version < 1.18.0) on all platforms allows remote attackers to\nmake the server allocate a large amount of memory via sending a\ncrafted mcpack request with a huge array item count.\n\nRoot Cause:\nThe bRPC mcpack2pb parser trusts the item count stored in the mcpack\narray header without validating it against the actual payload size.\nThe code generated by the mcpack2pb protoc plugin uses this count to\npreallocate memory for repeated protobuf fields via Reserve(). A\nmalformed request declaring item_count = 0x7fffffff can force the\nserver to preallocate about 16GB of virtual memory, which may abort\nthe process (SIGABRT) on memory-constrained hosts.\n\nAffected Scenarios:\nUse a bRPC server that wires a NsheadService to UbrpcMcpack2Adaptor\n(the Baidu ubrpc deployment pattern) and parses requests with code\ngenerated by the mcpack2pb protoc plugin. The request body is parsed\nbefore authentication.\n\nHow to Fix:\n(Choose one of the following options)\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3451\n\nNote:\nNo matter which option you choose, you should know that the fix caps\nthe array item count to the remaining bytes of the array payload.\n\nCredit:\n\nFeng Zhijie (Dopamine) (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-74757\n\n### CVE-2026-74758: Apache bRPC: Heap Use-After-Free in RTMP Abort\nMessage Handling\n\nSeverity: high\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nA heap use-after-free in the RTMP protocol component of Apache bRPC\n(versions < 1.18.0) allows a remote attacker to crash a bRPC RTMP\nserver by sending a crafted Abort control message. No authentication\nor application-level request is required.\n\nRoot Cause:\nWhen an RTMP Abort control message names the chunk stream that is\ncurrently being parsed (the chunk stream carrying the message itself),\nRtmpChunkStream::OnAbortMessage calls RtmpContext::ClearChunkStream,\nwhich deletes the RtmpChunkStream while its Feed() is still running.\nAfter the message handler returns, Feed() continues to access members\nof the deleted object, resulting in a heap-use-after-free.\n\nAffected Scenarios:\nbRPC servers that enable RTMP support (ServerOptions.rtmp_service set)\nand accept connections from untrusted networks.\n\nHow to Fix:\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3452\n\nThe fix skips clearing the chunk stream when the Abort message targets\nthe chunk stream that is currently being parsed.\n\nCredit:\n\nFeng Zhijie (Dopamine) (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-74758\n\n### CVE-2026-78048: Apache bRPC: Remote Denial of Service via\nOut-of-Bounds Dynamic Table Sizing in HPACK Decoder\n\nSeverity: high\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nA reachable-assertion flaw in the HPACK header-compression decoder of\nthe HTTP/2 (h2/gRPC) stack in Apache bRPC (version < 1.18.0) on all\nplatforms allows a remote attacker to crash the server process by\nsending a crafted sequence of HPACK headers, resulting in a denial of\nservice.\n\nRoot Cause:\nIn src/brpc/details/hpack.cpp, IndexTable::Init sizes the\ndynamic-table ring buffer as num_headers = max_size / (32 + 2), i.e.\nit assumes a minimum table entry of 34 bytes (name >= 1 byte + value\n>= 1 byte + 32 bytes of overhead). However, RFC 7541 section 4.1\nspecifies that the minimum entry size is 33 bytes, because the value\nmay be empty (name >= 1 byte + value == 0 + 32 bytes). For the default\n4096-byte table this allocates only 120 slots (4096/34). Eviction in\nAddHeader is driven by byte usage (_max_size), not by slot count, so a\npeer can add 121 minimal 33-byte entries (121*33 = 3993 <= 4096)\nwithout triggering eviction. The 121st AddHeader then hits\nCHECK(!_header_queue.full()), which aborts the process.\n\nAffected Scenarios:\nUse a bRPC server that serves HTTP/2 or gRPC requests (e.g. via the h2\nprotocol) from an untrusted network. The malicious header block is\nprocessed during HPACK decoding of incoming requests without\nauthentication.\n\nHow to Fix:\n(Choose one of the following options)\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3462\n\nNote:\nThe fix sizes the dynamic table for the 33-byte minimum entry\n(max_size / (32 + 1)) and ensures at least one ring-buffer slot is\nkept when max_size is smaller than the minimum entry, so that\ninitialization cannot fail on malloc(0).\n\nCredit:\n\nubeddulla khan (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-78048\n\n### CVE-2026-78058: Apache bRPC: Unbounded Resource Consumption and\nCrash in the HTTP/2 Receive Path\n\nSeverity: high\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nUncontrolled resource consumption in the HTTP/2 (h2) receive path of\nApache bRPC (version < 1.18.0) on all platforms allows a remote\nunauthenticated attacker to crash the server or grow its memory\nwithout bound by sending crafted HTTP/2 frames.\n\nRoot Cause:\nThe h2 parser, enabled by default on every bRPC server port and used\nby h2/gRPC clients, trusts the peer to respect receive-side limits\nthat bRPC advertises but never enforces:\n1. SETTINGS_MAX_CONCURRENT_STREAMS defaulted to unlimited and was\nnever checked on the server, letting a peer pin an unbounded number of\npending streams per connection (~100x memory amplification).\n2. SETTINGS_MAX_HEADER_LIST_SIZE defaulted to unlimited and was never\nenforced; 1-byte HPACK indexed references amplify a small HEADERS\nframe ~4000x into an unbounded decoded header list (\"HPACK bomb\"), and\na never-completed HEADERS/CONTINUATION block accumulates memory\nwithout limit.\n3. Control-frame acks (PING/SETTINGS acks, RST_STREAM, GOAWAY,\nWINDOW_UPDATE) unconditionally bypassed the\n-socket_max_unwritten_bytes write cap, so a PING flood combined with\nwithheld TCP reads grew the connection buffer without the documented\nbound.\n4. The HPACK dynamic table size update was validated against the\nprotocol default (4096) instead of the advertised\nSETTINGS_HEADER_TABLE_SIZE, which together with the dynamic-table\nqueue/accounting issue can desynchronize the decoder and dereference\nNULL (crash).\n\nAffected scenarios:\nAny bRPC server serving HTTP/h2/gRPC to an untrusted network, and any\nbRPC h2/gRPC client connecting to an untrusted backend. The h2 parser\nruns before any Authenticator check on the shared port.\n\nHow to fix:\nUpgrade bRPC, or apply the patch in https://github.com/apache/brpc/pull/3474.\n\nNote:\nAfter applying the fix the following limits are enforced by default:\n- max_concurrent_streams: 1024 per connection (4294967295 restores unlimited).\n- max_header_list_size: 1 MiB decoded size per stream (4294967295\nrestores unlimited; -h2_client_max_header_list_size for clients).\n- h2 control-frame acks respect -socket_max_unwritten_bytes\n(-h2_ack_ignore_eovercrowded restores the old behavior).\nRequests exceeding these limits are rejected\n(RST_STREAM(REFUSED_STREAM) or a connection error).\n\nCredit:\n\nClaude (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-78058\n\n### CVE-2026-78066: Apache bRPC: Resource Exhaustion via Unbounded\nDecompression and Unvalidated Wire-Declared Sizes\n\nSeverity: high\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nResource exhaustion in Apache bRPC (version < 1.18.0) on all\nplatforms: multiple parsers that accept wire-controlled input bound no\nlimit on the sizes declared by the client or on decompressed output,\nwhich attackers can use to drive disproportionate memory use and crash\nthe process.\n\nRoot Cause:\n1) The gzip/zlib/snappy decompressors enforce no output limit:\n-max_body_size is checked against the compressed bytes only, so a\ncap-compliant body (e.g. 64 MiB) can decompress to tens of GiB.\n2) The AMF string readers allocate the declared length before the\nbytes are actually available.\n3) RTMP chunk headers may re-declare a message length mid-stream; the\ndeclared length was never bounded and the partial reassembly buffer\nkept growing.\n4) The sofa-pbrpc parser does not bound meta_size.\n5) mcpack2pb trusts wire-declared item counts for Reserve() and a\nstring value_size of 0 underflows the buffer size, aborting the\nprocess.\n\nAffected Scenarios:\nAny bRPC service accepting gzip/zlib/snappy-compressed bodies or rtmp,\nsofa-pbrpc, or mcpack2pb messages from untrusted clients.\n\nHow to Fix:(Choose one of the following options) 1. Upgrade bRPC to\nversion 1.18.0, which fixes this issue.\n\n2. Apply this patch: https://github.com/apache/brpc/pull/3476\n\nNote:\nAfter the fix, requests whose decompressed size, RTMP message length,\nor mcpack declared count exceed the new limits are rejected. Operators\nwho legitimately need larger values can raise the corresponding flag\n(-max_decompressed_body_size, max_body_size).\n\nCredit:\n\nClaude (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-78066\n\n### CVE-2026-78334: Apache bRPC: Missing Authentication for Streaming RPC Frames\n\nSeverity: medium\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nMissing authentication in the streaming RPC path of Apache bRPC\n(version < 1.18.0) on all platforms allows a remote attacker to bypass\nserver authentication and inject or deliver streaming frames, when a\nserver is configured with an Authenticator.\n\nRoot Cause:\nWhen authentication is configured, streaming RPC frames are consumed\ndirectly by the streaming parser (ParseStreamingMessage) and never\npass through InputMessenger's authentication hook, so an\nunauthenticated peer can exchange frames without being authenticated.\nIn addition, a server-accepted stream is bound lazily to the first\nframe that happens to carry its id, so a stream could accept a frame\ncarrying its id from a socket other than the socket that created the\nstream.\n\nAffected Scenarios:\nA bRPC server configured with authentication that serves streaming RPC\nfrom an untrusted network, or a deployment where a foreign connection\ncan impersonate a stream by id, can be made to accept unauthorized\nstreaming frames.\n\nHow to Fix:\nUpgrade bRPC to 1.18.0, which fixes this issue, or apply the patch in\nPR https://github.com/apache/brpc/pull/3481.\n\nNote:\nThe fix rejects streaming frames on server sockets when configured\nauthentication has not completed, and keeps server-accepted streams\nbound to the socket of their creating RPC and rejects frames arriving\nfrom another socket. Authenticated streaming RPC behavior and the wire\nformat are unchanged; only unauthenticated or foreign-socket frames\nare now rejected.\n\nCredit:\n\nClaude (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-78334\n\n### CVE-2026-79704: Apache bRPC: Out-of-bounds Read in Multi-stream\nRPC Response Handling\n\nSeverity: medium\n\nAffected versions:\n\n- Apache bRPC (brpc) 1.11.0 through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nAn out-of-bounds read vulnerability exists in the streaming RPC client\nof Apache bRPC (versions 1.11.0 through 1.17.0) on all platforms. A\nclient that creates multiple streams in a single RPC expects the\nserver response to carry exactly one extra_stream_id for every\nadditional stream. The response handling path indexed the returned\nidentifiers using the locally created stream count without first\nvalidating the size of the returned list, so a malicious or\ncompromised server (or an on-path attacker) can trigger an\nout-of-bounds read in the client by returning a malformed\nStreamSettings response with fewer extra_stream_ids than expected.\nThis may crash the client process (denial of service) or leak\nunintended memory contents into subsequent stream handling; surplus\nidentifiers have no valid client-stream mapping and are processed\ninconsistently.\n\nRoot Cause:\nSince bRPC 1.11.0, a client can create multiple streams in one RPC via\nbatch StreamCreate. The expected behavior is that the server response\nmust return exactly (N-1) extra_stream_ids, where N is the number of\nlocally created streams. In Controller::HandleStreamConnection, the\nresponse path reads extra_stream_ids[i-1] for each additional local\nstream without first comparing the returned list size with (N-1). If\nthe server returns fewer identifiers, the read runs past the end of\nthe returned list (out-of-bounds read); if it returns more, the\nsurplus identifiers have no corresponding client-side stream.\n\nAffected Scenarios:\nA bRPC client using multi-stream RPC (creating more than one stream in\na single RPC) that connects to an untrusted, malicious, or compromised\nserver or to a server reached through an untrusted network path. The\nserver sends a malformed StreamSettings response to trigger the issue.\n\n\nHow to Fix:\n(Choose one of the following options)\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3485\n\n\nNote:\nThe fix makes the client reject responses whose extra_stream_ids count\ndoes not exactly match the number of additional client streams. Such\nmismatched responses now fail the RPC with ERESPONSE and go through\nthe existing stream cleanup path, instead of being partially\nprocessed.\n\nCredit:\n\nClaude (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-79704\n\n### CVE-2026-80463: Apache bRPC: Unbounded Memory Accumulation in\nStream Message Reassembly\n\nSeverity: medium\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nUnbounded memory accumulation in the stream message reassembly path of\nApache bRPC (version < 1.18.0) on all platforms allows remote\nattackers to exhaust the memory of a server (denial of service) by\nsending an endless sequence of continuation data frames.\n\nRoot Cause:\nThe streaming RPC protocol bounds every single data frame by\nmax_body_size, but a fragmented stream message accumulates\ncontinuation frames into one buffer (_pending_buf) without any limit\non the accumulated size. A malicious peer that can open a stream can\ntherefore keep sending continuation frames to make the receiver\naccumulate an arbitrarily large in-memory message. Since the default\nflow-control settings (socket_max_streams_unconsumed_bytes=0) do not\nthrottle the sending rate, the receiver's memory grows until the\nprocess runs out of memory and crashes or becomes unavailable.\n\nAffected Scenarios:\nServices that accept streams from untrusted clients (for example using\nbrpc::StreamAccept or brpc::StreamCreate with the built-in streaming\nprotocol) are affected.\n\n\nHow to Fix:\n(Choose one of the following options)\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3489\n\n\nNote:\nThe fix limits the accumulated payload of a fragmented stream message\nto max_body_size (default 64MB). When the accumulated payload exceeds\nthe limit, the pending fragments are released and the stream is closed\nwith error EMSGSIZE. After applying the fix, legitimate fragmented\nstream messages larger than max_body_size will be rejected; you can\nadjust the gflag max_body_size to change the limit.\n\nCredit:\n\nClaude (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-80463\n\n### CVE-2026-81755: Apache bRPC: Uncontrolled Resource Consumption via\nExcessive Streams in a Single RPC Request\n\nSeverity: medium\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nUncontrolled resource consumption in the streaming RPC component of\nApache bRPC (version < 1.18.0) allows a remote attacker to exhaust\nserver memory and cause denial of service by sending a single RPC\nrequest that declares an excessive number of streams.\n\nRoot Cause:\nIn the streaming RPC feature, a client can declare multiple streams in\none RPC request by putting extra stream identifiers into the repeated\nfield `stream_settings.extra_stream_ids` of the RPC meta. On the\nserver side, `StreamAccept` creates one response stream for every\nstream identifier declared by the request, without limiting the number\nof streams accepted in a single RPC. The request body size is only\nbounded by `max_body_size` (default 64MB), which is enough to carry\nmillions of stream identifiers. Each accepted stream allocates its own\nbthread execution queue and associated resources, so a single crafted\nrequest can make the server create a huge number of streams and\nexhaust memory, leading to denial of service.\n\nAffected Scenarios:\nUse a bRPC server that serves streaming RPC and calls `StreamAccept`\nto accept streams from untrusted clients.\n\nHow to Fix:\n(Choose one of the following options)\n1. Upgrade bRPC to the 1.18.0 version.\n2. Apply this patch: https://github.com/apache/brpc/pull/3493\n\n\nNote:\nThe fix adds a new gflag `stream_max_streams_per_request` with a\ndefault value of 64. Requests declaring more streams than the limit\nare rejected before any response stream is created. Applications that\nlegitimately need to accept more than 64 streams in one RPC must raise\nthis flag; otherwise such requests will fail after applying the fix.\n\nCredit:\n\nClaude (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-81755\n\n### CVE-2026-82210: Apache bRPC: Remote denial of service (crash) via\nmalformed stream feedback frames\n\nSeverity: medium\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nEnforceable assertion in the streaming feature of Apache bRPC (version\n< 1.18.0) on all platforms allows a remote attacker to crash the\nserver process by sending a malformed stream feedback frame.\n\nRoot Cause:\nWhen handling FRAME_TYPE_FEEDBACK frames, bRPC calls\nStream::SetRemoteConsumed() which contains CHECK(_cur_buf_size > 0)\nand unconditionally asserts CHECK(buf.IsEmpty()) on the frame payload.\nA feedback frame that carries an unexpected payload, or a feedback\nframe received on a stream where flow control is disabled\n(cur_buf_size == 0), reaches these assertions. On failure, CHECK\nfailures abort the process, allowing an unauthenticated single client\n(once a stream is established) to terminate the server and cause a\ndenial of service.\n\nAffected Scenarios:\nUse bRPC server with the streaming control feature (Stream API) served\nfrom untrusted network.\n\nHow to Fix:\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3494\n\nThe fix rejects malformed feedback frames with EPROTO and closes only\nthe affected stream instead of crashing the whole process, and it\nbounds buffer shrinking so cur_buf_size never drops to 0 while flow\ncontrol is enabled.\n\nCredit:\n\nClaude (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-82210\n\n### CVE-2026-82230: Apache bRPC: Stack Exhaustion via Unbounded\nRecursion in mcpack2pb Parser\n\nSeverity: high\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nUncontrolled recursion in the mcpack2pb component in Apache bRPC\n(version < 1.18.0) on all platforms allows remote attackers to make\nthe server crash via sending deeply nested mcpack data.\n\nRoot Cause:\nThe bRPC mcpack2pb parser (used to serve nshead_mcpack / ubrpc /\npublic_pbrpc requests) recursively parses nested objects and arrays\nwithout any depth limit. For a protobuf message that references itself\n(e.g. a repeated message field), the generated parser recurses once\nper nesting level of the incoming mcpack object. A deeply nested\nrequest makes the recursion grow unbounded, overflow the stack and\ncrash the process.\n\nAffected Scenarios:\nUse bRPC server with a recursive-schema protobuf message to serve\nnshead_mcpack / ubrpc / public_pbrpc requests from untrusted network.\n\nHow to Fix:\n(Choose one of the following options)\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3499\n\nNote:\nNo matter which option you choose, you should know that the fix\nenforces the documented parsing depth limit MAX_DEPTH (128) on the\nparse path, the same limit the serializer already applies. If your\nrequests contain mcpack messages nested deeper than 128 levels, the\nrequest will be failed after applying the fix.\n\nCredit:\n\nKaixuan Li (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-82230\n\n### CVE-2026-82231: Apache bRPC: Malformed Thrift T_EXCEPTION reply\ncauses process termination in Thrift client\n\nSeverity: high\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nA Thrift client in Apache bRPC (version < 1.18.0, built with\nWITH_THRIFT which is off by default) can be crashed by the server peer\nit talks to. When the server returns a T_EXCEPTION reply whose\nexception struct is malformed, the client decodes it without catching\nwhat Apache Thrift throws (TProtocolException, TTransportException or\nstd::length_error). The exception unwinds out of the bthread task\nfunction and the process calls std::terminate(), terminating the whole\nprocess along with every other in-flight RPC.\n\nThis is the client response path, so the adversary is the server peer,\nwhich THREAT_MODEL.md treats as untrusted. It requires a WITH_THRIFT\nbuild (off by default).\n\nHow to Fix:\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3500\n\nCredit:\n\nKaixuan Li (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-82231\n\n### CVE-2026-82425: Apache bRPC: Reachable Assertion in\nSocket::OnInputEvent Allows Remote Denial of Service\n\nSeverity: moderate\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nA reachable assertion in Apache bRPC (version < 1.18.0) on all\nplatforms allows a malicious remote peer to crash the process,\nresulting in denial of service.\n\nRoot Cause:\nWhen a Socket with health checking enabled fails, Socket::WaitAndReset\ncloses its file descriptor while the event dispatcher may still be\ndelivering an input event (EPOLLIN/EVFILT_READ) that was fetched for\nthe just-closed fd. If the health check then succeeds and revives the\nSocket, Socket::Address succeeds again while the fd is still -1 (the\nnext write reconnects on demand). In that window, Socket::OnInputEvent\nhits CHECK(!(events & EPOLLIN)) (or the kqueue equivalent) because the\nSocket is addressable but has no fd. CHECK failures terminate the\nprocess when bRPC is built with glog or when the gflag\n-crash_on_fatal_log is enabled (CHECK always terminates in\nOFFICIAL_BUILD/NDEBUG builds as well).\n\nAffected Scenarios:\nApplications using bRPC clients with health check enabled\n(-health_check_interval). A malicious remote peer that the client\nconnects to can deliberately abort connections and immediately accept\nthe health check probes, racing connection teardown against health\ncheck revival to trigger the assertion and abort the process.\n\nHow to Fix:\n(Choose one of the following options)\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3510\n\nNote:\nAfter applying the fix, stale input events on a Socket revived without\nan fd are silently dropped instead of triggering the assertion. No\nuser-visible interface or wire protocol is changed.\n\nCredit:\n\ncondy0919 (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-82425\n\n### CVE-2026-82942: Apache bRPC: Race Condition on the Shared Socket\nInput Buffer in the RDMA Transport Causes Remote Denial of Service\n\nSeverity: moderate\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nA data race in the RDMA transport of Apache bRPC (versions < 1.18.0)\nallows a remote client to crash the server process (denial of service)\nwhen RDMA is enabled at build time and runtime.\n\nRoot Cause:\nWhen a bRPC server negotiates RDMA with a client, the handshake\ncompletes on the TCP fd, but the server kept parsing that fd\nafterwards as if it were still an RPC channel. The TCP-fd input stream\nand the RDMA QP input stream (driven by CQ events) shared the same\nSocket::_read_buf, preferred_index and parsing_context without\nsynchronization. In addition, CQ event processing could start while\nthe handshake parsing was still in progress, and the handshake ACK\nphase could consume bytes belonging to the next protocol. A remote,\nunauthenticated client that has completed the RDMA handshake can send\ndata on the TCP fd at the same time RDMA messages are being processed,\ncorrupting the shared input buffer and parser state and crashing the\nserver process (CWE-362, availability impact).\n\nAffected Scenarios:\nUse a bRPC server with RDMA support enabled (built with BRPC_WITH_RDMA\nand serving rdma:// / SOCKET_MODE_RDMA sockets) and accept connections\nfrom untrusted clients. Deployments without RDMA are not affected.\n\nHow to Fix:\n(Choose one of the following options)\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3505\n\nCredit:\n\nbzs1118 (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-82942\n\n### CVE-2026-82953: Apache bRPC: NULL Pointer Dereference in RTMP\ncreateStream Error Path Leading to Remote Denial of Service\n\nSeverity: high\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nNULL pointer dereference in the RTMP protocol implementation in Apache\nbRPC (version < 1.18.0) on all platforms allows remote attackers to\ncrash the server (denial of service) via a crafted createStream\ncommand.\n\nRoot Cause:\nWhen an RTMP service rejects a createStream request by returning a\nnull stream from RtmpService::NewStream(), the server sends an error\nresponse to the client. If writing this rejection response fails (for\nexample, because the client closes the connection immediately after\nsending the createStream command), the error-handling path in\nRtmpChunkStream::OnCreateStream() dereferences the null stream pointer\nto access stream->_onfail_id, causing the process to crash.\n\nAffected Scenarios:\nRun an Apache bRPC RTMP server whose RtmpService::NewStream() may\nreturn null (i.e., the service rejects createStream requests). A\nremote client that sends a createStream command and then closes the\nconnection before the rejection response is written can crash the\nserver.\n\nHow to Fix:\n(Choose one of the following options)\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3508\n\nCredit:\n\nClaude (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-82953\n\n### CVE-2026-84727: Apache bRPC: Use-After-Free in RTMP Chunk Stream\nHandling via Abort Message\n\nSeverity: moderate\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nUse-after-free in the RTMP protocol implementation in Apache bRPC\n(version < 1.18.0) on all platforms allows a malicious RTMP peer to\ncrash the process or potentially corrupt memory via a crafted Abort\nmessage.\n\nRoot Cause:\nWhen processing an RTMP Abort (protocol control message type 2), the\nRTMP policy implementation deleted the target RtmpChunkStream object.\nThe send path (RtmpUnsentMessage::AppendAndDestroySelf ->\nRtmpChunkStream::SerializeMessage) runs concurrently on sender threads\nand dereferences the same RtmpChunkStream object without\nsynchronization. If a remote peer sends an Abort message naming a\nchunk stream that is concurrently being used to serialize an outgoing\nmessage, the stream object is freed while still in use, resulting in a\nuse-after-free. Additionally, deleting the chunk stream discarded its\nprevious message header, so subsequent compressed (type-3) chunk\nheaders on that stream could no longer be decoded.\n\nAffected Scenarios:\nAny application using the bRPC RTMP protocol implementation (rtmp\npolicy), either as an RTMP server or as an RTMP client, where the\nremote endpoint is untrusted. The attacker needs to send an Abort\nmessage targeting a chunk stream id that is concurrently used for\nsending, which can crash the process or lead to memory corruption.\n\nHow to Fix:\n(Choose one of the following options)\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3515\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-84727\n\n### CVE-2026-84747: Apache bRPC: Access Control Bypass via HTTP\nRequest Paths Containing Empty Path Segments\n\nSeverity: moderate\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nInterpretation conflict in the HTTP protocol implementation in Apache\nbRPC (version < 1.18.0) on all platforms allows remote attackers to\nbypass access control rules enforced by a front proxy.\n\nRoot Cause:\nThe method dispatch function FindMethodPropertyByURI() in bRPC's HTTP\nprotocol splits the request path with a string splitter that skips\nempty fields, so paths containing empty path segments (consecutive\nslashes), such as //flags, /flags// and /flags//port, are dispatched\nto the same method as their collapsed form /flags. Per RFC 3986 these\nare distinct paths. A front proxy that enforces an ACL (e.g. blocking\naccess to builtin services such as /flags) matches the collapsed form\nonly, and therefore forwards the padded literal to the bRPC server,\nwhere it is dispatched as if it were the collapsed form. This\ndifferential allows //flags?setvalue= to reach a builtin service that\n/flags is not allowed to reach. Additionally, the HTTP/2\nimplementation never validated the :path pseudo-header, so requests\nwithout a :path, or with a :path that neither begins with '/' nor is\nthe asterisk-form '*', contrary to RFC 9113 section 8.3.1, were not\nrejected.\n\nAffected Scenarios:\nDeployments of Apache bRPC behind a front proxy or gateway that\nperforms access control (ACL) decisions on the literal request path,\nwhere the bRPC server accepts HTTP or HTTP/2 traffic from that proxy.\nIn such deployments an attacker can send a path containing empty path\nsegments to reach a resource that the front proxy intended to block.\n\nHow to Fix:\n(Choose one of the following options)\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3512\n\nNote:\nAfter applying the fix, HTTP and HTTP/2 request paths containing empty\npath segments (consecutive slashes) are rejected by default, and\nHTTP/2 :path values that are empty or neither begin with '/' nor equal\n'*' are rejected. Deployments that depend on the previous lenient\nbehavior can restore it by turning on the gflag\n-http_allow_empty_path_segments, which is not recommended for servers\nexposed to untrusted traffic.\n\nCredit:\n\nClaude (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-84747\n\n### CVE-2026-84748: Apache bRPC: Builtin services reachable from the\npublic port via protobuf protocols despite ServerOptions.internal_port\nconfiguration\n\nSeverity: moderate\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nImproper authorization in Apache bRPC (versions < 1.18.0) on all\nplatforms allows remote attackers to access builtin services through\nthe public port.\n\nRoot Cause:\nServerOptions.internal_port is documented to make builtin services\n(and Tabbed services) reachable only from the internal port, and the\nHTTP/h2 dispatch path enforced this. However, all protobuf-based\nprotocol dispatch paths (baidu_std, hulu_pbrpc, sofa_pbrpc, and the\nnshead-based protocols public_pbrpc, nshead_mcpack, nova_pbrpc and\nubrpc2pb) computed the security_mode flag but never enforced it\nbetween method resolution and method invocation. Since builtin\nservices share the method map with user services, a client able to\nreach the public port could invoke builtin services such as brpc.vars\nor hotspots by name over these pb protocols and disclose sensitive\nruntime information (metrics, flags, profiler data) that the operator\nintended to expose only via the internal port.\n\nAffected Scenarios:\nUse a bRPC server with ServerOptions.internal_port configured (or with\nbuiltin/Tabbed services otherwise expected to be gated by it) while\nthe public port is reachable from an untrusted network and any\npb-based protocol is enabled.\n\nHow to Fix:\n(Choose one of the following options)\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3511\n\nCredit:\n\nClaude (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-84748\n\n### CVE-2026-86146: Apache bRPC: HTTP Request Smuggling and Header\nInjection via Lenient HTTP/1.1 Header Parsing\n\nSeverity: moderate\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nInconsistent interpretation of HTTP requests (HTTP request/response\nsmuggling) in the bundled HTTP/1.1 parser of Apache bRPC (version <\n1.18.0) on all platforms allows remote attackers to smuggle requests\nand inject headers when bRPC is deployed behind a proxy or load\nbalancer that parses the same bytes differently.\n\nRoot Cause:\nThe bRPC fork of http-parser accepts and acts on several HTTP/1.1\nheader forms that a conforming front-end either rejects or interprets\ndifferently, so the framing or the header set of a message can differ\nbetween the front-end and bRPC:\n1. A space before the colon of framing headers (e.g. Content-Length :\n5) is accepted; the value still drives bRPC's framing while the\nreported field name contains the trailing space.\n2. Interior spaces inside a Content-Length value (e.g. Content-Length:\n1 3) are skipped, so bRPC reads 13 where a front-end reads 1 or\nrejects the message (same class as CVE-2022-32213 in Node.js).\n3. Obsolete line folding (obs-fold, RFC 7230 3.2.4) of Content-Length\nand Transfer-Encoding values is accepted, so a folded framing value\ndrives bRPC's framing while a front-end that does not unfold sees a\ndifferent message.\n4. Chunked trailer fields are fed to the same header callbacks as the\nheader section and are merged into the header map like real headers. A\nfront-end only inspects the header section, so any chunked request can\nsmuggle fields such as Authorization or X-Forwarded-For past it.\n5. Transfer-Encoding lists with optional whitespace after a comma\n(e.g. Transfer-Encoding: gzip, chunked) are not recognized as chunked:\nsuch requests are rejected, and responses are read until connection\nclose instead of as chunked, causing response desync.\n\nAffected Scenarios:\nbRPC server or client communicating over HTTP/1.1 with a front proxy,\nload balancer, or any peer that parses the message independently. An\nattacker able to send requests through the front-end can desynchronize\nthe two parsers to smuggle requests, forge headers (e.g.\nAuthorization, X-Forwarded-For) via chunked trailers, or desynchronize\nresponses.\n\nHow to Fix:\n(Choose one of the following options)\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3521\n\nNote:\nAfter applying the fix, the four header forms above are rejected by\ndefault and chunked trailers are dropped instead of merged into the\nheader map. Two gflags are provided for compatibility:\nhttp_allow_obs_fold=true restores acceptance of folded\nContent-Length/Transfer-Encoding values, and\nhttp_strict_header_token=true additionally rejects spaces inside any\nheader field name (not only the ones that decide framing). Legitimate\nclients that do not use these obsolete forms are unaffected.\n\nCredit:\n\nClaude (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-86146\n\n### CVE-2026-86147: Apache bRPC: Arbitrary file creation/truncation\nvia /flags and unbounded profiling duration via /pprof\n\nSeverity: moderate\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nExternal control of file name or path and uncontrolled resource\nconsumption in Apache bRPC (version < 1.18.0) on all platforms allows\nremote attackers who can reach the builtin service port to create\ndirectories and truncate/overwrite files with the privileges of the\nserver process, or to hold the process-wide CPU/contention profiler\nfor an arbitrarily long time.\n\nRoot Cause:\n1. The builtin /flags service allows gflags carrying a validator to be\nmodified at runtime via ?setvalue=. The bvar/mbvar dump path gflags\n(bvar_dump_file, bvar_dump_tabs, mbvar_dump_file) were registered with\nan accept-anything validator whose only purpose was to wake the\ndumping thread. A remote attacker could therefore repoint the dump\npath (e.g. GET /flags/bvar_dump_file?setvalue=/victim/dir/target\nfollowed by GET /flags/bvar_dump?setvalue=true, or the equivalent for\nmbvar_dump_file, which is used verbatim without a forced suffix),\nmaking the dumping thread recursively create directories and\nopen/truncate files at attacker-chosen locations. Tab names in\nbvar_dump_tabs were appended to the path without sanitization,\nallowing '..' to escape the configured directory.\n2. The /pprof builtin service did not clamp the ?seconds= parameter to\nFLAGS_max_profiling_seconds (a limit that /hotspots enforced). A\nsingle request such as ?seconds=2147483647 made the handler sleep for\ndecades while holding the process-wide gperftools CPU profiler or\nbthread contention profiler, so /hotspots/cpu and /hotspots/contention\nreturned 503 for everyone else during that time.\n\nAffected Scenarios:\nAny Apache bRPC server exposing the builtin services (enabled by\ndefault on the same port as normal RPC traffic) to untrusted networks.\n\nHow to Fix:\n(Choose one of the following options)\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3523\n\nNote:\nAfter the fix, bvar_dump_file, bvar_dump_tabs and mbvar_dump_file can\nno longer be modified at runtime through the /flags builtin service.\nThey can still be changed programmatically via\ngoogle::SetCommandLineOption(), taking effect on the next dump cycle.\nThe profiling duration of /pprof is now capped by the\n-max_profiling_seconds gflag (default 300 seconds), which can be\nadjusted by the server owner.\n\nCredit:\n\nClaude (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-86147\n\n### CVE-2026-86249: Apache bRPC: Authentication bypass when a server\nsets ServerOptions.internal_port and ServerOptions.auth\n\nSeverity: moderate\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nOn a brpc::Server that sets both ServerOptions.auth and\nServerOptions.internal_port, the HTTP built-in service exemption on\ninternal_port can be abused to bypass authentication entirely.\nVerifyHttpRequest() returns true without checking any credential when\na built-in service is requested on internal_port, and this verdict is\nnot per - request: verification runs only for the first message of a\nconnection and the result latches the connection. Sending a request\nsuch as GET /status to internal_port first authenticates the whole\nconnection, after which every subsequent request dispatched on the\nsame connection is handled without ever calling VerifyHttpRequest().\nThis lets a remote attacker reach ordinary (non-built-in, non-tabbed)\nauthenticated services without supplying valid credentials whenever\nthe server uses ServerOptions.internal_port together with an\nAuthenticator. The fix restricts internal_port so that it carries only\nbuilt-in and Tabbed services; requests for ordinary services sent to\ninternal_port are rejected with EPREM / HTTP 403.\n\n\n\nMitigation / Fix: upgrade to 1.18.0 or apply PR\nhttps://github.com/apache/brpc/pull/3525 .\n\n\n\nUsers who rely on serving normal services on internal_port must move\nthose requests to the port passed to Server::Start().\n\nCredit:\n\nClaude (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-86249\n\n### CVE-2026-87849: Apache bRPC: Out-of-bounds read via non-object\nfields in Discovery naming-service reply parsing\n\nSeverity: moderate\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nThe Discovery naming-service reply parser in Apache bRPC (versions <\n1.18.0) calls RapidJSON object-only accessors (FindMember) on JSON\nvalues without first validating that those values are objects. A\nmalformed Discovery response whose data/service members or instances\nlist contain non-object entries (e.g. a bare integer) triggers the\nRapidJSON object-access precondition on the client, reading memory out\nof bounds and potentially crashing the bRPC client.\n\nRoot Cause:\nIn src/brpc/policy/discovery_naming_service.cpp,\nDiscoveryNamingService::GetServers() and\nDiscoveryNames::ListDiscoveryNodes() access JSON values with member\nfunctions on non-object values. RapidJSON only defines these\noperations for object types; invoking them on a non-object violates\nthe class invariant and results in undefined behavior (out-of-bounds\nread), commonly crashing the process.\n\nAffected Scenarios:\nAn operator-configured (or compromised) Discovery backend returns a\nmalformed /discovery/nodes or /discovery/fetchs response whose\ndata/service/instance entries are not JSON objects, crashing any bRPC\nclient that refreshes its server list.\n\nHow to Fix:\n1. Upgrade bRPC to version 1.18.0 or later, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3533\n\nThe fix validates that the Discovery response data, per-service data,\nand instance entries are JSON objects (and skips non-object\nnode/instance entries and rejects non-object data/service values)\nbefore calling member accessors.\n\nCredit:\n\nClaude (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-87849\n\n### CVE-2026-90484: Apache bRPC: Null pointer dereference in MySQL\nreply parser leading to client crash\n\nSeverity: moderate\n\nAffected versions:\n\n- Apache bRPC (brpc) through 1.17.0\n- Apache bRPC (brpc) 1.18.0 unaffected\n\nDescription:\n\nThe MySQL client response parser in Apache bRPC dereferences a null\npointer when the server peer sends a zero-payload-length response\npacket. A response packet whose declared payload length is zero is\naccepted by the frame-length check (is_full_package), after which the\nparser reads the response type byte via an unbounded 5-byte fetch that\nreturns nullptr, and type = p[4] dereferences it, crashing the client\nprocess.\n\n\n\nRoot Cause: In brpc::policy::MysqlReply::ConsumePartialIOBuf,\nbuf.fetch(header, 5) returns nullptr when the buffered data only holds\nthe 4-byte header of a zero-length packet, then the code reads p[4]\n(and, in the fast-auth path, p2[4]) without checking for a null or\nzero-length packet.\n\n\n\nAffected Scenarios: A brpc MySQL client connecting to a malicious or\ncompromised MySQL server (or a MITM) can be crashed by a zero-length\nserver response packet, resulting in denial of service of the client.\n\n\n\nFix: The fix rejects zero-length response packets (returning\nPARSE_ERROR_ABSOLUTELY_WRONG) both for the initial response type\ndetermination and after a fast-auth marker, before reading the type\nbyte. Upgrade to the Apache bRPC version 1.18.0 or apply the PR patch\nat https://github.com/apache/brpc/pull/3536.\n\nCredit:\n\nClaude (finder)\n\nReferences:\n\nhttps://github.com/apache/brpc\nhttps://www.cve.org/CVERecord?id=CVE-2026-90484\n\n---------------------------------------------------------------------\nTo unsubscribe, e-mail: dev-unsubscribe@brpc.apache.org\nFor additional commands, e-mail: dev-help@brpc.apache.org\n\n", "body_short": "Hi, all\n\nWe have released the Apache bRPC 1.18.0, with 35 vulnerabilities fixed\n(16 high, 19 moderate) . The vulnerabilities descriptions are below:\n\n### CVE-2026-48830: Apache bRPC: HTTP builtin reque", "html_source_only": false, "attachments": [], "forum": "dev@brpc.apache.org", "size": 66420, "id": "2pf15ojj0vr7rtx95677kgtl1mx3gdgb" }