BlackTree Security · Infrastructure · Automation · AI

Plex Told Every Server Owner to Patch. It Still Won’t Say What It Fixed.

Plex has told every Media Server owner and Desktop user to install a security update as soon as possible. It has not told them how serious the vulnerabilities are.

The Plex security update notice, posted on 1 September, directs administrators to Plex Media Server 1.43.3 or later and users of Plex Desktop to version 1.115.0 or later. Plex says the releases address “a number of security issues” and that CVEs have been requested.

No CVE identifiers, severity scores, attack prerequisites or impact descriptions were available in the notice when BlackTree reviewed it. Plex has given defenders a destination, but not the threat model they would normally use to decide which systems must move first.

The Plex security update is urgent, but the disclosure is incomplete

Plex’s public Media Server release notes provide two clues. Builds in the 1.43.3 line say the company addressed a potential vulnerability in the CompanionProxy. They also say the TranscoderH264Options and TranscoderH264OptionsOverride preferences can no longer be modified over the network.

Those notes identify security-sensitive areas, but they do not explain the practical risk. They do not state whether authentication is required, which network interfaces can reach the affected functions, what an attacker could achieve or which exact CVE will map to each change.

The Plex Desktop release history is even less revealing. Version 1.115.0 was announced on 17 August with a web-client update as its only public change. Plex’s later security notice identifies 1.115.0 as the required Desktop baseline, but does not say which security issue it fixes.

ProductPlex’s stated targetPublic security detail
Plex Media ServerLatest release, version 1.43.3 or laterPotential CompanionProxy vulnerability and network modification of two transcoder preferences
Plex DesktopVersion 1.115.0 or laterNo vulnerability detail in the release announcement

One version number can hide several different builds

The version guidance contains an operational trap. Plex published several Media Server builds carrying the 1.43.3 version number. An early 1.43.3 beta appeared in June, while public builds 1.43.3.10861 and 1.43.3.10896 followed in August and included the two security-related release-note entries.

Plex’s security notice says users should run the latest version and confirms 1.43.3 or newer as the required line. Administrators should therefore verify the full installed build and compare it with the newest package Plex currently offers. Seeing only “1.43.3” should not end the check if the interface, package metadata or container label can expose the complete build number.

This is why patch management is an evidence problem. A successful update message proves that an installer ran. It does not prove that every appliance, container and secondary server now runs the intended build. BlackTree previously examined how the patch window can disappear before defenders finish testing. Here, Plex has increased the urgency without yet publishing enough detail to support normal risk-based sequencing.

NAS package stores can make a patched release look unavailable

Plex specifically warns that updated NAS packages may not have reached a manufacturer’s package manager. That leaves a common gap: the appliance can report that no update is available even while Plex has already published a newer package.

Server owners using Synology, QNAP, TerraMaster, WD or Netgear hardware may need to download the correct package from Plex and install it through the NAS vendor’s manual-install workflow. The package must match the device platform and architecture. A manual installation should be followed by a fresh version check and a basic playback test.

Docker creates a different version of the same problem. Restarting an existing container does not necessarily obtain a newer image. The operator must pull the intended image, recreate the container from it and then verify the version reported by the running Plex instance. A floating tag is convenient, but the running image is what matters.

Update, 9 September 2026: More than 36,000 internet-exposed Plex Media Server instances were still running versions below Plex’s security baseline, according to scanning attributed to the Shadowserver Foundation. The count adds scale to the patch warning, but it is an exposure measurement rather than a count of compromised servers or victims.

More than 36,000 exposed servers were still below the patched version

BleepingComputer reports that Shadowserver began scanning and reporting unpatched Plex Media Server versions on 4 September after the vendor’s advisory. The project found more than 36,000 exposed instances that had not moved beyond affected versions. Administrators should read that number as visible patch debt: it identifies systems reachable from the internet and apparently below the required release, not evidence that attackers have entered them.

The measurement also explains why Plex’s limited disclosure has operational consequences. The vulnerabilities still do not have published CVE identifiers, so common scanners and asset tools may not produce the normal vulnerability records that drive ownership and remediation. Version inventory and external exposure monitoring must fill that gap.

Plex’s primary instruction remains unchanged: update Plex Media Server to the latest release in the 1.43.3 line or later, update Plex Desktop to 1.115.0 or later and verify the complete running build. Internet exposure should be removed when remote access is not required. Where it is required, restrict the path and confirm that old containers, NAS packages and secondary servers have not been missed.

No source reviewed for this update establishes active exploitation of the newly fixed issues. The public record still does not support claims about their severity, attack prerequisites or worst-case impact. The new fact is the size of the visible unpatched population, not proof of an attack campaign.

What Plex administrators should verify now

  • Inventory every Plex Media Server, including test systems, old NAS devices and secondary household servers.
  • Install the latest release offered directly by Plex, not merely the newest package visible in a delayed app store.
  • Confirm that Media Server reports version 1.43.3 or later and inspect the full build number where available.
  • Update the separate Plex Desktop application to version 1.115.0 or later on Windows, macOS and Linux.
  • For Docker, pull the current image, recreate the container and confirm the running application version.
  • Record the pre-update and post-update versions so the change can be demonstrated later.
  • Review remote-access settings and remove exposure that is not operationally necessary while technical details remain limited.
  • Return to Plex’s notice when the requested CVEs are published and reassess logging, detection and incident-response needs.

Old or forgotten installations deserve particular attention. The hardest server to patch is often the one that no longer has a clear owner. That same inventory failure is why obsolete SQL Server systems can reappear years later as emergency work.

What the warning does not prove

There is no basis in Plex’s notice to claim confirmed exploitation, a critical severity rating, unauthenticated remote code execution or a particular number of internet-reachable servers. The company has not published those facts.

The two Media Server release-note entries should not be stretched beyond their wording either. Preventing remote changes to transcoder preferences is security-relevant, but the public note does not state what access was previously required or what the worst credible outcome was. “Potential vulnerability” in CompanionProxy is similarly too broad to support a specific attack scenario.

The absence of detail is not evidence that the flaws are minor. It is evidence that defenders currently cannot measure them properly. Plex’s urgent language justifies prompt updating. It does not justify inventing the missing facts.

Patch now, explain later shifts the burden to defenders

Coordinated disclosure often requires temporary restraint. Vendors may need time for CVE publication, downstream packages and customer updates before releasing technical detail. That can be responsible, especially when a disclosure would make exploitation easier.

But the communication cost is real. Without severity, prerequisites or affected-component detail, a home user, managed-service provider and enterprise administrator receive essentially the same instruction. They cannot determine whether one exposed server should outrank a thousand internal desktops, nor can security teams build focused detections around an undisclosed attack path.

The practical response is to separate two decisions. Updating is already justified by Plex’s warning. Making claims about exploitation, impact and attacker behaviour must wait for evidence.

Frequently asked questions

Which Plex Media Server version should I install?

Plex says to install the latest available release and verify that it is version 1.43.3 or later. Because multiple builds can share that version line, check the complete build number where possible.

Is the vulnerability being exploited?

Plex has not reported exploitation in its notice. The absence of a statement is not proof either way, so defenders should not label the issues as actively exploited without new evidence.

Why is my NAS not offering the update?

NAS vendor package stores can lag behind Plex’s direct releases. Plex advises users to obtain the correct package from its downloads page and use the manufacturer’s manual-install process when necessary.

Does Plex Desktop need a separate update?

Yes. Plex identifies version 1.115.0 or later as the Desktop target. Updating Media Server does not automatically prove that the separate desktop client is current.

Sources and further reading

Leave a Reply

Your email address will not be published. Required fields are marked *