2026-10-22 12:39:14 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

Plex服务器被人拿来挖矿，八月发布的补丁还在等管理员安装

原创

tcode
tcode

字节脉搏实验室

2026年10月20日 11:27
北京

去阅读

一台放在家里的媒体服务器还能正常播放电影，CPU却长期跑满，进程列表里出现一个没人认识的矿工程序，这往往比“打不开网页”更难解释。2026年10月16日，Zach Main公开了Plex2Shell漏洞链；次日，安全研究者boredhackerblog在自己的蜜罐里看到利用请求，并从外部服务器下载到挖矿载荷。到了10月19日，公开报道又记录了一个名为myawesomeproxy的Linux反向代理。Plex官方修复版其实在8月3日已经发布，只是旧实例仍在互联网上等管理员行动。

先把事实边界说清。蜜罐记录的是攻击者对一台可控测试服务器的利用尝试，能证明公开代码很快进入自动化扫描，并与载荷下载、进程创建形成时间对应；它不能证明中国大陆有多少用户的Plex已经被攻破，也没有公开材料说明这些IP背后是谁。报道提到的同名矿工程序之所以值得重视，不在于“挖矿”损失通常多大，而在于执行代码的权限发生在Plex服务进程里。能挖矿的通道，同样可能被用来读取媒体库、配置文件、令牌和主机上可写的数据。

这条链并不等于一个漏洞直接打穿服务器。第一步从/player/timeline进入：代码只检查请求是否带X-Plex-Token头，没有验证令牌是否有效，因此一个无效值也可能通过；随后，protocol参数被拼进服务端发起请求的地址，形成未认证SSRF。攻击者不是直接从公网调用那些只应供本机使用的插件接口，而是让Plex服务器向自己的回环地址发请求，从而跨过本地信任边界。

进入回环位置后，/system/agents/\*中的searchOne接口允许调用插件函数。攻击者把构造好的identifier参数写成对网络请求函数的调用，再借插件框架的令牌附加逻辑外带所有者管理员令牌。关键细节是前缀判断：代码看到URL以http://127.0.0.1开头，就把令牌放进请求头；127.0.0.1后还能接一个由外部解析的域名，使请求最终落到攻击者地址。这里既有回环信任被滥用，也有字符串前缀匹配没有按主机名边界核对的问题。

拿到所有者令牌后，攻击面从“匿名请求”升级为“管理员请求”。攻击者可以修改服务偏好，并让转码器读取外部媒体描述和视频；转码参数又允许把解码帧写入指定路径。研究者利用无损编码，把共享库按字节写进Codecs目录，再触发下一次转码加载。只把它们理解成“四个CVE排队利用”不够准确：真正起作用的是SSRF、回环插件调用、令牌泄漏、任意路径写入与动态库加载之间的权限传递。公开写入路径假设攻击者能访问目标主机和Codecs目录，不能脱离这些条件宣称任何Plex实例都能被同一载荷打穿。

对管理员，最有效的第一步不是急着升级，而是画一张二维暴露表。横轴是版本：低于1.43.3.10828属于受影响范围，1.43.3.10861是公开修复版；纵轴是入口：32400是否直接从互联网可达，是否只经VPN或反向代理，代理是否限制到/player、/system/agents和转码路径。旧版本加公网直开是最高优先级；旧版本只在局域网也要补；新版本若在修复前公网开放，还要查是否已经失陷。版本号回答“漏洞是否应存在”，不能回答“令牌有没有被拿走”。

这里还有一个容易被标题概括掉的口径差异。Plex论坛把1.43.3.10861写成面向Plex Pass用户的Beta更新，并不意味着8月3日所有安装渠道都完成了自动替换，也不等于每台开启自动更新的服务器已经从旧构建跳到该版本。应直接读取Plex正在运行的构建号、安装包来源和最近一次成功更新时间，再与修复说明对照。如果机器使用容器镜像，镜像标签没有变化也可能藏着旧内核版本；如果由家人或集成商维护，还要确认他们是否只是看到“应用商店显示最新”，却没有实际重启服务。

第二步才是保全现在的状态。不要先清理Codecs目录或重置全部配置，否则后续只能看到一台“恢复正常”的机器，却无法解释异常来源。记录Plex进程的启动参数、运行用户、完整命令行、网络连接和父子进程关系；保存反向代理、系统防火墙、容器和宿主机中32400的访问日志。重点看/player/timeline/subscribe请求、protocol=http://127.0.0.1...参数、异常的searchOne标识符，以及服务端随后访问外部域名或IP的成对记录。设备还能播放影片，只能说明服务仍在运行，不能排除数据已被读取。

