AhsayCBS Exploitation Makes A Clean Rebuild The Recovery Path

Ahsay has replaced earlier fixes for two AhsayCBS vulnerabilities after active exploitation showed that versions previously described as protected were still exposed. CVE-2026-105133 bypasses authentication in an API check, while CVE-2026-105134 injects operating-system commands through the Replication Receiver component. Huntress observed attackers chaining the flaws from October 7 to obtain unauthenticated code execution as NT AUTHORITY\SYSTEM, install Java Server Page webshells, and deploy a Monero miner. Ahsay now directs version 10 customers to hotfix 10.3.4.45 and version 7, 8, and 9 customers to the 9.15.2.70 path, followed by a reboot.

CISA added both vulnerabilities to its Known Exploited Vulnerabilities catalog on October 14 with an October 17 federal remediation date. Patching closes the published entry path, but it does not establish that an exposed host was clean before the fix. Ahsay says servers showing suspicious root-level folders, unexpected JSP files, unauthorized replication receivers, or unauthorized administrator accounts should be treated as compromised and fully rebuilt. The public record confirms server takeover and cryptomining at five Huntress-observed organizations as of October 8. It does not establish how many AhsayCBS systems were reached overall, whether backup contents were copied, or who operated the campaign.

The current response starts with a correction. Ahsay said on October 9 that AhsayCBS 10.3.4.0, released in August, addressed both vulnerabilities. Huntress reported that the same release remained exploitable. Ahsay then issued hotfix 10.3.4.45 on October 10 and hotfix 9.15.2.70 on October 12, stating that the prior 9.15.2.59 and 10.3.4.0 fixes were incomplete. Administrators should therefore verify the full hotfix number rather than accepting a 10.3.4 label as proof of remediation.

Ahsay's October 13 status update says it began receiving partner reports of unauthorized access on October 9. Huntress had already seen exploitation beginning late on October 7 and counted five organizations by October 8. These statements describe different visibility, not necessarily a contradiction: Huntress records activity in its customer base, while Ahsay records reports reaching the vendor. Neither source publishes a total population of internet-exposed servers or a final victim count.

CISA added both CVEs to the KEV catalog on October 14. The catalog sets October 17 as the remediation date for covered federal systems and marks CVE-2026-105134 for forensic triage. That short window reflects active exploitation and a backup server's privileged position. Other organizations are not bound by the federal date, but the same evidence supports emergency treatment wherever the management service was reachable from untrusted networks.

CVE-2026-105133 affects the checkSysPwd function in AhsayCBS and permits an attacker to substitute a random value where valid authentication should be required. CVE-2026-105134 affects the Replication Receiver endpoint at /rps/api/json/UpdateReceivers.do and permits operating-system command injection. Huntress observed the first flaw used to pass the authentication boundary and the second used to execute commands. The practical condition is the chain, not either score viewed in isolation.

After gaining access, the actor created a malicious replication receiver and wrote a JSP webshell into the directory served by the AhsayCBS application. Huntress traced suspicious child processes directly from cbssvcX64.exe, the service hosting the web application. On Windows, the resulting commands ran as NT AUTHORITY\SYSTEM. That authority is enough to alter the backup controller, install persistence, read locally available secrets, and tamper with evidence.

The published exploitation path targets the externally reachable AhsayCBS web service. Restricting the management interface to trusted addresses or a VPN reduces exposure, but it is a containment measure, not a substitute for the current hotfix. An organization that restricted access only after the campaign began still needs to review earlier reachability, server events, proxy and firewall records, and any administrative sessions that occurred during the exposed period.

Huntress observed reconnaissance, webshell installation, and payload downloads from Alibaba Cloud object storage. The actor placed files in temporary directories, created a service named MicrosoftEdgeUpdateSvc, and used a modified copy of NSSM to keep a renamed XMRig process running with SYSTEM privileges. The naming was intended to resemble Microsoft Edge components. Process name alone is therefore poor evidence of legitimacy; original file names, hashes, paths, parent processes, and service configuration matter.

