You may have forgotten about Popcorn Time. Unfortunately, its updater didn’t forget about your device.

Security researchers have intervened to disable an abandoned update mechanism in Time4Popcorn, a version of the once-popular streaming app. If left running in the background, the updater could have allowed attackers to take control of Windows and Mac computers, even if their owners hadn’t opened the app in years.

Eye Security estimates that the vulnerable updater was present on millions of devices worldwide, including 2.5–3 million Windows computers and around 250,000–350,000 Macs.

Popcorn Time made watching movies and TV shows through BitTorrent look more like browsing Netflix. Rather than making users find torrent files and open them in a separate client, it wrapped the process in a familiar streaming-style interface.

Amid concerns about copyright infringement and its possible consequences, the original developers abandoned it shortly after its launch in 2014. But because its source code was publicly available, other developers could pick it up and create their own versions, known as forks.

One of those was Time4Popcorn, which was also distributed under the name “Popcorn Time.” That shared branding matters because people may have installed the affected software without ever seeing the Time4Popcorn name.

The problem at hand

Time4Popcorn was eventually abandoned too. But its update infrastructure was left behind, and at some point the domains associated with the software became available for others to register.

In other words, the people maintaining the software had gone away. The software’s ability to accept instructions had not. Time4Popcorn’s updater used unencrypted HTTP connections and accepted executable updates without checking digital signatures to verify their authenticity. So, someone who controlled an update domain or was able to tamper with the unencrypted traffic could supply their own program instead.

That combination created a remote code execution vulnerability, tracked as CVE-2026-30612, which could let an attacker run malicious software on a device. An attacker wouldn’t need to persuade someone to watch a movie or click a suspicious attachment. The forgotten updater could do the work for them.

Although Android was affected too, users had an extra layer of protection. Its updater checked for updates when the application was opened, but installing an attacker-supplied APK required the user to approve the installation. It was not the same silent, background takeover route researchers found on Windows and macOS.

What the researchers did

Eye Security registered an abandoned update domain and used the vulnerable mechanism to distribute an update that disabled the updater itself. On Windows, it stopped and disabled the service; on macOS, it prevented the update process from starting. The researchers say their intervention did not delete users’ files or collect host data.

By March 2026, Eye Security reported more than two million downloads of its updater-disabling fix, and update requests to its domains had fallen by 98%. Later that month, it transferred the 15 domains it controlled to the nonprofit Shadowserver Foundation.

Researchers could not remotely disable the Android updater in the same way. And the desktop application still contained other weaknesses, including an obsolete Chrome engine dating from 2014 and disabled sandbox protections, which normally help contain malicious code.

What users should do

If you used Popcorn Time years ago, check the devices on which you installed it. Don’t assume that no longer using an application means its background components have stopped running.

• Check your list of installed applications for Popcorn Time or Time4Popcorn. Pay particular attention to older Windows PCs, Macs, and Android devices where you may have forgotten about installing it. The affected fork was distributed under both names.
• Remove the old application. There is no vendor security update for the abandoned Time4Popcorn software. Disabling the updater addresses one vulnerability, not the application’s other security weaknesses.
• On Windows and macOS, check that the background updater is no longer running. Eye Security identifies the Windows component as Updater.exe, normally inside a Popcorn Time folder under Program Files or Program Files (x86), running through a service called Update Service. On macOS, the component is /Library/PrivilegedHelperTools/PT.updd, with a launch daemon at /Library/LaunchDaemons/PT.updd.plist. Its advisory provides instructions for disabling these components if needed.
• On Android, uninstall the affected app rather than accepting an update prompt from it. The updater is part of the main application and cannot easily be disabled separately.
• Use an up-to-date, real-time anti-malware solution to detect and block any attempts to install malware on your devices.

As we saw recently, cybercriminals can use software updates to distribute malware. Remove abandoned apps and check for any background updaters they leave behind.

From reporting threats to removing them.

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

You may have forgotten about Popcorn Time. Unfortunately, its updater didn’t forget about your device.

Security researchers have intervened to disable an abandoned update mechanism in Time4Popcorn, a version of the once-popular streaming app. If left running in the background, the updater could have allowed attackers to take control of Windows and Mac computers, even if their owners hadn’t opened the app in years.

Eye Security estimates that the vulnerable updater was present on millions of devices worldwide, including 2.5–3 million Windows computers and around 250,000–350,000 Macs.

Popcorn Time made watching movies and TV shows through BitTorrent look more like browsing Netflix. Rather than making users find torrent files and open them in a separate client, it wrapped the process in a familiar streaming-style interface.

