PHP2Shell 严重漏洞怎么修复？PHP 升级与旧版本应对

PHP2Shell 涉及两项可能让未登录攻击者在服务器上执行代码的严重漏洞：CVE-2026-109618 和 CVE-2026-109619，CVSS v4.0 评分均为 9.2。修复这次漏洞，需要更新实际处理网站请求的 PHP，并确认相关进程已经切换。仅安装新版本，网站却仍使用旧环境，是容易遗漏的一步。

先按你的环境选择修复路线

PHP 已于 2026 年 10 月 21 日发布修复版。下面先区分你能控制哪套环境，再决定更新、使用厂商补丁，还是测试迁移。版本和面板信息核对至 2026 年 10 月 22 日。

你当前的情况	优先处理方式	怎样证明补丁生效
标准 PHP 8.2 / 8.3 / 8.4 / 8.5	分别更新至 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12，或同分支后续包含修复的版本	网站实际 PHP、相关进程与必要扩展正确
发行版或 LTS 厂商维护的包	安装厂商明确覆盖两个 CVE 的回移修复包	完整包版本加厂商公告；不能只比较上游版本数字
PHP 7.4 / 8.0 / 8.1	检查可信厂商修复包；缺少修复来源或准备长期维护时，测试迁移到受支持分支	核对补丁覆盖、运行环境和兼容性；旧分支仍已停止上游维护
PHP 7.3 或更早，且无厂商修复承诺	先限制暴露，再处理应用依赖与 PHP 迁移	不能套用仅面向 7.4 / 8.0 / 8.1 的本次源码回移方案
共享主机，没有系统或容器管理权限	联系服务商确认实际运行环境和修复安排；有版本切换入口也要核对所选环境是否含补丁	要求说明修复包或版本、覆盖范围和生效时间，不只接受“已做防护”

如果现在拿不到补丁，或旧应用还不能迁移，先看临时访问限制与缓解措施，同时推进修复。PHP-FPM 也在风险范围内，不能因使用 Nginx 或某个面板就跳过检查。

已经运行 PHP 8.2 的站点，可以先用同分支补丁缩小应急改动。不过 PHP 8.2 将在 2026 年 12 月 31 日结束上游安全维护；从更旧版本迁移时，还应考虑应用兼容性和目标分支的维护周期。

确认网站实际使用哪套 PHP

面板显示“PHP 8.2”只是分支名称，终端里的 php -v 也只说明当前命令找到的程序。网站可能使用另一套 PHP-FPM，面板、队列和计划任务又可能各用一套。先列清楚，才能选对更新对象。

WordPress 用户可进入工具 → 站点健康 → 信息 → 服务器，记录完整 PHP 版本和 PHP SAPI。比如 8.2.25 / fpm-fcgi 表示网站请求由 PHP-FPM 处理，不能用另一套 CLI 的版本替它验收。其他应用通过受限的管理页或主机管理工具查看，不要长期公开放置 phpinfo() 页面。

有 SSH 权限时，可以先做这三项只读查询：

php -v
php --ini
php -m

它们分别列出 CLI 版本、CLI 配置文件位置和已加载模块，供后续与网站环境对照。然后在面板中记录网站绑定的运行环境、相关 PHP 服务、扩展和自定义配置；使用容器的网站，还要核对容器内部的 PHP。

备份到能恢复环境

更新前保存网站文件、数据库、Web 服务器与 PHP 配置、FPM 池配置、启用扩展清单，以及计划任务和服务的启动方式。有服务器快照时一并创建，并确认恢复入口可用。只有数据库备份，无法恢复丢失的 PHP 扩展或面板配置。WordPress 升级备份与回滚指南也解释了文件和数据库需要配套保存的原因。

记录数据库 Socket、Redis 连接方式、上传与内存限制等实际参数，保留可独立使用的 SSH 或主机控制台。切换 PHP 导致面板打不开时，仍需要一个恢复入口。快照和配置备份应放在受控位置，避免把数据库凭据上传到公开仓库或贴给 AI。

如果出现 502、后台无法登录或扩展加载失败，应暂停放量，先检查对应 PHP 错误日志和配置。需要恢复原环境时，可以使用备份恢复可用性，但若恢复后仍是未修复版本，就应继续限制公网访问，再处理补丁问题。

宝塔：更新实际使用的 PHP

宝塔面板的 PHP 更新和网站版本绑定是两个相关入口。下面的步骤根据宝塔官方安全公告和站点 PHP 配置文档核对；操作前先完成前面的备份。

