Plex patches multiple undisclosed flaws and pushes 360,000 exposed servers to update
Plex ships Plex Media Server 1.43.3 and Plex Desktop 1.115.0 to close several flaws whose CVEs have not yet been published, while Censys counts more than 360,000 web interfaces exposed to the internet. Update server and clients, and check your NAS update channel, which can lag behind.
September 4, 2026. Plex is urging users to update their instances after shipping a release that closes several undisclosed security flaws. The fixes land in Plex Media Server 1.43.3 and Plex Desktop 1.115.0. Why it matters: per Censys, more than 360,000 devices expose the Plex Media Server web interface to the internet, and the vendor hasn’t published technical details yet — so you patch blind, and fast.
A fix without details, a real risk
Plex hasn’t described the vulnerabilities it fixed, saying only that CVE identifiers have been requested. The advice fits in one line: “We recommend all server owners and Desktop users update to the latest version as soon as possible.” That editorial silence isn’t an anomaly — it’s standard practice while CVEs are still unassigned — but it forces an update with no prior risk assessment.
One practical detail matters for self-hosters: if you run Plex Media Server on a NAS, the fixed version may not yet be available in the device’s package manager. Plex recommends installing the package manually rather than waiting for automatic availability.
A history that weighs on the balance
This fix doesn’t arrive in a vacuum. Plex has hosted serious flaws before, and its exposure surface is well documented.
In August 2025, Plex fixed CVE-2025-34158 (CVSS 8.5), an authentication bug: the /myplex/account endpoint exposed the owner’s account details — including their administrative access token — to any authenticated non-owner or lower-privileged user. A follow-up call to /api/resources then revealed the other servers reachable by that owner. Combined, the two flaws formed an exploit chain that led to discovery of a victim’s entire Plex infrastructure.
The gravest episode dates to August 2022. The LastPass intrusion was helped along by keylogger malware planted on an employee’s home computer, compromised through a Plex Media Server flaw — CVE-2020-5741 (CVSS 7.2). A personal media server became the entry point for one of the decade’s most publicized breaches.
In February 2021, Plex fixed a flaw that let an attacker make a server “reflect” UDP packets to amplify a denial-of-service attack. The fix (Plex Media Server 1.21.3.4014) restricted the server to answering UDP requests from the local network only, never the public internet.
360,000 exposed interfaces
The Censys figure puts the problem in scale: more than 360,000 devices expose the Plex Media Server web interface to the internet. Not all of them are vulnerable, but every one is a potential attack surface. Plex is, by nature, the self-hosted service people willingly open outward — to watch their library from away, share it with family, or serve remote clients.
That convenience is exactly what costs you. An exposed Plex interface running unpatched is an easy target for bots that continuously scan media services. And because a NAS update is often delayed by the vendor’s channel, the window during which an instance stays vulnerable stretches further. That number has stayed stubbornly high for years — a sign that most self-hosters treat remote access as a feature to keep, not a risk to manage. Every one of those instances is a reminder that the convenience of streaming from anywhere and the discipline of patching don’t always travel together.
Why you patch blind
The lack of technical detail isn’t Plex being coy: it’s how coordinated disclosure normally works. When a researcher reports a flaw, the vendor prepares a fix, ships it, then publishes the details — and the CVEs — once some of the install base has had time to update. Revealing the technique before the fix would be handing attackers a manual.
For the user, that means a temporary act of faith: update without knowing what you’re fixing. It’s the classic self-hosting contract — you run the security of services you expose, sometimes with no visibility into the exact risk. The only rational answer is responsiveness: apply updates the moment they ship, and treat any exposed instance as a target until proven otherwise.
Plex, Jellyfin, and the question of exposure
Plex isn’t the only way to host a media library. Jellyfin and Emby offer comparable features under different models — Jellyfin being fully open source with no third-party account dependency. That choice has a direct security impact: Plex couples the local server to an online account and remote services, which widens the attack surface beyond the bare server.
But switching software isn’t a security strategy on its own. The real line isn’t between Plex and Jellyfin; it’s between a server exposed directly and one reachable only through a VPN or an authenticated reverse proxy. Whatever you run, an exposed unpatched media service is a target; a patched, segmented one isn’t. The verdict below keeps that distinction in view.
What to do
- Update immediately. Apply Plex Media Server 1.43.3 and Plex Desktop 1.115.0. If your NAS doesn’t have the version yet, install the package manually.
- Check your exposure. If the Plex web interface is reachable from the internet, protect it with an authenticated reverse proxy or keep it behind a VPN.
- Watch the update channel. On a NAS, track package availability from the vendor and don’t count on a silent auto-update.
These three moves go beyond this release: they durably shrink a class of flaws that, at Plex, has already led to major breaches.
Updating by installation type
The update path depends on how you run Plex. Under Docker, redeploying the image is enough; on Linux, the package follows the Plex repository; on a NAS — Synology, QNAP, TrueNAS — the package flows through the vendor’s ecosystem, often days behind. That delay isn’t neutral: it’s precisely the window during which an instance stays vulnerable while a public fix already exists.
# Docker: redeploy the up-to-date Plex image
docker pull plexinc/pms-docker:latest
docker restart plexThe Censys count is the sobering context. More than 360,000 exposed interfaces mean that any publicly known Plex flaw becomes a mass-scanning opportunity within hours of disclosure. An instance left on a lagging NAS channel isn’t a theoretical risk — it’s a machine already listed in a scanner’s result set, waiting for a payload that already exists.
The remote-access trade-off
Plex’s killer feature — streaming your library from anywhere — is also its chief risk. The Remote Access toggle punches a path through your router and points the world at your server. Disabling it isn’t an option for most users, which is why the practical mitigation is to keep remote access behind a reverse proxy that terminates TLS and adds an authentication layer, or to gate it behind a VPN like WireGuard or Tailscale. Exposed but unauthenticated is the one combination you should never accept.
Verdict
If your Plex server is exposed to the internet, update to 1.43.3 right now, without waiting for the CVEs: the flaws are fixed but not documented, and more than 360,000 instances sit within reach of scanners.
If your Plex lives on a NAS, force the manual package install rather than waiting on the vendor’s channel — that’s where the risk window drags on.
If you want to cut structural risk, take Plex out of direct exposure: a VPN or an authenticated reverse proxy turns a scannable target into an internal service.