Why Clean Software Updates Don't Always Mean a Secure Supply Chain

The security team receives an alarm for a trusted software updater. The vendor's download site is operating, the legitimate software package has a valid signature and there's no visible indication that anything has been altered. Everything appears legitimate, so it’s tempting to assume the alert was a false positive. 

But what if the attacker already put everything back before the investigation started? That’s the difficulty with security for software updates based on current checks. They can tell you if a package or server is trustworthy now, but they can't show what your systems got hours, days or weeks ago. 

Mandiant’s analysis in October 2026 showed how attackers exploited this gap by briefly changing the software update infrastructure and then putting it back the way it was. The results pose an uncomfortable dilemma for companies: How can you validate a software update when the evidence of its delivery is gone?

How Software Updates Can Be Compromised Without Changing the Software

When a program looks for updates, it doesn't always immediately grab a new version. It may first contact the vendor's server to get a configuration file including information about which version is available, where to download it, and how to check the downloaded file. These are instructions about how to distribute the software, not the software package itself. 

This leaves another possible channel into an organisation open to attackers. If an attacker gets control of the update configuration, they may be able to redirect the program to a malicious download. The vendor’s genuine software can be left alone, while the corrupted instructions send the application off to a whole different place. 

The attacker doesn't need to keep those instructions there forever. They can reconfigure it, wait for programs to check for updates, and then set the configuration back before anyone checks.

What the AOMEI investigation revealed

That's precisely the behaviour reported by Google Threat Intelligence Group and Mandiant in their October 2026 investigation of temporary software supply chain tampering on AOMEI's update infrastructure. Threat actors tracked as UNC7017 altered configuration files used by AOMEI Backupper’s update and notification functionality. 

These modifications routed apps to malicious downloads and misused the notification process to trigger execution. Researchers identified three especially brief episodes of tampering:

• 28 May 2026: 10 minutes
• 16 July 2026: 6 minutes
• 20 July 2026: 5 minutes

After each detected window, the attackers restored the legitimate configurations. Mandiant also warned that further instances of tampering may have gone unnoticed. If an application is checking for updates at any time outside those windows, it might receive perfectly legitimate instructions. During the attack, it could get malicious ones. 

That leaves investigators with a mystery. Later, when you come back to the same server, you don’t necessarily know what happened when the affected program reached out to it.

What Software Update Integrity Checks Actually Prove

Software update verification isn't one security check. There are various controls, each aimed at establishing something about the software or the way it's provided. Package integrity establishes whether a file matches the expected version. Update configuration integrity is about the directions that tell an application where that file is.

 Distribution infrastructure security covers the servers and services that distribute those instructions and downloads. Then there’s the issue of historical verification: what actually happened during a given update. An organisation may have tight controls in the first three categories but still struggle with the fourth. 

The problem isn't necessarily that its security checks failed. Those checks may never have been meant to answer enquiries regarding past delivery events.

Why a valid signature isn't the whole answer

Digital signatures are critical to software supply chain security. They enable systems to confirm that a file was signed using a trusted key, and that the contents of the signed file haven't been altered. But a verified signature on the vendor’s official installer doesn't imply that every client downloaded that installer. 

The attacker might alter the instructions that inform the application where to get an update. Whether the malicious download succeeds should depend on the client’s verification procedures, such as whether it rejects files that aren't properly authenticated. 

In the AOMEI example, the attackers modified both the download location and the expected MD5 checksum in the update settings. That’s why a hash provided through a corrupted configuration isn't independent confirmation of authenticity.

Why a clean update server may prove even less

Inspecting an update server after an incident establishes its state at the time of inspection. It doesn't establish what the server had delivered before. A configuration could have been altered and replaced. A download location might have been pointing somewhere else for a few minutes. 

If the changes weren't logged and archived, the current state of the server may offer minimal proof of either event. Here's where historical software update verification comes into play. Enterprises require records that allow them to analyse historical update activity without having to rely on what the vendor’s infrastructure looks like now.

How Enterprises Can Verify What Their Systems Actually Received

Security teams must therefore piece together the delivery process to be able to adequately evaluate a suspicious update. This involves looking backwards from the endpoint that was affected to see what instructions it received, where it connected and what happened after the download. This investigation has two sides. 

The vendor can offer evidence about the update it was trying to distribute and how its infrastructure behaved. The customer can provide evidence of what transpired in their own environment. Neither perspective necessarily tells the complete story.

Establish what the vendor intended to distribute

The starting point is the legitimate release. Investigators need to establish the approved version of software, its cryptographic hash and digital signature, and the instructions for updating that should have been applicable at the time in question. That means more than just having installers around. 

Vendors also need a solid history of the configuration files and metadata that were used to direct update clients. Useful records contain approved download locations, configuration modifications, release timestamps and proof of who or what approved those changes. These records serve as a baseline for comparison with questionable activity. 

Investigators can check whether an unknown download destination accessed by an endpoint was ever part of the permitted update procedure.

Reconstruct what the endpoint received