Amid concerns about copyright infringement and its possible consequences, the original developers abandoned it shortly after its launch in 2014. But because its source code was publicly available, other developers could pick it up and create their own versions, known as forks.

One of those was Time4Popcorn, which was also distributed under the name “Popcorn Time.” That shared branding matters because people may have installed the affected software without ever seeing the Time4Popcorn name.

The problem at hand

Time4Popcorn was eventually abandoned too. But its update infrastructure was left behind, and at some point the domains associated with the software became available for others to register.

In other words, the people maintaining the software had gone away. The software’s ability to accept instructions had not. Time4Popcorn’s updater used unencrypted HTTP connections and accepted executable updates without checking digital signatures to verify their authenticity. So, someone who controlled an update domain or was able to tamper with the unencrypted traffic could supply their own program instead.

That combination created a remote code execution vulnerability, tracked as CVE-2026-30612, which could let an attacker run malicious software on a device. An attacker wouldn’t need to persuade someone to watch a movie or click a suspicious attachment. The forgotten updater could do the work for them.

Although Android was affected too, users had an extra layer of protection. Its updater checked for updates when the application was opened, but installing an attacker-supplied APK required the user to approve the installation. It was not the same silent, background takeover route researchers found on Windows and macOS.

What the researchers did

Eye Security registered an abandoned update domain and used the vulnerable mechanism to distribute an update that disabled the updater itself. On Windows, it stopped and disabled the service; on macOS, it prevented the update process from starting. The researchers say their intervention did not delete users’ files or collect host data.

By March 2026, Eye Security reported more than two million downloads of its updater-disabling fix, and update requests to its domains had fallen by 98%. Later that month, it transferred the 15 domains it controlled to the nonprofit Shadowserver Foundation.

Researchers could not remotely disable the Android updater in the same way. And the desktop application still contained other weaknesses, including an obsolete Chrome engine dating from 2014 and disabled sandbox protections, which normally help contain malicious code.

What users should do

If you used Popcorn Time years ago, check the devices on which you installed it. Don’t assume that no longer using an application means its background components have stopped running.

• Check your list of installed applications for Popcorn Time or Time4Popcorn. Pay particular attention to older Windows PCs, Macs, and Android devices where you may have forgotten about installing it. The affected fork was distributed under both names.
• Remove the old application. There is no vendor security update for the abandoned Time4Popcorn software. Disabling the updater addresses one vulnerability, not the application’s other security weaknesses.
• On Windows and macOS, check that the background updater is no longer running. Eye Security identifies the Windows component as Updater.exe, normally inside a Popcorn Time folder under Program Files or Program Files (x86), running through a service called Update Service. On macOS, the component is /Library/PrivilegedHelperTools/PT.updd, with a launch daemon at /Library/LaunchDaemons/PT.updd.plist. Its advisory provides instructions for disabling these components if needed.
• On Android, uninstall the affected app rather than accepting an update prompt from it. The updater is part of the main application and cannot easily be disabled separately.
• Use an up-to-date, real-time anti-malware solution to detect and block any attempts to install malware on your devices.

As we saw recently, cybercriminals can use software updates to distribute malware. Remove abandoned apps and check for any background updaters they leave behind.

From reporting threats to removing them.

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

Two critical vulnerabilities in PHP (CVE-2026-109618 and CVE-2026-109619) have been published. Both vulnerabilities carry a severe CVSS score of 9.2 (more technical details are in the Unit 42 Threat Brief). 

This is not just another high-severity vulnerability disclosure, it marks the opening chapter in a massive acceleration of cyberthreats that will define the foreseeable future. Because PHP is widely used globally (by some estimates, more than half of all websites), the sheer scale of this is massive. Navigating this new reality demands immediate imperatives, including continuous, proactive vulnerability discovery before adversaries weaponize code, and a modern defense strategy that pairs traditional patching with real-time virtual patching. At a footprint of 22 million exposed instances, relying on manual remediation cycles alone is not a viable defense.

For context, exposures are typically in the thousands, for example around 50,000 potentially vulnerable exposed instances for recent NetScaler vulnerabilities, and about 16,000 exposed instances of BeyondTrust, potentially vulnerable to CVE-2026-1731. Pervasive open-source software introduces an exposure footprint on an entirely different order of magnitude. 

This situation illustrates what I shared in Defender’s Guide to the Frontier AI Impact on Cybersecurity. We’re officially in a new reality, and this is going to be an ongoing cycle.

An Accelerating Cycle

The latest frontier AI models are extraordinarily capable at finding vulnerabilities in code. We’ll see these models continue to surface critical issues at a pace faster than ever before.

