Answer in brief
CVE-2026-55407 records a Medium severity (CVSS 6.3) vulnerability in Buffa Vulnerable to Memory Exhaustion Denial of Service in decode_unknown_field via Unbounded Allocation. The current sources do not mark it as known exploited. The current feed maps buffa (rust). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 6.3. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps buffa (rust). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| buffarust | <0.8.0 | 0.8.0 |
Published upstream
Jul 16, 2026
Evidence: source:ghsa:source_dates:source-dates:recordSource modified
Aug 28, 2026
Evidence: source:ghsa:source_dates:source-dates:recordFirst seen by HOL
Jul 16, 2026
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.
Quoted source text, attributed separately from HOL analysis.