Onamae Desktop Cloud breach: review the provider-to-guest boundary

Sources checked: 30 October 2026. FailSafe Research.

A hosted desktop inherits security dependencies beyond its own operating system. Its provider’s administration, access tooling and recovery process are part of the workload’s trust boundary.

Read the first notice alongside the later updates

Onamae’s 21 October notice confirmed unauthorized programs on some Desktop Cloud customer servers and identified 26,739 servers as potentially affected. It described a progressive service shutdown and told customers to change credentials used or stored there. That figure is potential server scope, not a confirmed count of individually compromised customers.

The 29 October update recounts later extortion, publication of information and cooperation with police. The initial notice’s lack of confirmed leakage should therefore not be presented as the latest finding. Follow the vendor’s current notices for affected accounts and recovery instructions. This analysis does not independently attribute the attack or determine every server’s state.

Identify which party controls each layer

For enterprise hosting, document responsibility for the guest, management console, remote access, images, snapshots and support identities. “Dedicated” should be followed by a concrete account of who can administer the resource and how that access is approved.

Where credentials are used inside the workload, map their downstream authority. Rebuilding a desktop does not revoke a credential that was copied from it. Recovery decisions need coordination between the host owner and each credential issuer.

Assess isolation without assuming the cause

In your authorized environment, test whether a tenant or support role can access another customer’s workload, retrieve a snapshot or alter an approved image. Exercise revocation and access-expiry behavior. Use synthetic artifacts and dedicated accounts; do not probe the affected provider’s production systems based on an incident report.

Evidence should identify the actual authorization decision. A product label or architecture diagram alone cannot establish whether the deployed control enforces that boundary.

What enterprise buyers can ask FailSafe to verify

SWARM can investigate agreed infrastructure, identity and application paths and preserve reproduced evidence for remediation. FailSafe’s deployment options allow customers to define who operates assessment infrastructure and where inference runs.

Customer-controlled deployment and secure operations are related design choices. Even a private environment needs review of privileged access, egress, signed updates and the process for an approved support session.

Explore the October incident collection for related cases and existing FailSafe coverage. Incident descriptions are attributed to the linked sources; assessment recommendations are FailSafe’s analysis. We have not conducted forensic investigations of these incidents.