CVE-2026-0994

What it actually does

The flaw is a denial-of-service condition in Python's google.protobuf.json_format.ParseDict() implementation. The parser is intended to enforce max_recursion_depth while converting JSON-like dictionaries into Protocol Buffer messages, but recursion depth is not consistently accounted for when processing nested google.protobuf.Any messages. If an application parses attacker-controlled protobuf JSON that includes deeply nested Any structures, the nesting can bypass the configured recursion limit and continue until Python's interpreter recursion limit is reached, raising RecursionError and interrupting request handling. In services that do not isolate parsing failures or that run parsing in critical worker processes, repeated malformed requests can exhaust worker capacity and degrade or deny service.

Why it matters to the business

Applications, APIs, ingestion pipelines, or message-processing services that accept untrusted protobuf JSON may be crashed or repeatedly disrupted by a small number of crafted requests. The primary consequence is availability loss: failed API requests, worker restarts, queue backlogs, degraded service-level objectives, and potential cascading failures in systems that depend on protobuf message parsing. Although this issue does not directly expose or modify data, its network-accessible, unauthenticated nature and high availability impact make it important for internet-facing or high-throughput services using Python protobuf parsing. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS at the time of assessment, so broad active exploitation is not indicated; however, exploitation is straightforward once an affected parsing endpoint is identified.

How an attack unfolds

An attacker first identifies an application endpoint, webhook, API, broker consumer, or file-ingestion path that accepts protobuf JSON and processes it with Python's google.protobuf.json_format.ParseDict(). The attacker then crafts a payload containing google.protobuf.Any values nested within one another. Because the Any-handling path does not correctly increment or enforce the parser's recursion-depth accounting, the payload bypasses the intended max_recursion_depth protection. When the application attempts to parse the payload, the parser recurses until Python reaches its interpreter recursion limit and raises RecursionError, commonly producing messages such as 'maximum recursion depth exceeded'. If the application treats this as an unhandled exception, terminates the worker, retries the same message, or consumes excessive capacity handling repeated failures, the attacker can cause sustained denial of service by sending the payload repeatedly or placing it into a processing queue.

How to fix it

Upgrade the Python google protobuf package to a version that contains the vendor fix once available from the package maintainer. No fixed version was provided in the supplied advisory data, so security teams should monitor the official protobuf release notes, PyPI package metadata, distribution advisories, and dependency-management alerts for the first patched version and deploy it promptly. Until patched, reduce exposure by rejecting untrusted protobuf JSON where possible, avoiding use of google.protobuf.Any for untrusted inputs, enforcing strict request-size and nesting-depth limits before calling ParseDict(), applying schema allowlists, placing parsing in isolated worker processes with safe failure handling, and rate-limiting endpoints that parse protobuf JSON. Ensure parsing exceptions are caught and converted into bounded client errors rather than causing worker termination or retries without backoff. For asynchronous consumers, configure poison-message handling so a single malformed message cannot be retried indefinitely.

How to confirm the fix worked

Inventory Python applications and containers for installed protobuf packages and verify whether they use google.protobuf.json_format.ParseDict() on untrusted or externally influenced input. Confirm the installed protobuf version against the first vendor-patched release when available. Validate mitigations by testing with benign deeply nested protobuf JSON containing nested Any fields in a non-production environment and confirming that the application rejects the payload with a controlled error before Python raises RecursionError. Review API gateways, application middleware, and queue consumers to confirm request-size, nesting-depth, rate-limit, and poison-message controls are active. After patching, rerun the same regression test and verify that max_recursion_depth is enforced consistently for nested Any handling.

Typical attack path

1. Identify a network-exposed or externally reachable application feature that accepts protobuf JSON input.
2. Confirm or infer that the service uses Python google protobuf json_format.ParseDict() to parse incoming data.
3. Craft a protobuf JSON object containing deeply nested google.protobuf.Any structures.
4. Submit the crafted payload to the vulnerable endpoint, queue, webhook, or ingestion workflow.
5. Trigger uncontrolled recursion during Any parsing, causing Python to raise RecursionError or terminate the active request/worker path.
6. Repeat delivery of the malformed payload to consume workers, cause restart loops, generate queue backlogs, or degrade service availability.

How to detect it

Look for evidence of repeated parser failures, service instability, or malformed input containing nested Any protobuf structures. Relevant sources include application logs, API gateway and reverse-proxy logs, container stdout/stderr, Python exception traces, APM error telemetry, worker supervisor logs, message-broker dead-letter queues, and crash/restart events from orchestration platforms. Search for RecursionError exceptions occurring in or near google.protobuf.json_format parsing functions, especially when paired with bursts of HTTP 400/500 responses, repeated requests from the same source, unusually large or deeply nested JSON bodies, or messages containing repeated '@type' fields associated with google.protobuf.Any. For queue-based systems, look for the same message being retried repeatedly, dead-lettered after parser exceptions, or causing consumer restarts. Because there are no known public exploitation campaigns or named threat actors in the supplied data, detection should focus on behavioral artifacts rather than actor-specific infrastructure.

• RecursionError: maximum recursion depth exceeded
• maximum recursion depth exceeded while calling a Python object
• google.protobuf.json_format.ParseDict
• google.protobuf.json_format.Parse
• google/protobuf/any.proto
• type.googleapis.com/google.protobuf.Any
• @type
• json_format.py
• _ConvertAnyMessage
• google.protobuf.any_pb2.Any
• Exception in google.protobuf.json_format
• Traceback (most recent call last)
• CrashLoopBackOff
• Back-off restarting failed container

What your security team should do

• Prioritize internet-facing APIs, webhook receivers, message-ingestion services, and queue consumers that parse protobuf JSON with Python protobuf.
• Search code repositories for use of google.protobuf.json_format.ParseDict(), json_format.Parse(), and google.protobuf.Any on untrusted input paths.
• Track upstream protobuf advisories and upgrade immediately when a fixed Python protobuf release is published; add dependency-management alerts for the protobuf package.
• Apply compensating controls now: request-size limits, JSON nesting-depth validation, schema allowlists, rate limiting, and safe exception handling around protobuf parsing.
• Ensure asynchronous processing systems use dead-letter queues or poison-message controls to prevent repeated parsing of the same malformed payload.
• Add observability for RecursionError spikes, worker restarts, HTTP 5xx bursts, and queue backlogs associated with protobuf parsing components.
• If suspicious activity is found, preserve request bodies or message samples where legally and operationally appropriate for forensic analysis and vendor reporting.