Directory traversal in Spring Cloud Config exposes arbitrary files
TL;DR - A specially crafted URL sent to spring-cloud-config-server triggers directory traversal, letting the server return arbitrary text or binary files to the caller. This is rated CRITICAL. Upgrade to the fixed version for your branch - details in the table below.
What happened
Spring Cloud Config is the configuration-plane component that many Spring-based architectures use to serve externalised application config - database URLs, feature flags, credentials - to running services.
On 6 May 2026, Spring published CVE-2026-40982 as CRITICAL: a malicious caller can send a crafted URL to the spring-cloud-config-server module and trigger a directory traversal condition. The server then reads and returns arbitrary text or binary files accessible to its process.
The threat model here is worse than a typical file-read bug. Config servers sit on a high-trust internal path and routinely hold or reference credentials. A working traversal in this layer is a direct route to secrets, key material, and the credentials of every downstream service. For more background on this class of vulnerability, see our path traversal research and the secure dependency management guide.
Who is impacted
Any deployment running spring-cloud-config-server on an affected version line is vulnerable. Spring also confirms that older, unsupported versions are affected.
| Affected line | Fixed version | Availability |
|---|---|---|
3.1.x | 3.1.14 | Enterprise Support only |
4.1.x | 4.1.10 | Enterprise Support only |
4.2.x | 4.2.7 | Enterprise Support only |
4.3.x | 4.3.3 | OSS |
5.0.x | 5.0.3 | OSS |
What to do now
- Upgrade immediately to the fixed version for your active branch. Spring's guidance is direct:
"Users of affected versions should upgrade to the corresponding fixed version."
- Inventory every place
spring-cloud-config-serveris deployed - application-level instances, shared platform services, and any "internal-only" config servers that still have broad network reach. Internal does not mean safe here. - Treat this as a potential sensitive-file exposure and scope your response accordingly:
- Review access logs for request paths consistent with traversal attempts (unexpected
../sequences, encoded path separators, or requests for non-config file types). - Rotate credentials that could plausibly be present on, or readable by, the Config Server host or its runtime environment.
- Review access logs for request paths consistent with traversal attempts (unexpected
- If your organisation runs multiple Config Server branches, prioritise the instances with the widest network reach first - internet-facing before internal, shared platform before single-team.
For operational playbooks on handling this class of incident, see our secrets management research and incident response guide.
