Plex2Shell: a honeypot saw exploitation 1 day after the write-up and 74 days after Plex's fix (19 Oct)

74 days from the fix to the first exploitation seen, and 1 day from the write-up

Plex released Plex Media Server 1.43.3.10861 to everyone on 4 August 2026, according to its own release-notes thread, and the CVE records name that build as the first fixed one. A researcher's honeypot first saw the four Plex2Shell flaws exploited on 17 October. That is 74 days (derived). The technical write-up that describes the chain was posted on 16 October, so 73 of those 74 days passed before the chain was described in public, and one day passed after. Plex's own security notice came on 1 September, 46 days before the first exploitation seen (derived).

That interval is a measurement of one decoy, not a count of victims. What the record does not establish:

• how many Plex servers are reachable from the internet or were compromised: no primary page read for this briefing gives a number;
• who is exploiting the flaws;
• whether 17 October is the first exploitation anywhere: it is the first one honeypot saw;
• how often attempts succeed against real servers;
• whether the cryptocurrency miner is the only thing delivered, or where the proxy program that followed it comes from.

The first report that prompted this briefing, SecurityWeek's of 13:44 BST on 19 October, says Plex announced on 1 September that it had already shipped fixes. Counting from that announcement gives 46 days. This briefing leads with the release instead, because Plex's own release notes show the fix shipped on 4 August, and because the UK timescales discussed below count from release. Both numbers are shown. SecurityWeek is a secondary source and was used as a pointer: every figure below was checked against Plex's pages, the CVE records, CISA's records and the two researchers' own pages.

The record in order, drawn to scale

The dates come from Plex's pages, the CVE.org records and CISA's advisory, plus two researchers' pages for the dates only they can supply. The last column counts days from the 4 August release (derived, Python datetime). A time is given where the page prints one.

Dates and events as read on 19 October 2026. Days are calendar days from 4 August 2026, negative before it (derived).

