AhsayCBS CVE-2026-105134: Hunt the Backup Console Before You Call the Hotfix Done

The miner installed on a compromised AhsayCBS server watches for Task Manager. Open it and a PowerShell script stops the mining service; close it and the service starts again. After 18:00 local time the script kills Task Manager outright. Huntress found that logic running on backup consoles at five organisations, next to JSP webshells and an XMRig binary renamed edge.exe, and published the write-up on October 8.

The dates around that finding are the reason this is worth your morning. Both CVEs were published on October 4 with exploit code already public. Huntress saw the first exploitation at 23:20 UTC on October 7. Ahsay shipped the working hotfix on October 12. CISA added both to the Known Exploited Vulnerabilities catalogue on October 14 with a remediation date of October 17. Anyone who ran this product on a public address spent at least five days reachable by a published exploit, and the patch you install today says nothing about what happened during them.

Who owns this, and who can close the tab

AhsayCBS is the server half of Ahsay's backup suite: the console that managed service providers, system integrators and hosting companies run to back up their customers' endpoints. The two CVEs are scoped to that console, not to the agent software on protected machines. If you do not operate AhsayCBS, and your provider does not either, you can stop reading here and lose nothing.

Two groups should keep going. The first runs the console, directly or through a partner, and needs the build numbers and the hunt below today. The second runs some other backup platform with a web management interface, and should take the pattern rather than the indicators. A backup console holds credentials for every machine it protects, decides where restore data goes, and almost always runs with the highest privilege available on its host. Attackers reached SYSTEM on these servers without a password, and the payload they chose was a cryptominer. The next crew to use the same chain will have a better idea.

If your backups are somebody else's job, there is exactly one question to send them this week: which backup console do you run for us, what build is it on, and is its web interface reachable from the internet. A provider who cannot answer in a day has told you something useful.

The chain, and the build that actually closes it

Two bugs, one parameter. CVE-2026-105133 sits in the checkSysPwd function of com/ahsay/obs/api/ApiStructsAction.java. Manipulating the random argument produces improper authentication, which NVD scores at CVSS 4.0 5.5. On its own it reads like a medium-severity curiosity.

CVE-2026-105134 is what it unlocks. The same random argument, this time against /rps/api/json/UpdateReceivers.do in the Replication Receiver component, gives OS command injection: CVSS 4.0 9.3, CVSS 3.1 10.0, CWE-77 and CWE-78. Chain the two and an unauthenticated request over the network executes commands as NT AUTHORITY\SYSTEM. CISA's KEV entry for the command injection carries the forensic triage flag, which puts evidence collection on the same clock as the patch.

Now the part that costs people a weekend. Ahsay's October 12 advisory states that its previous patches, v9.15.2.59 and v10.3.4.0, "did not fully address" either vulnerability. The builds that do:

• AhsayCBS v10, including 10.3.4.0 - hotfix v10.3.4.45.
• AhsayCBS v7, v8 and v9 - hotfix v9.15.2.70.
• Both come from the partner portal, and the vendor asks you to reboot the server after applying either one.

The NVD records for both CVEs still say that upgrading to version 10.3.4 resolves the issue. That sentence was true when the entries were written and is wrong now. Read the build number off the running server and compare it to the vendor advisory, not to the CVE page.

What to look for on the host

Huntress documented the post-exploitation kit in enough detail to hunt with. The attackers pulled their payloads over certutil.exe from an Alibaba Cloud OSS bucket, installed a modified copy of the Non-Sucking Service Manager as msedge.exe to keep the miner alive, registered it as a service called MicrosoftEdgeUpdateSvc, and dropped the vulnerable WinRing0 kernel driver for mining performance. Run this on any AhsayCBS host before you call the upgrade finished.

# Run as administrator on the AhsayCBS server. Read-only; it changes nothing.
$hits = @()

# 1. The persistence service, named to sit next to the real Edge updater.
Get-CimInstance Win32_Service |
  Where-Object { $_.Name -match 'MicrosoftEdgeUpdateSvc' -or $_.PathName -match 'msedge\.exe' } |
  ForEach-Object { $hits += "SERVICE: $($_.Name) -> $($_.PathName)" }

# 2. Dropped files, by name and by hash. Hashes are from the Huntress report.
$known = @{
  '05F69AE6B2B89C1C4DCF836BFF032232F11BF0109F2B498E2345045D06139034' = 'msedge.exe (modified NSSM)'
  '4DCB0202FE8B2D4D7B183764E38184CD6ED50132786CC7E7D1F7F4BCE1DD6F3D' = 'edge.exe (XMRig)'
  '481728A7C9C4C02BE07051D9C1958D902EA6397EBB8952AB83944818E3D25D21' = 'Taskgmr.ps1'
}
Get-ChildItem C:\Users,C:\Windows\Temp -Recurse -File -Force -ErrorAction SilentlyContinue `
    -Include Taskgmr.ps1,edge.exe,msedge.exe,WinRing0x64.sys |
  ForEach-Object {
    $h = (Get-FileHash $_.FullName -Algorithm SHA256).Hash
    $hits += "FILE: $($_.FullName)  $($_.LastWriteTime)  $h  $($known[$h])"
  }

# 3. Children of the AhsayCBS service process. Sysmon 1, or 4688 with command
#    line auditing on. cmd, powershell and certutil are the ones that matter.
Get-WinEvent -FilterHashtable @{
    LogName='Microsoft-Windows-Sysmon/Operational'; Id=1
    StartTime=(Get-Date).AddDays(-21)
  } -ErrorAction SilentlyContinue |
  Where-Object { $_.Message -match 'ParentImage:.*cbssvcX(64|86)\.exe' } |
  ForEach-Object { $hits += "CHILD: $($_.TimeCreated) $(($_.Message -split "`n" | Select-String 'CommandLine:'))" }

