Security
May 15, 2026

Spring Framework April 2026: 3 Web Stack DoS and Cache Poisoning CVEs

How a single April 17 release addressed three independent denial-of-service vectors in the Spring 5.3, 6.1, 6.2, and 7.0 web stack, with two of those branches receiving fixes only on commercial subscriptions

Give me the TL;DR
Spring Framework April 2026: 3 Web Stack DoS and Cache Poisoning CVEs
For Qualys admins, NES for .NET directly resolves the EOL/Obsolete Software:   Microsoft .NET Version 6 Detected vulnerability, ensuring your systems remain secure and compliant. Fill out the form to get pricing details and learn more.

On April 17, 2026, the Spring team disclosed three Spring Framework vulnerabilities in a single coordinated release: CVE-2026-22740 (Medium, CVSS 6.5, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), CVE-2026-22741 (Low, CVSS 3.1, CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L), and CVE-2026-22745 (Medium, CVSS 5.3, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L). All three live in the web stack, all three map to CWE-400 (Uncontrolled Resource Consumption) or CWE-524, and all three follow the same fix pattern: Spring Framework 7.0.7 and 6.2.18 receive open source patches, while earlier versions are affected but not available in OSS branches.

The severities are not Critical, but the affected version footprint is. Spring Framework 5.3.x reached OSS end-of-life on August 31, 2024, and 6.1.x reached OSS end-of-life on June 30, 2025. Both branches have substantial enterprise install bases. Both now have three additional unpatched CVEs that the open source project will not address. The patched branch most teams will reach for, 6.2.x, itself reaches OSS end-of-life on June 30, 2026, less than two months from this writing.

What Spring Framework shipped on April 17, 2026

The April 17 release line is a single advisory wave covering three independent root causes that happen to share an attack surface (the web stack) and a class of impact (denial of service or cache integrity). Spring published all three advisories on the same day, with identical affected-version language and identical fix-version mappings. Treating them as one release is correct: a patch team applying any of the fixes will, in practice, apply all three by upgrading the underlying Spring Framework dependency.

CVSS scores are the VMware (Spring CNA) ratings as published in each advisory.

CVE-2026-22740: WebFlux multipart temp file leak (disk DoS)

The Spring advisory describes the bug in plain terms: a WebFlux server application that processes multipart requests creates temporary files for any part larger than 10 KB. Under some conditions, those temp files are not deleted after the request finishes. A repeated stream of multipart requests, each with a body part above 10 KB, fills the temp directory and exhausts available disk space.

The CVSS vector treats this as PR:L, which means the attacker needs at least a low-privilege account on the application. This is not an unauthenticated attack, and the post-draft framing is not "any internet user can fill your disk." It is "an abusive insider, a compromised low-privilege account, or any tenant in a multi-tenant deployment can fill your disk." For applications that expose multipart endpoints to authenticated users at scale (file uploads, profile photo changes, document submission flows), the practical effect is the same: a single credential is enough to take an instance offline by filling /tmp (or the configured temp directory), and on hosts that share that volume with the application's working directory, the side effects extend well beyond the upload feature.

The reporters credited in the advisory are Xint Code and Yuki Matsuhashi. The CWE is CWE-400 (Uncontrolled Resource Consumption).

CVE-2026-22741: static resource cache poisoning

CVE-2026-22741 is a cache poisoning issue against Spring MVC and Spring WebFlux applications that serve static resources with the resource chain. The advisory enumerates the preconditions explicitly:

  • The application uses Spring MVC or Spring WebFlux.
  • The application configures the resource chain with caching enabled.
  • The application adds support for encoded resources resolution (typically gzip or br).
  • The resource cache is empty when the attacker first reaches the application.

When all four conditions hold, an attacker can prime the cache with a static resource served under the wrong encoding. Subsequent legitimate requests then receive the wrong-encoding response, breaking the front-end for downstream clients. The CVSS score is Low (3.1) because the attack complexity is high (AC:H) and user interaction is required (UI:R), but the precondition list is the part to read carefully. Resource chain caching with encoded resources is a normal Spring configuration; teams running CDNs in front of Spring should not assume the CDN absorbs this, because the poisoned response originates from Spring itself.

The CWE assigned is CWE-524 (Use of Cache Containing Sensitive Information). That mapping is unusual for a cache poisoning bug (CWE-444 or CWE-441 would be more typical), but it is what NVD recorded; we cite the assigned CWE rather than the one we would have chosen.

