CVE-2026-44289

What it actually does

This flaw is an unauthenticated denial-of-service vulnerability in protobufjs decoding logic. Before versions 7.5.6 and 8.0.2, protobufjs could recursively decode deeply nested protobuf structures without enforcing a safe recursion-depth limit. A maliciously crafted protobuf binary payload containing excessive nesting, including nested message fields or unknown group fields that are skipped during parsing, can exhaust the JavaScript call stack. In Node.js or browser-based JavaScript runtimes, this typically causes a RangeError or decoding failure and may crash the affected process, terminate a request handler, or make the service unavailable depending on how errors and worker restarts are handled.

Why it matters to the business

Applications, APIs, gateways, message processors, or backend services that accept protobuf-encoded input using vulnerable protobufjs versions can be disrupted by a small crafted request or message. Because exploitation is network-reachable, requires no authentication, and has low complexity, exposed services may suffer outages, degraded availability, retry storms, queue backlogs, or cascading failures in systems that depend on protobuf message processing. The issue is not currently listed in CISA KEV, has no known mature public exploit reported in the supplied data, and has a relatively low EPSS score, but its impact is still operationally significant for internet-facing or high-throughput services that parse untrusted protobuf data.

How an attack unfolds

An attacker first identifies an endpoint, service, queue consumer, WebSocket interface, RPC method, or API path that accepts protobuf-encoded data and uses protobufjs to decode it. The attacker then constructs a protobuf binary payload with intentionally excessive nesting, either through nested message fields or group-field structures that trigger recursive skip logic. When the vulnerable application attempts to decode the payload, protobufjs recurses repeatedly without a protective depth limit until the JavaScript runtime call stack is exhausted. The resulting exception or process instability can interrupt request processing, crash a worker, restart a service, or consume operational capacity through repeated failures. Repeated delivery of the payload can sustain a denial of service even if supervisors automatically restart the affected process.

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. Review package-lock.json, yarn.lock, pnpm-lock.yaml, and transitive dependency trees to ensure no vulnerable protobufjs versions remain bundled through indirect dependencies. Rebuild and redeploy applications after dependency updates. Where immediate upgrade is not possible, reduce exposure by rejecting untrusted protobuf input at network boundaries, enforcing request-size and message-depth limits where feasible, isolating protobuf decoding in worker processes with restart limits, applying rate limits to protobuf-facing endpoints, and adding robust exception handling so decode failures do not terminate the main service process. Treat mitigations as temporary because the durable fix is upgrading the library.

How to confirm the fix worked

Confirm that all deployed applications resolve protobufjs to version 7.5.6, 8.0.2, or newer. Validate with dependency tooling such as npm ls protobufjs, yarn why protobufjs, pnpm why protobufjs, software composition analysis, and container image scans. Inspect lockfiles and production artifacts rather than only package.json, because protobufjs may be included transitively. Exercise protobuf-handling endpoints in a non-production environment with malformed and deeply nested test inputs to confirm the service rejects or safely handles excessive nesting without crashing or exhausting the call stack. Monitor post-upgrade logs for absence of recurring protobuf decode RangeError events and confirm service health under malformed-input tests.

Typical attack path

1. Identify an externally reachable or otherwise accessible service that accepts protobuf-encoded input.
2. Determine or infer that the service uses protobufjs versions earlier than 7.5.6 or 8.0.2 for message decoding.
3. Craft a protobuf binary payload with deeply nested message fields or unknown group fields designed to trigger unbounded recursive decoding or skipping.
4. Send the crafted payload to the vulnerable API, RPC endpoint, stream, message broker topic, or consumer input path.
5. Trigger JavaScript call stack exhaustion during protobuf decoding, commonly resulting in a RangeError or process-level failure.
6. Repeat delivery of the crafted payload to maintain service disruption, exhaust worker capacity, or create queue backlogs.

How to detect it

To determine whether exploitation has already occurred, review application logs, process supervisor logs, container logs, API gateway logs, load balancer telemetry, message broker dead-letter queues, and APM traces for bursts of protobuf decoding failures followed by process crashes, worker restarts, elevated 5xx responses, queue backlogs, or container restart loops. Focus on endpoints or consumers that parse protobuf binary data. Look for JavaScript runtime errors indicating call stack exhaustion, especially RangeError messages occurring during protobufjs decode, Reader skip, skipType, or generated decode functions. Correlate these errors with source IPs, client identifiers, request paths, message topics, payload sizes, and repeated delivery patterns. Because the exploit payload is binary and application-specific, reliable network-only IOCs are limited; behavioral evidence such as repeated malformed protobuf requests causing RangeError exceptions and restarts is more useful than payload matching.

• RangeError: Maximum call stack size exceeded
• Maximum call stack size exceeded
• protobufjs
• Reader.skipType
• skipType
• decode()
• at Type.decode
• at Reader.skip
• at Reader.skipType
• UnhandledPromiseRejectionWarning: RangeError: Maximum call stack size exceeded
• RangeError [ERR_STACK_OVERFLOW]
• FATAL ERROR: Ineffective mark-compacts near heap limit
• container restart after protobuf decode failure
• CrashLoopBackOff
• HTTP 500 with protobuf decode error

What your security team should do

• Inventory all services, containers, serverless functions, and frontend bundles that include protobufjs, including transitive dependency usage.
• Prioritize upgrades for internet-facing APIs, RPC services, message consumers, gateways, and any component that decodes protobuf data from untrusted or semi-trusted sources.
• Upgrade protobufjs to 7.5.6 or later, or 8.0.2 or later, and verify effective deployed versions from lockfiles and runtime artifacts.
• Add or tune rate limiting, request-size limits, queue-consumer throttling, and crash-loop protections around protobuf-ingesting services.
• Add monitoring for JavaScript call stack exhaustion, protobuf decode failures, worker restarts, container restarts, and sudden spikes in malformed protobuf traffic.
• Review error-handling paths so a single malformed protobuf message cannot terminate the primary application process.
• If protobuf input is accepted from partners or public clients, document and enforce input constraints and reject unexpected message types or oversized payloads at the edge.