CVE-2024-38816

What it actually does

CVE-2024-38816 is a path traversal vulnerability in Spring applications that serve static resources through the functional web frameworks WebMvc.fn or WebFlux.fn. It applies when RouterFunctions are used for static resource serving and the resource location is explicitly configured as a FileSystemResource. A remote unauthenticated attacker can craft HTTP requests containing traversal sequences to escape the intended static-resource directory and read arbitrary files that are accessible to the Spring application process. The impact is confidentiality-focused: the vulnerability enables file disclosure, not direct file modification or code execution. Requests are expected to be blocked when Spring Security HTTP Firewall is in use or when the application runs on Tomcat or Jetty.

Why it matters to the business

Successful exploitation can expose sensitive files such as application configuration, credentials, environment-specific secrets, certificates, source files, logs, or deployment metadata. This may lead to account compromise, lateral movement, cloud or database credential theft, and broader breach escalation. The CVSS score is high at 7.5, EPSS is elevated at approximately 14.7%, and exploit maturity is listed as weaponized, so internet-facing Spring applications using the vulnerable static-resource pattern should be treated as priority remediation targets even though the issue is not currently listed in CISA KEV and is not known from the provided data to be used in ransomware campaigns.

How an attack unfolds

An attacker first identifies a Spring application exposing static resources through functional routing rather than conventional MVC resource handling. They then send crafted HTTP requests to the static resource route using path traversal sequences such as ../ or encoded variants. In vulnerable configurations, Spring resolves the requested path relative to a FileSystemResource location without correctly preventing traversal outside the intended directory. If the application is not protected by Spring Security HTTP Firewall and is not running on a container that rejects the malicious path, the attacker receives the contents of files readable by the application process. The attacker typically starts with known operating-system and application files, then pivots to configuration files, secrets, keystores, logs, and deployment artifacts that can enable further compromise.

How to fix it

Upgrade Spring Framework to a fixed version. Where applicable, use Spring Framework 6.1.13 or later, 6.0.24 or later, or 5.3.40 or later. If using Spring Boot, upgrade to a Spring Boot release that includes the corrected Spring Framework version. Review applications for RouterFunctions-based static resource handling with explicit FileSystemResource locations and remove or redesign that pattern where possible. Prefer classpath-backed or container-managed static resources when feasible. Enable Spring Security HTTP Firewall where compatible, and ensure request normalization rejects encoded and double-encoded traversal sequences. As a compensating control, restrict filesystem permissions for the application process so it cannot read secrets or files outside its required runtime scope. Running behind Tomcat or Jetty may block the malicious requests, but this should not be treated as a substitute for upgrading vulnerable Spring components.

How to confirm the fix worked

Confirm the deployed application uses a fixed Spring Framework version by checking dependency manifests, SBOMs, build files, and runtime package metadata. Search code for RouterFunctions static-resource mappings that use FileSystemResource locations, including RouterFunctions.resources(...) and resource lookup functions backed by filesystem paths. Validate that Spring Security HTTP Firewall or equivalent request rejection is active where applicable. In a non-production environment, create a harmless test file outside the intended static-resource directory and verify that traversal attempts through static-resource routes return a rejection or 404 rather than file contents. Test encoded and double-encoded traversal variants. Confirm that the application process runs with least-privilege filesystem access and cannot read sensitive configuration files outside its intended directories.

Typical attack path

1. Discover a Spring-based web application with reachable static-resource endpoints.
2. Probe static-resource URLs with traversal payloads such as ../, encoded dot-dot-slash sequences, or requests for known files.
3. Identify whether the application leaks files outside the configured static-resource directory.
4. Retrieve high-value local files such as application.properties, application.yml, .env files, keystores, logs, or operating-system account files.
5. Use exposed secrets, tokens, database credentials, or internal configuration details to expand access to other systems.
6. Cover activity by blending traversal probes into normal static-content requests or using encoded traversal variants.

How to detect it

Review HTTP access logs, reverse proxy logs, WAF logs, application logs, and container ingress logs for traversal attempts against static-resource routes. Focus on requests containing ../, encoded dot-dot-slash patterns, double-encoded traversal, backslash traversal, or requests for sensitive filenames. Pay special attention to successful 200 responses or unusually large responses for URLs that should only serve static content. Compare requested paths with known static-resource route prefixes. Investigate requests for files such as /etc/passwd, application.properties, application.yml, .env, keystore files, logs, or cloud credential files. If successful exploitation is suspected, identify exactly which files may have been returned, rotate exposed credentials, and review downstream authentication logs for use of leaked secrets. Because exploitation does not require authentication and leaves no required file artifact on the server, network and web-layer logs are the primary evidence source.

• ../
• ..\\
• %2e%2e%2f
• %2e%2e/
• ..%2f
• %2e%2e%5c
• ..%5c
• %252e%252e%252f
• %252e%252e%255c
• /etc/passwd
• /etc/shadow
• /proc/self/environ
• application.properties
• application.yml
• bootstrap.properties
• bootstrap.yml
• .env
• WEB-INF/web.xml
• META-INF/MANIFEST.MF
• id_rsa
• id_dsa
• known_hosts
• authorized_keys
• .aws/credentials
• .kube/config
• .docker/config.json
• .npmrc
• keystore.jks
• truststore.jks

What your security team should do

• Immediately inventory Spring applications using WebMvc.fn or WebFlux.fn RouterFunctions to serve static resources from FileSystemResource locations.
• Prioritize internet-facing applications, applications running on Reactor Netty or other non-Tomcat/non-Jetty runtimes, and applications without Spring Security HTTP Firewall.
• Upgrade affected Spring Framework dependencies to fixed versions: 6.1.13+, 6.0.24+, or 5.3.40+ where applicable.
• Add or verify request filtering that rejects raw, encoded, and double-encoded path traversal sequences before requests reach application routing.
• Review application runtime permissions and remove read access to secrets, deployment files, backups, and configuration files that do not need to be accessible to the application process.
• Search historical access logs for path traversal probes and successful 200 responses involving sensitive filenames.
• Rotate credentials and tokens if logs show successful reads of configuration, secret, keystore, or environment files.
• Add regression tests for functional static-resource routes to ensure traversal attempts cannot escape the intended resource root.