蒲公英X5 Pro路由器路径穿越root RCE深度分析（CVE-2026-120225）（附PoC）

原创

赤霄攻防实验室
赤霄攻防实验室

赤霄攻防实验室

2026年11月2日 17:13
河北

去阅读

昨晚，一条针对国产组网路由器「蒲公英 X5 Pro」的漏洞披露悄悄上线 CVE：攻击者只要拿到管理密码，发起一次看似「失败」的配置恢复请求，就能把代码写进路由器的系统文件，再补一个普通的信息查询请求，直接以 root 身份执行任意命令。整个过程两个请求，全程有 PoC 佐证，而厂商至今零回应。

这款路由器在国内中小企业和连锁门店的异地组网场景里装机量极大——正是「远程管理」这个卖点，让它一旦沦陷，背后连着的整张内网都跟着暴露。本篇按老规矩做源码级拆解：黑名单漏了什么、文件怎么落地的、root 是怎么执行起来的，以及没有补丁的情况下你该立刻做什么。

▲ CVE-2026-120225 · 蒲公英 X5 Pro 配置恢复路径穿越 root RCE

TL;DR 四行速览

是什么：蒲公英 X5 Pro 路由器（固件 ≤ 7.6.1）Web 管理接口 config\_restore\_ex 的 filename 参数存在相对路径穿越（CWE-23），CVSS v4.0 打到 9.4 严重级，可升级为 root 任意代码执行。

影响谁：所有固件 7.6.1 及以下的 X5 Pro；攻击者需要先拿到管理密码——但同批披露的授权绕过漏洞（CVE-2026-120224，9.9 分）意味着密码这道墙本身也在漏水。

怎么修：厂商暂无回应、无官方补丁。当下只能缓解：改强密码、把管理面从公网收回去、盯固件推送。

看点：「接口报错 ≠ 攻击失败」——恢复请求返回 116 无效备份，文件其实已经写进去了。这个错误处理的次序问题，是整条利用链最值得记住的一课。

▲ 漏洞概要信息卡

一、攻击链全景：四次交互拿下 root

先看全貌。披露者 FirmAgent 在 X5 Pro 7.6.1 真机上完整走通了这条链，每一步都有响应记录：

▲ 完整攻击链四步

几个关键细节值得展开。第一步的认证并不复杂：路由器的 /cgi-bin/oraybox 接口用 \_pwd 参数过一道 oray 账号密码校验，拿到管理密码即可通过，没有二次验证、没有 CSRF 挑战。第二步是全链的核心——路由器收到恢复请求后，会把 filename 参数拼在 /tmp/ 后面，直接交给 wget 下载。问题就出在这个拼接：filename 传 ../etc/openwrt\_release，落地路径就成了 /tmp/../etc/openwrt\_release，也就是系统目录下的 /etc/openwrt\_release。

第三步是最反直觉的地方。下载完成后，固件会调用 oray\_cipher 工具校验这到底是不是一份合法的加密备份——当然不是，校验失败，接口返回 code 116「无效备份文件」。任何正常的开发者预期都会是「校验失败就什么都不该发生」，但反编译源码显示，错误返回的位置在清理逻辑之前：return 先执行了，删除残留文件的代码永远走不到。于是攻击者的文件就这样「合法地」留在了系统目录里。

第四步只是补一刀。/etc/openwrt\_release 本来是 OpenWrt 系统的版本信息文件，内容是一堆 Lua 赋值语句；而管理接口里的 sys\_base\_info（一个再普通不过的「查看系统信息」功能）在实现里会 dofile 加载这个文件再读版本号。攻击者把 Lua 代码混在版本赋值里写进去，下一次任何人点开系统信息页，代码就在 uhttpd 的 root 进程里执行了。披露者的验证输出是干净的四个字：uid=0(root)。

二、根因三连：黑名单、拼接、次序

把 7.6.1 固件的 Lua 模块反编译出来看，这个洞其实是三个「各自不算致命」的缺陷叠出来的：

▲ 根因三连：反编译源码中的三个缺陷点

第一个是过滤策略选错了。config\_restore\_ex 对 filename 做的是黑名单过滤，拦反引号、双引号、方括号、管道符、分号这些 shell 危险字符——动机可以理解，毕竟后面要拼命令。但黑名单的天生缺陷就是漏：这份清单里没有点号和斜杠，而路径穿越恰恰只需要这两个字符。做输入校验时，「允许什么」永远比「禁止什么」可靠，一份 enumerate 不全的黑名单等于给攻击者留了正门。

第二个是信任域错位。filename 被无条件拼接在 /tmp/ 后面，隐含的假设是「用户给的文件名只会落在临时目录里」。这个假设没有任何代码层面的强制——没有 chroot、没有路径规范化检查、没有白名单目录校验，只是字符串相加。一旦内容可控、路径可控，写入目标就完全可控。

