CVE-2026-59284

Overview

Spring Cloud Commons is the shared foundation of the Spring Cloud portfolio. It provides the abstractions that the individual Spring Cloud projects build on, including the service discovery and load balancer contracts, and the refreshable bootstrap application context in the spring-cloud-context module. That context ships actuator support that lets an operator inspect the running Environment and, when explicitly enabled, change it at runtime so that refresh scoped beans pick up new configuration without a restart.

A Resource Injection vulnerability (CVE-2026-59284) has been identified in the writable environment actuator endpoint of Spring Cloud Commons, which allows attackers who can reach the endpoint to write any property key they choose into the running Environment, overriding configuration that the application and the libraries it depends on read at runtime.

Per OWASP: This attack consists of changing resource identifiers used by an application in order to perform a malicious task. When an application defines a resource type or location based on user input, such as a file name or port number, this data can be manipulated to execute or access different resources.

This issue affects the writable /actuator/env endpoint provided by the spring-cloud-context module of Spring Cloud Commons.

Details

Module Info

• Product: Spring Cloud Commons
• Affected packages: org.springframework.cloud:spring-cloud-context
• Affected versions: >=5.0.0 <=5.0.2, >=4.3.0 <=4.3.3, >=4.0.0 <=4.2.6, <=3.1.10
• GitHub repository: https://github.com/spring-cloud/spring-cloud-commons
• Published packages: https://central.sonatype.com/artifact/org.springframework.cloud/spring-cloud-context
• Package manager: Maven
• Fixed in:
• NES for Spring Cloud Commons: 3.0.9, 3.1.14, 4.1.9, 4.2.7 and 4.3.5
• OSS Spring Cloud Commons 5.0.3

Vulnerability Info

This High-severity vulnerability is found in the org.springframework.cloud:spring-cloud-context package in the writable environment actuator endpoint of Spring Cloud Commons.

When an application sets management.endpoint.env.post.enabled to true, Spring Cloud Commons registers a web extension over the standard Boot environment endpoint that turns POST /actuator/env into a configuration write operation. The property key arrives as the name parameter of the request body and is handed to the environment manager without any inspection:

@EndpointWebExtension(endpoint = WritableEnvironmentEndpoint.class)
public class WritableEnvironmentEndpointWebExtension extends EnvironmentEndpointWebExtension {

	private EnvironmentManager environment;

	public WritableEnvironmentEndpointWebExtension(WritableEnvironmentEndpoint endpoint, EnvironmentManager environment,
			Show showValues, Set<String> roles) {
		super(endpoint, showValues, roles);
		this.environment = environment;
	}

	@WriteOperation
	public Object write(String name, String value) {
		this.environment.setProperty(name, value);
		return Collections.singletonMap(name, value);
	}

}

There is no allow list, deny list, prefix restriction or any other constraint on name, so the caller, rather than the application owner, decides which configuration key is targeted. The sink amplifies that control, because the manager installs its own property source at the front of the Environment and publishes a change event for the key it just wrote:

	public void setProperty(String name, String value) {

		if (!this.environment.getPropertySources().contains(MANAGER_PROPERTY_SOURCE)) {
			synchronized (this.map) {
				if (!this.environment.getPropertySources().contains(MANAGER_PROPERTY_SOURCE)) {
					MapPropertySource source = new MapPropertySource(MANAGER_PROPERTY_SOURCE, this.map);
					this.environment.getPropertySources().addFirst(source);
				}
			}
		}

		if (!value.equals(this.environment.getProperty(name))) {
			this.map.put(name, value);
			publish(new EnvironmentChangeEvent(this.publisher, Collections.singleton(name)));
		}

	}

Because the manager property source is added first, the injected value wins over every other property source, including application properties, profile specific files, environment variables and config server values. The change event then causes refresh scoped beans to re-bind against the mutated Environment, so the write takes effect on live components rather than only at the next startup. An operator who is trusted to adjust a handful of feature flags therefore gains the ability to rewrite unrelated settings such as datasource URLs, credential locations, outbound service endpoints and security switches, and the blast radius extends beyond the endpoint itself to any component that reads configuration from the Environment.

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

Mitigation

Only recent versions of Spring Cloud Commons 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 Commons.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• No finder is named in the upstream advisory for this issue.