2026 年 10 月 21 日，PHP 官方紧急修复了代号 php2shell 的两个严重漏洞（CVE-2026-109618、CVE-2026-109619），评分 CVSS v4.0 9.2 分，攻击者无需登录即可在服务器上远程执行任意代码，且安全厂商蜜罐已捕获真实在野利用。只要你托管网站的服务器在跑 PHP，就应该在 24 小时内完成版本核对与升级。本文基于官方公告（核验日期 2026-10-22）整理影响范围判断方法、四个分支的修复版本、老版本处理方案，以及暂时无法升级时的部分缓解措施。日常的服务器防护体系可先参考 Linux VPS 安全加固完整指南打基础。

事件回顾：php2shell 是什么

php2shell 并非单一漏洞，而是同时披露的两个 PHP 核心缺陷的组合代号，名称来源于漏洞信息泄露截图中出现的一款同名利用工具。漏洞由安全研究团队 Calif.io 首先发现，PHP 官方在 10 月 20 日发布预告后，于 10 月 21 日同步发布安全公告与全部修复版本；安全公司 watchTowr 的蜜罐网络同日即捕获到在野利用，美国网络安全机构 CISA 也发布了修补警报。

漏洞编号 触发条件 危害
CVE-2026-109618 PHP 处理内存耗尽（OOM）时，请求内部数据只初始化了一半就被中断，清理逻辑却将其当作有效数据处理 未认证远程代码执行
CVE-2026-109619 请求独有的内部状态在内存释放后残留，同一 worker 进程处理的下一个请求在正常初始化前使用了这些残留数据 未认证远程代码执行

两者的共同点是：触发路径都在 PHP 请求处理的最早期，早于任何业务代码运行。以风险最高的 mod_php 运行方式为例，一条未认证的 HTTP 请求就足以完成攻击，网站程序自身是否安全并不影响漏洞成立。

PHP 官方安全公告页面，标题为 Security advisory: Critical remote code execution vulnerabilities, update now

影响范围判断：你的服务器是否中招

先按下面的决策表核对自己的环境，再决定处理路径：

你的环境 是否受影响 建议动作
PHP 8.5 / 8.4 / 8.3 / 8.2 任意小版本 是 升级到对应修复版（见下文第 2 步）
PHP 7.4 / 8.0 / 8.1 是 应用官方回移植补丁或发行版安全更新（第 3 步）
PHP 5.x（已停止维护多年） 是，且无官方补丁 尽快迁移到受支持分支，这是唯一出路
仅运行 CLI 脚本、不对外提供 HTTP 服务 风险极低 保持常规更新节奏即可
面板环境（1Panel / 宝塔等） 是 在面板内将站点切换到已修复的 PHP 版本

受影响的运行方式覆盖 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 与 LiteSpeed，其中 mod_php 已被官方确认存在未认证请求直接触发的利用路径，风险最高。需要强调的是，漏洞出在 PHP 本身而非任何建站程序：WordPress、Laravel、ThinkPHP、Typecho 等应用只要运行在受影响版本的 PHP 上就一并暴露，与插件、主题是否更新无关。

修复步骤：升级到官方修复版

适用环境：自建或托管的 Linux 服务器，通过包管理器、面板或源码编译运行 PHP；前置条件：拥有服务器 root 或面板管理员权限，升级前完成一次站点与数据库备份（1Panel 用户可参考 1Panel 远程备份与容灾恢复指南配置异地备份）。

第 1 步：确认当前 PHP 版本

命令行执行 php -v 查看版本号；面板用户在「网站 → PHP 运行环境」或「软件商店 → PHP → 设置」中查看。多个站点可能绑定不同 PHP 版本，需要逐一核对。

第 2 步：升级到对应分支的修复版

官方已于 10 月 21 日发布四个分支的修复版本，把小版本升到位即可：

当前分支 修复版本
PHP 8.5 8.5.12
PHP 8.4 8.4.27
PHP 8.3 8.3.36
PHP 8.2 8.2.35

