无人维护的 PHP 老站如何修复 PHP2Shell

01

先找回管理权，不急着切 PHP

清点域名注册商、主机账号、服务器或面板权限、代码、数据库凭据和续费负责人。明确谁批准维护窗口、谁负责恢复。根据本地文件识别真实系统及准确版本，不能靠前台模板猜测。账号、源码不全时，先向服务商或原供应商恢复资料，再动生产环境。

02

保留证据，并真正恢复一次备份

怀疑被入侵时先保留访问、错误和应用日志，按入侵响应指南处置。把代码、数据库、上传附件、配置与定时任务作为同一日期的备份集，记录字符编码和外部存储。备份应加密并限制访问，恢复到私有环境后检查文章、附件和登录。显示“备份成功”不等于能够恢复。

03

先画清 PHP 代际差距

PHP 5.3/5.6 老项目可能依赖 mysql_* 等已移除接口。PHP 7 移除 ext/mysql；PHP 8 移除 each()、create_function() 并收紧签名和类型规则；PHP 8.2 对动态属性报弃用提示。逐代阅读跨过的迁移说明。框架历史最低要求不代表适合继续部署，也不能代替二次开发代码兼容测试。

04

选择修复、分阶段迁移或静态归档

兼容性改造期间，若厂商在原分支提供可信修补，可先核实两个 CVE 的修复证据和后续维护。停止支持的 PHP 仍需迁到受支持目标，不能长期只靠 WAF。持续经营且可接管的系统适合修复；依赖废弃严重时评估重建；纯内容老站可评估静态归档，同时处理登录、搜索和表单等后端功能。

05

建立贴近目标环境的私有演练站

让 Web PHP、扩展、INI、数据库和路由配置贴近目标。使用脱敏数据、访问控制，阻止演练站发真实邮件、扣款或调用生产回调。框架、插件与二次开发必须成组升级。执行对应系统的业务验收清单，保存日志和结果。不懂代码的负责人也可要求主机商交付这些记录。

06

回退方案必须考虑订单和数据库变更

保留配套的代码与数据库恢复集。切回 PHP 不能撤销数据库结构迁移。最终迁移前约定订单、文章等写入冻结，或采用经过演练的数据同步办法。明确失败条件、操作人和回退时限；记录快照后新增订单，测试恢复与对账，不能靠丢掉新交易来完成回退。

07

上线后检查真实运行服务

核对域名实际使用的 PHP、每个 FPM 池、队列、定时任务、容器和副本，替换旧工作进程并检查启动错误。按上游版本或厂商回补公告核实两个 CVE，再验证深链接、登录、上传和业务流程。保留日志与观察回退窗口；CLI 的 php -v 和首页正常都不够。

PHP2Shell 修复后的业务验收

核实 PHP2Shell 修复

应用兼容性、应用维护支持和 PHP 安全是三项独立检查。选择仍受支持且修复两个 CVE 的 PHP 分支，再验证 Web 工作进程、定时任务和全部副本。只更新框架或插件不会更换 PHP 解释器。