Between November 2025 and March 2026, Dutch firm Eye Security pushed more than 2 million updates onto computers it did not own. The payload shut off Time4Popcorn’s background updater, an abandoned fork of the Popcorn Time BitTorrent streaming client that still checked in for new binaries. If you run endpoints, this is the cybersecurity story that should rearrange your inventory: leftover auto-update channels keep taking orders after the vendor walks away.

Those hosts never opened a ticket. They never landed in your patch SLA. They still had a remote socket that would accept a package, and Eye Security used it before someone else did.

2 million kill updates landed on hosts nobody owned

Time4Popcorn is a leftover clone of Popcorn Time, the free app that streamed pirated films and TV over BitTorrent and then splintered into forks as legal pressure and maintainer burnout did their work. The product went quiet. The updater did not. Eye Security watched a background component keep polling for instructions on machines scattered across the public internet, including, you should assume, laptops that sometimes join your corporate network.

The firm spent roughly five months pushing disablement updates, more than 2 million of them, to switch that component off. A security company remotely changed software on computers it did not own, at botnet scale, because the alternative was leaving a loaded gun on the table. Anyone who captured the update infrastructure, the domain, the signing material, or the server that answered those check-ins, could have shipped a miner, a proxy, or a ransomware loader instead of a kill switch.

You can argue about consent. Lawyers will. Operators should argue about ownership. If a process on a PC will install code because a familiar URL said so, that process is a control plane. Eye Security treated it like one. So will the next crew that finds an unattended update origin. Your firewall never arbitrates this. The client dials out. The allow-list already trusts “the vendor.”

Abandoned Time4Popcorn updater remained a live command channel

Most threat detection is tuned for the fight you expect: brute-force noise against VPN, commodity loaders, the odd PowerShell spike. An abandoned updater fails those signatures on purpose. It looks like maintenance. It uses the same HTTPS path it used when the app was alive. Scheduled, polite, persistent.

That is why leftover updaters beat a lot of threat-protection tooling. You score inbound exploits and known malware families. You underweight a helper binary that has talked to the same host for years. Defense in depth assumes each layer knows what is talking. The inner layer here was a process nobody listed in the build image, running under a user who installed a movie app at home and then docked at work.

The real problem here is custody of the update origin. When maintainers vanish, DNS registrations lapse into auction, TLS certificates auto-renew on a forgotten card, and package repositories sit with a single stale token. You do not need a clever exploit against the client. You need the keys to the thing the client already trusts. Cyber security programs spend heavily on the EDR agent they chose. They spend almost nothing proving that every other self-updating binary still has a living owner.

Popcorn Time’s forks made this visible because the user base was huge and the maintainers were gone. The same shape shows up in old printer utilities, conference-room optimizer apps, codec packs, vendor remote-support tools left behind after a break-fix, and proof-of-concept agents from last year’s incident that someone forgot to uninstall. If it can fetch a binary and execute it, it is command-and-control with better branding.

Leftover auto-updaters belong on the cybersecurity inventory

Stop treating auto-update as a comfort feature. Treat it as privileged remote execution that you have to authorize, monitor, and revoke. You can do this without buying a platform. You need an owner for every self-updating binary and a hunt that actually runs.

Do the immediate work this week, then put the follow-up on a calendar you keep.

• Enumerate services, scheduled tasks, and LaunchAgents whose image path or description includes update, updater, helper, or the name of software you do not support.
• Alert on periodic outbound HTTPS from unexpected binaries that fetch an executable, catalog, CAB, or MSI.
• Remove abandoned clients, then block their update hosts at DNS and egress so a reinstall fails closed.
• Assign an expiry owner to every approved updater; if the vendor is dead, the control is uninstall.

Security hardening that leaves the leftover service running is a checkbox. Pull the binary, pull the task, pull the local exception, and confirm with a capture that the callback is gone. If you only flip a UI toggle, you have no proof. Reimage the worst offenders when the updater bundled other helpers you cannot unwind cleanly.

Approved updaters still need the same skepticism. Pin them to known hashes where you can. Watch the destination. A hijacked vendor channel looks like a successful patch to everyone except the team that diffs binaries. You already learned that lesson from poisoned package indexes. Apply it to the quiet clients that never make the sprint board.

Incident response must cover software you never approved

Your playbooks start from assets you meant to have. Time4Popcorn never asked your CISO. Neither did the other abandoned utilities living on contractor laptops, lab PCs, and the temporary jump box that became furniture. When Eye Security can reach 2 million endpoints through one neglected protocol, you should assume an unfriendly operator can reach the handful of those endpoints that sit on your DNS.

Build a shadow-client lane in incident response. If threat detection flags a rare updater domain, do not close it as junkware and move on. Isolate, collect the update URL and any signed catalog, revoke local admin if the user installed it, and search the fleet for the same image hash. Treat the update origin as hostile infrastructure until you prove who holds it.

Guest networks and BYOD make this worse. A home-installed piracy client that roams onto corporate wifi still originates trusted-looking update traffic from your address space. Split-tunnel policies and “allow known CDNs” rules will ferry it. Put consumer auto-updaters in the same mental bucket as unapproved remote-support tools: they expand the number of people who can run code on a box you think you manage.

Eye Security chose to burn the channel down at internet scale. You cannot copy that move inside a company without change control, and you should not wait for a researcher to do it for you. Find the updaters. Kill the ones with no owner. Watch the ones you keep. The next package that travels that path will not arrive with a note about public interest.

Sources

• Researchers Push Over 2 Million Updates to Remotely Disable Popcorn Time Updater That Could Fuel a Botnet