CVE-2026-41842

What it actually does

CVE-2026-41842 is a network-exploitable denial-of-service vulnerability in Spring Framework static resource resolution used by Spring MVC and Spring WebFlux applications. An unauthenticated remote attacker can send crafted requests for static resources that cause excessive resource consumption during resource resolution, degrading or exhausting application availability. The vulnerability affects Spring Framework 7.0.0 through 7.0.7, 6.2.0 through 6.2.18, 6.1.0 through 6.1.27, and 5.3.0 through 5.3.48. The flaw does not provide confidentiality or integrity impact, but it can materially affect availability.

Why it matters to the business

Applications built on affected Spring Framework versions may become slow, unstable, or unavailable if exposed endpoints serving static resources are abused. For customer-facing services, this can result in outages, failed transactions, degraded user experience, increased infrastructure cost from autoscaling or retry storms, and operational disruption for support and incident response teams. Although EPSS is currently low and no known exploited-in-the-wild status is reported, the issue is remotely reachable, unauthenticated, low-complexity, and has high availability impact, so internet-facing Spring applications should be prioritized for remediation.

How an attack unfolds

An attacker first identifies a Spring MVC or WebFlux application that serves static resources such as JavaScript, CSS, images, web assets, documentation, or frontend bundles. The attacker then sends crafted HTTP requests targeting static resource paths in a way that triggers inefficient or expensive resource resolution inside vulnerable Spring Framework versions. Because no authentication or user interaction is required, the attacker can automate the request pattern from a single host or distributed infrastructure. Repeated requests can consume CPU, memory, threads, file-system lookups, or event-loop capacity depending on the application configuration and runtime, eventually causing high latency, request failures, thread starvation, container restarts, or full service unavailability. Current public exploit maturity is reported as none, and the CVE is not listed in CISA KEV, but the vulnerability characteristics make it suitable for opportunistic denial-of-service activity once exploit details become public.

How to fix it

Upgrade Spring Framework to a version that contains the vendor fix for the affected release line. The affected ranges are 7.0.0 through 7.0.7, 6.2.0 through 6.2.18, 6.1.0 through 6.1.27, and 5.3.0 through 5.3.48; use the next patched version available for the applicable supported branch from the Spring project or your platform vendor. If Spring Framework is consumed through Spring Boot, upgrade Spring Boot to a release that includes the fixed Spring Framework dependency rather than overriding individual framework modules unless vendor guidance explicitly supports doing so. Where immediate upgrade is not possible, reduce exposure by placing rate limiting, request-size limits, request-normalization controls, bot protection, and WAF/CDN filtering in front of static resource paths; restrict unnecessary static resource handlers; serve static assets from a CDN or dedicated static file server; and monitor application resource saturation. Because this is an availability issue, also verify autoscaling, connection limits, circuit breakers, and operational runbooks to withstand abusive request bursts while remediation is underway.

How to confirm the fix worked

Confirm dependency versions from build manifests and runtime artifacts. For Maven, review dependency:tree output and resolved versions of org.springframework:spring-webmvc, org.springframework:spring-webflux, org.springframework:spring-web, spring-core, and related Spring Framework modules. For Gradle, review dependencies or dependencyInsight output for org.springframework framework modules. For packaged applications, inspect SBOMs, container image scans, application JAR/WAR contents, and BOOT-INF/lib entries for Spring Framework versions in the affected ranges. Validate that deployed workloads, not just source repositories, are running fixed versions. Exercise static resource endpoints with normal traffic patterns after patching and confirm that resource usage remains stable. Confirm compensating controls by testing rate-limit behavior and verifying that malformed or high-frequency static-resource requests are blocked, throttled, or absorbed before reaching the application.

Typical attack path

1. Identify internet-accessible applications likely built with Spring MVC or Spring WebFlux.
2. Probe for static resource routes such as /static/, /assets/, /webjars/, /css/, /js/, /images/, favicon.ico, or other publicly served resource paths.
3. Send crafted HTTP requests that exercise vulnerable static resource resolution behavior.
4. Increase request volume or concurrency to amplify CPU, memory, thread, event-loop, or file-system lookup pressure.
5. Monitor for application slowdown, elevated error rates, connection timeouts, or service restarts.
6. Continue or distribute traffic to sustain denial of service until rate limits, filtering, scaling, or patching interrupts the attack.

How to detect it

Review web server, reverse proxy, CDN, WAF, and application access logs for unusual request volume, concurrency, or repeated patterns against static resource paths. Focus on unauthenticated requests to resource-serving endpoints such as /static/, /assets/, /public/, /resources/, /webjars/, /css/, /js/, /images/, and individual asset files, especially when correlated with latency spikes, 5xx errors, thread-pool exhaustion, high CPU, memory pressure, garbage collection pauses, event-loop saturation, or container restarts. Compare baseline static resource traffic against the period after publication and any outage windows. Investigate single-source bursts, rotating-source distributed bursts, abnormal path depth, encoded path segments, traversal-like sequences, repeated cache misses, unusual query strings on static files, and high rates of 404/500 responses. Application logs may show resource handler resolution failures, repeated static resource lookup exceptions, timeouts, or request processing failures around the same timestamps as infrastructure saturation. No public, stable exploit payload indicator is available from the provided data, so detection should emphasize behavioral anomalies and correlation across edge logs, application telemetry, JVM metrics, container orchestration events, and uptime monitoring.

• GET /static/
• GET /assets/
• GET /public/
• GET /resources/
• GET /webjars/
• GET /css/
• GET /js/
• GET /images/
• /favicon.ico
• No static resource
• ResourceHttpRequestHandler
• ResourceWebHandler
• ResourceHttpRequestHandler.handleRequest
• org.springframework.web.servlet.resource
• org.springframework.web.reactive.resource
• ResolvedResource
• HTTP 503
• HTTP 504
• java.lang.OutOfMemoryError
• RejectedExecutionException
• reactor.core.Exceptions
• Request processing failed

What your security team should do

• Inventory internet-facing and business-critical applications using Spring MVC or Spring WebFlux and identify those running Spring Framework 7.0.0-7.0.7, 6.2.0-6.2.18, 6.1.0-6.1.27, or 5.3.0-5.3.48.
• Prioritize patching externally reachable applications and services where static resources are served directly by the Spring application.
• Upgrade through the appropriate Spring Boot or Spring Framework release path and redeploy all affected runtime artifacts, including containers, serverless packages, and embedded application bundles.
• Until patched, apply edge rate limiting and WAF/CDN rules for abnormal request rates or malformed requests targeting static resource paths.
• Move static assets to CDN or dedicated static hosting where practical to reduce load on Spring application runtimes.
• Add monitoring and alerts for spikes in requests to static resource paths, elevated 4xx/5xx responses, request latency, thread-pool saturation, event-loop saturation, CPU, memory, garbage collection, and container restarts.
• Review incident response procedures for denial-of-service events, including traffic filtering, upstream provider escalation, and temporary static route blocking.
• Track vendor advisories for exact fixed versions for each maintained Spring Framework branch and update dependency constraints or BOMs accordingly.