CVE-2026-44291

What it actually does

protobufjs generated JavaScript encode/decode functions using internal lookup tables implemented as plain objects with inherited prototypes. If an attacker can first cause Object.prototype pollution in the same Node.js process, inherited attacker-controlled properties may be treated as legitimate protobuf type metadata. That polluted metadata can influence generated JavaScript source and may lead to arbitrary code execution when protobufjs compiles message definitions. The vulnerability requires a pre-existing prototype-pollution condition, which raises exploitation complexity, but successful exploitation can compromise confidentiality, integrity, and availability of the application process.

Why it matters to the business

Applications that use vulnerable protobufjs versions may be exposed to full server-side compromise if they also process attacker-controlled input capable of polluting JavaScript prototypes. A successful attack could allow data theft, service disruption, unauthorized modification of application behavior, or pivoting from the affected Node.js service into connected systems. The issue is not currently listed in CISA KEV, has low EPSS, and has no public exploit maturity reported, but the impact is high because protobufjs is commonly used directly and transitively in JavaScript application stacks.

How an attack unfolds

An attacker first identifies an application path where untrusted input is merged, parsed, or assigned in a way that can pollute Object.prototype, commonly through keys such as __proto__, constructor, or prototype. Once the prototype is polluted inside the running Node.js process, the attacker triggers protobufjs functionality that compiles protobuf definitions into JavaScript encode or decode functions. Vulnerable protobufjs versions use plain objects for internal type lookup tables, so polluted inherited properties can be resolved as if they were valid protobuf type information. If the attacker-controlled inherited value is incorporated into generated JavaScript, the compilation step can execute attacker-influenced code in the application context. Exploitation is therefore chained: prototype pollution is the enabling primitive, and protobufjs code generation is the execution sink.

How to fix it

Upgrade protobufjs to a fixed version: 7.5.6 or later on the 7.x line, or 8.0.2 or later on the 8.x line. Because protobufjs is often present as a transitive dependency, inspect package-lock.json, yarn.lock, pnpm-lock.yaml, and dependency manifests, then use dependency upgrades, npm overrides, Yarn resolutions, or pnpm overrides where necessary to force a fixed version. Rebuild and redeploy applications after updating dependencies. Also remediate any prototype-pollution sources in the application: reject or sanitize keys such as __proto__, constructor, and prototype; avoid unsafe recursive merge patterns; prefer Object.create(null) or Map for dictionaries; and use hardened parsing/merge libraries. If immediate upgrading is not possible, reduce risk by preventing untrusted users from supplying protobuf definitions or data that can influence protobufjs compilation, disabling dynamic schema compilation where feasible, and applying strict input validation before any object merge or deserialization step.

How to confirm the fix worked

Confirm that all deployed dependency trees resolve protobufjs to 7.5.6 or later, or 8.0.2 or later. Use package-manager tooling such as npm ls protobufjs, yarn why protobufjs, pnpm why protobufjs, npm audit, and software composition analysis to identify direct and transitive vulnerable copies. Verify lockfiles and deployed artifacts, not just package.json, because a fixed top-level manifest may still deploy an older resolved package. Run regression tests that exercise protobuf encoding, decoding, schema loading, and generated-function paths. Add negative tests for prototype-pollution payloads using keys such as __proto__, constructor, and prototype and confirm they do not alter Object.prototype. In production, confirm updated containers, serverless bundles, or application packages were rebuilt and restarted so the vulnerable library is no longer loaded in memory.

Typical attack path

1. Find a Node.js application using protobufjs before 7.5.6 or 8.0.2, directly or through a transitive dependency.
2. Identify an input path that accepts attacker-controlled JSON, configuration, schema, or request data and unsafely merges object properties.
3. Submit crafted input containing prototype-pollution keys such as __proto__, constructor, or prototype to modify Object.prototype in the application process.
4. Trigger protobufjs parsing, loading, encoding, decoding, or code-generation behavior after prototype pollution is present.
5. Cause polluted inherited properties to be interpreted as protobuf type metadata during generated function creation.
6. Achieve execution of attacker-controlled JavaScript in the Node.js process or cause application failure if code execution is not reliable.

How to detect it

To investigate possible exploitation, review application, API gateway, WAF, and load balancer logs for requests containing prototype-pollution keys such as __proto__, constructor, and prototype, especially in JSON bodies, query parameters, multipart fields, or configuration upload endpoints. Correlate those requests with Node.js application logs showing protobuf schema parsing, protobufjs encode/decode generation, unexpected JavaScript syntax errors, crashes, or restarts. Inspect error monitoring systems for exceptions occurring inside protobufjs code-generation, parse, encode, decode, or reflection paths after suspicious input was received. On hosts or containers, look for post-exploitation behavior from the Node.js process, including unexpected child processes, shell execution, outbound network connections, credential access, or new files written by the application account. Review dependency and deployment history to determine whether vulnerable protobufjs versions were present at the time of suspicious activity. If memory or heap snapshots are available, inspect whether Object.prototype contains unexpected enumerable properties or application-specific strings that should not exist on the global object prototype.

What your security team should do

• Inventory all JavaScript and Node.js services for protobufjs usage, including transitive dependencies in lockfiles and built artifacts.
• Prioritize upgrades for internet-facing services, services that parse untrusted JSON, services that dynamically load protobuf schemas, and long-running Node.js processes where prototype pollution can persist in memory.
• Upgrade protobufjs to 7.5.6 or 8.0.2 or later and redeploy affected applications.
• Search for and remediate prototype-pollution vulnerabilities in the same applications, because this issue depends on Object.prototype being polluted first.
• Add CI/CD dependency checks that fail builds when protobufjs resolves to versions older than 7.5.6 on 7.x or older than 8.0.2 on 8.x.
• Add application-layer validation or WAF rules to detect and block suspicious object keys such as __proto__, constructor, and prototype in request bodies where those keys are not expected.
• Review application telemetry for evidence of prior prototype-pollution attempts and unexpected protobufjs code-generation errors.
• Because this is not currently KEV-listed and EPSS is low, handle as high-impact but not mass-exploitation-priority unless the service is internet-exposed or processes untrusted object input.