<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-23T04:15:52.599642+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-81755</id>
    <title>fkie_cve-2026-81755</title>
    <updated>2026-10-23T04:15:52.600968+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>Uncontrolled resource consumption in the streaming RPC component of Apache bRPC (version &lt; 1.18.0) allows a remote attacker to exhaust server memory and cause denial of service by sending a single RPC request that declares an excessive number of streams.</p>
<p>Root Cause:
In the streaming RPC feature, a client can declare multiple streams in one RPC request by putting extra stream identifiers into the repeated field `stream_settings.extra_stream_ids` of the RPC meta. On the server side, `StreamAccept` creates one response stream for every stream identifier declared by the request, without limiting the number of streams accepted in a single RPC. The request body size is only bounded by `max_body_size` (default 64MB), which is enough to carry millions of stream identifiers. Each accepted stream allocates its own bthread execution queue and associated resources, so a single crafted request can make the server create a huge number of streams and exhaust memory, leading to denial of service.</p>
<p>Affected Scenarios:
Use a bRPC server that serves streaming RPC and calls `StreamAccept` to accept streams from untrusted clients.</p>
<p>How to Fix: 
(Choose one of the following options) 
1. Upgrade bRPC to the 1.18.0 version.
2. Apply this patch:  https://github.com/apache/brpc/pull/3493</p>
<p>Note:
The fix adds a new gflag `stream_max_streams_per_request` with a default value of 64. Requests declaring more streams than the limit are rejected before any response stream is created. Applications that leg…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-81755"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-74m8-q5wc-qpjc</id>
    <title>GHSA-74m8-q5wc-qpjc</title>
    <updated>2026-10-23T04:15:52.601052+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>Uncontrolled resource consumption in the streaming RPC component of Apache bRPC (version &lt; 1.18.0) allows a remote attacker to exhaust server memory and cause denial of service by sending a single RPC request that declares an excessive number of streams.</p>
<p>Root Cause:
In the streaming RPC feature, a client can declare multiple streams in one RPC request by putting extra stream identifiers into the repeated field `stream_settings.extra_stream_ids` of the RPC meta. On the server side, `StreamAccept` creates one response stream for every stream identifier declared by the request, without limiting the number of streams accepted in a single RPC. The request body size is only bounded by `max_body_size` (default 64MB), which is enough to carry millions of stream identifiers. Each accepted stream allocates its own bthread execution queue and associated resources, so a single crafted request can make the server create a huge number of streams and exhaust memory, leading to denial of service.</p>
<p>Affected Scenarios:
Use a bRPC server that serves streaming RPC and calls `StreamAccept` to accept streams from untrusted clients.</p>
<p>How to Fix: 
(Choose one of the following options) 
1. Upgrade bRPC to the 1.18.0 version.
2. Apply this patch:  https://github.com/apache/brpc/pull/3493</p>
<p>Note:
The fix adds a new gflag `stream_max_streams_per_request` with a default value of 64. Requests declaring more streams than the limit are rejected before any response stream is created. Applications that leg…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-74m8-q5wc-qpjc"/>
  </entry>
</feed>
