Vulnerability-Lookup

FKIE_CVE-2026-78058

Vulnerability from fkie_nvd - Published: 2026-10-21 12:17 - Updated: 2026-10-21 12:17

Severity

Summary

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).

References

	URL	Tags
	security@apache.org	https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "collectionURL": "https://github.com",
          "defaultStatus": "unaffected",
          "packageName": "apache/brpc",
          "packageURL": "pkg:github/apache/brpc",
          "product": "Apache bRPC",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "1.18.0",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "source": "security@apache.org"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Uncontrolled resource consumption in the HTTP/2 (h2) receive path of Apache bRPC (version \u003c 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.\n\nRoot Cause:\nThe 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:\n1. 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).\n2. 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.\n3. 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.\n4. 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).\n\nAffected scenarios:\nAny 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.\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 restores unlimited; -h2_client_max_header_list_size for clients).\n- h2 control-frame acks respect -socket_max_unwritten_bytes (-h2_ack_ignore_eovercrowded restores the old behavior).\nRequests exceeding these limits are rejected (RST_STREAM(REFUSED_STREAM) or a connection error)."
    }
  ],
  "id": "CVE-2026-78058",
  "lastModified": "2026-10-21T12:17:23.373",
  "metrics": {},
  "published": "2026-10-21T12:17:23.373",
  "references": [
    {
      "source": "security@apache.org",
      "url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb"
    }
  ],
  "sourceIdentifier": "security@apache.org",
  "vulnStatus": "Received",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-400"
        },
        {
          "lang": "en",
          "value": "CWE-476"
        }
      ],
      "source": "security@apache.org",
      "type": "Primary"
    }
  ]
}

CVE-2026-78058 (GCVE-0-2026-78058)

Vulnerability from cvelistv5 – Published: 2026-10-21 11:52 – Updated: 2026-10-21 11:52

Title

Apache bRPC: Unbounded Resource Consumption and Crash in the HTTP/2 Receive Path

Summary

Severity

No CVSS data available.

CWE

CWE-400 - Uncontrolled Resource Consumption
CWE-476 - NULL Pointer Dereference

Assigner

apache CNA under the mitre root

CNA scorecard B 76/100 over 1088 records in the last 180 days details

References

1 reference

URL	Tags
https://lists.apache.org/thread/2pf15ojj0vr7rtx95…	vendor-advisory

Impacted products

1 product

Vendor	Product	Version
Apache Software Foundation	Apache bRPC	Affected: 0 , < 1.18.0 (semver)

Credits

Claude

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "collectionURL": "https://github.com",
          "defaultStatus": "unaffected",
          "packageName": "apache/brpc",
          "packageURL": "pkg:github/apache/brpc",
          "product": "Apache bRPC",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "1.18.0",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Claude"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Uncontrolled resource consumption in the HTTP/2 (h2) receive path of Apache bRPC (version \u0026lt; 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.\u003cbr\u003e\u003cbr\u003eRoot Cause:\u003cbr\u003eThe 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:\u003cbr\u003e1. 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).\u003cbr\u003e2. 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.\u003cbr\u003e3. 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.\u003cbr\u003e4. 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).\u003cbr\u003e\u003cbr\u003eAffected scenarios:\u003cbr\u003eAny 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.\u003cbr\u003e\u003cbr\u003eHow to fix: \u003cbr\u003eUpgrade bRPC, or apply the patch in https://github.com/apache/brpc/pull/3474.\u003cbr\u003e\u003cbr\u003eNote:\u003cbr\u003eAfter applying the fix the following limits are enforced by default:\u003cbr\u003e- max_concurrent_streams: 1024 per connection (4294967295 restores unlimited).\u003cbr\u003e- max_header_list_size: 1 MiB decoded size per stream (4294967295 restores unlimited; -h2_client_max_header_list_size for clients).\u003cbr\u003e- h2 control-frame acks respect -socket_max_unwritten_bytes (-h2_ack_ignore_eovercrowded restores the old behavior).\u003cbr\u003eRequests exceeding these limits are rejected (RST_STREAM(REFUSED_STREAM) or a connection error)."
            }
          ],
          "value": "Uncontrolled resource consumption in the HTTP/2 (h2) receive path of Apache bRPC (version \u003c 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.\n\nRoot Cause:\nThe 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:\n1. 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).\n2. 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.\n3. 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.\n4. 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).\n\nAffected scenarios:\nAny 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.\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 restores unlimited; -h2_client_max_header_list_size for clients).\n- h2 control-frame acks respect -socket_max_unwritten_bytes (-h2_ack_ignore_eovercrowded restores the old behavior).\nRequests exceeding these limits are rejected (RST_STREAM(REFUSED_STREAM) or a connection error)."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "high"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-400",
              "description": "CWE-400 Uncontrolled Resource Consumption",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-476",
              "description": "CWE-476 NULL Pointer Dereference",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-21T11:52:57.984Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache bRPC: Unbounded Resource Consumption and Crash in the HTTP/2 Receive Path",
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-78058",
    "datePublished": "2026-10-21T11:52:57.984Z",
    "dateReserved": "2026-08-22T09:17:53.072Z",
    "dateUpdated": "2026-10-21T11:52:57.984Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted