They remotely shut down a pirated updater on 2 million devices

An orphaned updater, an open door

Between November 2025 and March 2026, the Dutch security firm Eye Security sent more than two million updates to computers that were not theirs. The goal was not to install new software, but to shut down a background updater that, according to its researchers, could have allowed a third party to take control of the machine. That updater belongs to Time4Popcorn, an abandoned copy of Popcorn Time, the free application that streamed pirated movies and TV shows over BitTorrent.

The important detail is not the pirated content, but the mechanics: a component that runs with privileges, that connects to a remote server to look for new versions, and that no one maintains anymore. When the original project ceases to exist, that update channel is left orphaned. And an orphaned channel is, in practice, an entry point without an owner.

Why this should matter to an SMB

At first glance it looks like a problem for home users who install pirated software. But the pattern repeats in corporate environments more often than one would like. Think of a sales rep's laptop, an intern's computer, or a meeting room PC where someone installed an application to watch a TV show. That computer, months later, is still sending requests to a server that may have changed hands.

The news is about an updater that could feed a botnet. That is, the risk is not only that the computer gets infected: it is that it becomes part of a network of machines controlled from outside and used to launch attacks against third parties. For an SMB, that translates into two simultaneous problems. The first, technical: a compromised device inside the network. The second, reputational and legal: malicious traffic leaving from the company's IP.

An unmaintained updater is a door that no one watches. And doors that no one watches are the ones most used.

The updater as an attack surface

Automatic update mechanisms are convenient, but they concentrate enormous power: they run with elevated permissions, connect to the internet, and download code that they then execute. If the update server is compromised or simply disappears, the mechanism keeps running blindly. It is a pattern we have seen in other contexts: when a piece of infrastructure stops receiving maintenance but remains active, it becomes the weak link.

This case has a particularity that makes it more interesting: the researchers did not wait for users to uninstall anything. They sent legitimate updates, signed by them, to computers belonging to others in order to disable the component. It is a surgical intervention and, at the same time, a wake-up call about how much trust we place in update channels. If a third party can send an update that shuts down a service, it could also, in theory, send one that does something else. The difference between both situations is who controls the signature.

What we recommend at ForgeNEX

You don't need to be a large corporation to apply the lessons of this incident. These are the measures we suggest to our clients:

• A real software inventory, not a theoretical one. The list of approved applications is not enough. You need to know what runs on each computer, including what arrived through informal channels. Inventory and endpoint management tools help, but periodic review is what makes the difference.
• A clear installation policy. If the user can install anything, the perimeter blurs. A catalog of allowed software and a procedure for requesting exceptions reduce risk without stifling operations.
• Control of orphaned updaters. Review which applications have scheduled tasks or active update services and check whether the vendor still maintains them. If the project is abandoned, uninstall or block it.
• Segmentation and controlled internet egress. A compromised computer should not be able to talk freely to any domain. Filtering outbound traffic and monitoring connections to unknown servers detects these cases before they escalate.
• Patch management with judgment. Updating is necessary, but so is knowing what is updated and from where. An unverified update channel is as dangerous as a pending patch.

This incident connects to an idea we repeat often: an SMB's security does not depend on having the most expensive product, but on knowing its own terrain. We saw it with the exposed Fortinet and Palo Alto credentials, where the problem was not the vendor but careless access management. And we see it here: an abandoned program that is still alive on thousands of computers because no one reviewed it.

ForgeNEX's analysis

Eye Security's intervention is an unusual example of external responsibility: someone decided to shut down a risk that users were not going to shut down themselves. But we cannot depend on outside researchers to clean our computers. The lesson for an IT team is twofold. First, treat updaters as part of the attack surface and not as an invisible function. Second, accept that abandoned software is technical debt with security consequences.

If your company has computers with applications that no one remembers installing, that is the starting point. An honest inventory, a sensible installation policy, and a review of update channels are enough to close most of this exposure. There is no need to wait for a third party to send two million updates to discover that we had an open door.

Source: The Hacker News. Analysis and adaptation: ForgeNEX.