2026 年 10 月 21 日，PHP 官方发布 8.5.12、8.4.27、8.3.36、8.2.35 四个紧急安全版本，修复两个被合称为 PHP2Shell 的高危漏洞，编号 CVE-2026-109618 与 CVE-2026-109619，CVSS v4.0 评分均为 9.2。

这两个漏洞的特殊之处在于，问题不在任何应用、插件或框架里，而在 PHP 解释器的请求生命周期管理环节。这意味着代码写得再规范、CMS 更新到最新版，都无法构成防护。受影响范围覆盖 PHP 5.4.0 以来的几乎所有版本，且默认配置下即存在风险；业界估计约 70% 的网站依赖 PHP 运行。

本文梳理事件脉络与攻击原理，说明为什么常规的版本检查方式会给出误导性结论，并按部署形态给出自查与修复路径。

一、事件经过

发现与协调：2026 年 8 月，安全公司 Calif 借助 OpenAI 的 GPT-5.6 Sol 模型发现其中一个缺陷，谷歌旗下 Wiz 独立发现并报告另一个。此后约两个月，PHP 维护团队、安全厂商、云服务商与多国网络安全机构在保密状态下协同完成验证、修复开发与发布准备。

细节外泄：10 月 20 日，一组利用信息提前在网上出现，相关帖子随后被删除，但截图已在社交平台扩散。

补丁发布：10 月 21 日，PHP 发布四个修复版本。修复覆盖 8.2、8.3、8.4、8.5 四个分支。

利用态势：据 Cloudflare CEO Matthew Prince 披露的数据，漏洞公开后攻击尝试在 45 分钟内从数千次增至数万次，两小时内增至数十万次，累计达到数百万次。该数字反映扫描与利用的规模，不代表已有多站点被成功入侵。

机构反应：德国联邦政府 IT 服务商关闭部分网站，法国暂停地方政府站点，荷兰有政府服务网站、医院与鹿特丹港受影响，芬兰、比利时、捷克关闭部分站点加紧修补，维基媒体基金会临时暂停部分系统。泰国国家网络安全局发布国家级威胁警报。上述下线多为预防性措施，不等同于已被入侵。

当前状态：截至公开报道，两个漏洞尚未被列入 CISA 已知被利用漏洞目录，也未有确证的大规模入侵案例。但攻击尝试已达数百万次量级，风险窗口仍然存在。

二、攻击原理：为什么解析记录、账号、代码都正常也挡不住

2.1 请求生命周期里的两种内存

PHP 的常见运行方式，包括 mod_php、PHP-FPM、php-cgi、FrankenPHP、LiteSpeed 等，采用“工作进程连续处理多请求”模型：进程长期驻留，每个请求分配内存并在结束时释放。

由此存在两种生命周期：请求级内存仅属于当前请求，进程级全局字段会保留至下一个请求。正常流程下，PHP 会在释放请求内存前清理指向它的全局引用。两个漏洞都发生在这个清理环节。

2.2 CVE-2026-109619：跨请求 use-after-free

PHP 的请求启动有明确的顺序：php_hash_environment() 解析请求体，上传进度回调可能在此阶段运行，而各扩展的常规初始化，也就是 RINIT，要等 zend_activate_modules() 才执行。

也就是说，处理 multipart 上传进度时，Session 扩展的常规初始化尚未完成。若此时已保存指向请求内存的指针，随后又遇到 OOM、致命错误或超时，清理流程可能中断，指针被留在进程内。同一 worker 处理下一个请求时再次提前进入上传进度逻辑，读取的正是已失效的指针，形成跨请求的 use-after-free。攻击者控制被复用的内存内容后，可实现信息泄露与远程代码执行。

PHP 8.5 存在另一条不依赖 Session 的路径：fatal_error_backtraces 会残留旧状态，若下次请求初始化前产生 INI 诊断，mod_php 部署即可触发 RCE。

2.3 CVE-2026-109618：OOM 中断初始化后的清理

PHP 遇到内存耗尽时通过 longjmp 跳出执行位置。若此时某个内部结构已登记到请求状态、初始化却未完成，跳转会留下无效状态；随后的请求清理流程读取该数据，造成内存破坏并最终执行攻击者命令。

触发依赖构造特定的 multipart 请求：不携带可用 Content-Length 以绕过 post_max_size 前置检查、单个部件携带大量头部、以空文件控件配合嵌套字段名反复生成文件元数据。其核心在于 HTTP 请求体大小与 PHP 解析后的内存占用并不相等。

