PHP2Shell 漏洞修复教程 2026：PHP 8.2–8.5 安全版本、AWS WAF、1Panel 与网站应急检查

一、PHP2Shell 为什么值得所有网站管理员关注？

2026 年 10 月 21 日，PHP 项目紧急发布多个安全版本，修复两项可能导致未经认证远程代码执行的严重漏洞。

这两项问题被合称为 PHP2Shell。

相关漏洞编号是 CVE-2026-109618 和 CVE-2026-109619。

它们涉及 PHP 运行时处理请求过程中出现的内存状态问题。

与普通 CMS 插件漏洞不同，PHP2Shell 的关键风险位于 PHP 语言运行环境本身。

这意味着，不只是某一款 WordPress 插件或某一个网站主题可能受到影响。

凡是使用存在风险的 PHP 运行时处理 Web 请求的系统，都需要核对相关修复状态。

例如，博客、商城、企业管理后台以及基于 PHP 的业务接口。

Amazon 威胁情报团队还表示，在 PHP 项目正式公开漏洞之前，就已经从安全遥测中发现可疑利用尝试。

这进一步说明，此次升级不适合长期拖延。

二、两个 PHP2Shell 漏洞分别是什么？

AWS 安全博客将两项漏洞的 CVSS v4.0 严重程度均列为 9.2。

它们都被归类为严重风险。

但“漏洞存在”与“服务器已经被控制”是不同事实。

例如，网站运行某个受影响版本，不代表攻击者已经实际执行了命令。

真正是否遭到利用，需要结合服务器日志、网络记录和其他取证材料判断。

因此，管理员应该立即核对和修复，而不是未经检查就宣布网站遭到入侵。

三、哪些 PHP 版本需要升级？

PHP 官方在 10 月 21 日发布了以下修复版本：

对于直接采用 PHP 官方发行版本的用户，应升级至所属分支的修复版本或之后经过官方确认的更新版本。

对于使用 Linux 发行版软件包的服务器，需要核对发行版是否已经回移相关补丁。

因为某些长期支持系统可能保留旧的版本编号，同时将安全修复合并进去。

因此，不能单纯使用版本号判断所有发行版软件包都未修复。

但如果使用 PHP 8.1 或更早的上游已停止支持版本，应尽快制定迁移计划，或者确认可信长期维护供应商已经提供实际补丁。

四、为什么只更新 WordPress 或 Z-Blog 不够？

一些网站管理员习惯在发生安全问题时，第一时间升级网站程序和插件。

这当然是重要措施，但不能代替 PHP 运行时更新。

例如，某个网站使用最新的 CMS。

如果底层仍运行存在问题的 PHP 版本，那么语言运行时漏洞可能依然存在。

这次问题涉及 PHP 在应用代码正常处理请求之前或相关请求阶段的内部行为。

因此，安全修复必须覆盖真正运行 Web 请求的 PHP 实例。

对于 CMS 用户，建议分别检查三个层面：

网站主程序。

插件与主题。

PHP 运行环境。

三个层面相互配合，才能构成比较完整的维护流程。

五、为什么 Apache mod_php 被特别强调？

PHP 官方指出，所有处理 Web 请求的相关 PHP 部署方式均需关注。

包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed。

其中，官方认为 mod_php 部署风险尤其值得警惕。

因为相关研究展示，在特定配置中，未经认证的请求可能在应用正常代码执行之前触发问题。

但是，mod_php 风险较高不意味着其他方式安全。

例如，网站采用 PHP-FPM，也不能因此省去升级。

正确做法是盘点所有正在运行的 PHP 环境，并逐一核对修复状态。

六、如何检查服务器实际 PHP 版本？

管理员可以在有授权的服务器终端执行：

php -v

这能够查看当前命令行 PHP 版本。

但命令行 PHP 不一定等于网站实际使用的版本。

例如，服务器可能同时安装多个 PHP 分支。

网站使用 PHP-FPM 8.3，终端默认却调用 PHP 8.4。

因此，还应检查站点对应的 PHP-FPM 服务、容器镜像或面板环境。

在 Linux 中，可以根据系统环境检查：

systemctl list-units --type=service | grep -i php

以及对应服务的运行状态。

不同发行版的服务名称可能不同。

如果是 Docker 部署，则需要核对网站实际连接的 PHP 容器，而不是只检查宿主机环境。

七、使用 1Panel 的网站怎么处理？

如果使用 1Panel 管理 PHP 网站，建议先查看网站实际绑定的运行环境。

确认是 PHP-FPM、容器化 PHP 还是其他服务方式。

随后记录当前 PHP 版本、扩展、配置文件和数据库连接信息。

