CVE-2026-105134: Ahsay AhsayCBS OS Command Injection RCE Vulnerability — Analysis & Mitigation

On October 4, 2026, two CVE identifiers were published against Ahsay AhsayCBS, the server-side backup management platform of the Ahsay Cloud Backup Suite: CVE-2026-105134, an OS command injection flaw rated CVSS 10.0, chained with CVE-2026-105133, an authentication bypass. Within three days, attackers were exploiting the chain in the wild — dropping webshells, stealing credentials, and installing cryptominers on backup servers. For the security of cyberspace, few targets are more consequential than the machines that hold everyone's last good copy.

Summary

AhsayCBS is the central server that receives, stores, and manages backups for client machines — widely deployed by managed service providers (MSPs) who run backups for many customer organizations at once. Its management web service is frequently reachable from the internet by design, so administrators can reach it remotely.

Attackers chain two flaws, both reachable by manipulating a single random API argument, with no account and no user interaction. CVE-2026-105133 (improper authentication, CWE-287) sits in the checkSysPwd function of the API component (ApiStructsAction.java) and lets a remote attacker bypass authentication. CVE-2026-105134 (OS command injection, CWE-77/CWE-78) sits in the Replication Receiver component — the endpoint /rps/api/json/UpdateReceivers.do — and turns attacker-controlled text into operating-system commands. Together: unauthenticated remote code execution on the backup server, with the service running as NT AUTHORITY\SYSTEM.

The timeline is brutal. NVD publication: October 4. Huntress observed exploitation beginning October 7 at 23:20 UTC — three days later — with at least five organizations targeted by October 8. Bitdefender's MDR team investigated three separate customer incidents through this chain. Ahsay released hotfixes on October 12, and CISA added both CVEs to its Known Exploited Vulnerabilities catalog on October 14, with a federal remediation deadline of October 17.

Severity

• CVE ID: CVE-2026-105134 (chained with CVE-2026-105133)
• CVSS 3.1: 10.0 Critical (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) — CVE-2026-105133: 7.3 High
• CVSS 4.0: 9.3 Critical — CVE-2026-105133: 5.5 Medium
• Attack requirements: None — unauthenticated, remote, low complexity, no user interaction; public exploit exists; CISA rates exploitation automatable
• Impact: Remote code execution as SYSTEM on the backup server
• Exploited in the wild: Yes — confirmed by Huntress and Bitdefender MDR since October 7; CISA KEV-listed

The 10.0 vector is the maximum CVSS 3.1 can express: network-reachable, trivial to exploit, no privileges, and the scope change (S:C) means compromise escapes the vulnerable component itself. A public exploit exists, so this is not a theoretical rating — it is a weaponized one.

Affected Versions

Every AhsayCBS server from v7 through v10 reachable by an attacker is exposed unless it runs v10.3.4.45 or later (v10 branch) or v9.15.2.70 or later (v7, v8, v9). Read that carefully, because the patch story here is a trap: Ahsay's earlier patches — v10.3.4.0 and v9.15.2.59 — did not fully fix the flaws, and the NVD entries still list 10.3.4 as unaffected, which the vendor's later advisory supersedes. If you patched early and stopped, you are still vulnerable. The only question that matters is whether the server runs v10.3.4.45 / v9.15.2.70 or later — check the full four-part build number in the web console under System Settings > License > Update License.

Technical Analysis

Pentest Perspective: How the Chain Fits Together

From a pentest standpoint, this chain is a masterclass in why testers chain low and medium findings instead of reporting them in isolation. CVE-2026-105133 alone is "just" an authentication bypass (CVSS 7.3/5.5) — serious, but bounded. CVE-2026-105134 is the command injection that converts access into control. Attackers did exactly what a good penetration tester does: used the auth flaw to reach the injection point, then used the injection to land code execution as SYSTEM.

The shared random argument is the detail that should make every developer pause. Both flaws are reached by manipulating the same parameter — one in the auth check, one in the replication receiver. That pattern screams a single trust boundary drawn in the wrong place: attacker-influenced input flowing into security decisions and into command construction. When I test APIs, a parameter named "random" that influences authentication is an immediate red flag — randomness is for nonces and tokens, never for access decisions, and it must never reach a shell.

What the Attackers Actually Did

Bitdefender MDR's three incident investigations and Huntress's telemetry agree on the playbook. After gaining SYSTEM via the chain, attackers:

