导语：Plex Media Server 被曝出一条无需登录凭据的远程代码执行链 plex2shell，由四个 CVE 串成。补丁已发布，攻击者动手更早——10 月 17 日起已在野投放挖矿木马和住宅代理。
一、四个 CVE，一条链
研究者是安全研究员 Zach Main（zmain.info）。7 月 27 日报给 Plex，8 月 4 日确认并支付赏金，9 月 23 日 CVE 编号落地，10 月 16 日公开披露：
| CVE | 原语 |
|---|---|
| CVE-2026-96652 | /player/timeline 的 protocol= 参数未授权 SSRF |
| CVE-2026-96654 | 环回鉴权豁免 + searchOne 的 identifier= 注入 |
| CVE-2026-96655 | owner 鉴权下的转码器 SSRF + 任意路径写文件（dump-yuv） |
| CVE-2026-96656 | 未签名 codec 的 dlopen 导致代码执行 |
单看任何一个最高也只有 7.2 分，串起来却是 CVSS 9.8 的未授权 RCE，且不需要有效登录态。受影响的是 1.43.3.10828 之前的版本，修复版本 1.43.3.10861。
图源：推文卡片截图
二、链是怎么串起来的
第一步是伪造身份混过闸门。/player/timeline 端点的 token 检查只判断 X-Plex-Token 这个头存不存在，从不校验值是否有效。随便填个 junk 就能进。
第二步是让服务器打自己。播放器订阅回调的 URL 由 protocol、host、port 拼成，protocol 未经校验直接拼进去。攻击者把完整 URL 塞进这个字段，取消订阅时 PMS 就从真实的 127.0.0.1 源头发 POST——服务器自己把自己 SSRF 了。
第三步是环回免鉴权。/system/agents/* 这套插件管理 API 对环回来源不要求 token，上一步的环回请求因此拿到通行证。接着 searchOne 的插件白名单检查是个摆设：装饰器包住的内部函数提前返回时返回值被丢弃，外层照常往下走，从未”检查”从未拦截过任何东西。
第四步是偷走管理员 token。伪造的调用最终指向 networking.py:149 的 GetResultFromNetwork。PMS 会给发往 127.0.0.1 的请求自动附加 owner token，攻击者只要把 URL 写成 http://127.0.0.1..sslip.io/...，服务器看到前缀就贴上管理员凭据，而 DNS 把域名解析到攻击者的 IP。
第五步是投递载荷并执行。拿到 owner token 后，调转码接口把 path 指向攻击者托管的一段”载体视频”，再用 TranscoderH264Options=dump-yuv 让 x264 把解码后的帧原样写成 Codecs 目录下的共享对象文件。下一次转码加载 codec 时 dlopen 了这个没签名的库，构造函数直接跑起来，攻击者拿到 uid=1000(plex) 的反弹 shell。
三、找漏洞这件事，LLM 是怎么参与的
Zach 在博客里写清了方法论：Recon（拆组件、画出输入到危险汇聚点的路径）→ Hunt（逐组件定向狩猎）→ Verify（专门起一个 agent 去推翻每个发现，推不倒才算数）→ Chain（找最大影响的组合路径），循环到收益递减。他强调这不是”叫 LLM 去黑 Plex”，判断全由人做，LLM 只让他在更高抽象层上引导。
让 AI 自我证伪，比让 AI 找漏洞更有价值。
四、攻击者比补丁先动了
10 月 16 日公开披露，17 日起就在野被利用。蜜罐捕获的攻击行为很朴素：投放 XMRig 挖矿程序和住宅代理工具，矿池 ota.proxystream.st:3333，带 --rig-id plex 参数。
10 月 20 日，CISA 把四个 CVE 全部列入已知被利用漏洞目录（KEV），期限分两档：CVE-2026-96654 和 -96656 是 10 月 23 日，CVE-2026-96652 和 -96655 是 11 月 3 日。其中 -96656 还需额外做取证排查（BOD 26-04）。”已知被勒索软件使用”一栏仍标记为未知。
IOC 包括攻击源 IP 45.194.92.222、91.92.40.202、176.65.139.228，载荷托管地址 217.60.194.116、77.90.185.205，以及落地文件 /tmp/mylovelyminer、myawesomeproxy、/tmp/xsetup.lock 和 Codecs 目录下形如 zz.so 的植入库。攻击者随时会换名字换 IP。
五、怎么查，怎么修
先修。升级到 Plex Media Server 1.43.3.10861 或更高版本。NAS 用户要注意，包管理器版本可能还没跟上，得去官网下载页手动装。修完顺手撤掉 32400 端口转发。
再查。研究者提供了 YARA 检测规则（GPL-3.0），按三档置信度分层：high 档匹配产物结构特征，攻击者改工具也照样命中；medium 档匹配公开 PoC 字符串，重新编译就失效；hunting 档只能排优先级。规则要求 YARA ≥ 4.2，作者 10 月 18 日用 4.5.7 验证过，素材包括真实转码器 dump 文件和被攻击实验室日志。
社区还基于这套逻辑做了个只读排查脚本 plex2shell-check（GPL-3.0）：
curl -fsSLO https://raw.githubusercontent.com/ChrisLPJones/plex2shell-check/main/plex2shell-check.sh
less plex2shell-check.sh # 以 root 运行前务必先读一遍
sudo bash plex2shell-check.sh -o plex2shell-report.txt退出码 0 干净、1 有告警待看、2 发现入侵指标，全程不修改系统。它检查版本、日志里的攻击请求模式、Preferences.xml 残留的 dump-yuv、Codecs 里的可疑 .so、以 Plex 用户跑着的可疑进程、临时目录落地文件、到已知攻击 IP 和矿池端口 3333 的连接，以及 cron、systemd、SSH 公钥等持久化痕迹。-y 可挂 YARA 规则一起跑；它能识别原生安装、snap、Docker，甚至通过 /proc//root 钻进运行中的容器，在 Proxmox 主机上跑一次即覆盖 LXC 里的 Plex。
下载地址：
处置顺序别搞反。确认被入侵后，先备份 Logs、Preferences.xml 和可疑文件，再停 Plex、杀进程、删掉植入的 .so（或整个 Codecs 目录，Plex 会重新下载），升级补丁后再重新启动。这条链会偷走 owner token，必须改密码并执行”退出所有设备”。如果 Plex 用户有 sudo 或 docker 权限、或与其他服务共用 uid，建议直接重建主机。
研究者的完整利用代码仓库公开（github.com/code-zm/plex2shell，GPL-3.0），但鉴于这条链此刻正在被人在野牟利使用，本文只提供防御侧的检测规则与只读排查工具，不分发可直接运行的武器化利用脚本。
六、写在最后
这条链最值得警惕的不是单个漏洞，而是两个架构习惯：环回来源直接视为可信，以及服务端自动给”看起来像自己”的请求附加管理员凭据。前者让盲 SSRF 变成内部 API 的钥匙，后者让凭据自己送上门。
消费级服务直暴露公网不是原罪，但它同时具备庞大攻击面、宽松的默认信任模型和不打补丁的用户群——三者凑齐就是攻击者最爱的目标。修完补丁顺手关掉端口转发，性价比比任何检测规则都高。
版权声明：本文由华盟网原创发布，保留所有权利。配图由华盟网授权使用。
暂无评论内容