Vulnerability Directory | CVE-2026-22739 | Spring

Overview

Spring Cloud Config is a centralized configuration management tool for distributed systems built on the Spring Framework. It provides server-side and client-side support for externalized configuration, allowing applications to retrieve their configuration properties from a central Config Server backed by Git repositories, local filesystems, Vault, or other storage backends.

A medium-severity vulnerability (CVE-2026-22739) has been identified in Spring Cloud Config Server. The profile parameter in HTTP requests to the Config Server was not validated for path traversal sequences or SSRF payloads, even though the name and label parameters already were. When using a native filesystem backend, an attacker can inject directory traversal sequences into the profile parameter to read files outside the configured search directories. When using a Git or SVN backend with URI templates containing {profile} in the host or port, an attacker can redirect the Config Server to make requests to arbitrary hosts.

Per OWASP: A path traversal attack aims to access files and directories that are stored outside the intended root folder. By manipulating variables that reference files with dot-dot-slash sequences and their variations, it may be possible to access arbitrary files and directories stored on the file system.

This issue affects multiple versions of Spring Cloud Config Server.

‍

Details

Module Info

Product: Spring Cloud Config
Affected packages: spring-cloud-config-server
Affected versions: <3.1.13, >=4.1.0 <4.1.9, >=4.2.0 < 4.2.6, >=4.3.0 <4.3.2, >5.0.0 <5.0.2
GitHub repository: https://github.com/spring-cloud/spring-cloud-config
Published packages: https://central.sonatype.com/artifact/org.springframework.cloud/spring-cloud-config-server
Package manager: Maven
Fixed in:
- Spring Cloud Config 5.0.2, 4.3.2 (OSS)
- NES for Spring Cloud Config

Vulnerability Info

This medium-severity vulnerability is found in the spring-cloud-config-server module across all published versions of Spring Cloud Config prior to the fix.

Spring Cloud Config Server exposes HTTP endpoints that serve configuration data to client applications. The key URL patterns include:

GET /{application}/{profile}[/{label}]
GET /{application}-{profile}.properties
GET /{label}/{application}-{profile}.properties
GET /{application}/{profile}[/{label}]/{path}

‍

The profile parameter specifies which configuration profile to load (e.g., dev, prod). The Config Server supports multiple backends including native filesystem, Git, SVN, Vault, and JDBC.

Prior to the fix, the name and label parameters were validated through the normalize() method, which calls PathUtils.isInvalidEncodedLocation() to reject directory traversal sequences such as .. and %2e%2e. However, the profile parameter was passed directly to the backend repository without any validation.

This creates two distinct attack vectors depending on the backend configuration:

Path Traversal (filesystem backend)

In EnvironmentController.getEnvironment(), the profile parameter was used without validation:

public Environment getEnvironment(String name, String profiles, String label,
        boolean includeOrigin) {
    try {
        name = normalize(name);       // validated
        label = normalize(label);     // validated
        // profiles was NOT validated
        Environment environment = this.repository.findOne(name, profiles, label,
                includeOrigin);

‍

The same gap existed in ResourceController.retrieve() and ResourceController.binary(). An attacker could inject .. or URL-encoded equivalents (%2e%2e) into the profile parameter to read files outside the configured search directories.

SSRF (Git/SVN backend)

When using a source control backend, the repository URI can contain template placeholders like {profile}. If {profile} appears in the host or port portion of the URI:

spring.cloud.config.server.git.uri=http://{profile}:8080/config

‍

An attacker who controls the profile parameter could redirect the Config Server to make requests to arbitrary hosts, including internal services or cloud metadata endpoints such as 169.254.169.254.

The fix addresses both vectors across three files:

First, EnvironmentController.java now validates the profile parameter using the same isInvalidEncodedLocation() check already applied to name and label:

name = normalize(name);
label = normalize(label);
if (isInvalidEncodedLocation(profiles)) {
    throw new InvalidEnvironmentRequestException("Invalid request");
}
Environment environment = this.repository.findOne(name, profiles, label, includeOrigin);

‍

Second, ResourceController.java now receives the same validation in both the retrieve() and binary() methods.

Third, AbstractScmAccessor.java now has a new validateNoTemplateInAuthority() method that rejects URI templates containing placeholders in the host or port:

private void validateNoTemplateInAuthority(String urlTemplate) {
    UriComponents components = UriComponentsBuilder.fromUriString(urlTemplate).build();
    components.getPort();  // throws if port is templated
    String host = components.getHost();
    if (host != null && (host.contains("{") || host.contains("}"))) {
        throw new IllegalArgumentException(
                "Template placeholders not allowed in host: " + urlTemplate);
    }
}

‍

Template placeholders in the path portion of the URI are still allowed, as this is a legitimate configuration pattern.

This vulnerability is part of a recurring pattern of incomplete fixes in Spring Cloud Config Server. The profile parameter was never validated for path traversal from the project's inception in v1.0.0.RELEASE (2015). Three prior CVEs addressed path traversal in the same controllers but consistently missed the profile parameter:

CVE-2019-3799 (April 2019, fixed in v2.1.2/v2.0.4/v1.4.6): Added path validation in GenericResourceRepository for the path parameter only.
CVE-2020-5405 (March 2020, fixed in v2.2.2/v2.1.7): Added Environment.normalize() to name and label in both EnvironmentController and ResourceController, but did not apply any normalization to profile.
CVE-2020-5410 (May 2020, fixed in v2.2.3/v2.1.9): Added PathUtils.isInvalidEncodedLocation() checks to a normalize() wrapper for name and label, but again did not apply it to profile.

After the CVE-2020-5405 fix in March 2020, the profile parameter became the sole unvalidated path traversal vector in the Config Server's request handling.

The SSRF vector via {profile} URI template substitution has existed since v1.1.0.RELEASE (September 2015).

‍

Mitigation

Only recent versions of Spring Cloud Config receive community support and updates. Older versions have no publicly available fixes for this vulnerability.

Users of the affected components should apply one of the following mitigations: