Attackers started exploiting two bugs in AhsayCBS on October 7 at 23:20 UTC, three days after the CVEs went public, and the version the advisories told you to upgrade to is vulnerable too. Huntress reported the activity on October 8. By that evening it had counted five victim organizations and corrected the record on 10.3.4. There is still no patch.
AhsayCBS is a centralized backup server console from Ahsay, a Hong Kong vendor. Managed service providers run it to manage client backups, storage, user accounts and replication from one place. It runs as a Windows service called cbssvcX64.exe with a Java web front end. If you have ever outsourced backups to a small MSP, there is a fair chance one of these boxes holds a copy of your data.
Two bugs, one chain
The CVEs landed in NVD on October 4. CVE-2026-105133 is an authentication bypass in the checkSysPwd function of the API's ApiStructsAction class. Manipulate the random parameter and it stops checking your password. It scored 5.5 under CVSS 4.0. CVE-2026-105134 is OS command injection in the Replication Receiver's UpdateReceivers.do endpoint, scored 9.3. The receiver is the piece that accepts replicated backup data from another CBS instance, so it listens on the network by design.
Chain the two and an unauthenticated attacker gets a shell as NT AUTHORITY\SYSTEM. Huntress watched the sequence in the wild: bypass the login, register a malicious replication receiver, drop a JSP webshell into the directory the console serves, then run whatever you want as the backup service's account.
Both CVEs came through VulDB rather than the vendor, and the advisories said versions up to 10.3.2 were affected and 10.3.4 fixed it. Public exploit code shipped with the disclosure. Ahsay's own 10.3.4 release notes, dated August 5, list fixes for Microsoft 365 and Proxmox VE backups and say nothing about authentication, the API, or replication. Huntress tested 10.3.4 on October 8 and found it vulnerable. So the fixed version in the CVE record was never confirmed by anyone who could check, and for four days admins who upgraded believed they were done.
That failure should bother you more than the bugs. A CVE record is a claim, and the fixed version field is the claim people act on. When the entry comes from a third party and the vendor never publishes an advisory, nobody has verified it. Treat an unconfirmed fixed version as a rumor.
What the attackers did with it
They mined Monero. That is the good news.
Huntress saw the compromised service download four files from an Alibaba Cloud storage bucket: a PowerShell script named Taskgmr.ps1, a config.json, an XMRig miner renamed edge.exe, and msedge.exe, which is a modified copy of NSSM, the Windows service wrapper. NSSM then installed a service named MicrosoftEdgeUpdateSvc, running as SYSTEM, to keep the miner alive across reboots. The miner connected to a pool at kryptex.network on port 8029.
Taskgmr.ps1 hides the miner from the admin. It polls for Task Manager. When Task Manager opens, it stops the fake Edge service so the miner vanishes from the process list. When Task Manager closes, it starts the service again. At 18:00 local time it kills Task Manager outright, on the theory that the admin has gone home. Huntress thinks the script was written with AI help, based on the comments left in it. In one incident the attacker also pulled down WinRing0x64.sys, a legitimate but vulnerable kernel driver, through certutil.exe, most likely to give the miner direct hardware access for faster hashing.
Field Effect's write-up notes that no credential theft or backup tampering has been observed. That is luck. A SYSTEM shell on a backup console gives you every client's backup set, the configuration for every storage destination, and the ability to delete or encrypt the copies a victim would use to recover. Ransomware crews ran this playbook against Veeam Backup & Replication servers in 2024, when Akira and Fog used CVE-2024-40711 to get in. The first group through this door wanted CPU cycles. The next one will read the room.
Backup servers are the wrong thing to expose
I have run backup infrastructure for a long time, and the rule has not changed. The backup server is the most valuable host in the environment and the one you can least afford to expose. It holds a copy of everything, and it is the thing you need working on the worst day. A console with a web login, a replication listener and a vendor that has not acknowledged the bug is a bad candidate for a public IP.
Replication is where this gets uncomfortable, because the receiver exists to accept connections from another site. Vendors make it reachable so that replication works out of the box, and MSPs leave it that way because a VPN between two data centers is one more thing to maintain. The fix is boring. Put the receiver behind WireGuard or an IPsec tunnel and bind it to the tunnel interface. Put the management console behind the same tunnel or an allowlist of office IPs. If the vendor's design makes that hard, that is information about the vendor.
Borg, the tool I maintain a server for, takes the opposite approach. Clients reach the repository over SSH and nothing else, and the repository can run in append-only mode so a compromised client cannot delete history. That design has its own costs, and it is not for everyone. But there is no web login to bypass, and no API endpoint to inject commands into. Fewer surfaces, fewer CVEs.
What to do today
If you run AhsayCBS, Huntress's advice is the only advice until Ahsay ships something:
- Inventory every CBS instance, including DR, test and secondary replication targets. The receiver on the backup copy is as exposed as the primary.
- Restrict the management interface and the replication receiver to trusted source IPs or a VPN. Do this before anything else.
- Hunt for compromise. Look for unexpected child processes of cbssvcX64.exe, new JSP files in the application directory, a service named MicrosoftEdgeUpdateSvc, and outbound connections on port 8029. Huntress published four Sigma rules and a full indicator list.
- If you find anything, rebuild the host from trusted install media. A webshell is rarely the only backdoor, and the attacker had SYSTEM.
Then check whether the storage credentials for your clients' destinations were readable from that box, and rotate them if they were.
Ahsay had not responded to BleepingComputer by October 9, two days after exploitation started and five after the CVEs went public. Huntress says it shared its research with the company. Silence from a backup vendor during active exploitation of its product is a vendor selection data point, and I would weigh it heavier than any feature on the comparison sheet.
My guess for the next two weeks: Ahsay ships 10.3.5 with a release note one line long, CISA adds both CVEs to the KEV catalog, and at least one of the five victims turns out to have had a ransomware affiliate sitting behind the miner the whole time.
