CVE-2026-41004

Overview

Spring Cloud Config is a centralized configuration management tool for distributed systems built on the Spring Framework. Its spring-cloud-config-server module ships several environment-repository backends, including a Git backend that can clone configuration from any JGit-supported transport. To support AWS CodeCommit (which requires AWS Signature Version 4 authentication that JGit does not natively understand), Spring Cloud Config Server bundles AwsCodeCommitCredentialProvider: a JGit CredentialsProvider that supplies the AWS access key id as the Username credential and a freshly-signed CodeCommit password as the Password credential whenever JGit asks for them.

A medium-severity vulnerability (CVE-2026-41004) has been identified in that credential provider. Trace-level log statements in the credential-fill loop concatenate the AWS access key and the calculated CodeCommit signature into the log message every time JGit asks for credentials, with no scrubbing or masking. When trace logging is enabled for the credential provider (for example via logging.level.org.springframework.cloud.config=TRACE or a global logging.level.root=TRACE), every clone, fetch, or refresh against an AWS CodeCommit-backed Git repository writes the live AWS access key and the live signed CodeCommit password into the application log in plain text. Any local actor who can read those logs (or anyone downstream of a centralized log aggregator that ingests them) can recover the credentials and replay them against AWS CodeCommit for as long as they remain valid.

Per OWASP: "The first thing is to determine the protection needs of data in transit and at rest. [...] Is any of this data stored in clear text long term, including backups of this data? Is any of this data transmitted in clear text, internally or externally? [...] Is sensitive data logged?" Writing live AWS-signed credentials into a trace log is exactly the "sensitive data logged" failure mode that this OWASP category warns about: secrets are committed to a long-lived, often centralized, often broadly-readable storage tier with no protection beyond filesystem and log-aggregator ACLs.

The CVSS v3.1 base score for this vulnerability is 4.4 (Medium) with vector AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N. The attack vector is Local because the attacker must be able to read the Config Server's log output, attack complexity is Low because the secrets land in the log unconditionally whenever trace logging is on, and the privileges required are High because reading application logs is generally an operator-level capability. The impact is Confidentiality-only and High (live AWS-signed CodeCommit credentials are recoverable from the log); there is no integrity or availability impact because the logging path only writes credentials out, it does not modify state.

This issue affects Spring Cloud Config >=1.3.0 <=3.1.13, >=4.1.0 <=4.1.9, >=4.2.0 <=4.2.6, >=4.3.0 <=4.3.2, and >=5.0.0 <=5.0.2.

‍

Details

Module Info

• Product: Spring Cloud Config
• Affected packages: spring-cloud-config-server
• Affected versions: >=1.3.0 <=3.1.13, >=4.1.0 <=4.1.9, >=4.2.0 <=4.2.6, >=4.3.0 <=4.3.2, >=5.0.0 <=5.0.2
• 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 3.0.x, 3.1.x, 4.1.x, 4.2.x
  • OSS Spring Cloud Config 4.3.3, 5.0.3

Vulnerability Info

The vulnerability is in AwsCodeCommitCredentialProvider in the spring-cloud-config-server module, specifically in the get(URIish, CredentialItem...) method that JGit invokes whenever it needs credentials for an AWS CodeCommit clone or fetch. The provider is wired up automatically by JGitEnvironmentRepository whenever the configured Git URI resolves to an AWS CodeCommit endpoint, so any Spring Cloud Config Server deployment that pulls configuration from CodeCommit implicitly exposes credential-fill operations to this code path.

Pre-fix, each of the three branches in the credential-fill loop set the JGit credential value and then logged that value at TRACE:

for (CredentialItem i : items) {
    if (i instanceof CredentialItem.Username) {
        ((CredentialItem.Username) i).setValue(awsAccessKey);
        this.logger.trace("Returning username " + awsAccessKey);
        continue;
    }
    if (i instanceof CredentialItem.Password) {
        ((CredentialItem.Password) i).setValue(codeCommitPassword.toCharArray());
        this.logger.trace("Returning password " + codeCommitPassword);
        continue;
    }
    if (i instanceof CredentialItem.StringType && i.getPromptText().equals("Password: ")) {
        ((CredentialItem.StringType) i).setValue(codeCommitPassword);
        this.logger.trace("Returning password string " + codeCommitPassword);
        continue;
    }
    throw new UnsupportedCredentialItem(uri, i.getClass().getName() + ":" + i.getPromptText());
}

‍

