AhsayCBS is a central management console for backup operations. Huntress reports that attackers chained two vulnerabilities in internet-exposed AhsayCBS systems to obtain unauthenticated code execution with SYSTEM privileges. The operational question is therefore no longer only whether a vulnerable build is exposed. Teams also need to determine whether the management host was compromised and whether the running build is outside the demonstrated attack path.
What Huntress observed
Huntress says it began observing exploitation on 7 October 2026 at 23:20:15 UTC and had seen five organisations targeted by 8 October. The reported chain uses CVE-2026-105133 for an authentication bypass and CVE-2026-105134 for command execution through the Replication Receiver endpoint. Huntress observed JSP webshell deployment, follow-on commands from the AhsayCBS service, XMRig cryptomining and persistence through a Windows service.
This is direct telemetry reported by Huntress within its customer visibility. It is not evidence of prevalence across all Ahsay deployments, alteration of backup data or compromise of every internet-exposed instance.
The version boundary is disputed
Huntress updated its analysis on 8 October to say that AhsayCBS versions through 10.3.4 are affected. Ahsay published a clarification on 9 October stating that both vulnerabilities were addressed in 10.3.4.0, released on 4 August, and that upgraded systems are protected from unauthenticated remote exploitation. Ahsay separately warns that an upgrade does not remediate a compromise that occurred before it.
Those public claims are incompatible. The material inspected does not reconcile the exact build, test conditions or exploit path behind the disagreement. This analysis therefore does not label 10.3.4 either definitively vulnerable or definitively safe.
Three decisions should remain separate
- Contain the exposed management path. Identify AhsayCBS management interfaces and restrict access to trusted addresses or a VPN while the version dispute remains unresolved.
- Assess compromise independently of version inventory. Confirm the exact running build, but also review the host for the process, webshell, service and network indicators published by Huntress.
- Validate remediation and recovery evidence. Do not treat an upgrade as eradication evidence. If indicators are present, Huntress recommends a full re-image from a trusted backup because secondary persistence may remain.
A dated clarification from Ahsay or Huntress that reconciles the 10.3.4 result would materially change the version decision. Until then, build validation can inform prevention, but it cannot answer whether a previously exposed host is clean.
Primary sources
- Huntress technical disclosure, published and updated 8 October 2026. Observed exploitation, attack chain, host and network indicators, and response guidance. Inspected 10 October 2026.
- Ahsay clarification, dated 9 October 2026. Vendor position on 10.3.4.0 and prior compromise. Inspected 10 October 2026.
Next review event. Revisit this same case when either Ahsay or Huntress publishes a build-specific reconciliation, a new fixed version or additional exploitation telemetry. Material corrections should be dated rather than silently replacing this record.
Continue this decision.
Move from this analysis into a curated route across related incidents, evidence and operating constraints.