CVE-2025-68480

What it actually does

The vulnerability is a network-reachable denial-of-service condition in the Python marshmallow library when applications call Schema.load(data, many=True) on attacker-controlled input. A crafted or moderately sized payload containing many items can cause marshmallow versions 3.0.0rc1 through 3.26.1 and 4.0.0 through 4.1.1 to spend disproportionate CPU time during deserialization and validation. The flaw does not provide code execution, data disclosure, or data modification, but it can degrade availability of API workers, web processes, background jobs, or any service path that validates batch input with marshmallow.

Why it matters to the business

Applications that accept bulk JSON, form, or API payloads and deserialize them with marshmallow may become slow or unavailable under relatively low-volume attack traffic. The most likely consequence is service degradation, elevated infrastructure cost from autoscaling, failed transactions, delayed background processing, and customer-facing timeouts. The current public exploitation signal is low: it is not in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no reported exploit maturity in the provided data; however, marshmallow is commonly embedded as a dependency, so exposure may exist indirectly through frameworks or internal services.

How an attack unfolds

An attacker first identifies an HTTP endpoint, RPC method, webhook, file import, or other input path that accepts an array or batch of objects. If that path passes untrusted data into marshmallow using Schema.load(..., many=True), the attacker sends a specially shaped, moderately sized collection that triggers inefficient CPU behavior during deserialization and validation. Because the issue requires no authentication or user interaction when exposed on a public endpoint, repeated requests can tie up application worker threads or processes. As CPU utilization rises, response latency increases, queues back up, health checks may fail, and the service can become partially or fully unavailable until the malicious traffic stops, rate limits take effect, or the affected code is upgraded or isolated.

How to fix it

Upgrade marshmallow to a fixed release: use marshmallow 3.26.2 or later for the 3.x line, or marshmallow 4.1.2 or later for the 4.x line. If consuming the upstream source directly, include commit 1407d5102ae020421ddc8425474e976325a9539e or a later trusted revision. For Alpaquita stream linux-lts packages, update to 6.6.58-r0 or later as listed in the fixed version data. Rebuild and redeploy application containers, virtual environments, serverless packages, and dependency lockfiles so the fixed library is actually present at runtime. As compensating controls, enforce request body size limits, cap the maximum number of array elements accepted by endpoints that perform bulk loads, require authentication for bulk-processing paths where possible, apply per-client rate limits, set application worker timeouts, and reject unexpectedly nested or oversized JSON structures before marshmallow validation.

How to confirm the fix worked

Confirm dependency resolution shows a fixed marshmallow version: for Python environments, check pip freeze, pip show marshmallow, poetry.lock, Pipfile.lock, requirements files, SBOMs, and container image package inventories for versions older than 3.26.2 on the 3.x line or older than 4.1.2 on the 4.x line. Search application code for Schema.load calls using many=True on untrusted input and verify those paths have explicit request-size, item-count, and rate limits. Run a controlled performance regression test against representative batch endpoints before and after upgrade; fixed services should not show disproportionate CPU growth for moderately sized arrays. Validate deployed artifacts rather than only source repositories, because marshmallow may be bundled into containers, virtual environments, wheels, zipapps, or serverless layers.

Typical attack path

1. Discover an API, webhook, import, or batch-processing endpoint that accepts arrays or lists of objects.
2. Send test requests with increasing numbers of objects to identify endpoints whose latency grows disproportionately.
3. Confirm the backend likely performs marshmallow deserialization with many=True by observing CPU-bound delays, timeouts, or consistent slow responses without large bandwidth usage.
4. Automate repeated moderately sized requests against the vulnerable endpoint.
5. Exhaust available CPU or application worker capacity, causing slow responses, request failures, queue buildup, or health-check failures.
6. Continue or distribute requests to sustain denial of service until mitigations such as rate limiting, request-size limits, worker isolation, or patching are applied.

How to detect it

To determine whether exploitation has already been attempted, correlate application access logs, API gateway logs, load balancer logs, WAF logs, APM traces, and host/container metrics. Look for time windows where CPU usage on Python application workers increased sharply without a corresponding increase in request volume or bandwidth. Focus on endpoints that accept JSON arrays, bulk imports, batch updates, webhooks, or list-style payloads. Indicators include repeated moderately sized POST/PUT/PATCH requests, unusually long request durations, request timeouts, worker restarts, autoscaling events, queue backlog growth, and spikes in 5xx/timeout responses. In application traces, look for expensive spans or stack samples involving marshmallow deserialization, Schema.load, load_many, or validation routines with many=True. Because there is no universal payload string for this issue, detection should be behavior-based: high CPU per request, repeated access to batch endpoints from the same source or small source set, and latency that scales abnormally with submitted array length. If threat hunting deployed code, search for marshmallow versions in the vulnerable ranges and for Schema.load(..., many=True) applied to request bodies or other untrusted input.

• marshmallow==3.0.0rc1
• marshmallow==3.26.1
• marshmallow==4.0.0
• marshmallow==4.1.1
• Schema.load(
• many=True
• load_many
• marshmallow-3.26.1.dist-info
• marshmallow-4.1.1.dist-info

What your security team should do

• Inventory all applications and images that include marshmallow, including transitive dependencies and packaged Python virtual environments.
• Prioritize internet-facing APIs, webhook receivers, import endpoints, and bulk-processing services that accept arrays or lists from untrusted users.
• Upgrade to marshmallow 3.26.2 or 4.1.2 or later, then rebuild and redeploy affected artifacts.
• Add or verify request body size limits, maximum array-item limits, rate limits, and worker timeouts on endpoints that call Schema.load(..., many=True).
• Monitor for abnormal CPU saturation, request latency spikes, repeated HTTP 408/429/499/500/502/503/504 responses, and bursts of moderately sized requests to JSON/batch endpoints.
• Review recent access logs and APM traces for low-bandwidth, high-CPU request patterns that may indicate attempted exploitation.
• Document accepted bulk payload limits and add automated tests so future schema or endpoint changes do not reintroduce unbounded deserialization cost.