October 20–21, 2026: GMO Internet confirmed that "unauthorized access by a third party occurred against Onamae.com Desktop Cloud", the virtual private server service sold under its Onamae.com brand. Malicious programs were installed in some customer environments, and the company shut the servers down in stages from 04:00 Japan time on October 21. Up to 26,739 customer servers are affected. Canonical: onamae-desktop-cloud2026. Primary source: Onamae.com's notice.
Desktop Cloud is a VPS product. Customers rent a server, install their own operating system and software, and keep their own data on it. That makes a VPS intrusion different from a web-app breach: the attacker may have access to everything the customer put on the machine, including databases, configuration files, SSH keys and any secrets used to reach other systems.
What is confirmed
- Unauthorised access: the company says a third party gained access to the service. It has not described the entry point.
- Malware: malicious programs were installed in some customer environments. The company has not described their function.
- Shutdown: servers were taken down in stages starting at 04:00 JST on October 21. All Desktop Cloud plans are suspended, and no restart date has been given.
- Scope: up to 26,739 servers, according to the article that reported the notice. The company has not published a separate count of affected customers.
- Payments: reported to be held on separate infrastructure and not affected. The company says it will never ask for passwords or card details by email or phone.
Unknown so far
The company has not said how the intruder got in, when the intrusion began, what the malware does, whether it has been removed from servers that were not shut down, or whether any customer data has been taken. It says the investigation is ongoing and promises updates. Until those answers arrive, treat any server that was on the service during the incident period as potentially compromised.
Technical analysis
There are three likely routes for an intruder to reach a multi-tenant VPS platform, and each one changes what customers should do. Keep in mind that none of these is confirmed for this incident.
- Control-plane compromise: if the attacker reached the management layer, they could have used platform tooling to reach customer machines. Customers would see unexpected reboots, changed images, new users or altered SSH keys, and the remedy is a platform-side rebuild.
- Customer-side compromise: if a customer's own service was exploited and the attacker escalated from there, the exposure is limited to that server. Customers would still need to rebuild, because a root-level foothold can persist in cron jobs, systemd units and authorised keys.
- Shared-host abuse: if malicious programs ran on the host or on neighbouring machines, the attacker may have been able to read network traffic or resources shared with other customers.
In every case the safe response is the same: assume the operating system is no longer trustworthy. Restoring a snapshot from before the incident is risky if you do not know when the compromise began, because the malware may be in the snapshot.
A practical rebuild sequence
For a VPS that was on the service during the incident window, a rebuild should look like this. The order matters, because the old machine should not be trusted until its contents are checked.
- Capture evidence first. If the provider still gives you access to the disk or a snapshot, copy it somewhere isolated before you change anything. Note the times you first noticed anything unusual, because the attacker's activity may be recoverable from logs you preserve now.
- Stop trusting the host. Do not run new commands on the old system except for read-only inspection. Do not reuse its SSH keys, and do not connect it to databases or cloud accounts while you investigate.
- Inventory what the server held. List services, scheduled jobs, users, authorised SSH keys, environment files and any tokens saved in shell history or browser sessions. This list tells you which secrets to rotate.
- Rotate the secrets from the outside. Revoke and reissue each credential at its provider before you rebuild, so the attacker cannot use a copy they took while you work.
- Build a new machine from a clean image. Choose an image you trust, apply updates, and set up access with new keys. Do not restore full-system backups from the incident period.
- Move data across selectively. Copy only data you can verify, such as database dumps checked against known schemas, and scan files for scripts, unknown binaries and unexpected cron entries before they run.
- Restrict what the new server can reach. Use firewall rules and per-service credentials so that a future compromise of one service does not expose everything.
Keep the old disk or snapshot, sealed and offline, until your investigation is finished. It may matter for any notice you owe your own customers.
Verified vs unverified
- Verified (company notice): unauthorised third-party access, malware in some environments, staged shutdown from 04:00 JST on October 21, and the customer advice.
- Reported (press, citing the notice): the 26,739-server figure and the statement that payment data sits on separate infrastructure.
- Unknown: entry point, dates, malware behaviour, data taken, and whether any server was spared.
What to do
- If you had a Desktop Cloud server, assume it was compromised. Do not reconnect it to your network until you have rebuilt it.
- Change every password and secret stored on the server, including database passwords, API keys, SSH keys and any credentials in configuration files. Rotate at the provider, not only on the server.
- Rebuild from a clean image. Move data off the old server only after you have checked it for malicious scripts, cron entries and unknown keys, and avoid copying executables or configuration you cannot verify.
- Check what the server could reach. Review database connections, cloud keys, VPN configuration and any services that trusted the server's IP address, and rotate or restrict them.
- Review your own logs for outbound connections from the server during the incident window, and for logins from addresses you do not recognise.
- Treat phishing as likely. Customers of a hosting brand are frequent targets after an incident. Verify any message by visiting the official site yourself.
Related reading
For another hosting-provider intrusion with the same customer-side lesson, see the FirstVDS breach. For a platform that exposed customer environment variables, see the Railway write-up published with this post.