CVE-2026-22769 • Dell RecoverPoint • CVSS 10.0 • CISA KEV

Backdoor in Backup: Dell RecoverPoint
Hard-Coded Credentials Exploited for Two Years

CVSS 10.0 Critical RCE Nation-State Actively Exploited CISA KEV
⚠ CISA KEV — Federal Agencies Must Patch by February 21, 2026

CVE-2026-22769 carries a maximum CVSS score of 10.0 and has been added to CISA's Known Exploited Vulnerabilities catalog. Federal agencies had a hard deadline of February 21, 2026 to apply the patch. All organizations running Dell RecoverPoint for Virtual Machines must upgrade to version 6.0.3.1 HF1 or apply Dell's remediation script immediately. The China-linked threat actor UNC6201 has been actively exploiting this for over 18 months.

Overview

CVE-2026-22769 is a maximum-severity (CVSS 10.0) hard-coded credentials vulnerability in Dell EMC RecoverPoint for Virtual Machines (RP4VMs), a widely deployed enterprise backup and disaster recovery appliance. The flaw allows any unauthenticated attacker with network access to the appliance's management interface to authenticate as the built-in admin user and gain full root-level control over the appliance.

The truly alarming aspect of this vulnerability is not the flaw itself — hard-coded credentials are an unfortunately common anti-pattern in enterprise appliances — but the disclosure timeline. Mandiant investigators discovered CVE-2026-22769 in February 2026 while responding to an incident at an undisclosed victim organization. Their investigation revealed that the China-linked intrusion cluster UNC6201 had been silently exploiting this same vulnerability since at least mid-2024 — nearly two years before any vendor patch or public disclosure existed.

The vulnerability allowed UNC6201 to deploy the SLAYSTYLE web shell, establish persistent access via the BRICKSTORM backdoor family, and later evolve their tooling to the more evasive GRIMBOLT malware — all operating from within a trusted enterprise backup infrastructure that most EDR solutions do not monitor.

What Is Dell RecoverPoint for VMs?

Dell RecoverPoint for Virtual Machines (RP4VMs) is an enterprise continuous data protection (CDP) and disaster recovery solution for VMware vSphere environments. It enables organizations to:

  • Continuously replicate virtual machine data to on-premises or cloud recovery sites
  • Achieve near-zero RPO (Recovery Point Objective) for critical VMs
  • Perform point-in-time recovery for ransomware protection and compliance
  • Manage cross-site disaster recovery failover and failback

RP4VMs runs as a virtual appliance within the VMware environment. Because it must have deep integration with the hypervisor, storage fabric, and network to perform its CDP function, it is granted broad privileges within the infrastructure. A compromised RP4VM appliance represents a privileged position with visibility into potentially every VM and dataset in the environment — exactly the kind of infrastructure target that serves espionage objectives.

Technical Details

The Hard-Coded Credentials

The vulnerability stems from a static, hard-coded set of credentials for the Apache Tomcat Manager instance embedded within the RP4VMs virtual appliance. Apache Tomcat Manager is a web application that allows administrators to deploy, undeploy, start, and stop web applications within a Tomcat servlet container. Dell's RP4VMs appliance ships Tomcat with a pre-configured admin account using a password that is identical across every installation of the affected product versions.

Because the Tomcat Manager interface is accessible over the network and the credentials are the same on every device, any attacker who discovers these credentials (trivial once known — through reverse engineering or dark web sources) can authenticate to any unpatched RP4VMs appliance reachable on their target network.

The Full Attack Chain

Once an attacker has the hard-coded Tomcat credentials, the exploitation path to root is entirely automated and requires no additional vulnerabilities:

Attack Chain (Conceptual — Recreated from Mandiant Analysis)
# Step 1: Authenticate to Tomcat Manager using hard-coded admin credentials
curl -u "admin:<hardcoded_password>" http://<RP4VM_IP>:8080/manager/text/list

# Step 2: Deploy SLAYSTYLE web shell via the /manager/text/deploy endpoint
# Tomcat Manager's /deploy endpoint accepts a WAR file (Web Application Archive)
# UNC6201 uploads a malicious WAR containing the SLAYSTYLE JSP web shell
curl -u "admin:<hardcoded_password>" \
    -T slaystyle.war \
    "http://<RP4VM_IP>:8080/manager/text/deploy?path=/slaystyle"

