CRITICAL: AhsayCBS Zero-Days Hijack Backup Servers to Mine Monero

Backup servers are supposed to be the thing you reach for when everything else is on fire. This week a crew of opportunistic attackers decided they would rather turn them into space heaters. Huntress has confirmed active exploitation of two chained vulnerabilities in AhsayCBS, the backup server platform that a large number of managed service providers run behind their white-label backup offerings. The attackers are using the chain to get SYSTEM-level code execution without credentials, dropping web shells, and installing an XMRig Monero miner that dresses itself up as Microsoft Edge. The worst part is that the version the CVE records call fixed is not actually fixed, which means every AhsayCBS server reachable from the internet should be treated as exposed right now.

If your first instinct is "it's just a cryptominer, who cares," hold that thought. Anyone who can run arbitrary commands as SYSTEM on the box that holds your customers' backups can do a great deal more than mine Monero, and Huntress already found secondary backdoors tucked away on some of the compromised hosts. Today's miner operator is tomorrow's access broker.

Two bugs, one very bad afternoon

The two flaws were published to the NVD on October 4, 2026 with VulDB acting as the CNA. The first is CVE-2026-105133, an improper authentication weakness in the checkSysPwd function inside com/ahsay/obs/api/ApiStructsAction.java. By manipulating an argument called random, a remote attacker can satisfy the password check without knowing the password. On its own it scores a fairly modest 5.5 under CVSS 4.0 and 7.3 under CVSS 3.1, which is exactly the kind of number that gets a ticket parked in the "next maintenance window" column.

The second is the one that earns the CRITICAL label. CVE-2026-105134 is an OS command injection in the Replication Receiver component, specifically the /rps/api/json/UpdateReceivers.do endpoint, and once again the random argument is the lever. It carries a CVSS 4.0 score of 9.3 and a CVSS 3.1 score of a perfect 10.0, with a vector that reads like a wish list for attackers. It is network reachable, low complexity, needs no privileges and no user interaction, and the impact is high across confidentiality, integrity and availability with a changed scope. The NVD entries also note that exploit details are public, so this was never going to stay quiet for long.

Chained together, the first bug gets the attacker past authentication and the second turns that access into command execution as NT AUTHORITY\SYSTEM through the AhsayCBS service process, cbssvcX64.exe. In practice the attackers used that position to configure a malicious replication receiver and then plant a JSP web shell in the directory served by the CBS web application. In some incidents the web shell landed within moments of the initial exploit, which tells you this is automated and that the operators are not hand crafting each intrusion.

The version confusion problem

Here is where it gets ugly for defenders. The CVE descriptions say AhsayCBS up to 10.3.2 is affected and that upgrading to 10.3.4 resolves the issue. Version 10.3.4 shipped back on August 5, so plenty of administrators looked at those records, saw they were already current, and moved on. Huntress initially reported the same thing. Then, in an update posted on the evening of October 8, Huntress said it had confirmed that 10.3.4 is also vulnerable to both CVE-2026-105133 and CVE-2026-105134, that it had notified Ahsay, and that every AhsayCBS release through 10.3.4 should be considered affected.

That turns this from a "you should have patched in August" story into a genuine zero-day. As of this writing there is no vendor patch that Huntress or the trade press can point to, and Ahsay had not publicly responded to questions about a fix when SecurityWeek and BleepingComputer published their coverage. If someone on your team marked AhsayCBS as remediated because the dashboard says 10.3.4, go un-mark it. CISA had not added either CVE to the Known Exploited Vulnerabilities catalog as of its October 8 release, so do not wait for a KEV entry to tell you this matters either.

What the intrusions look like

Huntress first saw exploitation at 23:20 UTC on October 7, 2026, and had five affected organizations on its books by the following day, with one more incident using the same playbook reported afterward. That is a small number in absolute terms, but Huntress only sees the environments where it has an agent, and the activity started three days after the CVEs went public. The math on how many internet-facing AhsayCBS servers exist versus how many are watched by an EDR vendor is not comforting.

