high

CVE

CVE-2026-41840, CVE-2026-41842

CWE

CWE-400

Affected Surface

Spring Framework web modules in versions 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, org.springframework:spring-webflux consumers exposing multipart/form-data endpoints, org.springframework:spring-webmvc and org.springframework:spring-webflux consumers serving filesystem-backed versioned static resources, Spring Boot applications that inherit affected Spring Framework lines

Spring shipped 7.0.8 and 6.2.19 on 8 June with a dense batch of web security fixes, but two of them stand out for day-to-day application teams because they sit directly on request-processing paths that are easy to forget during threat modeling:

  • CVE-2026-41840 is a WebFlux multipart denial of service issue.
  • CVE-2026-41842 is a Spring MVC and WebFlux static-resource denial of service issue.

Neither bug requires a gadget chain, deserialization primitive, or unusual deployment model. If your service accepts multipart/form-data, or if it serves versioned static files from the filesystem, ordinary HTTP traffic can become the resource-exhaustion trigger.

What is affected

Spring’s advisories describe the impacted product as Spring Framework 5.3.0 through 5.3.48, 6.1.0 through 6.1.27, 6.2.0 through 6.2.18, and 7.0.0 through 7.0.7. For application teams, the most useful way to scope that is by the Maven modules and features in use:

CVEPackage / project surfaceTrigger conditionFixed in
CVE-2026-41840Applications using Spring WebFlux, typically through org.springframework:spring-webflux and the shared org.springframework:spring-web codecsThe application exposes a multipart endpoint and processes attacker-controlled multipart bodies7.0.8, 6.2.19, 6.1.28, 5.3.49
CVE-2026-41842Applications using org.springframework:spring-webmvc or org.springframework:spring-webflux static-resource handlingThe application serves static resources from the filesystem and has versioned resource support enabled7.0.8, 6.2.19, 6.1.28, 5.3.49

If you consume Spring through Spring Boot, the practical fix is to move to a Boot release that picks up those Spring Framework versions or later. The vulnerable logic lives in the framework web stack, so checking only direct dependencies is not enough.

Why CVE-2026-41840 matters

Spring’s advisory keeps the description intentionally short: a hostile multipart request can leak memory in WebFlux and eventually deny service. The 7.0.7 -> 7.0.8 source diff gives more texture about the failure mode. In DefaultPartHttpMessageReader, the error path now drains and releases body buffers before throwing on over-limit input:

if (tooManyParts(partCount)) {
  return partsTokens
      .doOnNext(token -> {
        if (token instanceof MultipartParser.BodyToken bodyToken) {
          DataBufferUtils.release(bodyToken.buffer());
        }
      })
      .then(Mono.error(new DecodingException("Too many parts ...")));
}

There are matching lifecycle hardening changes in the multipart parser and generator path:

else {
  changeState(this, DisposedState.INSTANCE, buf);
}
class DefaultPartHttpMessageReaderTests extends AbstractLeakCheckingTests {
  // leak-checking was added in the fix train
}

Taken together, those changes are consistent with a classic reactive resource-management bug: malformed or adversarial multipart traffic was able to push the parser into error or discard states without reliably releasing the underlying DataBuffer and part resources. In a WebFlux service, that does not have to look dramatic at first. It can start as slowly rising direct-memory pressure, buffer retention, or request stalls under repeated multipart traffic, and only later collapse the instance.

That is why the vulnerable surface is broader than “file upload services.” Any reactive endpoint that accepts multipart bodies, including image upload handlers, avatar endpoints, document ingestion APIs, and API gateways that proxy multipart traffic, belongs in the review set.

Why CVE-2026-41842 matters

CVE-2026-41842 is the higher-severity issue of the pair in NVD scoring terms. Spring says it affects applications that:

  1. use Spring MVC or Spring WebFlux,
  2. serve static resources from the filesystem, and
  3. enable versioned resource support.

The release diff shows Spring tightening exactly the version-stripping and path-validation path that sits in front of static resource resolution. Before the fix, version removal deleted every matching -<hash> substring. In 7.0.8, that became a last-occurrence removal:

public String removeVersion(String requestPath, String version) {
  String versionString = "-" + version;
  int index = requestPath.lastIndexOf(versionString);
  if (index != -1) {
    return requestPath.substring(0, index) + requestPath.substring(index + versionString.length());
  }
  return requestPath;
}

Spring also added an invalid-path rejection gate right after version stripping:

String simplePath = versionStrategy.removeVersion(requestPath, candidate);
if (ResourceHandlerUtils.shouldIgnoreInputPath(simplePath)) {
  return Mono.empty();
}

The regression test added in the same train makes the bug shape concrete:

String path = "font-awesome/css-sha/font-awesome.min-sha.css";
assertThat(removeVersion(path, "sha"))
    .isEqualTo("font-awesome/css-sha/font-awesome.min.css");

That matters because versioned-resource lookup is often treated as “just front-end plumbing,” but it still runs on request threads or event-loop capacity. When the resolver strips too much from a path, walks the wrong filesystem target, or keeps trying to resolve malformed versioned paths, attackers get a cheap connection-holding primitive against an otherwise ordinary static asset route.

For application security teams, the key takeaway is that a front-end feature flag like content-hash versioning changes the backend attack surface. A filesystem-backed asset handler is no longer a passive file server once it starts parsing attacker-controlled version strings and resolving them against local storage.

Scoping your exposure

First, identify whether the affected Spring web modules are present:

mvn dependency:tree -Dincludes=org.springframework:spring-web,org.springframework:spring-webflux,org.springframework:spring-webmvc
./gradlew dependencies --configuration runtimeClasspath | rg "spring-web(|flux|mvc)"

Then identify whether the vulnerable feature paths are actually enabled in your application:

rg -n "FilePart|Part|MultipartBodyBuilder|multipart/form-data" src
rg -n "VersionResourceResolver|addVersionStrategy|resourceChain|VersionStrategy" src

For CVE-2026-41840, prioritize any controller, router, or handler method that accepts Part, FilePart, or multipart uploads. For CVE-2026-41842, look for custom resource handlers serving from local filesystem locations rather than classpath-packaged assets, especially when content-hash versioning is enabled.

Detection and remediation

Upgrade to one of the fixed lines immediately:

  • Spring Framework 7.0.x -> 7.0.8
  • Spring Framework 6.2.x -> 6.2.19
  • Spring Framework 6.1.x -> 6.1.28 (commercial)
  • Spring Framework 5.3.x -> 5.3.49 (commercial)

If you need to prioritize, CVE-2026-41842 is the easier remote exhaustion path because VMware scored it AV:N/AC:L/PR:N/UI:N/A:H, while CVE-2026-41840 is still remotely reachable but requires a narrower multipart trigger path (AV:N/AC:H/PR:N/UI:N/A:H).

After upgrading, re-test the exact routes that map to the vulnerable features:

  1. multipart upload handlers that parse large or malformed multipart bodies;
  2. static asset endpoints that use content-hash versioning; and
  3. any reverse-proxy or CDN behavior that may cache or replay odd versioned paths.

For teams that cannot patch immediately, the safest temporary reduction is configuration-driven: reduce public exposure of multipart endpoints, put strict request size and rate controls in front of upload routes, and review whether filesystem-backed versioned static resources are truly required. Those are compensating controls, not fixes.

The important lesson is broader than these two CVEs. Modern Java web stacks include parsers, resolvers, caches, and resource chains that developers rarely touch directly, but attackers do not care whether a path is business logic or framework plumbing. If untrusted input reaches it, it is part of your application security boundary.

References