protobuf.js CVE-2026-44291

Exploitation requires four specific preconditions to be met sequentially. First, the application or one of its dependencies must contain a reachable prototype pollution vulnerability (e.g., unsafe JSON.parse, recursive object merge functions like lodash merge without proper guards, or vulnerable dependencies with prototype pollution flaws). Second, the polluted property keys must match the specific internal type lookup keys used by protobufjs code generation logic-attackers must understand protobufjs internals to craft effective pollution payloads. Third, the application must invoke protobufjs functionality that dynamically generates encode or decode functions for message types (static/pre-built code generation is not affected). Fourth, the code generation and execution must occur after Object.prototype pollution is established and while the polluted state persists-pollution must survive until the generated code path is reached. Limiting factors: Applications using Object.freeze(Object.prototype), applications performing only build-time code generation (not runtime), and applications without prototype pollution attack surface are not exploitable. Default configurations of protobufjs alone do not enable exploitation-an external prototype pollution primitive is mandatory.

Real-world risk is moderate despite CVSS 8.1 (High). The CVSS vector AV:N/AC:H/PR:N/UI:N indicates network-accessible remote exploitation without authentication, but AC:H (high complexity) accurately reflects the multi-stage attack requirement: attackers must first achieve prototype pollution through a separate vulnerability, then trigger protobufjs code generation with the polluted state intact. This is not a standalone vulnerability but an exploitation gadget requiring chaining. EPSS and KEV data not provided in input, but absence from CISA KEV and no public POC reference suggests limited in-the-wild exploitation. High impact ratings (C:H/I:H/A:H) are valid if exploitation succeeds, as arbitrary JavaScript execution grants full process control. SSVC decision factors: exploitation requires multiple preconditions (not automatable as standalone), technical impact is total system compromise (code execution), but exploitation status appears proof-of-concept at most. Priority depends heavily on whether the application has reachable prototype pollution primitives-applications hardened against prototype pollution (frozen prototypes, defensive coding) are not exploitable through this issue alone. Security teams should prioritize patching if using protobufjs AND the application accepts untrusted JSON/object inputs without prototype pollution defenses.

An attacker targets a Node.js API service using protobufjs 7.5.5 for gRPC message handling. The service has a separate JSON merge vulnerability allowing prototype pollution via POST /api/config endpoint. The attacker first sends a malicious JSON payload that pollutes Object.prototype with crafted properties matching protobufjs internal type lookup keys. When a legitimate user subsequently triggers protobuf message encoding (e.g., via GET /api/data), protobufjs generates encode functions that resolve the polluted properties as type metadata, injecting attacker-controlled JavaScript into the generated code. When the generated encoder executes, the injected code runs with the service's privileges, allowing the attacker to exfiltrate environment variables, access internal APIs, or establish a reverse shell. Exploitation requires the attacker to control both the pollution primitive and influence the timing/type of protobuf operations, but no authentication is required if endpoints are publicly accessible.