---
id: "CVE-2026-78058"
kind: "vulnerability"
aliases: ["CVE-2026-78058"]
title: "Apache bRPC: unauthenticated HTTP/2 frames can crash server or exhaust memory"
severity: "high"
cvss: null
epss: 0.00307
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["apache-brpc", "c++", "grpc", "http2", "package", "self-hosted"]
not_affected_if: ["internal-network-only", "no-h2-or-grpc-traffic", "version-1.18.0-or-later"]
published_at: "2026-10-21T12:17:23+00:00"
first_seen_at: "2026-10-23T21:57:28+00:00"
updated_at: "2026-10-25T05:02:40+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78058", "first_seen_at": "2026-10-23T21:57:28+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-78058", "first_seen_at": "2026-10-24T13:15:54+00:00"}]
---

# Apache bRPC: unauthenticated HTTP/2 frames can crash server or exhaust memory

Apache bRPC versions before 1.18.0 enforce no limits on concurrent HTTP/2 streams, header list size, or control-frame write buffering, and contain an HPACK table desync that can dereference NULL. A remote unauthenticated attacker can crash a bRPC server or grow its memory without bound by sending crafted HTTP/2 frames.

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

## How to check

- Check the bRPC version the service is built against, for example with `grep -r brpc` in the build manifest or the lockfile; affected if below `1.18.0`
- Check whether the server listens on a port that accepts HTTP/2 or gRPC traffic from untrusted networks, since the h2 parser is enabled by default on every bRPC server port
- Check whether a bRPC h2/gRPC client connects to untrusted backends

## Fix

- Upgrade Apache bRPC to `1.18.0` or later
- Or apply the patch from https://github.com/apache/brpc/pull/3474
- Keep the default limits: `max_concurrent_streams` 1024, `max_header_list_size` 1 MiB, and h2 control-frame acks respecting `-socket_max_unwritten_bytes`; only set `4294967295` to restore unlimited behavior if needed

## Timeline

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

## From the sources

Uncontrolled resource consumption in the HTTP/2 (h2) receive path of Apache bRPC (version < 1.18.0) on all platforms allows a remote unauthenticated attacker to crash the server or grow its memory without bound by sending crafted HTTP/2 frames.

Root Cause:
The h2 parser, enabled by default on every bRPC server port and used by h2/gRPC clients, trusts the peer to respect receive-side limits that bRPC advertises but never enforces:
1. SETTINGS_MAX_CONCURRENT_STREAMS defaulted to unlimited and was never checked on the server, letting a peer pin an unbounded number of pending streams per connection (~100x memory amplification).
2. SETTINGS_MAX_HEADER_LIST_SIZE defaulted to unlimited and was never enforced; 1-byte HPACK indexed references amplify a small HEADERS frame ~4000x into an unbounded decoded header list ("HPACK bomb"), and a never-completed HEADERS/CONTINUATION block accumulates memory without limit.
3. Control-frame acks (PING/SETTINGS acks, RST_STREAM, GOAWAY, WINDOW_UPDATE) unconditionally bypassed the -socket_max_unwritten_bytes write cap, so a PING flood combined with withheld TCP reads grew the connection buffer without the documented bound.
4. The HPACK dynamic table size update was validated against the protocol default (4096) instead of the advertised SETTINGS_HEADER_TABLE_SIZE, which together with the dynamic-table queue/accounting issue can desynchronize the decoder and dereference NULL (crash).

Affected scenarios:
Any bRPC server serving HTTP/h2/gRPC to an untrusted network, and any bRPC h2/gRPC client connecting to an untrusted backend. The h2 parser runs before any Authenticator check on the shared port.

How to fix: 
Upgrade bRPC, or apply the patch in https://github.com/apache/brpc/pull/3474.

Note:
After applying the fix the following limits are enforced by default:
- max_concurrent_streams: 1024 per connection (4294967295 restores unlimited).
- max_header_list_size: 1 MiB decoded size per stream (4294967295 restores unlimited; -h2_client_max_header_list_size for clients).
- h2 control-frame acks respect -socket_max_unwritten_bytes (-h2_ack_ignore_eovercrowded restores the old behavior).
Requests exceeding these limits are rejected (RST_STREAM(REFUSED_STREAM) or a connection error).

---

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