Overview
Spring Cloud Config is a tool that provides server-side support for externalized configuration in a distributed system. It allows microservices to retrieve their configuration properties from a central location, backed by a Git repository, a HashiCorp Vault server, a relational database, or another backend data source—enabling consistent and manageable configuration across environments. By decoupling configuration from application code, it supports dynamic updates, version control, and environment-specific settings, helping teams streamline deployments and maintain flexibility in rapidly evolving systems.
A Authentication Bypass vulnerability (CVE-2025-22232) has been identified in spring-cloud-config-server from Spring Cloud Config, which might use a different token than what is supplied by the user.
Per Common Attack Pattern Enumeration and Classification CAPEC-115: Authentication Bypass is when an attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.
This issue affects multiple versions of Spring Cloud Config’s spring-cloud-config-server package.
Details
Module Info
- Product: Spring Cloud Config
- Affected packages: spring-cloud-config-server
- Affected versions: >=2.2.0 <=2.2.8, >=3.0.0 <=3.0.7, >=3.1.0 <3.1.10, >=4.0.0 <=4.0.5, >=4.1.0 <4.1.6, >=4.2.0 <4.2.1
- 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 v3.1.12
Vulnerability Info
This vulnerability affects applications using Spring Cloud Config Server in conjunction with Spring Vault for secret management. Specifically, it relates to the handling of Vault tokens sent via the X-Config-Token HTTP header. The expectation is that the Config Server would use this header to authenticate each individual request to Vault. However, due to the behavior of certain SessionManager implementations—such as LifecycleAwareSessionManager (the default) and SimpleSessionManager—the server instead persists the first token it receives and reuses it for subsequent Vault requests.
As a result, even if different clients send distinct Vault tokens through the X-Config-Token header, the Config Server may ignore them after the initial token is stored. This breaks token isolation between clients and could lead to scenarios where a client inadvertently gains access to configuration data it should not be authorized to retrieve, depending on Vault policies. The issue stems from token reuse, not from direct token leakage, but the impact can still compromise security boundaries in multi-tenant or fine-grained access control environments.
Steps To Reproduce
- Issue a configuration request to the Spring Cloud Config Server from a client, including a Vault token via the X-Config-Token header (Token A).
- Observe that the server uses Token A to authenticate with Vault.
- Issue a subsequent request from a different client or the same client with a different Vault token (Token B) in the X-Config-Token header.
- Note that the Config Server continues to use Token A when communicating with Vault, ignoring the updated token in the request.
Credit
- Max Brauer
- Mohammad Shamsi
Mitigation
Spring Cloud Config versions below and including 4.0.x are no longer community-supported. The community support version will not receive any updates to address this issue. For more information, see here.
Users of the affected components should apply one of the following mitigations:
- Upgrade affected applications to supported versions of Spring Security
- Leverage a commercial support partner like HeroDevs for post-EOL security support.
Follow the mitigation steps here.