The next step is to see what the affected system actually did. An endpoint can also cache update configurations, downloaded files or application logs. Network security tools might also log connections to update servers and download destinations. Mandiant notably recommends keeping AOMEI’s cached configuration files and reviewing network telemetry from the exact time of suspected activity. 

Checking the current download URL of the vendor isn't enough, since the original response may have existed for only a few minutes. The investigation has to separate out a number of possible outcomes:

• Potential exposure: The application was present and may have checked for updates during the breach.
• Confirmed contact: Records indicate interaction with relevant infrastructure at the time in question.
• Confirmed delivery: Evidence establishes that malicious content reached the endpoint.
• Confirmed execution: Endpoint data reveals that the malicious content executed.

These aren't interchangeable findings. A connection doesn't always mean a download, and a download doesn't always mean execution. Correlating timestamps across application logs, network records and endpoint detection tools helps investigators understand how far the activity progressed.

Recognise where the evidence runs out

Sometimes there’s just not enough information to put together the whole transaction. Applications may overwrite cached configurations. Network logs might have expired. An endpoint monitor might log suspicious execution without saving the original download or the instructions that triggered it. 

In certain circumstances, investigators need to spell out what they’ve confirmed and what is in doubt. The absence of evidence isn't proof that a system was unaffected. Also, having a program installed during a known compromise window doesn't mean it was infected. 

This places a practical obligation on both suppliers and customers to keep the evidence needed to examine software delivery before an incident happens. When the relevant records have disappeared, some enquiries may no longer have reliable answers.

What Stronger Software Update Assurance Looks Like

Stronger software update assurance starts with protecting the instructions programs receive. It also involves retaining enough information to prove what happened if such measures fail. These are related aims, but they require different controls.

Protect the instructions, not just the package

One well-known way to secure software update information is the security model of The Update Framework. It uses cryptographically authenticated metadata, trusted roles and version information to help clients reject unauthorised changes, stale instructions and certain attempts to tamper with the delivery of updates. The premise is simple. 

An app shouldn't just blindly follow update instructions because they originated from a recognised server. AOMEI’s October 2026 incident response statement describes modifications made to address the exploited update mechanisms, including disabling the affected in-app update functionality and releasing Backupper 8.5.1. 

The company said it was still investigating the overall impact. These methods concentrate on the delivery process, but preventing another compromise is only part of the assurance challenge.

Preserve evidence that can be checked later

For historical accountability, you want records that can’t be readily changed without being noticed. The Sigstore Rekor transparency log demonstrates how metadata linked to signing can be stored in an append-only log that's cryptographically verifiable. This may help establish a history of recorded signing activity. 

But it doesn't automatically prove what file each particular endpoint downloaded or ran. Therefore, enterprises require a blend of authenticated update metadata, protected historical records and endpoint-level evidence. The goal is to make suspicious delivery activity more difficult to carry out and easier to investigate later.

What Enterprises Should Ask Their Software Vendors

Security certifications, vulnerability management and patching policies are already considered in most enterprise software assessments. Software update assurance needs more detailed questions about how updates are distributed and what evidence remains available afterwards. 

A vendor needs to guard against unauthorised alterations. Equally important is its capacity to explain what happened when something goes wrong.

Can the vendor prove what it distributed?

Look first at how the vendor tracks its approved releases and the instructions it uses to deliver them.

• Are update configurations authenticated and protected against unauthorised changes?
• Does the vendor maintain historical versions of update information and distribution settings?
• Can it detect when a configuration has changed and which systems or services authorised the change?

These questions help determine whether the vendor can distinguish between an intended distribution method and an unauthorised one.

Can customers independently verify what they received?

Enterprises should also determine what evidence still exists in their own environments.

• Can the application save authenticated update information or useful update logs?
• Can security teams identify download destinations and validate the downloaded files’ integrity without relying on a vendor assertion that comes after the fact?

The answers will depend on the program design and the monitoring tools available. What's important is to recognise those limits before an investigation starts.

Can both parties investigate an incident together?

Finally, ask about what happens when suspicious update activity is reported.

• How long does the vendor keep relevant records?
• What evidence can it share?
• Can it identify affected distribution windows and offer the technical details the customer needs to investigate their endpoints?

These discussions should identify who's responsible for evidence preservation, incident communication and investigative support. A provider with good current controls but no ability to reconstruct previous deliveries presents its customers with a crucial gap in their ability to assess exposure.

Final Thoughts: Software Update Trust Needs a History

A clean software update server is comforting, but that’s only half the story. If attackers can alter the delivery instructions and then change them back before anyone notices, inspecting the server later may not disclose much about what customers really received. 

Enterprises should consider not just whether a software package is legitimate, but whether its delivery can be verified over time. This includes securing update instructions, maintaining historical records and ensuring that vendor and customer evidence can be brought together during an investigation. 

As software updates grow more automated, those records will become an increasingly important part of enterprise security assurance. This is a good starting point for organisations examining their software supply chain security. 

EM360Tech looks at how organisations can strengthen security across interconnected systems, from checking trusted software to identifying the dangers hidden in the technologies they rely on.