Attackers Are Looting Backup Servers With a Zero-Day, and the Patched Version Is Still Vulnerable

The software companies buy as insurance is under attack. AhsayCBS, the centralized backup management console that managed service providers and system integrators use to protect entire fleets of client machines, is being actively exploited through two chained zero-day vulnerabilities. Security firm Huntress confirms attackers have been using them to gain unauthenticated remote code execution with full SYSTEM privileges since 23:20 UTC on October 7, and at least five organizations had been targeted by the following day.

That timeline is aggressive, but the detail that should worry defenders most is this: version 10.3.4, the release listed as the fix in the official vulnerability database, does not stop the attack. Huntress tested it directly and confirmed it remains exploitable. Organizations that patched promptly, exactly as instructed, are still exposed.

Two bugs, one master key

The attack chains two flaws, each unremarkable on its own, into something close to a skeleton key. The first, tracked as CVE-2026-105133, is an improper authentication weakness in the product's Replication Receiver component. The component's API accepts a random token in place of valid credentials, which means an attacker can simply invent authentication rather than steal it. It carries a CVSS score of 6.9, moderate, the kind of rating that often lands a bug at the bottom of a patch queue.

The second flaw is where the real damage starts. CVE-2026-105134 is an operating system command injection vulnerability, rated a maximum 10.0 on the CVSS 4.0 scale, reachable with no privileges and no user interaction. Once the authentication bypass opens access to the endpoint at /rps/api/json/UpdateReceivers.do, attackers pass a crafted value through an unsanitized 'random' parameter and the server executes it as a system command. Because the AhsayCBS service runs as NT AUTHORITY/SYSTEM, the highest privilege level on Windows, the injection translates instantly into remote code execution with total control of the machine. No password, no phishing, no second stage needed.

The vulnerabilities were disclosed on October 4, when NIST warned that exploit code was already circulating and that all versions up to 10.3.2 were affected. Three days later, Huntress was watching the attack run on production systems.

The authentication can be invented rather than stolen. The server executes it as SYSTEM. No password, no phishing, no second stage needed.

The fix that doesn't fix

The strangest part of this episode is the patching story. The NVD record for CVE-2026-105134 lists versions 10.3.0 through 10.3.2 as affected and names 10.3.4 as the fixed release. That framing is now demonstrably wrong. Huntress tested 10.3.4 itself and confirmed the exploit chain still works against it, a finding echoed by independent security outlets tracking the campaign.

The disconnect between the official advisory and operational reality creates what analysts are calling a patch black hole. Security teams that follow standard procedure, check the advisory, apply the recommended version, verify the build number, will find themselves defended by nothing. Huntress's blunt recommendation in the meantime: restrict access to the management interface to trusted IP addresses or require VPN access, and hunt for signs of compromise as if the patch did not exist. Because, functionally, it doesn't.

There is no public timeline from Ahsay Systems for a patch that actually resolves the flaws, and the threat actor behind the campaign has not been identified.

What the attackers do once inside

The intrusions Huntress observed follow a practiced playbook, and it reads less like a smash-and-grab than a long-term tenancy. First, the attackers configure a malicious receiver and drop a Java Server Page webshell into the application directory served by the backup console, giving them persistent access through a normal web request. Then comes reconnaissance, mapping what the compromised server can reach.

The monetization layer is a Monero cryptominer, XMRig, disguised as msedge.exe to blend in with Microsoft Edge. Persistence is engineered with unusual care: a Windows service masquerading as Microsoft Edge Update executes a modified copy of the legitimate NSSM service utility, itself renamed to msedge.exe, running with System privileges so the miner restarts after any crash or reboot. One observed attack also deployed WinRing0x64.sys, a legitimate but vulnerable kernel driver, to give the miner kernel-level access to the machine.

The most theatrical touch is counter-surveillance. The attackers planted a PowerShell script, which Huntress describes as AI-assisted, that watches for Task Manager and terminates it if it stays open too long, preventing an administrator from simply noticing an unfamiliar process eating the CPU.

Why backup servers are the worst thing to lose

Backup infrastructure occupies a strange psychological position in most security programs: it is treated as a recovery asset, something you consult after the worst happens. This campaign is a reminder that it is also a concentration of trust. A single AhsayCBS console manages backup policy, storage, and user accounts across entire client fleets. Compromising it at SYSTEM level does not just win one machine; it positions the attacker at the exact place where every recovery plan begins.

There is also a darker possibility that remains unverified. Huntress has confirmed the webshells, the miner, and the persistence tooling, but has not confirmed whether attackers reached into the managed backup repositories themselves. That distinction matters enormously. A cryptominer is an expensive nuisance. Quiet access to backup data, the raw file histories of every client an MSP protects, would be something else entirely, and it is the reason detection work here cannot stop at looking for miners.

What to do right now

Huntress's guidance is unusually direct because the usual playbook, patch and move on, is unavailable. First, take the management interface off the public internet: limit it to trusted IP addresses or put it behind a VPN. The exploit targets the externally accessible web application, so removing that exposure removes the current attack path even without a working patch.

Second, hunt. Look for unauthorized JSP files in the application root directory, Windows services with masked or Edge-like names, msedge.exe processes running on servers that have no browser installed, and the presence of WinRing0x64.sys. Correlate process anomalies with the known exploitation window, starting October 7.

Third, treat the official version guidance with suspicion until a genuinely fixed release is announced and independently verified. This campaign's central lesson is a hard one for a profession built on checklists: sometimes the fix is the most dangerous thing to trust.