2026-10-22 · CVE-2026-105133
CVE-2026-105133 + CVE-2026-105134: Attackers Chained Two Bugs in Your Backup Software to Mine Crypto as SYSTEM
On October 7, 2026, Huntress caught something unusual in its telemetry: webshells and a cryptominer disguised as a legitimate Windows process, all traced back to AhsayCBS — the centralized console that managed service providers use to run backup jobs for their clients. By October 8, five organizations were confirmed compromised. By October 14, CISA had added both underlying CVEs to its Known Exploited Vulnerabilities catalog with a three-day federal remediation deadline.
The bugs themselves are a now-familiar shape: one unauthenticated access flaw, one authenticated command injection, chained into unauthenticated code execution as the highest privilege Windows offers. We've covered that chaining pattern before on this blog. What makes this one worth a second look isn't just the chain — it's that the vendor's first attempt at a fix didn't actually close it, and a lot of defenders who patched in good faith are still exposed.
What the two bugs actually are
CVE-2026-105133 is an authentication bypass in AhsayCBS's checkSysPwd API function. It's the kind of bug that sounds dry in a one-line advisory and turns out to mean "an unauthenticated caller can get the console to treat them as if they'd already logged in." A working public exploit exists for it, which is a big part of why exploitation moved so fast — nobody had to reverse-engineer anything from scratch.
CVE-2026-105134 is an OS command injection in the Replication Receiver endpoint, /rps/api/json/UpdateReceivers.do. Replication between backup servers is a privileged, trusted operation by design — it has to be, because it's moving customer backup data around — and that trust is exactly what makes a command injection here so damaging. The endpoint builds a system command from input it doesn't sufficiently sanitize, and the process running it is the Windows service account: NT AUTHORITY\SYSTEM.
Neither bug needs the other to exist, but neither one gets you very far alone either. The auth bypass gets you in the door. The command injection is what you do once you're standing in the room that matters.
The chain, and why it lands as SYSTEM
| CVE-2026-105133 (auth bypass) | CVE-2026-105134 (command injection) | Chained | |
|---|---|---|---|
| Auth required | None | Authenticated session | None |
| Reported CVSS | ~7.3 | ~9.3–10.0 (sources vary) | Effectively 10.0 |
| Reachable from | AhsayCBS API | Replication Receiver endpoint | Internet-facing API |
| Privilege gained | Valid session context | Command execution as SYSTEM | Unauthenticated SYSTEM RCE |
checkSysPwd hands an attacker a session without a password. That session is then enough to reach the Replication Receiver API and trigger the injection — and because the backup service itself runs as SYSTEM on Windows (it has to, to read and write arbitrary files across the filesystem for restore operations), the command injection inherits that privilege for free. This is the same confused-deputy shape we keep seeing in appliance and management-console CVEs: the bug doesn't need to escalate privilege, because the thing it's injecting into already has more privilege than the attacker could ever request directly.
Huntress's writeup on the observed intrusions is consistent with that: JSP webshells dropped through the backup console's own file-handling paths, a cryptominer named edge.exe to blend into normal process lists, and persistence installed as a Windows service — which, on a box that already runs a trusted backup service, is a very easy thing to miss in a process list.
The part that should worry you more than the CVE numbers
Ahsay's original patches — versions 9.15.2.59 and 10.3.4.0 — did not fully close the chain. Organizations that updated to those versions and considered themselves patched were still exploitable. The actual fix requires the hotfixes released after that: v10.3.4.45 (plus a reboot) or v9.15.2.70, depending on branch.
"Patched" is a claim, not a fact, and advisories get revised after the fact more often than most patch-management workflows account for. If your vulnerability tracker marked this CVE pair as remediated the day you applied 9.15.2.59 or 10.3.4.0, go back and check the version you're actually running against the vendor's current advisory — not the one you read when you first patched. A ticket closed on an insufficient fix is worse than a ticket still open, because it stops showing up on anyone's radar.
What this means for defenders
The specific fix is straightforward once you know it's incomplete: get to v10.3.4.45 or v9.15.2.70, reboot, and don't trust the version string alone — confirm against Ahsay's current security bulletin, since the hotfix numbering changed after the initial release. If you can't patch immediately, the API endpoints involved have no legitimate reason to be reachable from the general internet; restricting access to known replication partners and admin networks closes the exposure even before the hotfix lands.
The broader lesson is about where backup infrastructure sits in most organizations' threat model, which is usually: nowhere. Firewalls and VPN gateways get patched on a tight cycle because everyone agrees they're perimeter-critical. Backup consoles often don't get that treatment, even though they are, functionally, just as privileged — they hold credentials to reach every endpoint they protect, and in this case the compromised process runs as SYSTEM on each one. A ransomware actor's first move is usually to find and disable backups before encrypting anything; a console that's already got a webshell on it has done half that job in advance, whether or not the current occupants are using it for ransomware today.
Why we teach it this way
We build 0Labs' chained-vulnerability labs around exactly this pattern — not "exploit this one CVE," but "here's an auth bypass that gets you a session, now find what that session can reach that it shouldn't be able to." The interesting skill isn't memorizing that checkSysPwd was broken in AhsayCBS version X; it's building the reflex to ask, every time you see an authentication bypass in isolation, "what authenticated-only functionality does this now hand me for free?"
The second habit worth drilling, and one we fold into our patch-verification exercises specifically because of cases like this one, is treating a vendor's "fixed in version X" claim as a hypothesis to test rather than a fact to file away. Students who've had to discover for themselves that a sanctioned fix didn't fully close a vulnerability come out with a healthier skepticism than students who only ever practice against bugs that stayed fixed the first time. In production, that skepticism is the difference between a closed ticket and an open door.