CVE-2026-41853

Overview

Spring Framework is a widely used application framework for the Java platform that provides the core programming and configuration model for modern Java enterprise applications, including the Spring MVC servlet web stack and the reactive Spring WebFlux web stack. Both web stacks can accept multipart/form-data requests, and the reactive stack performs its own lazy parsing of the request body through DefaultServerWebExchange, which decides whether a request body should be decoded as form data or as multipart based on the request Content-Type header.

A medium-severity vulnerability (CVE-2026-41853) has been identified in that content-type gating. Before the fix, DefaultServerWebExchange would decode a request body as multipart or form data whenever the request Content-Type was merely compatible with the expected media type, without first requiring the content type to be concrete. A request carrying a wildcard content type such as a fully-wildcard type or a multipart/ wildcard would therefore still be decoded as multipart. Because a wildcard or otherwise ambiguous content type is exactly the kind of header that a front-end Web Application Firewall (WAF) or proxy can interpret differently from the framework, an attacker can craft a multipart request that the protective layer parses one way and that Spring parses another way, smuggling multipart content past the WAF or proxy security checks. The vulnerability is only relevant when an application uses Spring MVC or Spring WebFlux, accepts multipart requests, and sits behind a WAF or proxy that parses multipart content to perform security checks.

Per OWASP, HTTP request smuggling is the act of using inconsistencies in how the front-end (a load balancer or proxy) and the back-end of a website process requests from one or more attackers. This issue is the multipart variant of that class: the front-end WAF or proxy and the Spring back-end disagree on whether a wildcard content-type body is multipart, so security checks performed by the front-end can be bypassed.

The CVSS v3.1 base score for this vulnerability is 5.3 (Medium) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N. The attack vector is Network because the request arrives over HTTP, attack complexity is Low, no privileges or user interaction are required, and the impact is Integrity-only and Low because the consequence is the bypass of a front-end security control rather than direct disclosure or destruction of data inside the framework.

This issue affects Spring Framework >=5.3.0 <=5.3.48, >=6.1.0 <=6.1.27, >=6.2.0 <=6.2.18, and >=7.0.0 <=7.0.7.

Details

Module Info

• Product: Spring Framework
• Affected packages: spring-web
• Affected versions: >=5.3.0 <=5.3.48, >=6.1.0 <=6.1.27, >=6.2.0 <=6.2.18, >=7.0.0 <=7.0.7
• GitHub repository: https://github.com/spring-projects/spring-framework
• Published packages: https://central.sonatype.com/artifact/org.springframework/spring-web
• Package manager: Maven
• Fixed in:
• NES for Spring Framework 5.3.x, 6.1.x
• Spring Framework 7.0.8, 6.2.19 (OSS)

Vulnerability Info

The vulnerability is in DefaultServerWebExchange, the reactive ServerWebExchange implementation in the spring-web module that backs Spring WebFlux. When an application reads form data or multipart data from the request (for example through ServerWebExchange.getFormData() or getMultipartData(), or when a controller binds a multipart argument), DefaultServerWebExchange decides whether to decode the request body based on the request Content-Type.

Pre-fix, the gating condition only required the content type to be non-null and compatible with the expected media type:

private Mono<MultiValueMap<String, String>> initFormData(...) {
   MediaType contentType = getContentType(request);
   if (contentType == null || !contentType.isCompatibleWith(MediaType.APPLICATION_FORM_URLENCODED)) {
       return EMPTY_FORM_DATA;
   }
   // ...
}

private Mono<MultiValueMap<String, Part>> initMultipartData(...) {
   MediaType contentType = getContentType(this.request);
   if (contentType == null || !contentType.getType().equalsIgnoreCase("multipart")) {
       return EMPTY_MULTIPART_DATA;
   }
   // ...
}


MediaType.isCompatibleWith treats wildcard types as compatible, and equalsIgnoreCase("multipart") on the type part matches a multipart/ wildcard. As a result, a request sent with a wildcard content type is still decoded as form data or multipart by the framework. A WAF or proxy that parses multipart content for security checks may treat such a wildcard or ambiguous content type as not-multipart and therefore skip those checks, while Spring proceeds to parse the same body as multipart. That parser differential is the smuggling primitive.

