文章总结： NetcoreNBR200V2企业路由器traceroute功能存在OS命令注入漏洞CVE-2026-94095，CVSS评分9.9。攻击者可通过ubusJSON-RPC请求注入任意命令，PoC已公开且厂商无回应无补丁。同批次另有94096/94097同源问题。建议管理口不暴露公网、修改默认口令、限制管理端点访问，并关注厂商后续固件更新。
综合评分： 85
文章分类： 漏洞分析,红队,应急响应
(9.9分) CVE-2026-94095：Netcore企业路由器traceroute命令注入
红队安全圈
红队安全圈
红队安全圈
2026年9月21日 08:46
重庆
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
Netcore NBR200V2 的 traceroute 功能把用户输入直接拼进 shell，一条 JSON-RPC 请求就是任意命令执行。PoC 已公开，厂商零回应，没补丁。这篇讲透利用链、检测和缓解。
01 引言
Netcore NBR200V2 企业路由器的 traceroute 诊断功能存在远程命令注入，CVE-2026-94095，CVSS 3.1 达 9.9。诊断接口直接把用户可控的 url 参数拼进 shell 命令执行，远程攻击者一条 JSON-RPC 请求就能执行任意命令、重启设备或完全接管系统。利用代码已随漏洞披露公开，而厂商在披露者提前联系后没有任何回应——至今没有补丁。
02 漏洞速览
漏洞编号CVE-2026-94095（同批 94096/94097）
影响产品Netcore NBR200V2 V1.3.241127.071246
漏洞类型OS 命令注入（CWE-74）
危害等级CVSS 9.9 Critical
是否在野未观测到在野利用，利用代码已公开
公开 PoC有，含完整利用链与请求样例
攻击前提可达 ubus 接口 + 一个低权限会话
03 漏洞成因
这条链路一共三步，每一步都在给命令注入放行。
第一层，远程请求以 ubus JSON-RPC 的形式进到设备，诊断功能的处理方法把请求路由到 tools_traceroute()。
第二层，tools_traceroute() 拿攻击者完全可控的 url 参数拼接 shell 命令字符串——参数到命令之间没有任何过滤、转义或白名单校验。
第三层，拼接结果交给 system() 执行：system() 会完整解析 shell 语法，分号、&&、管道、注释符统统有效。
三层叠完，一个原本只该做 traceroute 的诊断功能，变成了通用命令执行原语。披露文档给的预期效果是设备在处理 traceroute 任务时直接执行 reboot，把 reboot 换成任意 shell 命令就是完整接管。
同批次披露的问题结构完全相同：CVE-2026-94096 走 LAN IP 配置路径，CVE-2026-94097 走 CGI 诊断端点（CVSS 10.0），全部指向同一个 /usr/bin/network_tools——这个二进制里的诊断类功能基本都是同一个写法，修一个不叫修。
04 影响范围
确认受影响的是 NBR200V2 固件 V1.3.241127.071246。NBR 系列是企业级出口路由器，常见于小微企业和门店组网，管理口经常直接挂在内网甚至映射到公网。
坏消息有两层：一是披露者提前联系了厂商，厂商没有任何回应，目前没有官方补丁；二是同文件的 94096/94097 结构相同，即使某处做了过滤，换一个入口照样打。这类设备的安全生命周期基本取决于厂商态度，眼下态度已经很清楚了。
05 利用分析
利用代码已随披露公开，请求形态是向 ubus JSON-RPC 端点提交诊断任务，把 url 参数换成注入载荷：
// JSON-RPC 请求中注入位置
{
“method”: “traceroute”,
“params”: {
“url”: “8.8.8.8;
reboot”
}
}
url 参数先填一个合法目标（如 8.8.8.8）再接分号和任意命令，system() 会依次执行。验证时用 reboot 一眼可见——设备直接重启。实际利用中可替换为反弹 shell、添加后门账号或关闭防火墙规则。
前提是先拿到低权限会话：ubus 接口要求认证，攻击者可用弱口令、默认口令或历史凭据泄露进入。这让它更像是弱口令加命令注入的组合拳，但对企业环境两者都太常见了。
06 检测与排查
自查三步：确认设备型号和固件版本是否在受影响列表；检查管理口是否暴露在不可信网段（重点排查端口映射和 DMZ 配置）；审计设备日志里的异常诊断任务调用和不明会话。
临时检测命令注入是否可达，可以在管理界面手动发起一次 traceroute，目标填 127.0.0.1; echo test，设备行为异常即说明过滤缺失。
07 修复建议
截至发文没有官方补丁。临时缓解按优先级排：
1. 管理口绝不对公网暴露，关掉所有 WAN 侧管理映射
2. 修改默认口令，强口令加定期轮换（ubus 认证是这道洞的前置门槛）
3. 用防火墙把 ubus/管理端点限制到指定运维网段
4. 关注厂商后续固件，同批次的 94096/94097 一起验证修复
在厂商回应之前，这台设备应该被当作远程命令执行已公开的状态来管理——缓解措施做完也只能降低风险，不能消除。
08 红队视角
这是教科书级的 system() 拼接注入，但它真正值得看的是披露生态：研究者一口气交了三个同源问题，厂商零回应，PoC 全公开。对红队来说，Netcore/磊科这类国产企业设备的诊断功能族是稳定的高价值切入点——历史披露里 ping、traceroute、网络诊断模块反复出现同构问题，遇到 NBR 系列可以直接按这个模式测。
防守方要认清一点：没补丁的在野漏洞不是低优先级，是只能靠缓解。设备选型时厂商的漏洞响应记录应该纳入采购评估——一个不回应披露的厂商，等于让客户长期持有带公开 PoC 的未修补洞。
09 POC 链接
https://app.notion.com/p/Netcore-NBR200V2-Vul-3-39f797159f15802296c7f6e110363435
https://nvd.nist.gov/vuln/detail/CVE-2026-94095
说明：研究者披露文档（完整利用链）与 NVD 收录页。
如果文章对您有收获，欢迎关注、点赞、推荐、转发。
— END —
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：红队安全圈 红队安全圈
红队安全圈《(9.9分) CVE-2026-94095：Netcore企业路由器traceroute命令注入》