PHP2Shell：升级旧版 PHP，还是迁移到 Node.js？

返回

Kevin Riedl

10 分钟 阅读 · 2026年10月21日
最近审核 2026年10月21日

下一篇

PHP 的关键安全补丁已经发布。真正难办的是：企业应用无法在修复后的版本上正常运行，怎么办？

如果旧框架、自定义扩展或无人维护的插件让公司一直停留在 PHP 7.4、8.0 或 8.1，仅在托管面板里切换版本就可能导致产品出错。你需要先验证如何修复当前风险，再找到一条可行的升级路径，让团队能够长期维护这套软件。

Wavect 帮助企业将旧版 PHP 应用升级到最新、已修复漏洞且仍受支持的 PHP 版本。我们解决兼容性问题，测试关键业务流程，并规划生产环境的切换。如果业务适合更大的调整，我们也可以将 PHP 应用迁移到 Node.js/TypeScript、.NET、Java 或其他合适且持续维护的技术栈。

资料核查日期：2026年10月21日。下文版本号反映该日期已发布的版本。实际实施前，请再次确认仍受支持分支上的最新补丁。

新的 PHP2Shell 漏洞是什么？

PHP2Shell 指 PHP 运行环境中的两个严重漏洞：CVE-2026-109618 和 CVE-2026-109619。漏洞详情与修复版本于2026年10月21日一同发布。攻击者可能无需登录，就能在受影响的服务器上执行代码。CERT-EU 的 PHP 安全公告要求立即安装补丁，并指出处理 Web 请求的 PHP 部署存在风险。

官方警告涵盖 Apache 的 mod_php、PHP-FPM、php-cgi、FrankenPHP 和 LiteSpeed。PHP 团队认为 mod_php 风险最高，已演示在应用代码运行之前触发攻击。具体攻击路径会随配置变化。使用 Nginx 与 PHP-FPM 的部署也需要处理。

只更新 WordPress、Laravel、Symfony 或其他应用，并不等于更新了底层 PHP 运行环境。这两层都需要确认。

哪些 PHP 版本修复了 PHP2Shell？

首批已修复的稳定版本是 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35。请安装适用的受支持更新，或经过核实的供应商修复包。如果当前 PHP 分支仍受支持，可以先在同一分支内安装安全补丁，解决眼前问题，再准备更大的版本升级。

这些期限来自 PHP 官方支持计划。PHP 8.2 虽然获得了本次修复，但安全支持即将结束，因此只适合作为短期过渡目标。

如果希望升级到最新稳定版，本文发布当天核实的目标是 PHP 8.5.12，前提是应用兼容。PHP 官方版本公告还列出了包含修复的 PHP 8.6.0 RC4，但明确说明这是测试版本，不应投入生产使用。

还在使用 PHP 7.4、8.0 或 8.1，怎么办？

这些分支已经不再获得 PHP 项目的常规安全版本更新。但这不代表每一套旧部署都没有可用修复。针对本次严重问题，PHP 特别提供了适用于 7.4、8.0 和 8.1 的最小源码回移补丁。操作系统发行版和长期支持供应商也可能提供修复包。

回移补丁，也称 backport，是把修复应用到较早的代码版本。它可以在兼容性改造完成前提供过渡方案，但不会让一个已停止支持的分支重新获得 PHP 官方的常规维护。判断官方支持状态，应以 PHP 停止支持版本清单为准。

请向托管供应商确认：哪个具体软件包修复了两个 CVE，你的服务套餐是否可以使用，以及由谁部署。供应商修复包可能保留看起来较旧的 PHP 版本号，因此还要核查软件包修订号及对应安全公告。源码补丁也需要有人负责构建、测试、部署和后续维护。

如果现有部署没有可验证且受支持的修复包，也没有可行的回移补丁，Wavect 可以评估阻碍升级的问题，并将应用迁移到已修复、仍受支持的 PHP 分支。工作范围包括应用及其依赖，而不只是调整服务器设置。

企业现在应该立即做什么？

1. 找出所有 PHP 部署。包括客户门户、网站、管理工具、旧子域名、容器和供应商产品。NCSC-NL 的 PHP2Shell 资产排查指南特别提醒检查内置 PHP 的软件和设备。
2. 确认真正处理请求的 PHP 环境。终端里的 php -v 可能指向另一套安装，与 PHP-FPM 或 Apache 使用的版本不同。请核查每个实例实际处理 Web 请求的运行环境、软件包来源和运行中的构建版本。诊断页面应保持私密。
3. 安装并验证修复。更新相应软件包或镜像，重启或替换受影响的工作进程，并逐一检查所有实例。只改镜像标签而不重新部署运行中的服务，并没有完成更新。
4. 测试业务流程。检查这套部署实际使用的登录、权限、支付、文件上传、定时任务和外部集成。
5. 无法立即更新时，明确如何降低暴露风险。遵循最新官方临时处置建议。CERT-EU 建议：如果无法及时修复暴露在公网的服务，应考虑暂时将其与公共网络隔离。

