AhsayCBS CVE-2026-105134: Hotfix and Compromise Checks
AhsayCBS CVE-2026-105134 is a command-injection vulnerability in a backup server product. CISA added it to the Known Exploited Vulnerabilities catalog on October 14, 2026. Ahsay’s October 12 update warns that two earlier patches did not fully address this issue or the related authentication flaw, CVE-2026-105133. For teams responsible for backup infrastructure, the task is to find the actual running build, install the correct hotfix, and separately review whether the system was exposed while vulnerable.
What AhsayCBS CVE-2026-105134 does
CISA describes a remote command-injection path involving the random parameter in the Replication Receiver’s /rps/api/json/UpdateReceivers.do endpoint. CISA says attackers can chain this flaw with CVE-2026-105133, an authentication vulnerability. The KEV listing establishes known exploitation; it does not establish that every AhsayCBS deployment has been compromised or that a particular organization has been targeted.
CISA set October 17, 2026 as the remediation due date for covered federal agencies. That is not a blanket legal deadline for private businesses. The practical priority for other organizations depends on whether they run AhsayCBS, their exposure, and the vendor’s current instructions.
Which AhsayCBS versions need attention
NVD’s description identifies versions through 10.3.2, but its suggestion to upgrade to 10.3.4 is not sufficient as current patch advice. Ahsay explicitly said on October 12 that v9.15.2.59 and v10.3.4.0 did not fully resolve CVE-2026-105133 and CVE-2026-105134. Follow the newer vendor update rather than stopping at the older NVD recommendation.
- For affected v10 installations, Ahsay directs partners to the v10.3.4.45 hotfix.
- For affected v9 installations, apply the v9.15.2.70 hotfix. For affected v7 or v8 installations, Ahsay directs partners to upgrade first to v9.15.0.0, then apply the v9.15.2.70 hotfix.
Ahsay says both downloads require a partner portal login and instructs teams to reboot the server after applying the hotfix. The notice does not provide a complete affected-build matrix for every branch. Ask the vendor or your backup provider to confirm whether a particular build is affected rather than assuming that all installations in a branch share the same exposure.
A practical response plan for AhsayCBS CVE-2026-105134
1. Find each instance and confirm its build
Inventory production, replication, standby, and provider-managed AhsayCBS servers. Record the installed and running build, internet exposure, management access, backup destinations, and owner. Ask a hosting or backup partner to confirm its build if it administers the server. Compare each build with Ahsay’s current hotfix instructions; a downloaded package or completed change ticket does not prove the running service received the fix.
2. Preserve useful evidence if compromise is plausible
Before clearing or rotating logs, preserve relevant web/API, system, authentication, and backup-server records for the period when the server may have been vulnerable. Review unexpected requests to the named endpoint, unfamiliar administrator activity, unexpected processes or commands, configuration changes, and unusual outbound connections. These are general triage questions, not a complete set of indicators. Ahsay also identifies unexpected root-level folders, randomly named JSP files or folders under %CBS%\webapps, unauthorized RPS receivers, and unauthorized Admin accounts as signs of compromise. If these appear, preserve evidence and involve an incident-response specialist: Ahsay recommends a full server rebuild and restoration from a pre-compromise Auto Save configuration. A clean patch result does not rule out earlier activity.
3. Apply the right hotfix, reboot, and validate
Plan a maintenance window around active backups and replication. Obtain the branch-appropriate package through Ahsay’s partner channel or your service provider, back up configuration, and follow the vendor’s installation steps. For affected v7 or v8 servers, upgrade to v9.15.0.0 before applying v9.15.2.70, as Ahsay instructs. Reboot after the hotfix as Ahsay directs. Then confirm the running build on every instance: v10.3.4.45 for affected v10 deployments, or v9.15.2.70 for affected v9 and upgraded v7/v8 deployments, subject to any newer vendor guidance. Test backup jobs, replication, restore access, and alerting after maintenance.
4. Keep patch verification and incident review separate
Document the pre-change build, hotfix applied, reboot, post-change build, test result, and exposure window. If triage reveals suspicious activity, preserve evidence and scope the incident rather than declaring the system safe simply because the patch installed. Coordinate containment and any needed credential review with the team that owns the backup service.
Keep backup infrastructure on the security inventory
Backup servers often sit outside routine workstation patch cycles. Give each one a named owner, a recorded version, reliable off-host logs, a tested restore path, and a regular advisory check. That makes the next urgent vendor update easier to execute and verify.
If your team needs help reviewing exposure or checking remediation evidence, see Reliant System’s security review and remediation service. A scoped penetration test may help assess related exposure after immediate patching and any necessary incident response; it is not a substitute for either.