CVE-2026-47894

Overview

Spring Cloud Config is the Spring Cloud project that provides externalized configuration for distributed systems. Its server component, Spring Cloud Config Server, exposes application configuration over HTTP under paths shaped as {application}/{profile}/{label}, backing those requests with a pluggable environment repository. The native environment repository is the file system backed variant, which resolves each request against a configurable set of search locations rather than against a source control repository.

An Information Exposure vulnerability (CVE-2026-47894) has been identified in the native environment repository of Spring Cloud Config Server, which allows authenticated callers to read configuration files that live outside the configured repository path by placing wildcard characters in the application name or label segment of a request.

Per OWASP: Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.

This issue affects the native environment repository request handling of Spring Cloud Config.

Details

Module Info

• Product: Spring Cloud Config
• Affected packages: org.springframework.cloud:spring-cloud-config-server
• Affected versions: >=5.0.0 <=5.0.4, >=4.3.0 <=4.3.4, >=4.0.0 <=4.2.8, <=3.1.14
• 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:
• NES for Spring Cloud Config: patched builds for the 3.0.x, 3.1.x, 4.1.x, 4.2.x, and 4.3.x lines
• OSS Spring Cloud Config 5.0.5

Vulnerability Info

This Medium-severity vulnerability is found in the org.springframework.cloud:spring-cloud-config-server package in the native environment repository of Spring Cloud Config.

When the native profile is active, the server builds its search locations by substituting the application name, profile and label taken straight from the request path into the configured location templates. The substituted values are never checked for pattern characters, so a caller controls part of the location string that the configuration loader later resolves:

// NativeEnvironmentRepository.getLocations(String application, String profile, String label)
String value = location;
if (application != null) {
    value = value.replace("{application}", app);
}
if (prof != null) {
    value = value.replace("{profile}", prof);
}
if (label != null) {
    value = value.replace("{label}", label);
}
if (!value.endsWith("/")) {
    value = value + "/";
}
if (isDirectory(value)) {
    output.add(value);
}

The only gate in front of that substitution is the shared path check the controllers call on each incoming segment. That check rejects parent directory sequences and fragment characters, but it says nothing about the wildcard characters the configuration loader treats as a directory search:

// PathUtils.isInvalidLocation(String location)
private static boolean isInvalidLocation(String location) {
    boolean isInvalid = location.contains("..");

    if (isInvalid && logger.isWarnEnabled()) {
        logger.warn("Location contains \"..\"");
    }
    if (!isInvalid) {
        isInvalid = location.contains("#");
        if (isInvalid && logger.isWarnEnabled()) {
            logger.warn("Location contains \"#\"");
        }
    }

    return isInvalid;
}

// EnvironmentController.normalize(String part)
private String normalize(String part) {
    if (PathUtils.isInvalidEncodedLocation(part)) {
        throw new InvalidEnvironmentRequestException("Invalid request");
    }
    return Environment.normalize(part);
}

Because an asterisk or a question mark passes that check, a request such as one whose application name is an asterisk turns a configured location like file:./config/{application}/ into a wildcard directory search. The loader then expands the pattern across sibling directories, and the resulting property sources are returned to the caller, exposing configuration belonging to other applications and labels outside the repository path the operator configured. The same segments reach the resource and encryption endpoints, so the widened search path is not limited to the environment endpoint. The directory heuristic that filters resolved locations is a string test only, so a location containing a wildcard is retained rather than discarded.

This vulnerability was introduced in 2015 with Spring Cloud Config 1.0.1.RELEASE.

Mitigation

Only recent versions of Spring Cloud Config receive community support. Older lines are End-of-Life and will not receive public updates to address this issue.

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

• Upgrade to a currently supported version of Spring Cloud Config.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Nguyen Van Hiep from MBBank (finder)