# 4. Web content written since the exploit went public on October 4.
Get-ChildItem 'C:\Program Files\AhsayCBS' -Recurse -File -Force -ErrorAction SilentlyContinue `
    -Include *.jsp,*.jspx,*.war |
  Where-Object { $_.LastWriteTime -gt [datetime]'2026-10-01' } |
  ForEach-Object { $hits += "WEB: $($_.FullName)  $($_.LastWriteTime)" }

if ($hits) { $hits | Tee-Object -FilePath .\ahsay-triage.txt } else { 'No indicators found.' }

Reading the output

Section 1 is the clearest signal. Windows ships the Edge updater as edgeupdate and MicrosoftEdgeUpdateTaskMachine; a service literally named MicrosoftEdgeUpdateSvc pointing at msedge.exe in a temp path is the attacker's. Section 3 is the one that catches a quieter intruder: cbssvcX64.exe is a Java backup service and has no reason to spawn cmd.exe, powershell.exe or certutil.exe. If Sysmon is not installed on this host, turn on command-line process auditing before you reboot into the hotfix, because the reboot is also the last chance to lose volatile evidence. Section 4 flags files, not verdicts; compare anything it returns against a known-good install of the same build.

Huntress also published four Sigma rules with the report, covering unexpected children of the CBS service, Edge-named binaries carrying the --daemonized flag, Task-Manager-aware service control, and WinRing0 downloads on a command line. Those belong in your detection pipeline whether or not you run this product, because three of the four describe behaviour and not this campaign.

The traffic side

Host artefacts get deleted. Flow records usually survive longer, and in this campaign they are distinctive: mining pools do not look like backup traffic.

# A. Live sessions to the mining pool port seen in this campaign.
Get-NetTCPConnection -State Established |
  Where-Object { $_.RemotePort -eq 8029 } |
  Select-Object RemoteAddress, RemotePort, OwningProcess,
    @{n='Process';e={(Get-Process -Id $_.OwningProcess).ProcessName}}

# B. Resolver / proxy log search, last 30 days. Defanged on purpose.
#    xmr.kryptex[.]network          - pool
#    imagefiles-backup.oss-ap-southeast-7.aliyuncs[.]com  - payload host
grep -iE 'kryptex\.network|imagefiles-backup\.oss-ap-southeast-7' /var/log/dns/*.log

# C. Firewall log search for the source addresses Huntress observed.
grep -E '177\.4\.12\.11|38\.60\.252\.110|107\.191\.47\.199|185\.220\.236\.49|104\.234\.26\.10|123\.202\.208\.37' \
  /var/log/firewall/*.log

Check B before A. The payload host is an Alibaba Cloud OSS bucket serving from /javas/Office/win/, and a backup server resolving it is hard to explain innocently. A hit on C without a hit on A or B means somebody knocked and the exploit did not land, which is still worth recording in the ticket.

One more signal costs nothing to check, and it is the reason the attackers wrote the Task Manager logic in the first place. Mining burns CPU. A backup console is busy during its backup windows and close to idle the rest of the time, which makes its utilisation graph one of the most readable on the network. Pull the last fortnight from whatever already monitors that host and look for sustained load outside the schedule. Where the graph goes flat at the top for hours at a time, you have both a detection and a timestamp for when the intrusion started.

A compromised backup console is not a host you clean

Huntress recommends a full re-image from trusted media for any host showing these indicators, on the grounds that secondary backdoors were hidden on the systems they examined. I would hold that line harder for this product class than for a web server, for three reasons specific to backup infrastructure.

The credentials

The console authenticates to every machine it protects and to wherever the data lands. Code execution as SYSTEM on that host means every one of those secrets is now a candidate for rotation: agent enrolment keys, storage account credentials, the console's own administrator passwords, and any directory account the service runs under.

The replication receivers

Huntress observed the attackers configuring a malicious replication receiver. Replication is the feature that copies backup data to another destination, so an attacker-controlled receiver is an exfiltration channel built out of the product's own functionality and nothing else. Export the receiver list, compare it against the destinations you can name, and delete what you cannot.

The restores

A backup platform earns its budget on the day you restore from it. Once SYSTEM on the console is in question, so is every restore point written after October 4 and every restore target the console can reach. Pick two recoveries that matter, run them into an isolated network, and verify the result before you trust the platform again.

Re-image the backup server before you trust the next restore

Three moves, in this order, for anyone running this console. Get to v10.3.4.45 or v9.15.2.70 and reboot, because the earlier patches left the door open. Take the management interface off the public internet and put it behind a VPN or an allowlist, which Huntress recommended while no fix existed and which stays the right configuration now that one does. Then run the hunt above, and if anything comes back, rebuild the host and rotate the credentials rather than deleting files and hoping.

The wider lesson costs nothing to apply this week. Pull an inventory of every management console your organisation exposes to the internet - backup, RMM, hypervisor, NAS - and ask which of them you would notice someone logging into. Build that list from outside rather than from the firewall rules, because the rules describe what somebody intended and a scan of your own ranges describes what is actually answering. Most small environments find two or three consoles nobody meant to publish, usually behind a forwarding rule added for a weekend of remote work several years ago.

The answer on the backup console matters most, because it is the one your recovery plan assumes is still trustworthy.