# Step 3: Interact with deployed web shell — Tomcat runs as root on RP4VMs
curl "http://<RP4VM_IP>:8080/slaystyle/shell.jsp?cmd=id"
# Output: uid=0(root) gid=0(root) groups=0(root)

# Step 4: Drop BRICKSTORM / GRIMBOLT backdoor for persistence
# Step 5: Deploy Ghost NICs (temporary vNICs) for lateral movement and traffic masking

The result of this chain is unauthenticated root-level code execution on the RP4VMs appliance, with no prerequisites beyond network reachability to port 8080 (or the configured Tomcat port). The appliance's privileged position within the VMware environment then provides UNC6201 a launchpad for deep network lateral movement.

Threat Actor: UNC6201

UNC6201 is a China-nexus intrusion cluster tracked by Mandiant. The group has been active since at least mid-2024, primarily targeting organizations in North America. UNC6201 demonstrates sophisticated operational security and a clear focus on persistence within enterprise backup and virtualization infrastructure — assets that are infrequently monitored and provide broad access to victim environments.

Malware Arsenal: BRICKSTORM & GRIMBOLT

UNC6201 deployed two primary malware families through RP4VMs compromises:

  • BRICKSTORM: The initial backdoor deployed after SLAYSTYLE web shell installation. BRICKSTORM provides a remote shell capability, enabling UNC6201 to execute arbitrary commands on the appliance and use it as a pivot point to reach internal network segments. BRICKSTORM communicates over encrypted channels to attacker-controlled C2 infrastructure.
  • GRIMBOLT: Deployed beginning in September 2025, GRIMBOLT is the successor/replacement to BRICKSTORM with significantly enhanced evasion capabilities. GRIMBOLT is written in C# and compiled using native AOT (Ahead-Of-Time) compilation, which produces a self-contained native binary with no .NET runtime dependency. This means standard .NET detection signatures are ineffective, and the binary has no managed code metadata that forensic tools typically inspect. GRIMBOLT represents a deliberate retooling effort to counter improved defenses that may have begun detecting BRICKSTORM.

Ghost NICs: Lateral Movement Technique

One of UNC6201's more novel operational security techniques is the use of "Ghost NICs" — temporary virtual network interface cards created programmatically on the VMware host via the compromised RP4VMs appliance. UNC6201 creates these ephemeral virtual NICs to pivot across network segments that would otherwise be inaccessible from the appliance's primary network position, then removes them after use to complicate forensic reconstruction of their lateral movement path.

The group also employs iptables rules on the appliance to selectively monitor and redirect port 443 (HTTPS) traffic, intercepting or masquerading as legitimate encrypted communications to blend C2 traffic with normal enterprise traffic.

⚠ Why Backup Infrastructure Is a Tier-1 Target

Backup and replication infrastructure is a goldmine for attackers for three reasons: (1) It has access to continuous snapshots of every protected VM, meaning attackers can quietly exfiltrate terabytes of data over weeks without touching production systems. (2) Backup appliances are often excluded from EDR and security monitoring ("it's just backup traffic"). (3) Control of backup infrastructure enables ransomware actors to delete recovery points, making ransom demands far more compelling. UNC6201 is exploiting all three angles.

Affected Versions

The following versions of Dell RecoverPoint for Virtual Machines are confirmed vulnerable:

  • RecoverPoint for VMs 5.3 SP2
  • RecoverPoint for VMs 5.3 SP3
  • RecoverPoint for VMs 5.3 SP4 (including SP4 P1)
  • RecoverPoint for VMs 6.0, 6.0 SP1, 6.0 SP2, 6.0 SP3 (and their patch levels)

Not affected: RecoverPoint Classic (different product). The fix is available in RecoverPoint for VMs 6.0.3.1 HF1.

Detection

Given the two-year dwell time, organizations should assume compromise has already occurred on unpatched systems and approach this as an incident response scenario, not a routine patch.

Check for SLAYSTYLE Web Shell Artifacts
# SSH to the RP4VMs appliance (if accessible) and check Tomcat deployments
find /opt/vmware/share/httpsvc/webapps/ -name "*.jsp" -newer /etc/passwd
find /opt/vmware/share/httpsvc/webapps/ -name "slaystyle*"

