Pulp-style illustration of a brass detective robot with a magnifying glass examining a glowing red codec drawer

Hunt: Plex2Shell implants in the Plex Codecs folder

Plex2Shell ends with a shared object dropped into a folder that Plex loads without asking questions. That makes the folder a good place to watch. Two Sigma rules for free Linux telemetry, both untested drafts.

The behaviour we’re hunting

The Plex2Shell write-up describes the final stage. A crafted TranscoderH264Options setting with dump-yuv= writes an attacker’s file into Codecs/<setid>-linux-x86_64/. Plex’s libavutil.so.58 loads every .so in that directory through avpriv_load_new_libs, and the library’s constructor runs as the plex user. Our news piece covers the full chain and the fix.

Plex’s notice gives the rest of the picture: processes named myawesomeproxy, mylovelyminer and x12345, unfamiliar .so or .dll files in Codecs, traffic to proxystream.st, and a server that works hard while doing nothing.

That gives us two places to look: the file landing, and what Plex starts afterwards.

Rule 1: a shared object lands in Codecs

On a standard Linux package install the directory is /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Codecs/. The rule matches on the /Plex Media Server/Codecs/ fragment so it also catches Docker and NAS layouts.

Plex downloads legitimate codecs into the same place, so the rule excludes writes by the main Plex Media Server binary. That exclusion is an assumption we haven’t verified: if your telemetry shows codec downloads coming from another process, adjust it, and if you’d rather see everything, drop the filter and baseline first. Codec files change rarely, so the noise should be low either way.

title: Shared Object Written To Plex Media Server Codecs Directory
id: bfbae48d-36b3-4b3b-acbf-e2d94f775a0b
status: experimental
description: |
    Detects creation of a .so file under the Plex Media Server Codecs directory by a process other than
    the main Plex Media Server binary. Plex2Shell (CVE-2026-96652, CVE-2026-96654, CVE-2026-96655,
    CVE-2026-96656) writes a shared object there via transcoder settings, which libavutil then loads.
    UNTESTED DRAFT: not yet run against live or lab data.
references:
    - https://zmain.info/blog/plex2shell
    - https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319
author: Cyber-Threat.net Hunt Lab
date: 2026-10-22
tags:
    - attack.initial-access
    - attack.execution
    - attack.t1190
    - attack.t1574
    - cve.2026-96656
logsource:
    product: linux
    category: file_event
detection:
    selection:
        TargetFilename|contains: '/Plex Media Server/Codecs/'
        TargetFilename|endswith: '.so'
    filter_optional_plex_updater:
        Image|endswith: '/Plex Media Server'
    condition: selection and not 1 of filter_optional_*
falsepositives:
    - Legitimate codec downloads if Plex fetches them from a process other than the main server binary
    - Plex upgrades or reinstalls
level: high

Rule 2: Plex starts something it shouldn’t

The second rule looks for Plex Media Server or Plex Transcoder spawning a shell, a download tool or an interpreter, plus the three process names Plex published. A miner usually needs fetching, and fetching usually means curl or wget. The constructor in the dropped library could, of course, do everything in-process, so treat silence from this rule as weak evidence.

title: Suspicious Child Process Of Plex Media Server Or Transcoder
id: dff4601d-77cc-45d5-82af-243f438ed0d0
status: experimental
description: |
    Detects Plex Media Server or Plex Transcoder spawning shells, download tools, interpreters or the
    process names Plex listed as Plex2Shell indicators. UNTESTED DRAFT: not yet run against live or lab data.
references:
    - https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319
    - https://zmain.info/blog/plex2shell
author: Cyber-Threat.net Hunt Lab
date: 2026-10-22
tags:
    - attack.execution
    - attack.t1059.004
    - attack.t1105
    - attack.impact
    - attack.t1496
logsource:
    product: linux
    category: process_creation
detection:
    selection_parent:
        ParentImage|endswith:
            - '/Plex Media Server'
            - '/Plex Transcoder'
    selection_child:
        Image|endswith:
            - '/sh'
            - '/bash'
            - '/dash'
            - '/curl'
            - '/wget'
            - '/python'
            - '/python3'
            - '/perl'
            - '/nc'
            - '/ncat'
            - '/socat'
            - '/busybox'
    selection_ioc:
        Image|endswith:
            - '/myawesomeproxy'
            - '/mylovelyminer'
            - '/x12345'
    condition: (selection_parent and selection_child) or selection_ioc
falsepositives:
    - Plex plugins or scripts that legitimately shell out (rare on current versions)
level: high

Getting the telemetry for free

  • Sysmon for Linux produces both file_event (FileCreate) and process_creation events, and is the closest fit to these rules.
  • auditd covers process creation through execve rules. Watching the Codecs directory is awkward because of the spaces in the path, which audit rule files handle badly; check your result with auditctl -l.
  • Wazuh file integrity monitoring copes with the spaces. A <directories realtime="yes" whodata="yes"> entry on the Codecs path will flag new files with the process that wrote them.
  • Elastic, free tier, takes the output of sigma convert -t lucene or -t esql from the free sigma-cli. Map field names to ECS (file.path, process.executable, process.parent.executable) with a small custom pipeline (there is no stock ECS pipeline for Linux), or convert with --without-pipeline and rename the fields by hand.

A quick manual check

No telemetry? You can still look. List the Codecs tree with modification times, compare it with a known-good install of the same version, and look for files newer than your last Plex update. Check Preferences.xml for a TranscoderH264Options value you didn’t set. And see what the plex user is running right now: a media server with a process called mylovelyminer has answered the question for you.

Status and limits

Both rules pass sigma check and convert to Lucene without errors. That is all. Neither has been run against real or lab data, so treat them as untested drafts.

  • They cover Linux only. Plex’s indicators mention .dll files too, so Windows hosts need their own version.
  • Rule 1 assumes the default directory name. Paths in containers vary.
  • Rule 2 will miss an implant that never spawns a child.
  • If either rule fires on an exposed server older than 1.43.3.10861, don’t tune it. Rebuild the server, as Plex advises.

If you test them, we’d like to hear how they behaved.

What to do

  1. Update Plex to 1.43.3.10861 or later.
  2. Deploy the rules, or run the manual check, on every Plex host, including the one under someone’s desk.
  3. Hunt back to at least 16 October, when the proof of concept went public.
  4. On any hit, isolate the host, preserve the Codecs directory and Preferences.xml, then rebuild, sign out all devices and change the Plex password, and treat anything the plex account could reach as exposed.

More hunts like this one are collected in Hunt Lab, and the Alert Tracker lists every actively exploited flaw we are following.

Sources