Huntress says two AhsayCBS flaws are exploited and 10.3.4 is affected; Ahsay says 10.3.4 fixes both

The record said upgrade to 10.3.4. Huntress says 10.3.4 is affected. Ahsay says it is not.

The CVE records for CVE-2026-105133 and CVE-2026-105134, which NVD stamped at 07:16 UTC on Sunday 4 October 2026, tell defenders that upgrading AhsayCBS to 10.3.4 fixes both flaws. Ahsay had released 10.3.4 on 4 or 5 August (its announcement says 4 August and its release notes say 5 August), so the build the records name was already 60 days old (derived). Huntress says it first saw the flaws exploited at 23:20:15 UTC on 7 October, 3 days 16 hours after NVD's stamp (derived), and its update timed 6pm Eastern on 8 October says AhsayCBS 10.3.4 is also affected and that no patch is yet available. Ahsay's own notice, dated 9 October, says the opposite: both flaws were "addressed in AhsayCBS v10.3.4.0" and partners who have upgraded "are no longer affected". The safe-looking action in the record is disputed by the researcher and defended by the vendor, and nothing we could read settles it.

What this does not establish. It does not establish that 10.3.4 is vulnerable: that rests on Huntress's statement, and its post does not say whether the finding came from a lab build or from a host in the field. It does not establish that 10.3.4 is safe: Ahsay's notice says upgraded partners are not affected but not how that was checked, and it mentions neither Huntress nor any attack. It gives no count of exposed servers or of victims: Huntress's "five organizations" on 8 October were "targeted", and they come from its own customer base. It names no actor and no motive beyond a cryptominer. And a first sighting is the first time Huntress saw something, not the first time it happened. This briefing stays at defender level: it prints no indicators, requests or trigger details, and names no individual.

Two vendors with interests. Huntress sells managed detection and response, including to MSPs, so a report that MSP backup servers are under attack is also a case for its product. Ahsay sells AhsayCBS to MSPs and resellers, so a finding that its newest build is affected costs it customers, and its statement that the build is fixed is not neutral. Neither interest makes either account wrong. Each is a reason to ask for evidence, and the evidence is what is missing.

This is the same shape as earlier briefings here, a fix build that a later notice lists as affected: NetScaler's previous fix build, SonicWall's September SMA1000 fix and VeloCloud Orchestrator's July fixes. In those the vendor wrote both notices. Here the vendor says the fix works and a security firm says it does not.

Five accounts of one build, and what each leaves out

Wording in quotation marks is the source's. The CVE.org records are written by VulDB, the numbering authority, and NVD republishes them with their scores; neither is the vendor. The two secondary sources are pointers, and neither mentions Ahsay's notice.

What each source says about AhsayCBS 10.3.4, and what it does not say. Read on 9 October 2026 from the CVE.org and NVD records, Huntress, Ahsay, SecurityWeek and The Hacker News.

