CVE-2026-59315

Overview

Spring Cloud Config provides server-side and client-side support for externalized configuration in distributed systems, letting applications load their properties from a central config server backed by Git, SVN, Vault, or the filesystem. Its Monitor module adds a webhook endpoint that source control providers such as GitHub, GitLab, and Bitbucket call when configuration files change, so the server can translate the changed file paths into refresh events and push them to the affected applications over Spring Cloud Bus.

A Denial of Service (DoS) vulnerability (CVE-2026-59315) has been identified in the Spring Cloud Config Monitor webhook endpoint, which allows attackers to exhaust server CPU and flood the message bus by sending a single notification payload whose file path contains a large number of dash characters.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others.

This issue affects the webhook notification handling of Spring Cloud Config.

‍

Details

Module Info

• Product: Spring Cloud Config
• Affected packages: org.springframework.cloud:spring-cloud-config-monitor
• 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-monitor
• Package manager: Maven
• Fixed in:
  
  • NES for Spring Cloud Config: nes-v3.0.12, nes-v3.1.17, nes-v4.1.11, nes-v4.2.8, and nes-v4.3.5
  • OSS Spring Cloud Config 5.0.5

Vulnerability Info

This Medium-severity vulnerability is found in the org.springframework.cloud:spring-cloud-config-monitor package in the webhook notification handling of Spring Cloud Config.

The Monitor module exposes a /monitor endpoint that accepts a source control webhook payload, extracts the list of changed file paths from it, and derives a set of candidate service names from each path. Because a Spring application name may itself contain dashes, the endpoint cannot tell where the application name ends and the profile begins, so it walks the path from right to left and treats every dash-separated prefix as a separate candidate service name. The loop that performs this walk has no upper bound:

private Set<String> guessServiceName(String path) {
	Set<String> services = new LinkedHashSet<>();
	if (path != null) {
		String stem = StringUtils.stripFilenameExtension(StringUtils.getFilename(StringUtils.cleanPath(path)));
		// TODO: correlate with service registry
		String name = stem + "-";
		int index;
		// support application name with dashes
		while ((index = name.lastIndexOf("-")) >= 0) {
			name = name.substring(0, index);
			if ("application".equals(name)) {
				services.add("*");
			}
			else {
				services.add(name);
			}
		}
	}
	return services;
}

The attacker fully controls path, since it is read straight out of the notification body. Each iteration allocates a fresh substring of the remaining prefix, so a path carrying N dashes performs N iterations over strings that average half the input length, giving quadratic work in the size of a single request. Worse, every candidate name the loop accumulates is returned to the caller and published as a distinct RefreshRemoteApplicationEvent on Spring Cloud Bus, so one small POST is amplified into one refresh broadcast per dash. A payload with a few thousand dashes therefore costs the config server both CPU and a burst of bus traffic, and every client application listening on that bus is told to reload its configuration repeatedly. Because the endpoint is designed to be called by external source control providers, deployments commonly leave it reachable without authentication, and the request needs no privileges or user interaction.

‍

Steps to Reproduce

1. Start a Spring Cloud Config Server with spring-cloud-config-monitor on the classpath so the /monitor endpoint is registered.

2. Send a single form-encoded notification whose path contains a long run of dashes:

curl -X POST http://localhost:8888/monitor \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode "path=$(python3 -c 'print("a-"*5000 + "app.properties")')"

3. Observe that the response body contains one candidate service name per dash rather than the one or two names a legitimate webhook produces, and that the server logs a refresh event for each of them.

4. Repeat the request to hold the config server busy and to keep every bus-connected client refreshing its configuration.

‍

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 network access to the /monitor endpoint so that only trusted source control providers can reach it.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

‍

Credits

• Jihun Kim (finder)