第三个是错误处理次序。「校验失败就返回」本身没错，错的是清理动作被排在了返回之后。这类「fail path 不做善后」的写法在嵌入式固件里非常常见，因为正常测试永远测的是成功路径，失败路径的资源回收全靠开发者自觉。攻击者看到的却是：报错的接口，完成了写入。

三、不只是这一个洞：X5 Pro 漏洞家族

更值得警惕的是，CVE-2026-120225 不是孤例。同一个研究方在最近一周内对 X5 Pro 7.6.1 固件连续披露了十条以上漏洞，几乎条条高危：

▲ X5 Pro 漏洞家族全景（FirmAgent 一周内披露）

这批漏洞有两个共同特征。其一，打点全是路由器的系统级组件：Ser2net 串口服务、SNMP、Dnsmasq DNS 服务、IPsec/L2TP VPN 配置、PPPoE 上行配置——都是长期驻留在系统里、权限不低的进程，CRLF 注入系列（多条 9.9 分）意味着攻击面从 Web 管理界面一路铺到了网络协议栈层面。其二，据 VulDB 记录，所有披露厂商均被提前联系，但「did not respond in any way」——一条公开回复都没有。

对防御者来说，这组信号合起来看：这不是某个函数写错的偶然问题，而是整条固件开发流程缺乏安全审计的系统性暴露。等待单点补丁的意义不大，把设备的管理面从不可信网络里收回去，才是当下更现实的动作。

四、谁在风险里：威胁模型怎么读

必须说清楚前提：这条利用链需要管理密码，不是零点击打公网。那真实风险有多大？三个角度：

第一，密码的获取渠道比想象中多。弱密码和默认密码是一类；更现实的场景是设备的管理入口暴露在公网——大量门店场景的蒲公英就是为了「远程可管」才买的，扫描器拿到一个管理界面后慢慢爆破，是每天都在发生的事。第二，别忘了同批的 CVE-2026-120224 授权绕过（9.9 分）：如果普通用户权限可以借 run\_async\_task 通道调用管理员接口，那「需要管理密码」这个前提本身就会被绕掉，两个洞拼起来就是完整的预认证 RCE 链。第三，root 权限的路由器等于整张网络的守门人：流量镜像、DNS 劫持、内网横向、固件级持久化，攻防的想象空间都在这里。

另外有个容易被忽略的细节：URL 下载模式下，路由器会主动向攻击者指定的服务器发起 HTTP 请求。也就是说攻击者不需要能直接访问路由器——只要能诱导一次恢复请求（或者等待管理员自己操作），路由器就会自己走出来取「备份」。这在云管理架构下尤其值得琢磨。

五、没有补丁，先做四件事

截至本文写作，官方没有发布修复公告，VulDB 也标注无已知缓解措施。参考处置顺序：

▲ 自保清单（按优先级）

展开说两句。改密码这一条要改到位：长度优先、不复用、不在云平台和本地管理用同一套——本篇攻击链的第一道门就是 \_pwd 校验，而同批还有会话随机性缺陷（CVE-2026-120223）在削弱会话本身。收敛管理面的意思是：确认 Web 管理界面只从内网或官方云平台可达，公网 IP + 端口直连管理界面的部署方式在当前状态下应当视为高危暴露。固件检查建议每周看一次，路径是系统设置 → 系统升级。日志侧重点盯两类：异常的 config\_restore 调用记录，以及路由器向陌生地址的主动外联。

如果设备部署在连锁门店等无人值守场景，考虑在出口防火墙上给路由器管理端口加白名单；有条件的团队可以在上游设备抓一下 /cgi-bin/oraybox 的调用频率做基线，恢复类接口被调用本身就应该是低频事件。

附：验证工具

本篇同步开源了配套的验证脚本（完整验证版，非指纹判定）：脚本走指纹识别 → 版本影响矩阵 → 写入通道探测三段式，写入目标仅为 Web 根目录下的无害哨兵文件，读回即判、验后自动清理，输出 VULNERABLE / PATCHED / UNKNOWN 三态结论，供授权管理员自检自有设备使用：

https://github.com/Rubby2001/CVE-POCS/tree/main/CVE-2026-120225

参考

· CVE 记录（cve.org）：https://www.cve.org/CVERecord?id=CVE-2026-120225

· FirmAgent 完整披露（含源码级细节与验证记录）：https://app.notion.com/p/Oray-Pgyer-X5-Pro-Router-7-6-1-Configuration-Restore-Filename-Traversal-Leads-to-Root-Code-Execution-3eb797159f158017a2cbe1732b7ffa6c

· VulDB 条目：https://vuldb.com/vuln/429584

· 本号验证脚本：https://github.com/Rubby2001/CVE-POCS/tree/main/CVE-2026-120225