Huntress began observing attacks on AhsayCBS backup servers on October 7, 2026. Attackers chained CVE-2026-105133, an authentication bypass, with CVE-2026-105134 to execute code on exposed servers and install webshells and cryptocurrency miners. If you run AhsayCBS, verify the corrected hotfix and investigate the period before it was installed.
The replication receiver gave attackers code execution
In Huntress’s account of the chain, reviewed October 19, 2026, the authentication flaw lets an attacker reach the replication receiver API. The attacker then configures a malicious receiver and writes a JSP webshell into the application directory. That gives the attacker a way to run commands on the host.
The backup server manages recovery operations for other systems. A successful backup job does not tell you whether someone has gained control of that server. The patch and the investigation therefore need separate evidence.
Earlier patches left the chain exposed
The vendor's guidance changed. In its October 12 advisory, Ahsay said earlier patches v9.15.2.59 and v10.3.4.0 had not fully addressed the vulnerabilities. It directed affected v10 customers to v10.3.4.45 and older-version customers to v9.15.2.70, followed by a reboot. Its October 13 update clarifies that v7 and v8 installations should upgrade to v9.15.0.0 before applying that hotfix. These instructions were reviewed October 19; check the vendor's current guidance before making changes.
A ticket saying “upgraded to 10.3.4” can therefore describe completed work while leaving the exposure unresolved. Record the actual installed build and compare it with the corrected advisory. If an MSP manages the server, ask for that evidence rather than a general assurance that patching is handled.
Huntress's October 12 update says it verified that v10.3.4.45 mitigates the chain's initial entry point. That verification concerns the vulnerability. It cannot establish that an individual server is clean.
Installing the hotfix does not remove an intrusion
Ahsay's October 13 recovery guidance identifies unexpected JSP files, unauthorized replication receivers, and unauthorized administrator accounts among compromise indicators. For affected systems, it recommends rebuilding the server and recovering configuration from before the compromise.
That is a different job from installing a hotfix. Before rebuilding, coordinate evidence preservation and containment with whoever owns incident response. A rushed reinstall can remove information needed to understand what happened. Agree on what to preserve before making changes that overwrite the host.
For your own investigation, connect the exposure window to the maintenance record. When was the management interface reachable? When did the corrected hotfix finish installing? What logs cover that interval, and who reviewed them? Missing logs are an uncertainty to document, not evidence that nothing happened.
Recovery instructions need to survive the server
Consider a hypothetical small company whose administrator keeps the restore instructions and backup credentials on the same server that controls its backups. Even if a separate backup copy survives, recovery now depends on information from a host the team cannot trust.
Use a controlled recovery exercise to identify that dependency before an incident. Have an authorized operator locate the recovery instructions, obtain the required access through your normal controls, and restore a representative workload into an isolated environment. Record where the process stalls. Do not overwrite production data to demonstrate that a backup exists.
Keep two decisions visible in the incident record: who verified remediation of the vulnerable software, and who accepted the evidence that recovery was safe. Those decisions may happen at different times and involve different people.
Before putting a rebuilt server back in charge of backups, assign an owner to review the recovered configuration and the restore-test result. Keep the evidence behind that decision with the incident record.