CVE-2026-47837

Overview

Spring Cloud Config provides server-side and client-side support for externalized configuration in a distributed system. Spring Cloud Config Server serves configuration held in a backing SCM repository, most often Git, over HTTP so that applications can fetch their properties at startup and refresh them at runtime. The optional monitor module adds a /monitor endpoint that accepts push notifications, or webhooks, from the SCM provider and turns them into refresh events that are broadcast to every connected client over Spring Cloud Bus.

An Authorization Bypass vulnerability (CVE-2026-47837) has been identified in the monitor module of Spring Cloud Config Server, which allows attackers to post forged webhook notifications to the /monitor endpoint and cause the server to broadcast configuration refresh events across the bus without ever proving they are the SCM provider.

Per OWASP: Access control, sometimes called authorization, is how a web application grants access to content and functions to some users and not others. These checks are performed after authentication, and govern what 'authorized' users are allowed to do.

This issue affects the webhook monitor endpoint of Spring Cloud Config.

Details

Module Info

• Product: Spring Cloud Config
• Affected packages: org.springframework.cloud:spring-cloud-config-monitor, 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-monitor, 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-monitor package in the webhook monitor endpoint of Spring Cloud Config.

Every SCM provider that Spring Cloud Config Server supports signs its webhook deliveries, typically with an HMAC over the request body keyed by a shared secret and carried in a provider-specific header such as X-Hub-Signature-256. The monitor module never looked at those headers. PropertyPathEndpoint mapped a plain POST handler onto the monitor path and went straight from the request body to publishing bus events:

@RestController
@RequestMapping(path = "${spring.cloud.config.monitor.endpoint.path:}/monitor")
public class PropertyPathEndpoint implements ApplicationEventPublisherAware {

        @PostMapping
        public Set<String> notifyByPath(@RequestHeader HttpHeaders headers, @RequestBody Map<String, Object> request) {
                PropertyPathNotification notification = this.extractor.extract(headers, request);
                if (notification != null) {

                        Set<String> services = new LinkedHashSet<>();

                        for (String path : notification.getPaths()) {
                                services.addAll(guessServiceName(path));
                        }
                        if (this.applicationEventPublisher != null) {
                                for (String service : services) {
                                        log.info("Refresh for: " + service);
                                        this.applicationEventPublisher
                                                .publishEvent(new RefreshRemoteApplicationEvent(this, this.busId, service));
                                }
                                return services;
                        }

                }
                return Collections.emptySet();
        }

The auto-configuration that stands the endpoint up registered only the per-provider payload extractors, which parse the changed file paths out of the JSON body. No request validator and no servlet filter existed anywhere in the module, so nothing sat between an inbound POST and the endpoint:

@Configuration(proxyBeanMethods = false)
@ConditionalOnWebApplication
@Import(FileMonitorConfiguration.class)
public class EnvironmentMonitorAutoConfiguration {

        @Configuration(proxyBeanMethods = false)
        protected static class PropertyPathNotificationExtractorConfiguration {

                @Bean
                @ConditionalOnProperty(value = "spring.cloud.config.server.monitor.github.enabled", havingValue = "true",
                                matchIfMissing = true)
                public GithubPropertyPathNotificationExtractor githubPropertyPathNotificationExtractor() {
                        return new GithubPropertyPathNotificationExtractor();
                }

The attacker-controlled input is the whole HTTP request: the header that selects an extractor and the JSON body that names the changed paths. Because extract treats a well-formed payload as authentic, any party able to reach the endpoint can synthesize a notification, have guessServiceName expand a path such as application.yml into the wildcard destination, and make the server publish a RefreshRemoteApplicationEvent to every application bound to the bus. Repeating that request forces repeated, fan-out configuration reloads across the whole estate, which is why the impact is scored against availability rather than confidentiality or integrity. The endpoint is also not part of the Actuator surface, so operators who secured Actuator paths did not implicitly cover it.

This vulnerability was introduced in 2016 with Spring Cloud Config 1.1.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 network access to the monitor endpoint so that it is reachable only from the SCM provider, and disable the monitor module where push notifications are not used.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Sharlong Wen (finder)