AhsayCBS Is Being Exploited. Restrict Access Now

Matthew Leo · Published October 11, 2026 · Guides

A network administrator checks generic backup equipment and cable connections in an illustrative server-room scene.

Organizations running AhsayCBS should treat two newly disclosed vulnerabilities as an active incident, not a routine patch item. Huntress says attackers are chaining CVE-2026-105133 and CVE-2026-105134 against internet-exposed servers to gain unauthenticated code execution.

The security firm began observing exploitation late on October 7, 2026. By October 8 it had seen five organizations targeted. Its investigation found webshells, reconnaissance activity and XMRig cryptocurrency miners disguised as Microsoft Edge-related processes.

Huntress initially reported that version 10.3.4 was not affected, then updated its findings: AhsayCBS versions through 10.3.4 should be treated as vulnerable. At the time of that update, it said no patch was available and recommended restricting the management interface while investigating for compromise.

Why this backup server deserves priority

AhsayCBS is the central management console for Ahsay backup deployments and is used by managed service providers and systems integrators. A compromise can therefore land on a server that holds privileged access, backup policies and connections to customer environments.

Huntress’s technical analysis says the attackers first use CVE-2026-105133 to bypass authentication, then CVE-2026-105134 to execute commands through the replication receiver component. The observed processes run with SYSTEM privileges.

The public NVD record for CVE-2026-105133 and record for CVE-2026-105134 provide identifiers, but defenders should use the newer Huntress version finding when deciding whether 10.3.4 is exposed.

Immediate containment

  1. Identify every AhsayCBS instance. Include systems operated by subsidiaries and service providers, not only servers in the main asset list.
  2. Remove the management interface from direct internet exposure. Limit access to trusted source addresses or a controlled VPN. Do not assume a login page is adequate protection against a pre-authentication chain.
  3. Preserve evidence before making broad changes. Record configuration, running processes, services, network connections and relevant logs. If compromise is suspected, follow the incident-response process rather than casually cleaning individual files.
  4. Search for the published indicators. Huntress lists suspicious child processes from cbssvcX64.exe, JSP webshell behaviour, files placed in temporary directories and a fake-looking MicrosoftEdgeUpdateSvc service.
  5. Block malicious infrastructure. Use the domains, addresses and hashes in the current technical report, while recognizing that attackers can change infrastructure.
  6. Check for secondary persistence. Huntress cautions that observed attackers may leave more than the visible miner or webshell.

Do not confuse containment with recovery

Stopping public access reduces the immediate attack surface but does not prove the host is clean. Huntress recommends a full re-image from a trusted backup when its indicators are found because secondary backdoors may persist.

That recovery decision should consider the role of the server. Before restoring backup management, rotate credentials and tokens available to the compromised host, validate the backup source from a known-clean environment and confirm that connected customer systems were not reached.

Canadian managed service providers should also consider notification duties in customer contracts and applicable privacy law. A cryptominer alone may look like a resource-theft problem, but SYSTEM-level access and a webshell create a broader confidentiality and integrity risk.

What to monitor next

Version guidance is changing quickly. Administrators should follow Ahsay support communications, the NVD records and the Huntress update rather than relying on a cached vulnerability summary. Once a fixed build is available, test it in a controlled environment, deploy it promptly and verify from outside the network that the management page is no longer publicly reachable.

Mapletechie’s broader guide to building a backup plan that survives ransomware remains useful here: a recovery copy needs to be isolated from the server whose compromise triggered the restore.

Tags: AhsayCBS, cybersecurity, backups, vulnerability management

Read on Mapletechie