CVE-2026-41843

What it actually does

Spring MVC and Spring WebFlux applications using Spring Framework versions 7.0.0 through 7.0.7, 6.2.0 through 6.2.18, 6.1.0 through 6.1.27, or 5.3.0 through 5.3.48 can incorrectly resolve static resource paths in a way that permits path traversal. A remote unauthenticated attacker may be able to craft HTTP requests containing traversal sequences or encoded path components that escape the intended static resource directory and read files from elsewhere on the application host. The primary impact is unauthorized file disclosure; the CVSS vector indicates network reachability, no required privileges or user interaction, high confidentiality impact, no direct integrity or availability impact, and high attack complexity.

Why it matters to the business

Successful exploitation could expose sensitive local files such as application configuration, environment-specific secrets, logs, source artifacts, private keys, or deployment metadata, which may enable follow-on compromise even though the vulnerability does not directly modify data or execute code. Because Spring Framework is widely used across Java web applications and downstream products, exposure can be broad where affected versions are embedded. The vulnerability is not currently listed in CISA KEV, has no known ransomware association, has low EPSS probability, and no public exploit maturity in the provided data, but internet-facing applications serving static resources should still be prioritized for review due to the potential sensitivity of disclosed files.

How an attack unfolds

An attacker first identifies a Spring MVC or WebFlux application that serves static resources through vulnerable Spring Framework versions. They then probe static resource routes with crafted URL paths containing directory traversal sequences such as ../, URL-encoded traversal, double-encoded traversal, or path normalization bypasses. If the application’s static resource handler resolves the path outside the intended resource location, the server may return the contents of files on the filesystem that should not be web-accessible. The attacker typically iterates through likely file locations, targeting configuration files, logs, credentials, or application metadata. Any recovered secrets may then be reused to access databases, cloud services, management interfaces, CI/CD systems, or other application dependencies.

How to fix it

Upgrade Spring Framework to a fixed version outside the affected ranges. 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 vendor-provided fixed release for the relevant branch, such as a release newer than 7.0.7, 6.2.18, 6.1.27, or 5.3.48 when available. Also upgrade dependent frameworks and platforms that bundle Spring Framework, including Spring Boot or vendor distributions, rather than only updating direct application code. If immediate upgrade is not possible, restrict static resource handlers to known-safe locations, disable unnecessary static resource mappings, block traversal patterns at an edge proxy or WAF, reject encoded path separators and dot-segment traversal, and ensure the application process has least-privilege filesystem access so sensitive files are not readable by the web application runtime.

How to confirm the fix worked

Confirm the deployed application resolves to a non-affected Spring Framework version by inspecting dependency manifests, SBOMs, build files, packaged JARs, container images, and runtime classpath. For Maven, review dependency:tree output for org.springframework:spring-webmvc, org.springframework:spring-webflux, spring-web, spring-core, and the Spring Framework BOM version. For Gradle, review dependencies and dependencyInsight output for Spring Framework artifacts. Validate that no transitive dependency or packaged fat JAR still contains affected Spring Framework versions. Perform controlled testing against static resource routes using benign traversal probes and confirm requests are rejected or normalized safely and cannot access files outside the intended static resource roots. Review web server, reverse proxy, and application access logs for historical traversal probes and verify WAF or proxy rules do not interfere with legitimate static assets.

Typical attack path

1. Identify a Java web application likely using Spring MVC or Spring WebFlux.
2. Map routes that serve static files, assets, webjars, documentation, uploaded content, or application resources.
3. Send traversal probes using raw, encoded, double-encoded, or mixed path separator payloads.
4. Observe HTTP 200 responses, unusual file contents, changes in response length, or errors indicating filesystem path resolution.
5. Request high-value local files such as configuration files, logs, environment files, key material, or application metadata.
6. Use any disclosed secrets or internal information for follow-on access, privilege escalation, or lateral movement.

How to detect it

Review HTTP access logs from application servers, reverse proxies, load balancers, CDNs, and WAFs for requests to static resource paths containing traversal sequences. Look for raw ../, backslash traversal, encoded traversal such as %2e%2e%2f, double-encoded traversal such as %252e%252e%252f, overlong or mixed encoding, and requests targeting common local files. Prioritize events that returned HTTP 200, 206, 304, or unusually large response bodies, especially when the requested URI contains sensitive filenames. Review application logs for exceptions or debug messages from Spring resource handling, path normalization, ResourceHttpRequestHandler, WebFlux resource handlers, and file access errors. Correlate suspicious requests with subsequent authentication attempts, use of newly exposed credentials, access to administrative endpoints, or outbound connections to unusual destinations. If file disclosure is suspected, examine whether requested paths map to secrets such as application.properties, application.yml, .env, log files, keystores, cloud credential files, or container metadata. There are no named threat actors or known exploitation campaigns in the provided data, so detection should focus on generic path traversal behavior rather than actor-specific infrastructure.

• ../
• ..%2f
• ..%2F
• %2e%2e%2f
• %2e%2e/
• %2e%2e%5c
• %252e%252e%252f
• %252e%252e%255c
• ..\
• %2e%2e\
• ..;/
• ....//
• ....\\
• /etc/passwd
• /etc/shadow
• /etc/hosts
• /proc/self/environ
• /proc/self/cmdline
• /proc/self/mounts
• /var/log/
• /var/log/messages
• /var/log/syslog
• /var/log/tomcat/
• /WEB-INF/web.xml
• /META-INF/MANIFEST.MF
• application.properties
• application.yml
• bootstrap.properties
• bootstrap.yml
• .env
• .git/config
• id_rsa
• id_dsa
• known_hosts
• authorized_keys
• keystore.jks
• truststore.jks
• ResourceHttpRequestHandler
• PathResourceResolver
• NoResourceFoundException

What your security team should do

• Inventory internet-facing and internal Java web applications using Spring MVC or Spring WebFlux and identify affected Spring Framework versions.
• Prioritize remediation for internet-facing applications, applications serving static resources, and applications with access to secrets, local configuration files, or sensitive logs.
• Upgrade Spring Framework and any platform that bundles it to a fixed release outside the affected version ranges.
• Add temporary WAF or reverse-proxy controls to block dot-segment traversal, encoded traversal, double-encoded traversal, and suspicious static resource requests while upgrades are being deployed.
• Harden application runtime permissions so the web application user cannot read secrets, deployment keys, or unrelated system files.
• Rotate credentials if logs show successful or likely file disclosure of configuration, environment files, key stores, tokens, or logs containing secrets.
• Search historical HTTP logs for traversal payloads dating back at least to the publication date and longer where retention permits.
• Add SIEM detections for traversal attempts against static resource paths and alert on successful 200 responses with unusual response sizes or content types.
• Because EPSS is currently low and there is no KEV listing or known exploit maturity in the provided data, treat this as urgent for exposed high-value applications rather than broad emergency patching across fully internal low-risk systems.