CVE-2026-105134: AhsayCBS Command Injection
Active exploitation confirmed in the wild. CISA added this to the KEV catalog on 2026-10-14. Federal agencies must patch by 2026-10-17.
TL;DR - CVE-2026-105134 is a CVSS 10.0 remotely exploitable OS-command-injection flaw in AhsayCBS Replication Receiver. - Affected v10 systems should be upgraded to AhsayCBS 10.3.4.45; v9 systems should use 9.15.2.70. - CISA lists the CVE in KEV, confirming exploitation in the wild. Patch immediately and investigate exposed systems.
CVE-2026-105134 is a critical AhsayCBS vulnerability affecting the Replication Receiver component and its /rps/api/json/UpdateReceivers.do endpoint. The flaw permits OS command injection and has a CVSS base score of 10.0. AhsayCBS administrators should patch exposed systems, restrict network access, and investigate for compromise rather than treating the issue as a routine update.
Are You Affected?
CVE-2026-105134 affects Ahsay AhsayCBS, specifically the Replication Receiver component and its /rps/api/json/UpdateReceivers.do endpoint. NVD identifies AhsayCBS versions 10.3.0, 10.3.1, and 10.3.2 as affected, with 10.3.4 listed as the resolving version. Ahsay’s subsequent remediation guidance is more specific: 10.3.4.45 is the required hotfix for affected v10 deployments.
| Field | Assessment |
|---|---|
| CVE ID | CVE-2026-105134 |
| CVSS | 10.0 |
| Attack vector | Network / remotely exploitable |
| Authentication required | Not established in the available record; treat exposed systems as at risk |
| Vulnerable component | Replication Receiver |
| Affected input | random parameter |
| Patch available | Yes |
| CISA KEV | Yes, added 2026-10-14 |
| Known ransomware use | Unknown |
| Product or deployment | Affected versions and remediation |
|---|---|
| AhsayCBS v10 | NVD lists 10.3.0, 10.3.1, and 10.3.2 as affected. Ahsay’s current guidance calls for 10.3.4.45. |
| AhsayCBS v9 | Ahsay identifies 9.15.2.70 as the applicable hotfix. |
| AhsayCBS v7 and v8 | Follow Ahsay’s supported upgrade path to the vendor-recommended remediation level. Do not assume an older unsupported release is safe. |
| AhsayCBS 10.3.4.0 or earlier hotfix builds | Do not rely on these builds if Ahsay’s current guidance requires 10.3.4.45; the vendor indicates earlier builds may not fully address the broader attack chain. |
The initial NVD record describes the affected range as AhsayCBS “up to 10.3.2,” but the vendor’s later guidance should take precedence for operational remediation. Inventory exact build numbers rather than recording only the major version. Identify systems behind reverse proxies, managed-service deployments, or shared backup infrastructure as well. An apparently private replication interface may still be reachable through an exposed management path.
The Fix, If You’re in a Hurry
For AhsayCBS v10, upgrade to 10.3.4.45 using Ahsay’s current hotfix guidance. For v9, apply 9.15.2.70. NVD lists 10.3.4 as the resolving version, but that entry does not replace Ahsay’s later and more specific build guidance. After installation, reboot the server as directed by Ahsay and verify the installed build from the product interface or installation metadata.
If an immediate upgrade is impossible, remove the vulnerable service from direct internet exposure. Restrict access to trusted administrative or replication networks using firewalls, security groups, VPN access, or an allowlist. This reduces exposure temporarily; it does not replace the vendor hotfix. CISA’s KEV listing also advises discontinuing use if effective mitigations are unavailable.
Analyst’s Take: The combination of a CVSS 10.0 rating, CISA KEV status, and public exploit material makes exposure reduction and patch verification urgent. Treat a reachable instance as an incident-review candidate, not merely as a system awaiting its next maintenance window.
Technical Notes
Use your organization’s approved Ahsay distribution and change process. Ahsay hotfixes may require access to the partner portal, so obtain the package from the vendor rather than downloading an unverified copy. A generic operational sequence is:
1. Record the current AhsayCBS version and build.
2. Export or back up relevant configuration and recovery data.
3. Download the vendor-provided v10.3.4.45 or v9.15.2.70 hotfix.
4. Stop or pause dependent AhsayCBS services as directed by Ahsay.
5. Install the hotfix using the vendor procedure.
6. Reboot the server if required.
7. Confirm the resulting build number.
8. Re-enable only the network access required for operations.
Before patching a system suspected of compromise, preserve relevant logs and forensic evidence. Do not delete unexpected JSP files, administrator accounts, replication receivers, scheduled tasks, or other artifacts solely to make the system appear clean. Credential rotation, token replacement, and a rebuild may be necessary after evidence collection.
How This Vulnerability Works
CVE-2026-105134 is an OS-command-injection vulnerability in the Replication Receiver functionality. NVD identifies the affected endpoint as /rps/api/json/UpdateReceivers.do and the manipulated parameter as random. An attacker who can reach the service may provide crafted input that is processed in an operating-system command-execution path.
The public records do not disclose the vulnerable source code or establish the precise coding error. It is therefore not possible to state with confidence whether the defect is caused by insufficient input validation, unsafe command construction, shell interpretation, or another implementation issue. The security consequence is nevertheless clear: attacker-controlled data can reach command execution on the AhsayCBS host.
That uncertainty matters during incident response. A request does not need to resemble a simple shell command to be suspicious. Attackers may use encoding, separators, alternate syntax, or application-specific request formats. Review the complete request, response, authentication context, and process activity rather than relying on a single literal string.
Technical Notes
The primary endpoint and parameter to investigate are:
/rps/api/json/UpdateReceivers.do
random=<request value>
Do not test command-injection payloads against a production server. If validation is required, use an isolated, disposable system with vendor authorization and a non-destructive test plan. The supplied records do not provide a validated exploit string, so creating one from assumptions could cause unnecessary impact.
Severity, Explained
CVE-2026-105134 has a CVSS base score of 10.0, the maximum severity rating. The available research identifies it as remotely exploitable and capable of operating-system command execution, which explains the critical risk to confidentiality, integrity, and availability. A successful compromise could allow an attacker to alter backup infrastructure, access stored data or credentials, deploy additional tooling, create persistence, or disrupt recovery operations.
The exact CVSS vector string was not available in the supplied NVD retrieval. Consequently, the precise values for attack complexity, privileges required, user interaction, scope, and individual impact components should be verified directly in the NVD record before formal compliance reporting. The authentication requirement is also not established in the available material; organizations should not assume that authentication protects an exposed instance unless the vendor’s advisory and local configuration confirm it.
CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on 2026-10-14, with a remediation due date of 2026-10-17. The due date has passed relative to this article’s publication date, so federal agencies and organizations following KEV-based prioritization should treat remediation as overdue.
Is It Being Exploited?
Yes. CVE-2026-105134 is listed in CISA KEV, which means exploitation in the wild has been confirmed for CISA’s catalog purposes. NVD also states that an exploit has been published and may be used. Ahsay reportedly began receiving partner reports of unauthorized access affecting AhsayCBS environments on 2026-10-09, released the v10.3.4.45 hotfix on 2026-10-10, and published follow-up guidance on identifying possible compromise.
The available information does not establish known ransomware-campaign use. CISA’s ransomware field for this entry is Unknown. That does not make the vulnerability low risk; it means known ransomware use has not been established in the supplied record. Public exploit material also appears to exist, including a GitHub result associated with the DevGreick account, but the repository’s exploit mechanics and authority were not independently validated.
Organizations with internet-facing or otherwise reachable AhsayCBS systems should assume they may have been targeted. Prioritize systems that remained on vulnerable builds after the reported activity began, and investigate before simply applying the update and closing the ticket. For broader response planning, review guidance on how ransomware spreads, even though known ransomware use has not been confirmed for this vulnerability.
Detecting It in Your Environment
Start by inventorying every AhsayCBS deployment and recording its exact build, internet exposure, reverse-proxy path, and replication configuration. Review web access logs, application logs, Windows process creation telemetry, Linux audit records where applicable, endpoint detection alerts, and firewall data. The most valuable correlation is a request to the vulnerable endpoint followed by an unusual child process, file write, account change, or outbound connection from the AhsayCBS host.
Investigate unexpected JSP files under the AhsayCBS %CBS%\\webapps directory, unauthorized replication receivers, newly created AhsayCBS administrator accounts, and recently modified scheduled tasks or services. These are investigation leads, not proof that every such artifact is malicious. Because unauthorized accounts can expand access across backup infrastructure, review account ownership and permissions using an identity and access management guide. Secondary reporting also mentions Taskgmr.ps1, edge.exe, msedge.exe, TCP port 8029, and several domains. Validate those indicators independently before blocking or attributing activity.
For endpoint visibility on supported systems, an EDR platform can help correlate web requests with process creation and file changes. Use your organization’s approved security tooling and validate any vendor or product recommendation against your environment before deployment.
Technical Notes
A web-server or reverse-proxy log search should begin with the vulnerable path and parameter:
grep -R -Ei \\
'(/rps/api/json/UpdateReceivers\\.do|(^|[?&])random=)' \\
/var/log/nginx /var/log/apache2 2>/dev/null
For Windows-hosted deployments, search the relevant IIS or Ahsay access-log directory with PowerShell:
Get-ChildItem -Path "C:\\inetpub\\logs\\LogFiles","C:\\AhsayCBS" `
-Recurse -File -ErrorAction SilentlyContinue |
Select-String -Pattern 'UpdateReceivers\\.do','random='
Adapt the paths to the actual installation. A useful SIEM correlation is:
HTTP request path contains "/rps/api/json/UpdateReceivers.do"
AND request query/body contains "random="
FOLLOWED BY
process creation, web-shell/JSP creation, administrator-account change,
replication-receiver change, or unexpected outbound network connection
within 15 minutes
Review process telemetry for web-server or AhsayCBS processes spawning shells, scripting engines, archive tools, download utilities, or credential-access tools. Compare the %CBS%\\webapps directory against a known-good baseline and examine file timestamps, hashes, owner accounts, and creation events. Treat the following as leads requiring validation rather than definitive indicators:
imagefiles-backup.oss-ap-southeast-7.aliyuncs[.]com
Taskgmr.ps1
edge.exe
msedge.exe
xmr.kryptex[.]network
TCP/8029
If compromise is suspected, isolate the host while preserving evidence, capture volatile and disk data according to your incident-response plan, rotate credentials from a clean system, and assess whether backup repositories or downstream systems were accessed.
Incident-Response Priorities
If logs or endpoint telemetry indicate exploitation, treat the AhsayCBS host as potentially compromised until the investigation establishes otherwise.
- Contain exposure. Restrict access to trusted networks or isolate the host while maintaining the evidence needed for investigation.
- Preserve evidence. Export web, application, authentication, firewall, process, and endpoint logs before retention policies overwrite them.
- Assess persistence. Check JSP files, scheduled tasks, services, administrator accounts, replication receivers, startup locations, and unexpected binaries.
- Rotate credentials. Change AhsayCBS, operating-system, database, cloud, backup, and service-account credentials from a clean administrative system.
- Review downstream access. Determine whether backup repositories, protected clients, management systems, or other network segments were accessed.
- Rebuild when appropriate. A clean rebuild may be safer than attempting to remove unknown attacker changes from a system that handled backup data and credentials.
- Validate recovery. Confirm that backup sets, recovery accounts, and restoration procedures remain trustworthy before declaring the incident closed.
Do not connect a potentially compromised backup server to production systems simply to test whether it appears functional. Perform validation in a controlled environment and document the evidence supporting the recovery decision.
References and Further Reading
The primary vulnerability record is the NVD entry for CVE-2026-105134. It documents the command-injection condition, affected AhsayCBS versions identified in the initial record, the CVSS 10.0 score, and the statement that exploit material has been published.
Ahsay’s AhsayCBS v10.3.4 release notes, vulnerability status update, and security alert for CVE-2026-105133 and CVE-2026-105134 should be treated as the authoritative sources for supported upgrade paths and current hotfix builds.
Security teams should also consult CISA’s Known Exploited Vulnerabilities catalog and applicable CISA patching and forensic-triage guidance. The reported GitHub material associated with DevGreick may provide additional research context, but it was not independently validated in the supplied evidence and should not be treated as an authoritative exploit source.
Because the supplied research did not include a current EPSS percentile or a validated social-media count, the frontmatter values use 0.0 and 0 as unavailable-data placeholders. They should be replaced with current, source-verified metrics if the publishing workflow maintains those fields.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.