What is the CVSS score of CVE-2026-41002?

CVE-2026-41002 has a CVSS 3.1 base score of 7.2 (High). CVSS vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:N. EPSS exploitation probability: 0.0%.

Which versions of Spring Cloud Config Server are affected by CVE-2026-41002?

Spring Cloud Config Server (CVE-2026-41002) contains a race condition in Git repository operations that allows high-privilege local attackers to read or modify configuration data across applications…. A patch is available.

How to fix or mitigate CVE-2026-41002?

Within 24 hours: Inventory all Spring Cloud Config Server deployments and document current versions in use; isolate instances handling sensitive configurations if running on shared infrastructure. Within 7 days: Implement filesystem access controls restricting basedir directory permissions to prevent privilege escalation; review Git repository clone logs for suspicious timing patterns. Within 30 days: Monitor vendor security advisories for patch availability; evaluate migration to alternative configuration management solutions if Spring Cloud Config Server cannot be restricted to single-tenant or dedicated infrastructure.

Spring Cloud Config Server CVE-2026-41002

EUVD-2026-28248 HIGH

Time-of-check Time-of-use (TOCTOU) Race Condition (CWE-367)

2026-05-07 vmware

GHSA-86wq-234q-r6wg

Information Disclosure Java

7.2

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

7.2 HIGH

AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:N

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:N

Attack Vector

Local

Attack Complexity

High

Privileges Required

High

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Patch available

May 07, 2026 - 06:16 EUVD

Analysis Generated

May 07, 2026 - 04:46 vuln.today

CVSS changed

May 07, 2026 - 04:35 NVD

7.4 (HIGH) 7.2 (HIGH)

CVE Published

May 07, 2026 - 03:53 nvd

HIGH 7.2

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

7 maven packages depend on org.springframework.cloud:spring-cloud-config-server (6 direct, 1 indirect)

Ecosystem-wide dependent count for version 3.1.0.

DescriptionCVE.org

The base directory (spring.cloud.config.server.git.basedir) used by the Spring Cloud Config Server to clone Git repositories to is susceptible to time-of-check-time-of-use (TOCTOU) attacks. Spring Cloud Config 3.1.x: affected from 3.1.0 through 3.1.13 (inclusive); upgrade to 3.1.14 or greater (Enterprise Support Only). Spring Cloud Config 4.1.x: affected from 4.1.0 through 4.1.9 (inclusive); upgrade to 4.1.10 or greater (Enterprise Support Only). Spring Cloud Config 4.2.x: affected from 4.2.0 through 4.2.6 (inclusive); upgrade to 4.2.7 or greater (Enterprise Support Only). Spring Cloud Config 4.3.x: affected from 4.3.0 through 4.3.2 (inclusive); upgrade to 4.3.3 or greater. Spring Cloud Config 5.0.x: affected from 5.0.0 through 5.0.2 (inclusive); upgrade to 5.0.3 or greater.

AnalysisAI

Time-of-check-time-of-use (TOCTOU) race condition in Spring Cloud Config Server's Git repository cloning mechanism allows local privileged attackers with high-privilege system access to potentially read or modify configuration data intended for other applications. Exploitation requires timing manipulation of the basedir filesystem path between validation and use, enabling symlink attacks or directory substitution. CVSS 7.2 reflects high attack complexity (AC:H) and privileged local access (AV:L/PR:H) requirements, but scope change (S:C) indicates impact beyond the vulnerable component. EPSS data not available; no public exploit identified at time of analysis.

Technical ContextAI

Spring Cloud Config Server is a centralized configuration management solution for distributed systems, commonly used in microservices architectures to serve application properties from Git repositories. The vulnerability (CWE-367: Time-of-Check Time-of-Use) occurs in the server's Git backend implementation when cloning repositories to the filesystem path specified by spring.cloud.config.server.git.basedir. A TOCTOU race condition exists between when the application validates or checks the basedir path and when it actually uses that path for Git operations. An attacker with high privileges on the local system could exploit the timing window to replace the basedir directory with a symbolic link or substitute directory, redirecting Git clone operations to attacker-controlled locations. This could enable unauthorized access to configuration secrets (database credentials, API keys) or injection of malicious configuration data that would be served to downstream applications consuming the Config Server. Affected versions span Spring Cloud Config 3.1.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, indicating the vulnerability persists across multiple major version branches.

RemediationAI

Upgrade Spring Cloud Config Server to patched versions immediately. For Spring Cloud Config 3.1.x, upgrade to 3.1.14 or later (Enterprise Support Only). For 4.1.x, upgrade to 4.1.10 or later (Enterprise Support Only). For 4.2.x, upgrade to 4.2.7 or later (Enterprise Support Only). For 4.3.x, upgrade to 4.3.3 or later. For 5.0.x, upgrade to 5.0.3 or later. Organizations on 3.1.x, 4.1.x, or 4.2.x branches should note these versions require Enterprise Support subscriptions for patch access and should evaluate migrating to currently-supported major versions. Consult the official Spring Security Advisory at https://spring.io/security/cve-2026-41002 for specific upgrade instructions and dependency management guidance. If immediate patching is not feasible, implement compensating controls: restrict filesystem permissions on the Config Server host to prevent local administrative access by untrusted users, deploy Config Servers on dedicated hardened hosts with minimal user accounts, monitor filesystem operations on the basedir path for suspicious symlink creation or directory manipulation, and implement immutable infrastructure patterns where Config Server containers/VMs are rebuilt rather than modified in place. Note that these mitigations only reduce attack surface and do not eliminate the vulnerability-they may complicate deployment automation and increase operational overhead. No workaround fully resolves the TOCTOU condition; patching is the definitive solution.