The reporter credited in the advisory is Yuki Matsuhashi.

CVE-2026-22745: Windows DoS via slow static resource resolution

CVE-2026-22745 is the most exploitable of the three by raw CVSS metrics: AV:N/AC:L/PR:N/UI:N (network-reachable, low complexity, unauthenticated, no user interaction). The catch is that it only applies to Spring MVC and Spring WebFlux applications running on Windows that serve static resources from the file system.

The advisory says: "the attacker can send malicious requests that are slow to resolve and that can keep HTTP connections in use." The exact filesystem operation that Windows handles slowly enough to weaponize is not named in the advisory or in NVD's record. What the advisory does say is that the resulting connection-hold pattern is sufficient to exhaust the application's HTTP connection pool, which is a textbook slow-loris-class DoS without the slow-loris payload.

The Windows-only constraint trims the affected population, but Windows is not rare in regulated enterprise environments: defense, healthcare, public sector, and financial back-office deployments still run substantial Spring footprints on Windows Server. For those deployments this is the highest-priority of the three. The CWE is CWE-400 (Uncontrolled Resource Consumption).

The reporter credited in the advisory is Bocheng Xiang (@crispr) of Fudan University.

Why "Low" and "Medium" CVEs still matter for audit and SOC 2

A pattern we see consistently in HeroDevs customer engagements: enterprise security and compliance programs do not stop reading at the CVSS severity label. SOC 2, ISO 27001, and the EU Cyber Resilience Act all key off the existence of known unmitigated vulnerabilities, not off severity thresholds. A Low CVE that has been disclosed publicly and has no available fix on the version a team is running shows up in a vulnerability scanner's report, gets logged in an audit ticket, and stays open until the version is upgraded or replaced.

The three April 17 CVEs are likely to be ignored by initial triage in many shops because none is Critical and one is rated Low. They are not likely to be ignored on the second pass, when the same scanner is run during a SOC 2 audit cycle or a CRA-readiness review and three additional unaddressed CVE IDs land on the report for an EOL Spring branch. The cost to ignore them is administrative, not technical, but for organizations on the regulated side of the buyer profile, the administrative cost is the cost.

This is the framing security teams should bring to upstream conversations: severity does not govern reportability.

Affected versions and fix matrix

All three CVEs share an identical affected-version footprint and an identical fix matrix.

A note on 6.2.x: Spring Framework 6.2.x reaches OSS end-of-life on June 30, 2026. A team upgrading to 6.2.18 today is moving onto a branch that loses upstream OSS support in less than two months. The honest recommendation for teams that can absorb the migration cost is to plan for 7.0.x, not 6.2.x, even if the immediate stop-the-bleed action is to take the 6.2.18 patch.

A note on 6.1.x and 5.3.x: the advisory's "Availability: Commercial" entry is unambiguous. Spring Framework 6.1.27 and 5.3.48 exist as fixed releases, but they are not published to Maven Central. Teams running OSS 5.3.x or 6.1.x have no upstream OSS option for these three CVEs.

Mitigation guidance

Related Spring CVEs from the March-April 2026 window

The April 17 web stack release is part of a much broader two-month disclosure surge across the Spring ecosystem. For continuity:

The April 21 Spring Security batch (seven CVEs including two Critical authorization bypass issues) and the April 23 Spring Boot batch (eight CVEs) will be covered in subsequent dedicated roundups.

Taking action

The April 17 Spring Framework release is the cleanest possible illustration of why "Low" and "Medium" severity labels are not a green light to defer. Three CVEs landed on the same day. Two of them have OSS fixes only on the two newest branches. For organizations standing on Spring Framework 6.0.x, 5.3.x, or older, NES for Spring is the OSS-licensed alternative: drop-in replacements with security patches for CVE-2026-22740, CVE-2026-22741, and CVE-2026-22745, plus the rest of the March-April 2026 advisory set, on the versions Spring no longer maintains under any open license.

If your audit or compliance program treats unmitigated CVEs as reportable regardless of severity (and most do), the cost of leaving these three open through a SOC 2, ISO 27001, or EU CRA review cycle is the wrong cost to absorb for a Low-and-Medium triplet that has straightforward remediation paths.

Table of Contents
Author
Greg Allen
Chief Technology Officer
Open Source Insights Delivered Monthly