Debian、Ubuntu、RHEL 等发行版的仓库已提前合入补丁，直接执行 apt update && apt upgrade 或 dnf update php 即可；源码编译用户从 PHP 官方下载页获取新版本重新编译；1Panel、宝塔用户在面板的 PHP 版本管理中在线更新到上述版本，然后逐站点切换。

第 3 步：老版本 7.4 / 8.0 / 8.1 的处理

这三个分支已停止常规维护，官方安全团队专门提供了最小化源码回移植补丁，GitHub 上有对应分支（如 PHP-7.4-CVE-2026-109618-109619），自行编译更新。若你使用发行版打包的 PHP 7.4/8.0/8.1，发行版厂商已提前拿到补丁，走系统安全更新即可。这仍是权宜之计，官方给出的时间表是 PHP 8.2 将于 2026 年 12 月 31 日停止安全维护，规划一次大版本升级才能真正解决问题。

第 4 步：重启服务并验证

升级完成后重启 php-fpm 服务或 Apache（systemctl restart php8.3-fpm 这类命令，面板用户点重启），然后做三项验证：php -v 确认版本号已到位；phpinfo() 页面确认 Web 运行时使用的也是新版本（CLI 版本正确不代表 Web 端已切换）；前台打开网站确认页面正常渲染、后台可登录、能正常发布内容。

回退方案：升级前记录原版本号并保留原安装包或旧版容器镜像；若新版本与业务代码不兼容导致站点异常，面板用户可直接把站点切回旧 PHP 版本，包管理器用户可用 apt install php8.3=8.3.x 一类命令锁定回原小版本。切换只影响运行时，不影响站点文件与数据库。

暂时无法升级的部分缓解措施

官方明确说明：没有任何完整的缓解措施，升级是唯一安全选择。以下配置只能临时降低风险，为你争取升级时间。

针对 CVE-2026-109618（内存耗尽触发）：

  • 将 memory_limit 设为 -1，并通过 FPM 池或 Apache 的 php_admin_value 锁定，避免应用自行改回；
  • 调低 post_max_size（建议 8M，需要上传文件则 32M），并保持 upload_max_filesize 低于该值；在 Web 服务器或代理层限制请求体大小、字段数量与 header 数量；
  • 使用容器或 cgroup 资源限制兜底，让异常只影响单个 worker；注意不要使用 RLIMIT_AS / RLIMIT_DATA，它们触发的恰是漏洞利用所需的内存分配失败路径。

针对 CVE-2026-109619（状态残留触发）：

  • 在 php.ini 或 FPM 池配置中设置 session.upload_progress.enabled=0 并重启全部 worker（必须写在请求解析前生效的配置里，运行时 ini_set 与 .user.ini 无效）；
  • PHP 8.5 环境追加 fatal_error_backtraces=0，同样需要重启 worker；
  • 排查并修复业务代码中攻击者可主动触发的致命错误与执行超时；单纯用 error_reporting、display_errors 或错误抑制符隐藏报错没有作用。

常见错误与避坑提醒

  1. 只升级 CLI 不升级 Web 运行时：php -v 正确但网站仍跑旧版本，是面板多版本共存环境最常见的坑，务必用 phpinfo() 复核；
  2. 把锅甩给 WordPress：漏洞在 PHP 核心层，升级插件和主题解决不了，要升的是 PHP 本身；
  3. 下载来路不明的"补丁"和检测脚本：热点事件常被用于投毒，只认 PHP 官方公告与系统发行版官方源；
  4. 忽略反向代理后的多台机器：负载均衡后面的每一台应用服务器都要升级，漏一台等于没防；
  5. 大版本直接上生产：从 7.4 直接跳 8.x 前先在测试环境过兼容性，避免漏洞没来网站先挂。

下一步

完成升级后，建议顺手做两件事：一是按 Linux VPS 安全加固完整指南复查 SSH、防火墙与 fail2ban 配置，把暴露面收窄；二是 WordPress 站长可结合 WordPress 7.1 升级指南评估核心与 PHP 大版本的升级路线。更多日常运维选题可继续关注建站运维专题，后续有新漏洞预警我们也会第一时间跟进。