AhsayCBS backup attacks: conflicting findings on version 10.3.4

Huntress reported attacks observed since 7 October against AhsayCBS, a server that manages backups. The researchers described chaining two vulnerabilities and deploying webshells. Source: the Huntress investigation.

The VulDB records published on 4 October describe improper authentication in CVE-2026-105133 and operating system command injection in the Replication Receiver component in CVE-2026-105134.

Breachroad’s conclusion: backup administrators, MSPs and service owners should establish console reachability, the running version and available evidence of earlier server activity. Updating software and assessing a possible incident require separate findings. The plan below is our organisational recommendation.

A version number does not close the case

The CVE records examined mark 10.3.4 as unaffected. However, Huntress’s 8 October update states that this version is also affected. That discrepancy between sources must inform the remediation decision.

We do not identify a release here as a confirmed solution. We recommend checking the vendor’s release notes and obtaining current confirmation of which change addresses both issues. Record the source of that information and how it was verified in your configuration. An inventory version alone does not demonstrate that the relevant fix works.

Map console access first

We suggest establishing where the management interface is reachable from: the internet, customer networks, partner connections and internal segments. Do not limit the assessment to the location administrators normally use. A shared address or network rule may permit more systems than the procedure anticipates.

The result should identify the people responsible for the console, network and access restriction decision. If a partner operates the service, request a specific review scope and evidence. A broad assurance that software is current does not resolve the discrepancy above.

Our recommendation is to restrict reachability to justified locations and authorised operators, verify required jobs and record a service recovery plan if the change disrupts backups. Adapt controls to the environment: calling a connection a VPN does not establish who can use it.

Give historical analysis a scope

Huntress identifies unusual child processes of cbssvcX64.exe and Edge-named files in temporary directories. These are leads from a particular investigation, rather than standalone proof that every similarly named file is malicious.

In our plan, the team examines timing, process origin, account, connections and related changes. It also establishes how long the console was reachable and which logs cover that period. An absence of alerts with incomplete telemetry should be recorded as an analytical limitation.

If signs of unauthorised activity emerge, invoke incident handling. We recommend preserving logs and configuration, coordinating isolation with responders and establishing the scope of service account permissions. Removing one suspicious file does not explain whether other changes or persistent access exist.

What the backup owner needs to know

We suggest three questions for business and IT to discuss together:

1. What does this server control? Identify managed jobs, accounts and connections. A controller shared across customers requires a separate scope assessment for each customer.
2. How would you restore the management service? Identify a trusted configuration source and who authorises its use. Evidence that a copy exists does not replace an assessment of its suitability for recovery.
3. Who decides during an interruption? Establish owners for communication, recovery priorities and acceptance of limitations. Keep that record accessible outside the backup console itself.

A scenario to discuss with the team

Consider a provider whose shared console has open access while the team relies on having the correct version. This is a hypothetical training scenario. Participants should identify missing evidence, who authorises access restrictions and the information needed to assess the server’s history.

The aim is to practise decisions under conflicting remediation information while preserving backup continuity. For broader context, read our guide to the 3-2-1 backup strategy. IT teams and service owners can discuss similar scenarios in our cybersecurity training for organisations.