CVE-2026-22769: A Hard-Coded Tomcat Password Gave UNC6201 Root on Dell RecoverPoint for Two Years

On February 17, 2026, Dell, Mandiant, and CISA simultaneously disclosed something the security community had quietly suspected for years: backup appliances are absolutely treated as production by attackers, and the vendors shipping them sometimes ship the appliance with the same hard-coded administrative credential burned into every customer's image. The CVE is CVE-2026-22769. The CVSS is 10.0. The product is Dell RecoverPoint for Virtual Machines (RP4VMs). The exploitation cluster is what Mandiant tracks as UNC6201, a suspected China-nexus actor that had been quietly using this bug as a zero-day since at least mid-2024. CISA gave federal agencies a 3-day patching deadline — unusually aggressive for a non-Emergency-Directive KEV entry.

This post walks through what the bug is (it is shockingly simple), the BRICKSTORM-to-GRIMBOLT malware evolution UNC6201 used across the campaign, why this is a hypervisor-tier compromise rather than just a backup-appliance compromise, and what continuous pentesting would have flagged in the surrounding hygiene even though no testing program would have caught the underlying CVE itself.

The CVE at a glance

The Bug: One Hard-Coded Credential Inside Every Appliance

RP4VMs is the virtual-appliance flavor of Dell's RecoverPoint product line, deployed as a guest VM on VMware ESXi clusters to do continuous data protection and journaling backups for production VMs. To serve its management UI, the appliance ships with an Apache Tomcat 9 instance.

Tomcat configures users in tomcat-users.xml, which on this appliance lives at /home/kos/tomcat9/tomcat-users.xml. That file ships with an admin user assigned the manager-script role — the role that allows programmatic deployment of WAR files via Tomcat Manager's text API. The credential for that user is hard-coded at the OS image level. Every customer's RP4VMs appliance, anywhere in the world, has the same admin password.

The exploitation chain is:

1. Reach the appliance's Tomcat Manager port (TCP/8443 by default on RP4VMs). In Mandiant's observed cases, this was usually inside the customer's vSphere management VLAN, but several intrusions involved a previously-compromised perimeter device that gave the actor that VLAN reach.
2. Authenticate to Tomcat Manager with the hard-coded admin credential.
3. Deploy a malicious WAR with PUT /manager/text/deploy?path=/&update=true.
4. Tomcat on RP4VMs runs as root, so the deployed WAR — a JSP webshell Mandiant tracks as SLAYSTYLE — gets root RCE on the appliance.

From there, UNC6201's persistence pattern is the part that matters most: they modify /home/kos/kbox/src/installation/distribution/convert_hosts.sh so that the backdoor relaunches at boot via rc.local. The backdoor itself is either BRICKSTORM (the C-language ELF backdoor used in 2024) or, since September 2025, GRIMBOLT (a C# backdoor compiled with .NET native AOT and UPX-packed, designed specifically to defeat the BRICKSTORM YARA rules that had circulated in 2024).

Why This Is a Hypervisor Compromise, Not Just an Appliance Compromise

Here is the part that matters strategically: RP4VMs has admin-level access to the underlying ESXi cluster. It has to — that's how it does snapshot-based backups of the production VMs. So a root-level compromise of the RP4VMs appliance is not "you lost a backup appliance." It is "you lost the keys to the hypervisor that runs your production VMs."

UNC6201's observed post-exploitation tradecraft makes the consequences of that very concrete. Mandiant documented:

• "Ghost NIC" interfaces created on production VMs for stealthy lateral pivoting that does not appear in vSphere's normal network inventory views.
• iptables-based Single Packet Authorization (SPA) wrapping inbound C2 — the C2 listener does not respond at all unless the inbound packet matches a specific string, so external scanners see a closed port and the actor's traffic flows through invisibly.
• Selective targeting of mailboxes and source-code repositories on production VMs that the appliance had backup access to — classic espionage tradecraft, not destructive ransomware.

