正在被实际利用的 Plex 漏洞被用来投放加密货币挖矿程序

漏洞与利用细节

• 利用目标是较旧的 Plex Media Server；修复已随 1.43.3.10861（8 月）发布。任何更旧的版本都存在漏洞。
• 利用链（“Plex2Shell”）结合了多个 CVE；其中一些阶段被批评为安全设计特别糟糕（例如：只检查头是否存在却不验证其内容、仅依据字符串前缀检查 localhost URL）。
• 只有暴露在互联网上的 Plex 实例会受影响；服务器无法从家庭局域网外部访问的用户被认为不会受到此问题影响，但仍建议打补丁。

远程访问 vs VPN（Tailscale 等）

• 许多人会把 Plex 直接放在公网，原因是：
  • 这是 Plex 为远程串流和共享设定的默认/预期使用场景。
  • 非技术用户的朋友/家人以及随机设备（智能电视、电视棒）无法稳定使用 VPN。
• 也有人强烈认为，Plex（以及类似的自托管应用）应该只通过 VPN（WireGuard/Tailscale/netbird）暴露，或者至少通过反向代理并增加额外认证。
• 还有人指出使用 VPN 的现实摩擦：手机只能保留一个 VPN 槽位、电池耗电、缺少电视端应用、CGNAT 问题。

真实世界中的入侵

• 多位用户报告自己遭到入侵：CPU 占用很高、明显的矿工进程（“MyLovelyMiner”、伪装成系统名称的进程）、配置中出现 Monero 挖矿池，某些情况下还带有额外载荷，例如 DDoS 节点。
• 一些机器上的 Plex 都已更新到最新版，但操作系统安全补丁落后，这使人无法确定在这些案例中究竟是 Plex 还是操作系统成为了入口点。

缓解措施与加固

• 普遍共识是：一旦被入侵，就应视该系统为不可信；最佳实践是完整重装操作系统，而不只是删除矿工程序。
• 建议的加固措施：
  • 保持 Plex 和操作系统完全更新；修复损坏的软件包源。
  • 避免直接暴露 Plex；优先使用 VPN、Cloudflare tunnels，或反向代理（nginx/caddy、Authelia、限速、fail2ban、地理封锁）。
  • 如果不需要，移除 curl/wget；将 /tmp 挂载为 noexec；限制外向连接（例如按二进制程序设置防火墙、屏蔽挖矿池）。
  • 使用检测工具（YARA 规则、decloaker、chkrootkit、unhide）来搜寻痕迹。

Plex 自动更新与 NAS 担忧

• 自动更新支持并不一致：
  • 某些平台提供可选的自动更新。
  • 容器自动更新被描述为笨拙，并且在一定程度上破坏了容器不可变性。
  • 尤其是 Synology 套件的安全更新滞后；有人警告绝不要将 Synology 服务暴露到互联网上。
• 这种不一致很可能让许多老旧、易受攻击的 Plex 实例仍然暴露在外。

Plex 的 UX、策略与替代方案

• 一些用户抱怨 Plex 的 UX 已经退化：变慢、杂乱，并且优先推广免费的广告支持电视内容，而不是个人媒体库；有人觉得最新 UI 在某些设备上“无法使用”。
• 变通办法包括：
  • 替代客户端应用（例如第三方 Plex 前端、某些平台上仍保留旧 UI 的不同客户端）。
  • 改用 Jellyfin 或其他服务器，通常再配合 VPN 或反向代理。
  • 高度收紧的部署方式（一次性 Jellyfin 容器，媒体挂载为只读）。
• Jellyfin 因其开放性和可控性而受到赞赏，尽管早期版本曾因视觉表现粗糙而受到批评；有人表示它已经有所改进。
• 文中还提到一个新入局者（Pixel Brite），目标是把低摩擦的远程访问与充足的免费功能结合起来。

安全文化与攻击者经济

• 有些人认为加密挖矿载荷缺乏创意、价值不高，但也有人强调，任何立足点都可能被用于更糟的用途。
• 一条评论指出，多年来 Plex 一直存在“规模不大但后果显著”的安全问题，这进一步强化了这样一种观点：自托管媒体服务器需要与其他面向互联网的服务一样的防御思维。