Onamae Desktop Cloud Hack: Lessons for Hosted Desktop and VPS Users

On 20 October 2026, GMO Internet found that a third party had planted malicious programs on some customer servers in Onamae.com Desktop Cloud, a hosted Windows desktop service popular for automated FX trading. Up to 26,739 servers may be affected. Customers should change every password stored on those servers, from a separate device, and watch for phishing.

The service is stopped while GMO investigates, with no restart date yet.

What happened

GMO Internet runs Onamae.com, one of Japan's largest domain registrars, and sells Desktop Cloud under that brand. GMO's own notice, published on 21 October and stated as current "as of 4:00" that morning, is the primary source. The table adds outside reporting where it fills a gap. Times are Japan Standard Time.

GMO said it will publish details and the restart date once they are confirmed. The investigation was ongoing at the time of every source above.

What the 26,739 figure means

The number is the count of servers that may be affected. Rocket-boys and Otakuma Keizai Shimbun both stress the same point: it is not the number of servers where the malicious program was actually found, and it is not a count of leaked records. GMO stopped every plan, so every customer lost service, but not every server is known to be compromised.

"Up to 27,000" in English headlines is a rounding of 26,739. We use GMO's exact figure.

What is still unknown or reported differently

GMO has not said how the attacker got in, what the malicious program does, who is behind it, or which file types were involved. According to rocket-boys, none of these were specified as of the 04:00 notice. We found no attribution in any source.

On data exposure, GMO says information stored on the servers may have been viewed. It says no leak of customer personal information and no misuse of viewed information had been confirmed.

On payment data, sources word it differently. GMO's notice, as summarised by ASCII.jp, Otakuma and rocket-boys, says GMO does not hold payment information such as card details. BleepingComputer says payment data is not affected because it is stored on separate infrastructure. Both point the same way: card data is not described as at risk. We follow GMO's wording.

GMO's news list for the same week also carries separate notices: new VPS (KVM) applications paused over a Linux kernel flaw (19 October) and a response to a PHP vulnerability (22 October). GMO has not linked either to Desktop Cloud, which is a Windows service. Do not read a connection into the timing.

Who is affected

Desktop Cloud gives customers a Windows environment reached over remote desktop, so trading software can run around the clock without a home PC left on, according to Otakuma Keizai Shimbun. GMO's own product notices describe connecting by remote desktop and installing MT4 or MT5 builds through a downloader shortcut on the desktop.

That use case matters for the lessons below. A trading VPS typically holds the broker login, the trading platform's master password, licence keys for paid EAs, and sometimes email and API credentials for alerts. Those are the secrets GMO is asking people to change.

How it works

We do not know the entry point, so this section stays with what the public record supports and how hosted desktops are generally built.

A hosted desktop or VPS service runs many customer virtual machines on shared hosts, managed through a shared control plane and customer portal. The customer gets an administrator login inside their own Windows machine. The provider owns everything underneath: hypervisors, storage, images, the management network and the tooling used to maintain thousands of machines at once.

Two facts in GMO's notice point at how this incident behaves from the customer's side.

First, the response was fleet wide. GMO stopped every plan, not just the servers where the program was found. When a provider cannot yet say which machines are clean, stopping all of them is a reasonable way to limit damage. It also means a customer whose own machine was never touched still loses service for an unknown period.

Second, the risk to the customer is the data inside the machine. GMO's advice is about credentials stored on or used from the server. A Windows desktop that ran a trading terminal for months can hold saved passwords in the terminal, in browsers, in the Windows credential store, in configuration files and in scripts. That is how the hosted desktop model splits risk, not a comment on GMO: the provider controls the platform, and the customer controls what goes on it.

What to do now

GMO's own requests come first: change IDs and passwords stored on or used with the server, change reused passwords elsewhere, and be wary of phishing. GMO says it will never ask for passwords or card details by email or phone. The steps below expand on that. Rocket-boys published similar guidance, credited where used.

1. Read GMO's notice directly and bookmark it. Use onamae.com/news/article/11584 and the information news list. Do not follow links in emails or texts about the incident. Type the address yourself.

