文章总结： 本文披露NetcoreNBR200V2企业路由器traceroute功能存在CVE-2026-94095命令注入漏洞，CVSS9.9分。攻击者可通过ubusJSON-RPC请求注入任意命令，PoC已公开且厂商无回应无补丁。文章详述漏洞成因、利用链、检测方法及缓解建议，强调管理口勿暴露公网、修改默认口令等临时措施，并从红队视角分析该设备诊断功能为高价值攻击面。 综合评分： 92 文章分类： 漏洞分析,红队,应急响应

(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命令注入》