Source	Says about 10.3.4	Not stated
CVE records (VulDB), 4 Oct. NVD status Deferred.	"Upgrading to version 10.3.4 is able to mitigate this issue" for the first flaw and "resolve" for the second, for "AhsayCBS up to 10.3.2". Structured data: 10.3.0, 10.3.1 and 10.3.2 affected, 10.3.4 unaffected. The patch reference is Ahsay's 10.3.4 release notes.	Any test of 10.3.4. 10.3.3, which is not on Ahsay's list. A lower bound. Any correction since 4 October: none as read.
Huntress, 8 Oct, update at 6pm ET	"Ahsay 10.3.4 is also affected"; "Previous reporting indicated that 10.3.4 was not susceptible". Until a patch is available, restrict access. It has contacted Ahsay.	How it found this, which 10.3.4 build string, how many of the five organisations ran 10.3.4, or any proof.
Ahsay notice, dated 9 Oct	Both flaws "were addressed in AhsayCBS v10.3.4.0, released on 4 August 2026". Upgraded partners "are no longer affected" and are "protected against remote exploitation by unauthenticated attackers". An upgrade does not fix a server compromised earlier.	Huntress, any attack in the wild, how Ahsay checked, a time of publication, or whether older lines such as 9.x are affected.
SecurityWeek, 9 Oct 10:23 UTC (secondary)	Says NIST warned that versions up to 10.3.2 were affected (the wording is VulDB's, republished by NVD) and, citing Huntress, that 10.3.4 is also affected. Headline: "Unpatched".	Ahsay's notice. It says "at least five" where Huntress says five.
The Hacker News (secondary)	Says NVD advisories state 10.3.4 fixes both and Huntress "revealed that it's also impacted, essentially turning them to zero-days".	Ahsay's notice. "Zero-days" is the outlet's label: the flaws were public from 4 October.

Where they agree. Every account treats 10.3.2 and earlier as affected: the records say "up to 10.3.2", Ahsay says the fix is in 10.3.4 and Huntress says "through 10.3.4". So moving a server from 10.3.2 to 10.3.4 takes it from affected on every account to affected on one. Ahsay's release list, read today, ends at v10.3.4 dated 05-Aug-2026. There is no 10.3.3 and no later build to move to.

What could reconcile them, as inference and not as fact. Huntress may have tested a different build string, a configuration Ahsay did not consider, or a host that was compromised before it was upgraded: Ahsay itself says an upgrade does not repair that, and Huntress warns of "secondary backdoors". Or one of the two is wrong. The sources do not choose. Until someone publishes a version-specific test, treat 10.3.4 as unproven and the network path to the interface as the control.

The clock: 3 days 16 hours, and what was already public

NVD stamped both records at 07:16:33 UTC on 4 October. The CVE.org records, which VulDB wrote as numbering authority, were published earlier that morning: 05:15 UTC for the first flaw and 05:30 for the second. VulDB's timeline inside the records says its entry was created at 02:00 UTC on 3 October and the advisory disclosed that day. The gap to Huntress's first sighting depends on which clock you start.

Intervals to Huntress's first sighting at 23:20:15 UTC on 7 October 2026, from timestamps in the NVD and CVE.org records, Huntress and Ahsay. All derived.

Interval	Result (derived)
VulDB entry created (3 Oct, 02:00 UTC) to first sighting	4 days 21 hours 20 minutes
CVE.org publication (4 Oct, 05:15 and 05:30 UTC) to first sighting	3 days 18 hours 5 minutes (first flaw); 3 days 17 hours 50 minutes (second)
NVD stamp (4 Oct, 07:16 UTC) to first sighting	3 days 16 hours 3 minutes, or 88.06 hours
CISA data in the records, "exploitation none" (5 Oct, 15:04 UTC for the first flaw, 15:40 for the second), to first sighting	2 days 8 hours 15 minutes (first flaw); 2 days 7 hours 40 minutes (second)
First sighting to Huntress's update (8 Oct, 22:00 UTC)	22 hours 40 minutes
10.3.4 release (5 Aug per the release notes, 4 Aug per the announcement) to the records (4 Oct)	60 days, or 61

The title and the hero use the shortest, 3 days 16 hours, because it starts at the latest stamp: every other clock gives a longer gap. All of them end at a first sighting in one company's data, so the real gap to the first attack may be shorter. In UK time the sighting is 00:20 BST on Thursday 8 October.

What was already public. Both records say an exploit was out: "The exploit is now public and may be used" for the first flaw and "The exploit has been published and may be used" for the second. That is VulDB's statement. We did not look for the exploit, do not link to it and cannot say what it does. The records' vectors carry a proof-of-concept exploit-maturity value, and CISA's entry inside the records, dated 15:04 UTC on 5 October for the first flaw and 15:40 for the second, says exploitation "none" and automatable "yes", with total technical impact for the second flaw. The NCSC's guidance on responding to active exploitation says that where proof-of-concept code exists you should remediate sooner than your usual timelines. Whether the attackers used that published code is not stated.

How CISA's silence reads. The catalogue release 2026.10.08 came out at 20:09 UTC on 8 October, 20 hours 49 minutes after Huntress's first sighting and about 1 hour 51 minutes before its update (derived). It has no Ahsay entry, and the re-read at 18:32 BST on 9 October found the same version. That is not a finding. The NCSC's guidance notes that the catalogue only reports exploitation that has already occurred, and the NCSC's compressed timelines for flaws on it do not apply as written to either CVE. Rapid7's vulnerability database page for the second flaw, read the same hour, shows "In CISA KEV Catalogue: False".

A "medium" that opens the door

Scores VulDB assigned as CNA, read from NVD's API and from the CVE.org records on 9 October 2026. NVD has added no score of its own. Huntress's severity labels are in the first column.

Flaw and weakness	CVSS 3.1	CVSS 4.0, NVD and CVE.org
CVE-2026-105133. Improper authentication, CWE-287. Huntress: "medium-severity".	7.3 High. Network, low complexity, no privileges, no interaction, low impact on all three.	NVD API 5.5 Medium; CVE.org record 6.9 Medium. Same vector.
CVE-2026-105134. OS command injection, CWE-78 and CWE-77. Huntress: "critical-severity".	10.0 Critical. Same exposure, scope changed, high impact on all three.	NVD API 9.3 Critical; CVE.org record 10 Critical. Same vector.

Huntress calls the first flaw "medium" and the second "critical". The medium label matches the 4.0 score. The same record's 3.1 score, 7.3, is High, and Cyber Essentials v3.3 counts a CVSS v3 base score of 7 or above as "high risk". So under the UK's Cyber Essentials scheme the flaw labelled medium sits in the same 14-day class as the critical one. Huntress says it sees the two chained, authentication flaw first and command flaw second. The records give both flaws a vector with no privileges and no user interaction, so we cannot tell from them whether the second works alone; Huntress's own description of the second says the API "contains an authentication bypass".

The two 4.0 figures. For the same vector, CVE.org prints 6.9 and 10, and NVD's API prints 5.5 and 9.3. The vector carries a proof-of-concept exploit-maturity value, which we think accounts for the difference (inference); we did not recalculate either. The Hacker News prints 5.5 and 9.3. Huntress prints no number.

What Huntress observed, in words

Huntress's post is the only account of exploitation, and its method is its own telemetry, so everything below is its statement. Its post carries a table of indicators and a mapping to attacker techniques; this briefing reprints neither, and the behaviours below are given in words.

What Huntress states about the exploitation of AhsayCBS, and what it does not, from its post of 8 October 2026 including the update at 6pm ET. Quotations are Huntress's.

Topic	Stated by Huntress	Not stated
Exploitation	From 23:20:15 UTC on 7 October, "unauthenticated remote code execution" on exposed systems, with the two flaws chained. Code runs as the SYSTEM account.	Whether it began earlier, how many attempts, which versions were hit, whether a published exploit was used.
Victims	Five organisations "targeted" as of 8 October. Huntress is "working with potentially impacted organizations across our customer base".	How many were compromised, whether they are MSPs or MSP clients, sectors, countries, how many ran 10.3.4, the total exposed.
After access	Reconnaissance. Server-side web pages dropped in the web application directory. A Monero cryptominer disguised as a browser process, run by a service named to look like the browser updater. One use of a known vulnerable signed kernel driver to give the miner hardware access.	Any access to backup data, client credentials or other hosts, or whether anyone checked.
The script	A PowerShell script that "appears to be" AI-assisted "given the commented code". It stops the miner while Task Manager is open and closes Task Manager at 18:00 local time or after an hour open overnight.	Any test of the AI claim. It is Huntress's inference.
Actor and motive	"Threat actors". Cryptomining.	Attribution, how many actors, whether mining is the aim or a side effect.
Detection	Four Sigma rules in its threat-intel repository, one per step: an unexpected child process of the service, a disguised browser binary, a script that reacts to Task Manager, a download of the driver.	Our testing of them. Coverage of Linux installs.
Advice	Restrict management web access to trusted addresses or a VPN. If indicators are found, "re-image from a trusted backup" because attackers hid "secondary backdoors".	Whether Ahsay's own address filter covers the exposed service, and what a restriction does to client backups.

The service Huntress says to restrict is the one clients use. Huntress says the exploit "targets the externally accessible web app service on the host". Ahsay's network page says ports 80 and 443 carry "incoming backup and restore traffic and browsing the AhsayCBS web interface" and recommends exposing only those two to the public, and its replication page says replication also runs over the web ports and can go to another AhsayCBS server. A blanket block can therefore stop backups and replication. Ahsay documents an address restriction for the console, written for the case where you do not want clients using it; neither vendor says whether that setting covers the endpoint in the CVE record. Test from outside after any change.

"Patch available" is not "patch that works"

The records' reference tagged "patch" is Ahsay's 10.3.4 release notes. We read the page in full. It lists support for two Debian releases, a change to a restore-log warning and a set of bug fixes: clients connecting after an upgrade, a data-migration error, S3 destinations, Microsoft 365 and Proxmox items. It names no security fix, no CVE and nothing about authentication or replication. Ahsay's announcements show it does flag security work when it chooses: the 6 January entry for 10.1.6 lists "AhsayCBS XSS vulnerability fix". The 4 August entry for 10.3.4 lists platform support only. The first Ahsay statement we found that ties 10.3.4 to these CVEs is the notice dated 9 October, about two months after the release.

That is the pattern the NCSC describes in its update guidance: vendors "may publish advisories for some vulnerabilities" but also "silently" update others, without public acknowledgement. A defender who took 10.3.4 in August had the code and no way to know. A defender who read the record on 4 October and ticked "upgrade to 10.3.4" holds a closed ticket on a build that one vendor says is affected. Three labels did the work and none is a control: "unaffected" in the record's structured data, a "patch" reference that lists no security fix, and "fixed" in a vendor notice.

How the label spreads. The records list 10.3.0, 10.3.1 and 10.3.2 as affected and 10.3.4 as unaffected, and say nothing of 10.3.3, which Ahsay's list does not contain. Downstream pages repeat the advice: Rapid7's database page for the second flaw repeats the "Upgrading to version 10.3.4" text and the scores. A scanner or a ticket fed from data like that will mark a 10.3.4 host clean; that is our inference, and we did not test a scanner. As read at 18:32 BST, neither record has been corrected or annotated: NVD's data still says 10.3.4 is unaffected and the CVE.org records last changed on 5 October.

What "fixed" leaves out. Ahsay's notice is explicit on one point that matters in practice: an upgrade does not repair a server that was compromised first. The NCSC says the same and goes further: where an internet-facing service is being exploited in the wild, check for compromise before applying any update, "even if the exposure was brief". From either vendor's account an upgrade is not a cleanup, which is also the lesson of the briefing on Citrix's NetScaler web shells.

What this means for MSPs and their customers in the UK

Why a backup console is different. Huntress says AhsayCBS is "primarily used by managed service providers (MSPs) and system integrators" and "centralizes control of backup operations". Ahsay's help centre calls it the centralised management console for "user, backup, replication and redirection". One console, many clients. Huntress reports code execution as SYSTEM on the host. A backup server holds or reaches copies of client data, so for an MSP the question is not only whether the server is clean but what it held, who could reach it and which clients sat behind it. We found no count of UK users of AhsayCBS and make no claim about how many there are.

Shared responsibility. The NCSC's guidance on choosing an MSP (version 1.0, 24 November 2025) says contracts should "Define roles and responsibilities", "Agree on incident reporting procedures" and "Establish liability terms", and recommends patching "within 14 days of an update being released" where the fix is for a critical or high-risk flaw. Its guidance on active exploitation says organisations need critical suppliers and MSPs to be "contractually liable to rapidly mitigate vulnerabilities in internet-accessible systems, when these vulnerabilities are being exploited in the wild". For a customer whose MSP runs AhsayCBS, that is the sentence to test against the contract: who restricts the interface today, who tells you, and within what time?

What UK rules and guidance say that bears on a disputed fix, and what they do not. Sources: NCSC vulnerability management guidance v2.1 (reviewed 1 May 2026), Cyber Essentials Requirements for IT Infrastructure v3.3 (April 2026), the ICO breach guide. Dates are derived from 4 or 5 August.

Rule	What it says	What it does not say
NCSC update by default	Internet-facing services: test and roll out within 5 days of an update. For 10.3.4 that ended 9 or 10 August.	What to do when a fix is disputed, or when none exists.
Cyber Essentials v3.3	Update within 14 days of release where the vendor says "critical" or "high risk", CVSS v3 is 7 or above, or "there are no details of the level of vulnerabilities" fixed. Ahsay's 10.3.4 notes give none, so on its face 10.3.4 fell under 14 days: 18 or 19 August.	Anything for a flaw with no fixed build, or a build a researcher says is affected. Its aim is stated as known issues "for which fixes are available". A vendor-approved configuration change counts as a fix; Ahsay has not presented its address filter as one.
NCSC active exploitation	Isolate, "restrict access to only the organisation's IP range" or disable the component; investigate for compromise; rebuild as new if it cannot be investigated. Under 24, 48 or 72 hours plus incident response for flaws on CISA's catalogue.	Applies as written to neither CVE: not listed. Silent on a flaw exploited in the wild that the catalogue has not yet listed.
ICO breach guide	Report a notifiable breach within 72 hours of becoming aware. A processor must tell the controller "without undue delay"; the contract should set it out.	Whether a compromised backup server is a notifiable breach. That turns on whether personal data was accessed, altered or lost, which no source says for any victim.

The clocks run from the release of an update, not from the CVE. For 10.3.4 they ran out in August, well before the records existed, so an organisation that follows the rules to the letter could be compliant and still exposed if Huntress is right. That is not a flaw in the rules: they assume that a released fix works. Cyber Essentials also requires inbound firewall rules to be approved and documented with a business need, and an AhsayCBS service open to client backups is that kind of rule; the requirement on administrative interfaces in the same section names the firewall's own interface, not a backup server's, so it does not settle this case.

Exposure that a re-image cannot fix. Huntress's advice for a confirmed compromise is to re-image "from a trusted backup". For an MSP the backup is the thing at issue. Ahsay's replication page says replication runs over the same web ports and can go to another AhsayCBS, and lists the server's configuration folder, which its table says holds certificate files and user profiles, in the replication scope. If the server that was reachable also sent copies to a peer that was reachable, or if credentials for the peer sat on the compromised host, a "trusted backup" is a claim that needs evidence. Nothing we read says any backup data was read, altered or deleted, and nothing says anyone checked. The NCSC's MSP guidance asks where backups are stored and "who has access to it". For an MSP's clients that is the first question to answer.

What to do, in order

What is not established, and what we could not read

• Whether 10.3.4 is affected. Huntress says yes, Ahsay says no, and neither publishes evidence a reader can check.
• How many AhsayCBS servers face the internet. No source we read gives a count and we did not query internet-scan services.
• Whether Linux installs, the appliance edition, the multi-instance edition or Ahsay's hosted services are affected. Huntress's post describes Windows hosts.
• Whether versions below 10.3.0 are affected. The records say "up to 10.3.2" with no lower bound, list only three affected versions, and name 10.0.3 and 10.3.0 in the titles of their VulDB submission references. We did not open those submissions, because they may carry exploit detail.
• The VulDB entries themselves. VulDB answered with a bot check, to curl and to a browser, and we did not try to get past it. The CNA text in the CVE.org records is what we read.
• Whether an exploit is public and what it does. The records say so. We did not look and make no claim.
• Whether Ahsay has written to partners privately. Ahsay has a Partners Portal on a separate site, which we did not open.
• The time of Ahsay's notice. Its page shows a date only.
• Whether anyone has checked 10.3.4 independently. We found no such report.
• Huntress's linked reference on the vulnerable driver. It did not load when fetched and we did not read it. We did not test Huntress's detection rules, and we reprint none of its indicators.
• The date and byline of The Hacker News piece. The page loaded in a browser; the date was not captured.
• NCSC and NHS England Digital: nothing on AhsayCBS in the news page and alert list as read. Absence there says nothing about what either body knows.

The question this leaves

The record said 10.3.4. The vendor says 10.3.4. The researcher says 10.3.4 is affected, and nothing published settles which of them is right. A version number is a statement about code, and here it is a contested one.

So the question for your own process: if your ticket says AhsayCBS 10.3.4, what is your control, the version number or the fact that nobody outside can reach the console, and which of the two could you show a client this afternoon?

Key facts