2. Check your broker account from a trusted device first. Stopping an EA does not cancel open positions or pending orders at the broker, as rocket-boys points out. Open the broker's official app or website and check positions, stop loss and take profit orders, and margin. Rocket-boys notes this is a general precaution, not a sign that unauthorised trades were seen.

3. Make a list of every secret that touched the server. Think broadly: Windows login, MT4 or MT5 account and master password, broker portal login, EA licence keys, email accounts used for alerts, messaging bot tokens, cloud storage logins, and any API keys in scripts. On the Windows PC you use to connect, these commands show what it knows about the remote host:

   # Saved remote desktop credentials on your own PC
   cmdkey /list | findstr /i "TERMSRV"
   
   # Saved .rdp connection files, which name the hosts you connect to
   Get-ChildItem -Path $env:USERPROFILE -Filter *.rdp -Recurse -ErrorAction SilentlyContinue |
     Select-Object FullName, LastWriteTime
   

   If you use a password manager, search it for the server's hostname or IP and for every entry you ever copied into the remote session.

4. Rotate from a clean, separate device. Do not change passwords from inside a server that may still hold the attacker's program; rocket-boys makes the same point. Change the broker password through the broker, reissue API keys and tokens, and turn on two factor sign in wherever the service offers it.

5. Fix reuse. GMO specifically asks customers to change the same password anywhere else it was used. Most password managers have a reuse report. Work through it, starting with email, because email resets everything else.

6. Review recent activity. Look at broker order history, email sign in history and forwarding rules, and API usage logs for anything you did not do. Rocket-boys suggests checking login, API and brokerage histories.

7. Treat incident themed messages as hostile until proven otherwise. Expect emails and texts that claim to be GMO or your broker, offering "recovery" or "identity verification". Rocket-boys warns about exactly this. Go to the official site by typing it.

8. Do not wipe or reuse the server on your own. When access returns, follow GMO's recovery instructions. Rocket-boys advises against independently wiping suspected servers and asks customers to coordinate backup handling and evidence with the provider.

9. When you rebuild, start clean and verify what you copy back. A fresh machine is safer than a cleaned one. Reinstall the trading platform from your broker's official download, then restore only settings and EA files you hold elsewhere. Hash them so you can compare against your own copies:

   # Record hashes of your EA and indicator files before copying them anywhere
   Get-ChildItem -Path "C:\path\to\your\backup\MQL4" -Recurse -Include *.ex4,*.mq4,*.set |
     Get-FileHash -Algorithm SHA256 |
     Export-Csv -Path .\ea-hashes.csv -NoTypeInformation
   

10. If GMO tells you to inspect a restored server, look at persistence first. These read only commands list the common places a program would use to survive a reboot. Run them only if the provider's guidance allows it, and send anything odd to GMO rather than deleting it.

    # Scheduled tasks that are not Microsoft's own
    Get-ScheduledTask | Where-Object { $_.TaskPath -notlike "\Microsoft\*" } |
      Select-Object TaskName, TaskPath, State
    
    # Programs set to start automatically
    Get-CimInstance Win32_StartupCommand | Select-Object Name, Command, Location, User
    
    # Local accounts and when they last signed in
    Get-LocalUser | Select-Object Name, Enabled, LastLogon
    
    # What is listening or connected, with the owning process
    Get-NetTCPConnection -State Listen, Established |
      Select-Object LocalPort, RemoteAddress, RemotePort, OwningProcess
    

Lessons for hosted desktop and VPS customers

You can do everything right inside your own Windows session and still be affected by an incident at the platform layer. That is not a reason to avoid hosted services. It is a reason to plan for the day the provider has to pull the plug. We drew similar conclusions from the ransomware attack on IDCF Cloud earlier this month; see IDCF Cloud ransomware: third-party and concentration risk lessons. This incident is different in shape (malicious programs on customer machines, not encryption of a region), but the customer side planning overlaps.

Assume the server can be read by someone else. A hosted desktop is a computer you do not physically control. Store only the credentials it needs to do its job. A monitoring dashboard does not need your broker master password. MetaTrader offers a separate read only investor password for viewing an account without trading; use it wherever only viewing is needed.