第三步查配置和写入痕迹。在Plex偏好里搜索TranscoderH264Options和dump-yuv，确认是否有人写入异常输出路径；在Codecs的集合目录中比较新增文件、修改时间、所有权和哈希，尤其是没有lib前缀的.so文件。再看Plex运行用户可写的目录、容器挂载、开机启动和计划任务。myawesomeproxy、mylovelyminer、ota.proxystream[.]st及其同域基础设施可以作为检索线索，但单凭字符串命中不能判定攻击链；同样，发现一个矿工也不能自动解释它是从哪个入口进入的。

把这些检查压缩成权限迁移表，顺序会更清楚：公网请求先证明能否到达/player/timeline；回环插件请求证明匿名输入是否变成本机可信调用；带X-Plex-Token头的外部请求证明所有者令牌有没有被带出；TranscoderH264Options和Codecs目录证明管理员权限有没有继续变成文件写入与代码加载。上一段缺失时，下一段的证据仍然可疑，但不能单独补成完整链条。值班人员尤其不要只凭代理日志里出现一个127.0.0.1字符串就宣告失陷，也不要在只发现旧版本时忽略服务器是否曾在公网开放过。

确认风险后，处置顺序应倒过来。先停止公网直接暴露，变更Plex所有者令牌及复用过的账号密码，再隔离服务器并保留磁盘快照；随后按公开修复版重建或升级，清理未授权偏好、反向代理配置、动态库、容器挂载和持久化任务，最后才恢复媒体服务。只改端口不等于已清场，攻击者若已经拿到令牌，仍可能从VPN、反向代理管理面或其它已暴露接口继续访问。若服务器承载家庭照片、密码库备份、私钥或可用于登录内网的凭据，清理后的信任审查范围还要从Plex延伸到这些数据。

修复版为什么早于公开研究？研究者的披露时间线显示，问题在7月27日提交给Plex，8月4日获得确认，9月23日分配CVE，10月16日才公开细节。Plex论坛在8月3日发布1.43.3.10861，其中两条安全修复涉及CompanionProxy和“不再允许通过网络修改TranscoderH264Options”。版本与日期在这里比CVSS分数字更有用：管理员可以核对安装时间，判断服务器是否在8月到10月之间长期停留于旧版，同时避免错误地把“今天刚升级”当成过去没有暴露。

公开报道中的数字也应按口径拆开。Plex官方当时提醒1.43.2及更早版本更新，但并未公布受影响实例数量；研究者的蜜罐只展示了若干来源IP与一个载荷下载源；THN引用的Reddit帖能看到其他人报告同名矿工，却明确无法确认那些案例都来自Plex2Shell。因此，合理结论是“漏洞链真实、公开利用已出现、部分情形会造成可见挖矿或代理”，而不是“任何Plex服务器都已被控制”。中国大陆读者也不需要等本地受害者通报才行动，资产条件本身就能支持自查。

有一个非常直接的判断问题：这台Plex在修复前是否曾从互联网直接访问，而且所有者令牌和TranscoderH264Options现在是否可用？若答案都是是，升级只解决未来，需要按失陷处理；若公网入口一直关闭、版本也符合修复要求，风险仍不等于零，但优先级和证据要求不同。把服务器是否“还能用”换成“入口、令牌、写入路径和动态库是否对得上”，才算真正完成这起公开利用事件后的判断。没有公开证据能替管理员回答最后一个问题，日志和主机状态可以。

来源

Zach Main，《Plex2Shell: Unauthenticated RCE in Plex Media Server》，2026-10-16，https://zmain.info/blog/plex2shell

code-zm / Zach Main，Plex2Shell公开代码与版本、CVE对应说明，https://github.com/code-zm/plex2shell/

boredhackerblog，《Plex vulnerabilities being exploited in the wild to drop a cryptominer》，2026-10-17，https://www.boredhackerblog.info/2026/10/plex-vulnerabilities-being-exploited-in.html

Plex Forum，Plex Media Server 1.43.3.10861发布说明，2026-08-03，https://forums.plex.tv/t/plex-media-server/30447/712