CVE-2026-47836

Overview

Spring Cloud Config provides server-side and client-side support for externalized configuration in a distributed system. The Config Server exposes application configuration over HTTP and backs that configuration with a version control system or filesystem store, checking the configured repository out into a local working directory on the server host. When the Subversion backend is used, that working directory is derived from the spring.cloud.config.server.svn.basedir property, or from a generated temporary directory when the property is not set.

A Path Traversal vulnerability (CVE-2026-47836) has been identified in the Subversion environment repository of Spring Cloud Config Server, which allows a local attacker able to write to the parent of the configured base directory to substitute a symbolic link for that directory between the working copy check and the Subversion operation, redirecting checkout, update, and shutdown cleanup file operations onto files and directories outside the intended base directory.

Per OWASP: A path traversal attack (also known as directory traversal) aims to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with "dot-dot-slash (../)" sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files.

This issue affects the Subversion (SVN) backend of the Config Server component 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 High-severity vulnerability is found in the org.springframework.cloud:spring-cloud-config-server package in the Subversion environment repository of Spring Cloud Config.

SvnKitEnvironmentRepository decides whether to update an existing working copy or perform a fresh checkout by testing for a .svn entry under the configured working directory, and then hands the same unverified File to SVNKit:

try {
	String version;
	if (new File(getWorkingDirectory(), ".svn").exists()) {
		version = update(svnOperationFactory, label);
	}
	else {
		version = checkout(svnOperationFactory);
	}
	return new Locations(application, profile, label, version, getPaths(application, profile, label));
}
catch (SVNException e) {
	throw new IllegalStateException("Cannot checkout repository", e);
}

private String checkout(SvnOperationFactory svnOperationFactory) throws SVNException {
	logger.debug("Checking out " + getUri() + " to: " + getWorkingDirectory().getAbsolutePath());
	final SvnCheckout checkout = svnOperationFactory.createCheckout();
	checkout.setSource(SvnTarget.fromURL(SVNURL.parseURIEncoded(getUri())));
	checkout.setSingleTarget(SvnTarget.fromFile(getWorkingDirectory()));
	Long id = checkout.run();
	...
}

private String update(SvnOperationFactory svnOperationFactory, String label) throws SVNException {
	logger.debug("Repo already checked out - updating instead.");

	try {
		final SvnUpdate update = svnOperationFactory.createUpdate();
		update.setSingleTarget(SvnTarget.fromFile(getWorkingDirectory()));
		long[] ids = update.run();
		...
	}
	...
}

The existence test and the Subversion operation are two separate filesystem accesses against a path that is resolved again each time, and neither access rejects symbolic links. A local actor with write access to the parent of spring.cloud.config.server.svn.basedir can therefore win the race between the two: the check observes a genuine working copy (or a missing directory), and the path is then replaced with a symbolic link pointing somewhere else before SVNKit dereferences it. Because SVNKit follows the link, repository content is written through the attacker-controlled path and existing files at the target are read, overwritten, or removed under the identity of the Config Server process, which typically runs with different privileges than the attacker. The same pattern applies to the temporary base directory cleanup inherited from AbstractScmAccessor, where the shutdown hook deletes the recorded path without re-checking it:

protected File createBaseDir() {
	try {
		final Path basedir = Files.createTempDirectory("config-repo-");
		Runtime.getRuntime().addShutdownHook(new Thread() {
			@Override
			public void run() {
				try {
					FileSystemUtils.deleteRecursively(basedir);
				}
				catch (IOException e) {
					AbstractScmAccessor.this.logger.warn("Failed to delete temporary directory on exit: " + e);
				}
			}
		});
		return basedir.toFile();
	}
	catch (IOException e) {
		throw new IllegalStateException("Cannot create temp dir", e);
	}
}

A symbolic link planted at that temporary directory turns the shutdown cleanup into a recursive delete of an arbitrary directory tree, extending the impact from the configuration store to any location the server process can write. Exploitation requires local access, high privileges relative to the base directory, and precise timing, which is reflected in the published CVSS v3.1 vector AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:N, but a successful race crosses a security boundary because the file operations execute as the Config Server rather than as the attacker.

This vulnerability was introduced in 2015 with Spring Cloud Config 1.0.0.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.
• Restrict write access to the parent directory of spring.cloud.config.server.svn.basedir (and to the system temporary directory when no base directory is configured) so that no untrusted local account can create entries alongside the Config Server working directory.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Sharlong Wen (finder)