Protobuf.js RCE Flaw Threatens 50 Million Weekly npm Downloads

A critical remote code execution vulnerability in protobuf.js—the JavaScript implementation of Google's Protocol Buffers used by millions of applications—allows attackers to execute arbitrary code simply by loading a malicious schema definition. With nearly 50 million weekly downloads from npm, the blast radius of this flaw is enormous.

TL;DR

• What happened: Critical RCE in protobuf.js via unsafe code generation from schema definitions
• Who's affected: Any Node.js application using protobuf.js ≤ 8.0.0 or ≤ 7.5.4 that loads untrusted schemas
• Severity: CVSS 9.9 Critical (GHSA-xq3m-2v4x-88gg)
• Action required: Upgrade to protobuf.js 8.0.1 or 7.5.5 immediately

How the Attack Works

The vulnerability exploits a fundamental flaw in how protobuf.js compiles Protocol Buffer schemas into executable JavaScript. According to research published by Endor Labs, the library constructs JavaScript functions by concatenating strings and passing them to the Function() constructor—a pattern security auditors recognize as essentially equivalent to eval().

The problem: message type names from the schema are interpolated directly into this generated code without any sanitization.

An attacker can craft a malicious schema with a type name like:

User){process.mainModule.require("child_process").execSync("whoami");function x(

When the library generates a constructor function, this payload breaks out of the function signature, executes arbitrary shell commands, and then opens a throwaway function to balance the braces. The malicious code runs the moment an application attempts to decode a message using that schema.

This isn't theoretical. Proof-of-concept code has been published, and Endor Labs characterizes exploitation as "straightforward."

Why This Matters

Protobuf.js sits at the foundation of countless JavaScript applications. It handles inter-service communication in microservices architectures, powers real-time messaging systems, and manages efficient data serialization for cloud-native applications. This makes it a prime target for supply chain attacks targeting developer tools.

The attack surface is broader than it might appear. Any application that accepts schema definitions from external sources—configuration files, APIs, shared registries, or user uploads—could be compromised. Once an attacker achieves code execution, they gain access to environment variables, database credentials, API keys, and potentially lateral movement across infrastructure.

The npm ecosystem has seen a surge in supply chain compromises lately. Just last month, attackers planted a remote access trojan in fake axios packages, and North Korean actors have been seeding thousands of malicious packages across npm and PyPI. This protobuf.js vulnerability represents a different vector—compromising a legitimate, widely-trusted library through its design rather than through malicious package substitution.

Affected Versions and Patches

The GitHub Security Advisory confirms these affected versions:

Branch	Vulnerable	Patched
8.x	≤ 8.0.0	8.0.1
7.x	≤ 7.5.4	7.5.5

The fix itself is elegant—a single line that strips non-word characters from type names before they enter the code generation pipeline:

name = name.replace(/\W/g, "");

This removes parentheses, braces, semicolons, quotes, and every other character an attacker would need for injection.

Patches landed on GitHub March 11, but npm releases came later: version 8.0.1 on April 4 and version 7.5.5 on April 15. The advisory was published April 16.

Discovery Timeline

Security researcher Cristian Staicu of Endor Labs discovered the flaw and reported it on March 2, 2026. The maintainers confirmed the issue within a week and committed a fix by March 11. The delay between the GitHub fix and npm releases gave responsible disclosure time to propagate, though it also created a window where the vulnerable code was visible but patches weren't available through the standard package manager.

No active exploitation has been observed in the wild yet, but with a public PoC and a straightforward attack path, that could change quickly.

What You Should Do

Check your exposure immediately. Run npm ls protobufjs to see if you have vulnerable versions in your dependency tree. Don't forget transitive dependencies—protobuf.js might be pulled in by other packages you use.

Upgrade to patched versions. Update to 8.0.1 or 7.5.5 depending on your branch. Test thoroughly, but don't delay—the attack is simple and the fix is low-risk.

Audit your schema sources. If your application loads protobuf definitions from external sources—registries, APIs, user input, or shared configuration—treat those endpoints as untrusted code execution surfaces. Consider switching to precompiled, static schema artifacts in production.

Include dev tools in SCA. Software composition analysis often focuses on runtime dependencies. Endor Labs recommends expanding coverage to include build tools and code generators, which can introduce vulnerabilities that traditional scanners miss.

The core lesson from this vulnerability applies broadly: any tool that compiles, generates, or evaluates data into executable code is a potential code execution surface. Schema languages, template engines, code generators, and transpilers all deserve the same scrutiny as direct eval() calls.

FAQ

Does this affect Google's official protobuf library?

No. This vulnerability is specific to protobuf.js, the JavaScript implementation maintained independently on npm. Google's official Protocol Buffers libraries for other languages are not affected by this specific issue.

Is my application vulnerable if I only use my own schema files?

If your schemas are hardcoded, version-controlled, and never loaded from external sources, the attack surface is much smaller. However, you should still patch—defense in depth matters, and future code changes might introduce schema loading from untrusted sources.

Why wasn't this caught earlier?

The vulnerable code contained // eslint-disable-line no-new-func comments that suppressed the linter warnings about using the Function() constructor. This highlights how lint suppressions, while sometimes necessary, can mask security issues during code review.