2.4 一个关键判断

两个漏洞均在业务脚本运行之前触发。这解释了为什么应用层加固无效，也解释了为什么 mod_php 部署应当优先处理，它在请求启动失败后仍执行关闭流程，问题可在业务脚本运行前出现。

三、风险自查：版本号为什么会给出误导性结论

php -v 显示的是命令行二进制的版本，也就是 CLI 版本，而处理网站请求的往往是另一个二进制、读取另一份 php.ini。多项目共存的服务器上，两者版本不一致属于常态。

以下四种情况会导致版本判断失真：

CLI 与 Web SAPI 分离：需确认实际服务请求的运行时，可通过 php-fpm -v、站点级版本诊断入口，查后记得删除，或响应头中的 X-Powered-By 核对，前提是它未被关闭。

发行版回移补丁：Debian、Ubuntu、RHEL 常将安全修复回移至旧上游版本号，外观上“存在风险”的版本可能已修复。判断依据应为软件包 changelog 中是否包含对应 CVE 编号，而非上游版本号本身。

捆绑运行时：Docker 基础镜像、控制面板自带的 PHP、一体机与厂商设备内置的 PHP，均不出现在主机操作系统的软件包清单中，需逐个镜像与面板核查。

陈旧进程：补丁安装完成但 PHP-FPM 未重启时，旧 worker 仍运行旧代码。未重启 worker，补丁不生效。

修复版本线为 8.5.12、8.4.27、8.3.36、8.2.35。PHP 8.1 及更早分支，官方未发布正式修复版本，仅提供 7.4、8.0、8.1 的最小源码回移，需具备编译与测试能力；发行版与 LTS 厂商可能另行提供软件包。PHP 7.3 及更早，包括 PHP 5，无任何修复。

共享主机用户的自查方式：虚拟主机环境下用户通常无法直接变更 PHP 运行时。以时代互联 now.cn 云主机为例，面板默认安装 PHP 8.0，可在「更改设置」中自助切换至 5.6 或 7.0，更早的 5.2 和 5.3 需提交服务单配置。这些分支均处于「官方无正式修复版本」范围，因此共享主机用户应就以下两项向服务商确认：

1. 服务端 PHP 是否已更新至含补丁的版本，或已应用厂商回移补丁；
2. PHP worker 是否已重启完成。

四、修复路径：按部署形态分别处理

总体原则一致：更新承载 Web 请求的那个 PHP 运行时，随后重启其 worker 进程。

Apache 搭配 mod_php：优先级最高。先确认 Apache 加载的 libphp 模块来自哪个软件包，按安装来源更新，安装后重启 Apache，使旧父进程与子进程退出。同时审查 .htaccess、虚拟主机及目录级的 php_value、php_flag、php_admin_value 配置，无效或过时的设置若在请求初始化前产生诊断信息，可能成为 109619 的提前读取点。

Nginx 或 Apache 反代 PHP-FPM：从站点配置的 fastcgi_pass 或 proxy_fcgi 定位对应 FPM pool、服务名与版本。同机多个 pool 可能属于不同版本，需逐一处理。重启承载流量的 FPM 服务后确认旧 worker 已退出。需注意，重启 Nginx、更新 CLI 包或替换磁盘文件，均不会替换仍在运行的 FPM worker。

php-cgi、FrankenPHP、LiteSpeed：先确认站点所用 SAPI，再按独立安装、Web 服务器打包、平台供应商维护三条路径分别处理，升级后重启对应服务与 worker。FrankenPHP 的请求启动与关闭方式与 mod_php 有相似之处；LiteSpeed 需结合具体实现与应用代码核查。

Windows IIS 搭配 PHP FastCGI：在 IIS 管理器的处理程序映射中确认 .php 指向的 php-cgi.exe 实际路径，核对应用池与配置文件。Windows 上并存多个 PHP 目录较为常见，更新错目录不会影响站点。替换后回收该应用池。

Docker 与 Kubernetes：定位 Dockerfile 中的 PHP 基础镜像及多阶段构建中实际进入最终镜像的运行时。拉取含修复的基础镜像重新构建业务镜像，记录镜像摘要，不依赖浮动标签。部署后令旧容器全部退出，检查镜像仓库与自动构建流水线，防止后续发布回滚至旧镜像。

