The fans spin up at 3:14 in the morning, and almost nobody reads that signal correctly. A spare-room NAS in Lisbon. A mini-PC bolted behind a television in Osaka. A Dell tower humming in the back office of a dentist in Ohio. All of them running Plex Media Server, all of them pinned at ninety-something percent CPU for eleven days straight, all of them explained away with a single word: transcoding. The owner hears the noise, opens the dashboard, sees the word, and goes back to bed.
That word is the most valuable asset the attacker owns — more valuable, in the end, than the Monero.
What security reporting began to surface this week is that a chain of four vulnerabilities in Plex Media Server — nicknamed Plex2Shell, in the now-familiar pattern set by Log4Shell and Spring4Shell — has been used to plant XMRig on internet-facing instances and convert them into Monero miners, with a second payload quietly opening a reverse proxy back into the host network. A fixed build exists. A proof of concept has been circulating since October. And the technical specifics, as the reporting itself concedes, remain unclear.
That concession is where I want to begin. Decoding the whisper before it becomes a shout means reading the silence between the sentences as carefully as the sentences themselves.
What the disclosure does not say
In the years I have spent reading vulnerability write-ups — and in the two months I withdrew from public commentary in 2022 to audit how badly the industry's security marketing had outrun its security engineering — I have learned that the quality of a disclosure is itself a data point. It tells you what the researchers knew, what they were permitted to publish, and how much of the threat is engineering versus theatre.
Consider the absences here. There is no CVE number attached to any of the four vulnerabilities. There is no affected version range, only a fixed build — 1.43.3.10861 — whose numbering I could not independently verify and which sits oddly high against Plex's customary versioning convention. There are no indicators of compromise: no file hashes, no command-and-control domains, no mining pool addresses, nothing a defender could carry into a hunting query this afternoon. There are no absolute timestamps, only "this week," "in October," "earlier this year." And the byline belongs to a news desk, not a research team.
None of that makes the event false. It makes it unverified — and the distinction matters enormously for anyone deciding whether to spend a weekend patching a media server.
The naming deserves its own paragraph, because it is doing work that the technical detail cannot. Plex2Shell borrows a suffix that has become a brand. Security researchers adopt these names deliberately, and often for good reasons — a memorable name raises patch rates, and a raised patch rate is a public good. But a memorable name also inflates perceived severity before severity has been established. A name is a marketing decision, not a CVSS score. The questions that would actually tell us how dangerous this is — does the chain require a specific configuration, does it require authentication, can it be triggered unauthenticated over the public internet — are precisely the questions the reporting leaves unanswered. Until they are answered, the responsible posture is patched caution, not panic.
There is also a terminological slip worth flagging, because it will mislead defenders who skim. The headline frames the incident as "Monero mining malware." The body describes XMRig. These are not the same thing. XMRig is open-source mining software, freely available and entirely legal, and it will mine any RandomX-family coin you point it at. Monero is a target, not a tool. The conflation matters because it subtly reframes a general-purpose intrusion as a Monero-specific problem — and Monero, as I will argue, is the least interesting part of this story.
The chain, reconstructed
Strip away the naming and what remains is a well-worn pattern, executed against a specific and unusually hospitable target.
Plex Media Server is an application-layer service. It listens, classically, on port 32400, and it advertises itself outward through Remote Access, a feature that in most home deployments is configured with UPnP or NAT-PMP — meaning the router opens the port automatically, without the user ever consciously deciding to expose a service to the internet. That single design choice is the reason this story exists at all.
The reconnaissance phase, in other words, costs the attacker almost nothing. Plex is trivially fingerprintable; a product query returns its instances the way a lighthouse returns its coastline. There is no scanning discipline required, no stealth, no targeted research. The population is enumerated in advance, by the vendor's own convenience features.
The exploitation path runs through four chained vulnerabilities to achieve remote code execution. Chaining is not novel; it is the standard grammar of modern exploitation, and its structure is almost always the same: one flaw bypasses authentication, a second bypasses input validation, a third achieves file write, a fourth converts the write into execution. Which of the four does what in Plex2Shell has not been published. That is the single most consequential gap in the entire disclosure, because it determines whether the chain is a wide-open door or a lock that only turns under a specific configuration. The reporting acknowledges as much: not every Plex server is necessarily vulnerable.
Once execution is achieved, the payload bifurcates, and this is where the incident stops being a curiosity and becomes an economic story.
One branch installs XMRig, consuming CPU cycles and pointing them at a Monero pool. The other installs software that behaves as a reverse proxy or backdoor — an outbound connection, persistently maintained, through which traffic can be relayed. Two payloads, two business models, one host.
Why the attacker never needed root
Here is a detail that most coverage will skip and that changes the risk calculus substantially. On Linux, Plex Media Server typically runs as a dedicated low-privilege user, conventionally plex. Mining is a CPU-bound activity. A reverse proxy is an outbound network activity. Neither requires root. Neither requires a local privilege escalation step.
That matters because privilege escalation is where a great many intrusion chains die. It is the noisy stage, the one that trips endpoint detection, the one that leaves kernel-level artifacts and elevated process trees. By building a chain that terminates in remote code execution under an unprivileged service account, the attacker removes the hardest remaining step. The barrier to a successful, persistent, revenue-generating compromise drops accordingly.
The practical consequence for defenders is uncomfortable: an intrusion can be complete, profitable, and durable while never touching a privileged path. Detection logic built around escalation — the alert that fires when a service account tries to become something else — will see nothing at all.
Transcoding is the perfect alibi
I want to dwell here, because this is the design insight the reporting gestures at without naming.
Plex's core function is video transcoding. Transcoding is, by its nature, a sustained multi-core CPU load. A Plex server operating normally will routinely sit at high utilization for the duration of a film. Its owners are conditioned — actively conditioned by the product's own dashboard — to interpret CPU saturation as evidence that the machine is doing exactly what it was purchased to do.
The attacker did not choose Plex because it was easy. The attacker chose Plex because its normal operating state is indistinguishable from a cryptojacking infection.
This is a different class of target selection than the one the security industry usually discusses. Most threat modelling asks: where is the value? Cryptojacking asks a different question entirely: where is the noise floor highest? A hospital has high value and low tolerance for noise. A home media server has low value per unit and near-infinite tolerance for noise, because noise is the product.
That reframing explains the target. It also explains the duration. An intrusion into a corporate network is measured in days before someone notices. An intrusion into a spare-room NAS can be measured in months.
The cleanup problem nobody budgets for
There is a second-order cost to the dual-payload design that deserves more attention than the initial infection.
Cryptojacking is often treated as the least serious form of compromise — no data exfiltrated, no encryption, no ransom note. That framing is a category error, and the architecture here proves it. If an operator detects the miner and removes XMRig, they have addressed the symptom and left the mechanism. The reverse proxy persists. The outbound tunnel remains open. The host stays reachable, and the attacker, having already learned the environment, can redeploy the miner at leisure.
A host that has been cryptojacked is not a host that has been lightly compromised. It is a host that has been fully compromised and then monetized twice.
The correct remediation is not deletion of a process. It is rebuild. And in a home or small-office context, rebuild is precisely the action the owner is least equipped to perform — which is why the long tail of this incident will extend well past the publication of any patch.
Why Monero, and why it was never about the price
The reflexive reading of any cryptojacking story is that the attacker picked the most valuable coin available. That reading is wrong, and getting it right tells us something useful about how criminal infrastructure actually selects its rails.
Monero's monetary design is unremarkable for this purpose. It runs a tail emission of 0.6 XMR per block at roughly two-minute block times — call it 432 XMR a day, against a network hashrate that has oscillated between three and six gigahashes per second in recent years. There is no halving narrative, no scarcity event to trade. At a rough $200 per coin, the entire network's daily issuance is on the order of $86,000. This is not a market anyone mines for the price action.
What Monero offers instead is a precise match to the resource endowment of a botnet. RandomX is CPU-friendly and ASIC-resistant — a compromised general-purpose processor is not a consolation prize, it is the only efficient source of hashrate. Marginal cost to the attacker is zero — the victim pays for electricity, hardware depreciation, and cooling. And privacy primitives — ring signatures, RingCT, stealth addresses, Dandelion++ — degrade forensic traceability at the payout end. Converting mined XMR into something spendable is harder to follow than converting mined BTC.
Put those three together and the conclusion writes itself: Monero was selected for its technical fit with stolen CPU cycles, not for its market value. The coin is a settlement rail chosen for its properties, the way a smuggler chooses a shipping route for its waters rather than its scenery.
I have made a version of this argument before in a different context. When I spent six months inside the Compound and Aave governance forums in 2020 and co-authored a report arguing that leverage needed an ethical framework rather than just a parameter fix, the pushback was always the same: the mechanism is neutral, the incentives will sort it out. They do not. Incentives sort themselves toward whatever the rails permit.
The arithmetic of borrowed electricity
Now the part that I think is genuinely under-reported, and where the numbers become uncomfortable.
Take a single compromised home server. A Celeron J4125-class machine delivers roughly one to one and a half kilohashes per second under RandomX; a desktop i5 or i7 might reach three to eight. Call it two kilohashes for a representative unit.
Against a network hashrate of roughly 4.5 gigahashes, one kilohash per second earns about $0.019 per day. So a two-kilohash machine earns its operator approximately four cents a day.
The additional electricity that machine burns — fifty to eighty watts of sustained load at $0.15 per kilowatt-hour — costs its owner somewhere between fifteen and thirty cents a day.
Read those two numbers together. The victim's electricity bill rises by an order of magnitude more than the attacker's revenue.
| | Per machine, per day | |---|---| | Attacker revenue (2 kH/s) | ≈ $0.04 | | Victim electricity cost | ≈ $0.15 – $0.30 | | Net social loss | ≈ $0.11 – $0.26, dissipated as heat |
Single-machine cryptojacking is negative-sum extraction. The value destroyed exceeds the value captured, and the difference leaves the system entirely, as heat and grid load. This is not a wealth transfer. It is a wealth incineration with a beneficiary.
Which raises the obvious question: why would anyone run this? The answer is scale and cost structure. At ten thousand infected machines the operation clears roughly $380 a day. At a hundred thousand — the order of magnitude that would make this a genuine business — it clears around $3,800 a day, or roughly $1.4 million annualized, against near-zero marginal cost once the exploit chain exists and the proof of concept is public. The attacker is not running a mining operation. The attacker is running a logistics operation that happens to emit hashes.
And that reframing forces a second conclusion, one the reporting does not draw but its own facts support: if mining earns four cents per machine per day, the reverse proxy is almost certainly the primary revenue line, and the miner is the decoy.
A compromised residential IP address is a tradable commodity. The residential proxy market — which resells home and small-office connections for scraping, ad fraud, geo-restriction circumvention, and account takeover — pays for exactly the asset this chain creates: a persistent, outbound, plausibly residential tunnel. The unit economics there are an order of magnitude better than four cents, and the detection surface is smaller, because a proxy generates traffic patterns that look like a household browsing the internet, which is what a household does.
This is the structural move I have been arguing against in a different arena for years. When intent-based architectures push execution off-chain into solver networks, the extraction does not disappear; it relocates into a layer with less visibility. The same thing happens here. The mining pool is visible. The proxy pool is not. Anyone who reads this incident as a mining story has been shown the wrong layer on purpose.
The one node that can actually be squeezed
If the miner is the decoy, where does enforcement land? Not on the exploit — that is public. Not on the victim — that is diffuse and unpatchable at scale. It lands on the single point where stolen hashrate must touch the regulated world: the mining pool.
A botnet's RandomX output is worthless until it is submitted to a pool that credits it. Pools have historically done very little to audit the provenance of the hashrate they accept, and the reasons are structural rather than malicious — hashrate arrives pseudonymously, at volume, from everywhere, and the pool operator's commercial incentive is to accept it. But it remains true that this is the only node in the entire chain where a compliance question can be asked of a counterparty with a legal identity and a bank account.
The mining pool is the chokepoint the industry has decided not to look at. It is the same institutional reflex that keeps Tether's reserve attestations at arm's length while the market treats a quarterly letter as though it were an audit: the problem is visible, structural, and collectively unexamined, because examining it would impose costs on parties who prefer not to bear them. We have built an industry meticulous about verifying what is convenient to verify and silent about what is not. Hashrate provenance sits firmly in the second category.
The squeeze may arrive from the other direction regardless. Monero's liquidity has contracted sharply as major centralized venues have delisted it, and the European Union's MiCA and AMLR framework, with its privacy-asset restrictions phasing in through 2027, will narrow the conversion path further. That raises friction at the payout end — more slippage, more reliance on non-KYC venues. It does not eliminate the business, but it reshapes it, and reshaped criminal businesses tend to migrate toward rails with better liquidity and worse traceability, which in practice has meant stablecoins on high-throughput chains and mixing services. Navigating the storm with an anchor made of code is possible only if the code is actually audited; where it is not, the storm simply moves.
Open source is not a security posture
There is a comfortable inference available here, and I want to close it off before it hardens into folklore: the inference that Plex's closed-source nature is the root cause, and that users should migrate to an open alternative.
Migration may well be sensible for other reasons. But it is not a security fix. Jellyfin, the community fork, and Emby, its upstream, share a media-processing lineage with Plex — FFmpeg and the transcoding pipeline are common ground across all three. If the four chained flaws live in shared components, the open alternatives inherit the exposure and simply respond on a different clock. The reporting does not disclose which component is affected, which means this is a live, unresolved question rather than a settled one.
More importantly, the determinant variable in this incident is not licensing. It is operational hygiene. The vulnerability chain is only half the story; the other half is a feature — Remote Access with automatic UPnP port mapping — that guides non-technical users into exposing a service to the public internet without a conscious decision. An open-source alternative that asks the user to configure port forwarding manually will be safer for a technical user and abandoned by everyone else. Security here is a function of defaults and update discipline, not of source availability.
And update discipline is where the long tail really lives. Desktop Plex installs receive update prompts through an operating system with a mature patch culture. NAS installs — Synology, QNAP, Western Digital — run Plex as a container or a vendor package, and updating means logging into a NAS admin interface and taking an affirmative action. Most owners will not. A quiet observation in a loud, decentralized room: the devices most likely to be compromised are the ones whose owners believe they have already finished setting them up.
The exposure question is also, finally, an empirical one — and the fact that it went unanswered is the disclosure's most frustrating omission. Counting internet-facing Plex instances is not hard. A Shodan or Censys query against the product fingerprint returns a number in minutes. That number, multiplied by a plausible patch rate, is the size of this problem. Its absence from the reporting is not a small gap; it is the difference between a headline and a risk assessment.
The contrarian reading: the label is the misdirection
Here is the counter-intuitive conclusion, and the one I would put in front of any operations team this week.
The instinctive response to Plex2Shell will be to patch Plex and feel finished. That response is correct and insufficient, because the label is doing exactly what labels do: it localizes a general problem into a specific product. In six months, Plex2Shell will be a line item in a patch log, and the underlying economics — a consumer appliance that runs around the clock, sits behind an automatically opened port, produces CPU noise indistinguishable from its normal function, and is updated by nobody — will be entirely intact. The next version of this incident will not be called Plex2Shell. It will have a different name, on a different appliance, with the same arithmetic.
There is also a moral framing worth resisting, because it is the one that lets everyone off the hook: the idea that cryptojacking is a victimless crime, a bit of stolen compute and nothing more. The arithmetic above refutes it. The victim pays more in electricity than the attacker earns, and then pays again in the form of an open backdoor they will never find. The cost is not hypothetical; it is metered.
The second half of the contrarian reading is harder to accept. The crypto industry is not a bystander to this economy; it is the settlement layer. The hashrate is Monero's. The pool is crypto infrastructure. The proxy tunnels are paid for in crypto. The liquidity constraints that shape the attacker's exit are set by crypto's own compliance choices. We have a habit in this industry of strapping cargo onto vehicles that were never designed to haul it — Runes on Bitcoin being the most conspicuous recent example, a payload bolted to a settlement layer engineered for something else entirely — and then expressing surprise when the suspension fails. Cryptojacking is the same error from the other direction: a media server used as a mining rig, a home router used as a proxy node, a privacy coin used as a payroll system. None of these are design failures of the underlying protocol. They are failures of the surrounding operational imagination.
And so we arrive at the part nobody wants to publish. The four cents is not the point. The four cents is the visible residue of a business whose actual product is your IP address and your electricity, sold to buyers who will never learn your name.
What comes next
The patch exists. Apply it, then verify the build independently rather than trusting a version string quoted in a news desk summary. Then ask the question the incident actually poses: what else in your environment runs continuously, answers to the internet by default, and reports its own health in a way you have been trained to trust?
That question does not get answered by a patch. It gets answered by deciding, once, that the quiet hum in the spare room is data — and that reading it before it becomes a shout is the only form of defence that scales.