因质疑、叨扰声太多，已更新披露漏洞信息和临时解决方案。
前言
本来以为 EmbyServer 相关的事件已经彻底结束了。结果这两天朋友告诉我，现在 EmbyServer 被侵入的事件越演越烈，而且似乎不局限于插件和第三方服务，种种迹象表明，EmbyServer 本身可能也有问题。
朋友顺带给我提供了一张截图，告诉我之前7月份的时候，已经有人发现并向 EmbyServer 厂商提交过一个危害等级比较高的授权漏洞，不过受影响版本是 v4.9.0.35 及以下。（他受到攻击的版本是 v4.9.1.80，应该跟这个授权漏洞无关，自上次发文更新后，他的服务器没有再受到过影响。）
但是这件事本身还是出乎我的意料了，因为我先入为主的认为，一个曾经开源过且被大量使用的项目应该不太可能存在这种问题。
但是转念一想，当年 log4j 出现漏洞之前，大伙又何尝不是这么想得？看来有句话说的不错，这个世界本质上就是个巨大的草台班子
言归正传，在了解到 EmbyServer 本身可能并不安全以后，我尝试去收集和了解上文提到的 CVE-2025-46387 的漏洞细节，看看问题在现有版本是否依然存在。但是厂商那边似乎迟迟没有修复该漏洞，导致相关的细节一直没有公开，问了几个朋友，也都说不太清楚。
既然获取不了，那我只能自己去尝试挖掘有没有别的 0day。
过程
本来写了详细的挖掘思路和操作过程的，但是被提醒到，可能会被别有用心的用户利用，还是省略了。
结果
意外发现了一个 EmbyServer 严重的访问控制失效问题，不确定和上面提到的是不是同一个也不确定是不是最近导致 EmbyServer 入侵频发的原因。
漏洞名称: 访问控制失效
漏洞等级: 高危
影响范围: v4.9.1.80(截止2025.10.29最新版本) 及以下
具体表现，在 EmbyServer 没有额外安全配置的情况下，几乎可以攻破任意 EmbyServer，（无需Token， 无需拥有账户）。
昨天录制了一个，纯净系统下，本地环境搭建的最新的 v4.9.1.80 版本的官方 EmbyServer ，基本可以做到在 1 分钟内攻破，多次实验，基本不超过 3 分钟。】
具体的过程见:
漏洞信息披露
摘要
Emby Server 的密码重置功能存在多个安全缺陷组合，导致未经身份验证的远程攻击者可以通过暴力破解一个熵值极低的4位数字验证码，最终重置任意或所有用户的密码，包括管理员账户，从而导致服务器被完全接管。
细节
由以下三个缺陷共同导致：
全局密码重置
缺陷：密码重置接口，在处理请求时，允许攻击者提交一个空用户名的重置请求来进行对所有用户的密码进行重置的操作。
后果：此缺陷允许攻击者在不知道任何有效用户名的情况下，强制重置服务器上所有账户的密码。
验证码复杂度过低
缺陷：系统用于验证密码重置的 PinCode 仅为一个4位纯数字
后果：PinCode 的总可能性空间仅有 10000 种组合，极易受到暴力攻击破解。
缺乏速率限制与动态路由
缺陷：用于提交 PinCode 的验证路由是固定的，并且没有严格的速率限制机制
后果：攻击者可以无限制地（或在很宽松的限制下）向此路由提交破解尝试。
结论
允许一个远程的、未经身份验证的攻击者，在无需任何先验知识（如用户名）的情况下，通过低成本的暴力破解攻击，获得 几乎任意版本 的Emby Server 的最高管理员权限。
修复方案
老规矩，首先要做的是，第一时间提交厂商。
至于出一个第三方修复方案，和朋友沟通后似乎直接公布也蛮容易让有心人逆向出来原理的。因为该 0day 影响范围比较广，利用起来又有些简单，还是减少这种可能比较好。
我之前写过一篇关于《【Geek】EmbyServer Token 安全维护指南》 的文章，里面详细阐述了如何最大化保障 EmbyToken 的安全。现在回过头看，里面提到的各种策略，对于防范此次新发现的 0day 依然有效。
EmbyServer 之所以频繁爆出安全问题，我的评价是: 根源在于其核心设计理念与产品定位与使用场景不符。我在查找的过程中能感受到，EmbyServer 更多的是为授信环境（如家庭网络）下的用户设计的媒体资源库，权限与职责划分非常粗糙。如果暴露在公网等非授信网络，各种基于授信环境下构建的安全机制特别容易失效。
要想从根本上解决这个问题，还是得回到我之前文章中提倡的方案: 引入一层【安全网关】（最好是方案2，当然用反向代理并配置严格的访问策略也不是不行），用于彻底屏蔽 EmbyServer 在权限机制上的设计缺陷。
感觉要么 EmbyServer 自己重做解决一下，要么使用【安全网关】，否则任何基于现有架构的局部修复方案，我个人感觉，意义不大，治标不治本。
临时修复方案 - 禁止密码重置功能
默认情况下，EmbyServer 的密码重置功能会在 EmbyServer 的 /config 文件夹下，生成 passwordreset.txt，里面记录了重置密码所需要的 PinCode。可以使用如下命令在该位置生成占位符，让重置密码的操作执行失败，从而避免爆破。
已经过验证，实实在在的中断了重置操作，而不单单只是个前端返回错误，需要注意，此种修复方案会导致重置密码功能失效。
mkdir passwordreset.txt && chmod 000 passwordreset.txt
# 注意，下面的命令权限配置不合理的情况下是没用的，不如上面的稳固
# touch passwordreset.txt && chmod 000 passwordreset.txt 临时修复方案 - 反向代理路由屏蔽
看个人需求和发挥了，实在不会可以结合 <<官方 API 文档>>，问问AI,方法多种多样。
location ~* ^/emby/Users/ForgotPassword {
return 403;
# 或者使用 deny all;
}修复验证
如果在前台，你的密码重置功能不好用了，且在 EmbyServer容器内的 /config 目录下找不到 文件 passwordreset.txt，就说明成功了。
溯源
利用该漏洞针对指定用户的定点爆破，登录 EmbyServer 的 WebUI 后台能发现的痕迹是很少的，很容易被大量的信息给覆盖掉，尤其是用户数比较多的情况下。
如果你想溯源，或者是简单查看是否有用户已经利用该漏洞后偷偷隐藏起来，可以在 EmbyServer 容器内的 /config/logs/embyserver.txt 文件中，搜索 /emby/Users/ForgotPassword 相关信息，可找到痕迹。
后记
应该是 EmbyServer 相关的最后一篇了吧？另外经过核查，很多 EmbyServer 的侵入事件并不一定是上述原因导致的，漏 Token 的也占了不小比例，至于有没有其他的漏洞，暂时不太清楚，做好安全防护永远是最重要的。
如果你感觉本篇文章对你有帮助的话，可以给予我一些小小的鼓励，感谢您的支持。
评论