CVE-2026-44293

What it actually does

The flaw is a code generation vulnerability in protobufjs. When protobufjs compiles Protocol Buffers definitions into JavaScript conversion functions, a crafted schema descriptor can place attacker-controlled JavaScript into the generated toObject conversion logic through an unsafe expression derived from a bytes field default value. If an application accepts or processes untrusted protobuf schemas, descriptors, or reflection data and then generates or executes conversion functions, the attacker can achieve remote code execution in the Node.js process or other JavaScript runtime running protobufjs. The issue requires the attacker to influence the protobuf definition or descriptor being compiled; it is not typically triggered by ordinary protobuf message data alone.

Why it matters to the business

Successful exploitation can allow an attacker to run code inside applications that compile untrusted protobuf schemas, potentially leading to service compromise, data theft, credential exposure, lateral movement, or disruption of business services. The risk is highest for developer platforms, API gateways, schema registries, build systems, ingestion pipelines, plugin systems, and multi-tenant services that accept user-supplied protobuf definitions. EPSS is currently low and the vulnerability is not in the CISA KEV catalog, but the CVSS severity is high because exploitation can result in full compromise of the affected application process when the vulnerable code path is reachable.

How an attack unfolds

An attacker first identifies an application or service that uses vulnerable protobufjs versions before 7.5.6 or 8.0.2 and allows a user, tenant, integration, plugin, or upstream feed to provide protobuf schemas or descriptors. The attacker submits a crafted protobuf descriptor containing a bytes field with a malicious non-string default value designed to break out of the intended generated expression. When the application compiles the descriptor, protobufjs emits JavaScript for the toObject conversion function that includes attacker-controlled code. When that generated conversion function is created or invoked, the embedded JavaScript executes with the privileges of the application process. From there, the attacker may read environment variables, access files available to the process, make outbound network connections, tamper with data, or use the compromised process as a foothold for further activity.

How to fix it

Upgrade protobufjs to a fixed release: 7.5.6 or later on the 7.x line, or 8.0.2 or later on the 8.x line. Ensure all direct and transitive dependencies resolve to a fixed version by updating lockfiles and rebuilding artifacts. If immediate upgrade is not possible, prevent untrusted users or external systems from supplying protobuf schemas, descriptors, or reflection data to protobufjs code-generation paths. Treat protobuf definitions as code, not as ordinary data. Disable dynamic schema compilation where feasible, precompile trusted schemas during build time, and validate schema sources against an allowlist. Run affected services with least privilege, restrict outbound network access, and avoid exposing secrets in the runtime environment to reduce post-exploitation impact.

How to confirm the fix worked

Confirm package resolution with dependency tooling such as npm ls protobufjs, yarn why protobufjs, pnpm why protobufjs, or software composition analysis. The effective installed version should be 7.5.6 or later for 7.x, or 8.0.2 or later for 8.x. Check lockfiles, container images, serverless bundles, and build artifacts for bundled copies of protobufjs. Review application code for dynamic use of protobufjs schema loading and code generation, including load, loadSync, Root.fromJSON, Type.fromJSON, parse, setup, toObject, and generated conversion paths. Validate that untrusted protobuf definitions cannot reach compilation paths. As a functional test, run regression tests covering protobuf schema loading and toObject conversion after upgrade. For exposure testing, attempt to submit malformed descriptors only in authorized test environments and confirm they are rejected or do not produce executable injected code.

Typical attack path

1. Find a service, API, plugin interface, build workflow, or ingestion pipeline that uses protobufjs to compile protobuf schemas or descriptors.
2. Confirm the target accepts or processes attacker-controlled protobuf definitions, descriptors, reflection output, or schema packages.
3. Craft a protobuf descriptor with a bytes field default value that causes unsafe JavaScript to be emitted during toObject conversion code generation.
4. Submit the crafted schema or descriptor to the target system.
5. Trigger schema compilation and creation or invocation of the generated toObject conversion function.
6. Execute attacker-controlled JavaScript in the application runtime.
7. Use the compromised process to access secrets, data, files, network resources, or to establish persistence depending on runtime permissions.

How to detect it

Look for evidence that untrusted protobuf schemas or descriptors were submitted shortly before suspicious Node.js behavior. Relevant log sources include application request logs, API gateway logs, schema registry or plugin upload logs, CI/CD build logs, package ingestion logs, container logs, Node.js application stderr/stdout, EDR telemetry, process creation logs, DNS logs, proxy logs, and cloud audit logs. Focus on events involving protobuf schema parsing, descriptor imports, dynamic code generation, or toObject conversion errors. Investigate suspicious child processes spawned by Node.js, such as shell, curl, wget, PowerShell, Python, or netcat, especially if they occur after schema upload or compilation activity. Review submitted .proto files, descriptor JSON, or schema packages for bytes fields with unusual default values, JavaScript syntax, function bodies, process access, child_process references, template-breaking characters, or encoded payloads. Network indicators may include unexpected outbound connections from application workers immediately after schema compilation. File artifacts may include newly written scripts in temporary directories, modified package artifacts, dropped web shells, or unexpected changes to build outputs. There are no universal exploit strings because payloads are attacker-controlled, so detection should combine schema-content inspection with runtime behavior analytics.

• protobufjs
• bytes
• default
• toObject
• Root.fromJSON
• Type.fromJSON
• loadSync
• child_process
• require("child_process")
• require('child_process')
• process.env
• process.mainModule
• Function(
• eval(
• constructor.constructor
• /bin/sh
• /bin/bash
• cmd.exe
• powershell.exe
• curl
• wget
• nc
• netcat
• /tmp/
• /var/tmp/

What your security team should do

• Prioritize upgrading protobufjs to 7.5.6 or later, or 8.0.2 or later, in all applications and build pipelines.
• Identify services that accept user-supplied protobuf schemas, descriptors, plugins, API definitions, or integration packages; treat those as highest priority.
• Search dependency manifests, lockfiles, SBOMs, container images, and packaged application bundles for vulnerable protobufjs versions before 7.5.6 and 8.0.2.
• Restrict dynamic protobuf schema compilation to trusted sources only and prefer build-time precompilation of schemas.
• Add input validation or allowlisting for protobuf descriptors and reject bytes fields with unexpected or non-string default values where applicable.
• Review runtime privileges for affected services, especially access to secrets, filesystem paths, metadata services, and outbound network destinations.
• Monitor for suspicious Node.js child process creation, unexpected outbound connections, and errors during protobuf schema compilation or toObject conversion.
• Because this is not currently KEV-listed and EPSS is low, schedule remediation based on exposure: internet-facing or multi-tenant schema-processing services should be fixed urgently, while internal trusted-schema-only use can follow normal high-severity patch timelines.