After the initial foothold, the CBS service process spawns curl and certutil to pull tooling into the %TEMP% directory from an Alibaba Cloud object storage bucket. The haul includes a PowerShell script called Taskgmr.ps1, an XMRig binary renamed to edge.exe, a modified copy of the NSSM service manager renamed to msedge.exe, and a config.json that gets tweaked on the fly by PowerShell. In at least one case the attackers also fetched WinRing0x64.sys, the well-known vulnerable kernel driver that miners love because it gives them low-level hardware access to squeeze out more hash rate.

Persistence comes from a new service named MicrosoftEdgeUpdateSvc, which is close enough to the legitimate edgeupdate service that a tired admin scrolling through services.msc will sail right past it. NSSM runs the fake msedge.exe as SYSTEM, restarts the miner if it crashes, and brings it back after reboots. The miner then reports in to xmr.kryptex.network on port 8029.

The Taskgmr.ps1 script is the part that made me laugh, in the grim way you laugh at a security incident. It watches for Task Manager and stops the mining service whenever someone opens it, then starts it again once the window closes, so the CPU graph looks perfectly calm while you are staring at it. It will also kill Task Manager at 18:00 local time, or if it has been left open for more than an hour overnight. The Hacker News noted that the script has the fingerprints of AI-assisted authorship, which is entirely believable. Somebody asked a chatbot to help them hide from the one tool every Windows admin opens first, and it obliged.

Huntress published the attacker infrastructure it observed. The exploitation traffic came from 177.4.12[.]11 and 123.202.208[.]37 in Hong Kong, 38.60.252[.]110 in Vietnam, 107.191.47[.]199 in France, 185.220.236[.]49 in Taiwan, and 104.234.26[.]10 in the United States. Payloads were staged under imagefiles-backup.oss-ap-southeast-7.aliyuncs[.]com, and the mining pool also resolved to 51.195.127[.]124 on the same port. File hashes for the fake msedge.exe, the edge.exe miner and Taskgmr.ps1 are in the Huntress write-up linked below, and you should drop all of it into your SIEM and EDR blocklists today.

What to do before Monday

Since there is no trustworthy patch, the first move is to take the AhsayCBS management interface off the open internet. Restrict it to a short allowlist of trusted IP addresses or put it behind a VPN, which is exactly what Huntress recommends. I know the usual objection is that remote clients need to reach the server for backup jobs, and that is a real constraint, but the web management console and the replication receiver endpoints do not need to be exposed to the entire planet. If your firewall or reverse proxy can block requests to /rps/api/json/UpdateReceivers.do from anything other than your known replication partners, do that as well.

Next, assume you might already be compromised and go hunting. Look for any child process spawned by cbssvcX64.exe or cbssvcX86.exe that is not part of normal startup or maintenance, since web shell commands show up as direct children of the service. Check for a service named MicrosoftEdgeUpdateSvc, for binaries named edge.exe or msedge.exe living in a user %TEMP% folder, for anything Edge-branded launched with a --daemonized flag, and for WinRing0x64.sys sitting outside a legitimate hardware monitoring tool. Review the CBS web application directory for JSP files you did not put there, and check the replication receiver configuration for entries you do not recognize. Outbound connections to port 8029 or to kryptex pool addresses are a strong tell. Huntress has released four Sigma rules in its public threat intel repository under 2026/2026-10/AhsayCBS_XMRig_Miner that cover the unexpected child process, the fake Edge binary, the Task Manager-aware PowerShell logic and the WinRing0 download, and they are worth importing even if you think you are clean.

If you do find signs of compromise, do not just delete the miner and call it a day. Huntress found hidden secondary backdoors on some hosts, so the right answer is to rebuild the server from a known-good image and restore configuration carefully. While you are at it, rotate every credential the backup server stores or touches, including administrator accounts, storage destination keys and any service accounts used for replication. A backup server is a high-trust system by design, and anything it could reach should be treated as potentially exposed until proven otherwise.

Finally, keep a close eye on Ahsay's release notes and support channels for a build that actually closes these holes, and validate it before declaring victory. Given how the 10.3.4 situation played out, I would want independent confirmation from Huntress or another researcher before trusting a vendor "fixed" label on this one.

The MSP angle

AhsayCBS is overwhelmingly an MSP product, so this is your problem first and your clients' problem second. Use it as a reason to sell external attack surface monitoring and managed detection that covers your own backup and RMM infrastructure, and to pitch a backup architecture review that adds immutable or offline copies so a compromised backup server is never the single point of failure.