CVE-2026-48712

What it actually does

protobufjs versions before 7.6.1 and 8.4.1 can perform unbounded recursive conversion when decoded Protocol Buffer messages are transformed into plain JavaScript objects or JSON. The vulnerable paths include generated toObject() conversion logic and the custom JSON conversion handling for google.protobuf.Any. An unauthenticated network attacker can send a crafted protobuf binary payload containing deeply nested Any values, causing JavaScript call stack exhaustion, typically resulting in a RangeError and process failure or request-handling failure. The impact is availability only; the vulnerability does not directly provide confidentiality or integrity compromise.

Why it matters to the business

Services that accept protobuf input and convert messages to JSON or plain objects can be crashed or made unreliable by a malicious payload, causing outages, failed API requests, degraded background processing, or cascading failures in Node.js applications. The CVSS score indicates high availability impact, but EPSS is currently low and there is no known CISA KEV listing or ransomware association, so prioritization should focus first on internet-facing or high-throughput services that parse untrusted protobuf data.

How an attack unfolds

An attacker identifies an endpoint, message broker consumer, RPC handler, API gateway, or backend service that accepts protobuf-encoded input and uses protobufjs to decode it. The attacker crafts a protobuf binary message with deeply nested google.protobuf.Any structures. When the application decodes the message and converts it using toObject(), toJSON(), JSON.stringify() on a converted object, or equivalent protobufjs JSON conversion logic, the library recursively descends through nested values without an effective depth limit. The recursion exhausts the JavaScript call stack, throwing an exception such as RangeError: Maximum call stack size exceeded. If the application does not isolate or recover from the exception, the request handler, worker, or Node.js process may crash or become unavailable, enabling denial of service through repeated submissions.

How to fix it

Upgrade protobufjs to a fixed release: 7.6.1 or later for the 7.x line, or 8.4.1 or later for the 8.x line. Rebuild and redeploy applications, containers, lockfiles, and serverless packages so the patched dependency is actually present at runtime. If immediate upgrade is not possible, mitigate by rejecting or limiting deeply nested protobuf messages, enforcing strict maximum request sizes, applying schema validation before conversion, avoiding conversion of untrusted messages to JSON where unnecessary, wrapping conversion paths with exception handling, and isolating parsing work so a single malformed message cannot terminate the primary process. Network rate limiting and queue dead-lettering can reduce repeated crash attempts but should not be considered a complete fix.

How to confirm the fix worked

Confirm dependency resolution shows protobufjs 7.6.1 or later, or 8.4.1 or later, in all deployed artifacts. Check package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, container images, bundled JavaScript, and transitive dependencies. Run npm ls protobufjs, yarn why protobufjs, or pnpm why protobufjs as applicable. Exercise protobuf ingestion paths with benign protobuf messages and, in a controlled non-production environment, a deeply nested Any test case to verify the service rejects the payload or handles it without process termination. Review runtime logs after deployment to confirm the absence of recurring stack exhaustion errors during protobuf conversion.

Typical attack path

1. Find a service that accepts Protocol Buffer payloads from untrusted users or network clients.
2. Confirm or infer that the service uses protobufjs and converts decoded messages to plain objects or JSON.
3. Create a protobuf payload containing deeply nested google.protobuf.Any values.
4. Submit the crafted binary payload to the exposed endpoint, queue, or RPC method.
5. Trigger protobufjs to execute generated toObject() conversion or the Any JSON conversion path.
6. Cause JavaScript call stack exhaustion and an unhandled RangeError or process crash.
7. Repeat requests to maintain service disruption or exhaust worker capacity.

How to detect it

Look for evidence of attempted or successful denial of service rather than data theft. Relevant sources include application logs, Node.js uncaught exception logs, container stdout/stderr, process manager logs, Kubernetes pod restart events, API gateway logs, load balancer logs, message broker retry and dead-letter logs, APM traces, and crash dumps. Search for RangeError stack exhaustion events occurring during protobuf parsing, JSON conversion, toObject(), toJSON(), or google.protobuf.Any handling. Correlate these errors with bursts of requests from the same source, unusual binary payload submissions, repeated HTTP 5xx responses, worker exits, container restarts, queue retry storms, or elevated CPU followed by process termination. Because no public exploit campaign or KEV activity is known from the provided intelligence, prioritize anomaly-based detection around crash signatures and repeated malformed protobuf inputs.

• RangeError: Maximum call stack size exceeded
• Maximum call stack size exceeded
• at Type.toObject
• toObject()
• toJSON()
• google.protobuf.Any
• protobufjs
• uncaughtException
• UnhandledPromiseRejection
• JavaScript heap out of memory
• pod restarted
• CrashLoopBackOff
• worker exited with code 1
• process exited with code 1

What your security team should do

• Inventory applications, APIs, workers, and services that use protobufjs, especially those accepting protobuf data from external users, partners, queues, or untrusted internal sources.
• Prioritize upgrading internet-facing and business-critical services to protobufjs 7.6.1+ or 8.4.1+ and redeploy all dependent artifacts.
• Search dependency manifests and SBOMs for protobufjs versions below 7.6.1 in the 7.x line and below 8.4.1 in the 8.x line.
• Add input depth, size, and schema validation controls for protobuf payloads handled from untrusted sources.
• Ensure Node.js services run under process managers or orchestration that restarts failed workers while preserving crash telemetry for investigation.
• Add monitoring for spikes in RangeError, stack overflow, worker restarts, HTTP 5xx responses, queue retries, and malformed protobuf parsing failures.
• Create SIEM detections for repeated call stack exhaustion errors associated with protobuf conversion functions such as toObject, toJSON, Any, and protobufjs.
• Track upstream advisories and package manager alerts because protobufjs is commonly used transitively by other JavaScript and TypeScript packages.