Attackers Are Exploiting AhsayCBS Flaws to Take Over Backup Servers: Your Recovery Plan Is Now an Attack Surface

Backup servers are supposed to be the boring, trusted box in the corner that saves you on your worst day. This week is a reminder that attackers see them differently. Huntress reports that threat actors are chaining two AhsayCBS flaws to run code on exposed backup management servers, and the vendor’s first patch did not fully close the hole. If you treat AhsayCBS vulnerability backup server security as a quarterly checkbox, now is the time to treat it as an active incident.

What Huntress Saw in the AhsayCBS Attacks

AhsayCBS (Cloud Backup Server) is the management console for Ahsay’s backup software. In its October 8, 2026 writeup, Huntress says it is “primarily used by managed service providers (MSPs) and system integrators” and that it “centralizes control of backup operations.” That makes it a high-value spot: one console, many customers’ backups.

Huntress says NVD disclosed two CVEs on October 4, 2026:

• CVE-2026-105133, which Huntress describes as “a medium-severity flaw” in the checkSysPwd function that “can lead to improper authentication.”
• CVE-2026-105134, described as “a critical-severity vulnerability” in the Replication Receiver component that “can be exploited to achieve unauthenticated remote code execution as NT AUTHORITY/SYSTEM on the host.”

According to Huntress, attackers are chaining them: “First, CVE-2026-105133 is used to bypass authentication. Then CVE-2026-105134 is used to gain code execution.” Huntress says exploitation started on October 7 at 23:20:15 UTC, which is 7:20 PM ET. It adds that “As of October 8, Huntress has seen five organizations targeted via these flaws.”

Here is what Huntress documented after the attackers got in:

• Webshells. “In some incidents we saw threat actors deploy .jsp webshells in the web application directory immediately after exploitation.”
• A disguised cryptominer. “On several endpoints we observed the XMRig miner (edge.exe), renamed to masquerade as a Microsoft Edge process.”
• Persistence. A Windows service named MicrosoftEdgeUpdateSvc, built to look like the real Edge Update service, which ran a modified copy of the NSSM utility with SYSTEM privileges.
• Hiding tricks. A PowerShell script, Taskgmr.ps1, that Huntress says “appears to be an AI-assisted script.” It stopped the miner’s service while Task Manager was open.
• A vulnerable driver. In one incident, attackers downloaded WinRing0x64.sys. Huntress says it gave the miner kernel-level access to the hardware.

Huntress does not name an attacker, and its report does not describe any data theft or tampering with backups. I am keeping that scope. What it documents is SYSTEM-level code execution, webshells and mining. That is bad enough on a box that controls backups.

The Patch Story: Incomplete, Then Corrected

I would not call these flaws unpatched. A fix exists. But the timeline has a twist every operator should know. Ahsay’s own October 10, 2026 security alert says: “our previous patch v10.3.4.0 did not fully address the following security vulnerabilities,” naming both CVEs. It tells partners that “Partners running affected v10 versions should apply the AhsayCBS v10.3.4.45 hotfix” and adds: “After applying the hotfix, please reboot your server.” Ahsay says a partner portal login is required to download it.

Huntress’s own updates track the same correction. On October 8 it said 10.3.4 “is also affected,” noting that “Previous reporting indicated that 10.3.4 was not susceptible.” Its October 12 update says it “independently verified that the AhsayCBS 10.3.4.45 hotfix mitigates the initial entry point of this attack chain.” Huntress also says companies on AhsayCBS v7, v8 and v9 “should apply the 9.15.2.70 hotfix.” Ahsay’s alert only mentions v10, so check your version against both pages.

The lesson there is simple. If you patched to 10.3.4.0 and moved on, you are not done.

AhsayCBS Vulnerability Backup Server Security: What Operators Should Do Now

Huntress recommends restricting management interface access “to trusted IP addresses only or require VPN.” If you find any of its indicators, it says to “carry out a full host re-image from a trusted backup; as attackers have been able to hide secondary backdoors for extended persistence.” My checklist, built on those two sources plus my own judgment:

1. Apply the hotfix and reboot. For v10, that is 10.3.4.45 per Ahsay. Confirm the reboot actually happened.
2. Get the console off the open internet. Allow-list trusted IPs or put it behind a VPN, as Huntress advises.
3. Hunt before you relax. Huntress publishes indicators and four Sigma rules. Look for unexpected child processes from cbssvcX64.exe, .jsp files in the web app directory, a MicrosoftEdgeUpdateSvc service, Edge-named binaries in Temp folders, WinRing0x64.sys, and outbound traffic to mining pools on port 8029.
4. Re-image if you find a hit. Do not just delete the webshell. Huntress’s guidance is a full rebuild from a trusted backup.
5. Review downstream access. If the console has credentials or agents tied to customer environments, check whether any of those were used during the exposure window.

Opinion: Your Recovery Plan Is Now an Attack Surface

This section is my opinion, not a finding from Huntress or Ahsay. In this campaign, the documented payoff was cryptomining. But think about what SYSTEM access to a backup console could mean in a different campaign. Imagine an attacker who quietly changed retention policies or disabled jobs weeks before a ransomware event. You would not find out until you tried to restore. That scenario is hypothetical, but the access needed to attempt it is exactly what these flaws grant.

So I treat backup management the way I treat domain controllers. Keep it off the internet. Give it separate admin credentials with MFA. Monitor it like a crown-jewel system. Test restores from copies the console cannot delete or change. If your recovery plan depends on a box anyone can reach from the internet, the plan is part of your attack surface.