Yes. CISA added CVE-2024-37079 to its Known Exploited Vulnerabilities catalogue on 23 January 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Broadcom VMware vCenter Server contains an out-of-bounds write vulnerability in the implementation of the DCERPC protocol. Any organisation running the affected product should treat remediation as urgent.
What this means for vCenter exposure and exploitation confirmation
The practical question is not whether the product has a flaw in the abstract, but whether your environment still exposes the vulnerable vCenter Server path and whether evidence of abuse already exists. For actively exploited issues, the first step is to confirm inventory, ownership, and internet or lateral reachability, then compare the installed build and deployed role against the vendor advisory and the CISA KEV catalogue.
If the appliance is internet reachable, exposed to untrusted networks, or used as a management plane for other infrastructure, treat the exposure as high priority. The combination of management-plane privilege and a memory corruption flaw means a successful exploit can move quickly from application crash to deeper administrative impact, so triage should assume the worst until proven otherwise.
For the vendor and catalogue records, use the CVE Program and the CISA Known Exploited Vulnerabilities Catalog to anchor your validation, then map the entry back to your own asset list and maintenance window planning.
Why an out-of-bounds write in vCenter changes the response
An out-of-bounds write is not just a generic software weakness. In a control plane product, it raises the possibility of process corruption, service disruption, and potentially attacker-controlled execution paths depending on the surrounding memory layout and hardening. That is why exploited memory-safety flaws in infrastructure software are usually handled as urgent remediation items rather than routine backlog work.
For practitioners, the key issue is blast radius. vCenter often sits at the centre of authentication, inventory, orchestration, and privileged administrative operations, so compromise can expose far more than the application itself. If attackers can reach the management interface, they may be able to use the product as a stepping stone into adjacent systems, especially where administrators reuse access paths or broad management privileges.
The broader pattern of in-the-wild exploitation is why the Zero-Day and Exploited Vulnerabilities Guide is relevant here, alongside the Vulnerability Management Guide for KEV-based prioritisation and exception handling.
What to do if patching cannot happen immediately
When patching must wait, the goal is to reduce reachable surface area without pretending the risk is gone. Restrict access to the management interface, segment the vCenter host from broad user and partner networks, and remove any unnecessary exposure through VPNs, jump hosts, or administrative tooling that fans out trusted access.
Then verify whether compensating controls are real, not theoretical. A login banner, perimeter rule, or “internal only” assumption is not a mitigation if untrusted segments, contractor networks, or administrative subnets can still reach the service. If you cannot reduce exposure quickly, move the issue into an emergency change path rather than treating it like a standard maintenance ticket.
Where prioritisation is needed, the FIRST EPSS resource can help you weigh exploitation likelihood alongside KEV status, while the NIST Cybersecurity Framework 2.0 provides a useful structure for governance, detection, response, and recovery decisions around an urgent vulnerability.
Risk and Threat Considerations
Actively exploited management-plane flaws matter because they compress attacker effort: one reachable weakness can yield disproportionate control over infrastructure, monitoring, and downstream workloads. For vCenter, that creates a high-value target for disruption, persistence, and pivoting even when the initial vulnerability is “just” a write condition.
Failure mechanism: If the vulnerable DCERPC path is reachable, a crafted request can trigger memory corruption in a privileged service, which may lead to denial of service or deeper compromise depending on the surrounding controls and exploit reliability.
Impact: The likely consequences include loss of administrative control, service interruption, and broader infrastructure exposure because the management plane often has trusted visibility and authority across the virtual environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 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 urgent vuln prioritisation and remediation tracking. |
| Recommendation — Prioritise KEV-listed exposures and track remediation to closure. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | KEV exploitation changes risk prioritisation and exception handling for critical assets. |
| ID.RA-01 — Asset Vulnerability Identification and Assessment | Exposure confirmation depends on identifying the affected asset and verifying vulnerability status. | |
| Recommendation — Escalate exploited vulnerabilities into the risk process and set response priority. Verify asset exposure and confirm vulnerability status before relying on compensating controls. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | This case requires continuous identification and tracking of exploitable flaws. |
| SI-2 — Flaw Remediation | CVE exploitation makes timely remediation the core control response. | |
| Recommendation — Scan for the vulnerable service and track remediation until exposure is removed. Apply vendor remediation promptly and document exception handling when patching waits. | ||
Practitioner Guidance
What to prioritise: Treat KEV-listed exploitation as a response workflow, not a standard vulnerability item. Confirm whether the instance is externally reachable, whether the affected service is enabled, and whether any administrative access paths widen the blast radius.
What to verify: Check for signs of pre-remediation compromise before and after applying vendor guidance, especially unusual service crashes, unexpected administrative sessions, new accounts, or unexplained configuration changes on the management plane.
Decision rule: If the system cannot be patched immediately, reduce exposure first, then escalate the exception for formal risk acceptance only if the business impact is understood and the compensating controls are demonstrably effective.
Practitioner takeaway: For an actively exploited flaw in a control-plane product, prioritisation should follow exploitability and blast radius, not the convenience of the patch window.
Related resources from NHI Mgmt Group
- CVE-2024-37079 (Broadcom VMware vCenter Server Out-of-bounds Write)
- CVE-2023-34048 (VMware vCenter Server Out-of-Bounds Write)
- Is CVE-2025-21043 (Samsung Mobile Devices Out-of-Bounds Write) being exploited in the wild?
- Is CVE-2025-21042 (Samsung Mobile Devices Out-of-Bounds Write) being exploited in the wild?
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.
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