文章总结： UniFiOSServer存在三个CVSS10.0满分漏洞(CVE-2026-34908/34909/34910)，攻击者通过HTTP请求无需凭证即可绕过认证网关，利用路径穿越和命令注入获取root权限。漏洞影响Ubiquiti全线产品，root权限可控制整个网络、门禁和摄像头。修复版本为UniFiOS5.0.8，需立即打补丁、轮换JWT密钥、限制管理端口访问，并使用BishopFox开源工具检测。
综合评分： 85
文章分类： 漏洞分析,应急响应,威胁情报,解决方案,网络安全
【安全圈】严重漏洞：UniFi OS 无需密码即可拿下 Root 权限
安全圈
2026年6月14日 19:00
江苏
在小说阅读器读本章
去阅读
关键词
UniFi、Ubiquiti
一、60 秒看完全部要点
- 🎯 一条 HTTP 请求，无凭据、无交互，直取 UniFi OS Server root 权限
- 🐛 三个 CVE 串成链：访问控制缺陷 + 路径穿越 + 命令注入，单个 CVSS 满分 10.0
- 🏠 受害面有多广？Ubiquiti 是全球家庭/SMB 网络第一品牌之一，Cloud Gateway、Dream Machine、UNVR/NVR、UNAS、UniFi Express 全线中招
- 🚨 拿到 root 不只是控制一台服务器 —— 管理平面被攻陷 = 整个网络 + 门禁 + 摄像头 全部失守
- 🔑 更阴险的是：JWT 签名密钥一旦被偷，打了补丁也救不了 —— 攻击者继续用旧密钥伪造 admin token
- 🛠️ Bishop Fox 公开了生产可用的检测工具：CVE-2026-34908-check[2]
- ✅ 修复版本：UniFi OS Server 5.0.8（unifi-core 5.0.153）
二、攻击现场：三次握手拿到 root
2.1 受害应用是个什么玩意儿
UniFi OS Server 是 Ubiquiti 的统一管理平台，把旗下所有产品（Network、Protect 摄像头、Identity、Update）都拢在一个 Web 界面后面。
它的架构长得像这样：
┌──────────────────────────────────────────────┐
│ 客户端（你 / 攻击者） │
└──────────────────┬───────────────────────────┘
│ HTTPS
▼
┌─────────────────────┐
│ Nginx 前端（11443） │ ← 终止 TLS，做认证
└──────────┬──────────┘
│ 内部转发
┌────────────┬────┴────┬────────────┐
▼ ▼ ▼ ▼
ulp-go network protect update
(身份) (网络) (摄像头) (包更新)
整套安全模型全压在一个点上：Nginx 前端必须正确判断”哪些请求是公开的、哪些需要登录”。
2.2 CVE-2026-34908/34909：Nginx 的”精神分裂”
Bishop Fox 团队拿到补丁前（5.0.6）和补丁后（5.0.8）的 rootfs，做了三层对比：
- Nginx 配置（纯文本，diff 干净）
- 一个 1.2 MB 混淆过的
service.js（Node.js 实现 unifi-core 认证处理器） - 几个 Go 二进制（包更新后端）
关键漏洞在第一层 —— 一个 Node.js 的 authCheck 函数：
authCheck = async (req, res) => {
let uri = getHeader(req.headers, "x-original-uri"); // 原始 $request_uri
...
if (publicRoutes.has(`${method} ${uri}`) ||
uri?.startsWith("/api/auth/validate-sso/")) // 白名单前缀匹配
return res.statusCode = 200, res.end();
...
return res.statusCode = 401, res.end();
};
Bug 在哪？ 同一个 URI 在 Nginx 眼里有两个不同的值：
| Nginx 变量 | 用在哪 | 形态 |
| — | — | — |
| $request_uri | 认证检查（白名单前缀） | 原始字符串，%2f 仍然是 %2f |
| $uri | 路由（决定转发到哪个后端） | 解码归一化，%2f → /，../ 被压平 |
精心构造的请求让两边”看法不一致”：
- 原始形态以
/api/auth/validate-sso/开头 → 白名单放行，200 OK - 归一化形态解析成
/proxy/<service>/xxx→ Nginx 把请求转给”假设已经认证过”的后端
🤔 为什么不拆成两个 CVE？ Bishop Fox 也困惑 —— 在他们看来这就是一个 bug，登记成 CVE-2026-34908 + CVE-2026-34909 大概是按”访问控制”和”路径穿越”分别算的影响维度。
2.3 CVE-2026-34910：第二个坑等着你
认证网关被骗过之后，攻击者能访问到 package-update 后端 的一个接口。
这个接口的逻辑很简单：客户端传一个”包名”进来，后端查最新版本，用 shell 命令解析：
// sink 内部大概长这样
cmd := fmt.Sprintf("sudo /usr/bin/uos runnable latest-versions %v", packageName)
exec.Command("sh", "-c", cmd)
%v 直接插值，零校验。 攻击者把 packageName 写成 foo;sleep 5 就能在 shell 里任意执行命令。
同一条路径，有 token 调是 CVE-2026-33000（CVSS 9.1），无 token 调（借由前面的网关绕过）是 CVE-2026-34910（CVSS 10.0）。
Bishop Fox 用了一个非常巧妙的时间型 oracle 做无害验证：
| 版本 | 注入 sleep 5 后响应 |
| — | — |
| 5.0.6（未修复） | HTTP 200，但延迟了 5 秒（命令真的执行了） |
| 5.0.8（已修复） | HTTP 400，零延迟（拒绝执行） |
“slow 200 vs fast 400” —— 这就是验证漏洞的标志性差异。
2.4 第三跳：服务账号的”豪华 sudo 配置”
命令注入拿到的 shell 不是 root，而是 ucs-update 这个服务账号。
按理说被沙箱化也认了。但 Ubiquiti 给了这个账号一个豪华 sudoers 白名单：
ucs-update ALL=(ALL) NOPASSWD: /usr/bin/dpkg
ucs-update ALL=(ALL) NOPASSWD: /bin/chmod
ucs-update ALL=(ALL) NOPASSWD: /bin/systemctl
ucs-update ALL=(ALL) NOPASSWD: /usr/bin/uos
每一条都是”一键 root”：
dpkg -i安装一个.deb，postinst 脚本以 root 跑chmod改/etc/shadow权限systemctl改服务配置uos是 Ubiquiti 自家命令
Bishop Fox 选了最简单的 dpkg 路径：打了个空壳 .deb 包，postinst 脚本里写一句 cat /etc/shadow > /tmp/out，sudo -n dpkg -i evil.deb —— 拿到 shadow 文件内容，root 身份坐实。
“提权不是难点，是走个过场” —— 攻击者从一条 HTTP 请求到 root shell，总共三次跳转。
三、为什么”拿到 root”等于”控制整个家”
UniFi OS Server 不是一个普通应用服务器，它是管理平面。
Bishop Fox 在博客里点出关键：
Root 读到的是整个密钥库：
- JWT 签名密钥（最致命 —— 见第四节）
- TLS 私钥
- 云端 token
- 用户数据库
- RADIUS / WiFi / VPN 凭据
Root 写的是物理世界：
- 解锁门禁（UniFi Access）
- 关闭/调取摄像头（UniFi Protect）
- 控制交换机 ACL、防火墙规则
- 改 DNS 把所有客户端劫持到钓鱼页
一个家庭或小公司可能花几十万元部署 UniFi 全套生态，结果一条 HTTP 请求就全部拱手让人。
四、最阴险的细节：补丁救不了你
Bishop Fox 在结尾专门强调了一段所有应急人员必看的话：
“The fix closes the way in, but it does not reach back and undo what an attacker already did with root on an instance that was exposed beforehand.”
具体说：
| 攻击者已经做过的 | 补丁能不能撤销 |
| — | — |
| 偷走 JWT 签名密钥 | ❌ 不能 |
| 用旧密钥铸造的伪造 admin token | ❌ 继续有效，直到密钥轮换 |
| 设置 SSH root 密码 / 留后门 | ❌ 继续有效 |
| 留持久化（cron / systemd unit） | ❌ 继续存在 |
所以”打补丁”是起点，不是终点。 Bishop Fox 强烈建议已经暴露过但还没确认是否被入侵的设备，直接重建，不要相信”轮换密钥就够了”。
五、给防御者的 5 步操作清单
5.1 立刻打补丁
| 产品线 | 修复版本 |
| — | — |
| UniFi OS Server （软件） | 5.0.8 （unifi-core 5.0.153） |
| Cloud Gateways / Dream Machines / NVR | 5.1.12+ |
| UNAS 系列 | 5.1.10+ |
| Dream Machine Beast | 5.1.11+ |
| UniFi Express | 4.0.14+ |
5.2 如果暂时打不了补丁
只做一件事：把管理界面的网络可达范围缩到最小。
UniFi OS Server 默认监听 TCP 11443。两条铁律：
- ❌ 绝不要让这个端口能从公网直接访问
- ❌ 绝不要让这个端口暴露在访客 VLAN
- ✅ 放在专门的管理 VLAN，ACL 收紧
5.3 跑 Bishop Fox 公开的检测工具
git clone https://github.com/BishopFox/CVE-2026-34908-check
cd CVE-2026-34908-check
# 单个目标
python3 check.py 192.168.1.1:11443
# 批量
python3 check.py -f targets.txt --json
它做了什么、为什么安全：
- ✅ 发一个不带注入参数的探测请求，不会执行任何命令
- ✅ 不会读任何文件或密钥
- ✅ 不会修改目标状态
- ✅ 4 种结论：vulnerable / patched / unaffected（不是 UniFi OS Server）/ inconclusive（需要人工）
退出码非零 = 有目标未修复，可以直接接 CI/CD 或巡检脚本。
5.4 轮换所有密钥（从 JWT 签名密钥开始）
ssh root@<device>
openssl rand -hex 32 # 生成新密钥
# 编辑 /data/unifi-core/config/jwt.yaml → secret: <新密钥>
reboot # 必须重启，所有 token 消费者重载
然后再轮换：TLS 私钥、云端 token、数据库密码、RADIUS / WiFi / VPN 凭据。 最后强制所有用户登出。
5.5 在边界上检测攻击特征
Bishop Fox 给的规则极其干净：
任何合法请求都不应该带 URL 编码的路径穿越序列。
所以你只要在 Nginx / WAF 上配规则：
- URI 同时包含
/api/auth/validate-sso/和..%2f/..%2e/%2e%2e等 → 告警package-update路由（/.../ucs/update/latest_package）参数含 shell 元字符 → 告警- 主机上出现异常子进程 → 告警
⚠️ 重要：必须在边界日志或SIEM上做这件事，不能依赖目标主机的本地日志 —— 攻击者拿到 root 后能清日志，而且
ucs-update这个账号的 sudo 操作默认就不写日志。
六、CVE 一览表
| CVE | 描述 | 触发条件 | CVSS | 致谢 |
| — | — | — | — | — |
| CVE-2026-34908 | 认证网关访问控制缺陷 | 未认证 | 10.0 | Duc Anh Nguyen (@heckintosh_) |
| CVE-2026-34909 | 认证网关路径穿越 | 未认证 | 10.0 | Abdulaziz Almadhi（Catchify Security） |
| CVE-2026-34910 | 包更新后端命令注入 | 未认证 （走网关绕过） | 10.0 | John Carroll |
| CVE-2026-33000 | 同上命令注入 sink | 带有效 view:identity:update token | 9.1 | V3rlust |
| CVE-2026-34911 | 低权文件读路径穿越 | 部分认证 | 7.7 | Hakai Security |
三个 10.0 串成链，而且致谢来自三个不同的安全研究者 —— 这条攻击链不是单点发现，是社区协作拼出来的。
七、几个值得追问的反思
7.1 “一行 if 缺失”的故事再次上演
还记得 Meta Instagram 那个”密码重置不验证邮箱”的洞吗？
这次的 UniFi OS 漏洞是同一个剧本：
“本来该写但没写的一行代码”
if (uri_normalized !== uri_raw) return reject; // 没人写这行
安全行业有个说法：最贵的不是 0day，是”一行没写过的 if”。
7.2 服务账号为什么有 NOPASSWD sudo dpkg？
ucs-update 这个账号的业务是”包更新”。给它 dpkg 权限听起来”合理” —— 但任何能在 root 上下文跑 postinst 脚本的能力，就是 root 本身。
这是经典的 “最小权限原则” 失守案例：
- 业务需要
dpkg✅ - 但不一定要 NOPASSWD ❌
- 更不一定要能装任意来源的 .deb ❌
正解：用 apt 的本地仓库 + 签名校验，让 ucs-update 只能”装白名单里的包”，而不是”装网上下载的任何 .deb”。
7.3 “补丁即终点”是个危险的幻觉
“我们已经打了补丁”是 90% 应急响应的句号，但这次是逗号。
JWT 签名密钥的”前向保密”问题，在几乎所有 SaaS / 设备管理平台都存在：
| 平台类型 | 类似的”补丁救不了”风险 |
| — | — |
| 单点登录（SSO） | 签名密钥泄漏 → 攻击者继续伪造 SAML/JWT token |
| API Gateway | API 签名密钥泄漏 → 攻击者继续签发请求 |
| 设备管理平台 | 设备身份密钥泄漏 → 攻击者继续冒充设备 |
“先补丁，再轮换，再清理” 永远是这个顺序。
7.4 这次”无危害”检测的设计值得借鉴
Bishop Fox 的探测工具不靠 PoC 复现，靠的是目标行为差异：
- 漏洞版：缺参数时到达 handler 内部才报错（HTTP 200）
- 修复版：在网关层就拦下来（HTTP 400）
这种”用行为差异代替真实利用”的检测思路，值得国内安全团队抄作业。它适用于一切你不能随便”实际入侵”的生产环境。
八、结语
一次 HTTP 请求，2 万美元设备交出 root。 一次完整攻击链，CVSS 三个 10.0。 一次成功入侵，补丁都救不回来。
UniFi 是全球数百万家庭和企业的网络心脏。当心脏可以被一次 HTTP 请求停跳，整个生态就都暴露在刀锋上。
漏洞从不偏心 —— 它挑没写那行 if 的人，挑给服务账号豪华 sudo 的人，挑把”打补丁”当终点的人。
🔐 记住三件事：
- 补丁是起点，不是终点
- NOPASSWD sudo 是潘多拉魔盒
- 检测能用行为差异，就别真的去利用
🔧 行动按钮：
- 🔍 立刻跑检测：CVE-2026-34908-check[3]
- 📥 补丁下载：Ubiquiti 官方 → UniFi Network → Downloads
- 🆘 怀疑被入侵？别只打补丁，先离线快照取证，再做密钥轮换 + 重建评估
#UniFi #Ubiquiti #RCE #CVE-2026-34908 #路径穿越 #命令注入 #IoT安全 #网络设备安全 #补丁管理 #应急响应
END
阅读推荐
【安全圈】执法机构捣毁 ‘AudiA6’ 勒索软件加密货币洗钱服务
【安全圈】超过 400 个 Arch Linux 软件包被攻破，用于推送 rootkit 和信息窃取程序
【安全圈】紧急提醒！WinRAR漏洞仍未绝迹：大量用户已中招 立即检查更新
【安全圈】甲骨文确认 PeopleSoft 漏洞被利用 已影响百余家机构
安全圈
←扫码关注我们
网罗圈内热点 专注网络安全
实时资讯一手掌握！
好看你就分享 有用就点个赞
支持「安全圈」就点个三连吧！
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：安全圈 《【安全圈】严重漏洞：UniFi OS 无需密码即可拿下 Root 权限》