An auto-updater is a trusted channel into every user's machine, so attackers study it. The project that maintains The Update Framework describes four scenarios: freezing updates, rolling back to an old version, serving a version that is newer but not newest, and signing malware with a stolen key. Good designs address each one.
Why a plain signature is not enough
Many updaters only check that a downloaded file has a valid signature. That blocks an outsider with no key. It does not stop an attacker who can serve you an older signed file, or who can withhold news of a fix. The signature says the file is genuine, not that it is current.
The four scenarios
Freeze. The attacker keeps serving the same file, so the client never learns an update exists. A vulnerable version stays in place for as long as the attack lasts.
Rollback. The attacker serves an older, insecure version that the client had already moved past, and presents it as the update.
Newer but not newest. The attacker serves a version that looks newer to the client but is not the latest, and it may still be exploitable.
Key compromise. The attacker steals the signing key and signs a malicious file. It passes verification, because it is correctly signed.
What the framework adds
Per the project's overview, signed metadata lists trusted signing keys, hashes of files, signatures on the metadata, version numbers and expiry dates. The client checks downloads against that metadata. Expiry dates make a frozen feed detectable, since stale metadata stops being trusted. Version numbers let the client refuse to go backwards. Separating keys and limiting what each can sign is one of the design goals to reduce harm from a stolen key.
What you can apply without adopting a framework
- Sign update metadata, not only binaries, and include a version number and a short expiry.
- Make the client refuse any version lower than the one installed.
- Use more than one key, with the release signing key kept offline or in hardware. See where to keep code signing keys.
- Have a revocation story ready, with a way to ship a fix to users whose key you must retire.
- Alert if your own update server stops serving expected metadata.
For connected devices, the ETSI based checklist in IoT secure update design and OTA update threats go deeper.
Testing your updater
Write tests for the attacks, not only the happy path. Serve an older signed build and confirm the client refuses it. Serve stale metadata and confirm it is rejected after expiry. Block the update server and confirm the client reports a problem rather than silently staying put. These tests are cheap to automate and they catch regressions when someone refactors the update code.
Quick check
If my updates are signed, can an attacker still push an old version?
Yes, unless the client tracks versions and refuses to go backwards, or metadata expires.
What if the signing key is stolen?
Plan for it in advance, with separate keys, hardware storage and a tested recovery path.
Sources
Last reviewed: 19 October 2026.
