AhsayCBS CVE-2026-105134: Unauth RCE as SYSTEM, No Patch Yet

The host you least want an attacker to own is the one that holds copies of everything else. That is the host under attack right now. Since October 7, 2026, threat actors have been running code as NT AUTHORITY\SYSTEM on internet-facing AhsayCBS backup servers, with no password and no patch to stop them. The managed detection firm Huntress, which reported the activity and assigned the identifiers, says at least five organizations were hit in the first days.

AhsayCBS is the server-side console for Ahsay's backup suite, the piece that hosting providers and managed service shops run to drive backups for their own clients. When it falls, the blast radius is not one workload. It is the recovery plane for everything that console touches.

What is actually broken

Two flaws are being used together. CVE-2026-105133 is the authentication problem: a weakness in the checkSysPwd function (in com/ahsay/obs/api/ApiStructsAction.java) that lets a request slip past the login check. CVE-2026-105134 is the serious one, rated critical by Huntress: an unauthenticated remote code execution hole in the Replication Receiver component, reachable at /rps/api/json/UpdateReceivers.do, where a random token can stand in for valid credentials. Chained, they turn an exposed management interface into a SYSTEM shell.

The specifics a defender needs, as confirmed on the primary advisory:

• Affected: AhsayCBS versions through 10.3.4, which is the current release. Earlier reporting suggested a fix landed in 10.3.2, but researchers confirmed 10.3.4 is also vulnerable, so there is no fixed version to upgrade to as of this writing.
• Exploitation status: actively exploited in the wild since October 7, and a public exploit for the authentication bypass is circulating. This is not theoretical.
• Privilege: code runs as SYSTEM, the highest account on a Windows host. There is no privilege step left to climb.

The CVEs were published October 4. In-the-wild remote code execution followed on October 7, and multiple victims were confirmed by October 8. Three days from a public advisory to working attacks is the window defenders now live inside, and for AhsayCBS that window has no closing edge yet because there is nothing to patch to.

Why a backup-server compromise is its own category of bad

Standard incident advice after SYSTEM-level code execution is to rebuild from a known-good backup. That advice turns circular here. The compromised host is the backup platform. The recovery path you would reach for is the thing the attacker is sitting on, which means you cannot assume the recovery path is clean. Before you trust a single restore point, you have to establish whether the console that produced and stored it was already under someone else's control. That is a slower, more painful investigation than a normal box rebuild, and it is the part the wire coverage skips.

There is a second reason this stings. A backup console usually holds standing credentials and agents reaching into the systems it protects. RCE on that one host is a credible path to the clients behind it, which is exactly why management and backup planes keep showing up as soft targets. We wrote up the same shape when Quest NetVault's backup server took an unauthenticated RCE, and again when N-able N-central's management console was hit with a max-severity unauthenticated bug. Command injection leading to remote code execution is the second-largest flaw class across our last 90 days of vulnerability triage, behind only cross-site scripting. Attackers go where the keys are kept.

The crypto-miner is a signal, not just noise

Dropping an XMRig miner on a SYSTEM-level foothold looks like small-time monetization, and it is. That is the point. When the first payload on a fresh, unauthenticated RCE is commodity cryptomining, it tells you the activity is opportunistic and scan-driven, not a hand-picked target list. The attacker is spraying the internet for exposed consoles and cashing in on whatever answers. If your AhsayCBS interface is reachable from the public internet, you should assume it is being probed, not wonder whether you are interesting enough.

The post-exploitation set follows a familiar living-off-trusted-names pattern. The actors stood up a Windows service called MicrosoftEdgeUpdateSvc to blend in next to the real Edge updater, ran the miner under an edge.exe name, and used a renamed copy of the legitimate NSSM service manager (msedge.exe) to keep it alive. They also loaded WinRing0x64.sys, a legitimate but vulnerable kernel driver, to reach the hardware for mining. That last move matters for cleanup: a vulnerable driver loaded into the kernel means host trust is gone below the point any on-host tool can vouch for. This is the same bring-your-own-vulnerable-driver technique we have tracked in tooling built to disable endpoint defenses. Combined with SYSTEM-level RCE, it is why re-imaging the host is the honest remediation, not scrubbing the artifacts you can find.

What to do now

There is no patch, so the work is containment and hunting.

• Get it off the public internet today. Restrict the AhsayCBS management interface to trusted source addresses or put it behind a VPN. An exposed console is the entire precondition for this attack.
• Hunt before you assume you are clean. The highest-signal detection does not need the IOCs below: look for the AhsayCBS process spawning child processes it has no business launching, such as PowerShell or a service-control command. A backup server shelling out is the tell.
• Treat a confirmed hit as a rebuild, not a cleanup. Given SYSTEM access and a kernel driver load, re-image the host and rotate every credential and agent token the console held. Validate restore points against an independent record before trusting them.

The indicators Huntress published, for a retrospective sweep of hosts and egress logs:

Service name:   MicrosoftEdgeUpdateSvc  (mimics the real 'edgeupdate' service)
msedge.exe      05f69ae6b2b89c1c4dcf836bff032232f11bf0109f2b498e2345045d06139034  (renamed NSSM)
edge.exe        4dcb0202fe8b2d4d7b183764e38184cd6ed50132786cc7e7d1f7f4bce1dd6f3d  (XMRig miner)
Taskgmr.ps1     481728a7c9c4c02be07051d9c1958d902ea6397ebb8952ab83944818e3d25d21  (loader script)
Driver:         WinRing0x64.sys  (legitimate but vulnerable kernel driver)
Payload host:   imagefiles-backup.oss-ap-southeast-7.aliyuncs[.]com
Mining pool:    xmr.kryptex[.]network:8029 , 51.195.127[.]124:8029
C2 addresses:   177.4.12[.]11 , 38.60.252[.]110 , 107.191.47[.]199
                185.220.236[.]49 , 104.234.26[.]10 , 123.202.208[.]37

Map the behavior to ATT&CK for your detections: initial access via T1190 (exploit public-facing application), execution through T1059.001 and T1059.003, persistence with T1543.003 (new Windows service) and T1505.003 (web shell), and impact as T1496.001 (resource hijacking for mining). None of that replaces getting the console off the internet. With no fix on the table, exposure is the only knob you control.