PHP 的临时配置措施只能覆盖特定攻击路径。WAF 规则或临时配置不能证明 PHP 运行环境已经修复。如果发现入侵迹象，应在打补丁的同时安排事件调查；仅完成更新，不能证明系统中没有残留问题。

为什么升级 PHP 会让旧应用出错？

旧版 PHP 升级往往也是一项兼容性改造。PHP 的 PHP 7.4 升级至 8.0 迁移说明记录了行为变化和移除的功能。PHP 8.5 迁移指南也要求在切换生产环境前测试不兼容变化。

在确定最终目标版本前，我们会检查五类常见障碍：

• 框架与 CMS 支持情况：当前版本、主题和插件是否支持计划使用的 PHP 版本。
• 依赖项：Composer 版本限制、无人维护的软件包，以及需要替换的库。
• 扩展与托管环境：数据库驱动、图像处理、自定义模块，以及托管供应商真正能够提供的软件包。
• 业务行为：必须保持正常的计算、校验、会话、权限和外部集成。
• 上线控制：可用的测试环境、备份、监控，以及能够保护新增数据的回退方案。

从 PHP 7.4 升级到 8.5 时，还应检查中间各版本的迁移指南。可以在隔离环境中测试这些变化，无需将每一个已过时的中间版本都暴露在生产环境中。

应该升级 PHP，还是迁移到 Node.js？

如果应用能够以合理成本在受支持版本上继续维护，就可以保留 PHP。如果产品需求、依赖项或团队技能使替换技术栈更有价值，再考虑分阶段迁移。先解决当前暴露风险，避免让紧急修复依赖于整个系统的重写。

如果团队已经在开发 JavaScript 应用，Node.js/TypeScript 可能适合。已有企业技术环境也可能更适合 .NET 或 Java。评估集成、托管条件、人员经验和运营成本后，其他持续维护的技术栈同样可以成为选择。Node.js 的官方版本指南建议生产应用使用 Active LTS 或 Maintenance LTS 版本。

从一个组件中移除 PHP，可以消除该组件对这两个特定 PHP 运行环境漏洞的暴露。这并不代表 Node.js 或其他技术没有自己的漏洞。新的 React 前端、放在 PHP 前面的 JavaScript API，或采用 headless 架构的 WordPress，仍然可能保留需要维护的 PHP 组件。

确定架构后，我们的Web 应用开发服务可以负责实施。技术选择应符合企业实际需要运营的产品。

示例：停留在 PHP 7.4 的订单门户

以下是说明性场景，并非客户案例：一家经销商的订单门户具有定制价格、按客户区分的权限，以及 ERP 集成。一个无人维护的模块阻碍了直接升级。

首先要获得经过验证的运行环境修复，或在准备修复期间限制暴露的服务。然后测试：替换这个模块，能否让现有应用在当前 PHP 版本上继续运行？如果可以，PHP 升级就能保留多年积累的有效业务逻辑。

如果企业同时需要更大范围的产品调整，我们可以把一项边界清晰的功能迁移到 Node.js，同时让已修复的 PHP 系统继续运行。每一步都要明确谁负责写入哪些数据，保持权限规则兼容，并检查订单是否遗漏或重复。只有被替换的 PHP 路径及其依赖真正退役后，这部分迁移才算完成。

值得比较的是：继续维护 PHP 产品的成本，与分阶段替换的成本和价值。后者也要计入两个系统同时运行的过渡期。

Wavect 如何帮助企业升级和迁移 PHP？

我们帮助奥地利、德语区及其他国家的企业，把紧急 PHP 更新转化为可以执行的计划。如果现有代码或升级路径不清楚，可以从我们的软件接管与评估服务开始。

我们的软件质量保障服务可以根据约定的业务行为验证发布结果。若还涉及更完整的维护责任交接，可以参考软件项目接管指南。

费用与工期取决于框架、已停止支持的依赖、集成、测试覆盖，以及可以接受的维护窗口。我们会先检查这些障碍，再约定范围。回退方案必须保护新增交易数据，也不能把已知存在漏洞的运行环境重新开放到公网。

怎样证明 PHP 升级已经完成？

结束工作前，应确认以下证据：

• 运行环境证据：准确的 PHP 官方版本或供应商软件包信息，覆盖两个 CVE 的修复依据，以及每个处理 Web 请求实例的验证结果。
• 部署证据：旧工作进程已经替换或重启，旧容器实例不再接收流量。
• 业务行为证据：权限、交易和必要集成的约定测试已经通过，上线后的相关错误也已检查。
• 如果迁移到非 PHP 技术栈：提供清单，说明哪些 PHP 服务已退役，哪些仍保留并继续获得补丁与维护。管理面板和 CMS 后端也要计入。

请告诉我们 PHP 版本、框架或 CMS、托管方式，以及必须保持正常的业务流程。如果不知道版本，先告诉我们应用由谁托管。我们可以从这些信息开始，帮助明确升级或迁移范围。