CVE-2024-38819

What it actually does

This is a path traversal vulnerability in Spring applications that serve static resources using the functional web frameworks WebMvc.fn or WebFlux.fn. If a static resource handler does not properly constrain requested paths to the intended resource directory, a remote unauthenticated attacker can submit crafted HTTP paths containing traversal sequences or encoded traversal sequences and cause the application process to read files outside the static resource root. The impact is confidentiality-focused: files readable by the application operating-system user may be exposed, including configuration files, secrets, source artifacts, environment data, keys, logs, and application metadata. The CVSS vector indicates network exploitation, low attack complexity, no authentication, and no user interaction, with high confidentiality impact and no direct integrity or availability impact.

Why it matters to the business

Successful exploitation can expose sensitive files from internet-facing Spring applications, potentially leaking credentials, API keys, database connection strings, cloud tokens, private configuration, or intellectual property. Those secrets can then be used for follow-on compromise of databases, cloud services, internal systems, or third-party integrations. Although this issue is not currently listed in CISA KEV and is not marked as ransomware-associated, the supplied EPSS score is high and exploit maturity is listed as weaponized, so exposed applications should be treated as urgent. The supplied affected-product metadata references Ubuntu flashplugin-nonfree with fixed version 11.2.202.577ubuntu0.14.04.1, but that package appears inconsistent with the Spring Framework vulnerability description; organizations should validate both Spring Framework exposure and any separately inventoried Ubuntu package exposure rather than assuming one remediates the other.

How an attack unfolds

An attacker first identifies a Spring application endpoint that serves static content through WebMvc.fn or WebFlux.fn, such as a route returning files from a classpath or filesystem resource location. The attacker then sends HTTP requests with path traversal payloads, including dot-dot-slash sequences or URL-encoded equivalents, to attempt to escape the configured static resource directory. If vulnerable, the framework resolves the manipulated path against the filesystem and returns a file that is accessible to the application process but outside the intended public content directory. The attacker typically starts with harmless proof files, then requests high-value files such as application configuration, environment files, service account credentials, private keys, logs, deployment metadata, or source artifacts. Any recovered secrets may be used to authenticate to downstream systems, expand access, or prepare additional attacks.

How to fix it

Upgrade affected Spring Framework versions to vendor-fixed releases for the applicable branch and rebuild/redeploy applications. For Spring Framework deployments, verify the official Spring advisory for the exact fixed release matching the branch in use; commonly remediated branches should be moved to fixed or later versions such as 6.1.14, 6.0.25, or 5.3.41 where applicable. If the supplied package inventory is relevant to a separate Ubuntu 14.04 LTS asset, update flashplugin-nonfree to 11.2.202.577ubuntu0.14.04.1 or later, but do not treat that package update as remediation for the Spring application vulnerability. As compensating controls, remove unnecessary static resource routes, avoid serving filesystem-backed resources when classpath resources are sufficient, restrict file permissions for the application runtime user, block traversal patterns at reverse proxies or WAFs, and ensure static file handlers normalize and validate paths before serving content. Rotate any secrets that may have been stored in files readable by the application if exploitation is suspected.

How to confirm the fix worked

Confirm the deployed application is using a fixed Spring Framework version by checking the runtime dependency tree, SBOM, container image contents, build manifests, or JAR metadata. Review application code for WebMvc.fn or WebFlux.fn routes that serve static resources and verify they are no longer vulnerable after upgrade. Perform controlled testing in a non-production or authorized environment by requesting benign traversal payloads and confirming the application returns 400, 403, or 404 rather than file contents outside the configured static resource location. Validate that reverse proxies, WAFs, and application logs capture traversal attempts. For Ubuntu assets, confirm package status with package-management tooling and verify flashplugin-nonfree is at 11.2.202.577ubuntu0.14.04.1 or later if that package is present.

Typical attack path

1. Discover a publicly reachable Spring application serving static resources.
2. Fingerprint routes that use functional web endpoints or static resource handlers.
3. Send traversal probes using ../, ..\, and encoded variants such as %2e%2e%2f.
4. Confirm exposure by retrieving a predictable local file or application metadata file.
5. Enumerate readable files accessible to the application process.
6. Extract credentials, configuration secrets, keys, or tokens from exposed files.
7. Use recovered secrets for lateral movement, cloud access, database access, or further application compromise.

How to detect it

Review HTTP access logs, reverse-proxy logs, WAF events, CDN request logs, application logs, and endpoint telemetry from systems running Spring applications. Look for requests to static-resource endpoints containing traversal patterns such as ../, ..\, %2e%2e%2f, %252e%252e%252f, or mixed encoded separators. Prioritize requests that returned HTTP 200, unusually large response bodies, text/plain responses, or filenames associated with secrets and configuration. Search for attempted reads of /etc/passwd, /etc/shadow, /proc/self/environ, application.properties, application.yml, bootstrap.yml, .env, WEB-INF/web.xml, pom.xml, build.gradle, id_rsa, and cloud credential files. Correlate suspicious requests with outbound authentication activity, new cloud API calls, database logins, secret-manager access, or unusual process activity shortly afterward. If application logs include resolved file paths, search for paths escaping the configured static resource directory. Because attackers often encode traversal payloads multiple times, normalize URL decoding during log analysis before matching.

• ../
• ..\
• %2e%2e%2f
• %2e%2e/
• ..%2f
• %2e%2e%5c
• ..%5c
• %252e%252e%252f
• %252e%252e%255c
• ....//
• ..;/
• /etc/passwd
• /etc/shadow
• /proc/self/environ
• /proc/self/cmdline
• /var/log/
• application.properties
• application.yml
• bootstrap.yml
• .env
• WEB-INF/web.xml
• META-INF/MANIFEST.MF
• pom.xml
• build.gradle
• gradle.properties
• settings.xml
• id_rsa
• id_dsa
• .aws/credentials
• .kube/config
• file:
• classpath:
• Resolved resource path outside
• Invalid resource path
• Path contains "WEB-INF" or "META-INF"

What your security team should do

• Prioritize internet-facing Spring applications that use WebMvc.fn or WebFlux.fn static resource handling because exploitation is unauthenticated, low complexity, and listed as weaponized with high EPSS.
• Inventory Spring Framework versions across applications, containers, and build artifacts; upgrade affected branches to fixed vendor-supported releases.
• Search source code and route definitions for functional static resource handlers and review any filesystem-backed resource mappings.
• Deploy temporary WAF or reverse-proxy rules to block traversal sequences and encoded traversal variants while upgrades are being completed.
• Restrict the operating-system permissions of application runtime users so they cannot read secrets, private keys, deployment files, or unrelated application data.
• Hunt historical web access logs for traversal attempts and successful responses containing sensitive file content.
• Rotate credentials and tokens stored in files accessible to the application process if logs indicate probable exploitation.
• Treat the supplied flashplugin-nonfree fixed version as separate package hygiene unless local validation confirms it is in scope; do not let inconsistent package metadata delay Spring Framework remediation.