What is the CVSS score of EUVD-2026-35342?

EUVD-2026-35342 has a CVSS 3.1 base score of 5.3 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N. EPSS exploitation probability: 0.0%.

Is there a patch available for EUVD-2026-35342?

Yes, a patch is available for EUVD-2026-35342. Update the affected software to the latest version immediately.

Spring Framework EUVD-2026-35342

| CVE-2026-41853 MEDIUM

HTTP Request/Response Smuggling (CWE-444)

2026-06-09 vmware

GHSA-cjpg-rgq5-fr37

Information Disclosure Java Request Smuggling Spring Framework Red Hat

5.3

CVSS 3.1 · Vendor: vmware

Severity by source

Vendor (vmware) PRIMARY

5.3 MEDIUM

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Red Hat

5.3 MEDIUM

qualitative

Primary rating from Vendor (vmware).

CVSS VectorVendor: vmware

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

Low

Availability

None

Lifecycle Timeline

Patch available

Jun 09, 2026 - 06:01 EUVD

Analysis Generated

Jun 09, 2026 - 05:21 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

6 maven packages depend on org.springframework:spring-webflux (5 direct, 1 indirect)
21 maven packages depend on org.springframework:spring-webmvc (13 direct, 8 indirect)

Ecosystem-wide dependent count for version 7.0.0 and other introduced versions.

DescriptionCVE.org

Spring MVC and WebFlux applications are vulnerable to Multipart request smuggling attacks.

Affected versions: Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.

AnalysisAI

Multipart request smuggling in Spring Framework's MVC and WebFlux components exposes applications to HTTP request manipulation via CWE-444. Unauthenticated remote attackers (AV:N/AC:L/PR:N/UI:N per CVSS) can exploit inconsistent multipart boundary parsing to smuggle malformed HTTP requests, achieving low-integrity impact against affected deployments. No public exploit code and no CISA KEV listing have been identified at time of analysis; however, the zero-prerequisite attack profile and broad version coverage across four major Spring branches (5.3.x, 6.1.x, 6.2.x, 7.0.x) make this relevant to any Java shop running Spring MVC or WebFlux with multipart upload handling enabled.

Technical ContextAI

CWE-444 (Inconsistent Interpretation of HTTP Requests - HTTP Request/Response Smuggling) describes vulnerabilities where a front-end and back-end component disagree on the boundaries of HTTP message bodies or headers. In this case, Spring Framework's multipart request parsing logic - used by both the synchronous Spring MVC (DispatcherServlet) and reactive Spring WebFlux (DispatcherHandler) stacks - misinterprets multipart boundary delimiters in a way that allows an attacker to embed additional, smuggled HTTP content within a single request. The CPE string cpe:2.3:a:spring:spring_framework:*:*:*:*:*:*:*:* covers all affected artifact groups. The vulnerability spans the entire supported and partially-supported version matrix: 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. Both the servlet-based and reactive programming models share the same underlying multipart parsing code path, making both deployment patterns affected.

RemediationAI

Upgrade to the next patched release in your active Spring Framework branch as documented in the vendor advisory at https://spring.io/security/cve-2026-41853. Exact fixed version numbers are not confirmed from the input data provided - consult the advisory directly to identify the target upgrade version for your branch (5.3.x, 6.1.x, 6.2.x, or 7.0.x). As a compensating control prior to patching, consider deploying a WAF rule or reverse proxy policy that rejects or normalizes malformed multipart Content-Type headers and boundary parameters before they reach the application; note that this may break legitimate clients using non-standard but valid multipart encodings and should be tested in staging first. If multipart upload functionality is not required by the application, disabling multipart resolvers in the Spring configuration (removing MultipartResolver beans or setting spring.servlet.multipart.enabled=false) eliminates the attack surface entirely with the trade-off of breaking file upload features.