百度云防护 WAF 上线规则 4645：一条规则守住了 PHP2Shell 的哪一环

10 月 22 日上午 11 时 31 分，百度云防护的 WAF 规则库里多了一条编号 4645 的规则，名字叫 Code_exec.CVE-2026-109618.A，风险等级高风险，防护类型代码执行。从命名习惯看，这是给 PHP2Shell（CVE-2026-109618 / CVE-2026-109619）出的第一条针对性规则，编号后缀的 .A 说明后面大概率还会跟 B、C。

这条规则本身没有太多可讲的——一条 WAF 规则上线，用户侧通常无感。但主机吧认为，它的规则描述值得单独拎出来读一遍。因为从这段一两百字的描述里，能看出厂商对这条漏洞链的理解到了哪一层，也能反过来推算：如果你只靠这层防护，还剩多少风险敞口。

一、先看这条规则说了什么

把规则详情拆成字段看：

几个值得注意的细节：

第一，规则名称用的是主编号 109618，而不是两个 CVE 并列。这条链上多数复现和公开分析都从 109618 的 OOM 入口切入，把 109619 当作后续的收割环节，命名顺序与这个理解一致。

第二，时间点值得记一下。PHP 官方补丁在 UTC 10 月 21 日 14:00 发布，折成北京时间是 21 日 22:00。规则更新在 22 日 11:31，中间隔了约 13 个半小时；如果按漏洞编号首次出现在公开论坛的 10 月 20 日 15:00 UTC 算，从编号泄露到有 WAF 规则可挡，跨了将近两天。这两天正是最危险的窗口——细节已公开，补丁还没有，中间只有第三方 WAF 规则能顶。

第三，真正有信息量的是「规则描述」那一段。原文写的是：

检测 PHP2Shell（CVE-2026-109618 / CVE-2026-109619）session upload_progress UAF 利用链的 session 污染阶段：POST 请求同时携带 PHPSESSID 与 PHP_SESSION_UPLOAD_PROGRESS 上传进度字段，攻击者借该字段把 PHP 代码写入 session 文件，再配合 LFI 触发 RCE。

这段话把攻击链拆成了明确的阶段，并且指出了自己只守其中一段。这种写法在 WAF 规则描述里并不常见——多数规则只会写「检测 XX 攻击」四个字。愿意把「守哪一段、不守哪一段」讲清楚，说明写规则的人确实看过这条链的完整形态。

二、它守的是链条的第几环

回顾一下 PHP2Shell 的完整形态。这条链不是单个漏洞，而是五个环节串起来的：

规则 4645 的判据落在第 ④ 环：同一个 POST 请求里，同时出现了 PHPSESSID 和 PHP_SESSION_UPLOAD_PROGRESS 这两个字段名。

为什么是这一环？因为其余四环它拦不了：

• ① 和 ② 拦不住。攻击者靠的是「每个字段都不大、但总量撑爆 memory_limit」。单看任何一个字段、任何一行头部，内容都完全合规，没有注入特征、没有攻击关键词。WAF 按内容匹配，对「合法的垃圾」没有判据。
• ③ 是攻击者自己的准备工作。反复打请求、让会话文件里堆积垃圾数据，为后面的 UAF 布局铺垫。这一步从外部看就是一堆正常请求，识别成本很高。
• ⑤ 发生在应用层。本地文件包含是应用自己的代码缺陷，WAF 看不到服务器内部把 session 文件当 PHP 读了这一动作。

只有第 ④ 环留下了请求层面的指纹：写代码进会话文件这个动作，必须依赖上传进度特性，而该特性要求请求里带一个固定名字的字段。这个字段名是 PHP 内建常量，攻击者改不了；PHPSESSID 也是必须的，否则代码写不进目标会话。

两个条件同时成立，就是这个动作的必要条件。规则卡在这里，命中率最高、误伤最低——正常业务不会在一个请求里同时提交会话 ID 和上传进度字段，除非你正好在做文件上传，而那种场景下 WordPress 这类框架通常走 cookie 传会话、不会把 PHPSESSID 摆到 POST 体里。

三、这条规则能挡住的，和挡不住的

规则描述里有一句话关键：它检测的是「session 污染阶段」。这意味着它只覆盖了 PHP2Shell 的一条利用路径。

