CVE-2026-41242 - protobufjs generated-code RCE
protobufjs generates JavaScript from protobuf schema metadata. In vulnerable versions, attacker-controlled type names or type references in a protobuf definition or JSON descriptor can flow into generated code and execute in the Node.js process when the application loads and uses that descriptor.
This is not just a routine dependency bump. Applications that only decode
messages with trusted, application-owned schemas have a different risk profile
than services that accept .proto files, JSON descriptors, model/tool schemas,
plugin schemas, tenant-provided integration definitions, or repository-supplied
descriptors. The remediation should upgrade protobufjs and make descriptor
trust explicit.
When to use it
- A repository installs, bundles, generates, or deploys
protobufjsin Node.js services, CLIs, jobs, functions, generated clients, or agent/plugin runners. - Code dynamically loads
.protofiles, JSON descriptors, schema registries, plugin descriptors, connector definitions, model/tool schemas, archives, or repository/tenant-supplied schemas. - Schema loading occurs in a process with environment secrets, service tokens, customer content, internal network access, or package/deployment credentials.
- You need a bounded PR or triage note that upgrades protobufjs and enforces approved descriptor sources before generation/loading.
Inputs
- Package manifests, lockfiles, generated clients, schema-loader code, descriptor registries, plugin/connector/agent schema inputs, Dockerfiles, images, SBOMs, and deployment artifacts.
- Resolved protobufjs versions, schema source classification, signed registry policy, archive/path handling, isolated-worker design, cache ownership, and credential rotation owners.
- Available package install, schema-loader tests, generated-client tests, lint/typecheck, container build, SBOM, and dependency/security scans.
Affected versions
| Package | Vulnerable versions | Fixed versions |
|---|---|---|
protobufjs |
<7.5.5 |
7.5.5+ |
protobufjs |
>=8.0.0, <8.0.1 |
8.0.1+ |
Indicator-of-exposure
- The repository depends on
protobufjsbefore7.5.5, or on8.0.0. - Application code loads protobuf schemas or JSON descriptors from user, tenant, plugin, workflow, model, connector, repository, archive, upload, queue, or agent-generated input.
- Code uses reflection or dynamic schema APIs such as
protobuf.load,loadSync,Root.fromJSON,Type.fromJSON,Field.fromJSON, descriptor JSON parsing, generated roots from untrusted files, or wrappers aroundpbjs. - The schema-loading runtime can access environment variables, service tokens, internal networks, source workspaces, package-manager credentials, customer content, or deployment secrets.
Quick checks:
rg -n "protobufjs|protobuf\\.load|loadSync\\(|Root\\.fromJSON|Type\\.fromJSON|Field\\.fromJSON|fromJSON\\(|pbjs|FileDescriptorSet|descriptor|\\.proto|new protobuf\\.(Root|Type|Field)" .
npm ls protobufjs
pnpm why protobufjs
yarn why protobufjs
For package metadata without a package manager:
rg -n "\"protobufjs\"|node_modules/protobufjs|protobufjs-v(7|8)" package.json package-lock.json npm-shrinkwrap.json pnpm-lock.yaml yarn.lock bun.lockb . 2>/dev/null
Remediation strategy
- Upgrade every controlled
protobufjsdependency, lockfile, generated client, container image, SBOM, and deployable artifact to7.5.5+or8.0.1+. - Treat protobuf schema definitions and JSON descriptors as executable input unless they come from a trusted, repository-owned or signed schema registry.
- Replace direct dynamic schema loading with a central loader that accepts only approved schema sources, rejects tenant-controlled descriptor JSON by default, and logs non-secret source metadata for audit.
- If untrusted schemas are a product requirement, process them in a separate low-privilege runtime with no secrets, constrained filesystem/network access, resource limits, and explicit approval before the schema reaches protobufjs.
- Add regression tests that prove unapproved descriptor sources are rejected without embedding exploit payloads or executing generated attacker code.
- Rotate credentials if a vulnerable runtime previously loaded untrusted descriptors in a secret-bearing process.
The prompt
You are remediating CVE-2026-41242 / GHSA-xq3m-2v4x-88gg, a protobufjs
generated-code execution issue in dynamic protobuf descriptor loading. Produce
exactly one output:
- A reviewer-ready PR/change request that upgrades protobufjs, hardens
descriptor loading, adds safe regression tests, refreshes generated
artifacts, and documents operator cleanup, or
- TRIAGE.md if this repository does not own an affected protobufjs runtime or
cannot make a safe patch.
## Rules
- Scope only CVE-2026-41242 and directly related protobuf descriptor-loading
hardening.
- Do not run proof-of-concept payloads, generated attacker JavaScript, child
process probes, or live exploit commands.
- Do not print, commit, or expose environment variables, API keys, service
tokens, package tokens, source archives, tenant descriptors, customer
messages, or decoded message contents.
- Do not remove protobuf validation, schema verification, or generated-client
checks to make the upgrade easier.
- Do not auto-merge.
## Steps
1. Inventory every Node.js package, workspace, generated client, container,
Lambda/function image, CLI wrapper, lockfile, SBOM, and deployment artifact
controlled by this repository that references `protobufjs`.
2. Determine every resolved `protobufjs` version. A target is vulnerable if it
resolves to `<7.5.5` or `8.0.0`.
3. Search for dynamic schema loading and descriptor construction:
`protobuf.load`, `loadSync`, `Root.fromJSON`, `Type.fromJSON`,
`Field.fromJSON`, descriptor JSON parsing, uploaded `.proto` files,
generated roots, `pbjs`, schema registries, plugin descriptors, connector
definitions, model/tool schemas, and agent-supplied configuration.
4. Classify every schema source:
- repository-owned and reviewed;
- generated at build time from trusted inputs;
- signed or allow-listed registry input;
- admin-supplied;
- user, tenant, plugin, connector, archive, queue, repository, or
agent-supplied input.
5. Upgrade `protobufjs` to `7.5.5+` on the 7.x line or `8.0.1+` on the 8.x
line. Regenerate lockfiles, generated clients, bundled artifacts, image
metadata, SBOMs, and dependency reports.
6. Add or update a central schema-loading helper where the repository owns the
call site. The helper must:
- deny unapproved descriptor JSON and uploaded `.proto` files by default;
- accept only repository-owned, signed, or explicitly allow-listed schema
sources;
- keep source allow-lists in code or policy, not mutable request fields;
- normalize paths and reject archive traversal before reading schema files;
- emit audit logs with schema source, version, and decision only, not schema
contents or decoded messages.
7. Replace direct dynamic protobufjs loading calls with the central helper for
services, CLIs, jobs, plugin runners, and agent workflows that can receive
untrusted or semi-trusted schema input.
8. If the product must accept untrusted schemas, isolate schema parsing and
decoding in a low-privilege worker with no production secrets, no package
manager tokens, constrained filesystem/network access, CPU and memory
limits, and short-lived runtime identity. Document why the repository cannot
reject those schemas outright.
9. Add safe tests that do not execute exploit code:
- dependency resolution rejects vulnerable protobufjs versions;
- unapproved descriptor JSON is rejected before protobufjs loading;
- uploaded or archive-sourced `.proto` files are rejected unless approved;
- approved repository-owned schemas still load and decode known-good
fixtures;
- logs omit schema contents, message contents, secrets, and tenant data.
10. Add a PR body section named `CVE-2026-41242 operator actions` that states:
- protobufjs versions before and after;
- every schema-loading call site changed or triaged;
- which schema sources are now approved;
- whether existing schema caches, generated clients, or container layers
must be rebuilt;
- whether credentials should be rotated because untrusted descriptors
previously ran in a secret-bearing process.
11. Run validation available in this repository: package install, unit tests,
schema-loader tests, generated-client tests, lint/typecheck, container
build, SBOM refresh, and dependency/security scans.
12. Use PR title:
`fix(sec): remediate CVE-2026-41242 in protobufjs loading`.
## Stop conditions
- No affected protobufjs runtime, generated client, image, or deployment
artifact is controlled by this repository.
- All controlled targets already resolve `protobufjs >=7.5.5` or
`protobufjs >=8.0.1`, and generated artifacts are current.
- The vulnerable package is present only in development tooling that never
loads untrusted schemas and never ships in deployable artifacts; write
TRIAGE.md with evidence instead of changing runtime code.
- The product intentionally accepts arbitrary user or tenant protobuf schemas
in a secret-bearing process; document the owner decision and propose isolated
processing before patching.
- Meaningful verification would require executing attacker-controlled
generated code or exposing production descriptors, messages, or credentials.
- Validation fails for unrelated pre-existing reasons; document those failures
instead of broadening scope.
Verification - what the reviewer looks for
- No package manifest, lockfile, generated client, image, SBOM, or deployment
artifact resolves
protobufjs <7.5.5orprotobufjs ==8.0.0. - Dynamic protobuf schema loading routes through an approved-source helper or is documented as trusted, build-time-only code.
- Tests prove unapproved descriptor JSON and uploaded
.protofiles are rejected before protobufjs receives them. - Generated clients, schemas, SBOMs, image metadata, and dependency reports agree on the fixed protobufjs version.
- Operator notes cover cache rebuilds and credential rotation when untrusted descriptors may have been processed before the fix.
Output contract
- Reviewer-ready PR upgrading every controlled protobufjs runtime to
7.5.5+or8.0.1+and refreshing locks, generated clients, images, SBOMs, reports, and deployment artifacts. - Central schema-loading policy that rejects unapproved descriptor JSON,
uploaded
.protofiles, archive traversal, and mutable request-controlled allow-lists before protobufjs receives them. - Safe tests proving unapproved descriptors are rejected and approved repository-owned schemas still load without executing generated attacker code or logging message/schema contents.
TRIAGE.mdwhen protobuf runtime, generated artifacts, schema registry, or credential cleanup ownership is outside this repository.
Watch for
- Updating
package.jsonwhile generated clients, bundled CLIs, containers, or SBOMs still carry the old protobufjs copy. - Treating “trusted schema” as a comment instead of an enforceable loader policy or signed registry boundary.
- Plugin, connector, model-tool, or agent workflow definitions that quietly introduce new descriptor JSON sources.
- Tests that load only repository-owned schemas and never assert rejection for unapproved schema sources.
- Logging full descriptors or decoded messages while adding audit visibility.
Related recipes
- CVE-2025-12735 expr-eval context function RCE
- CVE-2026-41265 Flowise Airtable Agent code injection RCE
- Source code supply-chain build integrity audit
References
- GitHub Advisory: https://github.com/advisories/GHSA-xq3m-2v4x-88gg
- protobufjs advisory: https://github.com/protobufjs/protobuf.js/security/advisories/GHSA-xq3m-2v4x-88gg
- NVD CVE: https://nvd.nist.gov/vuln/detail/CVE-2026-41242
- protobufjs 7.5.5 release: https://github.com/protobufjs/protobuf.js/releases/tag/protobufjs-v7.5.5
- protobufjs 8.0.1 release: https://github.com/protobufjs/protobuf.js/releases/tag/protobufjs-v8.0.1