awsAccessKey is the literal AWS access key id retrieved via AWSCredentialsProvider.getCredentials().getAWSAccessKeyId(). codeCommitPassword is the live signature value computed by calculateCodeCommitPassword(uri, awsSecretKey) and is exactly what JGit hands AWS CodeCommit as the HTTP Basic Auth password to authenticate the operation. Both are short-lived but production-active credentials at the moment they are logged, and either pair (awsAccessKey plus signed password) is sufficient to reproduce the same CodeCommit operation against the real backend.

There are three concrete dangers:

1. The credentials hit the log every time JGit asks for them, which on a Spring Cloud Config Server backed by CodeCommit happens for every clone of the repository's basedir, every git fetch triggered by a refresh() event, and every per-request branch-switch. A long-running Config Server with TRACE logging will accumulate many copies.
2. The credentials are concatenated into the message string with +, not passed as parameters, so any log-scrubbing layer that operates on parameter slots (e.g., a custom Logback Converter keyed off MDC or known argument indices) cannot redact them. Only a regex-based message scrubber would catch the leak, and almost no operator runs one.
3. Centralized log aggregation (CloudWatch Logs, ELK, Splunk, Datadog) widens the blast radius. Secrets logged on a single Config Server are now indexed and searchable across every operator with query access to the log store, even those who would not otherwise be allowed to read the Config Server host's filesystem.

The fix replaces the three secret-bearing trace strings with constant, non-sensitive descriptions and leaves the rest of the method (and the log levels) untouched.

The change is intentionally minimal: the trace messages remain (so operators debugging credential negotiation can still see that each branch fired) but no longer concatenate any value-bearing variable. The control flow is unchanged, and the public API of AwsCodeCommitCredentialProvider is unchanged.

The vulnerable trace statements were introduced together with the AWS CodeCommit credential provider in 2017. They first shipped in Spring Cloud Config 1.3.0 and remained essentially unchanged through to the pre-fix tip, so every Spring Cloud Config 1.3.x and later release prior to the listed fix versions that has CodeCommit configured as a Git backend is affected. The advisory's listed range starting at 3.1.x reflects Spring's currently-supported scope, but older versions all the way down to 1.3.0 are also affected.

‍

Steps To Reproduce

1. Deploy Spring Cloud Config Server 4.3.2 (or any other affected pre-fix version) configured with an AWS CodeCommit Git URI.  Provide AWS credentials to the JVM via the standard chain (AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY, an instance profile, etc.), so that AwsCodeCommitCredentialProvider resolves a real key.

spring:
     cloud:
       config:
         server:
           git:
             uri: https://git-codecommit.us-east-1.amazonaws.com/v1/repos/example-repo

2. Set the credential provider's logger to TRACE in application.yml (Equivalently, logging.level.root: TRACE reproduces the same behavior, as do many ad hoc debug-logging configurations.):

logging:
     level:
       org.springframework.cloud.config.server.support.AwsCodeCommitCredentialProvider: TRACE

3. Trigger any Git operation against the configured backend, for example by starting the Config Server (which clones the repository into basedir) or by issuing a normal Config Client request that causes a git fetch.

4. Inspect the application log. Lines of the following form will appear, each containing the live access key id and the live signed CodeCommit password:

TRACE o.s.c.c.s.s.AwsCodeCommitCredentialProvider - Returning username AKIAIOSFODNN7EXAMPLE
   TRACE o.s.c.c.s.s.AwsCodeCommitCredentialProvider - Returning password 20260506T120000Z...
   TRACE o.s.c.c.s.s.AwsCodeCommitCredentialProvider - Returning password string 20260506T120000Z...

5. After upgrading to a fixed version (4.3.3, 5.0.3, or a HeroDevs NES build), repeat steps 3 and 4. The same TRACE lines now read Setting AWS Access Key in CredentialItem and Setting password in CredentialItem and contain no credential material.

‍

Mitigation

Only recent versions of Spring Cloud Config receive community support and updates. Older versions have no publicly available fixes for this vulnerability.

Users of the affected components should apply one of the following mitigations:

• Upgrade to a currently supported version of Spring Cloud Config. The OSS fix ships in Spring Cloud Config 4.3.3 (4.3.x line) and 5.0.3 (5.0.x line).
• As an interim hardening step on a vulnerable deployment, raise the log level for org.springframework.cloud.config.server.support.AwsCodeCommitCredentialProvider (and any ancestor logger that is currently at TRACE) above TRACE so the credential-bearing messages are not emitted. Operators who shipped TRACE-level logs to a multi-tenant log store before upgrading should treat any AWS access keys present in those logs as compromised and rotate them.
• Leverage a commercial support partner like HeroDevs for post-EOL security support through Never-Ending Support (NES) for Spring Cloud Config.