The fix adds an isConcrete() guard so that a non-concrete (wildcard) content type is no longer decoded as form data or multipart, and passes the actual request content type to reader selection:

private Mono<MultiValueMap<String, String>> initFormData(...) {
   MediaType contentType = getContentType(request);
   if (contentType == null || !contentType.isConcrete()
           || !contentType.isCompatibleWith(MediaType.APPLICATION_FORM_URLENCODED)) {
       return EMPTY_FORM_DATA;
   }
   HttpMessageReader<MultiValueMap<String, String>> reader = getReader(configurer, contentType, FORM_DATA_TYPE);
   // ...
}

private Mono<MultiValueMap<String, Part>> initMultipartData(...) {
   MediaType contentType = getContentType(this.request);
   if (contentType == null || !contentType.isConcrete()
           || !contentType.getType().equalsIgnoreCase("multipart")) {
       return EMPTY_MULTIPART_DATA;
   }
   // ...
}


The change is minimal and behavior-preserving for legitimate requests: a request with a concrete content type such as multipart/form-data; boundary=... is decoded exactly as before, while a request with a wildcard content type is no longer treated as form data or multipart, removing the ambiguity that a front-end WAF or proxy could disagree about. The fix is delivered in upstream commit 696692f1edb801efbe631804bdb45502371f10fb ("Do not attempt to decode wildcard content-types as form-data") in the spring-web module. The same DefaultServerWebExchange decoding path has existed since the WebFlux reactive stack was introduced in Spring Framework 5.0, so every 5.x, 6.x, and 7.x release prior to the listed fix versions that exposes WebFlux form or multipart reading is affected. The advisory range starting at 5.3.x reflects Spring's currently supported scope; older lines that contain the same decoding logic are also affected. Spring MVC applications are listed as affected because the same multipart-handling expectations apply to applications fronted by a WAF or proxy that performs multipart content checks.

Steps To Reproduce

1. Deploy a Spring WebFlux application on an affected Spring Framework version (for example 6.1.27) with a controller that consumes multipart data, behind a WAF or proxy that inspects multipart/form-data bodies for security checks:

@PostMapping(path = "/upload", consumes = MediaType.MULTIPART_FORM_DATA_VALUE)
Mono<String> upload(@RequestPart("file") FilePart file) {
   return Mono.just(file.filename());
}


2. Send a normal multipart request with a concrete content type and observe that the WAF or proxy inspects the multipart payload as expected:

POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----abc

------abc
Content-Disposition: form-data; name="file"; filename="x.txt"

benign
------abc--


3. Send the same request but replace the content type with a wildcard value (a multipart/ wildcard, or a fully-wildcard type), keeping the same body and boundary.

4. Observe that the front-end WAF or proxy, treating the wildcard type as not a concrete multipart type, may skip its multipart content inspection, while the affected Spring back-end still decodes the body as multipart and dispatches it to the controller. The multipart payload has been smuggled past the protective layer.

5. After upgrading to a fixed version (7.0.8, 6.2.19), repeat step 3. The framework no longer decodes the wildcard-content-type body as multipart, so the request is not processed as a smuggled multipart upload.

Mitigation

Only recent versions of Spring Framework receive community support and updates. The 5.3.x and 6.1.x lines are out of open-source support, and the open-source project does not provide a free fix for those lines.

Users of the affected components should apply one of the following mitigations:

• Upgrade to a currently supported version of Spring Framework. The OSS fix ships in Spring Framework 7.0.8 (7.0.x line) and 6.2.19 (6.2.x line).
• Leverage a commercial support partner like HeroDevs for post-EOL security support through Never-Ending Support (NES) for Spring Framework, which provides the fix for the 5.3.x and 6.1.x lines.

Credits

• Yuki Matsuhashi (finder)