Is CVE-2026-59310 (Broadcom VMware vCenter Path Traversal) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2026-59310 to its Known Exploited Vulnerabilities catalogue on 18 August 2026, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Broadcom VMware vCenter contains a path traversal vulnerability which could allow a threat actor with network access to vCenter to execute arbitrary code.

What makes an exploited vCenter CVE a real-world incident signal?

A KEV listing is stronger than a generic vulnerability alert because it reflects evidence of active exploitation, not just theoretical impact. For vCenter, that matters because the platform often sits at a high-trust point in the virtualisation stack, so compromise can quickly expand into broader infrastructure control. When exploitation is confirmed, you should treat exposure as immediate, not hypothetical.

The practical question is whether the vulnerable vCenter instance is internet reachable, exposed to partner networks, or accessible from other trusted segments that an intruder could already use. A path traversal issue can be especially dangerous when it reaches administrative interfaces or server-side components that handle files, requests, or session-adjacent data. Confirming exposure is the first step before deciding whether the environment is merely vulnerable or already at risk of privilege-bearing compromise.

How should teams respond when patching or mitigation is delayed?

For a KEV-listed flaw, the correct response is to move from normal change planning to emergency containment. That usually means reducing network exposure around vCenter, tightening access paths to the management plane, and applying the vendor’s fix or mitigation as soon as operationally possible. If the platform cannot be patched immediately, the environment should be treated as under active threat until the exposure is removed.

Because this class of issue can enable arbitrary code execution, delay creates an adversary window rather than a passive backlog item. In practice, that means prioritising the affected management system ahead of less critical maintenance, even if patching requires a short outage or compensating control. The vendor advisory and the CISA Known Exploited Vulnerabilities Catalog remain the authoritative sources for remediation details, while the NIST National Vulnerability Database and the CVE Program help anchor the record and scope of the issue.

When exposure cannot be removed quickly, current guidance is to isolate the asset as much as possible, restrict administrative reach, and watch for signs that the management plane has already been used as an entry point. In this situation, the most useful additional step is not more scanning alone, but checking whether the platform shows signs of earlier compromise, because an actively exploited management server can become a pivot into the rest of the estate. The Zero-Day and Exploited Vulnerabilities Guide is useful here for KEV-driven triage and post-patch hunting, and the Vulnerability Management Guide covers prioritisation, exceptions, and verification.

What should you verify after a KEV-listed vCenter flaw is announced?

First, verify whether the asset is actually in scope, because “vCenter exists somewhere in the environment” is not the same as “this instance is exposed and reachable.” Then verify whether the management plane has been touched by unusual logins, unexpected process changes, new files, or traffic patterns that do not fit normal administrative use. If the environment includes shared admin access or broad network trust, review those assumptions as part of the verification, not as an afterthought.

Second, decide whether the issue is a patching task or an incident-response task. If there is any evidence that the vulnerability may have been used before remediation, investigation takes priority over simple closure. The distinction matters because a successfully exploited management component can leave behind access paths that survive a patch. Web Application Attacks Guide is a useful reference for understanding path traversal as an access mechanism, while The State of NHI & AI Agent Breach Report 2026 is relevant where compromise of trusted systems leads to stolen credentials, tokens, or service access that outlives the original exploit.

Risk and Threat Considerations

Actively exploited management-plane flaws are high-value targets because they can convert a single network foothold into control over virtual infrastructure. In a vCenter context, that means the issue is not just code execution, but the potential to reach hosts, workloads, snapshots, secrets, and administrative workflows that depend on the platform.

Failure mechanism: A path traversal weakness can let a remote attacker reach unintended files or server-side paths, and in a management product that can become a step toward code execution, credential exposure, or trusted-system abuse.

Impact: The likely consequences are administrative compromise, broader infrastructure access, and possible ransomware-style follow-on activity if the management plane is used as a launch point.

Standards & Framework Alignment

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

MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1211 — Exploitation for Defense Evasion	Path traversal exploitation can be part of attacker entry and post-exploit activity.
Recommendation — Map observed exploitation to T1211 and hunt for anomalous management-plane access.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	KEV-listed vCenter exposure requires urgent flaw remediation and verification.
Recommendation — Prioritise SI-2 remediation for the affected vCenter system and validate closure.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	The question is about exploited vulnerability response and prioritisation.
Recommendation — Use CIS-7 to triage the KEV-listed flaw and verify remediation status.
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	KEV exploitation turns patch prioritisation into a risk decision for critical infrastructure.
Recommendation — Apply GV.RM-01 to elevate exploited management-plane flaws ahead of routine work.
OWASP ASVS	V15 — Secure Coding and Architecture	Path traversal is an application-layer weakness with architectural security implications.
Recommendation — Review server-side path handling under V15 to eliminate traversal conditions.

Practitioner Guidance

What to verify: Confirm whether the affected vCenter instance is reachable from any untrusted or semi-trusted network, then check logs and host indicators for evidence of pre-patch activity. If the platform is management-critical, treat the verification as incident-adjacent rather than routine hygiene.

Decision rule: If the instance is internet exposed or supports high-value workloads, prioritise emergency remediation and containment over normal maintenance sequencing. If patching must wait, reduce access paths immediately and assume the system may already be a pivot point until proven otherwise.

Practitioner takeaway: For a KEV-listed flaw in a management platform, the key judgement is whether you are closing a vulnerability or responding to a likely intrusion path, because that distinction changes both the order of work and the evidence you need before declaring the system safe.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org