OVHcloud CLI and AOMEI Backupper: When Vendor Release Channels Served Malware, and How to Check Your Builds

TL;DR: In October 2026, two software vendors' own download or update channels were disclosed to have delivered malware for short periods. OVHcloud says a compromised developer GitHub account replaced the release binaries of ovhcloud-cli v0.11.0 to v0.15.0 with a secret-stealing build on 19 October 2026 between 14:47 and 16:21 (UTC+2), which is 15:47 to 17:21 Cyprus time (UTC+3). Only people who downloaded the CLI in that window are affected; source code and OVHcloud's build chain were not, and the clean v0.16.0 release is out (OVHcloud, GHSA-862f-55f5-vmvw). Separately, Google Threat Intelligence Group (GTIG) and Mandiant report that a cluster they track as UNC7017 tampered with AOMEI's update configuration files for five to ten minutes at a time between April and July 2026, so that AOMEI software polling for updates in those minutes downloaded and ran malware (Google Cloud blog). AOMEI says it remediated the update server in July and released AOMEI Backupper 8.5.1 on 19 October 2026 (AOMEI statement). The two cases are unrelated. Neither has a CVE, and neither is in CISA's Known Exploited Vulnerabilities (KEV) catalog. If you or your vendors use either product, check whether any system downloaded or updated during the published windows, and treat any match as a compromised host (Rescana guidance).

These are two separate incidents. Neither OVHcloud nor Google links them to each other, and they are attributed to different actors. We group them here because they share a pattern: the software itself was not backdoored at source, but the channel that hands it to users was briefly changed, and then changed back.

Technical Information

OVHcloud CLI (ovhcloud-cli): release files replaced on GitHub

OVHcloud published its post-mortem as a GitHub security advisory, GHSA-862f-55f5-vmvw ("ovhcloud-cli security incident - October 19th, 2026"), on 20 October 2026 at 12:49 UTC (15:49 Cyprus time (UTC+3)). GitHub lists the advisory severity as High, with no CVSS score and no CVE ID. OVHcloud says:

• "a compromised OVHcloud's GitHub developer account was used to replace several existing assets releases with malicious binaries on 19 October 2026 between 14h47 (UTC+2) and 16h21 (UTC+2)"
• "affected assets releases are from v0.11.0 to v0.15.0"
• "only users that installed the CLI between 14h47 (UTC+2) and 16h21 (UTC+2) on 19 October 2026 are affected, users that downloaded v0.11.0 to v0.15.0 prior to this date are unaffected"
• "source code and build chain are not affected"
• "no other repository projects were affected"

The customer's initial report (issue #300) is titled v0.13.0 to v0.15.0 because those were the releases it had checked; OVHcloud's advisory, published the next day, gives the full range of v0.11.0 to v0.15.0.

OVHcloud gives the root cause as a repository setting: "The main issue was that the GitHub repository was not appropriately configured to ensure release immutability." In other words, an account with write access could swap the files attached to existing releases without going through OVHcloud's pipeline. OVHcloud says the setting was corrected and "The same configuration has been applied to every repositories."

