AhsayCBS CVE-2026-105133 and CVE-2026-105134 Exploited: Version 10.3.4 Still Vulnerable

According to Huntress's updated advisory, AhsayCBS 10.3.4 is affected, despite earlier reporting suggesting it was not susceptible. Huntress updated its findings after further investigation and confirmed all versions through 10.3.4 are impacted by CVE-2026-105133 and CVE-2026-105134. If you upgraded to 10.3.4 and considered the issue closed, you need to look again.

What happened, and when​

The timeline is short:

• October 4, 2026: NVD disclosed two CVEs impacting the AhsayCBS backup utility: CVE-2026-105133 and CVE-2026-105134.
• October 7, 2026, 23:20:15 UTC: Huntress began seeing threat actors exploiting the flaws to perform remote code execution on impacted hosts.
• October 8, 2026: Huntress had seen five organizations targeted via these flaws. Five is the number Huntress saw among its own customers. It is not a count of every compromised server.
• October 9, 2026: BleepingComputer reported that it had been told both vulnerabilities are reported as fixed in AhsayCBS 10.3.2, but researchers at managed detection and response company (MDR) Huntress found that they also affect Ahsay 10.3.4, currently the latest version. BleepingComputer also said it had asked Ahsay about patch plans and had no reply when it published.

Why the version guidance was confusing​

Sources disagree on which version fixes the flaws, so it helps to lay out what each one said. Huntress notes that the NVD records for both flaws also said that an exploit had been published, and upgrading to version 10.3.4 mitigates the issue. Version 10.3.4 was released August 5, 2026, according to Ahsay's documentation. Some coverage repeated that advice. SecurityOnline, for example, still lists 10.3.4 as the fixed version and tells readers to "Update to 10.3.4 now".

Huntress's October 8 update contradicts that. Its researchers found 10.3.4 still exploitable, contacted Ahsay, and told customers to restrict access until a patch ships. No patch is available yet, so organizations should restrict management interface access to trusted IPs or VPN until Ahsay releases a fix.

Section summary: The flaws became public on October 4, attacks began late on October 7, and as of Huntress's update no AhsayCBS version is known to be safe.

The two vulnerabilities​

Daily.dev's summary of the Huntress research puts it this way: CVE-2026-105134 is a critical unauthenticated remote code execution flaw in the Replication Receiver component (/rps/api/json/UpdateReceivers.do) allowing attackers to run code as NT AUTHORITY/SYSTEM. SecurityWeek reported that the two bugs allow attackers to manipulate arguments in certain functions of the tool to bypass authentication and inject OS commands.

The attackers use the bugs together. First, CVE-2026-105133 is used to bypass authentication. Then CVE-2026-105134 is used to gain code execution. SecurityOnline describes the next step: attackers configure a malicious receiver to upload a Java Server Page webshell into the web root. Once the webshell lands, the backup service process executes system commands with NT AUTHORITY/SYSTEM privileges.

The "medium" label on CVE-2026-105133 understates the risk. It is the bug that gets attackers past the login, and the critical bug does the rest. Patch prioritization should treat the pair as one unauthenticated remote code execution path.

Section summary: An authentication bypass plus a SYSTEM-level command injection gives attackers full control of an internet-facing backup console with no login required.

What the attackers did after getting in​

Huntress first noticed the activity through process behavior: several suspicious command lines spawning from AhsayCBS executable files (cbssvcX64.exe). From there it observed the following.

Webshells​

In some incidents, threat actors deployed .jsp webshells in the web application directory immediately after exploitation. A webshell is the part to worry about most. A miner is noisy and easy to find. A webshell lets the attacker come back whenever they like, and on a backup server that could mean far more damaging activity than mining.

A miner disguised as Edge​

After gaining access, Huntress observed the attacker perform reconnaissance, deploy Java Server Page (JSP) webshells, and download the XMRig miner disguised as edge.exe. The miner persists on the host via a service named 'MicrosoftEdgeUpdateSvc,' which runs msedge.exe, identified by Huntress as a modified copy of the legitimate Non-Sucking Service Manager (NSSM) utility.

Huntress gives more detail:

