--- title: Plex vulnerabilities being exploited in the wild to drop... description: A security researcher set up a honeypot after Plex disclosed critical vulnerabilities (CVE-2026-96652, 96654, 96655, 96656) affecting Plex Media Server v1.43.2... canonical: https://daily.dev/posts/plex-vulnerabilities-being-exploited-in-the-wild-to-drop-a-cryptominer-mvs9muvxb twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Plex vulnerabilities being exploited in the wild to drop a cryptominer | daily.dev og:description: A security researcher set up a honeypot after Plex disclosed critical vulnerabilities (CVE-2026-96652, 96654, 96655, 96656) affecting Plex Media Server v1.43.2... og:url: https://daily.dev/posts/plex-vulnerabilities-being-exploited-in-the-wild-to-drop-a-cryptominer-mvs9muvxb og:image: https://api.daily.dev/og/posts/Mvs9MuvxB.png og:image:alt: Plex vulnerabilities being exploited in the wild to drop a cryptominer og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Plex vulnerabilities being exploited in the wild to drop a cryptominer **[Hacker News](https://daily.dev/sources/hn)** · 4 min read · 0 upvotes · 0 comments ## Summary A security researcher set up a honeypot after Plex disclosed critical vulnerabilities (CVE-2026-96652, 96654, 96655, 96656) affecting Plex Media Server v1.43.2 and earlier, chained together by the plex2shell exploit to achieve remote code execution. Starting Oct 17th 2026, in-the-wild exploitation was observed from multiple IPs, dropping a Docker-based cryptominer (xmrig) and later a proxy tool called myawesomeproxy. The post includes IOCs, file hashes, pcaps, and links to the original researcher's code and detection signatures, along with ongoing updates as the researcher monitored continued attacks. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What CVEs are being exploited in Plex Media Server v1.43.2 and earlier? CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, and CVE-2026-96656 were chained together by researchers (via the plex2shell project) to achieve remote code execution on vulnerable Plex Media Server installations. Plex disclosed the security update on September 1, 2026, and in-the-wild exploitation attempting to drop a cryptominer was first observed around October 17, 2026. _Admins patching Plex servers can track emerging exploit chains and IOCs on daily.dev._ ### What payload do attackers drop after exploiting the Plex RCE vulnerability? Attackers deliver a Docker-based cryptominer (xmrig) after gaining remote code execution, with file hashes published for detection. A separate tool called myawesomeproxy was also observed being deployed, acting as a residential IP proxy and displaying a message warning that running it permits external use of the victim's internet traffic. _Those hunting cryptomining and proxyjacking malware can follow fresh IOC writeups on daily.dev._ ### Which IP addresses were observed exploiting the Plex2Shell vulnerability chain? Exploitation attempts came from 45.194.92.222, 91.92.40.202, and 176.65.139.228, with a malicious file download observed from 217.60.194.116. The attack path involved a crafted request to the Plex timeline subscribe endpoint chained to a local agent search function to achieve server-side request forgery and remote code execution. _Security teams building detection rules can track IOC disclosures like these on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 44 comments across hackernews (as of 2026-10-20). **TL;DR:** Discussion centers less on the vulnerability itself and more on whether exposing Plex (or any self-hosted media server) to the internet is reckless, with many defending the practice as necessary for non-technical friends/family and others recommending Tailscale or VPNs instead. **Sentiment:** 10% positive · 35% mixed · 55% skeptical **The case for** - Several people note Plex's convenience for non-technical friends/family and cross-device support is the whole reason they accept the exposure risk. - Some argue the risk is manageable since access is authenticated and no worse than exposing any other software. - One commenter mitigates risk by running Jellyfin in ephemeral, read-only containers that are destroyed after each use. **The pushback** - Multiple commenters call exposing Plex to the internet terrifying or reckless, especially on NAS devices like Synology that run outdated Docker/package versions. - Several report being personally hit by cryptominers (icloud-services, mylovelyminer) via Plex or OS vulnerabilities, with cleanup being annoying. - Critics argue non-technical friends/family alternatives (Tailscale, VPN) are hard to explain or configure on devices like Android TV/Fire Stick. - Complaints that Plex doesn't force automatic updates, leaving many servers unpatched for months. - Separate gripes that Plex's recent UI overhaul (shared codebase) made the app slow and unusable on non-PC devices, pushing some toward Jellyfin. **By community** - hackernews (heated): A long, contentious thread debating whether exposing Plex/Jellyfin/NAS devices to the internet is reckless or a necessary tradeoff for sharing media with non-technical users, alongside side-threads on Synology reliability, Tailscale as an alternative, personal cryptominer infection stories, and complaints about Plex's slow UI and lack of forced auto-updates. **Hottest debate:** Whether it's reasonable/safe to expose a Plex (or similar) media server directly to the internet versus requiring VPN/Tailscale access. **Open questions** - Is there any solid evidence that Plex is more insecure than comparable self-hosted software, or is that reputation unfounded? - What's the best way to give non-technical friends/family easy access without exposing a server directly to the internet? **Highlights** > > This is terrifying. Who runs things like this open to the outside? A budy of mine has got 30 000 movies and series. Better offer than Netflix (what, easily 4x more choice!?). He's got a 42U rack. He gives free access to his server to his friends and family: it's not a business (so what he risks is also very limited in the country he lives in, for he's not making a business out of it). It's not because you and I don't run Plex servers accessible from the big bad Internet that others don't enjoy doing it. Now concerning this miner: I've posted about it in the past here on HN but I only run Jellyfin on my LAN and it's only with throwaway containers: I've got a script that sets up movies/series named/organized the way Jellyfin likes it, then that volume is passed read-only to a transient podman container. When we're done watching the movie, the podman container is deleted. It's over: it doesn't exists anymore. All that I care about are data: like family pictures and movies (and, say, other movies). My Jellyfin server is just a temporary "view" on my actual data. I don't trust it and don't need to trust it: for it's only future after I'm done watching the movie is to be destroyed. > — [TacticalCoder on hackernews · 2 comments](https://news.ycombinator.com/item?id=50156120) > I got hit with a cryptominer on my mac mini the other day. I only noticed because I happened to sitting in the room with it and noticed the fans were working overtime. There was a process, "icloud-services", which was using 100% of the CPU. It's sort of an indictment of Apple that my first inclination was "they've got a bug that's got an infinite loop" instead of "this is malicious software". After a reboot, I traced it back to a folder in `Library/Application Support` which included a `config.json` that mentioned gulf[.]moneroocean[.]stream, so I knew I'd been popped. Cleanup was easy enough (the files themselves, plus the launch daemon), but it's annoying. I don't do dev work on that machine (it's really just for plex & stuff) so it must have been some sort of vulnerability in Plex (but not the one described in OP) or macOS itself. Interestingly, I was up to date on my Plex install, but my macOS version was behind what was apparently an important security update related to an RCE (Sequoia 15.8). > — [xavdid on hackernews · 1 comments](https://news.ycombinator.com/item?id=50156001) > Yeah, this happened to me the other day. I completely missed their "please upgrade now" email on Sep 1st and was running a 13 month old version. I got a notification that my home server was at 100% usage, and found the miner right away. At least they were nice enough to name the process "mylovelyminer." > — [iamjackg on hackernews](https://news.ycombinator.com/item?id=50157558) > That may be true, but how do you grant non-technical family/friends access? They don't even understand what a VPN is, let alone how to toggle one on/off to access the Jellyfin instance. Additionally, if they try to connect from an Android TV / Fire Stick, where you can't configure a VPN (and use their ISP's modem, so no wireguard client on the router to transparently route to the subnet), what are you supposed to do? I feel it may be easier long-term to just contain the Jellyfin daemon to only r/o access to media, putting it behind a subdomain like jellyfin.example.com, and use the dns-01 challenge via LE to only provision a wildcard cert for the domain (IE *.example.com). Then, have nginx listen on 80/443 with a default server directive that returns 444 for any requests not to the (correct) jellyfin hostname (due to bots hammering 80/443 across the internet on webserver's direct IPs). Its the only solution I can think of to make it easy for nontechnical users (everything just described is completely invisible to a regular client) while reducing the attack surface area of the daemon. FWIW, with the aforementioned setup, I got 0 unauthorized requests to my jellyfin server. Just a bunch of bots hammering my IP's 80/443 ports directly with exploits for old (usually wordpress) vulns, but they were all served 444 (IE an immediate TCP connection close without nginx even responding to the request). > — [DaSHacka on hackernews · 1 comments](https://news.ycombinator.com/item?id=50156592) > What get me the most, are the rabid Plex fanbois swearing that having jellyfin open on the internet is such a baaaad idea and you should spend ~50~ ~100~ 500 bucks for a sub to Plex which totally don't expose the same risk > — [Orygin on hackernews · 1 comments](https://news.ycombinator.com/item?id=50156261) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50152321) · 101 points · 44 comments ## Similar posts on daily.dev - [I got hacked, my server started mining Monero this morning.](https://daily.dev/posts/i-got-hacked-my-server-started-mining-monero-this-morning--2rfojzh4u) · Hacker News · 2 upvotes · 1 comments - [From Langflow to Monero: Inside CVE-2026-33017 Cryptominer](https://daily.dev/posts/from-langflow-to-monero-inside-cve-2026-33017-cryptominer-yaxregtae) · Trend Micro · 0 upvotes · 0 comments - [Threat Actors Exploit Critical AhsayCBS Flaws to Drop Webshells and XMRig Cryptominer](https://daily.dev/posts/threat-actors-exploit-critical-ahsaycbs-flaws-to-drop-webshells-and-xmrig-cryptominer-68sjl9tak) · Huntress Blog · 0 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security) [View this post on daily.dev](https://daily.dev/posts/plex-vulnerabilities-being-exploited-in-the-wild-to-drop-a-cryptominer-mvs9muvxb) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Plex vulnerabilities being exploited in the wild to drop a cryptominer","url":"https://daily.dev/posts/plex-vulnerabilities-being-exploited-in-the-wild-to-drop-a-cryptominer-mvs9muvxb","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/plex-vulnerabilities-being-exploited-in-the-wild-to-drop-a-cryptominer-mvs9muvxb"},"datePublished":"2026-10-19T18:21:35.137Z","dateModified":"2026-10-20T04:18:25.194Z","description":"A security researcher set up a honeypot after Plex disclosed critical vulnerabilities (CVE-2026-96652, 96654, 96655, 96656) affecting Plex Media Server v1.43.2...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/2195afb81bdb4185e803fa231d626491?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/2195afb81bdb4185e803fa231d626491?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/plex-vulnerabilities-being-exploited-in-the-wild-to-drop-a-cryptominer-mvs9muvxb","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security","timeRequired":"PT4M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Plex vulnerabilities being exploited in the wild to drop a cryptominer"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/plex-vulnerabilities-being-exploited-in-the-wild-to-drop-a-cryptominer-mvs9muvxb#faq","mainEntity":[{"@type":"Question","name":"What CVEs are being exploited in Plex Media Server v1.43.2 and earlier?","acceptedAnswer":{"@type":"Answer","text":"CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, and CVE-2026-96656 were chained together by researchers (via the plex2shell project) to achieve remote code execution on vulnerable Plex Media Server installations. Plex disclosed the security update on September 1, 2026, and in-the-wild exploitation attempting to drop a cryptominer was first observed around October 17, 2026. Admins patching Plex servers can track emerging exploit chains and IOCs on daily.dev."}},{"@type":"Question","name":"What payload do attackers drop after exploiting the Plex RCE vulnerability?","acceptedAnswer":{"@type":"Answer","text":"Attackers deliver a Docker-based cryptominer (xmrig) after gaining remote code execution, with file hashes published for detection. A separate tool called myawesomeproxy was also observed being deployed, acting as a residential IP proxy and displaying a message warning that running it permits external use of the victim's internet traffic. Those hunting cryptomining and proxyjacking malware can follow fresh IOC writeups on daily.dev."}},{"@type":"Question","name":"Which IP addresses were observed exploiting the Plex2Shell vulnerability chain?","acceptedAnswer":{"@type":"Answer","text":"Exploitation attempts came from 45.194.92.222, 91.92.40.202, and 176.65.139.228, with a malicious file download observed from 217.60.194.116. The attack path involved a crafted request to the Plex timeline subscribe endpoint chained to a local agent search function to achieve server-side request forgery and remote code execution. Security teams building detection rules can track IOC disclosures like these on daily.dev."}}]} ```