PHP 8.1 及更早：优先规划迁移至受支持且已修复的分支，先在预生产环境完成回归再切换流量。迁移期间可核查发行版或 LTS 供应商是否已提供覆盖这两个 CVE 的回移补丁，核验包来源、公告编号与生效版本后再安装。

五、临时缓解措施的适用边界

官方公告列出的措施可降低特定路径的风险，但不构成完整修复。

针对 CVE-2026-109618：将 memory_limit 设为 -1 以防止应用自行覆盖；收紧 post_max_size；在 Web 服务器或代理层实施请求体大小限制。官方同时提示，不可使用 RLIMIT_AS 或 RLIMIT_DATA 替代，二者可能触发同一条出错路径。

针对 CVE-2026-109619：关闭 session.upload_progress.enabled 并重启所有 worker；PHP 8.5 上另需设置 fatal_error_backtraces=0。

关于“关闭上传进度”这一做法的评价存在分歧：该建议最早来自一位研究者在外泄后的分析，后续有研究者按其 PoC 复现失败，亦有审计认为所述漏洞与已发布 PHP 不符；watchTowr 认为修改 INI 对阻止利用无效；PHP 核心开发者 Gina Peter Banyard 表示，打补丁或升级是唯一的缓解方式。由于关闭进度跟踪不影响上传功能、成本接近于零，可作为补丁上线前的一层防御，但不应视为修复手段。

明确不适用的做法：

disable_functions。漏洞在业务脚本运行前触发，不经过函数调用层；且该配置项为 PHP_INI_SYSTEM 级别，使用 php_value 或 ini_set() 设置会静默失效，须使用 php_admin_value。

PHP 层 WAF 或安全插件。与漏洞运行于同一进程，进程失陷后防护随之失效。有效性依赖网络层 WAF 规则或 CDN 在请求到达 PHP 之前完成拦截。

仅收紧 memory_limit。对 109618 的特定路径有效，对 109619 无效。

更新 CMS 或框架。应用更新不改变 PHP 运行时版本。

六、入侵迹象与处置顺序

常见迹象：PHP worker 派生出 shell、curl、wget 或探测类子进程，可用 ps -eo pid,ppid,user,cmd --forest 查看进程树；PHP worker 出现异常出站连接；Web 根目录存在晚于上次部署产物的文件，可用 find /srv/app -type f -newer /srv/app/composer.lock 快速缩小范围；异常增大的 PHPSESSID Cookie；伴随内存错误的大量 multipart 请求；反复出现的 HTTP 500；worker 意外重启。

处置顺序，顺序不可颠倒：

1. 隔离：临时下线站点或限制访问，阻断异常流量；
2. 取证：将访问日志、FPM 日志、PHP 错误日志与 ps auxf 输出转储至主机之外。重启会清除所需进程树，取证须在此前完成；
3. 排查：查杀 webshell，核查账号、计划任务、密钥与进程；
4. 修复：优先修补 PHP 漏洞，再清理后门。未修复漏洞即清理后门，仍可能再次被入侵；
5. 轮换：将应用可触达的密钥全部更新，包括 .env、数据库凭据、API Key 与会话签名密钥，按“已被读取”处置。

七、常见认知误区

“站点规模小，不会成为目标”：本次为大规模自动化扫描，依据版本特征而非流量规模选择目标。

“已接入 CDN 即安全”：CDN 处理流量与部分攻击特征，不改变源站 PHP 版本。若未在 CDN 或 WAF 层有效拦截恶意请求体，源站仍处于暴露状态。

“升级 PHP 后即可结束”：仍需确认重启后实际服务请求的版本已变更，并按第六节排查入侵迹象。从补丁发布到大规模利用开始，间隔仅为数小时。

“等待服务商通知”：托管与共享主机场景下服务商确为责任主体，但“已更新”与“worker 已重启”是两个独立的确认项，建议主动核实一次。

相关服务

云虚拟主机（https://www.now.cn/vhost/）：自带管理面板，支持 PHP 版本切换，提供免费备案与网站迁入服务

轻量云服务器（https://www.now.cn/fcloud/lightcloud.php）：适合需要自主控制 PHP 运行时与运行环境的场景

SSL 证书（https://www.now.cn/ssl/）：全站 HTTPS 加密，配合安全加固降低整体风险面

域名注册（https://www.now.cn/domain/）：域名实名认证、自由锁定与过户