Popcorn Time updater can execute remote code with full rights at startup

Key points

• Updater queries a remote domain and runs whatever code it receives.
• Execution occurs at startup with full privileges, allowing complete host takeover.
• Millions of installations are in scope; no CVE identifier was issued.
• Treat the update path as a high-value compromise route.

The Popcorn Time updater presents a high-severity security problem: it reaches out to an update domain and executes code supplied by that endpoint. That code is launched automatically when the machine starts and runs with full privileges, so a hostile update response could yield code execution from a remote source and total control of the host. No CVE identifier was issued for the issue.

The exposure is broad. Millions of endpoints that use Popcorn Time are within scope, and the updater is the critical link because it combines remote input with startup execution. An attacker who can influence the update response does not need a separate local foothold; the updater can become the entry point.

Why this matters: update channels are usually trusted, and this one carries code into a privileged context at boot. A failure there can turn a routine update check into system takeover. The absence of a CVE also means standard vulnerability feeds may not surface the risk, so defenders should not wait for a public identifier before acting.

What to watch: DNS, proxy, and firewall logs for the updater's domain; unexpected processes spawned during startup; and endpoints where Popcorn Time remains installed without a business need. Because the updater starts automatically, boot-time monitoring and startup-item review are especially useful.

What to do now

1. Inventory endpoints for Popcorn Time and its updater, prioritizing removal where there is no business justification.
2. Block the updater's update domain at DNS, proxy, and firewall layers, and alert on attempted connections.
3. Disable or remove the updater's startup entry so it cannot launch automatically during boot.
4. Restrict local administrator rights and monitor for unexpected high-privilege processes created at startup.
5. Hunt for signs of unauthorized code execution tied to update traffic, including boot-time process creation events.
6. If retention is required, isolate installations and require updates from a controlled, verified source.
7. Track vendor guidance closely; because no CVE exists, use internal advisories and blocklists for coverage.

Original source

SecurityWeek