Date (2026)	What the record says, and where	Days from fix
14 Jul	Plex releases 1.43.3.10828 to everyone. Its notes carry no security line. (Plex release-notes thread)	-21
27 Jul	The researcher reports to Plex. (the researcher's own disclosure timeline)	-8
3 Aug	1.43.3.10861 goes to the Plex Pass beta channel. Its notes add two security lines: one on the companion proxy, one saying two transcoder settings can no longer be changed over the network. (release notes, 13:59 UTC)	-1
4 Aug	1.43.3.10861 goes to everyone. The researcher says Plex confirmed the reports and paid a bounty the same day. (release notes, 16:09 UTC; the write-up)	0
1 Sep	Plex posts 'Important Security Update for Plex Media Server v1.43.2 and earlier' and recommends updating as soon as possible. It says CVEs have been requested and that it will reply with more details once they are published. (Plex forum, 19:30 BST)	28
23 Sep	Four CVE records are published, assigned by the numbering authority the records print as cisa-cg, with a CISA advisory the same day. (CVE.org, 17:06 BST for the first)	50
16 Oct	The researcher posts the write-up. (the write-up's own date)	73
17 Oct	A honeypot researcher sees exploitation 'this morning', then a proxy program later that day. (the honeypot post; time zone not stated)	74
18 Oct	The public history of a repository named for the chain begins: first commit 05:01 UTC, the commit titled as the proof of concept 15:06 UTC. (GitHub's public record)	75
19 Oct	SecurityWeek reports the exploitation at 13:44 BST. This briefing's date.	76

Two things in the table matter for how to read it. First, the fix is early: on the researcher's own timeline it reached users 8 days after the report and on the day of the bounty. Second, almost all of the interval is quiet. Plex's notice came 28 days after the fix, the CVE records 50 days after, and the first exploitation seen 74 days after. The release notes call the two changes only a 'potential vulnerability' in the companion proxy and a restriction on two transcoder settings, with no severity. The notice of 1 September promised a reply on the thread once the CVEs were published. They were published on 23 September; as read on 19 October, 26 days later (derived), the thread still holds only its first post.

The shape is familiar. The site's earlier briefing on a file-server flaw, HFS CVE-2026-61500, recorded a fix 80 days old and exploitation reported within 39 hours of a write-up. Plex2Shell is the same pattern at 74 days and one day. What differs is where the software runs: Plex's own pages describe home and small-business machines, where nobody may have been told to patch, which is inference and not something any source states.

A public proof of concept, and dates that do not quite agree

SecurityWeek says the researcher released a write-up and proof-of-concept code on 16 October, and that attacks began one day after technical details and a working exploit went public. The write-up, read in full, is dated 16 October, describes each stage of the chain in technical detail, and links a public code repository. This briefing reproduces none of that detail and does not link the repository. The write-up also says the researcher used large language models heavily for reconnaissance, hunting, verification and chaining, and that the judgement calls were the researcher's. Nothing else read says how the flaws were found.

The repository's own record does not match the 16 October date. As read on 19 October, GitHub's public record shows the repository created at 05:00 UTC on 18 October, first commit 05:01 UTC, and the commit that added the working code at 15:06 UTC that day. Yet the honeypot researcher's post, dated 17 October, already links the same repository address in its main text, and the write-up page links it too. The likeliest reading is that the repository was recreated or its history reset, which is inference: the record read does not say. So the dates this briefing can stand behind are these: the write-up was public on 16 October by its own date; exploitation was seen on 17 October; the code's public history, as it now stands, begins on 18 October. That is why the title says 'write-up' and not 'exploit'.

The repository's README, as read on 19 October, states a score of 9.8 on CVSS 3.1 for the whole chain, and its commit history shows a change from 10 to 9.8 at 01:30 UTC that day. That score is the researcher's own. No CVE record carries it. The README also says the chain affects versions below 1.43.3.10828 and was fixed in 1.43.3.10861, a range that does not say whether 1.43.3.10828 and the builds up to 1.43.3.10860 are affected; the version section below shows why that matters.

Four records, each scored on its own

The CVE.org records for CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 and CVE-2026-96656 were read as JSON from the CVE Services API, and the NVD records from the NVD API. NVD carries the same scores from the same source, marked secondary. All four CVE.org records say 'before 1.43.3.10861' for the affected range. The CVE numbers between them are not all Plex: CVE-2026-96653 is a WordPress plugin record. CISA's advisory, VA-26-266-01, lists a fifth Plex CVE fixed in the same build, CVE-2026-96651, a path traversal that its CVE.org record scores 6.5 on CVSS 3.1 and 7.1 on 4.0. It is not one of the four chained flaws, and updating to the fixed build covers it as well.

The four records as published by the numbering authority on 23 September 2026 (CVE.org). Scores are CVSS 3.1 and 4.0 base scores assigned by that authority; the last column is the access the record's own vector assumes.

CVE	Class, in the record's words	CVSS 3.1 / 4.0	Access assumed
CVE-2026-96652	Server-side request forgery in a player feature that accepts any token value (CWE-918)	4.3 / 5.3, medium	Low
CVE-2026-96654	URL values not correctly neutralised in a plugin search function, so a caller can invoke other plugins' functions with its own parameters (CWE-84)	6.5 / 6.9, medium	None
CVE-2026-96655	Server-side request forgery through the transcoder's media path, for an authenticated user (CWE-918)	4.3 / 5.3, medium	Low
CVE-2026-96656	An admin user can write arbitrary files that may be executed on load, because libraries are loaded with no signature check (CWE-73)	7.2 / 8.6, high	High (admin)

The scores run from 4.3 to 7.2 on CVSS 3.1, a spread of 2.9 points, and from 5.3 to 8.6 on 4.0 (derived). One of the four reaches 7 and none reaches 9. Each record scores one step on the access that step is assumed to have, and the chain supplies that access to itself: the write-up and the repository describe the whole chain as needing no valid credentials. CISA's advisory puts the worst case in its own words as a remote attacker who could 'steal a legitimate user's account credentials and eventually write arbitrary files or execute code'. The gap between the researcher's 9.8 for the chain and the highest record score is 2.6 points (derived).

Which build is fixed: the label '1.43.3' is not enough

Every source agrees that 1.43.3.10861 is the first fixed build. Not every source says it the same way, and a version label that is close to the right one is the kind of label that gets copied into an asset register.

What each source says about affected and fixed versions, as read on 19 October 2026, and what that leaves out.

Source	What it says	What it leaves out or gets wrong
Plex notice, 1 Sep	Title says 'v1.43.2 and earlier'. Windows and macOS lines say to be on 1.43.3 or newer.	No build number. A server on 1.43.3.10828 is '1.43.3' and is not fixed.
CVE.org records and CISA advisory	Affected: before 1.43.3.10861. Fixed in 1.43.3.10861.	The only build-level statement from a numbering authority.
Plex release notes	1.43.3.10828 reached everyone on 14 Jul with no security line. 1.43.3.10861 added two on 3 Aug.	Do not map each CVE to a note; Plex's notes name only two changes.
NVD configuration	Affected range ends before 1.43.0.10861.	Disagrees with NVD's own description text. A scanner trusting it would pass later 1.43.0 builds, 1.43.1 and 1.43.2 as unaffected.
Researcher's repository README	Chain affects versions below 1.43.3.10828; fixed in 1.43.3.10861.	Stops one build short of the fix.
Plex downloads listing	Lists 1.43.4.10903 as the public release for computers and NAS platforms.	Later than the fix, so taking the current release clears the range.

The practical rule is to read the full build number against 1.43.3.10861 or later, take the current public release, and not accept a scanner result that rests on the NVD range. The mismatch itself is unexplained in the sources: a mistyped build number in a configuration is the obvious guess, and it is only a guess.

What the honeypot saw on 17 October, and what it cannot say

The honeypot researcher is an individual running a personal blog, a security practitioner and a Plex user by the post's own account, with no commercial interest stated. The post says a decoy running a vulnerable Plex version, set up in response to Plex's 1 September announcement, mostly drew scanning and generic attempts until the morning of 17 October. Then it saw exploitation, from three source addresses, followed by a file download from a separate address. The post is dated Saturday 17 October with later edits on 17 and 18 October, and its time zone is not stated. The honeypot blocks outbound traffic by default; the researcher relaxed that later because of how the flaw works, and says payloads were not captured for every attack, so the data may be partial. The attackers may have used slightly modified code, the researcher adds.

What was delivered, in the researcher's account: a cryptocurrency miner built on XMRig, and later that day a proxy program that prints a notice saying anyone running it agrees to the potential external use of their internet traffic. The researcher's view is that Plex servers may sit on residential internet connections, and that criminals would want a residential proxy to reach corporate VPNs and email. That is a theory, attributed to the researcher. The researcher also cautions that the indicators published cover only the honeypot. This briefing prints none of them.

The honeypot record, question by question. Source: the honeypot researcher's post of 17 October, with edits to 18 October, and SecurityWeek.

Question	What the record shows	What it does not show
Was exploitation seen?	Yes, on one decoy, on the morning of 17 October.	Whether it began earlier elsewhere, or how widely.
Who is behind it?	Three source addresses and one download address, not printed here.	Any attribution. A source address is not an actor.
What was delivered?	A miner and, later, a proxy program.	That these are the only payloads, or that real servers received the same ones.
Did it work on real servers?	It worked on the decoy, which ran a vulnerable build.	Any success rate, victim count or sector.
Is the proxy part of a known network?	The researcher saw traffic tied to a proxy-related domain (not printed) and pointed to a security report on a botnet that rents out infected devices as proxies.	Any link. The post does not claim one, and neither does this briefing.

Residential proxy abuse of compromised devices is a pattern the site has covered before: GreyNoise on proxyjacked edge devices. The Bitsight report the honeypot researcher cites is about a different botnet, which installs proxy software on exposed devices to rent them out; it is secondary context here and says nothing about Plex.

Who runs a Plex server, and how many can be reached: not found

No primary page read for this briefing gives a number of internet-exposed Plex servers, and no search tool or scan was used to produce one. The count is therefore not found, and nothing here estimates it.

What the sources do say about who runs it and how it is reachable:

• The write-up describes the software as run on home servers or cloud boxes, listening on one port and often exposed directly to the internet so people can stream remotely.
• Plex's installation page lists Windows, macOS, Linux and compatible NAS devices, and its NAS page says the processors in most home or small-business NAS are not especially powerful.
• Plex's remote-access article, last modified 8 September 2026, says that unless remote access is disabled the server will try to set it up itself, first through the router's automatic port mapping (UPnP or NAT-PMP). It does not mention these flaws.
• Plex's firewall article lists one required port for the server, and strongly recommends not forwarding its additional ports where the server has a public address or sits in a router's DMZ.
• The 1 September notice says the updated version may not yet be in a NAS maker's package manager, and gives a manual route. Release notes of 14 July and 4 August repeat that app stores 'may take some time to go through the various approvals'.
• Plex's update setting can check for updates and prompt to install, on a public or beta channel; its Linux repository changed at version 1.43.0, so older repository set-ups need redoing to keep receiving updates.

Taken together: a default that tries to open the port, a package source that can lag, and an update that prompts rather than installs. None of those is a failure by itself, and none was established as the cause of any compromise. They are the reasons an owner who 'has automatic updates' may not be on the fixed build.

Six labels that did the work of a control

A comforting label is not a control. Six labels on this record were read as if they were, and each came with a date that makes it a snapshot.

Labels on the Plex2Shell record, what each said and when, and what it did not do. Sources as named in the text.

Label	What it said, and when	What it did not do
'Medium' severity	Three of four records scored 4.3 to 6.5 on CVSS 3.1 (23 Sep).	Score the chain. Each record assumes the access its own step needs.
SSVC 'Exploitation: none'	Stamped 14 and 23 Sep in the records, with 'Automatable: no'.	Anticipate a write-up 23 days after the second stamp (derived).
Low EPSS	0.222 to 0.396 per cent, percentile 11.8 to 32.2, dated 18 Oct (FIRST).	Reflect an exploitation seen the day before the date it carries.
'Not in KEV'	None of the four listed at 14:52 BST on 19 Oct.	Mean 'not exploited'. The NCSC notes KEV only reports exploitation that has already occurred.
'1.43.3 or newer'	Plex's notice to Windows and macOS owners, 1 Sep.	Name the fixed build, 1.43.3.10861.
'A media server'	How the product is described and run, on a NAS or a home machine.	Make it a low-impact service. Code from the chain runs with the Plex service's privileges, per SecurityWeek and the write-up.

The NCSC's own guidance warns against the first of these: it says not to base update decisions on a single severity score such as CVSS. Its table of compressed update times is keyed to a KEV listing, and the same page warns that KEV only reports exploitation that has already occurred. On 19 October the table's rows did not apply to Plex and the exploitation was already under way, which is the gap between a trigger and a control.

What UK guidance requires, and what it does not say

Each page below was read from the NCSC's and the ICO's own sites on 19 October 2026, and the sections quoted were read in full. None of them mentions Plex, media servers or Plex2Shell. What follows is what each requires and what it leaves open, for an organisation that runs a Plex server on a NAS or a spare machine, which Plex's pages say is a normal way to run it.

UK sources as read on 19 October 2026. Quotation marks show exact wording; everything else is paraphrase.

Source	What it says	What it does not say
NCSC, vulnerability management: update by default (published 12 Feb 2024, reviewed 1 May 2026, v2.1)	Best-practice timescales from release: internet-facing services and software, 5 days; operating system and applications, 7 days; internal or air-gapped, 14 days. Where an internet-facing flaw is exploited in the wild, 'investigate your exposure and check for signs of compromise before applying any update'.	Name Plex, a NAS or home servers. It does not make the 5 days a legal duty.
NCSC, responding to active exploitation (1 May 2026)	Compressed update times of under 24, 48 or 72 hours, with an incident-response check, apply to KEV-listed flaws, depending on internet access, automation and whether an attacker can take total control. Find shadow IT. Do not run released exploit code to confirm a flaw without expert assessment.	Say what to do for a flaw exploited before it is in KEV. It notes KEV reports only exploitation already seen.
NCSC, own the risk of not updating	Not updating is a senior-level risk decision. Do not decide on a single severity score such as CVSS.	Set a deadline of its own.
Cyber Essentials v3.3 (April 2026), security update management	Software on in-scope devices must be updated 'within 14 days' of release where the vendor calls the fixes critical or high risk, the CVSS v3 base score is 7 or above, or the vendor gives no level. A single update with any such issue must be installed within 14 days. Inbound firewall rules must be approved and documented.	Mention media servers, UPnP or NAS. Cover a home server outside an assessed scope.
NCSC, top tips and small-organisations guide	Apply updates as soon as they are available and turn on automatic updates.	Cover servers, NAS devices or port forwarding. Both pages are written around phones, laptops and tablets.
ICO, guide to data security and breach guide	The UK GDPR security principle needs 'appropriate' measures, and Cyber Essentials is a good starting point. A personal data breach is reported within 72 hours of becoming aware, where feasible.	Set a patch time, or say when a media server holds personal data. The ICO says the guide is under review for the Data (Use and Access) Act.

Applied to the dates: the 14 days of Cyber Essentials from the 4 August release ended on 18 August, and the NCSC's 5 days for internet-facing software on 9 August. The first exploitation seen was 60 and 69 days after those lines (derived). Under Cyber Essentials the 14-day rule applied from the start through its third condition: Plex's release notes gave no level for the fixes. It also applied through its second, once the records were published, because CVE-2026-96656 scores 7.2 and the single-update clause covers the rest. That holds only for an organisation whose scope includes the server, and the page says its requirements apply to in-scope devices and software that can accept incoming connections from internet-connected devices. A home user is outside it, and the NCSC's consumer pages say to apply updates as soon as they are available, which is the same advice with no number of days.

What to do, in order

How this was read, and what rests on one source

Everything was read with curl between 14:47 and 15:17 BST on 19 October 2026, with no browser, no form filled in and no account created. The researcher's write-up, the honeypot post, Plex's forum thread and release notes (as the forum's JSON), the CVE records (CVE Services API), the NVD records, CISA's advisory file, the KEV file, the FIRST EPSS interface, the NCSC vulnerability-management pages and the ICO data-security guide were read in full. Plex's support articles, the Cyber Essentials PDF and the ICO breach guide were read for the sections cited. The repository was read through its public page and GitHub's public metadata, and no code was saved. A Reddit thread the honeypot post links answered with a block page and was not read, and no bot check was bypassed.

What rests on a single or secondary source: the first exploitation on 17 October (one researcher's decoy, plus SecurityWeek's report of it); the researcher's reading that the activity used the published technique (SecurityWeek says so; the post says only that the code may be slightly modified); and the Bitsight context, which is secondary. Plex has an interest in showing the fix shipped first, and the researcher in publishing a chain write-up; neither relationship is hidden, and both are on the record in their own pages.

Re-checked just before finishing, at the time shown above: KEV listed none of the four CVEs, the CVE and NVD records were unchanged, Plex's security thread held one post, the release-notes thread held no newer post than 6 October, and the repository README still carried 9.8. If any of that has changed since, trust the page over this briefing.

The question that exposes the gap

On 4 August the fix shipped with two security lines in the release notes and no severity, and 74 days passed before anyone saw it exploited. Which of your records would have turned those two lines into a 14-day deadline for a Plex server on a NAS that nobody listed, and who would have been told?

Key facts