- Endor Labs reports that a small message can make Anthropic's buffa decoder use about 22 times its size in memory. The flaw is CVE-2026-55407, fixed in buffa and connectrpc 0.8.0.
- Anthropic rated it 6.3 (Moderate) for its own setup. Endor Labs argues the same code reaches High-to-Critical in default gRPC and file-ingestion setups.
- Upgrade to 0.8.0, or regenerate code with preserve_unknown_fields=false. Then score the flaw against your own memory limits, restart behaviour and rate limiting.
A severity score describes a deployment more than it describes code. That is the useful lesson in CVE-2026-55407, a denial-of-service flaw in buffa, Anthropic's Rust library for reading protobuf messages. Protobuf is a common format for data passed between services.
The code has one fixed property. A small input can make the decoder claim much more memory than the input's size. What that means for you depends on the service around it.
What Endor Labs found
Endor Labs, a security vendor, ran its AI-based code scanner on buffa. A researcher there followed a flagged data flow and reported a memory-amplification flaw. Anthropic rated it Moderate, CVSS 4.0 score 6.3. The flaw has two identifiers: the GitHub advisory GHSA-f9qc-qg88-7pq5 and the CVE ID CVE-2026-55407.
The report says any message decoded from untrusted input is affected if the code was generated with preserve_unknown_fields=true. That is the default. Endor Labs adds that the message type being decoded need not define a group field. Protobuf's forward-compatibility handling sends every unknown field through the same vulnerable function.
How the amplification works
Protobuf is built so that old software can read messages from newer software. A decoder that meets a field it does not recognise keeps it rather than rejecting it. In buffa, that retention is the weak point.
The scanner first flagged a simple case. A length value read from the incoming bytes is used directly to size a memory allocation. Endor Labs says this costs roughly twice the input size. A cap on input size bounds it, so the researcher considers it modest.
One branch further down, the researcher found the bigger problem. The decoder handles nested groups of unknown fields in a loop. Endor Labs says the library limits how deeply groups nest, but not how many fields one group holds.
The cheapest field an attacker can send takes two bytes. Each one becomes a structure of about 40 bytes in memory on a 64-bit system. That is a 20-fold expansion, plus roughly another 1.5 times while the list grows. Endor Labs reports that a 64 MiB payload drove the decoder to about 1.4 GB of memory.
In its proof of concept, the target process was OOM-killed (exit code 137, OOMKilled: true).
Why an input cap does not solve it
The library's own documentation tells callers to limit the input buffer size. Endor Labs argues that this is the control the group flaw defeats. A 64 MiB cap still allows about 1.4 GB of allocation.
The researcher adds that the library's default maximum message size is about 2 GiB, far too high to help. The cap also measures only input. It does not see a small input that grows during decoding.
One code flaw, several severities
Anthropic scored the flaw against its own deployment: several supervised copies of the service, each restarting automatically. On that basis it settled on 6.3 and paid a $600 bounty. Endor Labs agrees that 6.3 is right for a well-supervised, rate-limited setup.
The researcher disagrees on the general case. Endor Labs argues that a 4 MB gRPC limit is already enough, because the attack only needs the limit times 22 to exceed the memory available to the process. The trigger is small, unauthenticated and repeatable. A worker that restarts automatically can be knocked over again at once.
Endor Labs calls that a crash loop and argues it amounts to sustained unavailability. It says default gRPC and file-ingestion setups can reach the High-to-Critical range. This is one vendor's argument, and the two sides did not agree on every scoring metric.
One caveat on the source: Endor Labs sells the scanner that found the flaw. The technical analysis is its own, and the fix details come from the same report.
What to do
The fix shipped in buffa and connectrpc 0.8.0. It adds a configurable per-message limit on unknown fields, set by default at 1 million. Endor Labs says that caps the overhead at about 40 MiB per message.
Teams that cannot upgrade yet have a second route. Regenerating the code with preserve_unknown_fields=false stops the library from keeping unknown fields at all, which removes the path the flaw uses.
Leaders can put four questions to their teams:
Do we use buffa or connectrpc, directly or through a vendor's product? Which of those services decode data from outside our network? How much memory does each one have compared with its input limit multiplied by 22? And if one crashes, does something restart it into the same attack?
The lesson is that a published score is someone else's assumption about their deployment. Use it as a starting point, then calculate your own.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Endor Labs.
