CVE-2026-22745

What it actually does

Unauthenticated remote Denial of Service in Spring MVC and Spring WebFlux when static resources are served from the local filesystem on Windows. Crafted requests make resource path resolution unusually slow, holding HTTP connections and worker threads until connection pools, thread pools, or accept queues are exhausted. Confidentiality and integrity are unaffected (CVSS 5.3, C:N/I:N/A:L).

Why it matters to the business

Public-facing Spring apps on Windows that serve files from disk can become slow or unavailable, causing outages, failed checkouts or logins, SLA breaches, and incident-response cost. Likelihood is currently low: EPSS ~0.0034 and flat over 30 days, not in CISA KEV, exploit maturity none, ~163 days since publication. Impact still scales with how widely Spring is used for static content on Windows; treat as an availability risk for internet-exposed services rather than an imminent mass-exploitation event.

How an attack unfolds

An unauthenticated attacker probes for Spring MVC or WebFlux apps on Windows that map static content to the filesystem. They send many concurrent HTTP requests against those static-resource URLs using path values that force expensive Windows filesystem lookups. Each request occupies a connection and a request thread for a long time. Without rate limits or short timeouts, connections stay in use, new clients fail, and the application appears down. No code execution, data theft, or known named threat-actor use is indicated.

How to fix it

Upgrade Spring Framework to a vendor-patched release from the official Spring/VMware security advisory for this issue (exact versions were not supplied with this record—confirm against current Spring Framework CVE notes for 5.x/6.x and Boot-managed BOMs). If you cannot patch immediately: stop serving static assets from the local filesystem on Windows (use a CDN, object storage, or a reverse proxy); restrict resource-handler locations; shorten server and proxy idle/read timeouts; cap concurrent connections and request rates on static paths; run the app on a non-Windows platform if that is an acceptable architecture change. Rebuild and redeploy all Boot/WAR artifacts that embed the vulnerable Spring jars.

How to confirm the fix worked

Inventory apps using Spring MVC or WebFlux on Windows with ResourceHandlerRegistry, WebJars, or WebFlux resource functions pointing at file: or filesystem locations. Confirm deployed spring-web / spring-webmvc / spring-webflux (and Boot parent) versions match a patched advisory line. After upgrade, regression-test static content and verify resource resolution no longer stalls under concurrent requests to static URLs. Review reverse-proxy and app-server configs for timeouts and connection limits. Do not use public exploit payloads to prove exposure.

Typical attack path

1. Discover an internet-reachable Spring MVC or WebFlux application running on Windows that serves static files from disk.
2. Identify URL mappings handled by the static resource pipeline (for example resource handlers or WebFlux resource routes).
3. Send concurrent HTTP requests with path values that trigger slow filesystem resolution on Windows.
4. Hold connections open so worker threads and the HTTP connection pool remain occupied.
5. Repeat until new legitimate requests time out or fail, producing a service outage.

How to detect it

This is an availability attack with no known in-the-wild exploitation, so look for symptoms rather than a unique malware artifact. Review HTTP access logs, load-balancer/WAF logs, and APM traces for bursts of long-duration GETs to static-resource paths, rising concurrent connections, thread-pool exhaustion, and timeouts without a matching traffic increase in business APIs. On hosts, correlate with Spring resource-handler threads blocked in filesystem APIs (PathResourceResolver / ResourceHttpRequestHandler or WebFlux resource resolution) and Windows file-open latency. Compare against change windows; a sudden stall after a deploy of filesystem-backed static handlers is more likely a config issue, while external IPs flooding static URLs is more consistent with abuse. No named APT campaigns are associated.

• ResourceHttpRequestHandler
• PathResourceResolver
• org.springframework.web.servlet.resource
• org.springframework.web.reactive.resource
• GET requests to static resource mappings with multi-second durations
• thread dumps showing blocked file I/O in spring-webmvc or spring-webflux resource resolution
• connection-pool / Tomcat-or-Netty worker exhaustion coincident with static-path traffic

What your security team should do

• Prioritize inventory of Windows-hosted Spring MVC/WebFlux apps that serve static files from disk; internet-facing instances first.
• Apply official Spring Framework upgrades as soon as patched versions are identified in the vendor advisory; rebuild Boot applications rather than hot-patching jars.
• If patching is delayed, move static assets off the app JVM (CDN/proxy) and enforce aggressive timeouts and rate limits on static routes.
• Track EPSS/KEV; this is not currently KEV and exploit maturity is none, so schedule as a medium availability fix rather than an emergency ransomware-driven patch.
• Add availability monitoring (thread-pool saturation, request duration, 5xx/timeouts on static paths) until patches are confirmed everywhere.