# Check Tomcat access logs for suspicious /manager/text/deploy calls
grep "manager/text/deploy" /opt/vmware/share/httpsvc/logs/localhost_access_log*

# Look for unexpected WAR deployments or new web application directories
ls -lat /opt/vmware/share/httpsvc/webapps/

# Check for GRIMBOLT / BRICKSTORM artifacts
find /tmp /var/tmp /dev/shm -type f -newer /etc/hosts -executable

# Check for suspicious outbound connections
ss -antp | grep "ESTABLISHED"
netstat -antp | grep -v "127.0.0.1\|::1"
Splunk — Detect Suspicious Tomcat Manager Activity
index=webserver sourcetype=tomcat_access_log
  (uri_path="/manager/text/deploy" OR uri_path="/manager/html/deploy")
| where method="PUT" OR method="POST"
| stats count by src_ip, uri_path, http_user_agent, _time
| where count > 0
| sort - _time

Network-Level Indicators

Look for the following network behaviors associated with UNC6201 post-exploitation:

  • Unexpected outbound HTTPS (port 443) connections from RP4VMs appliance IP addresses to external hosts
  • New virtual network interfaces appearing on VMware ESXi hosts correlating with RP4VMs management activity
  • Unusual iptables rule modifications on Linux-based appliances
  • Tomcat access on port 8080 from internal IPs that should not be managing the appliance

Remediation

🚨 Treat As Active Incident

Given the vulnerability's 18+ month exploitation window, do not simply patch and consider the issue resolved. Conduct a forensic review of the appliance for indicators of compromise before and after patching. A patched appliance may still harbor GRIMBOLT persistence mechanisms.

Immediate Steps:

  1. Isolate the appliance: If you are running a vulnerable version, consider temporarily isolating the RP4VMs management interface from external access while patching. The Tomcat Manager should never be internet-facing; verify firewall rules immediately.
  2. Apply the patch: Upgrade to RecoverPoint for VMs 6.0.3.1 HF1 per Dell Security Advisory DSA-2026-079. For the 5.x line, apply the vendor-provided remediation script referenced in the advisory.
  3. Forensic sweep: Check for SLAYSTYLE artifacts, unexpected Tomcat deployments, unusual cron jobs, new system users, unexpected binaries in /tmp or /dev/shm, and outbound network connections from the appliance.
  4. Review VMware infrastructure: Given RP4VMs' privileged access, investigate whether the appliance was used as a pivot. Review vSphere audit logs for unusual VM snapshots, exports, or configuration changes corresponding to periods of suspected compromise.
  5. Rotate credentials: Rotate any credentials the RP4VMs appliance had access to, including vCenter credentials, storage credentials, and any credentials stored in VM snapshots that could be read by an attacker with CDP-level access.

Zero Trust Perspective

CVE-2026-22769 is a textbook case study in why Zero Trust principles must extend to infrastructure components — not just user-facing applications. The RP4VMs appliance was implicitly trusted as "internal infrastructure" and escaped scrutiny. Several Zero Trust controls would have limited the blast radius:

  • Micro-segment management interfaces: The Tomcat Manager interface on RP4VMs should only be accessible from a dedicated, tightly controlled management VLAN — not from any machine that can reach the backup network. Port 8080 should be firewalled to only the IPs of authorized administrators.
  • No implicit trust for backup infrastructure: Backup appliances should be subject to the same EDR/security monitoring as production workloads. The assumption that "it's just backup traffic" is precisely what UNC6201 exploited.
  • Principle of least privilege for CDP: RP4VMs does not need broad network access beyond the specific storage and replication paths required for CDP. Network policies should enforce this constraint, limiting the appliance's usefulness as a lateral movement pivot even if compromised.
  • Asset inventory and patch management for all appliances: Virtual appliances with embedded web servers (Tomcat, Nginx, Apache) are software and must be in scope for vulnerability management. This CVE sat unpatched in production environments for two years partly because appliance firmware is frequently excluded from standard VM-focused patch management programs.
  • Detect credential stuffing against management interfaces: Monitoring for successful authentication to Tomcat Manager from unexpected sources (or at all, if it should not be actively used) would have flagged this attack.