Proto6: Six Vulnerabilities in protobuf.js Open Node.js Apps to RCE and DoS

Protocol Buffers are supposed to be the boring part of your stack. You define a schema, serialize some structured data, send it across the wire, and decode it on the other end. That boring reliability is exactly why protobuf.js ended up everywhere in the JavaScript world, powering Google Cloud client libraries, messaging frameworks, vector databases, and inference pipelines. Now researchers at Cyera have shown that the library's quiet trust in schema and metadata can be turned into remote code execution and denial-of-service attacks.

The six flaws, collectively named Proto6, were disclosed this week. The short version: in affected setups, a single crafted protobuf schema, descriptor, or payload can be enough to crash a service, corrupt its runtime, or execute attacker code. If your Node.js application deserializes Protobuf data or generates code from .proto schemas, you should assume you are in scope until you have patched.

What actually breaks

Cyera security researcher Assaf Morag framed the root cause cleanly. "In affected environments, a single malicious protobuf schema, descriptor, or crafted payload could be enough to trigger crashes, runtime corruption, or even code execution," he said. Every one of the six issues traces back to the same design assumption: protobuf.js treats the schema and its metadata as trusted by default. That assumption was reasonable when schemas were authored by the same team that ran the service. It is dangerous now that schemas travel between repositories, cloud platforms, and third-party integrations.

Here is the full list, with severity:

• CVE-2026-44289 (CVSS 7.5): DoS through unbounded protobuf recursion.
• CVE-2026-44290 (CVSS 7.5): Process-wide DoS when loading schemas with unsafe option paths.
• CVE-2026-44291 (CVSS 8.1): Code generation gadget triggered after prototype pollution.
• CVE-2026-44292 (CVSS 5.3): Prototype injection in generated message constructors.
• CVE-2026-44294 (CVSS 5.3): DoS from crafted field names in generated code.
• CVE-2026-44295 (CVSS 8.7): Code injection in pbjs static output from crafted schema names.

The RCE chain worth understanding

The headline severity number belongs to CVE-2026-44295, but the most instructive bug is CVE-2026-44291, because it shows how two individually unremarkable problems combine into arbitrary code execution.

Security researcher Vladimir Tokarev walked through the sequence. An attacker-controlled input first reaches a prototype pollution gadget somewhere in the application. "Later, the same process uses protobuf.js to encode or decode a message," he explained. "Because protobuf.js resolves type names through plain property lookups, a polluted Object.prototype can make an attacker-controlled string look like a valid protobuf primitive."

That is the hinge. Protobuf.js builds its encoders and decoders dynamically. To squeeze out performance, it generates JavaScript source for each message type and compiles it with Function(). When type resolution happens through ordinary property lookups on objects whose prototype has been polluted, an attacker can smuggle a string into that generated source. "Protobuf.js then inserts that string into a generated encoder or decoder function and compiles it with Function()," Tokarev continued. "The attacker gets arbitrary JavaScript execution inside the Node.js process."

This is what Cyera means by the phrase "data can become behavior." The library was designed to turn schema definitions into running code. That is its job. The problem is that nothing along the way checks whether the strings driving that code generation came from a trusted source.

Where this lands in the real world

The attack scenarios are not theoretical lab setups. Cyera points to CI/CD pipelines, where a poisoned protobuf schema committed to a repository can trigger code generation during a build and leak build secrets in the process, the path described by CVE-2026-44295. That is a clean supply chain angle: the malicious input is a configuration file, not an exploit payload, and configuration files rarely get the scrutiny that executable code does.

Another scenario hits messaging automation. Baileys, a popular TypeScript library for the WhatsApp Web API, leans on protobuf.js to parse messages. A specially crafted message can crash a bot built on it through CVE-2026-44292. For anyone running customer-facing WhatsApp automation, that turns a denial-of-service into something an external party can trigger by sending a single message.

Morag was direct about why the exposure is broader than it first appears. "While exploitation of these vulnerabilities generally requires specific conditions, those conditions are increasingly common in data and AI ecosystems that routinely exchange data, schemas, and configuration files across services, repositories, cloud platforms, and third-party integrations," he noted. Vector stores, inference pipelines, orchestration systems, and cloud SDKs all sit in that category, and protobuf.js is embedded across them.

Affected versions and the fix

The vulnerable ranges are:

• protobuf.js: versions <= 7.5.5 and >= 8.0.0 <= 8.0.1
• protobufjs-cli: versions <= 1.2.0 and >= 2.0.0 <= 2.0.1

Patches are out. Upgrade protobuf.js to 7.5.6 or 8.0.2, and protobufjs-cli to 1.2.1 or 2.0.2. Both major release lines received fixes, so you do not need to jump to v8 if you are still on the 7.x branch. Check the protobuf.js releases page and your lockfile, because transitive dependencies are where this library most often hides. Google Cloud client libraries pull it in indirectly, so npm ls protobufjs will tell you more than your package.json will.

The practical takeaway

Patching closes these six holes, but the lesson Cyera draws is the part worth keeping. "Modern software increasingly treats schemas, metadata, and configuration files as trusted inputs that drive automation, orchestration, and code generation," the company said. "When those trust assumptions break, data can become behavior. That shift creates new attack surfaces that security teams must learn to identify and manage."

The defensive move is to stop treating schema and descriptor files as inert. If a .proto file, a descriptor, or a generated message constructor can originate from outside your trust boundary, including a contributor's pull request or a third-party feed, it deserves the same review you would give untrusted executable code. Run pbjs code generation in isolated, least-privilege build steps rather than in environments holding deployment secrets. And audit your dependency tree for the libraries that compile generated code at runtime, because they are the ones where a polluted prototype quietly becomes a shell.

Upgrade first, then go look at how schemas flow through your pipelines. The patch fixes the known gadgets. The trust assumption is the thing that will produce the next one.