TL;DR: Six vulnerabilities in protobuf.js and protobufjs-cli let attacker-controlled schema data trigger remote code execution, process-wide denial of service, or build-time code injection through unsafe type lookups, prototype pollution, and generated JavaScript, according to Cyera; Schema-to-code boundaries now need the same trust controls as executable code, not metadata assumptions.
At a glance
What this is: Cyera’s analysis shows six protobuf.js vulnerabilities that let schema-controlled input drive code execution or denial of service when metadata crosses into generated JavaScript.
Why it matters: This matters because teams using protobuf.js for untrusted schemas, event payloads, or build-time code generation need to treat schema fields as executable-risk input, not harmless structure.
By the numbers:
- protobuf.js has over 48 million weekly npm downloads.
Context
Schema injection becomes dangerous when a library turns untrusted metadata into executable JavaScript. In protobuf.js, the boundary is not just parsing, it is code generation, which means schema values can influence runtime behaviour if they are not strictly treated as untrusted input.
For IAM and runtime-risk programmes, the issue is broader than application bugs. Any pipeline that lets external parties shape schemas, descriptors, or generated artifacts is effectively allowing data to participate in control flow, and that changes the trust model for non-human identities, build systems, and service workflows.
The article’s central finding is that protobuf.js treated schema values as trusted metadata in places where they could become code. That is an atypical assumption in modern software supply chains, where schema ownership, contribution, and execution paths are often split across teams and environments.
Key questions
Q: What breaks when protobuf schema data is allowed to drive code generation?
A: The break point is the trust boundary between metadata and executable code. When schema names, type lookups, or option paths flow into generated JavaScript without strict sanitisation, an attacker can turn a data file into runtime behaviour, causing code execution, denial of service, or build-time compromise.
Q: Why do schema-driven code generation bugs create runtime risk in Node.js?
A: Because runtime generation compiles attacker-shaped strings into executable JavaScript inside the same process that handles application logic. In Node.js, that can convert a malformed type name, namespace, or field into process-wide impact, especially when a library uses Function() or writes generated source that is later imported.
Q: What are the signs that schema resolution is using unsafe trust assumptions?
A: Look for plain-object lookup tables, inherited property visibility, and schema fields that are accepted before escaping or canonicalisation. If a library resolves types or paths through ordinary object inheritance, then polluted prototypes or crafted names can influence results even when the original schema looked valid.
Q: How should teams handle generated JavaScript from external schemas?
A: Treat it like build output from an untrusted upstream, not like a harmless artifact. Review the schema source, sanitise names before generation, and restrict who can contribute or alter schemas that feed build-time code generation. The key question is whether the generator can turn data into executable instructions.
Technical breakdown
How schema values become generated JavaScript
protobuf.js does not only deserialize data. It also builds encoder and decoder functions from schema objects, then compiles those functions with Function(). That design is fast, but it means a field name, type name, or namespace can influence emitted source code if the library fails to validate or escape it correctly. Once a string reaches string interpolation in generated code, the data boundary is gone and the library is no longer processing metadata, it is executing code shaped by that metadata.
Practical implication: treat schema compilation paths as code-generation surfaces, not parser surfaces.
Why prototype pollution turns lookup into execution
One exploit path depends on JavaScript prototype inheritance. protobuf.js used plain objects for lookup tables, so a polluted Object.prototype could make an attacker-controlled value appear to be a legitimate primitive type. The library then inserted that value into generated code without adequate escaping. This is the classic failure mode of assuming object-property lookups are safe when inherited properties can alter the result of a trust decision.
Practical implication: use prototype-safe data structures and reject inherited-property lookups in schema resolution.
How static generation widens the supply-chain blast radius
The pbjs CLI creates JavaScript files from schemas ahead of time. In that model, malicious schema names can be written into generated source, then executed later when the file is imported. That changes the threat from in-process exploitation to build-time code injection, which is far more serious in CI/CD because the attacker may inherit the privileges of the build environment, including secrets, tokens, and signing material.
Practical implication: apply the same review and sanitisation standards to generated artifacts that you apply to source code.
Threat narrative
Attacker objective: The attacker aims to turn schema-controlled input into code execution inside application or build infrastructure, or to crash the target repeatedly through crafted recursive payloads.
- Entry occurs when attacker-controlled schema data or payloads reach protobuf.js through untrusted inputs, contributed schemas, or generated build artifacts.
- Credential-like trust is abused when polluted object properties or crafted schema names are accepted as valid type or namespace values during schema resolution.
- Escalation happens when those values are interpolated into generated JavaScript and compiled with Function() or emitted into static output.
- Impact is remote code execution inside the Node.js process or code execution during build and import, with denial of service as a parallel outcome.
Breaches seen in the wild
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
- Mastra npm Supply Chain Attack — Sapphire Sleet: North Korean Sapphire Sleet backdoors 144 AI npm packages in 88 minutes via supply chain attack on Mastra ecosystem.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Metadata-to-code is now a governance boundary, not a library detail: protobuf.js shows that schema values cannot be treated as inert configuration once a library turns them into executable functions. The practical lesson is that any schema compilation boundary needs explicit trust classification, because the failure mode is not just parsing error, it is code generation from untrusted input. Practitioners should classify schema-to-code paths as high-risk execution surfaces.
Prototype-safe lookups are a control requirement, not an implementation preference: the vulnerable resolution logic depended on ordinary object inheritance, which let polluted prototypes influence trust decisions. That is a control gap, because plain-object lookups are structurally unsafe when attacker-controlled pollution can occur elsewhere in the process. Teams should re-evaluate every place they rely on inherited property behaviour to validate identity, type, or permission data.
Build pipelines must govern generated JavaScript as privileged output: pbjs demonstrates that generated files can become an attack carrier when external schemas are accepted upstream. The important concept here is schema-to-code trust debt, where metadata ownership and execution privilege have drifted apart. Practitioners should treat generated artifacts as supply-chain outputs that require review, signing, and provenance controls.
Untrusted schemas collapse the assumption that metadata is non-executable: that assumption was designed for environments where schemas are authored internally and remain bounded by static release processes. It fails when contributors, tenants, or upstream registries can influence schema shape, because the library may transform that input into runtime code. The implication is that governance models must separate trusted schemas from externally influenced schemas before compilation begins.
Denial of service is the companion failure when code generation is not the only risk: recursion depth and unsafe option paths show that schema input can break availability even when it never reaches an explicit code execution sink. That widens the governance scope beyond code injection. Practitioners should therefore treat schema validation, recursion limits, and generated-code safety as one control family rather than isolated fixes.
What this signals
Schema-to-code trust debt: when a parser also generates executable functions, the governance problem is no longer just input validation. Teams need to classify which schemas are truly trusted, which are influenced by tenants or contributors, and which must never cross into code generation without review.
The most important programme question is not whether protobuf.js can be exploited, but whether any of your own libraries perform similar metadata-to-code conversion. That pattern appears in build tools, templating layers, and generated client code, so application security reviews should extend to generation boundaries, not stop at runtime validation.
For practitioners
- Enforce trusted-schema boundaries Separate internally authored schemas from externally influenced schemas, and route any untrusted source through review before it reaches protobuf compilation or generation.
- Replace plain-object lookups Use prototype-safe lookup patterns for type resolution and option traversal so inherited properties cannot change validation outcomes in schema loading paths.
- Sanitise generated output paths Inspect every field, namespace, service, and type name that can reach emitted JavaScript, and reject characters that can alter source syntax.
- Cap recursive decoding depth Set explicit nesting limits for recursive protobuf messages so untrusted payloads cannot exhaust the Node.js stack or trigger retry loops.
- Review generated artifacts as release assets Require review and provenance controls for pbjs output before it enters CI, testing, or deployment workflows, especially when schemas come from outside contributors.
Key takeaways
- protobuf.js exposed a class of failures where schema-controlled data could become executable JavaScript or crash the process through recursion.
- The article ties the issue to six vulnerabilities, including prototype-pollution-assisted code execution and static code injection in pbjs output.
- Teams should treat schema compilation, generated artifacts, and recursion limits as governed security controls rather than implementation details.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Schema-controlled strings reach executable output through unsafe trust boundaries and generation paths. |
| NHI-06 — Insecure Cloud Deployment Configurations | The attack surface includes build and runtime deployment paths that execute generated code from untrusted input. | |
| Recommendation — Audit schema compilation paths for unsafe input handling and remove any code-generation sink that accepts untrusted values. Restrict generated artifacts from entering build and deployment flows unless their provenance is verified. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The article’s threat model includes code execution, crash loops, and downstream infrastructure impact. |
| Recommendation — Map schema-injection findings to code-execution impact paths and hunt for build or runtime compromise indicators. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-Rest Is Protected | Schemas and generated artifacts need protection at the trust boundary where data becomes executable output. |
| Recommendation — Apply data-protection controls to schemas and generated files before they can influence execution. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article’s build and runtime compromise paths can expose tokens and secrets once code executes in trusted environments. |
| Recommendation — Rotate credentials exposed to build-time code execution and enforce strict secret-lifecycle controls. | ||
Key terms
- Schema-to-code boundary: The point where structured data is converted into executable source or runtime logic. In practice, this boundary is fragile because untrusted names, types, or descriptors can affect what code is emitted or run, so it needs code-level validation, escaping, and review.
- Prototype Pollution: Prototype pollution is a JavaScript bug where attacker-controlled keys modify Object.prototype or another shared prototype. That makes the injected property visible to many objects that were never directly touched by the attacker. In security terms, it creates hidden state that later code may treat as trusted configuration.
- Generated artifact provenance: Evidence that a generated file came from an approved source, toolchain, and input set. For schema-driven build pipelines, provenance matters because the output may execute later with privileged access, so teams need to know who supplied the schema and how the artifact was produced.
- Recursion depth control: A limit on how many nested structures a parser or decoder will process before stopping. In protobuf and similar formats, depth control prevents crafted payloads from exhausting stack space or trapping systems in repeated crash-and-retry loops, especially when the input is untrusted.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org