CVE-2026-105134 (CVSS 10.0): AhsayCBS Backup Zero-Day Actively Exploited — No Patch Confirmed

Your backup server just became the most dangerous machine on your network. That is the blunt reality delivered by researchers at Huntress this week, after they caught threat actors actively chaining two critical zero-day vulnerabilities in AhsayCBS — one of the world’s most widely deployed cloud backup and disaster-recovery platforms — to gain SYSTEM-level code execution on corporate servers without presenting a single valid credential. Patches are not confirmed as of publication. If you run AhsayCBS, you need to act today.

What Is AhsayCBS — and Why Are Attackers Targeting It?

AhsayCBS (Ahsay Cloud Backup Suite) is the server-side management component of the Ahsay backup ecosystem, widely used by managed service providers (MSPs), enterprises, and government agencies across Asia-Pacific, Europe, and the Middle East to orchestrate, store, and replicate critical business data. Because it sits at the centre of a company’s data-protection architecture, a compromised AhsayCBS instance gives an attacker read access to every backup job it manages — including credentials, database exports, and potentially entire virtual machine images.

This is not theoretical. Threat actors have spent years systematically targeting backup and replication infrastructure, recognising that IT security teams often exempt these systems from the same zero-trust controls applied to production servers. Firewalls may expose the management interface to the internet for remote administration. The backup agent may run as SYSTEM. Alerting may be thin. The combination makes backup servers a high-value, low-visibility target.

The Vulnerability Technical Breakdown

Detail	CVE-2026-105133	CVE-2026-105134
Component	checkSysPwd authentication function	Replication Receiver API endpoint
CVSS v4 Score	6.9 (Medium)	10.0 (Critical / Maximum)
Authentication required	None	None (bypassed by first flaw)
Impact	Authentication bypass	OS command execution as SYSTEM
Last confirmed vulnerable	v10.3.4	v10.3.4

The first flaw, CVE-2026-105133, resides in AhsayCBS’s checkSysPwd function — the routine that validates the system password on certain administrative API calls. Huntress researchers found that the check can be bypassed by a remote, unauthenticated attacker, effectively unlocking the administrative interface without credentials. On its own, this is a serious but medium-severity issue. In combination with the second flaw, it becomes catastrophic.

CVE-2026-105134 lives in the Replication Receiver API, an endpoint designed to accept incoming backup replication jobs from authorised agents. With authentication stripped away by the first vulnerability, an attacker can send a maliciously crafted replication request that causes the server to execute arbitrary operating-system commands — running in the context of the SYSTEM account, the highest privilege level on Windows. There is no user interaction required. There is no MFA to bypass. There is no privilege-escalation step: the attacker lands as SYSTEM from the opening move.

Inside the Attack Chain: From HTTP Request to SYSTEM Shell

According to Huntress’s incident-response analysis, the attack flow observed in the wild follows a tight, automated sequence:

1. Reconnaissance — Attackers scan for AhsayCBS management interfaces exposed on the internet, typically on TCP port 443 or 80.
2. Authentication bypass — CVE-2026-105133 is invoked to satisfy the checkSysPwd check without a valid password.
3. Unauthenticated RCE — A crafted replication request is sent to the Replication Receiver API endpoint, triggering CVE-2026-105134 and executing attacker-controlled commands as SYSTEM.
4. Webshell deployment — A JSP-based webshell is written to the AhsayCBS web root, giving the attacker a persistent, browser-accessible command channel that survives service restarts.
5. Cryptominer installation — XMRig, a Monero cryptocurrency miner, is dropped and renamed edge.exe to blend in with legitimate Microsoft Edge processes during superficial process-list inspections.
6. Persistence via fake service — A Windows service named MicrosoftEdgeUpdateSvc is created using a modified copy of NSSM (Non-Sucking Service Manager) to ensure edge.exe restarts automatically after a reboot or process kill. The service name is deliberately chosen to mimic the legitimate Microsoft Edge Update service.

This kill chain is notable for its speed: from initial access to persistent miner, the attacker’s tooling appears fully automated. Huntress first observed this activity on 7 October 2026 and has confirmed at least five organisations impacted — a number almost certainly understated given the scale of AhsayCBS deployments globally.

Backup Servers and the Zero-Trust Blind Spot

The AhsayCBS incident illustrates a gap that I see repeatedly in enterprise environments across India: backup and DR systems are granted implicit trust that production systems no longer receive. A production application server might sit behind a next-gen firewall with microsegmentation, MFA, EDR, and privileged-access management — but the backup server that holds a copy of that application’s data is exposed directly on port 443, authenticates with a single system password, and runs as SYSTEM.