But here’s the challenge: As soon as patches for vulnerabilities are available, attackers will reverse engineer the patch, locate the root flaw, and target them in near real time. It simply takes too long to apply patches to every system. This vulnerability deluge demands urgency and new technologies, such as virtual patching, are needed.

What Organizations Should Do Now

(1) Assess Your Open Source Inventory

Given the unprecedented speed at which new, critical vulnerabilities are being found with frontier AI, organizations need the ability to understand their true exposure at a moment’s notice. Attack surface management solutions have never been more critical for finding these blind spots across your entire codebase and supply chain. You can’t protect what you can’t see.

Additionally, services like Unit 42 Continuous Frontier AI Defense put defender-grade AI models in the hands of defenders to find and fix vulnerabilities before attackers can weaponize them.

(2) Prioritize Remediation Based on Reachability

You have to reduce what is reachable by attackers. You can't instantly patch everything everywhere, so prioritize what needs to be fixed first based on attack-path reachability. Secure what must be accessible to the public internet, and evaluate your environments to understand which of those exposed PHP instances carry the most immediate risk. For example, Cortex Xpanse and exposure management are great tools for determining reachability and automating remediation.

(3) Secure your AI deployments

While not the main focus for these PHP vulnerabilities, rapid deployment of AI across organizations is expanding the attack surface. All AI deployments must be secure AI deployments.

(4) Mitigate and Ensure Attack Protections

While you coordinate patching with your development teams, ensure best-in-class protections are in place to block the actual exploits. Mitigate against potential attacks immediately through proactive virtual patching and reducing overall exposure. Deploying high-fidelity virtual patches across your network and cloud security provides the mitigation layer necessary to give your teams the time they need to update the actual software safely.

Our new Frontier Virtual Patching capability delivered preemptive coverage for these PHP vulnerabilities ahead of today’s public disclosure. Additionally, Palo Alto Networks customers are protected from exploitation of these vulnerabilities by Advanced Threat Prevention available on our next-generation firewalls and Prisma Access.

(5) Deploy Real-Time Security Operations

Autonomous AI-driven attacks will drive attack lifecycles to minutes requiring every SOC to achieve single-digit mean time to detect (MTTD) and mean time to respond (MTTR).

The Path Forward: Institutionalize Defenses

This isn’t a one-and-done situation. With frontier AI compressing the patch-to-exploit window to minutes, assessing exposure, prioritizing reachability, mitigating and ensuring attack protections must become a continuous, automated motion.

This is a pivotal moment. While the scale of the challenge presented by frontier AI is real, I’m confident in our ability to solve it. Take the steps to secure your organization today, and build the foundation needed to ensure the advantage remains with the defender.

The post Millions of PHP Instances Exposed - What Organizations Need To Do Right Now appeared first on Palo Alto Networks Blog.

AI agents and AI-enabled tools are fundamentally changing how work gets done. From coding assistants to Model Context Protocol (MCP) servers, autonomous tools now access sensitive data, execute commands, and modify local workflows directly from the endpoint. Traditional endpoint security models fail to offer the visibility or governance required to manage these autonomous actions.

The security gap is already significant. Only 6% of organizations have an advanced AI security strategy. And the fastest attacks can move from initial access to data exfiltration in just 72 minutes, according to the 2026 Unit 42 Global Incident Response Report. As AI adoption grows, teams need context to prioritize risk and experts ready to respond so the business can continue adopting AI with confidence.

Today, we are announcing Unit 42 Managed Agentic Endpoint Security (Managed AES). We built the service on Cortex AES, our AI-native endpoint security platform that provides visibility, contextual risk intelligence and protection for AI agents and artifacts. Managed AES adds 24/7 Unit 42 expertise to help organizations put those capabilities into action. Backed by Unit 42 threat intelligence, our experts provide AI governance, threat hunting, investigation and response, and AI-related cyber hygiene. They apply human judgment to turn contextual intelligence into policy recommendations and prioritized actions as the environment evolves.

Continuous Expert Defense for the AI Environment

Managed AES brings continuous Unit 42 expertise to four areas of AI endpoint security.

• Govern AI Adoption with Greater Confidence
  AI adoption often moves faster than security teams can assess it. Our experts help identify AI tools and associated risks, evaluate exposure and recommend improvements to policies and controls. Security leaders gain a clearer view of AI use across their environment.
• Hunt for Emerging and Zero-Day Threats
  AI-related threats can emerge before they trigger a known alert. Our threat hunters use frontline threat intelligence and Cortex AES signals to proactively hunt across the customer’s AI environment. They evaluate findings, recommend action and refine policies and correlation rules to strengthen protection over time.