The lesson is structural: any backup or data-protection appliance that has hypervisor-tier access is, from an attacker's perspective, a hypervisor management tool. The CVSS score of the underlying appliance bug undersells the blast radius of compromising it.

BRICKSTORM → GRIMBOLT: The Tooling Evolution

One of the more interesting parts of Mandiant's writeup is the documented evolution of the post-exploitation toolkit during the 20-month exploitation window.

Mid-2024 to September 2025: BRICKSTORM. A C-language ELF backdoor with classic operator features — persistent C2 over HTTPS, ability to drop additional payloads, and the convert_hosts.sh boot-persistence pattern. YARA rules for BRICKSTORM circulated in mid-2025 after Mandiant published initial detection guidance for adjacent UNC clusters.

September 2025 to present: GRIMBOLT. A C# backdoor compiled with .NET native AOT (so it ships as a single statically-linked binary with no .NET runtime dependency on the appliance) and UPX-packed (so the on-disk strings are compressed and the existing BRICKSTORM YARA rules do not match). Same operator, same infrastructure family, deliberately evolved tooling to defeat the published detections.

This evolution is one of the cleaner public examples of how a sophisticated actor adapts when their tooling becomes detectable. It is also the reason Mandiant's February 17 disclosure includes a refreshed YARA ruleset: G_APT_BackdoorToehold_GRIMBOLT_1, G_Hunting_BackdoorToehold_GRIMBOLT_1, and G_APT_BackdoorWebshell_SLAYSTYLE_4.

Attribution: UNC6201, Suspected China-Nexus, Tooling Overlap with Silk Typhoon

Mandiant tracks the operator as UNC6201, a suspected People's Republic of China nexus cluster. Mandiant's writeup explicitly calls out tooling and TTP overlap with UNC5221 — the cluster Microsoft has publicly identified as Silk Typhoon — including the BRICKSTORM lineage, the convert_hosts.sh persistence pattern, and the iptables SPA technique. Mandiant is careful to say that UNC6201 and UNC5221 are not currently merged into the same actor; the overlap could be shared talent, shared tooling, or two clusters operating under the same intelligence-services tasking.

Treat the China-nexus framing as Mandiant's analytic assessment, not a US-government attribution. No State Department or Treasury action has been announced as of late April 2026, and CISA's joint advisories have stayed neutral on attribution.

Mandiant's stated victim count is "less than a dozen" confirmed compromises as of disclosure, but they explicitly note the actual scope is unknown because BRICKSTORM/GRIMBOLT are designed for long-dwell espionage and the 20-month exploitation window gives substantial room for undetected victims. Targeted sectors track the Silk Typhoon profile: legal, technology, SaaS, and managed-service providers. Several of the compromises Mandiant references in passing strongly imply victims were upstream service providers whose RP4VMs compromise gave UNC6201 a path into downstream customer environments.

Detection and Mitigation

Patch first

Upgrade to RP4VMs 6.0.3.1 HF1 or later. Dell's KB is the authoritative source: 000426773.

Workaround if you cannot patch immediately

Two compensating controls, both documented by Dell:

1. Edit /home/kos/tomcat9/tomcat-users.xml to remove the hard-coded admin user, or change its credential to a unique value.
2. Block external reach to the Tomcat Manager port (TCP/8443 by default on RP4VMs) at the network layer.

Public IOCs from Mandiant

Hunt artifacts on every RP4VMs appliance

• Search Tomcat audit log /home/kos/auditlog/fapi_cl_audit_log.log for any PUT /manager/text/deploy entries. Any such entry not part of an approved Dell maintenance event is a high-confidence IOC.
• List unexpected WAR files in /var/lib/tomcat9 and compiled JSP artifacts in /var/cache/tomcat9/Catalina.
• Compare /home/kos/kbox/src/installation/distribution/convert_hosts.sh against a known-good baseline. Any modification is suspicious.
• On the surrounding ESXi cluster: look for unexpected NIC interfaces on production VMs that do not appear in your CMDB or vSphere inventory baseline ("Ghost NICs").
• Check iptables rules on the RP4VMs appliance for entries referencing --name ipt and string-matching on TCP/443 traffic — the SPA-style trigger pattern.

