CVE-2024-38819: Spring Framework path traversal in functional static-resource routes
The short version: Spring Framework has a path-traversal flaw (CVE-2024-38819) that can let an attacker read arbitrary files from the host — but it only bites applications that serve static resources through the functional web frameworks (WebMvc.fn / WebFlux.fn) in a particular configuration. If that's you, patch; if it isn't, you're likely not affected. Steady hands.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — gated by a specific app configuration (see below) |
| CVSS v3.1 (NVD) | 7.5 — High · AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N |
| EPSS | ~54.9% · 98.9th percentile (2026-07-17) |
| In CISA KEV? | No |
| Known exploited? | Not listed in KEV; no confirmed in-the-wild activity at time of writing |
| Vulnerability type | CWE-22 path traversal → arbitrary file read |
| Requires authenticated session? | No — pre-authentication |
| Affected | Spring Framework 5.3.40 and earlier, 6.0.0–6.0.24, 6.1.0–6.1.13 — only when RouterFunctions serve static resources and the resource location is an explicitly configured FileSystemResource |
| Fixed in | 6.1.14 (OSS) · 6.0.25 · 5.3.41 (Enterprise Support) |
What you need to know
CVE-2024-38819 is a path traversal in Spring's functional web frameworks. When an application uses RouterFunctions to serve static resources and the resource handler points at an explicitly configured FileSystemResource location, a crafted request can escape that directory and read other files the application process can reach.
The important nuance is the narrow trigger. This is not "every Spring app is exposed":
- Both conditions must hold — static resources served via the functional endpoints (WebMvc.fn / WebFlux.fn) and a
FileSystemResourcelocation. Apps that don't serve static content this way aren't affected. - Spring Security's HTTP Firewall blocks it — if you run the Spring Security HTTP Firewall, malicious traversal requests are rejected.
- Unlike a related variant, Tomcat and Jetty deployments are affected for this one.
How serious we see it
High — and we'll say plainly when it's worse.
On paper it's a 7.5 (High) because an unauthenticated arbitrary file read is genuinely serious. In practice the severity is gated by whether your application meets the specific configuration above, and it isn't in KEV or (at time of writing) confirmed exploited in the wild. For an app that does meet the trigger and has no HTTP Firewall in front of it, treat this as High and patch promptly. For everyone else, it's a patch-in-the-normal-cycle item. Either way it's fixed and quick to reason about.
Recommendations
Straight from the Spring advisory:
- Upgrade. Move to 6.1.14 (or 6.0.25 / 5.3.41 on Enterprise Support) or later.
- Confirm whether you even meet the trigger. Check whether your app serves static resources via
RouterFunctionswith aFileSystemResourcelocation — if not, your exposure is limited. - Keep the Spring Security HTTP Firewall in place. It rejects the malicious traversal requests as a defense-in-depth layer.
- Restrict exposure until patched where the configuration applies.
How BreachRisk sees it
BreachRisk discovers your internet-facing web applications from the outside and fingerprints the frameworks behind them, including Spring, flagging exposure tied to this CVE. Where a safe check is possible, it goes beyond version-matching and issues a single bounded, non-destructive request that attempts to read a harmless system file — confirming whether the traversal actually resolves rather than assuming it from a banner. That's the honest difference between "this looks like a vulnerable Spring build" and "we confirmed the file read."