The campaign also downloaded the legitimate but vulnerable WinRing0x64.sys driver. Huntress assessed that the driver gave the miner low-level hardware access rather than documenting a separate security-tool disabling step in these incidents. Its report includes network indicators, payload hashes, and four Sigma detections for unexpected AhsayCBS child processes, disguised Edge binaries, the Task Manager-aware PowerShell behavior, and command-line retrieval of WinRing0. Those indicators are useful starting points, but absence of a listed value does not clear a host.

The confirmed impact should not be expanded beyond the evidence. Huntress saw five organizations by October 8, and Ahsay later acknowledged partner reports of unauthorized access. Public sources do not identify the actor, prove ransomware deployment, quantify stolen customer information, or confirm that backup archives were copied or destroyed. A SYSTEM-level compromise makes those outcomes possible in some deployments, but responders must establish them through local evidence rather than treating possibility as fact.

AhsayCBS centralizes users, policies, replication, storage destinations, agents, and restoration operations for service providers and system integrators. That makes the server more than an ordinary web application. Its configuration can contain routes to customer environments, storage credentials, encryption settings, notification channels, and operational metadata. The exact material present varies by deployment, so incident scope begins with an inventory of what the compromised instance could read, change, issue, or distribute.

Separate the controller, backup repositories, customer agents, and recovery credentials into distinct evidence questions. Confirm whether repositories accepted sessions from the server, whether replication destinations changed, whether new administrators or receivers appeared, and whether agent packages or update channels were modified. Validate restore points from systems outside the suspected host. Do not assume that an intact backup job report proves the stored data or the controller configuration remained trustworthy.

Service providers also need tenant-aware scoping. Review which customers were attached to each server during the exposure window, which credentials were shared across tenants, and which administrative actions can be traced to a known operator. Notify customers based on confirmed reach and legal duties, while explaining what remains under investigation. A broad warning without boundaries can create panic; a narrow warning that ignores controller authority can leave customers exposed.

For version 10, Ahsay directs partners to install hotfix 10.3.4.45. For versions 7, 8, and 9, it directs operators to move to AhsayCBS 9.15.0.0 and apply hotfix 9.15.2.70. The vendor requires a reboot after the hotfix. Record the running base version and hotfix before and after maintenance, then confirm that the service restarted on the expected build. A package download or completed installer is not deployment proof.

Before changing a plausibly compromised server, preserve volatile and durable evidence according to the incident plan. Collect service state, child processes, network connections, user and receiver lists, web application contents, scheduled tasks, services, relevant registry data, command histories, and external firewall, proxy, authentication, and storage logs. Ahsay's indicator list calls out unexpected root-level folders, random JSP files or directories under %CBS%\webapps, unauthorized RPS receivers, and unauthorized administrator accounts.

If no indicators appear, the conclusion should be proportional to visibility. Document when the interface was exposed, how much logging exists, whether endpoint telemetry covered cbssvc processes, and whether external network records are available. A server with missing logs and public reach cannot be declared clean solely because four named indicators were absent. Patch it, constrain access, increase monitoring, and decide whether uncertainty warrants a precautionary rebuild.

Ahsay recommends a full rebuild when its indicators are present: reinstall Windows or Linux, install the current supported AhsayCBS base, apply the relevant hotfix, and restore a server configuration Auto Save that predates compromise. The vendor advises choosing a configuration from at least one day before suspicious folders or files were created. Treat that as a minimum selection rule. Correlate it with the earliest external evidence and validate the restored configuration before reconnecting repositories or agents.

Rotate credentials and keys according to what the server could access. That can include local and directory administrator credentials, storage and replication secrets, database accounts, API tokens, notification credentials, certificates, and keys used by automation. Remove unauthorized accounts and receivers from the clean configuration. Test a restoration using independently verified data, and monitor the rebuilt host for attempted reuse of old credentials or callbacks to the published infrastructure.

After recovery, keep AhsayCBS management off the public internet, require an authenticated administrative path, centralize logs outside the server, and alert on new receivers, administrators, JSP files, service creation, and unexpected children of AhsayCBS processes. Track hotfixes at the complete build level and require independent validation when a fix changes. The lesson from this incident is concrete: a backup server can only support recovery if its own patch state, identity boundary, and rebuild procedure are independently trustworthy.