PHP「PHP2Shell」双 RCE：AI 参与发现、披露被迫提前，88 万主机悬在门外
10 月 21 日 14:00 UTC，PHP 项目紧急发布安全更新，修复核心请求处理中的两个未认证远程代码执行漏洞：CVE-2026-109618 与 CVE-2026-109619（各评 CVSS 9.2），安全研究者冠以「PHP2Shell」之名。官方措辞罕见地严厉：「没有完整的缓解措施，更新是唯一安全的选择。」影响 8.2.35、8.3.36、8.4.27、8.5.12 之前的所有版本。
漏洞是什么
两个都是 PHP 内存管理层面的问题：前者是内存耗尽时 longjmp() 弃置请求、留下无效内存状态被后续清理流程当作有效数据；后者是 worker 进程保留的全局状态指向已释放的请求内存（session.upload_progress 是触发路径之一）。最初传言的「multipart 解析器 use-after-free、一个 POST 就够」并不准确——官方向量显示攻击复杂度高（AC:H），但利用工具已在研究者手中验证可行。
值得警惕的是 Wiz Research 同时披露了一个独立的远程内存读取原语（Heartbleed 式的 worker 内存泄漏）——即便暂不能 RCE，信息泄露本身已可资敌。
这一次，AI 在发现者一列
此前我们报道过 AI 参与漏洞的负面清单（供应链投毒、agent 失控），这次换个位置：三个独立团队全部借助 AI 模型完成发现。Ryan Austin 与 OpenAI 在 8 月 11 日报告了同一根因；Wiz Research 8 月 24 日补充了更多攻击向量。方法论值得细看：AI 帮助研究者把 PHP memory_limit 导致 RCE 的历史模式（可追溯到 2004 年 Stefan Esser 的经典研究）泛化成可复用的检测规则——不是「一句 prompt 找到所有 bug」，而是「AI 加速的专家假设验证」。PHP 基金会也承认，最早的迹象可追溯到 2024 年 Quarkslab 的审计，迟迟未闭环是一次「结构性失败」。
信号：AI 正在同时放大攻防两侧的速度。安全团队用 AI 找洞，意味着漏洞从发现到武器化的周期被压缩；协调披露流程（这次原定 10/22，因细节提前泄露被迫提前 24 小时）承受的压力只会越来越大。
企业行动清单
- 1全量更新到 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12（或发行版回传包，如 Debian 12 的 8.2.35-1~deb12u1），重启 PHP-FPM/Apache 与所有常驻 worker；按 SAPI 逐一验证版本，别只看
php -v； - 27.4/8.0/8.1 仅有源码回传；5.x 与 7.0–7.3 没有任何修复——Shodan 调查估算约 88.4 万台互联网主机拿不到修复，迁移或网络隔离（VPN/白名单）是仅剩选项；
- 3实在无法立即更新的：管理面关闭
session.upload_progress（针对 109619）、memory_limit=-1、收紧post_max_size、对无需上传的路由拒绝 multipart POST——记住原话「ini 设置救不了你」，这些只是买时间； - 4监测特征：web worker 异常派生 shell/解释器、FPM 段错误与 multipart POST 时间相关、HTTP 500 突发、畸形 PHPSESSID cookie。已有蜜罐（watchTowr）与 Cloudflare 观测到在野攻击尝试——补丁后记得回溯排查是否已被利用、轮换密钥。
深层启示
PHP 8.2 将于 2026 年 12 月 31 日 EOL——这次事件等于给所有还停在旧版本的生产系统做了最后通牒预演。更普适的教训是：AI 参与漏洞发现已成事实，攻击者的武器化周期在缩短，企业补丁窗口必须相应缩短——「等一周看看稳定版」的旧节奏，在 PHP2Shell 这样的漏洞面前已经不够用了。贵司若有 PHP 遗留系统（含老旧 FileMaker 网站发布层），ProMen 建议借此事件做一次全量盘点，欢迎交流升级与加固方案。