How secure software updates work: signatures, HTTPS, TUF and what a safe updater checks

In short

A secure software updater has to answer three questions before it runs anything: is this file really from the publisher, is it the file I asked for, and is it the newest one? Digital signatures answer the first, HTTPS helps with the second and third on the wire, and frameworks such as The Update Framework (TUF) add the metadata that defends against rollbacks, freezes and stolen keys. This week's Popcorn Time updater flaw (CVE-2026-30612) had none of them: it fetched a link over plain HTTP and ran the result as the most privileged user.

Why updaters are an attractive target

An updater is code the user has already trusted, often running with full privileges, that regularly downloads other code and runs it. The OWASP Top 10 (2021) makes this its own category, "Software and Data Integrity Failures". It describes applications whose auto-update functionality downloads updates "without sufficient integrity verification" and applies them to the previously trusted application, so that attackers "could potentially upload their own updates to be distributed and run on all installations". It also lists CWE-494, "Download of Code Without Integrity Check", among the notable weaknesses.

The same page names two real-world patterns. One is unsigned firmware on routers and set-top boxes. The other is the SolarWinds Orion attack, where, OWASP says, the vendor had secure build and update integrity processes that were still subverted, and a malicious update went to more than 18,000 organisations, of which around 100 were affected. That shows the two ways updates fail: the channel can be attacked, or the source can be.

Step 1: Check who published the file

The basic fix is a digital signature. The publisher signs each release with a private key; the updater carries the matching public key and refuses a file whose signature does not verify. OWASP's first prevention advice is exactly this: use digital signatures or similar mechanisms to verify the software is from the expected source and unaltered.

Signing alone does not stop the updater from being fed the wrong thing, and it protects nothing if the check is missing. The Popcorn Time fork's updater, according to Eye Security's analysis, accepted a JSON reply with a link to an executable, downloaded it and ran it as NT AUTHORITY\SYSTEM, "with no code signing", over HTTP. Anyone who controlled one of the domains it contacted, or who could tamper with the traffic, could run code on the machine.

Step 2: Protect the channel

HTTPS encrypts the connection and authenticates the server, so a network attacker (a hostile Wi-Fi, a compromised router) cannot silently swap the download. It is necessary but not sufficient: if an attacker controls the server, or registers an expired domain the updater still points to, HTTPS will happily deliver their file. That is the second half of the Popcorn Time problem. Eye Security found update domains that were no longer registered; by registering them, the firm saw requests arrive at about 50 per second.

The lesson for developers is to pin what the updater trusts. Ship the publisher's public key inside the app and verify signatures regardless of where the file came from, so that a lost domain cannot turn into code execution.

Step 3: Defend against stale and withheld updates

Even correctly signed files can be misused. The TUF project catalogues attacks that signatures alone do not stop. From its security page:

• Rollback attacks: an attacker serves a file older than the one the client has, which may contain known vulnerabilities.
• Indefinite freeze attacks: the attacker keeps serving files the client has already seen, so it never learns an update exists.
• Fast-forward attacks: the attacker inflates version numbers in metadata so real updates look like rollbacks.
• Mix-and-match attacks: the client is shown files that never existed together in the repository.
• Endless data attacks: the server answers with an endless stream of data, filling disks or exhausting memory.
• Key compromise: a single stolen signing key lets the attacker sign malicious files that verify.

TUF's answer, as its overview describes, is to add verifiable metadata about the repository: which signing keys are trusted, cryptographic hashes of files, signatures on the metadata, version numbers and an expiry date after which the metadata is considered stale. The updater checks downloaded files against that metadata and hands them over only if they match. TUF is designed for the first two steps of an update (knowing that one exists, and downloading it), while the application still applies it. The project says its goals include limiting the impact of a key compromise, which it does by spreading trust across several keys and roles rather than relying on one.

TUF's overview also groups updaters into three kinds that behave similarly: application updaters (it gives Firefox as an example), language package managers such as pip with PyPI or Composer for PHP, and system package managers such as APT and YUM.

Step 4: Protect the build and the publisher's accounts

The strongest updater cannot help if the release pipeline is compromised. OWASP recommends controls on the pipeline itself: review of code and configuration changes, segregation and access control in CI/CD, and trusted repositories for dependencies. We have covered what happens when this fails: in LiteLLM 1.107.0 on PyPI, a release was a credential stealer, and OVHcloud CLI releases 0.11.0 to 0.15.0 were swapped for a secret-stealing build. In those cases the update channel worked as designed and delivered what the publisher's account appeared to publish, which is why key protection and account security matter as much as the client's checks.

A worked example: what the Popcorn Time updater skipped

Mapping Eye Security's findings onto the steps above shows how many checks were absent at once:

• No signature check. The updater would download any executable it was pointed to and run it with SYSTEM privileges on Windows or root on macOS.
• No protected channel. Requests and replies went over unencrypted HTTP, so anyone who could manipulate a user's traffic could answer instead of the real server. Eye Security points out that governments have used insecure update processes to install spyware on dissidents' PCs, and that even joining an unencrypted Wi-Fi network could put a user at risk.
• Domains nobody controlled. Several of the update domains were unregistered or held by third parties, some parked and offered for sale. Whoever registered one could answer every client that asked. Eye Security registered one and watched requests arrive continuously, then counted over 3.8 million hardware IDs in six months.
• No vendor to patch. The usual response to a flaw, a patched release, was unavailable: the fork's maintainers were anonymous and had lost control of the domains. That is why the firm resorted to serving a disabling update itself, which reduced update requests to its domains by 98% by 1 March 2026.
• A stale runtime. The application itself is built on a 2014 Chrome engine with the sandbox off, so even a safe updater would not make it safe to use.

None of this required a sophisticated attacker. The conditions for abuse were an expired domain and a client that trusted whatever it was told. The same conditions can exist in any program left running after its maintainers walk away, which is why the checklist above includes an end-of-life plan.

A checklist for developers

1. Never download and execute code over plain HTTP.
2. Verify a signature against a key shipped with the application, not one fetched alongside the update.
3. Make the updater reject older versions than the one installed.
4. Use expiring metadata so that a frozen or abandoned server cannot keep clients on a stale view forever.
5. Run the updater with the least privilege that works; avoid SYSTEM or root where a user-level update will do.
6. Plan for the end of life of your project: when you stop maintaining software, ship a final version that disables the updater or point it at a server you will keep controlling. An abandoned updater that looks up domains no one owns invites exactly the situation Eye Security found.
7. Protect signing keys and release accounts with offline keys, multi-person approval and multi-factor authentication.

What users can do

• Uninstall software you no longer use, especially anything abandoned. Forgotten programs with background updaters are an inventory problem; the Popcorn Time updater was found running on machines whose owners had probably forgotten it, per Eye Security.
• Keep the operating system and browser updating from their vendors, which use signed updates.
• On a managed network, use software inventory to find tools that are running updaters.

Sources

• OWASP Top 10:2021, A08 Software and Data Integrity Failures
• The Update Framework (TUF): Overview
• The Update Framework (TUF): Security
• Eye Security: Operation IXIM
• Eye Security: CVE-2026-30612