CVE-2026-41853

HTTP Request Smuggling

Affects

Spring Framework

Spring

Versions

>=5.3.0 <=5.3.52, >=6.1.0 <=6.1.28, >=6.2.0 <=6.2.18, >=7.0.0 <=7.0.7

Patch Available

This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.

View NES Solution

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 both decide where one part of such a request ends and the next begins by reading the boundary parameter out of the request Content-Type header with the framework's shared MIME type parser in the spring-core module.

An HTTP request smuggling vulnerability (CVE-2026-41853) has been identified in that Content-Type parsing, which allows attackers to make the framework split a multipart request body on a different boundary than the Web Application Firewall (WAF) or proxy in front of it, so that content the protective layer never inspected is still parsed and dispatched by the application. 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: "the attacker exploits the fact that some specially crafted HTTP messages can be parsed and interpreted in different ways depending on the agent that receives them. HTTP smuggling requires some level of knowledge about the different agents that are handling the HTTP messages (web server, proxy, firewall)."

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.52, >=6.1.0 <=6.1.28, >=6.2.0 <=6.2.18, and >=7.0.0 <=7.0.7, including the End-of-Life 5.3.x and 6.1.x lines supported by NES for Spring Framework.

‍

Details

Module Info

Product: Spring Framework
Affected packages: org.springframework:spring-webmvc, org.springframework:spring-webflux, org.springframework:spring-core
Affected versions: >=5.3.0 <=5.3.52, >=6.1.0 <=6.1.28, >=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-webmvc, https://central.sonatype.com/artifact/org.springframework/spring-webflux, https://central.sonatype.com/artifact/org.springframework/spring-core
Package manager: Maven
Fixed in:
- NES for Spring Framework nes-v5.3.53 and nes-v6.1.29
- Spring Framework 6.2.19 and 7.0.8 (OSS)

‍

Vulnerability Info

This Medium-severity vulnerability is found in the spring-core package in multiple versions of Spring Framework, and is reached from the multipart handling of both spring-webmvc and spring-webflux. Every MIME type the framework parses, including the request Content-Type header of a multipart upload, goes through MimeTypeUtils.parseMimeTypeInternal, which walks the parameter section of the header and tracks whether it is currently inside a quoted parameter value:

int nextIndex = index + 1; boolean quoted = false; while (nextIndex < mimeType.length()) { char ch = mimeType.charAt(nextIndex); if (ch == ';') { if (!quoted) { break; } } else if (ch == '"') { quoted = !quoted; } nextIndex++; } String parameter = mimeType.substring(index + 1, nextIndex).trim();

The quoted flag is toggled by every " character, including one that is backslash-escaped. RFC 9110 defines a backslash-escaped quote inside a quoted string as a quoted pair, that is, a literal " that does not end the quoted string. An affected version therefore treats an escaped quote as closing the quoted section, and the next ; is taken as a parameter separator instead of ordinary data, so the parameter value is cut short and the remainder of the header is re-read as further parameters.

For a multipart request this changes the boundary the framework works with. Given the header:

Content-Type: multipart/form-data; boundary="a\";b"

an RFC 9110 compliant parser reads a single boundary parameter whose value is a";b. An affected Spring version stops at the escaped quote and records the boundary as "a\", discarding the rest, and the multipart readers then strip only the surrounding quote characters, leaving a\ as the delimiter that the body is split on.

The result is a parser differential between the application and anything in front of it. A WAF or proxy that implements quoted pairs correctly scans the body for the parts delimited by its own reading of the boundary, finds either nothing or a different set of parts, and forwards a request it believes it has inspected, while the affected Spring application splits the same bytes on its own truncated delimiter and processes the parts the attacker intended. Multipart content is smuggled past the protective layer without the two sides ever disagreeing about the request line or the Content-Length.

The vulnerable parameter-parsing logic was introduced in Spring Framework 4.3.5 (December 2016), when MIME-type parsing was reworked to honor semicolons inside quoted parameter values, and it remained in place through every subsequent release line until the 6.2.19 fix.

‍

Steps to Reproduce

1. Add an affected version of spring-core to a project, for example 6.2.18, and parse a multipart content type whose boundary uses a quoted pair:

String header = "multipart/form-data; boundary=\"a\\\";b\""; MimeType mimeType = MimeTypeUtils.parseMimeType(header); System.out.println(mimeType.getParameter("boundary"));

2. Observe that the parsed boundary parameter is "a\", truncated at the escaped quote, rather than the full quoted value the header carries. An RFC 9110 compliant parser reads the same header as one boundary parameter with the value a";b.

3. Repeat the same call on a patched version, for example 6.2.19, and observe the complete value "a\";b".

4. In a deployment where a WAF or proxy inspects multipart bodies, send a POST request with that Content-Type header and a body framed with the boundary the protective layer derives. The protective layer and the affected application split the body differently, so parts that were never inspected are still processed by the application.

‍

Mitigation

Only recent versions of Spring Framework receive community support. The 5.3.x and 6.1.x lines are End-of-Life and will not receive public updates to address this issue, so there is no publicly available fix for those lines other than through a commercial support partner.

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

Upgrade to a currently supported version of Spring Framework. The open-source fix ships in Spring Framework 6.2.19 on the 6.2.x line and 7.0.8 on the 7.0.x line.
Leverage a commercial support partner like HeroDevs for post-EOL security support, which provides the fix for the 5.3.x and 6.1.x lines in nes-v5.3.53 and nes-v6.1.29.

‍