A freeze attack keeps a client on the same file so it never learns an update exists. A rollback attack serves an older, vulnerable version as if it were the latest. Both work with real signatures, because old files were genuinely signed once.
Definitions
According to The Update Framework (TUF) overview, update systems face several attacks:
- Freeze: the attacker keeps giving you the same file, so you never realize there is an update.
- Rollback: the attacker serves an older, insecure version disguised as newer, and the client installs it.
- Mix-and-match: the attacker serves a file that is newer to the client but not the newest available, and it may be exploitable.
- Key compromise: the attacker steals a signing key and signs malicious files that pass verification.
The overview does not use every one of these labels, but the scenarios it describes map to them.
A worked example
Suppose version 4.1 of a game launcher fixes a code execution bug. An attacker who controls the update path wants users to stay exposed.
- With a freeze, the feed keeps saying 4.0 is current. Nothing is forged. Users simply never see 4.1.
- With a rollback, the feed offers 3.9, which carries a valid signature from last year. A client that only checks the signature accepts it.
Signature checks alone do not stop either one, because the files are real.
What defends against them
TUF's metadata includes trusted signing keys, file hashes, signatures, metadata version numbers and expiration dates. Two of those fields do the work here:
- Expiration dates mean a frozen view eventually goes stale and the client can notice that the metadata is too old.
- Version numbers mean the client can refuse metadata or files older than what it has already seen.
A simple desktop updater that compares a plain version string and trusts a signature does not get these properties by default. If you build your own, add a minimum accepted version and a freshness limit. If you adopt a framework, read what it checks.
Questions to ask about your updater
- Does the client refuse a version lower than the one installed?
- Does signed metadata expire, and what does the client do when it has expired?
- Can the client tell the feed is stale?
- Who can write to the place update files live?
Try it yourself
The zero day demo shows how quickly a newly disclosed flaw becomes urgent. Click through it and imagine a frozen update path during that window.
Click through it at your own pace, or open it full screen.
Quick check
Does code signing stop a rollback?
Not by itself. An old release was validly signed, so a client that checks only the signature may accept it. Version checks and signed metadata with expiry address this.
Are these only a problem for large vendors?
No. Any app with an update channel has the same shape of risk. The effort to defend is small when planned at the start.
Safeguard's zero day discovery and reachability analysis help you see which flaws matter to a shipped app, so a frozen update path is less likely to leave you blind. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