Timeline (from OVHcloud's advisory, converted to Cyprus time (UTC+3)):

OVHcloud puts the "Duration of malware availability" at 1h33 and its "Download stats" at ~250. The GitHub releases page now shows v0.16.0 as an "Immutable release" (ovh/ovhcloud-cli releases).

What the malicious build did: OVHcloud says it was "the original CLI recompiled with malicious Go code (stripped) embedded in it, designed to steal a number of secrets and files". OVHcloud's list of targets covers AI coding assistant and IDE data, cloud (AWS, Google Cloud, Azure, DigitalOcean) and Terraform credentials, Docker, Kubernetes and npm configuration, SSH keys, ".netrc" and the global Git config; it says the data was staged in a temporary folder and exfiltrated to an attacker-controlled address.

Root cause, per OVHcloud: OVHcloud traced the account takeover to an extension, color-picker-universal 2.8.91, that the developer installed on a personal MacBook on 20 October 2025. OVHcloud says a Solana wallet used by that extension "is known as belonging to the Glassworm threat actor", and that the release files were replaced "by using the stolen keys", not from the developer's MacBook. It adds that "The OVHcloud laptop of the developer has not been compromised as far as we know at that time", and that its main internal CI/CD platform, which is not hosted on GitHub, has "NOT been compromised." The Glassworm attribution is OVHcloud's; Google does not mention OVHcloud.

AOMEI Backupper: short-burst tampering of update configuration

Google's GTIG and Mandiant published their investigation on 15 October 2026. They say they "investigated a software supply chain compromise campaign targeting the update infrastructure belonging to AOMEI Technology between April 2026 and July 2026", and that "Each tampering window remained active for only five to ten minutes before reverting to authentic versions." Google calls this "the first time that we have encountered a software supply chain compromise that was implemented with these very short windows." It attributes the activity to a threat cluster it tracks as UNC7017 and does not tie it to a named state or group.

How it worked, at a high level (per Google): AOMEI Backupper and AnyViewer use a shared update and notification flow in which the client periodically fetches two remote configuration files over HTTPS, down_html.ini (which names the update package and its expected MD5 hash) and Notifycfg.ini (which controls in-app notifications). During each tampering window, the attacker changed both files so that clients downloaded a ZIP archive from attacker infrastructure and then executed it through the notification feature. No software vulnerability was used. Because the expected checksum sits in the same unauthenticated file as the download URL, the attacker could change both together. Google says ManageEngine's Threat Analysis Lab (METAL) first detected the activity in its EDR telemetry in late May; METAL's own report makes the same checksum point (METAL report, 16 Oct 2026).

Confirmed tampering windows (per Google; AOMEI's statement repeats them):

Google cautions that "it is probable that additional tampering occurred throughout the campaign that remained outside our visibility," and that it observed related malware samples "in the wild starting in late April." Systems that checked for updates before or after a window "received clean, authentic files."

Payloads (per Google): a downloader Google tracks as CROSSROAD (upgrade-now.exe), which sets up a scheduled task and stages a backdoor Google tracks as SHINYROAD, delivered alongside legitimate Radmin remote-administration components. In the 20 July window, Google says the notification file was also changed to point at a remote WebDAV resource in a way that could coerce Windows endpoints into sending NetNTLMv2 authentication hashes to an attacker-controlled IP address. From mid-July, Google also saw later-stage activity using the Adaptix C2 framework disguised as Nitro PDF tools.

Who was affected (per Google): organizations in sectors including IT services, telecommunications and higher education, in 11 countries Google lists. Google says that because the campaign "attempted to deliver malware to any system polling the update distribution servers during the threat actor's tampering windows, victimology was opportunistic and likely extends more broadly." METAL's report lists the affected software as "AOMEI Backupper (observed on v8.3.0 and later versions)". That is METAL's observation; neither Google nor AOMEI gives a version range, and both scope exposure by when a client polled for updates.

Disclosure and fixes:

• 17 July 2026: Mandiant notified AOMEI and shared indicators; AOMEI responded on 29 July that "corrective actions had been taken" (per Google).
• AOMEI says it "completed remediation of the upgrade server in July" and that "GTIG confirmed that it had not observed any further related attack activity following the remediation" (AOMEI statement, updated 19 October 2026).
• 15 and 16 October 2026: Google and METAL publish their reports.
• 19 October 2026: AOMEI publishes its statement and releases AOMEI Backupper 8.5.1 (AOMEI changelog).

Google stresses one point that matters for anyone assessing exposure: "server-side remediation does not clean endpoints that downloaded malicious updates during earlier tampering windows." A host that received the payload in May or July may still be running it.

Affected Product Versions

Google describes the same update flow for AOMEI AnyViewer, and METAL says Google's report documents "targeting of AOMEI AnyViewer alongside Backupper". AOMEI's statement and the 8.5.1 changelog address Backupper; we found no separate AnyViewer incident notice from AOMEI (checked 22 Oct 2026, 17:10 Cyprus time (UTC+3)). AOMEI's AnyViewer changelog lists version 5.8.1 on 19 October 2026 with "Strengthened security for software updates and promotional content updates", without referring to the incident. The Record reported on 20 October that AOMEI said its monitoring found that "only AOMEI Backupper exhibited anomalies," with "no abnormal activity" in AnyViewer.

Workaround and Mitigation

OVHcloud CLI: what OVHcloud recommends

OVHcloud says: "If you downloaded or updated OVHcloud-cli between 14h47 and 16h21 on 19 October 2026 and ran it on your computer, the secrets stored on this computer should be considered compromised. Otherwise, you are safe." If you suspect you are affected, OVHcloud says to:

• "Proceed to a secret change or deactivation for all relevant services as soon as possible"
• "Delete the compromised binaries"
• "Update or reinstall the CLI with the v0.16.0 version"

OVHcloud also says to check a binary "securely" by comparing its MD5 hash against the list in the Indicators section below, and to "not run the binary" while doing so.

AOMEI Backupper: what AOMEI and Google recommend

AOMEI tells users who ran Backupper during the exposure windows, or who are concerned, to download AOMEI Backupper 8.5.1, update their existing security software and scan, and, if that scan is not conclusive, scan with Malwarebytes Free; AOMEI says "Malwarebytes has stated that its software can detect the malicious files used in this attack." AOMEI says it is preparing an "AOMEI Security Scanner" that is still in testing, and that it will "proactively notify" users it assesses as affected.

AOMEI lists these changes in 8.5.1 and on its servers: in-app promotional and automatic-update entry points disabled; "asymmetric encryption protection for remote configuration files (.ini)" (AOMEI's wording; Google's guidance to vendors recommends digitally signing remote configuration files); the www2.aomeisoftware.com download domain retired; the old upgrade server taken offline and update services moved to a new provider; software updates separated from marketing notifications; downloads restricted to official AOMEI sites; and stronger server monitoring.

Google tells organizations running AOMEI software that they "cannot assume they are protected solely because the vendor took corrective server-side action" and should "perform retrospective endpoint and network hunts across the entire April–July time frame." It also advises blocking the network indicators below, blocking outbound SMB (TCP 445) and WebDAV traffic to external IP addresses, and preserving the cached configuration files in %PROGRAMFILES(X86)%\AOMEI\*\Tmphtml\ rather than relying on a live check of AOMEI's servers, which will now return clean files.

Rescana guidance (general hygiene, not vendor instructions)

• Find the installs first. Inventory where ovhcloud-cli and AOMEI software (Backupper and AnyViewer) are installed, including developer laptops, jump hosts and CI runners.
• Match on time, not just version. For ovhcloud-cli, the version number alone does not tell you whether a file is bad; the download time and the hash do. For AOMEI, the question is whether the client polled for updates during a window, which only endpoint and proxy logs can answer.
• If a host matches, treat it as compromised. Isolate it, rebuild it from a known-good image where practical, and rotate every credential it could reach, including cloud, CI, SSH and AI-assistant tokens.
• Prefer channels you can verify. Pin tool versions, install from immutable or signed releases where the vendor offers them, and check vendor-published hashes or signatures before running new binaries.

Indicators of Compromise

All indicators below are copied from the vendor or Google and defanged by Rescana (dots in domains and IPs replaced with [.]). Do not download or execute any file to test it; compare hashes of files you already have.

OVHcloud CLI (source: OVHcloud, GHSA-862f-55f5-vmvw)

MD5 hashes of the malicious binaries:

• ovhcloud (Darwin_arm64 platform): 6f2f086239f3d88eb2750e871901927d
• ovhcloud (Darwin_x86_64 platform): 347e65eb7f2d78d1c6872690272a6cc3
• ovhcloud (Linux_arm64 platform): 01f57206d37c28cf711677f612052913
• ovhcloud (Linux_x86_64 platform): 301bff0b51980b9e76c93633e7cfd3bd
• ovhcloud.exe (Windows x86_64 platform): 6a3cf153338c416169cda2fe704c8848

Host artifact: OVHcloud says each run of the malicious binary creates a folder in the temporary directory named envchecker- followed by 9 or 10 digits, and that this folder "is never deleted". Its presence indicates the binary ran.

Network:

• Exfiltration: 45.32.148[.]174:443 (OVHcloud notes the upload URL "is time-sensitive and can be changed at any moment by the threat actor")
• Solana wallet: BHaDaVbdCYFNaKZGn7yLXFneWoJHZgLiBYkHxVrjyALF
• Solana RPC endpoints used: solana.drpc[.]org, solana-rpc.publicnode[.]com, solana.api.pocket[.]network, api.mainnet-beta.solana[.]com, solana.api.onfinality[.]io/public

The Solana RPC endpoints are public services, so traffic to them is not malicious by itself; use them as context alongside the hashes and the temp folder.

AOMEI Backupper (source: Google Threat Intelligence Group / Mandiant)

Malicious file hashes (SHA-256), selected from Google's Table 2:

Google's full list, including tampered .ini file hashes and YARA rules, is in its post. Google also lists legitimate Radmin and Nitro binaries that the attacker abused; it describes FamItrfc.exe as "the legitimate, signed Radmin binary", so its presence is not malicious by itself.

Network indicators (selected from Google's Table 5, defanged):

• promotion.storage-data[.]com (Stage-2 Dropper Staging Domain)
• aomei.storage-data[.]com (Stage-3 Payload Staging Server)
• storage-data[.]com (Threat Actor Domain)
• serv.oss-cn-hongkong.aliyuncs[.]com (Alibaba Cloud OSS Bucket, April/May 2026 Staging)
• hxxps://storage.googleapis[.]com/aomeiupdate/upgrade-now.zip (July 20 GCS Staging URL)
• hxxps://storage.googleapis[.]com/aomeiupdate/component.zip (July 20 GCS Component URL)
• hxxps://promotion.storage-data[.]com/download/abpopup/upgrade-now.zip (Stage-2 Dropper Download URL)
• 8.210.84[.]56 (WebDAV NTLM Target Server; Adaptix C2)
• 8.218.65[.]184 (Historical SHINYROAD C2 Server; ports 41397 and 443)
• 47.239.60[.]117 (Secondary Infrastructure)
• User-Agent Anyviewer-loader/1.0 in proxy logs (per Google)

Host indicators (per Google):

• Scheduled tasks \RadminComponentRuntime and \NitroRuntime
• Mutex Global\{F9E6E3C0-E11A-4F85-9944-AF4AD6E05883}
• Shared memory mapping Local\963d3c60-d406-4ad6-aa1e-dc8e45061ccf
• Unsigned DLLs in %LOCALAPPDATA%\Radmin\ (BlkScrDl.dll, csvc\RuntimeComponent.dll) and executions with --runtimechk
• upgrade-now.exe in AOMEI's html\ directory

CVE, CVSS and KEV status

• OVHcloud CLI: no CVE assigned. GitHub repository advisory GHSA-862f-55f5-vmvw lists severity High with no CVSS score. At our check (22 Oct 2026, 17:07 Cyprus time (UTC+3)), it was not in the reviewed GitHub Advisory Database or OSV.
• AOMEI Backupper (update tampering): no CVE assigned and no CVSS score. Google, METAL and AOMEI describe it as server-side configuration tampering, not a software vulnerability.
• CISA KEV: neither incident is listed (no CVE, and no OVHcloud or AOMEI entry) in the live catalog (catalogVersion 2026.10.21, checked 22 October 2026 at 17:07 Cyprus time (UTC+3)).

What we will update: We will update this post if OVHcloud or AOMEI publish new findings, if AOMEI releases its security scanner or an AnyViewer notice, if a CVE is assigned, or if a national CERT issues an alert.

Sources

• OVHcloud: GHSA-862f-55f5-vmvw, "ovhcloud-cli security incident - October 19th, 2026" (published 20 Oct 2026); ovhcloud-cli releases (v0.16.0 immutable release); issue #300, the customer report (19 Oct 2026)
• Google Threat Intelligence Group and Mandiant: Investigating Ephemeral Supply Chain Tampering (15 Oct 2026)
• AOMEI: Statement on Ephemeral Tampering with the AOMEI Backupper Update Server (updated 19 Oct 2026); AOMEI Backupper changelog (8.5.1, 19 Oct 2026); AnyViewer changelog (5.8.1, 19 Oct 2026)
• ManageEngine Threat Analysis Lab (METAL): AOMEI Backupper supply-chain compromise: Investigation and analysis (16 Oct 2026)
• The Record: AOMEI yet to notify customers after hackers hijacked its software updates (20 Oct 2026), cited only for AOMEI's AnyViewer statement

No CISA, CERT-FR, CERT-EU, NCSC or Canadian Centre for Cyber Security notice naming either incident was found (checked 22 Oct 2026, 17:10 Cyprus time (UTC+3)).

Why this matters for vendor risk

Neither incident needed a software bug: in both, what the vendor's own channel handed out was briefly changed and then changed back, so a supplier whose staff installed or updated these tools in the published windows could have lost credentials that reach your data, while a later look at the vendor's download page would show nothing wrong. That makes release and update integrity a fair question for any software supplier, not only the two named here.

Forward this to your TPRM owner: Ask your key software suppliers whether they use ovhcloud-cli, AOMEI Backupper or AnyViewer and have checked downloads and update polls against the published windows and hashes; whether the releases and update metadata they ship to you are immutable and signed, and can be verified independently of their download page; who can publish or replace a release, and whether that is tied to central identity with MFA; and how quickly they would detect a tampered build and notify customers (Rescana guidance).

Want to see how your software suppliers handle release integrity and supply-chain incidents? Book a demo.