The Safe Data Storage attack has prompted an unverified ransomware claim from AuditTeam. The UK backup and disaster recovery provider has confirmed a cyber attack, but it has not attributed the incident to AuditTeam or confirmed that data was stolen.
Safe Data Storage identified the incident on 13 October 2026. Its account confirms important details about the affected infrastructure and recovery work, while leaving the identity of the attacker, the product exploited and the consequences for customer data unresolved.
What happened in the Safe Data Storage attack
Safe Data Storage said the attack was localised to its London and replication servers. The company stated that its SAFE C2C service and what it described as its world servers continued to operate, indicating that the incident did not disrupt every part of its infrastructure.
According to the provider, attackers entered through a newly disclosed vulnerability in its backup application. Safe Data Storage said the vendor initially issued two patches that did not fully remediate the problem, allowing the attackers to gain access before a complete fix became available.
The company has not publicly identified the backup application, its vendor or the software version involved. It has also not confirmed whether the attackers encrypted systems, accessed customer backups, removed data or attempted to extort the business.
Safe Data Storage said it identified and closed the route used by the attackers. It then created a clean environment intended to protect new data while investigation and recovery work continued. This separation is particularly significant for a backup provider because restored systems must not reintroduce an attacker or contaminated components.
The company engaged a specialist cyber security firm and reported the incident to the Metropolitan Police and relevant authorities. It also contacted the Information Commissioner’s Office and the National Cyber Security Centre.
Safe Data Storage attack timeline
The technical context began before Safe Data Storage detected the intrusion. Several newly disclosed backup platform vulnerabilities were being actively exploited during the same period, although no specific product has been conclusively linked to this incident.
- 4 October 2026: CVE entries were published for two vulnerabilities affecting AhsayCBS backup software.
- 7 to 8 October 2026: Security researchers observed in-the-wild exploitation of the AhsayCBS vulnerabilities.
- 9 to 10 October 2026: Ahsay acknowledged incidents and released hotfix 10.3.4.45 for AhsayCBS version 10. Guidance was also issued for versions 7 to 9. Subsequent analysis found that earlier fixes had been incomplete.
- 13 October 2026: Safe Data Storage became aware of the cyber attack affecting its London and replication servers.
- 16 October 2026: A Safe Data Storage update for customers and partners described the backup application vulnerability, incomplete initial patches and continuing recovery work.
- 26 October 2026: Multiple ransomware trackers indexed an AuditTeam leak-site entry naming Safe Data Storage as an alleged victim.
The AuditTeam claim therefore appeared after the date on which Safe Data Storage detected the incident. That timing does not establish that the group conducted the attack, especially because the listing was not accompanied by public proof.
How the backup application vulnerability may relate
Safe Data Storage has only said that a newly disclosed flaw in its backup application was exploited. The company has not named the software, so the exact vulnerability used in the Safe Data Storage attack remains unknown.
However, the incident occurred during active exploitation of two AhsayCBS vulnerabilities. Ahsay has previously identified Safe Data Storage as a partner in published material, but that historical relationship is not evidence that AhsayCBS was the product involved in this attack.
AhsayCBS flaws exploited during the same period
CVE-2026-105133 is an improper authentication vulnerability reachable through an application programming interface function. Exploitation can allow an attacker to bypass security checks and proceed to further stages of an attack chain. Public exploit code has been reported as available.
CVE-2026-105134 is a command injection vulnerability. When chained with CVE-2026-105133, it can enable remote code execution, allowing an attacker to issue commands on a vulnerable backup server.
Field investigations reported that AhsayCBS versions up to and including some 10.3.4 builds were exposed before hotfix 10.3.4.45 mitigated the initial entry point. The vulnerability database lists affected versions up to 10.3.2, while incident response findings identified exposure in later builds prior to the hotfix. Ahsay also issued guidance for older version 7 to 9 product lines.
Observed activity against vulnerable AhsayCBS systems included reconnaissance, webshell deployment and installation of XMRig cryptocurrency miners disguised as Microsoft Edge processes. Researchers also found an AI-assisted PowerShell script designed to interfere with Task Manager. None of these behaviours has been publicly confirmed in the Safe Data Storage attack.
Why the AuditTeam ransomware claim is unverified
AuditTeam’s leak site named Safe Data Storage as a victim, and independent trackers confirmed that the listing existed on 26 October 2026. The listing did not provide sample files, screenshots or other publicly accessible material substantiating data theft, encryption or AuditTeam’s involvement.
Safe Data Storage has not attributed the incident to AuditTeam or any other threat actor. It has also not confirmed receiving a ransom demand. The evidence therefore supports two separate conclusions: a cyber attack occurred, and AuditTeam subsequently claimed the provider as a victim. It does not establish a verified connection between them.
Leak-site entries should not be treated as definitive evidence on their own. Other criminal groups have previously published fabricated victim claims, and ransomware activity counts can differ substantially between tracking services. The AuditTeam listing should remain classified as unverified unless the company, authorities or credible forensic evidence confirms attribution.
What customers and partners should do
Organisations using Safe Data Storage should follow the provider’s official updates rather than relying on the ransomware listing. They should verify that scheduled backup jobs are completing in the clean environment and confirm whether any restore procedures or connection settings have changed.
- Request confirmation that current backups and replication jobs are operating as expected.
- Review recent restore tests and identify any recovery points that may have been affected.
- Monitor for provider notifications concerning customer data, credentials or required configuration changes.
- If directly running AhsayCBS, apply the hotfix appropriate to the installed version and restrict internet access to its management interface.
- Investigate exposed backup servers for webshells, unexpected administrator activity and miner artefacts.
No Safe Data Storage-specific indicators of compromise have been published. Generic AhsayCBS indicators should therefore be used only where that product is present, not as proof of involvement in this incident.
Current status of the Safe Data Storage attack
Safe Data Storage has confirmed containment and recovery measures, including closure of the attackers’ route and construction of a clean environment. Its London and replication servers were affected, while other named services continued operating.
AuditTeam’s involvement, data theft and ransomware deployment remain unconfirmed. Until further evidence or an official attribution emerges, the leak-site claim should be monitored but not presented as an established account of the Safe Data Storage attack.
Originally reported by redpacketsecurity.com.