不要直接删除旧运行环境。

更稳妥的方法是先备份站点文件和数据库，再在测试环境安装修复版本。

确认网站页面、登录、支付回调、定时任务和后台功能正常后，再切换生产环境。

对于依赖特殊 PHP 扩展的应用，需要提前确认扩展是否支持目标版本。

如果服务器具有多个网站，应逐个核对，避免只升级默认站点而遗漏其他运行实例。

八、Docker 容器如何核对？

首先查看实际运行的容器：

docker ps

然后，在确定容器名称后检查 PHP：

docker exec <container_name> php -v

这里的 <container_name> 需要替换为真实容器名。

如果镜像包含多个 PHP 运行入口，还应核对实际负责 Web 请求的进程。

对于需要修复的容器，不建议直接在正在运行的容器内部临时覆盖大量 PHP 二进制文件。

更合理的方式是更新可信镜像版本，再按照部署编排进行重建。

重建前应确保数据库和上传目录使用持久化存储。

否则，错误处理可能造成业务数据丢失。

九、PHP 官方 10 月 23 日为什么又发布提醒？

10 月 23 日，PHP 项目公开了一项关于 Session Upload Progress 的额外安全提醒。

其对应问题是 CVE-2026-115560。

这个问题与此前修复的两项严重漏洞有所不同。

PHP 官方说明，它需要非常特殊的配置组合才能出现。

例如，应用配置使用特定的 session.serialize_handler，然后在运行时切换处理器，并在相关位置启动 Session。

同时，Session Upload Progress 功能仍处于启用状态。

因此，不能将它直接归类为所有 PHP 网站都能被同一方式利用的新漏洞。

但需要注意，10 月 21 日的安全版本并未同时修复这项独立问题。

PHP 官方建议有需要的用户临时关闭相关功能，等待后续常规修复版本。

十、session.upload_progress.enabled 应如何处理？

PHP 官方临时建议可以通过关闭 Session Upload Progress 降低相关特殊配置风险。

其配置项为：

session.upload_progress.enabled=0

但这项配置可能影响依赖 Session 上传进度的业务功能。

因此，生产调整前需要确认网站是否使用相关能力。

如果不需要，可以考虑按官方建议关闭，并在受控变更流程中重新加载对应 PHP 服务。

如果确实依赖该功能，则需要结合具体配置、业务代码和官方安全公告处理。

此外，10 月 21 日修复的两项主要 PHP2Shell 漏洞仍然要求更新 PHP 运行时。

不能把关闭 Session Upload Progress 当作所有问题的完整替代方案。

十一、AWS WAF 提供了哪些防护？

AWS 在安全博客中介绍了针对 PHP2Shell 的 Web 应用防火墙缓解措施。

其中，AWS Managed Rules 的 PHP Application 规则组加入了相关检测规则。

10 月 22 日的版本 2.3 引入 PHP2Shell_BODY。

10 月 23 日的版本 2.4 又增加了 PHP2Shell_BODY_Extended。

AWS 表示，使用默认版本的相关客户能够自动获得对应规则更新。

但如果企业锁定了旧版规则组，就需要检查是否完成升级。

这些规则能够降低部分已知攻击路径的风险。

不过，AWS 也明确指出，WAF 不是完整修复。

根本问题仍然需要通过安装 PHP 安全补丁解决。

十二、Cloudflare、OpenResty 可以替代升级吗？

不能。

Cloudflare 和 OpenResty 可以承担反向代理、请求过滤、限流和部分 WAF 防护功能。

但这些措施主要控制 HTTP 请求路径。

PHP2Shell 的根本缺陷存在于 PHP 运行时。

即使大部分攻击流量能够被过滤，错误配置、绕过代理的直连路径或新攻击变体仍可能带来风险。

因此，正确的关系是：

首先升级 PHP。

其次使用 WAF 和合理的请求限制降低额外风险。

再检查日志和访问控制。

如果暂时不能升级，应根据业务重要性采取隔离、暂停高风险服务或其他明确的应急措施。

十三、AWS 是否发现公开前的利用尝试？

是的。

Amazon 威胁情报团队公开表示，其 MadPot 监测系统在 10 月 17 日观察到疑似 PHP2Shell 利用活动。

这早于 PHP 10 月 21 日正式披露。

AWS 还提到，相关流量使用了与匿名化网络有关的来源。

但这一观察不能直接说明攻击者身份。

也不能证明互联网上的所有 PHP 服务在 10 月 17 日已经遭到入侵。

对于防御人员，这项情报的重要价值是提醒：漏洞尚未公开，并不代表一定没有人在尝试利用。

因此，安全工作不能完全依赖正式 CVE 公告之后才开始监控。