1. 进入软件商店 → 已安装，先点更新软件列表 / 支付状态，获取新的软件信息。
2. 找到网站实际使用的 PHP 分支，执行对应更新，核对目标完整版本或修复包。升级面板本身不能替代 PHP 软件更新。
3. 如果新安装了另一个 PHP 分支，在网站 → 目标站点域名 → PHP中核对并切换该网站指定的运行版本。同分支原地更新时，也应确认该网站仍绑定预期分支。
4. 完成相关 PHP 服务的更新处理后，验证实际网页 PHP、模块与业务；服务器里其他仍在使用的 PHP 分支也要分别检查。

例如，网站原本使用标准 PHP 8.2 构建，应急目标是装上 8.2.35 或同分支后续含修复版本，并确认网站请求确实用到它。若发行商采用回移补丁，还要核对其完整包版本与安全公告，而不只看“PHP 8.2”这个分支名称。

截至 2026 年 10 月 22 日的宝塔公告，Linux 面板还提供了 7.4.34、8.0.31、8.1.35 三个旧分支修复包。这是宝塔应用回移补丁后打包的版本，覆盖本次两个 CVE；PHP 旧分支仍已停止上游维护，之后还需规划迁移。

宝塔 Windows 用户不能套用这三个 Linux 包。其公告对 8.2–8.5 列出相应修复版，对旧分支仍要求临时缓解并尽快迁移。两类系统都应分别核对各自的软件来源。

1Panel：准备修复环境，再绑定网站

1Panel 用户需要区分 PHP 运行环境与网站绑定。以下网站切换入口按 1Panel v2 官方文档说明，PHP 版本和扩展选择则应在当前运行环境中确认；本文没有在 1Panel 服务器上实测此次升级。

1. 确认目标网站当前绑定的 PHP 运行环境、关联容器，以及共享该环境的其他网站。保存 PHP/FPM 配置、扩展清单和必要的容器挂载信息。
2. 在 PHP 运行环境管理中准备包含补丁的环境。当前渠道有更新时按该环境的更新入口处理；需要新建时，选择已确认包含修复的 PHP 版本并补齐原站必需扩展。先核对完整版本，不能把一个 8.2 标签当成已经修复的证明。
3. 需要更换环境时，进入网站列表 → 目标网站「配置」→ 基本 → PHP，将网站切换到已经准备好的 PHP 运行环境。v2 文档明确 PHP 类型网站可以在这里切换不同运行环境。
4. 进入该运行环境关联的 PHP 容器终端，执行 php -v、php --ini、php -m，核对容器内的版本、配置与模块；再通过实际网站请求和业务测试验收。宿主机的 CLI 输出不能代替容器内结果。

如果只是重启原容器，或者重建后仍使用未修复的软件来源，漏洞不会因此消失。若当前渠道拿不到修复版，先采取临时访问限制，再选择可信的修复来源或迁移方案。这里不预设所有 1Panel 镜像渠道都已经提供同一补丁。

更新运行环境可能影响共享它的多个网站。提前列出影响范围；验证失败时停止继续切换，按备份恢复可用性。若恢复到了未修复 PHP，仍要限制公网暴露并继续处理补丁。

核对进程、扩展与后台任务

更新后先回到 WordPress 的站点健康，确认网页请求使用对应修复版，再查该网站的 PHP-FPM。下面是 Linux 的只读核对方法；需要拥有读取目标进程信息的权限，容器环境还需在正确的进程命名空间中检查。

ps -eo pid,ppid,args | grep '[p]hp-fpm: master process'

结果中的 PID 和 FPM 配置路径可帮助区分不同网站池。面板或其他组件本身也使用 PHP 时，才需要另查它们的 PHP 进程。先把它们与网站绑定的 PHP 配置对应起来。以下 12345 是示例 PID，必须替换为刚确认的目标进程；不要把一台机器上的所有 PHP-FPM 当成同一个服务。

readlink /proc/12345/exe
/proc/12345/exe -n -v
grep -E '/(opcache|redis)\.so' /proc/12345/maps

第一条读取该进程的程序路径；第二条用该进程对应的同一可执行文件，仅输出版本，-n 表示不加载 php.ini；第三条查看它已映射的 OPcache、Redis 模块文件。版本应对应修复后的 PHP，模块路径应与准备使用的文件一致。如果出现 (deleted)，说明进程仍持有已从目录中删除的文件，应继续确认并处理。没有权限或 PID 已退出时，先重新定位，不能把查询失败算作验收通过。

