DEV Community

The Codecs directory: why CVE-2026-96656 turns a transcoder preference into code execution

Of the four Plex Media Server issues fixed in 1.43.3.10861, only CVE-2026-96656 gives an attacker the final step. The other three produce requests, internal calls and a token. This one plants a file where the service looks for code.

What the NVD record actually says

The record for CVE-2026-96656 describes an external control of file name or path flaw, scored 7.2 on CVSS 3.1 by a secondary scoring source. Three details carry the exploit:

  • The preference TranscoderH264Options is appended verbatim to x264's option string on every transcode.
  • An admin user can therefore write arbitrary files.
  • At startup, all .so files are run without signature, execute bit or symbol checks.

Plex's own summary is shorter: an arbitrary file write to the Codecs directory through transcoder preferences.

CISA classifies the same issue as CWE-73 and lists it in the Known Exploited Vulnerabilities catalog from 2026-10-20, with a due date of 2026-10-23 and a forensic triage requirement.

Why a verbatim append matters

An option string that is passed to an external encoder is normally built from fixed fields. If a user-controlled preference is concatenated without quoting or validation, characters that mean something to the shell or to the argument parser stop being data. That is the mechanism class here: the value is trusted where it should be escaped.

The consequence of the flaw is a file write, not execution by itself. Execution comes from the loading behaviour that follows.

Why an unsigned shared object runs

Plex ships its own transcoder and stores codec libraries in a Codecs directory inside the server data path. On startup the service loads the shared objects it finds there. According to the NVD record there is no signature verification, no requirement that the file carry the execute bit, and no symbol check against an allowlist.

That combination converts the file write into persistence. An attacker who can place a .so file in the directory does not need to exploit a memory corruption bug, defeat ASLR or find a gadget chain. The loader does the work on the next start, under the privileges of the Plex service account.

The role of the other three CVEs

CVE-2026-96656 requires administrative access, which on a hardened deployment is not something an unauthenticated attacker has. That is what the rest of the chain supplies.

CVE-2026-96652 gives an unauthenticated SSRF through /player/timeline with any X-Plex-Token value. CVE-2026-96654 reaches internal agent functions over the loopback interface through searchOne. CVE-2026-96655 discloses the server owner's admin token through the transcode path parameter. With the owner token, the attacker holds the admin capability the file write needs.

Plex states the combined effect plainly: chained together, the issues let an unauthenticated remote attacker run code with the privileges of the Plex Media Server process.

Detection on a live host

Because the payload is a file, this part of the chain is inspectable. Compare the contents of the Codecs folder against a known-good installation of the same version. Any .so or .dll file without a matching counterpart on a clean build deserves a hash and a timestamp.

Then read Preferences.xml. A TranscoderH264Options value that nobody on the team set is the precondition for the write. Plex recommends checking that file for transcoder options you did not configure, and deleting everything in the Codecs folder as part of remediation.

Process names matter as a secondary signal. Plex lists myawesomeproxy, mylovelyminer and x12345 as examples observed after exploitation, and notes outbound traffic to proxystream.st plus high CPU while idle.

Remediation that addresses the loader

Upgrading to 1.43.3.10861 or later closes the write path, but it does not remove a file that is already in the Codecs directory. Reboot after the upgrade only if the directory was verified clean.

Where compromise is plausible, Plex recommends rebuilding the server from a clean installation instead of reusing the data directory, deleting the Codecs contents, signing out all devices and changing the Plex password. Treat mounted shares and credentials reachable from the service account as exposed.

A tighter default would help beyond this CVE: keep the server's data directory writable only by the service account, monitor that directory for new shared objects, and restrict remote access and port 32400 forwarding to hosts that need them.

Exposure context

A ZoomEye query for app="Plex Media Server" returned 507,974 matching assets when this article was prepared, while vul.cve="CVE-2026-96654" returned 0. The product count measures internet-facing Plex installations, not hosts confirmed vulnerable, and it does not reveal which of them have untrusted users with admin rights.

References

Read on DEV Community ↗ ← Back to News

Comments

No comments yet. Start the discussion.