CVE-2025-4565

What it actually does

CVE-2025-4565 is a denial-of-service weakness in the pure-Python Protocol Buffers parser. When an application parses untrusted protobuf data containing deeply recursive groups, recursive messages, or long sequences of SGROUP tags, parsing can exceed Python's recursion limit. The immediate technical result is typically a RecursionError or parser failure; depending on how the application handles the exception, this can terminate a request handler, crash a worker process, trigger repeated restarts, or make the service unavailable to legitimate users. The issue affects projects using the pure-Python protobuf backend to parse attacker-controlled protobuf payloads; applications using non-Python backends or not accepting untrusted protobuf input are less exposed.

Why it matters to the business

Successful exploitation can interrupt services that ingest Protocol Buffers messages, especially APIs, message-processing workers, gateways, and backend services that parse external or partner-supplied protobuf payloads. The likely business consequence is service degradation or outage rather than data theft. EPSS is low at 0.00251, there is no CISA KEV listing, and no ransomware use is indicated, so this should be prioritized based on exposure: internet-facing or high-volume protobuf parsers should be remediated promptly, while internal-only uses may be handled through normal patch cycles. Because protobuf is widely embedded in application stacks and dependencies, organizations should also check transitive usage rather than only directly declared packages.

How an attack unfolds

An attacker first identifies an application endpoint, queue, RPC interface, file upload path, or message consumer that accepts Protocol Buffers data and uses the pure-Python protobuf parser. The attacker then sends a specially malformed protobuf payload with excessive recursive groups, recursive messages, or repeated SGROUP tags. During deserialization, the parser follows the recursive structure until Python's recursion limit is exceeded. If the application does not reject the payload early or recover cleanly from the exception, the affected request, worker, or service process may fail. Repeating the request can keep workers crashing or busy, causing denial of service. No authentication bypass or code execution is implied by the provided description; exploitation is focused on availability disruption.

How to fix it

Upgrade affected protobuf implementations to a fixed version. For protocolbuffers/protobuf from Git, update to a version containing commit 17838beda2943d08b8a9d4df5b68f5f04f26d901 or later. For Mageia 4 x11-server packaging, update to 1.14.5-2.1.mga4 or later where applicable. In addition to patching, reduce exposure by rejecting untrusted protobuf payloads that exceed reasonable size or nesting limits, enforcing request body size limits, validating message schemas before deep parsing where possible, rate-limiting unauthenticated protobuf ingestion endpoints, and ensuring parser exceptions are handled without crashing long-running worker processes. Where operationally feasible, avoid the pure-Python backend for untrusted high-volume parsing if a maintained backend with safer recursion handling is available.

How to confirm the fix worked

Confirm dependency versions through package manifests, lockfiles, container images, SBOMs, and runtime package inspection. Verify that protocolbuffers/protobuf includes commit 17838beda2943d08b8a9d4df5b68f5f04f26d901 or a later fixed release, and verify Mageia packages are at x11-server 1.14.5-2.1.mga4 or later if relevant. Exercise representative protobuf ingestion paths with benign validation tests that include oversized, malformed, and deeply nested inputs, and confirm the service returns controlled client errors rather than crashing, restarting, or logging unhandled RecursionError exceptions. Review deployment telemetry after upgrade for absence of repeated protobuf parsing exceptions and stable worker uptime under malformed-input testing.

Typical attack path

1. Find an externally reachable or otherwise accessible service that accepts Protocol Buffers input.
2. Confirm or infer that the service uses the pure-Python protobuf backend for deserialization.
3. Craft a protobuf payload containing deeply recursive groups, recursive messages, or repeated SGROUP tags.
4. Submit the payload through an API request, RPC call, message queue, file upload, or other protobuf ingestion path.
5. Trigger Python recursion-limit exhaustion during protobuf parsing.
6. Repeat delivery to cause worker crashes, repeated exceptions, increased error rates, or service unavailability.

How to detect it

To determine whether exploitation has already occurred, review application logs, exception telemetry, APM traces, container logs, systemd or supervisor restart logs, API gateway logs, WAF logs, and message broker dead-letter or retry queues for malformed protobuf submissions followed by recursion-limit exceptions, worker crashes, or elevated 5xx responses. Focus on endpoints or consumers that accept protobuf content types, gRPC traffic, serialized message uploads, or queue messages. Look for repeated requests from the same source that produce RecursionError exceptions, protobuf decoder stack traces, abnormal worker restarts, or request bodies rejected after deep parsing. In containerized environments, correlate timestamps of protobuf parsing exceptions with pod restarts, crash loops, liveness-probe failures, and CPU spikes. There are no known unique attacker infrastructure indicators from the provided data; detections should be behavior-based and exception-based rather than IP- or domain-based.

• RecursionError: maximum recursion depth exceeded
• maximum recursion depth exceeded while calling a Python object
• google.protobuf.internal.decoder
• google.protobuf.message.DecodeError
• SGROUP
• START_GROUP
• END_GROUP
• Content-Type: application/x-protobuf
• Content-Type: application/protobuf
• Content-Type: application/grpc
• CrashLoopBackOff
• Back-off restarting failed container

What your security team should do

• Inventory services, APIs, queues, workers, and file processors that parse untrusted Protocol Buffers data in Python.
• Prioritize remediation for internet-facing, partner-facing, unauthenticated, or high-volume protobuf ingestion paths.
• Upgrade protocolbuffers/protobuf to a fixed build containing commit 17838beda2943d08b8a9d4df5b68f5f04f26d901 or later, and apply Mageia x11-server 1.14.5-2.1.mga4 or later where applicable.
• Add request size, message depth, and rate limits around protobuf ingestion points, especially before deserialization.
• Harden error handling so protobuf parser exceptions cannot terminate persistent workers or trigger cascading restarts.
• Search application and platform logs for recursion-limit errors associated with protobuf parsing, spikes in 4xx/5xx responses, worker restarts, and repeated malformed payload submissions.
• Because the CVE is not KEV-listed, has low EPSS, and has no indicated ransomware use, treat broad patching as normal priority unless the affected parser is exposed to untrusted traffic.