Notifications
Clear all
Topic starter
09/06/2026 11:10 pm
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.
NHIMG editorial — based on content published by Cyera: Proto6, the schema was not supposed to run
By the numbers:
- protobuf.js has over 48 million weekly npm downloads.
Questions worth separating out
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.
Q: Why do schema-driven libraries create risk for non-human identity workflows?
A: Because they often run inside privileged service accounts, bots, CI jobs, or message consumers.
Q: How do security teams know when generated code is crossing a trust boundary?
A: Look for library behaviour that turns names, types, or descriptors into source text, then compiles that text at runtime or writes it into imported files.
Practitioner guidance
- Inventory schema-to-code paths Map every place protobuf schemas, JSON descriptors, or generated files enter runtime or CI.
- Block inherited object lookups Use null-prototype objects for lookup tables and reject prototype-linked properties in any schema resolution logic.
- Sanitise schema-derived identifiers before emission Treat every emitted namespace, service, enum, and field name as code input.
What's in the full article
Cyera's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact vulnerable code paths in protobuf.js and protobufjs-cli, including how type lookup and static code generation were exploited
- The six CVEs and their individual exploit conditions, so engineers can match exposure to the libraries they actually run
- Proof-of-concept paths for runtime crash loops in WhatsApp bots and cloud functions
- Patch versions and remediation notes for both the runtime library and the CLI generator
👉 Read Cyera's analysis of Proto6 and protobuf.js schema injection risks →
Proto6 schema injection: what it means for IAM and runtime risk?
Explore further
10/06/2026 1:25 am
Schema-to-code trust is the broken assumption here. protobuf.js was operating as if schema metadata stayed metadata, but the library turns that metadata into executable JavaScript. Once attacker influence reaches type names or namespace names, the boundary is no longer descriptive, it is executable. Practitioners should treat any schema compilation path as a code-generation control point, not a formatting step.
A few things that frame the scale:
- protobuf.js has over 48 million weekly npm downloads, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- Cyera’s findings sit in a broader environment where 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Should organisations treat protobuf libraries as security-sensitive components?
A: Yes, when they compile external or semi-trusted schemas, consume untrusted binary messages, or run in build pipelines. In those cases, protobuf libraries are part of the attack surface, and teams should govern them with the same care they apply to other code-generation or deserialisation boundaries.
👉 Read our full editorial: Proto6 schema injection exposes code execution in protobuf.js
