What the unpatched AhsayCBS zero-day changed about what my homelab exposes

Two things landed on the AhsayCBS backup platform within a few days of each other, and both matter to me even though I run none of it. The NVD published CVE-2026-105134 on October 4, 2026, an OS command injection flaw in the Replication Receiver component reachable at /rps/api/json/UpdateReceivers.do and triggered through the random argument ¹. VulDB, the CNA on the record, scored it 9.3 and listed versions 10.3.0 through 10.3.2 as affected with 10.3.4 as the fix ¹.

Huntress published the other half on October 8. Exploitation started at 23:20:15 UTC on October 7, and Huntress had seen five organizations hit by the following day ². Attackers chain CVE-2026-105133, an authentication bypass in the checkSysPwd function, with the command injection to run code as NT AUTHORITY\SYSTEM, then drop a JSP webshell into the application directory the console serves ². Huntress also contradicts the version advice on the record: it tested 10.3.4, the current release, and found it affected, so there is no fixed version to move to ². BleepingComputer asked Ahsay for its patch plans and had no answer when it published on October 9 ³.

Why the console is the target

A backup management server holds connections to backup destinations, storage systems, domain services and privileged service accounts, and Field Effect makes the case that the console carries more value to an attacker than the backup data it protects ⁴. That framing is why I read the full advisory set, version tables included. The console authenticates to everything else in the stack, so a SYSTEM-level compromise lands as a credential problem before it lands as a crypto-mining problem. The visible damage in this campaign was XMRig and a webshell, and the access underneath reaches as far as the console’s own accounts reach.

Checking my own exposure

My homelab is a Docker swarm behind a reverse proxy, and reading my own notes proves nothing about what the internet can reach. I start from the outside. From a phone on cellular, off my network, I walk the hostnames I own and look at what each one hands back: a page I meant to share, a login form, a JSON error, a protocol handshake. When a management interface answers with a login form, I stop and weigh it, and the JSON error is the one I used to wave off.

The second pass is bookkeeping. I list the ports the swarm publishes to each host, then list the names the reverse proxy serves, and I reconcile the two. One list comes from me on a Saturday months ago and the other from me now, and the gap between them is where I find surprises. I publish a port in one file and put a name in front of it in another, and nothing in the stack checks that I did both.

The third pass covers the class of endpoint this CVE lives in. The flawed component exists so another machine can hand the console its backup data, and I give service-to-service endpoints less attention than a web page because no person types that URL into a browser. I went looking for that shape on my own network: anything listening for another machine to talk to it while also answering from outside the trusted VLANs. Management ports, replication ports, agent callbacks, anything with a token in place of a login.

Moving the exposed ones behind the tunnel

The fix on my side is a configuration change. The names that answer with a console or an API go onto the VPN-only access list on my reverse proxy, and the names that serve something I share stay public. I keep that list short, because a long allow-list is a list nobody rereads. The change lives in the proxy, so I do not rebuild or restart a container to make it stick. If one of those consoles ran Windows and I found this campaign’s indicators on it, I would rebuild the host from a backup I trust and skip the cleanup step, which is what Huntress recommends for confirmed hits ³.

What the hunting looks like

The highest-signal indicator in the Huntress write-up needs no indicator list. Huntress describes a backup service process spawning children it has no business spawning and points at unexpected child processes of cbssvcX64.exe or cbssvcX86.exe ². The published indicators also cover unknown .jsp files in the console’s web directory, a Windows service named MicrosoftEdgeUpdateSvc, and Edge-named binaries running out of Temp folders ³. The same list names outbound traffic to a Monero pool on port 8029 and certutil.exe pulling files from an Alibaba Cloud bucket ². Huntress shipped four Sigma rules alongside the report ³. Even without AhsayCBS anywhere in my rack, that list shows what a compromised service looks like after someone turns a valid execution path into a foothold.

The rule I am keeping

Any interface on my homelab that can touch the rest of the stack gets a reachability answer I can point at, and I review that answer on a schedule instead of trusting my notes from setup. A network scan on a calendar entry costs me an afternoon a quarter. The alternative is trusting that the list I wrote when I deployed a service still matches the list the proxy serves today, and the AhsayCBS story is a good reminder of where that trust ends: a vendor record that said a version was fixed, researchers who tested it and found otherwise, and administrators who had already moved on to other work. My consoles stay behind the tunnel, and I write down the reason so the next review can find it.