Keep secrets out of files on the box. Scripts that send trade alerts often carry a bot token or SMTP password in plain text. Read them from an environment variable or the Windows credential store instead, so a copied folder does not carry them along.

Know every secret the server holds, before you need the list. The slowest part of responding to GMO's request is working out what to rotate. A short inventory, kept in your password manager or a notes file off the server, turns a stressful evening into twenty minutes.

Plan for a provider wide stop. GMO stopped every plan, with no restart date. If an EA manages open risk, decide in advance what happens when it goes dark: protective orders set at the broker, a second host from a different provider ready to run, and a phone alert when the terminal disconnects.

Hold your own copies. EA files, .set parameter files, templates, indicators and scripts should live in version control or backup storage that is not on the same VPS. That lets you rebuild elsewhere in an hour.

Separate accounts, and bookmark the notices page. Use a unique password for the hosting portal and never reuse the server's Windows password. During an incident, the provider's own news page is the only link you should trust.

What would have helped

None of the steps below would have stopped a third party from reaching the provider's platform. They limit what is exposed and how long you are down.

1. A credential inventory per host: what each secret is, where it lives, how to rotate it.
2. Least privilege credentials: investor passwords for monitoring, scoped API keys, no admin email signed in on the server.
3. Two factor sign in everywhere it exists, so a password read from the server is not enough on its own.
4. Protective orders held at the broker, which survive the server being stopped.
5. Off host copies and a tested rebuild on a second provider.
6. Scripted rotation, so reissuing tokens takes minutes, not support tickets.
7. A heartbeat from outside the server that tells you within minutes the terminal has gone dark.

Where Safeguard fits

Be clear about scope first. Safeguard does not monitor Windows desktops, does not detect malware on a VPS, does not scan for stored secrets, and has no visibility into a hosting provider's platform. It would not have detected or prevented this incident, and it cannot tell you whether your server was among the 26,739.

Where it can help is the code and components you run on hosted machines, and the work of rebuilding them.

• Know what you are redeploying. If your trading automation, alert bots or business jobs live in a repository or container image, safeguard scan --dir ., safeguard scan --image <name> or safeguard scan --sbom <file> produces an SBOM and dependency findings, with results as JSON under ./output. Before you stand the workload up on a new host, you know which components and versions it carries and which have known vulnerabilities, with reachability analysis to show which ones your code actually calls.
• Find every project that carries a component. The platform shows which projects contain a given component and version. That helps when the question is "which of our services ship this library", useful when a dependency in your automation code gets a CVE.
• Gate the rebuild. Policies and gates evaluated in the platform can block a build that brings in a known critical vulnerability while you are rushing to redeploy. safeguard exec runs the same checks in CI.
• Do the code changes with approval. The Safeguard CLI's assistant can edit code and run commands with your approval. You could ask it to change an alert script so it reads its bot token from an environment variable instead of a hard coded string, then run the tests. The /permissions modes (Ask, Accept edits, Plan, Auto, Strict) decide how much it can do without asking. The desktop and phone apps can send work to a computer running the CLI and approve each command.
• Fix PRs. Autonomous remediation can open fix pull requests for vulnerable dependencies. It is off by default.

The overview in October 2026 security incidents: what would have helped puts this incident's lessons next to the others from the month. For the general pattern of finding affected software fast, see SBOM incident response: finding affected products fast.

Zero-Day Discovery and Gold

Two other Safeguard capabilities are relevant to the rebuild habit, not to this incident.

Zero-Day Discovery looks for previously unknown flaws before a CVE exists. It runs in an agentic mode and a deterministic scanner mode, and its findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. A hosting provider's platform, Windows itself and closed trading terminals are outside what it covers, and we make no claim that it found anything related to Desktop Cloud.

Gold Open Source at gold.safeguard.sh is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a GitHub Action that can gate CI. Gold Registry at registry.safeguard.sh is the paid side: hardened drop in components and container images held to zero exploitable critical or high CVEs, built to SLSA L3+, signed with Sigstore, with evidence pages. An artifact loses its badge if it regresses.

