导语：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.<attacker>.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<pid>、myawesomeproxy、/tmp/xsetup.lock 和 Codecs 目录下形如 zz<hex>.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/<pid>/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 的钥匙，后者让凭据自己送上门。
消费级服务直连公网不是原罪，但它同时具备庞大攻击面、宽松的默认信任模型，以及不打补丁的用户群——三者凑齐就是攻击者最爱的目标。修完补丁顺手关掉端口转发，性价比比任何检测规则都高。后续云栈社区也会持续跟进这条链的利用动态与处置经验。
本文由华盟网原创发布，版权归原平台所有。
发表于 5 小时前
|
查看: 9|
回复: 0
