Table of contents
16
Read this in 30 seconds: CVE-2026-105134 is a perfect-10.0, unauthenticated command injection in Ahsay’s AhsayCBS backup server, chainable with the authentication bypass CVE-2026-105133, and Ahsay’s own announcements page shows the fix failed twice before a working hotfix shipped. CISA added both to the KEV catalog on October 14, 2026, due October 17, with forensic triage required on the command injection.
- The fix was silent, then it failed, then it failed again. Ahsay’s own v10.3.4.0 release notes (August 4, 2026) never mentioned a security fix. Ahsay only confirmed it addressed these CVEs on October 9, after “inquiries from various sources,” then admitted the next day that v10.3.4.0 “did not fully address” the vulnerabilities, then admitted again on October 12 that the first hotfix also fell short.
- A perfect severity score, confirmed exploited. NVD scores CVE-2026-105134 at 10.0, the maximum possible, and states directly that “the exploit has been published and may be used.”
- Real victims, not a theoretical risk. Ahsay’s own incident timeline says it “began receiving reports from partners regarding unauthorized access incidents affecting their AhsayCBS server environments” starting October 9.
- Ahsay’s own recovery advice is a full rebuild, not a patch. For any server showing compromise indicators, Ahsay recommends reinstalling the OS entirely rather than trusting a patched-in-place system.
- The target is backup infrastructure itself. AhsayCBS is what MSPs and their customers rely on to recover from an incident, which makes compromising it first a well-understood precursor to ransomware deployment.
A backup server’s entire job is to be the thing you can trust after everything else is compromised, which is exactly what CVE-2026-105134 and its partner bug put at risk.
AhsayCBS is Ahsay’s Cloud Backup Suite, the server MSPs run to back up their customers’ data. CVE-2026-105134 lets an unauthenticated remote attacker inject operating system commands through a single manipulated parameter, and it chains with CVE-2026-105133, an authentication bypass in the same product. Both carry a public exploit, confirmed real-world exploitation, and a patch history that took Ahsay three separate releases to actually close.
This article covers both CVEs as Ahsay and NVD describe them, the full patch timeline reconstructed directly from Ahsay’s own announcements page, the compromise indicators Ahsay itself published, and why the recommended fix for an already-compromised server is a full rebuild, not an update.
A backup server sits in a unique position of trust. It holds credentials and access to every system it backs up, and when ransomware operators plan an attack, disabling or corrupting backups first is a well-documented step, precisely because it removes the recovery option before the real damage starts.
AhsayCBS is used heavily by managed service providers, which means a single compromised instance can be the pivot point into every client environment that server backs up. That is the scenario CVE-2026-105134 and CVE-2026-105133 make possible with no authentication required at all.
NVD’s record for CVE-2026-105134 describes it precisely: a flaw in “the file /rps/api/json/UpdateReceivers.do of the component Replication Receiver. Executing a manipulation of the argument random can lead to os command injection.” It adds, directly: “The exploit has been published and may be used.”
CVE-2026-105133 sits in a different component: “the function checkSysPwd of the file com/ahsay/obs/api/ApiStructsAction.java… Performing a manipulation of the argument random results in improper authentication.” Same pattern, a manipulated random parameter, different endpoint, different impact.
| CVE-2026-105134 | CVE-2026-105133 | |
|---|---|---|
| Weakness | CWE-77/CWE-78, OS command injection | CWE-287, improper authentication |
| CVSS 3.1 (NVD) | 10.0, the maximum possible score | 7.3 |
| Component | Replication Receiver, UpdateReceivers.do | API component, checkSysPwd |
| Authentication required | None | None |
| Exploit status | Published, per NVD | Published, per NVD |
| CISA forensic triage | Yes | No |
CISA’s own KEV catalog entry for CVE-2026-105134 states plainly that “this vulnerability can be chained with CVE-2026-105133,” which is exactly the combination you’d expect: bypass authentication with one bug, then execute commands with the other.
This is the part of the story that makes CVE-2026-105134 more than a routine critical bug. We read every entry on Ahsay’s own announcements page to build this timeline ourselves, rather than repeat a secondary summary.
| Date | What happened |
|---|---|
| Aug 4, 2026 | Ahsay releases AhsayCBS v10.3.4.0. The public release notes describe new Hyper-V and macOS support, with no mention of a security fix. |
| Oct 4, 2026 | CVE-2026-105133 and CVE-2026-105134 are published via VulDB, a third-party vulnerability database, referencing Ahsay’s own v10.3.4 release notes as the fix. |
| Oct 9, 2026 | Ahsay posts a “Clarification” notice, confirming that v10.3.4.0 (released two months earlier) did in fact address both CVEs, after receiving “inquiries from various sources.” The same notice warns that upgrading does not undo damage from a compromise that happened before the upgrade. Separately, Ahsay says it began receiving partner reports of actual unauthorized access incidents around this date. |
| Oct 10, 2026 | Ahsay admits v10.3.4.0 “did not fully address” the vulnerabilities and releases hotfix v10.3.4.45 for the v10 branch. |
| Oct 12, 2026 | Ahsay admits the v9 patch, v9.15.2.59, also fell short, and releases v9.15.2.70, which it says “fully addresses” both CVEs. Partners on v7 or v8 are told to first upgrade to v9.15.0.0, then apply the same hotfix. |
| Oct 13, 2026 | Ahsay publishes compromise-indicator guidance and a recommended full-rebuild recovery procedure. |
| Oct 14, 2026 | CISA adds both CVEs to the KEV catalog, with forensic triage required on CVE-2026-105134, due Oct 17, 2026. |
Read that sequence again. A fix that shipped silently in a feature release in August turned out to be incomplete when examined in October, the first hotfix meant to close the gap also fell short, and only the second hotfix, five days and two tries later, actually closed it on Ahsay’s own account.
Ahsay’s October 13 guidance gives specific, concrete signs of compromise, not generic advice. If any of the following are present on an AhsayCBS server, Ahsay recommends treating it as compromised:
ahsay_ts, ahsay_t8, ahsay_t9, ahsay_t20, ahsay_t21, srv, user, or opt, typically all created the same day..jsp files in the %CBS%\webapps folder, Ahsay’s own example is 75bc584d292933ad.jsp, or folders with short, randomized lowercase alphanumeric names like xtj7iu, kje74x, or 103y9r.# Illustrative: a quick first pass for the exact folder-name pattern
# Ahsay published, run from the AhsayCBS server's drive root.
for d in ahsay_ts ahsay_t8 ahsay_t9 ahsay_t20 ahsay_t21 srv user opt; do
[ -d "/$d" ] && echo "FOUND possible IOC directory: /$d"
doneAhsay does not recommend simply patching a server that shows these signs. Its own guidance calls for a full rebuild:
Ahsay’s own framing is direct: this is “to ensure that your AhsayCBS backup server is completely free from any issues resulting from these security vulnerabilities,” which is a stronger standard than “the hole is patched now.”
We’re flagging this explicitly because it’s a reusable lesson, not just specific to Ahsay. A security fix shipped inside a routine feature release, with no advisory, no CVE reference, and no changelog entry calling it out as security-relevant, gives defenders no signal to prioritize the update. Ahsay’s own v10.3.4.0 release notes read like a normal feature update. The actual security relevance only became public two months later, after active exploitation had already started.
If you run software with a pattern of feature-release version numbers (not dedicated “security update” releases), treat every release as a potential silent security fix and apply it on a shorter cycle than a pure feature-adoption decision would otherwise justify.
So yeah, here’s the part where we talk about our own angle, clearly marked as that.
What stands out about this case is the three-attempt patch cycle and the confirmed real-world intrusions that followed it. Our AI VAPT services include verifying that a vendor’s claimed fix actually closes the hole it claims to, rather than trusting a changelog entry, which is precisely where Ahsay’s own first two patches fell short by its own admission.
A penetration test report documents what was tested. It does not certify that a backup server is clean after a suspected compromise, and it does not replace Ahsay’s own rebuild guidance if your server shows any of the indicators above. XHack does not store your data, and your session data stays on your own computer.
CVE-2026-105134 is a critical, unauthenticated OS command injection vulnerability in Ahsay’s AhsayCBS backup server, scored 10.0, the maximum possible CVSS 3.1 score, by NVD. It affects the Replication Receiver component and can be chained with CVE-2026-105133, an authentication bypass in the same product.
Yes. NVD states the exploit has been published, and Ahsay’s own incident timeline confirms it began receiving partner reports of unauthorized access to AhsayCBS servers starting October 9, 2026, before the full fix had even shipped.
Not on the first or second try, by Ahsay’s own account. The original fix shipped silently in v10.3.4.0 on August 4, 2026. Ahsay confirmed on October 9 that this version addressed the CVEs, then admitted on October 10 that it “did not fully address” them, then admitted again on October 12 that the first hotfix for the v9 branch also fell short. The v10.3.4.45 and v9.15.2.70 hotfixes are the versions Ahsay states fully resolve both CVEs.
Check for unexplained root-level folders with names like ahsay_ts, ahsay_t8, or srv, randomly-named .jsp files in the %CBS%\webapps folder, unauthorized RPS receivers, or unauthorized Admin-level user accounts. Ahsay recommends treating a server with any of these signs as compromised and performing a full rebuild rather than just patching.
Rebuild it, per Ahsay’s own guidance. Ahsay’s recommended recovery is a full OS reinstall, a fresh AhsayCBS install with the current hotfix, and restoring configuration from an Auto Save version that predates the compromise, not simply applying the hotfix to the existing, potentially backdoored installation.
Versions up to 10.3.2 are listed as affected in the original CVE description, though Ahsay’s own announcements clarify that even v10.3.4.0 and the first v9 hotfix (v9.15.2.59) did not fully resolve the issue. The versions Ahsay states fully address both CVEs are v10.3.4.45 and v9.15.2.70.
CVE-2026-105134 is a maximum-severity, unauthenticated vulnerability in backup infrastructure, confirmed exploited, and it took Ahsay three separate releases across roughly two months to actually close, by the company’s own public timeline. The lesson for defenders isn’t just “patch this CVE.” It’s that a fix buried in a routine release note, with no security framing attached, gave nobody a reason to prioritize it until real intrusions started.
If you run AhsayCBS, check for the compromise indicators above before you patch, apply v10.3.4.45 or v9.15.2.70 depending on your branch, and treat any sign of compromise as grounds for a full rebuild, exactly as Ahsay itself recommends.
Categories
Related articles
