Vulnerability: Path Traversal in Spring Cloud Config Server ResourceController
Severity: 9.1 Critical (CVSS v3.1 Base score) CWE-22
Affected Versions: Spring Cloud Config Server 3.1.x through 5.0.x
Authentication Required: None
First Identified: April 23, 2026
Fixed In: 3.1.14 / 4.1.10 / 4.2.7 / 4.3.3 / 5.0.3
A path traversal vulnerability in Spring Cloud Config Server’s ResourceController allows an unauthenticated attacker to read arbitrary files from the server’s filesystem with a single HTTP request, no credentials, no user interaction required. The fix for a prior vulnerability (CVE-2026-22739) protected one parameter in one controller. Three others in an adjacent controller received no equivalent check. The gap was found during BAS exploit development for the Hive Pro Exposure Management platform.
This blog covers the following: Vulnerability Description and Details, Vulnerability Timeline, Risk, Attack Vector, Threat and Exploit, Business Impact, and Recommendation.
Responsible Disclosure
Spring Cloud Config Server is the centralized configuration and secret distribution layer for microservice environments built on the Spring framework. When any microservice starts up, it connects to Config Server and asks for its runtime configuration: database password, cloud provider credentials, JWT signing keys, API tokens, feature flags. Config Server pulls all of it from a Git repository and distributes it over HTTP.
This makes it one of the highest-value targets in any Spring-based infrastructure. Compromise Config Server and you do not need to break into individual services you get the keys to all of them at once.
Spring Boot, the foundation on which Spring Cloud Config Server runs, is used by over 71,000 companies globally. Any organisation running Spring Boot-based microservices at scale is a potential Spring Cloud Config Server user. More than 60% of Java developers use Spring as their primary framework, and it dominates enterprise Java banking, healthcare, insurance, government, e-commerce. Config Server is a default component in any microservices deployment on this stack. When a flaw lands here, the blast radius is wide.
Local, cloud, or both all deployments are at risk
Config Server is deployed in two common configurations, and both carry exposure:
CVE-2026-40982 is a path traversal flaw in ResourceController, one of three request handlers inside Spring Cloud Config Server that accept user-controlled URL inputs. The server uses four path variables to serve configuration files: name, profile, label, and path.
The fix for CVE-2026-22739 added a traversal check to the profile variable in EnvironmentController. That same variable also flows through ResourceController, and the three remaining variables name, label, and path received no protection at all. An attacker sends a crafted GET request with a traversal sequence in any of those three variables. The controller passes it through. The server returns the file.
Officially, this is CWE-22 Path Traversal. Under OWASP it maps to A01:2021-Broken Access Control (accessing files outside the intended boundary) and A05:2021-Security Misconfiguration (the same protection applied to one controller, never the others). Both matter when making the case for patching to leadership or an auditor.
Spring Cloud Config Server has a seven-year documented history of path traversal vulnerabilities in the same module. The pattern is consistent across all of them: a flaw is reported, the fix is applied to the specific parameter that was flagged, and the adjacent parameters are left untouched. The next researcher finds one of those gaps and the cycle repeats.
⚠️ Note: This vulnerability has the highest impact on deployments running Spring Cloud Config Server with a custom ResourceRepository implementation. In default setups, a fallback check inside the built-in repository may catch the traversal. With a custom repository, that safety net does not exist; a single unauthenticated request reads the file directly.
Very easy. There is no exploit chain, no specialised tooling, no insider access needed. This is a single crafted HTTP GET request.
ResourceRepository. On default installations, a fallback check may intercept the traversal at the repository layer however the controller still passes the request through unchecked.#1 Initial access via network reach. Attacker identifies a reachable Spring Cloud Config Server endpoint. In cloud environments, misconfigured security groups have left Config Server directly internet-exposed. In internal environments, any foothold on the network is sufficient. No authentication prompt is present.
#2 One crafted web request. The attacker sends a GET request to the Config Server URL with a manipulated path variable. The variable contains a traversal sequence that tells the server to go up and outside the intended directory. The server processes it without objecting.
#3 The server does not check. The three unprotected path variables name, label, and path reach the file repository with no validation at the controller layer. The prior fix only covered the profile. Everything else passes straight through. If you are running a custom repository backend, there is no fallback check either. The file is returned.
#4 Controller passes. Repository receives. File returned. The controller lets the request through. In a default installation, the built-in GenericResourceRepository has its own isInvalidPath() check that catches the traversal before a file is read. But organisations running custom ResourceRepository implementations of a documented and common pattern have no such check. The request reaches the custom repository, the file is located and returned, with HTTP 200. No errors. No alert.
Config Server is not one application. It is the master keyring for the entire service mesh. A single file read on a Config Server host typically yields enough material to pivot into every downstream system. The attacker does not need to chain additional exploits. The credentials are already there, in plaintext, in the config files.
#1 An attacker identifies your Config Server endpoint either through internet scanning (cloud deployment) or from a foothold inside your network (internal deployment). No login page. No authentication. The endpoint accepts requests.
#2 A crafted GET request is sent. Within seconds, the server returns a configuration file. That file contains your database connection string. Another request returns your cloud provider API key. A third returns your JWT signing secret.
#3 The attacker now has the database password. Every record your application touches is accessible. Customer names, emails, financial transactions, national IDs, healthcare records whatever your databases hold. The breach has already happened at this point. The attacker has not touched the database directly yet, but the credential to do so is in their hands.
#4 The cloud provider key is used to access object storage. Backups, documents, logs, archived data all of it is now reachable. The attacker can read, copy, or delete without triggering application-layer alerts.
#5 The JWT signing key is used to forge authentication tokens. The attacker can now impersonate any user in the system including administrators without knowing a single password and without triggering any failed-login alerts. From the application’s perspective, every forged session looks legitimate.
Depending on where you operate and what data was accessible:
EnvironmentController, ResourceController, and EncryptionController and add normalize(path) before the repository call. All four path variables are now validated. This is a complete fix, not a partial one.Recommendation for Hive Pro exposure management platform customers:
This came out of routine BAS (Breach and Attack Simulation) development work on the HivePro Exposure Management platform. While building a simulation test for CVE-2026-22739, the CVE history of spring-cloud-config-server was the natural first thing to review.
The CVE history told the story clearly: four vulnerabilities, same defect class, fixed one parameter at a time, seven years running. Each fix closed what was reported and left everything else open. The fix for CVE-2026-22739 added a check to the profile parameter in EnvironmentController. That same parameter also flows through ResourceController with no equivalent check.
Focus shifted to the three remaining unprotected path variables on ResourceController name, label, and path and to EncryptionController, which the fix had not touched at all. Traversal payloads were sent through each slot. Three returned HTTP 404 the controller accepted them and passed them to the repository. One returned HTTP 400 the fix working as intended on profile.
The finding was reported to the Spring team via GitHub Security Advisories ( The Spring Cloud maintainers acknowledged it within 14 hours and assigned it for triage. CVE-2026-40982 was published on May 6, 2026, alongside fixes for all five affected branches.
Seven years. Five CVEs. The same module. Every fix was correct but too narrow scoped to what was reported, not what was exposed. That is the pattern this discovery followed, and it is a pattern worth internalising: when you patch a vulnerability, ask what else in the same code path shares the same attack surface.The Spring team responded promptly and fixed the full surface in 5.0.3 and 4.3.3. The patches are available across all branches.
----
