CVE-2026-41853

What it actually does

The flaw allows crafted multipart/form-data HTTP requests to be interpreted inconsistently by Spring MVC or Spring WebFlux applications and surrounding HTTP infrastructure such as reverse proxies, gateways, servlet containers, or application servers. By abusing multipart parsing edge cases, an unauthenticated network attacker may cause request-boundary confusion or request smuggling behavior, potentially making the application process attacker-controlled request content differently than upstream controls intended. The published CVSS indicates low-integrity impact with no direct confidentiality or availability impact, meaning the most likely technical outcome is bypass or manipulation of request handling rather than full remote code execution.

Why it matters to the business

Applications that accept file uploads, form submissions, API multipart requests, or similar Spring-based HTTP traffic may be exposed to request-routing or request-validation bypasses. In practical terms, this can allow attackers to evade security controls, manipulate application actions, or reach functionality that gateways, filters, or application logic were expected to protect. The risk is currently moderated by low EPSS, no known KEV listing, no known ransomware use, and no reported mature public exploit, but Spring Framework is widely deployed and the affected version ranges span multiple major supported branches, so remediation should be planned across all Java application portfolios.

How an attack unfolds

An attacker identifies a Spring MVC or Spring WebFlux application that accepts multipart requests, commonly through upload endpoints, form-post endpoints, or APIs using multipart/form-data. The attacker then sends specially crafted HTTP requests where multipart boundaries, body framing, content length, transfer encoding, or related parsing details are designed to be interpreted differently by intermediary infrastructure and the Spring application. If the frontend component and backend Spring parser disagree about where one request ends or how a multipart body should be parsed, attacker-controlled data may be treated as a separate or altered request by the backend. The attacker can use this discrepancy to bypass upstream request validation, confuse routing or authentication assumptions, or cause the application to process unintended parameters or actions. There is no indication from the provided intelligence that exploitation is currently widespread or associated with named threat actors, but the bug class is attractive because request smuggling flaws can be chained with access-control or business-logic weaknesses.

How to fix it

Upgrade Spring Framework to a version outside the affected ranges. Affected branches are 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; use the vendor-fixed successor release for the branch in use, such as 7.0.8 or later, 6.2.19 or later, 6.1.28 or later, and 5.3.49 or later if those releases are available from the vendor. Where direct framework versions are inherited through Spring Boot or another platform BOM, upgrade the parent platform to a release that includes a fixed Spring Framework dependency. As interim mitigations, restrict multipart upload endpoints to authenticated users where possible, enforce strict request-size and part-count limits, normalize or reject ambiguous HTTP framing at reverse proxies, disable unsupported transfer encodings, ensure consistent HTTP/1.1 parsing between proxies and backends, and add gateway rules to reject malformed multipart boundaries or conflicting Content-Length and Transfer-Encoding combinations.

How to confirm the fix worked

Confirm the effective runtime Spring Framework version, not only the declared dependency version, by inspecting build manifests, dependency trees, container images, SBOMs, application startup logs, and packaged JARs. Validate that no deployed application includes spring-web, spring-webmvc, or spring-webflux artifacts in the affected version ranges. For Maven, review dependency:tree output; for Gradle, review dependencies or dependencyInsight output; for containerized workloads, scan the image layers and application archive contents. After upgrading, run regression tests for multipart upload and form endpoints, including malformed multipart bodies, oversized bodies, missing boundaries, duplicate Content-Length headers, chunked requests, and requests with trailing data. At the edge, verify that proxies and application servers reject ambiguous request framing consistently and that requests containing both Content-Length and Transfer-Encoding are blocked or normalized according to policy.

Typical attack path

1. Discover a public or internal Spring MVC or Spring WebFlux application running an affected Spring Framework version.
2. Identify endpoints that accept multipart/form-data, such as upload, import, attachment, document, profile, or API form endpoints.
3. Map the HTTP path through proxies, load balancers, gateways, servlet containers, and the Spring application to find parser discrepancies.
4. Send malformed or ambiguous multipart requests using unusual boundaries, body framing, Content-Length, Transfer-Encoding, or trailing data.
5. Observe differences in response codes, timing, backend errors, or downstream request handling that indicate request desynchronization or parsing confusion.
6. Refine the crafted request to cause the backend application to process attacker-controlled content outside the intended validation path.
7. Use the bypass to manipulate application state, reach otherwise protected behavior, or support follow-on attacks against application-specific logic.

How to detect it

Look for evidence of malformed multipart/form-data traffic and HTTP request-framing anomalies reaching Spring MVC or WebFlux services. Useful sources include reverse proxy logs, API gateway logs, WAF events, load balancer logs, servlet container access/error logs, Spring application logs, distributed tracing, and packet captures for suspicious upload endpoints. Hunt for bursts of 400-series responses, backend errors following successful gateway acceptance, unusual combinations of Content-Type multipart/form-data with Transfer-Encoding: chunked, duplicate or conflicting Content-Length headers, missing or malformed multipart boundaries, trailing data after multipart terminators, and repeated probes against upload/import/attachment endpoints. In Spring logs, search for MultipartException and related multipart parsing failures. In proxy and WAF telemetry, look for request smuggling signatures, HTTP desynchronization alerts, invalid chunked encoding, duplicate headers, and requests where the frontend and backend record different URI paths, methods, body sizes, or response statuses for the same connection. Because no named threat actors or public exploit maturity are indicated, detections should focus on exploit attempts and parsing anomalies rather than actor-specific infrastructure.

• org.springframework.web.multipart.MultipartException
• Failed to parse multipart servlet request
• Content-Type: multipart/form-data; boundary=
• Transfer-Encoding: chunked
• Content-Length: 0
• duplicate Content-Length
• multiple Content-Length
• conflicting Content-Length
• invalid multipart boundary
• missing multipart boundary
• no multipart boundary was found
• unexpected end of multipart data
• Stream ended unexpectedly
• Invalid chunk header
• HTTP request smuggling
• request smuggling detected
• HRS detected
• CL.TE
• TE.CL

What your security team should do

• Inventory Spring MVC and Spring WebFlux applications, prioritizing internet-facing services and APIs that accept multipart/form-data.
• Patch affected Spring Framework branches to vendor-fixed successor versions or upgrade the parent Spring Boot/platform BOM that controls Spring Framework transitive dependencies.
• Prioritize applications with upload, import, attachment, media, document, or multipart API endpoints, especially those behind complex proxy or gateway chains.
• Add temporary WAF, API gateway, or reverse-proxy controls to reject malformed multipart requests, duplicate or conflicting request-framing headers, and multipart bodies with invalid boundaries.
• Review access controls on multipart endpoints and require authentication or authorization wherever business requirements allow.
• Enable or increase logging for HTTP 400 responses, multipart parsing failures, gateway/backend response mismatches, and unusual request-body handling until remediation is complete.
• Search historical logs for malformed multipart attempts and request smuggling indicators, especially since publication on 2026-06-09.
• Include this issue in software composition analysis policies for Spring Framework versions 7.0.0-7.0.7, 6.2.0-6.2.18, 6.1.0-6.1.27, and 5.3.0-5.3.48.
• Because EPSS is low and there is no KEV listing or known exploit maturity, treat this as a high-priority hygiene patch for exposed Spring applications rather than an active-emergency incident unless local telemetry shows exploitation attempts.