Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🦀 crates.io
Not in CISA KEV

Buffa Vulnerable to Memory Exhaustion Denial of Service in decode_unknown_field via Unbounded AllocationGHSA-f9qc-qg88-7pq5

Fix: anthropics/buffa#184

GHSA-f9qc-qg88-7pq5 is a Uncontrolled Resource Consumption vulnerability in buffa. A fix is available for buffa — see the affected versions and patch details below.

Also known asCVE-2026-55407
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 12, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-f9qc-qg88-7pq5.

EPSS Exploitation Probability

via FIRST.org ↗
0.8%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs54th percentile — riskier than 54% of all scored CVEsHighest risk
0.26%0.59%0.92%1.26%0.8%0.8%Sep 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected
🦀buffa

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.

Description

The decode_unknown_field function in buffa's protobuf decoder allocated heap memory in proportion to untrusted input (unknown fields in the serialized protobuf) without enforcing an allocation budget. Any message decoded from untrusted input using code generated with preserve_unknown_fields=true (the default) was affected. A small, well-formed payload of nested unknown fields inside a StartGroup could trigger roughly 22× memory amplification (e.g., a 64 MiB input forcing ~1.4 GB of heap allocation), and length-delimited unknown fields could be sized arbitrarily, enabling an unauthenticated attacker to crash a process via memory exhaustion. This was reachable from the default decode APIs, since the top-level message size cap did not account for in-decode amplification.

For users of connectrpc - the DEFAULT_MAX_MESSAGE_SIZE for connectrpc is 4MiB, which limits amplification in the worst case to ~88 MiB of memory. A flood of concurrent requests with this pattern could still be used to exhaust available memory, however.

Users are advised to either set preserve_unknown_fields=false on their current generated code, or upgrade to 0.8.0, which enforces per-message unknown field count limits - this is configurable, with a default of 1 million unknown fields, or ~40MiB of allocation overhead per message. Users are advised to update to the latest version, which enforces per-message unknown field count limits.

Thank you to @p80n-sec for reporting this issue.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🦀crates.iobuffaall versions0.8.0cargo update -p buffa --precise 0.8.0

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for buffa, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update buffa to 0.8.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-f9qc-qg88-7pq5 is resolved across your whole dependency graph.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Frequently Asked Questions

The `decode_unknown_field` function in buffa's protobuf decoder allocated heap memory in proportion to untrusted input (unknown fields in the serialized protobuf) without enforcing an allocation budget. Any message decoded from untrusted input using code generated with `preserve_unknown_fields=true` (the default) was affected. A small, well-formed payload of nested unknown fields inside a StartGroup could trigger roughly 22× memory amplification (e.g., a 64 MiB input forcing ~1.4 GB of heap allocation), and length-delimited unknown fields could be sized arbitrarily, enabling an unauthenticated
O3 Security · Impact-Aware SCA

Is GHSA-f9qc-qg88-7pq5 in your dependencies?

Find it across crates.io, including transitive dependencies.

Scan my dependencies How O3 SCA works
Buffa Vulnerable to Memory Exhaustion Denial of Service…