Zero-trust architecture demands that every system — including backup infrastructure — be treated as potentially hostile. That means network segmentation that restricts the AhsayCBS management interface to a dedicated, monitored management VLAN; identity and access policies that enforce MFA for backup-admin accounts; and EDR coverage on backup servers equal to what you run on domain controllers. As I have written about in detail for campus deployments, FortiGate’s segmentation policy and FortiAuthenticator’s identity-aware controls are precisely the tools that prevent backup servers from being treated as trusted peers of your most sensitive infrastructure.

If backup data is exfiltrated — as is common in third-party access abuse incidents like the Denmark CPR breach — it frequently bypasses DLP and CASB controls because the exfiltration path looks like a legitimate backup replication job. No anomaly is raised. No alert fires. The data simply walks out the door inside an encrypted backup stream.

What You Should Do Right Now

The absence of a confirmed patch means your defensive posture must rely on compensating controls until AhsayCBS releases a verified fix. Here is the prioritised checklist I recommend to every client running AhsayCBS:

• Firewall the management interface immediately. Block all inbound access to the AhsayCBS management port (typically 443 or 80) from any IP range that is not your dedicated management VLAN or VPN gateway. If you are using a FortiGate, apply an explicit deny policy on the WAN-facing interface now.
• Audit running services for MicrosoftEdgeUpdateSvc. Run sc query MicrosoftEdgeUpdateSvc on every Windows host running AhsayCBS. The legitimate Microsoft Edge Update service uses a different name and binary path; any instance pointing to NSSM or an unexpected directory is an indicator of compromise.
• Check the web root for JSP webshells. Review all .jsp files in the AhsayCBS installation directory for recently created or modified files, particularly anything containing Runtime.exec, ProcessBuilder, or Base64-encoded command strings.
• Inspect outbound network traffic from the backup server. XMRig connects to Monero mining pools over port 3333 or 443. Block or alert on outbound connections from the backup server to unknown external IPs, particularly those in miner pool CIDR ranges.
• Enable EDR on the AhsayCBS host. If your backup server lacks endpoint detection and response coverage, deploy it immediately. Treat the backup server as a Tier-0 asset — equivalent in sensitivity to a domain controller.
• Patch immediately when AhsayCBS releases a verified fix. Monitor the Ahsay official advisory page and Huntress’s original disclosure for patch confirmation. Do not rely on version 10.3.2 or 10.3.4 being safe — Huntress has confirmed both remain vulnerable.
• Isolate and forensically triage any AhsayCBS instance that has been internet-facing since 7 October 2026 or earlier, regardless of whether you see indicators of compromise. Assume breach until cleared.

Frequently Asked Questions

Which versions of AhsayCBS are vulnerable?

As of Huntress’s most recent reporting, all versions through 10.3.4 (the latest available version) are confirmed vulnerable to both CVE-2026-105133 and CVE-2026-105134. Earlier reports suggested a fix was available in 10.3.2, but Huntress’s testing showed that version remains exploitable. There is no confirmed safe version at the time of publication. Apply compensating controls immediately and monitor vendor channels for a verified patch.

Is this only a risk for internet-facing AhsayCBS deployments?

No — while internet exposure dramatically increases the attack surface, an attacker who has already gained any foothold on your internal network (via phishing, a VPN credential, or a compromised endpoint) can reach an internally-hosted AhsayCBS instance just as easily. Zero-trust network segmentation is the correct defensive posture regardless of whether the server is publicly accessible.

The attackers are deploying a cryptominer — so this is just a financial crime, right?

Do not make that assumption. Cryptomining is often the first visible payload, used by initial-access brokers to monetise access while they assess the value of the compromised network. The same SYSTEM-level access that runs a Monero miner can just as easily exfiltrate your backup archives, pivot to Active Directory, or deploy ransomware. The cryptominer is a signal, not a ceiling, on the threat actor’s intentions. Take it as seriously as you would a ransomware precursor.

Should I disable AhsayCBS entirely until a patch is available?

That depends on your operational requirements and your ability to implement compensating controls. Disabling backup replication entirely exposes you to unacceptable data-loss risk. A better path is to keep AhsayCBS running but strictly restrict network access to the management interface, deploy EDR, and increase monitoring. If your backup server is actively internet-facing and you cannot restrict that access within the next few hours, taking it offline temporarily is the lesser risk.

---

The AhsayCBS incident is a reminder that no system sits outside the threat landscape — and that the systems you trust most are often the ones that need scrutiny first. Backup infrastructure, DR replication platforms, and monitoring servers all hold the keys to your most sensitive data. Applying zero-trust principles uniformly across your stack, including the systems that protect it, is the only defensible posture.

If you want an expert assessment of your backup and DR security posture, your segmentation architecture, or your organisation’s readiness to respond to an active compromise, reach out to Sanjay Seth for a security consultation. With thirty years of enterprise network and cybersecurity experience across Indian enterprises, I help organisations close the gaps attackers exploit before those gaps make headlines.