目前公开讨论的利用路径至少有三条：

这不是在挑规则的毛病。任何按「指纹」做的虚拟补丁都有这个结构性局限：它能覆盖的，永远是「它认得出的那一种请求形态」。攻击者只要换一条不经过 session 的路径，规则 4645 全程不会响。

更要紧的一层是：即使走的是 session 投毒这条路，规则对请求的解析方式本身也可能被绕。主机吧此前在解读腾讯云 php2shell 通告时引用过 Upwind 的分析，指出 PHP 的 multipart 解析器比多数人以为的宽松——它接受折行头部、接受没有冒号的行（会被粘到上一个头部）、接受缺失 form-data 的 Content-Disposition、也接受闭合引号后面的垃圾字符。这意味着，如果一条规则只匹配「单行里干干净净的 name="PHP_SESSION_UPLOAD_PROGRESS"」，攻击者把这些字段名拆到折行里、或塞进引号后面的冗余位置，PHP 照样能解析出正确的字段，而正则可能匹配不上。

规则 4645 的判据写的是「同时携带这两个字段」，从描述看它比单纯匹配字面量要进一层。但规则内部具体是按什么粒度做归一化的，控制台没有公开，主机吧也没有办法在不实际打规则的前提下验证。这一点必须说清楚：本文能确认的只有规则的存在、编号、判据描述和时间戳，无法确认它对归一化绕过的实际抵抗力。

四、如果你是这层防护的用户，该做什么

按投入产出排序，实际可执行的顺序是这样的：

另外有两件事，很多人在这次事件里做反了：

调低 memory_limit 是反向操作。看到「内存耗尽导致漏洞」，直觉是收紧内存。但 OOM 恰恰是触发条件，限额越低，攻击者用越小的请求就能把它打出来。这是典型的「看起来在加固，实际在帮忙」。

关掉 session.upload_progress 只关掉一半。这个措施能切断规则 4645 所针对的那条路径，也就是 109619 相关的 session 生命周期；但对 109618 的 OOM 入口，它不起作用——那条路上没有任何一步需要上传进度功能参与。这一点主机吧此前已在PHP2Shell 事件梳理中做过更正说明。

五、一条规则上线，本身就是一次情报披露

最后说一层容易被忽略的意义。

WAF 规则是公开可查的。百度云防护的用户打开控制台就能看到规则 4645 的完整描述，包括它检测的是哪个阶段、依赖哪两个字段。对防守方这是好事——你能知道防护边界在哪。对攻击方，这同样是一份免费的说明书：规则描述等于明确告诉你，哪些路径不在检测范围内。

这不是批评。商业 WAF 的规则描述必须让客户看懂，否则客户无法判断防护是否合理。但它提醒了一件事：看到规则上线就认为「问题已解决」，是对虚拟补丁最常见的误读。

规则 4645 的真正价值，是买到了从 10 月 22 日到下一次维护窗口之间的这段时间。窗口期内它可能挡住绝大多数批量扫描和现成脚本——这部分贡献是实打实的，很多站点正是靠这个撑过最初几天的扫描高峰。但它替代不了一行 apt upgrade，也替代不了把应用里的文件包含漏洞修掉。

查到自己的 PHP 版本很简单，重点是看到第三位：

php -r 'echo PHP_VERSION, PHP_EOL;'

输出 8.3.35 说明还没修，8.3.36 才是安全的。面板里显示「PHP 8.3」无法判断——那个数字在很多情况下只到小数位。

六、写在最后

这次规则上线值得肯定的一点是速度：从漏洞编号公开到有针对性的规则可用，约 44 小时；从官方补丁发布到规则更新，13 个小时。在国内云厂商里这个节奏属于快的。

但主机吧更想强调另一半：规则的规则描述写得越精确，越说明它只守了一段。厂商诚实地把覆盖范围写在了产品界面上，剩下的事就该由站点自己完成——升级、修 LFI、检查日志投毒路径。

规则会一直加，.A 后面会有 .B、.C。但攻击路径也会一直加。WAF 和补丁不是二选一，是两条腿，缺一条都走不远。

主机吧 · 本文规则信息引自百度云防护控制台规则详情，漏洞机理部分参考 PHP 官方 advisory、Datadog Security Labs 与 Upwind 公开分析。