• Investigate and Respond 24/7
  Our analysts continuously monitor activity, investigate suspicious behavior and take permitted actions on the customer’s behalf to contain AI-related threats. Security teams gain specialized support to understand what happened, determine the potential impact and prioritize next steps.
• Continuously Strengthen AI-Related Cyber Hygiene
  Unit 42 assesses the customer’s AI security posture as adoption evolves. AI Security Posture Reports identify policy and control improvements, while Threat Impact Reports detail threats, potential impact, response actions taken and recommended next steps. These insights help teams prioritize improvements.

Expert Protection Across Your AES Environment

Organizations can choose the Cortex AES deployment model that best fits their environment while receiving the same 24/7 Unit 42 expertise.

• Managed AES with Standalone Cortex AES
  Organizations can deploy Cortex AES alongside their existing endpoint security solution for AI-native visibility, contextual risk intelligence, governance and protection for AI agents and AI-enabled tools. Managed AES adds Unit 42 experts who help customers act on that visibility and risk intelligence.
• Managed AES with Cortex XDR One
  Cortex XDR One brings together Cortex AES and Cortex XDR into a single sensor and console experience. It combines endpoint detection and response with AI-native security for AI agents and artifacts. Unit 42 experts provide 24/7 governance, threat hunting, investigation and response across the entire endpoint attack surface.

Securely Scale AI Adoption

Unit 42 Managed AES helps security teams understand how AI is being used, address risk before it escalates and respond quickly when threats emerge. By combining Cortex AES context with frontline threat intelligence and expert analysis, Managed AES helps businesses adopt AI with confidence.

Register for our upcoming webinar, The Next Era of Endpoint Security, to learn how Cortex AES and Unit 42 experts help your team govern AI risks, strengthen visibility and protect the agentic endpoint.

The post Introducing Unit 42 Managed Agentic Endpoint Security appeared first on Palo Alto Networks Blog.

On a recent external network penetration test, the client's attack surface was quite small. From a tester’s perspective, that is usually bad news, because a handful of exposed services means only a handful of chances to find a way in. Luckily one host in particular jumped out at me, a Bosch Telex Remote Dispatch Console (RDC) Server.

A little research turned up Bosch advisory BOSCH-SA-992447, which maps to CVE-2025-29902, a CVSS 10.0 unauthenticated remote code execution vulnerability in the RDC's REST API, fixed in version 1.3.0 in May of 2025. The patch date on the web server's home page was "2023-07-29", leading me to believe the server was vulnerable. The bad news for me was that there were no public exploits available. I notified the customer who challenged me to demonstrate impact with a working proof of concept. This post walks through my journey trying to track down where the vulnerability was and how to exploit it.

Telex RDC is a dispatch console server used to drive radio communications, the kind of system you find behind dispatch centers for utilities, transit, and public safety. Per the Bosch advisory, the flaw lives in the REST API, affects all versions below 1.3.0, requires no authentication, and was responsibly disclosed by external researcher Omer Shaik. I managed to get in touch with the author of the exploit, but they were not willing to share a proof of concept.

Before I could analyze anything, I needed a copy of the old, v1.2 vulnerable software. The vendor's site offered the latest patched release, v1.3, which already had the fix implemented. Luckily, I was able to track down a download URL for the pre-patched version of Telex RDC, v1.2.

https://telex-downloads.s3.us-east-1.amazonaws.com/Releases/230809_v120_RDC_Server.zip

Now that I had both binaries, it was time to find out what had changed.

The textbook next move is patch diffing where you load both versions into a decompiler, compare them, and let the delta point you straight at the fix. I dropped both binaries into a fresh Ghidra project and ran a version diff, expecting a tidy little patch to jump out.

Ghidra version diff between v1.2 and v1.3

It did not. There were two full years and a complete UI overhaul separating v1.2 from v1.3. The diff was enormous, with thousands of changes and almost none of them related to the security fix. Trying to isolate the one patched code path in that sea of churn was a genuine needle-in-a-haystack problem.

This is the honest reality of patch diffing. It is fantastic when the vendor ships a small, targeted fix, and nearly useless when the vulnerable version is buried under a couple of years of unrelated feature work. Rather than burn the rest of the engagement squinting at decompiled functions, I switched approaches entirely.

If static analysis was going to fight me, I would let the application tell me where the bug was. I installed the RDC Server v1.2 on a Windows VM and stood up a local instance that I could poke at, without any risk to the client's production system.

Telex RDC Server local instance

I went back and reread the security advisory which gave me two extremely useful hints: the vulnerability was triggered over HTTP, and it did not require prior authentication. That narrowed the hunt to one question: which parts of the REST API can I reach without logging in?