• The payloads (Taskgmr.ps1, msedge.exe, edge.exe and config.json) were downloaded into %TEMP% or AppData\Local\Temp from an Alibaba Cloud Object Storage host.
• The miner connected to a Monero pool on port 8029, including xmr.kryptex[.]network and 51.195.127[.]124.
• The fake service name MicrosoftEdgeUpdateSvc imitates the real Edge Update service, which is named edgeupdate. The fake service ran the renamed NSSM binary from Temp with SYSTEM privileges, and NSSM restarted the miner after crashes or reboots.

A practical check for Windows admins: the real Edge updater does not run out of a user's Temp folder. Any Edge-named executable running from AppData\Local\Temp should be investigated.

A script that hides from Task Manager​

The PowerShell script Taskgmr.ps1, which Huntress thinks was written with AI help based on its commenting style, watches for Task Manager. When Task Manager opens, the script stops the mining service. When it closes, the script starts the service again. It also kills Task Manager at 18:00 local time, or if Task Manager stays open for more than an hour overnight. The script reads the host's local clock with Get-Date, not UTC.

The result is that an admin who opens Task Manager to find out why the CPU is maxed will see normal CPU usage. Huntress's "AI-assisted" label is its own inference from the code comments, not a confirmed attribution.

A vulnerable kernel driver​

Attackers also loaded a vulnerable kernel driver (WinRing0x64.sys) for hardware-level mining access. Huntress says this happened in one incident, with the driver downloaded through Windows' built-in certutil.exe. Attackers usually bring vulnerable drivers to switch off endpoint security tools. Here Huntress assessed that the driver was likely there to give the miner low-level hardware access. That is an assessment, not a confirmed motive.

Section summary: The intrusions combined webshells for return access, an Edge-themed service to keep the miner running, a script that hides the miner from Task Manager, and in one case a kernel driver.

What admins should do now​

Until Ahsay ships a fix that has been confirmed to work, these steps follow Huntress's guidance:

1. Take the console off the open internet. The exploit targets the externally reachable web app. Limit access to the AhsayCBS management interface to trusted IP addresses, or require VPN access.
2. Don't assume 10.3.4 is safe. Huntress says every version through 10.3.4 is affected. Check the version you run, but don't treat any version as clearing you.
3. Look for signs of compromise. In particular:
   • Unexpected child processes of cbssvcX64.exe or cbssvcX86.exe
   • .jsp files you don't recognize in the AhsayCBS web application directory
   • A service called MicrosoftEdgeUpdateSvc, or Edge-named binaries running from Temp folders
   • Outbound connections on port 8029 or to the mining pool hosts listed above
   • curl or certutil command lines fetching files from the Alibaba Cloud OSS host Huntress identified
4. If you find indicators, rebuild the host. Huntress recommends a full re-image from a trusted backup because attackers may have planted other backdoors. Removing the miner and leaving a hidden webshell does not fix anything.
5. Use the published detections. Huntress released file hashes and four campaign-specific Sigma rules. They cover unexpected child processes of the AhsayCBS service, fake Edge binaries (original filename msedge_exe or the --daemonized flag), PowerShell that stops and starts a service based on Task Manager's state, and command lines that pair WinRing0 with a URL. The Task Manager rule matches the behavior rather than the service name, so renaming the service won't get around it.

Treat the published names as clues, not proof. A file named msedge.exe is usually the real browser, and some legitimate hardware-monitoring tools include WinRing0 in their installers. What gives an indicator weight is context: where the file sits, what launched it and what it connects to.

Section summary: Restrict access, hunt for the indicators, and rebuild any host that shows them.

Why MSPs should take this seriously​

MSPs depend on backup consoles to recover from incidents, and a single console often manages backups for many customers. A SYSTEM-level compromise of that console is serious even when the visible payload is only a cryptominer. The webshells give the attacker a way back in.

There's also a pattern here: management and backup platforms keep turning up as targets for exploitation. It's reasonable to ask why a backup administration console was reachable from the internet at all. Some deployments have good reasons for remote access, but those cases should go through a VPN or an IP allowlist.

Two caveats keep this in proportion. Huntress's view comes from its own customer base, so "five organizations" is what it saw, not the full picture. And nothing published so far says who is behind the attacks or how many AhsayCBS servers are exposed. Ahsay had not commented publicly when this was written.

For now: restrict access to the AhsayCBS console, check your hosts, rebuild any that show indicators, and wait for Ahsay to release a confirmed fix.