What is CVE-2026-22769?
CVE-2026-22769 is a hard-coded credential vulnerability in Dell RecoverPoint for Virtual Machines (RP4VM). In affected deployments, an attacker who knows the embedded credential can authenticate remotely without prior access and potentially gain unauthorized control of the appliance. Public reporting indicates the issue is tied to RP4VM’s use of Apache Tomcat Manager with default credentials present in a configuration file, enabling abuse of management functionality if reachable.
What is Affected By CVE-2026-22769?
Dell RecoverPoint for Virtual Machines (RP4VM) versions prior to 6.0.3.1 HF1 are affected. Dell’s advisory lists multiple impacted 6.0.x service packs and patch levels, and also warns that 5.3 SP2/SP3/SP4 (and potentially earlier) are impacted, with upgrade guidance provided to reach a supported remediation path. Investigation write-ups associate the weakness with Tomcat Manager configuration (including an admin account) on the appliance, which matters most when management interfaces are exposed to untrusted networks. Dell also indicates RecoverPoint Classic appliances are not impacted (the advisory text references a different CVE ID in that sentence, but the surrounding context is RP4VM).
Affected versions and components commonly referenced in vendor and research disclosures include:
-
RP4VM: All versions earlier than 6.0.3.1 HF1
-
RP4VM 6.0 line: 6.0, 6.0 SP1 / SP1 P1 / SP1 P2, 6.0 SP2 / SP2 P1, 6.0 SP3 / SP3 P1
-
RP4VM 5.3 line: 5.3 SP2, 5.3 SP3, 5.3 SP4 (and “potentially earlier”), with Dell recommending upgrade to 5.3 SP4 P1 or 6.x before applying remediation
-
Management surface implicated in exploitation reports: Apache Tomcat Manager configuration on the appliance
Mitigation and Remediation For CVE-2026-22769
The most reliable remediation is to move to Dell’s fixed build (6.0.3.1 HF1) or apply Dell’s vendor-provided remediation script where supported. Dell provides two main paths: upgrade to 6.0.3.1 HF1, or run a remediation script described in Dell’s security KB (noting it must be re-applied after reimaging or when adding older appliances to a cluster). For older 5.3 branches, Dell recommends upgrading to 5.3 SP4 P1 or a 6.x version first, then applying the same remediation approach. In parallel, Dell advises deploying RP4VM only in trusted, access-controlled internal networks with firewalls and network segmentation, and not on untrusted/public networks.
Recommended actions (prioritize in this order):
-
Upgrade to the fixed version: Upgrade RP4VM to 6.0.3.1 HF1 (Dell’s primary fix).
-
If you can’t upgrade immediately: Apply Dell’s remediation script to each RecoverPoint Appliance (RPA) in the RP4VM system, following Dell KB instructions; re-run it after reimage or deploying older appliances into a cluster.
-
For 5.3 deployments: Upgrade to 5.3 SP4 P1 (or 6.x) first, then apply the upgrade/script remediation path above.
-
Reduce exposure while remediating: Enforce network segmentation, restrict access to management interfaces, and ensure RP4VM is not reachable from untrusted networks.
Impact of Successful Exploitation of CVE-2026-22769
Successful exploitation can enable unauthorized access to the appliance and potentially root-level persistence on the underlying system. Authoritative summaries describe an unauthenticated remote attacker (with knowledge of the embedded credential) gaining unauthorized access, with research reporting that attackers used management access to establish persistent footholds and deploy additional tooling. Because RP4VM typically sits in sensitive backup/replication and VMware-adjacent workflows, compromise can have outsized operational consequences, including using the appliance as a pivot into the broader environment. This vulnerability has also been referenced in government vulnerability tracking feeds as being used in real-world attacks, increasing the urgency for patching and defensive review.
Realistic impacts include:
-
Unauthorized administrative access to RP4VM management services
-
Potential root-level control and persistence on the appliance operating system
-
Deployment of web shells/backdoors or other post-compromise tooling (as described in public incident research)
-
Lateral movement risk into adjacent VMware and internal infrastructure where RP4VM has network reach
Proof of Concept for CVE-2026-22769
A safe “proof” for this issue should focus on exposure and indicators—not attempting authentication or payload deployment. Public research attributes exploitation to abuse of Tomcat Manager on RP4VM when reachable, and highlights audit/log artifacts defenders can review to identify suspicious access patterns (especially around /manager). The defensive examples below help you validate whether the management surface is reachable and whether logs show unexpected manager activity, without sharing or using any credential material. For deeper incident-response context and public research details, see the Google/Mandiant write-up referenced in official feeds and vendor materials.
Defensive validation examples (non-weaponized):
# Replace HOST and PORT as appropriate for your environment.
curl -k -I “https://HOST:PORT/manager/” | head
# Google/Mandiant notes audit logging that can reveal requests to /manager.
sudo grep -n “/manager” /home/kos/auditlog/fapi_cl_audit_log.log | tail -n 50
# 3) Local-only hygiene check: list Tomcat usernames (do NOT print password fields).
# Run only if you have authorized admin access to the appliance.
import xml.etree.ElementTree as ET
path = “/home/kos/tomcat9/tomcat-users.xml”
root = ET.parse(path).getroot()
users = [u.attrib.get(“username”) for u in root.findall(“user”) if u.attrib.get(“username”)]
print(“Tomcat users:”, sorted(set(filter(None, users))))
If any of the following are true, treat it as a high-priority investigation signal:
-
Repeated or unusual requests to
/managerfrom unfamiliar sources/accounts -
Evidence of unexpected web app deployments or changes around Tomcat/RP4VM management services (review alongside vendor remediation steps)