Is CVE-2020-5410 (VMware Tanzu Spring Cloud Config Directory Traversal) being exploited in the wild?

Yes. CISA added CVE-2020-5410 to its Known Exploited Vulnerabilities catalogue on 25 March 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Spring, by VMware Tanzu, Cloud Config contains a path traversal vulnerability that allows applications to serve arbitrary configuration files. Any organisation running the affected product should treat remediation as urgent.

What “being exploited in the wild” means for CVE-2020-5410

For a vulnerability like CVE-2020-5410, the practical question is not just whether the issue exists, but whether attackers are actively using it against exposed systems. Once a flaw appears in the CISA Known Exploited Vulnerabilities Catalog, it should be treated as an exploitation problem, not a theoretical weakness.

That changes prioritisation. Organisations should assume internet-facing or broadly reachable instances are at risk first, then confirm whether the product is present anywhere in development, test, or production. For path traversal issues, the exposure is often wider than the obvious server endpoint because configuration content can be sensitive even when the application seems internal.

Spring Cloud Config is also a good example of why configuration services deserve the same urgency as application code: if an attacker can retrieve arbitrary configuration files, they may gain secrets, connection details, or environment data that supports follow-on access. The vulnerability is not only about reading a file, it is about what that file can unlock.

How to confirm exposure and close the gap

Start by identifying every deployment of VMware Tanzu Spring Cloud Config and every application that depends on it for configuration delivery. The vendor advisory and the NIST National Vulnerability Database are the right references for exact affected-version guidance, while CISA KEV tells you why the issue belongs on an urgent remediation track.

If patching or upgrading must wait, reduce reachability immediately. Restrict network access to the config service, remove unnecessary exposure to untrusted clients, and verify that no other route can retrieve configuration content indirectly. For externally reachable services, compensating controls are temporary risk reduction, not a substitute for fixing the vulnerable product.

After remediation, validate that no old paths, proxies, or cached routes still expose the vulnerable behavior. For directory traversal flaws, post-fix verification matters because partial fixes, misrouted traffic, or stale deployments can leave the same attack path available even when the main instance has been updated.

What to check after potential exploitation

Because this flaw can expose configuration files, the response should include compromise assessment, not only patching. Review access logs, request patterns, and any signs that unusual path input was used to reach configuration content. If secrets or connection strings may have been disclosed, treat downstream systems as potentially exposed too.

Where configuration material may have been read, rotate any credentials, tokens, certificates, or service account material that could have been embedded in those files. The safest assumption is that configuration disclosure can become a broader trust compromise, especially when the same secrets are reused across environments.

If there is evidence of retrieval at scale, use the incident to audit whether similar configuration services exist elsewhere in the estate with the same exposure pattern. Directory traversal in a configuration service is often a repeatable class of weakness, not a one-off implementation mistake.

Risk and Threat Considerations

Actively exploited path traversal in a configuration service creates a high-probability exposure path because attackers do not need to “break in” first, they only need to reach the vulnerable endpoint. The downstream impact can include disclosure of secrets, environment details, and connection material that helps them pivot into other systems.

Failure mechanism: The service accepts attacker-controlled path input and resolves it outside the intended configuration boundary, allowing retrieval of arbitrary files or sensitive configuration data.

Impact: Attackers may steal credentials, discover internal architecture, and use exposed configuration values to expand access or compromise connected services.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation requires fast identification and remediation of vulnerable assets.
Recommendation — Prioritise and remediate exposed vulnerable systems using continuous scanning and exception tracking.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The question is about confirming exposure and exploited vulnerability handling.
	SI-2 — Flaw Remediation	CVE-2020-5410 needs urgent fix deployment once exploited status is known.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-exploitation checks depend on reviewing logs for suspicious traversal requests.
Recommendation — Scan for the affected product and validate remediation status across the estate. Apply the vendor fix or mitigation and track closure until the flaw is removed. Review logs for traversal attempts and investigate signs of file access abuse.

Practitioner Guidance

What to prioritise: Treat any public or semi-public Spring Cloud Config deployment as urgent until exposure is ruled out. If the service stores or serves secrets, the remediation priority should be higher than for a normal configuration bug because the blast radius can extend beyond the application itself.

What to verify: Confirm the vulnerable component is absent or remediated, then verify that configuration access is limited to the intended paths and callers. Also verify whether any dependent application inherited secrets or endpoints from the exposed config store.

Decision rule: If the service may have been reachable by untrusted users before remediation, rotate likely-exposed secrets even if you do not yet have proof of abuse. Waiting for certainty can leave the same credentials usable after the flaw is fixed.

Practitioner takeaway: For KEV-listed exploitation, the right unit of response is the vulnerable service plus everything its configuration could reveal, not the CVE alone.