Recently fixed vulnerabilities in the Plex Media Server are under active exploitation in attacks that, when successful, install malware, including cryptominers and residential proxy apps, a researcher said.
Plex fixed four vulnerabilities at the start of last month. Three weeks later, published CVE designations revealed five vulnerabilities, with one of them carrying a severity rating of 8.6 out of 10. A researcher last week revealed an exploit that chained four of them together to achieve remote code execution of the device running a vulnerable Plex version. The researcher named the chain “Plex2Shell.”
Complex exploit chain
The new details allowed a separate researcher to create a honeypot that could track attempts in the wild to exploit the vulnerability chain. Within a day, the researcher began seeing active scanning of the simulated Plex server and eventually successful attempts to infect devices. So far, successful attacks are installing two payloads. One is a cryptominer, which uses the device to mine cryptocurrency and deposit it into a wallet controlled by the attacker. The other payload is residential proxy software, which allows people to anonymize their Internet activity (much of it illegal) by connecting to the infected box and then using it to send the user’s traffic to a final destination.
“Plex may be hosted on residential IP [sic] and I think threat actors would love to have residential IP proxy to access corporate VPNs and emails,” the second researcher wrote.
The published exploit chain was part of a proof-of-concept attack that the first researcher included when submitting a bug report to Plex. The complex code completes a series of steps, including performing an unauthenticated SSRF, a loopback pivot, a security token theft, a payload delivery, and finally the execution of the payload. The bug finder said he used AI “heavily” to develop the exploit chain. Steps included:
- Recon: Break the system into logical components. Map every path from user input to a dangerous sink.
- Hunt: Focused vulnerability hunt per component.
- Verify: Spawn a separate agent to try to disprove each finding. If it can’t refute the bug, it’s likely real.
“This was not a matter of telling the LLM ‘go hack Plex,’” the researcher wrote. “It was hours of iterative work, dead ends, and reprioritization. All of the judgment calls on what to look for and what to prioritize were mine. The LLM speeds this process up significantly, allowing me to stay at a higher level and simply guide the process.”
Plex representatives didn’t immediately respond to questions.
Anyone using Plex should ensure it’s running version 1.43.3. The software can be configured to install updates automatically, or users can manually download and install them. Given the active exploitation, outdated versions should be updated immediately. Beyond that, users should devote care to properly securing the media servers. The safest option is to restrict its access to local networks with no exposure to the Internet. This option prevents being able to use many useful features, though. One option when connecting a device to the open Internet is to route traffic through a reverse proxy, instead of using the default port 32400. Users should also use only secure Plex apps. And of course, strong passwords are a must.
Do I need to do anything else to check if my server has either of these exploits installed, or is simply updating my server enough to fix it if I am affected?I forgot to uninstall Plex from my server when I moved to Jellyfin after they started requiring a Plex Pass to stream from outside your own network. Seeing this article reminded me to go check and sure enough it was still installed and got hacked. Wasn't real bad, they just installed a cryptocurrency miner and made a weak attempt at persistence by setting up a crontab entry for the plex user. They made no attempts to clean up or obfuscate what they'd done. Here's what I saw that you can check for:
The files .px_7c1e, cert.pem, cert_key.pem ce.sh, config.json, deploy.sh, libcow.so, k.sh, plexmediaserver.state, w3.sh & x.sh (among others) in /tmp along with the directory .pxb. Delete all the files and directories owned by the plex user in /tmp directory.
Also look for /var/lib/plexmediaserver/, especially the directory softwaretechreview. That contains a file named watchsoftware.sh that handles relaunching the miner. You should delete the whole plexmediaserver directory and everything under it. The watchsoftware.sh file is called from the crontab of the plex user, which is located in /var/spool/cron/crontabs. There should be no entry for plex there, if there is one delete it.
You'll also see extremely high load that can make doing things even from the command line via SSH difficult. For me it was w3.sh showing high load. That file doesn't appear to be the cryptominer itself, so I may have caught the hack as it was happening and nipped it in the bud. I couldn't actually find the cryptominer file (softwaretech) that's referenced in w3.sh anywhere, so it's also possible their hack wasn't fully successful. Or that both are true and I killed the hack before it could complete.
As for why it was out of date, the Debian source repository I used for Plex was no longer online, so it had stopped getting updated and I didn't notice it.