The habit they support is the one that matters after any hosting incident: rebuild from patched, signed components pulled from a curated source, quickly, rather than copying an old machine forward.

Common mistakes

Changing passwords from the affected server. If the attacker's program is still there, the new password goes with it. Use a separate device.

Rotating the broker password and forgetting the rest. Email accounts, alert bot tokens, EA licence portals and cloud storage logins used on the server all need the same treatment.

Clicking "recovery" links. Incident themed phishing follows every public breach. GMO says it will never ask for passwords or card details by email or phone.

Assuming a stopped EA means no open risk. Positions and pending orders stay open at the broker. Check them directly.

Reading 26,739 as 26,739 confirmed infections. It is the potentially affected count. Report it that way inside your own organisation so nobody overreacts or underreacts.

FAQ

When did the Onamae Desktop Cloud incident happen?

GMO confirmed the malicious programs on 20 October 2026 and began stopping servers from 04:00 on 21 October. The notice was published on 21 October. As of 22 October, no restart date had been announced.

How many servers are affected?

GMO lists 26,739 servers as potentially affected. English coverage rounds this to "up to 27,000". It is not the number of servers where the program was confirmed.

Was my credit card data exposed?

GMO says it does not hold payment information such as card details. BleepingComputer says payment data sits on separate infrastructure and is not affected. Neither source describes card data as at risk.

Was customer data stolen?

GMO says information stored on the servers may have been viewed. As of its 21 October notice, it had not confirmed any leak of customer personal information or any misuse. The investigation is ongoing.

Who is behind the attack?

No source we read names an attacker or group. GMO has not said how the intrusion happened.

What should I do if I run an EA on Desktop Cloud?

Check positions and protective orders directly with your broker from another device. Then change the broker, platform and email passwords that were stored or used on the server, from a clean device, and fix any reuse.

Does this affect Onamae.com domains or DNS?

According to rocket-boys, domain registration, DNS and the general rental servers are not described as affected by this shutdown. Check GMO's news page for any change.

Is this related to the IDCF Cloud attack?

We found no source linking the two. IDCF Cloud was a ransomware attack on a different provider's region. Both show why customers of hosted platforms should plan for a provider wide outage.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos show the Desktop Cloud incident. Each is a real Safeguard session, and the text says how the same flow applies when you rebuild a hosted trading or automation workload after an incident like this one.

The first demo is a CLI session that fixes a lodash CVE: the assistant reads the finding and advisory, asks before each command, edits package.json, runs the install and tests with your approval, prints a summary and pushes nothing. For Desktop Cloud, you would open the same session in the repository that holds your alert bot or job scripts and ask it to replace a hard coded token with an environment variable read, then run the tests. It asks before every edit and command.

Click through it at your own pace, or open it full screen.

The second demo is a desktop app session: the CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with the upgrade done and tests passing. After a provider stop, you would point it at the folder you are moving to a new host and ask it to upgrade the dependencies a scan flagged before you redeploy.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: you send work to a computer running the CLI and approve the command on the phone with Allow once, Allow for turn or Deny. Hosting incidents rarely land at a convenient hour. You could start the rebuild on your workstation and approve each step from your phone while you check positions with your broker.

Click through it at your own pace, or open it full screen.

To try the CLI on your own repositories, download it from https://safeguard.sh/download and read the setup guide at https://docs.safeguard.sh/docs/cli .

Quick check

Sources

• GMO Internet: notice of unauthorised third party access to Desktop Cloud, as of 21 October 2026, 04:00 (Japanese)
• Onamae.com information news list (Japanese)
• Onamae.com: Philip Securities MT5 added to Desktop Cloud (Japanese)
• BleepingComputer: Japan's Onamae Desktop Cloud hacked, up to 27,000 servers affected
• INTERNET Watch: FX automated trading VPS stops servers after unauthorised access (Japanese)
• ASCII.jp: GMO stops all Desktop Cloud plans, about 27,000 may be affected (Japanese)
• Rocket-boys Security Measures Lab: Desktop Cloud unauthorised access, up to 26,739 servers (Japanese)
• Otakuma Keizai Shimbun: Onamae.com FX VPS unauthorised access (Japanese)

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.