What Continuous Pentesting Would Have Caught

Honest framing first — this CVE is harder for continuous pentesting to claim a win on than the Cisco SD-WAN one. For approximately 20 months between mid-2024 and February 17, 2026, no continuous pentest in the world would have flagged CVE-2026-22769 itself. It was a true zero-day. Nobody outside UNC6201 knew the hard-coded credential was there. Dell shipped exactly what they shipped. We will not pretend continuous testing prevents that.

What continuous pentesting would have flagged is the surrounding architectural hygiene that turned a one-credential bug into a 20-month espionage campaign with hypervisor-tier blast radius.

Architectural finding one: backup and data-protection appliances reachable from anything other than a tightly scoped management VLAN. RP4VMs is not a product that should be reachable from broader corporate networks, and it is certainly not a product that should be reachable from the public internet. A continuous external pentest would have flagged any RP4VMs appliance whose Tomcat Manager port (TCP/8443) was reachable from outside the vSphere management VLAN. That single architectural recommendation, on its own, would have substantially raised the cost of UNC6201's intrusions — the actor would have needed to compromise a specific perimeter device and then pivot, rather than walking up to the appliance directly.

Architectural finding two: trust-boundary review of what the appliance can reach. An external pentest team thinking adversarially about backup infrastructure would have flagged the trust-boundary inversion that RP4VMs creates — the backup appliance has more privileged access to the ESXi cluster than most production services do. That is a known structural issue with the entire data-protection product category, and it is exactly the kind of finding that lands in the "architecture and design" section of an external pentest report. Acting on that finding before the CVE was public would have meant deploying compensating controls (network segmentation, EDR on the ESXi management interface, restricted RP4VMs admin access) that would have made post-exploitation substantially noisier.

Post-disclosure window: the patching gap. After February 17, 2026, continuous pentesting becomes the difference between patching inside the CISA 3-day deadline and being still vulnerable when the post-disclosure scanning wave hits during week two. Given that Mandiant's IOC set is now public, continuous testing also delivers retroactive compromise-assessment value — the convert_hosts.sh modification, the WAR-deployment audit log entries, the GRIMBOLT and SLAYSTYLE artifacts — that an annual pentest would never deliver.

The Bigger Lesson: Backup Infrastructure Is Production

If you operate any modern backup or data-protection appliance — RecoverPoint, Veeam, Cohesity, Rubrik, Commvault, anything that has hypervisor-tier access to your VMs — the takeaway from CVE-2026-22769 is that this product category is now one of the most attractive targets in the enterprise. The architectural reasons are stable and not going away:

• Backup appliances need privileged access to everything they back up — that is the whole point.
• They typically run on custom appliance OSes that EDR cannot fully see.
• They are managed through web UIs that feel like "IT plumbing" rather than "production attack surface" and so are often allowed to remain reachable from broader networks.
• They sit downstream of the trust boundary that protects production, so post-exploitation has lateral access by design.

Treat your backup infrastructure as Tier-0 alongside your domain controllers and your hypervisor management plane. Network-segment it the same way. Monitor it the same way. Pentest it the same way. And patch it on the same emergency cadence you patch the rest of your Tier-0.

Sources

• Mandiant / Google Cloud Threat Intelligence — UNC6201 technical writeup (primary)
• Dell Security Advisory KB 000426773
• The Hacker News — CVE-2026-22769 coverage
• Help Net Security — PRC-nexus framing and timeline
• The Register — CISA's 3-day deadline
• eSentire — IR observations
• SC Media — victim scope and China-linked framing

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.