CVE-2026-41841

What it actually does

This vulnerability affects Spring MVC and Spring WebFlux static resource resolution. Under specific, high-complexity request conditions, an unauthenticated remote attacker may be able to cause the framework to resolve and return files or resources that were not intended to be publicly exposed. The impact is confidentiality-only: successful exploitation can disclose sensitive application files, configuration resources, classpath resources, or other static content accessible through the vulnerable resource handling path. There is no direct code execution, data modification, or service disruption indicated by the advisory.

Why it matters to the business

Applications using affected Spring Framework versions may unintentionally expose sensitive files such as configuration data, internal application resources, or deployment metadata. If secrets, credentials, API keys, internal endpoints, or business logic are disclosed, attackers could use that information to support follow-on compromise. The CVSS score is moderate, EPSS is currently low and stable, and the vulnerability is not known to be in CISA KEV or ransomware campaigns, but internet-facing Java applications should still be remediated because information disclosure bugs can become high-impact when exposed files contain secrets.

How an attack unfolds

An attacker first identifies an internet-accessible application built with an affected Spring Framework version and using Spring MVC or Spring WebFlux static resource handling. They then probe static resource endpoints with crafted paths, encoded path segments, unusual separators, or resource-location edge cases intended to make the framework resolve resources outside the intended public static content area. If the application’s static resource configuration and deployment layout meet the vulnerable conditions, the server may return sensitive files that should not be web-accessible. The attacker reviews disclosed content for secrets, internal URLs, source artifacts, framework metadata, or configuration values that can be used for credential theft, lateral movement, or targeted exploitation of other services.

How to fix it

Upgrade Spring Framework to a version newer than the affected ranges for the branch in use. 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. If exact fixed versions are not yet listed in local dependency tooling, consult the official Spring advisory and move to the first patched release available for the maintained branch, or to a newer supported major/minor line. Also review custom static resource handlers, resource locations, and path pattern configurations; ensure sensitive directories such as configuration, classpath internals, source files, templates, build artifacts, and deployment metadata are never mapped as public static resources. As defense in depth, block access to sensitive file names at the reverse proxy or WAF, disable directory browsing where applicable, remove secrets from packaged artifacts, and avoid storing production credentials in files that could be served by the application.

How to confirm the fix worked

Confirm exposure by inventorying applications that depend on Spring Framework and checking resolved dependency versions in build output, software composition analysis, Maven dependency trees, Gradle dependency reports, container SBOMs, or runtime manifests. The application is remediated when no deployed artifact resolves to 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. Validate static resource behavior in a non-production environment by attempting to request known non-public files through static resource routes and confirming they return 403 or 404 rather than file contents. Review application and proxy routing to confirm only intended public static directories are exposed.

Typical attack path

1. Identify Spring-based web applications, especially those exposing static resources through Spring MVC or Spring WebFlux.
2. Fingerprint the framework or infer Spring usage from headers, error pages, static asset paths, or application behavior.
3. Send crafted requests to static resource paths using traversal-like sequences, encoded dot segments, double encoding, unusual path normalization, or resource handler edge cases.
4. Observe HTTP 200 responses, abnormal content types, file downloads, or responses containing configuration or application metadata.
5. Extract sensitive values such as secrets, tokens, internal hostnames, dependency metadata, or application configuration.
6. Use the disclosed information to support follow-on attacks such as credential abuse, targeted exploitation, or internal service discovery.

How to detect it

To assess whether exploitation already occurred, review HTTP access logs from application servers, API gateways, reverse proxies, load balancers, CDN logs, and WAF events for unusual requests to static resource paths. Focus on requests containing path traversal markers, encoded traversal, double-encoded characters, semicolon path parameters, backslashes, or attempts to retrieve sensitive files such as application configuration, build metadata, classpath resources, templates, private keys, or deployment descriptors. Correlate suspicious requests with successful HTTP 200 responses, non-image or non-CSS content types returned from static paths, unusually large downloads, repeated probing from a single IP, and requests followed by authentication failures or activity against newly discovered internal endpoints. Application logs may also show resource resolution warnings, static resource handler misses, abnormal normalized paths, or exceptions related to invalid paths. Because no public exploit maturity is currently reported and EPSS is low, detections should emphasize successful disclosure indicators rather than scanning noise alone.

• ../
• ..\\
• %2e%2e
• %2E%2E
• %252e%252e
• %2f..%2f
• %5c..%5c
• ..;/
• WEB-INF
• META-INF
• application.properties
• application.yml
• application.yaml
• bootstrap.properties
• bootstrap.yml
• logback.xml
• log4j2.xml
• pom.xml
• build.gradle
• gradle.properties
• .env
• id_rsa
• private.key
• keystore.jks
• truststore.jks
• classpath:
• file:

What your security team should do

• Prioritize inventory of internet-facing Spring MVC and Spring WebFlux applications using the affected Spring Framework version ranges.
• Upgrade affected applications to the first vendor-patched release newer than the affected branch, or to a supported unaffected Spring Framework line.
• Review static resource handler configuration for overly broad mappings, classpath-wide resource exposure, or mappings that include sensitive directories.
• Search web, reverse proxy, CDN, and application logs for suspicious static resource requests containing traversal sequences, encoded dot segments, or sensitive file names.
• Rotate any credentials, tokens, or keys if logs or testing indicate sensitive configuration files may have been exposed.
• Add WAF or reverse-proxy rules to block requests for common sensitive files and encoded path traversal patterns as a temporary mitigation, but do not treat this as a substitute for upgrading.
• Ensure packaged application artifacts do not contain production secrets, private keys, source archives, or unnecessary configuration files.