A critical OS command injection flaw has been published for Ahsay’s AhsayCBS backup server, tracked as CVE-2026-105134 and scored CVSS 10.0. The bug requires no authentication, is reachable over the network, and ends in command execution on the host running the backup service. At the time of writing, we have not seen a vendor-confirmed report of in-the-wild exploitation, but the combination of an unauthenticated endpoint and a high-value target class makes this one to patch immediately.

What’s affected

Per the CVE record and aggregator write-ups, AhsayCBS up to and including 10.3.2 is vulnerable. The fix is in version 10.3.4. If you run 10.3.3, treat it as unverified and move to 10.3.4 rather than assuming it is clean.

AhsayCBS is the central console and storage controller for Ahsay’s backup platform, widely deployed by managed service providers and mid-size enterprises. Servers are frequently internet-facing so that remote clients can back up and so that administrators can reach the web console.

Technical details

The flaw sits in the Replication Receiver component, in the handler for /rps/api/json/UpdateReceivers.do. A crafted value in the random argument is not neutralized before it reaches an operating-system command, which is classic CWE-78 OS command injection. Because the replication API is exposed through the same web interface as the rest of AhsayCBS, an attacker only needs network access to that listener. No credentials, session, or user interaction are involved, which is why the score lands at the top of the CVSS scale.

We have not independently confirmed exploit mechanics beyond the endpoint and parameter named in the public record, and we are not publishing payload details. Defenders should assume that a working proof of concept is straightforward to derive from the endpoint name and parameter once someone diffs 10.3.2 against 10.3.4.

Impact

Code execution on a backup server is worse than code execution on most other servers:

  • Backup data exposure. Backup stores hold copies of file servers, databases, mailboxes and endpoint data. Access to the host usually means access to the data, and often to encryption keys or stored credentials used for the backup jobs.
  • Ransomware staging. Ransomware operators routinely target backup platforms first, deleting or encrypting backup sets and retention data before detonating on production systems. Veeam, Commvault and other backup products have all been exploited this way. An unauthenticated RCE in a backup controller fits that playbook.
  • MSP blast radius. Providers that host multiple customer tenants on one AhsayCBS instance risk cross-customer exposure from a single compromise.
  • Pivot point. Backup servers tend to hold broad network reach and service credentials, making them useful for lateral movement.

Mitigation

  1. Upgrade AhsayCBS to 10.3.4 or later. This is the only complete fix.
  2. Remove internet exposure. If the console and replication listeners must be reachable by clients, place them behind a VPN, an allowlist of known client and replica IP ranges, or a reverse proxy that restricts /rps/api/ paths to trusted sources.
  3. Hunt for exploitation. Review web and application logs for requests to /rps/api/json/UpdateReceivers.do, particularly from unfamiliar addresses or with unusual random values containing shell metacharacters. Look for unexpected child processes spawned by the AhsayCBS service account, new scheduled tasks or cron entries, new local accounts, and outbound connections from the backup host to unknown destinations.
  4. Verify backup integrity. If you find suspicious activity, validate that backup sets and retention policies have not been altered or deleted, and keep at least one offline or immutable copy that the backup server cannot modify.
  5. Rotate secrets. On any host you suspect was reached, rotate credentials and encryption keys stored in or accessible to the AhsayCBS service.

Sources

Details here come from public CVE aggregators; check Ahsay’s own release notes for the authoritative fixed-build list.