So, I automated the question. I configured Autorize, the Burp Suite extension, to replay every authenticated request with the Authorization header removed, flagging any endpoint that answered the unauthenticated copy the same way it answered the authenticated one. Clicking through the entire admin interface with Autorize running produced a nice list of endpoints that were not enforcing authentication at all.

The endpoints reachable with no Authorization header are shown below.

/api/v1/resources?type=IMAGE_FILES
/SystemAdmin/views/activityLog.html
/SystemAdmin/views/selectorchooser.html
/SystemAdmin/views/audiofilechooser.html
/SystemAdmin/views/keylistener.html
/SystemAdmin/views/systemStatus.html
/SystemAdmin/views/radioChannels.html
/api/v1/ssl/status

One of the endpoints stood out from the others.

Autorize flagging endpoints that ignore authentication

The /api/v1/resources endpoint accepted uploads. My next step was to intercept the request in Burp Suite and look over the attack surface. I sent the unauthenticated POST and set the filename to a basic path traversal payload aimed at the root of the drive.

..\..\..\..\..\test.exe

To my amazement, the server responded with "204 No Content", indicating that no error had been encountered, so it was possible the file had been created on the server.

Unauthenticated arbitrary path traversal

Sure enough, browsing to C:\ on the VM showed my test.exe file sitting right there in the root of the drive. I was dumbfounded.

Unauthenticated path traversal successful

So, there it was. An unauthenticated attacker can write an arbitrary file anywhere on disk. That is the core of CVE-2025-29902. It is also, on its own, not remote code execution. Writing a file is only half the battle, because you still need something on the box to actually execute it.

My first idea was classic DLL hijacking. I fired up Process Monitor from the Sysinternals Suite and filtered on "Load Image" operations targeting DLLs under C:\Program Files\Telex\RDC Server\. The application loaded plenty of DLLs, but every one of them was already present on disk, so there was no missing DLL I could simply drop in. Exploiting that would have required DLL proxying.

ProcMon Load Image results, no missing DLLs to hijack

I kept exploring the application looking for a binary that would launch on demand. I found one. The web UI has a feature to regenerate the SSL configuration, and when you trigger it, the application shells out to a bundled openssl.exe living in the install directory.

The app launches its bundled openssl.exe during cert generation

That seemed to be a perfect target, a known, fixed path to an executable that the application itself runs, and one I can overwrite. The only catch was that triggering certificate regeneration requires being logged in, which brings us to the authentication bypass, courtesy of the same file write.

Poking around the install directory, I found SystemConfiguration.txt, which included the administrator username and password. The password appeared to be encrypted and Base64 encoded.

System configuration file with credentials on disk

I created a new Telex RDC server instance with a different username and password and made a copy of that configuration file.

Custom system configuration file

Next, I used the path traversal to overwrite the SystemConfiguration.txt with my modified version.

Overwriting the system configuration with new credentials

Once the service restarted, I logged into the administrator portal with username "jack" and password "admin". With admin access in hand, I used the file write one more time to overwrite openssl.exe with a compiled binary of my own. For a clean and harmless proof of concept, that binary just launches the Windows calculator.

#include <iostream>
#include <cstdlib>

int main() {
system("calc.exe");
std::cout << "Calculator opened. Press Enter to exit..." << std::endl;
std::cin.get();
return 0;
}

Overwriting the bundled openssl.exe as an unauthenticated user

Finally, I logged in with my credentials, browsed to System, then Certificates, then Install Self-Signed Certificate. The application dutifully invoked openssl.exe, which was now my binary, and up popped the most glorious calculator. Notably, it ran with administrator privileges, which meant full compromise of the server. The exploit chain was complete using an unauthenticated file write, authentication bypass, and another file write to finally achieve remote code execution as local administrator.

Proof of concept: arbitrary code execution as administrator on the RDC server

Back in my lab, everything worked but this exploit was scrappy, and there was no chance I was going to run the full chain against a live dispatch server. Instead, I proved reachability with the least invasive check possible, a single unauthenticated GET to /api/v1/resources against the production host. It responded just as the lab instance had, confirming that the vulnerable endpoint was exposed and unauthenticated, which was enough to prove exploitability without writing a single byte to the customer's system. I'm sure there are more elegant ways to get RCE with this path traversal, but this was the way I came up in the two days of testing available.

If you are running a Telex RDC Server, the mitigations are straightforward.

• Patch to RDC Server v1.3.0 or later, and VLink 6.6.0 or later. This is the single most important step.

To check if you are currently vulnerable, send an unauthenticated GET request to the /api/v1/resources endpoint. If you receive a "200 OK" response, the server is vulnerable.