• Planted JSP webshells in the AhsayCBS web application directories — small scripts that turn ordinary web requests into a command shell.
• Staged payloads in C:\Users\Public (writable by every local user) and downloaded tooling via curl and certutil.
• Built persistence that survives patching: installing and configuring OpenSSH for a backdoor that does not depend on the vulnerable web service, creating services and scheduled tasks, and elevating accounts.
• Deployed XMRig cryptominers disguised as edge.exe (Microsoft Edge's name) with an AI-assisted PowerShell script (Taskgmr.ps1) that kills Windows Task Manager when opened — anti-analysis tradecraft.
• Went credential hunting — exactly what you expect on a backup server, which stores credentials for everything it protects.

The cryptominer is the polite outcome. The same webshell and SYSTEM access on an MSP's backup console reaches other people's data — and ransomware operators know that destroying backups comes before encrypting anything. Bitdefender saw no ransomware in its three incidents, but calls continued opportunistic exploitation "near-certain."

What Is Data Integrity When the Backup Server Itself Is Owned?

What is data integrity in the context of CVE-2026-105134? It is the guarantee that your backups are complete, unaltered, and restorable — and this flaw attacks that guarantee at its root. An attacker with SYSTEM on the backup server can silently corrupt, encrypt, or exfiltrate backup sets long before any ransomware note appears. Your disaster-recovery plan assumes the backups are the one thing the attacker cannot touch. This vulnerability breaks that assumption, which is why backup infrastructure deserves the same hardening as domain controllers: isolated networks, no internet exposure of the management interface, and immutable/offline backup copies that no compromised server can rewrite.

Why This Matters

Three lessons stand out. First, patch completeness matters more than patch speed. Admins who applied v10.3.4.0 did the right thing promptly — and remained vulnerable. Verify the build number, not the fact of patching. Second, patching does not evict the attacker. Webshells, rogue services, and OpenSSH backdoors survive the hotfix; every exposed server needs a compromise assessment going back to October 4. Third, several actors are likely using this independently — Bitdefender saw shared infrastructure (C2 at 38.60.252[.]110) but divergent tooling, the signature of a public exploit in wide circulation. A similar chained-auth-to-RCE pattern recently hit the network edge in CVE-2026-104935 (Ivanti Connect Secure), and the unauthenticated-RCE-with-public-exploit shape matches CVE-2026-105192 (LMCache) — both analyzed on this blog.

What is data integrity worth if the system guarding it can be owned remotely with no credentials? That is the question CVE-2026-105134 forces every MSP and backup administrator to answer this week. What does vulnerable mean for a backup platform? It means the last line of defense has become the first target.

Mitigation

1. Patch to the real fixed builds: v10.3.4.45+ (v10) or v9.15.2.70+ (v7–v9), then reboot as Ahsay's advisory instructs. Earlier builds are not fixed — verify the full version number.
2. Assume breach on any internet-exposed server and hunt from October 4 onward: unknown JSP/script files in AhsayCBS directories, PowerShell or shells spawned by the AhsayCBS service, .cmd files in C:\Users\Public, unexpected OpenSSH installations, new services/scheduled tasks, privilege changes, and outbound connections to unknown IPs.
3. Reduce exposure: restrict the management web service to known administrative networks; it should never face the open internet.
4. Protect data integrity directly: maintain offline/immutable backup copies isolated from the backup server, so a compromised console cannot destroy your recovery path.
5. Rotate credentials stored on or reachable from the backup server — attackers explicitly hunted them.

References

• Bitdefender technical advisory — exploitation chain analysis: https://www.bitdefender.com/en-gb/blog/businessinsights/technical-advisory-ahsaycbs-exploitation-chain-cve-2026-105133-cve-2026-105134
• The Hacker News — attackers exploit AhsayCBS flaws to deploy miners: http://thehackernews.com/2026/10/attackers-exploit-ahsaycbs-flaws-to.html
• SecurityAffairs — CISA KEV additions (AhsayCBS, Cisco, Palo Alto): https://securityaffairs.com/201041/security/u-s-cisa-adds-palo-alto-networks-pan-os-ahsay-ahsaycbs-and-cisco-secure-email-gateway-flaws-to-its-known-exploited-vulnerabilities-catalog.html

More from this blog: about Faizan Akhtar.

Report by Faizan Akhtar — The Cyber Security Researcher