Summary
pbjs static code generation could emit unsafe JavaScript identifiers derived from schema-controlled names. When generating static JavaScript from a crafted schema or JSON descriptor, certain namespace, enum, service, or derived full names could be written into the generated output without sufficient sanitization.
Impact
An attacker who can provide or influence schemas passed to pbjs may be able to cause generated JavaScript output to contain attacker-controlled code. The injected code would run if the generated file is later executed or imported by the application or build process.
This affects the protobufjs CLI static code generation path. Applications that only use trusted schemas, or that do not execute generated output from untrusted schemas, are not directly affected.
Preconditions
- The application or build process must run pbjs static code generation on a schema or JSON descriptor influenced by an attacker. - The attacker-controlled input must contain crafted schema names that reach generated JavaScript output. - The generated JavaScript file must subsequently be executed, imported, or otherwise evaluated.
Workarounds
Do not run affected versions of pbjs static code generation on untrusted schemas or descriptors. If untrusted schemas must be accepted, validate schema names before code generation and run generation in an isolated environment.
Summary
A previous fix for unsafe name handling in pbjs static / static-module code generation was incomplete. Affected versions of protobufjs-cli could still emit unsafe JavaScript references when generating static output from crafted JSON descriptor input. The common case of parsing schemas from .proto files is not affected.
This is a bypass of GHSA-6r35-46g8-jcw9 / CVE-2026-44295.
Impact
An attacker who can provide or influence pre-parsed JSON descriptors passed to pbjs static code generation may be able to cause generated JavaScript output to contain attacker-controlled code.
The injected code may execute if the generated file is later executed or imported and an affected generated API path is invoked.
Preconditions
The application or build process must run pbjs static code generation on a pre-parsed JSON descriptor influenced by an attacker. The generated JavaScript file must subsequently be executed or imported. An affected generated API path must be invoked.
Workarounds
Do not run affected versions of pbjs static or static-module generation on untrusted JSON descriptors. If untrusted JSON descriptors must be accepted, validate descriptor-derived names before code generation and reject names that could not have been produced by parsing a valid .proto file. Running code generation in an isolated environment can reduce impact.
Summary
pbts invoked JSDoc by building a shell command string from input file paths and executing it through childprocess.exec. File paths containing shell metacharacters could therefore be interpreted by the shell instead of being passed to JSDoc as plain arguments.
Impact
An attacker who can control file names or paths passed to pbts may be able to execute arbitrary shell commands with the privileges of the process running pbts.
This affects the protobufjs CLI tooling path. The protobufjs runtime APIs for encoding, decoding, parsing, and loading protobuf messages are not directly affected by this issue.
Preconditions
- The application or user must invoke pbts on file paths influenced by an attacker. - The attacker must be able to supply or create a path containing shell-significant characters. - The vulnerable pbts version must execute the generated JSDoc command through a shell.
Workarounds
Do not run affected versions of pbts on attacker-controlled file names or paths. If this cannot be avoided, sanitize or rename input files before invoking pbts, or run the CLI in an isolated environment with minimal privileges.
Summary
protobufjs accepted certain schema-derived names that could collide with properties used by protobufjs runtime helpers. The known affected names are fields named hasOwnProperty, field or oneof names such as $type when loaded through protobufjs JSON/reflection descriptors, and service methods whose generated helper name is rpcCall.
When affected message or service types were used, protobufjs could read schema-controlled data where it expected an own-property helper, reflected type metadata, or the base RPC helper. This could cause deterministic exceptions or recursive calls in affected decode post-checks, verification, object conversion, reflected JSON serialization, or protobufjs RPC helper invocation.
Impact
An attacker who can provide or influence protobuf schemas or protobufjs JSON descriptors may be able to make affected message or service types unusable, resulting in denial of service for the affected processing path.
Applications using only trusted schemas are affected only if those schemas contain one of the problematic names and the application reaches the affected API path.
The issue is not known to allow code execution by itself.
Preconditions
The application must use an affected protobufjs version. The application must load or use a schema or protobufjs JSON descriptor containing one of the problematic names: a field named hasOwnProperty, a field or oneof named $type through protobufjs JSON/reflection descriptor input, or a service method whose generated helper name is rpcCall. The application must reach the affected API path for that name: required-field decode post-checks, verify, or toObject for hasOwnProperty; reflected message JSON serialization for $type; or protobufjs RPC service invocation for rpcCall.
Workarounds
Do not load protobuf schemas or protobufjs JSON descriptors from untrusted sources with affected versions. If untrusted schemas or descriptors must be accepted, validate schema-derived field, oneof, and service method names before loading and reject the problematic names described above.
Applications using trusted schemas can avoid the issue by renaming affected fields or service methods, or by avoiding the affected API path.