十四、网站管理员应该检查哪些日志？

首先是 Web 服务器访问日志。

例如，检查短时间内异常增多的上传请求、大量失败响应和非预期来源。

其次是 PHP-FPM 或 Apache 错误日志。

关注异常进程退出、内存错误和请求处理异常。

第三是主机安全日志。

检查未知进程、新增计划任务和异常外联。

第四是应用日志。

例如，查看后台管理员操作、插件更新和非预期文件变更。

不过，日志异常并不自动证明利用成功。

尤其不能只根据出现 500 错误就宣布服务器遭到远程代码执行。

需要综合关联时间、来源、行为和主机证据。

十五、发现可疑迹象应该怎么办？

如果怀疑服务器已经受到入侵，应避免在没有保留证据时随意清理系统。

首先限制不必要的外部访问。

随后保存相关日志和当前运行环境信息。

对重要数据进行独立备份，并检查备份是否完整。

如果确认有恶意访问，应按照企业应急响应流程隔离受影响服务。

对于支付、用户信息和敏感业务，还需要评估凭据是否可能泄露。

如有必要，使用可信备份和经过验证的镜像重建服务。

但重建时必须先修复 PHP 环境，否则新系统可能继续暴露相同风险。

十六、为什么不应该随意运行网络上的漏洞扫描脚本？

重大安全漏洞公开后，互联网上往往会出现大量检测脚本。

其中部分可能是真实研究工具。

但也可能有恶意程序伪装成安全扫描器。

因此，管理员应优先使用 PHP 官方、可信安全机构和成熟服务商提供的资料。

如果需要下载第三方工具，应核对作者、代码、发行版本和签名。

对生产服务器执行任何代码前，都应该确认其实际行为。

尤其不要为未经审查的脚本授予 root 权限。

对于拥有许多网站的企业，使用官方版本清单和自动资产盘点，通常比盲目运行外部利用验证工具更加稳妥。

十七、如何安排持续防护？

此次事件不是 PHP 网站安全工作的终点。

建议管理员建立软件生命周期台账。

记录 PHP 运行版本、扩展、Web 服务器、CMS 和插件。

同时订阅官方安全公告。

重要安全版本发布后，优先评估公网服务。

对于不再受到上游支持的软件，应提前规划替代或长期支持渠道。

另外，建立定期备份与恢复演练。

如果拥有多个节点，应该验证升级过程中是否能够逐步切换流量。

真正成熟的运维系统，应该既能及时升级，也能在升级出现兼容问题时安全恢复。

十八、FAQ：常见问题

PHP2Shell 涉及哪些漏洞？

主要包括 CVE-2026-109618 和 CVE-2026-109619。

PHP 官方修复版本是什么？

8.2.35、8.3.36、8.4.27 和 8.5.12。

PHP-FPM 是否安全？

不能这样判断。PHP 官方同样要求相关 PHP-FPM 环境升级。

升级 WordPress 或 Z-Blog 是否就够了？

不够。此次主要漏洞位于 PHP 运行时。

安装 WAF 能完全修复吗？

不能。WAF 只能缓解部分攻击路径。

CVE-2026-115560 是否已被 10 月 21 日版本修复？

没有。PHP 官方 10 月 23 日单独发布了对应的特殊配置风险提醒。

关闭 session.upload_progress.enabled 是否会影响业务？

可能影响依赖 Session 上传进度的功能，应先核对实际应用。

已经升级 PHP 还需要检查日志吗？

建议继续检查，因为升级修复未来暴露风险，并不自动排除过去可能发生的异常行为。

十九、结语：安全升级应优先于临时拦截

PHP2Shell 是一次提醒整个 Web 开发生态的严重安全事件。

它说明，成熟的软件运行时也可能存在长期未发现的深层缺陷。

即使网站程序和插件都保持最新，底层运行环境仍然需要持续维护。

对于站长，最重要的是核对真正处理网站请求的 PHP 版本，并及时安装可信修复。

对于企业运维团队，还应将 WAF、日志、备份和应急预案结合起来。

随着 AI 辅助安全研究能力提高，漏洞发现可能更加迅速。

防御方也需要让资产盘点、补丁升级和故障恢复变得更加可靠。

官方与可信来源

1. PHP 官方安全公告与后续提醒： https://www.php.net/

2. PHP 官方发布版本： https://github.com/php/php-src/releases

3. AWS Security Blog — PHP2Shell WAF 防护： https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/

4. Amazon Threat Intelligence — PHP2Shell 公开前利用迹象： https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/

`5. 荷兰国家网络安全中心 PHP2Shell 运营信息： https://github.com/NCSC-NL/php2shell