OPcache、Redis 等模块应来自目标环境能正确加载的文件。本站在另一套运行环境升级时曾遇到：PHP 主程序已更新，配置却仍指向旧 OPcache 文件，之后才换成新 PHP 配套模块；Redis 扩展通过加载与连接检查后继续沿用。这说明扩展要分别核对，无需因此重装 Redis 服务端。这个经验不是宝塔或 1Panel 的实测结果。

需要让修改生效时，先核对具体服务和配置，再通过对应管理入口重启或平滑重载。PHP-FPM 支持 SIGUSR2 重载配置与程序，但具体面板或容器应优先使用其管理流程；不把向宿主机某个 PID 发信号当作通用步骤。重载后观察旧工作进程是否退出，并复查程序、模块和动态请求。主进程 PID 可能保持不变，不能只凭 PID 判断成功。上述查询按 Linux /proc 和 PHP-FPM 手册核对。

队列、计划任务和监控脚本还可能调用另一套 CLI PHP。本站曾发现一个监控进程仍运行已卸载的 PHP 7.4.33，程序路径带有 (deleted)；单独重启并验证后才改用新 PHP。磁盘目录已经删除，并不代表旧进程已经退出。对这类任务，应核对启动命令、实际程序和更新后的运行结果，再决定是否清理旧组件。

低于 8.2，怎样让 AI Agent 帮忙

旧站真正需要判断的是：有没有可信的现成修复包，以及应用能迁移到哪个受支持版本。让 AI 先收集证据、整理方案，比一句“帮我升级到最新版”更容易得到可执行的结果。

第一轮：只读盘点

可以把下面的提示词交给能在你授权环境中操作的 Agent。登录通过主机或面板的正规入口完成，不把密码、Cookie 或完整敏感配置粘贴进聊天。

我要应对 CVE-2026-109618 和 CVE-2026-109619。先只读检查，不安装、不重启、不改配置。

请分别确认：
1. 操作系统、面板和软件包/镜像来源。
2. 每个网站实际使用的 PHP 完整版本、SAPI、对应服务或容器。
3. 面板自身、CLI、定时任务、队列和监控是否另用一套 PHP。
4. 配置文件位置、扩展、数据库/缓存连接方式，以及 PHP 进程实际使用的程序；不要输出密码、令牌或其他密钥。
5. 当前厂商是否明确提供这两个 CVE 的修复包，列出公告、完整包版本及适用系统。

分别列出已确认事实、无法确认的项目和下一步需要的条件。不能只用 php -v 或 HTTP 响应头判断网站已修复。

这一轮应得到一张“网站或服务 → PHP → 来源 → 补丁状态”的对应表。例如：宝塔 Linux 的某网站使用 7.4，且当前商店提供官方公告列出的修复包，便可以先评估同分支更新；只有“装着 PHP 7.4”而没有来源和补丁证明，不能得出相同结论。

第二轮：选厂商补丁或测试迁移

PHP 官方确实为 7.4、8.0、8.1 提供了最小源码回移入口，但它们面向需要自行构建或缺少 LTS 来源的场景。把补丁文件放进网站目录不会修复 PHP；让 Agent 临时生成一段 C 代码，也不能当成官方补丁。普通面板用户优先选择可追溯的厂商包，或者安排兼容性迁移。

根据刚才的盘点，给出最小改动的应急方案和后续迁移方案，先不要执行。

有厂商回移包：列出两个 CVE 的修复依据、适用系统、备份范围、更新入口、需要重启的具体服务、验收及回滚方法。

没有可信包：检查应用、主题、插件、框架、Composer 依赖、加密加载器和 PHP 扩展的版本要求；选择一个受支持且包含修复的 PHP 分支，在隔离测试环境验证。不要直接拿生产网站试兼容性。

测试至少覆盖登录、页面、数据库读写、文件上传、缓存、定时任务和业务关键流程。列出失败项、阻塞依赖、目标配置及切换影响。迁移完成前说明怎样限制公网暴露。

如果需要自行编译，只评估官方回移补丁、现有编译参数、扩展 ABI、构建测试和恢复要求；不要自行发明补丁，不替换生产二进制。

Agent 应交付可核查的包来源或测试结果，以及明确的服务清单。如果应用依赖一个只支持旧 PHP 的加载器，就要先解决该依赖，不能用“升级后再说”略过。PHP 7.3 及更早版本也不能直接套用 7.4 的补丁分支。

第三轮：限定范围执行，再交付验收结果

前两轮应产出明确的包来源或迁移测试结果。你确认目标、恢复手段和影响范围后，再让 Agent 执行，避免它一边猜环境、一边改生产配置。可在确认具体方案后补充：

