Which AhsayCBS Hotfix Does Your Server Need?
Getting the right AhsayCBS hotfix onto a server is not the same as deciding that server can be trusted with recovery. Treat the installation, the investigation and the restore test as three separate jobs.
Huntress observed exploitation from 7 October and five organisations targeted by 8 October, within its telemetry. It also reported webshells and XMRig miners disguised as Edge components.
For a backup operator, the question is therefore larger than whether a maintenance ticket says complete. Who will establish what happened before the change, and what evidence will support using this host again? The following separates the published facts from BlackTree’s recommended acceptance checks.
Choose the package for the server branch
Ahsay’s 12 October alert says earlier 9.15.2.59 and 10.3.4.0 patches were incomplete. Its current instructions are:
| Server branch | Current hotfix |
|---|---|
| v10 | 10.3.4.45 |
| v7, v8 and v9 | 9.15.2.70 |
Both downloads require an Ahsay partner account, and installation must be followed by a server reboot. BlackTree checked the public instructions, not the restricted packages.
For the change record, capture the machine identity, its branch, the exact package obtained and the running build after the restart. Keep the package’s provenance with that record. A ticket covering several nodes should identify the result for each one, including a standby that could later become active. Do not use a screenshot from one server to sign off the rest.
Why an earlier update is not enough
On 9 October, Ahsay said v10.3.4.0 protected against these flaws. Its 10 October warning reversed that assurance; the 12 October notice then included the legacy hotfix route above.
The current structured records still label 10.3.4 unaffected in their CNA version data, despite newer CISA exploitation enrichment. That classification conflicts with the later vendor warnings. Do not use it as the installation target. Huntress verified v10’s entry-point mitigation, not persistence or legacy builds.
This distinction matters when reviewing an earlier change. Recover the actual package and completion evidence rather than treating a familiar version label, an old scan result or a closed ticket as a current security decision. If the record is ambiguous, ask the vendor or support partner to reconcile the package before declaring remediation complete.
What the incident review must establish
The chain combines CVE-2026-105133 authentication bypass with CVE-2026-105134 command execution in the replication receiver.
In practical terms, the incident review must distinguish preventing another entry from accounting for activity that has already occurred. Neither a successful update nor a quiet dashboard proves the latter. The published material leaves the full scale and earlier patch failure unexplained.
Consult Huntress’s investigation for indicators and detection material. Treat a match as a lead for investigation, not a complete account of the intrusion. Conversely, a search with no matches is only as useful as the records it actually covered. Record missing periods and unavailable telemetry alongside negative results.
Update, 14 October 2026: the federal deadline
CISA added both flaws to its Known Exploited Vulnerabilities catalogue on 14 October, with a 17 October remediation date for covered US federal agencies under BOD 26-04. Its forensic-triage flag is Yes for CVE-2026-105134 and No for CVE-2026-105133. Ransomware use is listed as unknown for both.
These catalogue fields do not replace an organisation’s incident assessment. The federal date is not a universal customer deadline, and a No flag is not evidence that an exposed host is clean. Give the response owner an explicit deadline for the local decision rather than borrowing a date that may not apply.
Investigate the period before the repair
Huntress recommends restricting management access and rebuilding from a trusted backup when indicators are present. BlackTree recommends keeping the installation decision separate from the evidence needed to return a potentially compromised service to use.
Start with a timeline: when was the management service reachable, when did the relevant logging begin, and when was access restricted? Preserve relevant records outside the suspect host before destructive recovery work. Note who collected them and which questions they cannot answer. Do not delay urgent containment merely to make the record look complete.
Next, assess the identities and recovery assets that the host could reach. Review the actual permissions and stored secrets in this environment, not a theoretical list of everything the product might support. Where exposure warrants it, plan credential replacement from a trusted administration path and check the dependent jobs afterwards. A rotation performed only on a suspect machine is a weak basis for confidence.
If the investigation cannot establish a trustworthy starting point, document that uncertainty and involve qualified responders. A clean scan is not a substitute for knowing whether its coverage included the suspected intrusion period. These are BlackTree’s response recommendations, not a finding that every installation or backup was compromised.
Prove that recovery works before closing the incident
Choose a restore point on evidence that it predates the suspected intrusion, not simply because it is the newest available copy. Test a representative workload in an isolated recovery environment. Check the restored application’s behaviour and access controls as well as the backup job’s success label. Record the result and any remaining exceptions.
Consider a hypothetical provider with two backup nodes: one has the new package and a verified restart; the other’s maintenance record is missing. A successful test restore from the first does not close the second node’s update gap. Equally, both nodes showing the expected build would not resolve an unexplained administrator account or a gap in historical logs. Those are different acceptance failures with different owners.
The incident record should therefore show three outcomes: the installation evidence for each node, the investigation’s findings and limitations, and the restore test that demonstrates an acceptable recovery path. Name the person accepting each outcome. If service must resume with an unresolved question, record the restricted operating conditions, expiry time and person accepting that risk.
BlackTree explored the same separation in the Acronis backup integration attacks and LoadMaster incident recovery. The relevant lesson is about evidence, not an assertion that those incidents share this attack mechanism.
Close the maintenance task when the installation is verified. Close the incident only when the investigation and recovery decisions are supported too. That is the difference between a server with a new version number and a recovery service the organisation has a defensible reason to trust.
Editorial update, 15 October 2026: expanded the explanation and response guidance, clarified the conflict in structured version data, and retained the original publication date, URL and artwork.
