high

CVE

CVE-2026-41242

CWE

CWE-94

Affected Surface

protobufjs <= 7.5.4, protobufjs 8.0.0, Node.js applications using protobufjs reflection APIs, Applications loading attacker-influenced .proto files or JSON descriptors, Transitive consumers through @grpc/proto-loader, Firebase SDKs, Google Cloud SDKs, and dynamic gRPC tooling

protobufjs, the widely used JavaScript implementation of Protocol Buffers, disclosed CVE-2026-41242 on 16 April 2026. The vulnerability allows attacker-controlled protobuf schema metadata to reach JavaScript runtime code generation without enough validation.

The affected package is common in Node.js dependency graphs, including direct use and transitive use through gRPC tooling, Firebase SDKs, Google Cloud SDKs, protocol-aware gateways, and developer debugging tools. The vulnerable condition is narrower than “any protobufjs install”: the application must load an attacker-controlled or attacker-influenced protobuf definition or JSON descriptor through reflection APIs, then reach the generated-code path for that type.

Affected versions

The affected npm package is protobufjs:

  • protobufjs versions <= 7.5.4
  • protobufjs version 8.0.0

Patched versions are:

  • protobufjs 7.5.5
  • protobufjs 8.0.1

Teams should check both direct and transitive dependencies. Many services do not import protobufjs directly but receive it through packages such as @grpc/proto-loader, Firebase clients, Google Cloud clients, and dynamic gRPC inspection tools.

Root cause

protobufjs can compile schema-derived data into JavaScript functions for performance. Before the fix, schema-controlled type names and type references could be interpolated into generated source and executed with the Function constructor.

That means a malicious descriptor can turn a field that developers usually treat as inert schema metadata into code. The payload runs in the Node.js process that loaded the descriptor, with access to that process’s environment variables, service credentials, filesystem permissions, and network reachability.

Exploitation preconditions

Applications are directly exposed when all of these are true:

  • An attacker can control or influence a .proto file or JSON descriptor.
  • The application loads that definition with protobufjs reflection APIs such as descriptor loading or Root.fromJSON.
  • The application performs an operation that causes code generation for the attacker-controlled type, such as decode, encode, or instantiate.

Applications that only decode messages with trusted, version-controlled schemas written by the application team are not directly exposed to this attack path. The highest-risk cases are dynamic schema loading and schema reuse across trust boundaries.

Where this appears in real systems

The practical risk is higher than the precondition may sound. Common exposure patterns include:

  • Multi-tenant ingestion systems where customers upload protobuf descriptors.
  • Dynamic gRPC clients, proxies, and debugging tools that fetch descriptors from remote services.
  • Internal schema registries where one compromised account can publish a descriptor consumed by other teams.
  • Partner integrations that load vendor-provided protobuf definitions at runtime.
  • Developer workstations decoding captured traffic with third-party schema files.

In those patterns, .proto files and JSON descriptors are effectively code inputs. They should be reviewed, pinned, and isolated like executable dependencies.

Remediation

Upgrade protobufjs to a fixed version:

npm install protobufjs@^7.5.5
# or, for the 8.x line:
npm install protobufjs@^8.0.1

Then verify the resolved dependency tree:

npm ls protobufjs

If a transitive dependency pins an affected version, update the parent package or use the repo’s established package-manager override mechanism until upstream dependencies catch up.

Hardening guidance

Patch first, then reduce the schema attack surface:

  • Do not load protobuf definitions or JSON descriptors from untrusted sources in production.
  • Prefer precompiled static protobuf artifacts where runtime schema compilation is not required.
  • Pin external schema dependencies to immutable versions and verify checksums.
  • Isolate schema-processing workers if customers, partners, or remote services can influence descriptors.
  • Treat .proto, OpenAPI, and other code-generation inputs as security-reviewed artifacts rather than harmless documentation.

Detection and response

Search for direct and transitive protobufjs versions in lockfiles and deployed artifacts. In code, look for dynamic loading paths such as Root.fromJSON, descriptor loading, remote schema fetches, or gRPC reflection clients.

For exposed services, review logs for unexpected schema uploads or descriptor fetches before the patched deployment. If untrusted descriptors were processed by an affected version, rotate secrets available to the Node.js process and inspect outbound network activity from the service during the exposure window.

References