Nothing says “trust us with your data” like a backup product that can be fully owned by a single unauthenticated HTTP request. The call is coming from inside the MSP.
Backups are supposed to be the one thing that saves you when ransomware eats the rest. So naturally the backup console is now the thing getting eaten. AhsayCBS, a backup management platform that MSPs and enterprises run to babysit everyone’s data, is under active attack via two unauthenticated flaws. And the version Ahsay shipped as the fix does not actually fix them. Chef’s kiss.
What happened
Huntress saw the first exploitation at 23:20:15 UTC on October 7, 2026, and within 24 hours confirmed five organizations breached. Attackers are scanning the internet for exposed AhsayCBS instances and running an exploit chain in an automated-ish sequence, dropping webshells and, because why not, cryptominers. Two CVEs are in play:
- CVE-2026-105133: an authentication bypass in the AhsayCBS web console. An unauthenticated attacker skips the login gate entirely.
- CVE-2026-105134: a command injection flaw in the Replication Receiver component at the endpoint
/rps/api/json/UpdateReceivers.do.
Chain them and you get SYSTEM-level code execution from a single unauthenticated HTTP request sequence. No creds. No clicks. Ahsay released version 10.3.4.0 on August 4, 2026 and called it a fix. Huntress confirmed on October 10 that the patch closes neither CVE. As of October 12 there is no fully verified fix. You are patching into the void.
Who is screwed
MSPs, mostly, and by extension every client whose data they hold. This is the supply-chain nightmare in its purest form: own one backup console and you own a fan-out of downstream environments. Backup infrastructure sits with god-tier access by design, so compromising it is the fastest path to deploying ransomware across every managed tenant at once. The webshell-plus-cryptominer activity we are seeing now is the polite opening act. The main event is extortion.
If your org outsources backup to an MSP running AhsayCBS with the console exposed to the internet, you are downstream of a fire you cannot see and did not light. Ask your provider. Today. In writing.
And yes, this week the broader ransomware economy kept humming. Ransom-DB logged 243 claimed incidents in the trailing seven days, with The Gentlemen, NightSpire, and Qilin leading the pack. A compromised backup console is how a mid-tier MSP becomes a multi-tenant headline.
Technical breakdown
The auth bypass (105133) means the web console trusts a request it should not. Once you are past the gate, the Replication Receiver endpoint takes attacker-controlled input and shovels it into a command context without sanitizing it (105134), so you go from “hello, unauthenticated stranger” to “SYSTEM shell” in one motion. The Replication Receiver is meant to accept data from other AhsayCBS nodes, so it is internet-facing by design in a lot of deployments. That is the whole problem: the feature that makes replication convenient is the feature that makes RCE convenient.
Because the vendor patch does not close the holes, standard patch-and-forget does nothing here. The only real controls right now are network-level: do not let the world talk to your backup console. Hunt for webshell writes under the AhsayCBS web root and anomalous child processes spawned from the AhsayCBS service. If you find either, assume the box is hostile and rebuild from a known-good image after rotating every credential the console ever touched.
Indicators of compromise (related active campaigns)
Ahsay-specific IOCs are still evolving with the Huntress write-ups, so prioritize their webshell path and process indicators first. For context, here is live infrastructure from this week’s commodity-malware noise that your EDR should already be choking on, pulled from abuse.ch ThreatFox (Oct 12 to 13, 2026):
| Type | Indicator | Family | First seen (UTC) |
|---|---|---|---|
| C2 ip:port | 52.205.177.11:8080 | Cobalt Strike | 2026-10-12 20:05 |
| C2 ip:port | 52.205.177.11:443 | Cobalt Strike | 2026-10-12 19:05 |
| C2 ip:port | 154.94.227.136:8088 | Cobalt Strike | 2026-10-12 17:56 |
| SHA256 | a30d908237853ef035449d6236f2e817fdfcc280fab60609de6f7cc36f1c1be8 | Mirai | 2026-10-13 00:53 |
| URL | https://noa.666iapk.net/vo/ | Vidar | 2026-10-13 02:10 |
IOCs are perishable. Treat the table as a starting point, not a shopping list, and pull fresh data from ThreatFox and your own telemetry before you go hunting.
What to do Monday morning
- Get AhsayCBS off the public internet. Restrict the management and Replication Receiver interfaces to trusted IPs via firewall or VPN, right now, before anything else.
- Assume breach if you were exposed between Oct 7 and now. Hunt for webshells in the web root and unexpected processes off the AhsayCBS service before you trust the box again.
- Do not rely on 10.3.4.0 as a fix. Track Huntress and Ahsay advisories for a verified build and apply it the second it lands.
- If you are a customer, interrogate your MSP. Are they running AhsayCBS? Is the console exposed? When did they lock it down? “We’re looking into it” is not an answer.
- Validate your backups are both offline and immutable. A backup an attacker can reach is just a second copy of the ransom note.
Sources
- Decryption Digest, AhsayCBS CVE-2026-105133 exploit chain (citing Huntress telemetry): decryptiondigest.com
- abuse.ch ThreatFox, live IOC feed (queried 2026-10-13): threatfox.abuse.ch
- Ransom-DB weekly ransomware trends (2026-10-12): ransom-db.com
