CVE-2025-22232

Spring Cloud Config Server May Not Use Vault Token Sent By Clients

Description

Spring Cloud Config Server may not use Vault token sent by clients using a X-CONFIG-TOKEN header when making requests to Vault. Your application may be affected by this if the following are true: * You have Spring Vault on the classpath of your Spring Cloud Config Server and * You are using the X-CONFIG-TOKEN header to send a Vault token to the Spring Cloud Config Server for the Config Server to use when making requests to Vault and * You are using the default Spring Vault SessionManager implementation LifecycleAwareSessionManager or a SessionManager implementation that persists the Vault token such as SimpleSessionManager. In this case the SessionManager persists the first token it retrieves and will continue to use that token even if client requests to the Spring Cloud Config Server include a X-CONFIG-TOKEN header with a different value. Affected Spring Products and Versions Spring Cloud Config: * 2.2.1.RELEASE - 4.2.1 Mitigation Users of affected versions should upgrade to the corresponding fixed version. Affected version(s)Fix versionAvailability4.2.x4.2.2OSS4.1.x4.1.6OSS4.0.x4.0.10Commercial3.1.x3.1.10Commercial3.0.x4.1.6OSS2.2.x4.1.6OSS NOTE: Spring Cloud Config 3.0.x and 2.2.x are no longer under open source or commercial support. Users of these versions are encouraged to upgrade to a supported version. No other mitigation steps are necessary.

Remediation

Workaround:

  • If you cannot upgrade, then you can either: * Remove Spring Vault from the classpath if it is not needed or * Implement your own SessionManager that does not persist the Vault token and provide a bean using that implementation in a @Configuration class. For example: public class StatelessSessionManager implements SessionManager {   private final ClientAuthentication clientAuthentication;   private final ReentrantLock lock = new ReentrantLock();   public StatelessSessionManager(ClientAuthentication clientAuthentication) {     Assert.notNull(clientAuthentication, "ClientAuthentication must not be null");     this.clientAuthentication = clientAuthentication;   }   public VaultToken getSessionToken() {     this.lock.lock();     try {       return this.clientAuthentication.login();     }     finally {       this.lock.unlock();     }   } } @Configuration public class MySessionManagerConfiguration extends SpringVaultClientConfiguration {   private final VaultEnvironmentProperties vaultProperties;   public MySessionManagerConfiguration(VaultEnvironmentProperties vaultProperties, ConfigTokenProvider configTokenProvider, List authProviders) {     super(vaultProperties, configTokenProvider, authProviders);     this.vaultProperties = vaultProperties;   }   @Bean   @Primary   public SessionManager sessionManager() {     if (vaultProperties.getAuthentication() == null && !StringUtils.hasText(vaultProperties.getToken())) {       return new StatelessSessionManager(clientAuthentication());     }     return super.sessionManager();   } }

Category

5.3
CVSS
Severity: Medium
CVSS 3.1 •
EPSS 0.04%
Affected: Spring Spring Cloud Config
Published at:
Updated at:

References

Frequently Asked Questions

What is the severity of CVE-2025-22232?
CVE-2025-22232 has been scored as a medium severity vulnerability.
How to fix CVE-2025-22232?
As a workaround for remediating CVE-2025-22232: If you cannot upgrade, then you can either: * Remove Spring Vault from the classpath if it is not needed or * Implement your own SessionManager that does not persist the Vault token and provide a bean using that implementation in a @Configuration class. For example: public class StatelessSessionManager implements SessionManager {   private final ClientAuthentication clientAuthentication;   private final ReentrantLock lock = new ReentrantLock();   public StatelessSessionManager(ClientAuthentication clientAuthentication) {     Assert.notNull(clientAuthentication, "ClientAuthentication must not be null");     this.clientAuthentication = clientAuthentication;   }   public VaultToken getSessionToken() {     this.lock.lock();     try {       return this.clientAuthentication.login();     }     finally {       this.lock.unlock();     }   } } @Configuration public class MySessionManagerConfiguration extends SpringVaultClientConfiguration {   private final VaultEnvironmentProperties vaultProperties;   public MySessionManagerConfiguration(VaultEnvironmentProperties vaultProperties, ConfigTokenProvider configTokenProvider, List authProviders) {     super(vaultProperties, configTokenProvider, authProviders);     this.vaultProperties = vaultProperties;   }   @Bean   @Primary   public SessionManager sessionManager() {     if (vaultProperties.getAuthentication() == null && !StringUtils.hasText(vaultProperties.getToken())) {       return new StatelessSessionManager(clientAuthentication());     }     return super.sessionManager();   } }
Is CVE-2025-22232 being actively exploited in the wild?
As for now, there are no information to confirm that CVE-2025-22232 is being actively exploited. According to its EPSS score, there is a ~0% probability that this vulnerability will be exploited by malicious actors in the next 30 days.
What software or system is affected by CVE-2025-22232?
CVE-2025-22232 affects Spring Spring Cloud Config.
This platform uses data from the NIST NVD, MITRE CVE, MITRE CWE, First.org and CISA KEV but is not endorsed or certified by these entities. CVE is a registred trademark of the MITRE Corporation and the authoritative source of CVE content is MITRE's CVE web site. CWE is a registred trademark of the MITRE Corporation and the authoritative source of CWE content is MITRE's CWE web site.
© 2025 Under My Watch. All Rights Reserved.