CVE-2026-54269

What it actually does

protobufjs versions before 8.6.0 and 7.6.3 do not sufficiently validate schema-derived names when compiling protobuf definitions into JavaScript helpers. A malicious or malformed protobuf schema, especially one loaded through JSON/reflection descriptors, can define fields, oneofs, or service methods using names that collide with protobufjs runtime helper properties such as hasOwnProperty, $type, or rpcCall. When the affected message or service type is decoded, verified, converted to objects, serialized through reflection JSON, or invoked through protobufjs RPC helpers, the runtime may read attacker-controlled schema data instead of the expected helper or metadata property. The practical impact is denial of service through deterministic exceptions or recursive calls; confidentiality and integrity impact are not expected from the published description.

Why it matters to the business

Applications, APIs, build tools, or services that accept or process untrusted protobuf definitions can be made to fail reliably, causing request errors, service instability, failed data processing, or outages in protobuf-dependent workflows. The CVSS score is moderate and EPSS is currently low, and the issue is not listed in CISA KEV, but protobufjs is commonly embedded in JavaScript and Node.js ecosystems, so exposure may exist indirectly through dependencies even where the package is not used explicitly.

How an attack unfolds

An attacker first needs a path to influence the protobuf schema or descriptor processed by an affected protobufjs version. This is most relevant where an application imports protobuf definitions from users, partners, plugins, remote registries, generated JSON descriptors, or reflection-based service metadata. The attacker supplies a schema containing one of the problematic names, such as a field named hasOwnProperty, a field or oneof name such as $type in a JSON/reflection descriptor, or a service method whose generated helper name becomes rpcCall. When the application later uses the affected message or service type, protobufjs generated/runtime code collides with those schema-controlled names. Instead of calling or reading the intended internal helper or metadata, protobufjs reads the schema-derived property, which can cause predictable exceptions or recursion during decode post-checks, verification, object conversion, reflected JSON serialization, or RPC helper invocation. The result is typically application-level denial of service rather than code execution.

How to fix it

Upgrade protobufjs to a fixed release: 8.6.0 or later for the 8.x line, or 7.6.3 or later for the 7.x line. Also update protobufjs-cli where it is present, because generated artifacts and descriptor workflows may be affected. If direct upgrade is delayed, reduce exposure by rejecting untrusted protobuf schemas and JSON/reflection descriptors containing reserved or collision-prone names such as hasOwnProperty, $type, and service helper names that generate rpcCall. Treat externally supplied schemas as untrusted input, validate them before loading, and avoid dynamically compiling protobuf definitions from unauthenticated or low-trust sources. Rebuild and redeploy applications after dependency updates, and regenerate any protobufjs-generated code if the build process embeds generated output.

How to confirm the fix worked

Confirm that dependency manifests and lockfiles resolve protobufjs to 8.6.0 or later, or 7.6.3 or later, including transitive uses through protobufjs-cli or other packages. Use package-manager inspection commands such as npm ls protobufjs protobufjs-cli, yarn why protobufjs, or pnpm why protobufjs across source repositories and deployed artifacts. Validate runtime containers or serverless bundles, not only source trees, because protobufjs may be bundled. As a functional validation, load a test descriptor containing the previously problematic names in a non-production test harness and confirm the patched version rejects or safely handles it without recursive calls or deterministic exceptions. Review CI/CD output to ensure regenerated code and packaged artifacts use the patched dependency version.

Typical attack path

1. Identify an application, API, build pipeline, plugin system, or service that processes protobuf schemas or JSON/reflection descriptors using protobufjs before 8.6.0 or 7.6.3.
2. Submit or cause ingestion of a protobuf definition or descriptor containing a colliding schema-derived name such as hasOwnProperty, $type, or rpcCall.
3. Trigger application functionality that decodes, verifies, converts, serializes, or invokes RPC helpers for the affected message or service type.
4. Cause protobufjs runtime/helper logic to resolve the schema-controlled property instead of the intended internal helper or metadata.
5. Produce deterministic exceptions, recursion, failed requests, worker crashes, or service degradation depending on how the application handles the error.

How to detect it

Look for evidence that untrusted or newly introduced protobuf schemas/descriptors were processed shortly before application errors, worker restarts, request spikes, or failed RPC calls. Useful log sources include application logs, API gateway logs for schema upload or descriptor import endpoints, CI/CD build logs, package/build tool logs, container stdout/stderr, process supervisor logs, crash reports, and APM traces. Search for protobufjs stack traces or exceptions during decode, verify, toObject/fromObject conversion, reflected JSON serialization, or RPC helper invocation. Correlate failures with protobuf schema content containing the known colliding names hasOwnProperty, $type, or rpcCall. Because this vulnerability primarily causes availability impact, indicators are more likely to be repeated deterministic errors, recursion/stack overflow messages, or service restarts than persistent malware artifacts. There are no public KEV or named threat actor indicators in the provided intelligence, and no ransomware association is reported.

• hasOwnProperty
• $type
• rpcCall
• RangeError: Maximum call stack size exceeded
• TypeError: hasOwnProperty is not a function
• protobufjs
• protobufjs-cli

What your security team should do

• Inventory all JavaScript and Node.js applications, build tools, CLIs, and generated-code workflows that include protobufjs or protobufjs-cli, including transitive dependencies.
• Prioritize updates for internet-facing services, APIs, developer portals, plugin systems, schema registries, CI/CD jobs, and data-processing services that accept protobuf definitions or descriptors from outside a trusted codebase.
• Upgrade to protobufjs 8.6.0 or later, or 7.6.3 or later, and update protobufjs-cli where present.
• Add validation controls for protobuf schema ingestion to block reserved or collision-prone names such as hasOwnProperty, $type, and rpcCall-derived service helper names.
• Search logs for repeated protobuf processing exceptions, stack overflows, recursion errors, or crashes correlated with newly uploaded or remotely fetched protobuf descriptors.
• Add dependency scanning rules to flag protobufjs versions earlier than 8.6.0 on the 8.x line and earlier than 7.6.3 on the 7.x line.
• If untrusted schemas are not required for business functionality, disable dynamic schema loading and use only reviewed, version-controlled protobuf definitions.