文章总结： CVE-2026-101037是FASTFAC1200R路由器devdiscover服务UDP5001端口的栈溢出漏洞，CVSS9.9，无需认证即可利用，PoC已公开且厂商未回应。漏洞源于解析advertisement包时未校验length字段导致栈缓冲区溢出。建议立即封禁UDP5001端口、限制管理面访问并更换设备。 综合评分： 90 文章分类： 漏洞分析,应急响应,红队,渗透测试
(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 状态来设防，网络层封口比等补丁现实得多。
08 POC 链接
GitHub 仓库（含完整漏洞分析、运行时证据截图、PoC 脚本）：
https://github.com/xiaobor123/vuls-find-VxWorks/tree/main/vul-find-FAST_FAC1200R-copy_msg_element/vul-find-FAST_FAC1200R-copy_msg_element
漏洞详情页：
https://nvd.nist.gov/vuln/detail/CVE-2026-101037
如果文章对您有收获，欢迎关注、点赞、推荐、转发。
— END —
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：红队安全圈 红队安全圈 红队安全圈《(9.9分) CVE-2026-101037：FAST路由器栈溢出PoC公开》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论