On 8 June 2026 the Spring team published advisories for three Spring Framework issues, all found internally: an XSS bug in JavaScriptUtils.javaScriptEscape() (CVE-2026-41845, High), an information disclosure through the static resource cache (CVE-2026-41841, Medium) and a denial of service through versioned resources (CVE-2026-41842, High).
All three require a specific feature. That makes them a good case for asking whether your code is actually on the path before you decide how fast to move.
What's affected
All three advisories list the same ranges: Spring Framework 7.0.0 to 7.0.7, 6.2.0 to 6.2.18, 6.1.0 to 6.1.27, and 5.3.48 and earlier.
Fixed versions: 7.0.8 and 6.2.19 are open source. The fixes 7.0.7.1, 6.2.18.1, 6.1.28 and 5.3.49 are available only with Enterprise Support, so teams on 6.1 or 5.3 without a support contract have no open source fix to move to.
What each one needs to be reachable:
- CVE-2026-41845: your code calls
JavaScriptUtils.javaScriptEscape(), typically to put server values into inline JavaScript. Incorrect escaping can allow script injection in the browser. - CVE-2026-41841: Spring MVC or WebFlux, several resource handlers with different locations, at least one handler that requires authentication, and a cache shared across them. If a public resource with the same name resolves and is cached first, a protected one becomes reachable.
- CVE-2026-41842: Spring MVC or WebFlux serving static resources from the file system with versioned resources configured. Crafted slow requests hold connections open.
How to check if you're exposed
Find the Framework version and the code that matters:
# resolved version
./mvnw dependency:tree -Dincludes=org.springframework:spring-core
./gradlew dependencies --configuration runtimeClasspath | grep spring-core
# CVE-2026-41845: direct calls and JSP/Thymeleaf helpers
grep -rn "javaScriptEscape\|JavaScriptUtils" src
# CVE-2026-41841 and CVE-2026-41842: resource handler config
grep -rnE "addResourceHandler|addResourceLocations|VersionResourceResolver|resourceChain|resources\.chain" src
In JSPs, the spring:escapeBody javaScriptEscape="true" and spring:message javaScriptEscape="true" attributes are a common route to the escape function, so grep your templates too.
No hits for resource handlers means 41841 and 41842 are not reachable in that app, though the version should still move. A hit means read the config against the conditions above.
What to do now
- Upgrade to Spring Framework 7.0.8 or 6.2.19. Spring Boot users should move to a Boot release that pulls the fixed Framework, or override the Framework version in the BOM while waiting.
- If you are on 6.1 or 5.3, plan the move to 6.2 or 7.0, or confirm whether you have Enterprise Support for the 6.1.28 and 5.3.49 builds.
- Start with apps that call
javaScriptEscapeand with apps that combine authenticated and public resource handlers. - Add a Content Security Policy that blocks inline scripts where you can. It does not replace the fix but reduces the damage from an escaping bug.
How this could have been avoided
- Avoid putting server values into inline JavaScript. CVE-2026-41845 only matters if you escape data for a script context. Passing data as JSON in a
data-attribute or a JSON endpoint removes that context. - Use separate handler paths for public and protected resources. CVE-2026-41841 depends on a shared cache across handlers where one needs authentication. Distinct path prefixes and security rules per prefix keep the cache keys apart.
- Put a front proxy with request timeouts in front of file system resources. CVE-2026-41842 holds connections open. Edge timeouts and a CDN for static assets take the load off the application.
- Subscribe to project advisories and pin Framework versions through the BOM. All three were disclosed together, and a single pinned version makes the upgrade one change.
Why it matters
Three advisories in one day against one framework can look like a fire drill. Reading the conditions shows something calmer: each bug lives behind a feature flag in practice, and many apps do not use that feature.
That is not a reason to skip the upgrade. It is a reason to rank it. Reachability analysis, which checks whether your code calls the affected function, turns "three CVEs in spring-webmvc" into "one service calls javaScriptEscape in a JSP and two do not."
Try it yourself
Search one Spring service for the three triggers above and write down which CVEs it can reach. Then see how a scanner that understands calls would rank the same findings.
Click through it at your own pace, or open it full screen.
Quick check
Which Spring versions have open source fixes for these CVEs?
7.0.8 and 6.2.19. The 7.0.7.1, 6.2.18.1, 6.1.28 and 5.3.49 builds are for Enterprise Support customers.
What must be true for CVE-2026-41842 to be reachable?
The app uses Spring MVC or WebFlux, serves static resources from the file system, and has versioned resources configured.
