Scoped response to AOMEI update tampering

The captured October 29, 2026 discussion reports that server-side update configuration was changed so legitimate AOMEI clients would accept upgrade-now.zip, including changes to the download URL, build value, and expected MD5.

It identifies three AOMEI Backupper delivery windows—May 28, 05:40–05:50 UTC; July 16, 08:33–08:39 UTC; and July 20, 10:35–10:40 UTC—while also reporting activity across April–July. That mismatch makes the named windows useful prioritization points but not safe outer boundaries.

Update and endpoint telemetry can expire, so evidence must be preserved before exposure can no longer be reconstructed.

At the same time, the evidence supports a scoped response rather than a blanket compromise declaration because installation alone does not show payload retrieval, execution, or command-and-control activity.

AOMEI Backupper endpoints that used in-application updating during the reported May 28, 05:40–05:50 UTC; July 16, 08:33–08:39 UTC; or July 20, 10:35–10:40 UTC windows have the clearest reported exposure to manipulated update delivery.

AOMEI Backupper endpoints updated at other times during the reported April–July activity range, or whose update history cannot be reconstructed, have unresolved exposure and require telemetry and artifact review.

Privileged backup endpoints merit priority because the captured analysis identifies risk concentration there.

AnyViewer remote-access endpoints are conditionally affected only when shared telemetry or artifacts connect them to the reported update activity; the supplied evidence does not support treating every AnyViewer installation as exposed.

Backup administrators, remote-access administrators, security operations teams, and incident responders must preserve and assess the relevant evidence. No affected version numbers or build boundaries for AOMEI Backupper or AnyViewer were supplied, and installation alone does not establish compromise.

1) Captured supply-chain analysis — support: it reports that server-side update configuration was altered, including the download URL, build value, and expected MD5, so legitimate AOMEI clients would accept upgrade-now.zip. It identifies AOMEI Backupper windows on May 28, 05:40–05:50 UTC; July 16, 08:33–08:39 UTC; and July 20, 10:35–10:40 UTC, while also reporting observed activity across April–July. It expressly distinguishes this distribution-control failure from proof that every installation was breached. 2) Operational decision analysis — support: it bases exposure and compromise tiers on update timing, retrieved artifacts, execution evidence, and command-and-control evidence rather than installation alone, and identifies privileged backup and remote-access endpoints as the priority population. 3) Evidence review — support: it confirms that the captured analysis recommends a scoped pause of in-application updates, preservation of historical telemetry and artifacts, independently authenticated replacement installers, artifact verification, and hunting for the reported execution chain. It also confirms that AnyViewer conclusions require shared telemetry or artifacts. 4) Source-completeness review — evidence gap: it finds that the underlying vendor and threat-research publications are not separately captured, preventing independent verification of the reported windows, product scope, attribution, and indicators.

The supply-chain analyst characterized the incident as server-side update-configuration manipulation rather than proof that every AOMEI installation was breached.

The decision analysis converted that distinction into a scoped response based on update timing, retrieved artifacts, execution evidence, and command-and-control evidence.

The evidence review supported pausing in-application updates, preserving telemetry, using independently authenticated replacement installers, and hunting for the reported malware chain, but found that the underlying vendor and threat-research publications were not separately available for verification.

The boundary review accepted the response only with the qualifications that the delivery windows and malware chain remain described as reported and that AnyViewer is not treated as affected without shared telemetry or artifacts. No prior matching decision was found.

The arbiter therefore selected a new operational decision: investigate higher-risk assets without declaring every AOMEI installation compromised.