Why ransomware crews love a backup server twice over
CVE-2022-36537 is a ZK Framework bug that handed attackers ConnectWise R1Soft backup servers. A backup server is the perfect ransomware target for two reasons at once: it can push code to everything it protects, and destroying it removes the one thing that lets a victim refuse to pay.
A backup server is the asset a ransomware crew most wants to own, and for two reasons that compound. First, it has reach: a backup product runs agents on, or holds privileged access to, every system it protects, so controlling it is a ready-made distribution channel into the whole estate. Second, it’s the off switch on your leverage: backups are the thing that lets a victim restore and refuse to pay, so destroying or encrypting them is how attackers make the ransom unavoidable. Compromise the backup server and you get the spread and the extortion in one move. CVE-2022-36537 is the bug that handed attackers exactly that, on ConnectWise R1Soft Server Backup Manager.
What the bug is
CVE-2022-36537 is, at its root, a flaw in the ZK Framework, an open-source Java web framework, specifically its AuUploader servlet (CWE-441). A crafted POST to the /zkau/upload endpoint with a nextURI parameter causes the server to forward the request internally and return the contents of files in the protected WEB-INF directory, an information disclosure. Potix fixed it in ZK 9.6.2 on May 4, 2022, and CISA added it to the Known Exploited Vulnerabilities catalog on February 27, 2023, with the ransomware flag.
On its own, “read a file from WEB-INF” sounds modest. The R1Soft exploitation shows how a disclosure becomes takeover. As Rapid7 documented, attackers used the bug to leak /Configuration/database-drivers.zul and recover a secret ID value, then used that ID to reach an otherwise-protected endpoint and upload a malicious database driver, achieving remote code execution and planting a backdoor. ConnectWise embeds ZK in R1Soft and its Recovery products, so the framework bug became an RCE in the backup software. LockBit 3.0 affiliates were among those exploiting it, and incident responders found hundreds of compromised R1Soft servers.
Two problems stacked
This CVE is worth dwelling on because it stacks two of the patterns this catalog keeps teaching, and the combination is what makes it dangerous.
The first is the framework-dependency problem, the same shape as Log4Shell. The vulnerability wasn’t in ConnectWise’s code; it was in a third-party framework ConnectWise shipped inside its product. Organizations running R1Soft weren’t tracking “are we exposed to a ZK Framework bug,” because most of them didn’t know they were running ZK. Your exposure includes the dependencies your vendors embed, and you usually can’t see them.
The second is the backup-server problem, and it’s the one that turns a serious bug into a worst-case one. R1Soft Server Backup Manager is, by design, a privileged hub with reach into every protected machine. RCE on it is not one compromised server; it’s a position from which to push malicious code to the entire backup footprint, and simultaneously to corrupt the backups themselves. Ransomware operators specifically hunt backup infrastructure precisely because of this dual value, and a pre-authentication path to RCE on a backup manager is close to an ideal find for them.
What to do
- Patch the backup software and its embedded framework. Update R1Soft / ConnectWise Recovery to a version with a fixed ZK Framework (9.6.2 or the relevant hotfix branch), and apply the vendor’s product update. If you run other ZK-based products, check them too.
- Treat backup infrastructure as tier-zero. Backup servers deserve the same protection as domain controllers: tight network segmentation, no internet exposure of the management interface, least-privilege service accounts, and close monitoring. The management console of a backup product should be among the least-reachable things on your network.
- Make your backups resistant to the backup server being owned. Immutable or air-gapped backups, and offline copies, mean that an attacker who compromises the backup manager still can’t destroy your ability to recover. This is the control that preserves your leverage when, not if, an attacker reaches the backup tier. Test restores from those copies regularly.
- Inventory embedded dependencies, including in appliances and vendor products. You can’t manage exposure to a framework bug you don’t know you’re running. Push vendors for transparency on their components, and prioritize a dependency inventory that includes the software you bought, not just the software you wrote.
- Assume compromise on long-exposed R1Soft instances. Public exploitation goes back to late 2022. Hunt for the malicious database driver, unexpected backdoors, the secret-ID leak in logs, and signs that the backup server was used to push to protected hosts.
The reframe is one to take into your architecture review. Ransomware economics turn on whether the victim can restore, which is why the backup server isn’t just another system to defend, it’s the system whose compromise decides whether you have a choice when the ransom note arrives. CVE-2022-36537 got attackers there through a framework dependency nobody was tracking, and the lesson is to defend the backup tier like the crown jewel it is and to keep recovery copies an attacker can’t reach even from inside the backup server. We flag the bugs that land on backup and recovery infrastructure with particular weight, because those are the ones that take away the option to say no.
Sources
Share
Related field notes
-
Compromise one MSP's RMM, ransom a thousand businesses: the Kaseya pattern
Kaseya VSA is remote-monitoring software MSPs use to manage thousands of client machines. That reach is why it keeps getting attacked, and why in 2021 REvil used it to push ransomware to roughly 1,500 downstream businesses in a single weekend.
-
The other half of the ScreenConnect chain just got a 2026 deadline
CVE-2024-1709 got the CVSS 10 and the headlines in February 2024. The path-traversal half that actually lands code execution, CVE-2024-1708, only got its own KEV deadline on April 28, 2026. Two years late, same chain.
-
Ransomware crews keep hitting Veeam for the same two reasons
Four Veeam Backup & Replication CVEs feed the same playbook. Attackers target the backup server because it can destroy your recovery option and because it holds the credentials to everything it backs up. CVE-2024-40711 took Akira and Fog from access to ransomware fast.
One email, every weekday morning.
You're in. Check your inbox.