只执行我已确认的目标环境和方案。开始前复核备份位置、恢复入口、实际 PHP 服务及受影响网站。

逐项说明将修改的文件、安装或更新的包，以及需要重启/重载的具体服务。不要重启数据库或 Redis，不删除旧组件；确需扩大范围时先说明原因。

预检通过后执行已授权步骤。若扩展加载、配置测试或关键业务失败，停止后续变更并报告；按已确认的恢复方案处理，恢复到未修复 PHP 时继续限制公网暴露。

结束后按网站、面板、后台任务分别返回：修改前后版本、进程对应程序、扩展路径、真实动态请求和业务测试结果、未完成项目。写明每个结论的证据；无法确认就标为未完成，不用“安装完成”代替修复验收。

合格的交付应让你看得见证据，而不只是一句“已修好”：

交付项	应当包含的结果
补丁依据	来源公告、完整包版本，以及两个 CVE 是否都被覆盖
正在使用的环境	网站请求、面板和后台任务各自的 PHP；区分未使用组件与仍在运行的进程
业务验证	哪些动态页面、登录、上传、数据库、缓存及任务已经检查，失败项是什么
恢复和遗留	备份位置、恢复方式、尚未修复的实例与临时访问限制

暂时不能升级，先减少暴露

暂时无法修复时，优先限制未修复 PHP 的公网访问。必要时由 Web 服务器或代理直接返回静态维护页，并覆盖可直连源站、备用域名和其他入口，避免请求继续进入 PHP。只开启应用内部维护模式，未必能阻断应用代码执行前的攻击路径。

PHP 官方还给出了特定路径的临时缓解。例如，在实际 Web 环境使用的 php.ini、FPM 池或服务器配置中关闭 Session 上传进度跟踪：

session.upload_progress.enabled = 0

保存前备份并检查配置，然后使全部相关工作进程退出、重新启动，核对网站请求中的生效值。这项措施只阻断 CVE-2026-109619 已确认的 Session 路径；不能替代两个漏洞的修复。PHP 8.5 还有 fatal_error_backtraces=0 的对应局部缓解。不要依赖应用中的 ini_set() 或 FPM 的 .user.ini，它们无法按官方要求在请求解析前完成这里的设置。

请求大小和复杂度限制需要结合上传、导入等业务设置。官方提到的 memory_limit=-1 会取消 PHP 自身的内存上限，涉及容器或 cgroup 等资源隔离；不适合普通站长直接复制到配置里。缺少这些条件时，先限制访问并完成更新更容易把风险控制住。

怎样验收修复完成

按最初的环境清单逐项回查：

• 实际请求：每个相关网站使用已修复 PHP，或有厂商公告和完整包版本证明已回移两个 CVE 的补丁。
• 运行进程：网站工作进程已切换；需要更新的面板、容器和后台服务分别确认，没有用新磁盘文件的版本代替旧进程版本。
• 配置与模块：新程序加载正确配置，Redis、数据库扩展、图片处理和 OPcache 等必要模块符合预期，错误日志没有相关启动异常。
• 业务：登录、页面、上传、数据库、缓存与关键任务正常。对缓存网站还要验证动态请求，单看 CDN 首页不足以判断 PHP。
• 恢复与遗留：保留备份、变更记录和仍待迁移的旧分支；确认依赖解除后再清理旧组件。

补丁验收解决的是当前运行环境的漏洞状态。如果已有异常文件、账号、外连或可疑日志，还需继续调查，不能用“已升级”关闭这些线索。

修复来源

• PHP 官方公告及旧分支回移入口：https://www.php.net/archive/2026.php#2026-10-21-5
• 宝塔 Linux / Windows 分流与更新说明：https://docs.bt.cn/notices/php-nodejs-security-update-2026-10-21/
• 宝塔站点 PHP 版本绑定：https://docs.bt.cn/user-guide/site/php/site-config/php
• 1Panel v2 网站 PHP 运行环境切换：https://1panel.cn/docs/v2/user_manual/websites/website_config_basic/
• 1Panel PHP 版本与扩展选择（v1 文档）：https://1panel.cn/docs/v1/user_manual/websites/php/
• 内存耗尽漏洞详情：PHP 官方 OOM 安全通告
• Linux 进程程序与模块映射说明：https://man7.org/linux/man-pages/man5/proc_pid_exe.5.html 、https://man7.org/linux/man-pages/man5/proc_pid_maps.5.html
• PHP-FPM 参数与重载信号手册：https://manpages.debian.org/bookworm/php8.2-fpm/php-fpm8.2.8.en.html
• 状态残留漏洞详情：PHP 官方 stale-state 安全通告