Dell Warns of RecoverPoint for VMs Zero-Day (Exploited Since Mid-2024)
•February 18, 2026
0
Companies Mentioned
Why It Matters
Compromise of the ESXi host gives attackers full control over virtual workloads, posing a systemic risk to data centers and cloud environments. Immediate patching and network segmentation are essential to prevent a cascade of breaches across the infrastructure.
Key Takeaways
- •CVE‑2026‑22769 grants admin access via hard‑coded credentials.
- •Attackers can gain ESXi root, compromising all VMs.
- •Exploitation active since mid‑2024, reported by Google Threat Intel.
- •Patch requires upgrade to RecoverPoint 6.0.3.1 HF1, with steps.
- •Secure management interface and audit for post‑exploitation artifacts.
Pulse Analysis
The discovery of CVE‑2026‑22769 underscores how deeply embedded credentials can become a silent backdoor in enterprise storage solutions. RecoverPoint for Virtual Machines sits at the intersection of data protection and virtualization, making its management plane a high‑value target. By exploiting hard‑coded admin accounts in the Tomcat interface, threat actors can bypass traditional authentication, upload malicious code, and pivot to the ESXi hypervisor—a move that grants unrestricted access to every virtual machine on the host. This chain of compromise illustrates the broader risk of supply‑chain vulnerabilities in critical infrastructure software.
Google’s Threat Intelligence Group’s early detection of the exploit highlights the importance of external monitoring and information sharing. The fact that attackers have been leveraging the flaw since at least mid‑2024 suggests a long dwell period, during which they could have refined tools and established persistence. Organizations that rely on RecoverPoint without rigorous version control or network segmentation are especially exposed, as the vulnerability can be triggered from any reachable network segment. The active exploitation also serves as a reminder that zero‑day threats can surface in niche enterprise products, demanding vigilant patch management and threat‑intel integration.
Dell’s remediation path—upgrading to RecoverPoint 6.0.3.1 HF1, with prerequisite jumps for legacy versions—adds operational complexity but is non‑negotiable. Administrators should inventory all deployments, verify current build levels, and follow the staged upgrade sequence to avoid service disruption. Beyond patching, hardening the management interface by isolating it from general networks, enforcing multi‑factor authentication, and continuously monitoring upload logs will mitigate future attacks. Finally, a post‑patch forensic review of ESXi hosts is advisable to detect any lingering footholds, reinforcing a defense‑in‑depth posture for virtualized environments.
Dell warns of RecoverPoint for VMs zero-day (exploited since mid-2024)
If you’re running Dell RecoverPoint for Virtual Machines in a VMware setup, this is one of those “drop what you’re doing and check versions” moments. Dell is warning about CVE‑2026‑22769, a maximum‑severity bug (CVSS 10.0) that’s being exploited in the wild. What makes it nasty is that attackers don’t need to guess a password in the usual way—there are embedded credentials baked into the software stack, and they map to an admin account. The weak spot sits in the web‑facing plumbing RecoverPoint uses, including a Tomcat‑based layer. With the hard‑coded credentials, an attacker who can reach the interface can log in as an administrator. From there, the attack path is painfully straightforward: use admin‑level features to upload something malicious and then push the compromise further until you’re sitting at root privileges. In the worst case, the target isn’t just the RecoverPoint appliance itself, but the underlying VMware ESXi host—the hypervisor that runs your virtual machines.
Why does ESXi root matter? Because it’s the keys to the kingdom. ESXi runs on the bare metal, and root access there can translate into control over workloads, data paths, and virtual networking. Attackers can potentially tamper with VM disks, snapshot behavior, network configuration, or use the environment as a pivot point deeper into the infrastructure. Even if an initial compromise looks “limited,” hypervisor‑level access is the kind of foothold threat actors love because it can be quiet and durable.
Google’s security teams (Mandiant / Google Threat Intelligence Group) tipped Dell off, and they report active, limited exploitation that goes back to at least mid‑2024. Long dwell time is a red flag: it suggests adversaries had time to refine tooling and operational playbooks. So the risk isn’t just that the vulnerability exists—it’s that it’s already been used successfully, and organizations that haven’t patched may be behind the curve.
Dell’s fix is an upgrade to RecoverPoint for Virtual Machines 6.0.3.1 HF1. If you’re on older builds, there’s an upgrade staircase: systems on 5.3 SP4 P1 need to move to 6.0 SP3 first, then to the patched release. That’s annoying, but it’s also common with infrastructure tooling where version jumps are restricted. Alongside patching, Dell also provides a recovery script. That’s a hint that simply updating may not be enough if a system was already hit—you’ll want to assume attackers could have left persistence behind.
Practical checklist
-
Inventory your RecoverPoint for Virtual Machines deployments.
-
Confirm current versions.
-
Patch to 6.0.3.1 HF1 (following the required intermediate step if needed).
-
Lock down management access – treat the management plane like you would vCenter: keep it off general networks, restrict it to trusted admin segments, and monitor logs for unusual authentication or upload behavior.
-
If the interface was reachable from untrusted networks, conduct a deeper review of the ESXi hosts and surrounding infrastructure for signs of post‑exploitation activity.
Source: Dell – DSA‑2026‑079
0
Comments
Want to join the conversation?
Loading comments...