CVE-2026-41840

What it actually does

Spring WebFlux applications using affected Spring Framework versions can experience availability loss when handling specially crafted or resource-intensive multipart/form-data requests. The flaw is reachable over the network without authentication and affects request parsing in reactive multipart handling; an attacker can cause excessive CPU, memory, buffer, or event-loop pressure during multipart processing, degrading service responsiveness or causing request handling failures. The impact is denial of service only: confidentiality and integrity are not directly affected.

Why it matters to the business

Public-facing APIs and web applications that accept file uploads or multipart form submissions may become slow, unstable, or unavailable during an attack. This can disrupt customer-facing services, integrations, and internal workflows that depend on Spring WebFlux applications. The CVSS availability impact is high, but exploitability is rated high complexity, EPSS is low and flat over 30 days, there is no known KEV listing, no ransomware association, and no reported mature public exploit based on the supplied data, so prioritization should focus first on internet-exposed upload endpoints and high-availability services.

How an attack unfolds

An attacker identifies a Spring WebFlux endpoint that accepts multipart requests, such as file upload, form submission, or API ingestion functionality. They then send crafted multipart/form-data traffic designed to stress the vulnerable parser, for example by using excessive part counts, large or malformed boundaries, slow or repeated uploads, or concurrency patterns that amplify server-side resource consumption. If the application runs an affected Spring Framework version and lacks protective limits at the application, reverse proxy, or gateway layer, request processing can consume enough resources to slow or deny legitimate traffic. Because the weakness is availability-focused, successful exploitation is typically observed as latency spikes, elevated memory or CPU, event-loop saturation, request timeouts, 5xx responses, or container restarts rather than data theft or privilege escalation.

How to fix it

Upgrade Spring Framework to a version outside the affected ranges: 7.0.0 through 7.0.7, 6.2.0 through 6.2.18, 6.1.0 through 6.1.27, and 5.3.0 through 5.3.48. If exact fixed versions are not yet recorded in internal dependency guidance, consult the official Spring advisory and move to the first patched release newer than the affected line in use. Where immediate upgrade is not possible, reduce exposure by enforcing strict multipart upload limits, including maximum request body size, maximum file size, maximum number of parts, maximum header size, read timeouts, and request-rate limits at the application gateway, load balancer, reverse proxy, or Web Application Firewall. Disable unused upload endpoints, require authentication for upload functionality where feasible, and isolate high-risk upload processing from critical application paths.

How to confirm the fix worked

Confirm dependency versions using build manifests and runtime artifacts, including Maven dependency trees, Gradle dependency reports, SBOMs, container image scans, and deployed application package inspection. Verify that no deployed service includes Spring Framework versions in the affected ranges. Exercise upload endpoints in a non-production environment with legitimate multipart requests to confirm expected functionality after upgrade. Validate that reverse proxy, gateway, and application-level limits reject oversized, excessive-part, malformed, or slow multipart requests before they can consume application resources. Monitor post-remediation metrics for normalized request latency, stable memory usage, reduced 5xx errors, and absence of multipart parsing exceptions under routine upload traffic.

Typical attack path

1. Discover an internet-accessible Spring WebFlux application or API endpoint that accepts multipart/form-data requests.
2. Confirm that the target endpoint processes multipart uploads or multipart form submissions.
3. Send crafted multipart requests that stress parsing behavior, request buffering, or reactive request handling.
4. Increase request size, part count, malformed multipart structure, slow delivery, or concurrency until service degradation is observed.
5. Maintain pressure to exhaust application resources, saturate event loops, trigger timeouts, or cause application/container restarts.

How to detect it

To assess possible prior exploitation, review application, reverse proxy, API gateway, WAF, CDN, load balancer, Kubernetes, and container runtime logs for abnormal multipart/form-data traffic targeting upload or form endpoints. Focus on bursts of POST, PUT, or PATCH requests with multipart/form-data content types, unusual boundary values, very large request bodies, excessive request duration, client disconnects, repeated 400/413/415/429/499/500/502/503/504 responses, and spikes in request concurrency from a small set of source IPs or user agents. In application logs, look for Spring WebFlux multipart parsing errors, reactive stream cancellation errors, data buffer limit exceptions, out-of-memory errors, high garbage collection activity, event-loop starvation, and request timeout messages near periods of degraded availability. Correlate these findings with infrastructure telemetry showing CPU or memory saturation, pod/container restarts, liveness/readiness probe failures, autoscaling events, or load balancer health-check failures. Because the vulnerability does not inherently create persistent malware or data-access artifacts, detection is primarily behavioral and log-correlation based rather than file- or registry-based.

• Content-Type: multipart/form-data
• multipart/form-data; boundary=
• org.springframework.http.codec.multipart
• MultipartHttpMessageReader
• DefaultPartHttpMessageReader
• PartEventHttpMessageReader
• DataBufferLimitException
• Exceeded limit on max bytes to buffer
• OutOfMemoryError
• Java heap space
• request body too large
• 413 Request Entity Too Large
• 413 Payload Too Large
• 499 Client Closed Request
• 504 Gateway Timeout
• ReadTimeoutException
• PrematureCloseException
• reactor.netty.http.server
• reactor.netty.channel.AbortedException
• Connection reset by peer

What your security team should do

• Inventory Spring WebFlux applications and prioritize internet-facing services that accept multipart/form-data or file uploads.
• Patch affected Spring Framework versions as part of the next urgent maintenance cycle, prioritizing high-availability and externally reachable applications.
• Until patched, enforce upload size, part count, timeout, and request-rate limits at edge controls and application gateways.
• Add monitoring for spikes in multipart POST requests, upload endpoint latency, 4xx/5xx responses, request timeouts, memory pressure, CPU saturation, and container restarts.
• Review WAF, reverse proxy, CDN, API gateway, and application logs for signs of prior multipart request floods or malformed multipart traffic since publication.
• Ensure upload endpoints require authentication and authorization where business requirements allow.
• Document accepted multipart limits and add regression tests so future deployments do not remove protective controls.