PHP 是运行在服务器上的编程语言和运行环境，许多网站与 Web 应用都会用它生成页面、处理登录、读写数据库和响应接口请求。WordPress 本身也是依赖 PHP 运行的内容管理系统，因此，WordPress 后台或插件能够自动更新，并不代表网站服务器上的 PHP 也会自动获得安全修复。

此次安全公告涉及两个严重漏洞，严重等级为 9.2/10。安全公司 watchTowr 表示，相关问题据称影响 PHP 5 及之后的版本，并可能被利用执行远程代码（Remote Code Execution，简称 RCE）：攻击者一旦成功利用，就可能让服务器运行其准备的代码，进而篡改网站、窃取数据或破坏服务。

据原报道，PHP 修复补丁已于 10 月 21 日美国东部时间上午 10 点发布，PHP 管理员被要求在对应版本可用后尽快升级。研究人员估计，可能有超过 130 万台连接互联网的主机受到影响；由于 WordPress 网站普遍运行在 PHP 服务器上，使用 WordPress 的站点也不能只等待 WordPress 的自动更新。

这不是“更新一个插件”就能解决的问题。站点所有者首先需要确认 PHP 由谁维护、网站实际运行在哪些服务器上，以及自己是否拥有切换或升级 PHP 的权限。

WordPress 网站为什么需要单独检查 PHP

WordPress 的核心程序、主题和插件，运行在主机提供的 PHP 环境中。它们的自动更新机制主要负责 WordPress 自身及其扩展，并不会替主机升级 PHP 软件包，也不会自动重启承载网站请求的 PHP 服务。

因此，网站可能出现这样的情况：WordPress 后台显示“已是最新版本”，但服务器仍运行着尚未修复的 PHP 版本。Wordfence 也提醒，运行在 PHP 服务器上的 WordPress 网站都需要检查自身环境；PHP 的修复不能通过普通的 WordPress 自动更新完成，通常需要主机商、系统管理员或托管服务商处理。

这里的“PHP 版本”指网站实际处理 Web 请求时使用的运行时版本，而不一定是管理员在命令行中看到的版本。很多服务器同时存在命令行 PHP、PHP-FPM 服务和多个 PHP 版本，反向代理、容器或负载均衡后面还可能有多台应用服务器。只升级其中一个环境，不能保证网站已经完成修复。

第一步：确认网站实际使用的 PHP 环境

1. 先确认负责升级的人或平台。虚拟主机用户通常需要通过主机控制面板切换 PHP 版本，云平台用户可能需要修改运行时配置；自建服务器则由系统管理员更新软件包和服务。若没有服务器权限，应直接联系主机商或托管服务商，而不是只更新 WordPress。
2. 查看当前 PHP 版本。可以从主机控制面板、托管平台或服务器配置中查看。自建服务器也可以运行 php -v，但这条命令通常查看的是命令行环境，不能单独证明网站正在使用同一个版本；还需要确认 Web 服务器连接的 PHP-FPM 或其他 PHP 处理进程。
3. 盘点所有实际承载流量的节点。如果网站使用了容器、自动扩缩容、多台 Web 服务器或负载均衡，需要逐一确认每个节点的 PHP 版本。反向代理或 CDN 只负责转发、缓存或过滤请求，并不意味着后端 PHP 已经升级。
4. 记录升级前状态。保存当前 PHP 版本、Web 服务器配置、PHP 扩展列表、站点运行节点以及重要服务配置，便于升级后定位兼容性问题或按原流程回滚。

升级前先准备测试环境和可恢复备份

PHP 版本切换可能影响旧插件、主题、扩展或应用代码。即使这次升级的主要目标是修复安全漏洞，也不应在没有恢复手段的情况下直接改动唯一的线上实例。

1. 准备隔离测试环境。尽量复制网站文件、数据库和必要的 PHP 配置，在不接收真实外部流量的环境中切换到提供商发布的修复版本。
2. 测试关键功能。至少检查首页、后台登录、文章发布、文件上传、数据库连接、定时任务、REST API、缓存和支付等与站点业务有关的功能。测试的目的不是证明网站“看起来能打开”，而是确认 PHP 版本切换没有让核心业务失效。
3. 制作可恢复备份。升级前保存数据库、网站文件和当前配置，并确认备份能够读取。若升级后出现白屏、插件致命错误或大量 5xx 错误，应按照主机商或运维平台的既定流程恢复，而不是在生产环境中反复试错。

如何完成 PHP 安全升级

原报道没有列出具体的修复版本号，因此不能简单地把“升级到最新版”当作精确操作指令。应根据 PHP 提供方、操作系统发行版、主机商或托管平台给出的修复版本执行；不同平台可能通过软件包更新、控制面板切换或容器镜像更新提供补丁。

1. 自建服务器更新 PHP 软件包。按照服务器操作系统和维护方提供的安全更新方式安装对应修复版本，同时确认网站使用的 PHP 处理服务已经更新。
2. 重启相关 PHP 服务。如果网站使用 PHP-FPM，升级后通常还需要按服务器架构重启或重新加载 PHP-FPM；Apache、容器或其他 Web 组件也要遵循对应平台的发布流程。不要只更新磁盘上的文件，却让旧进程继续处理外部请求。
3. 托管平台切换运行时版本。虚拟主机、云平台或网站托管服务通常在控制面板中提供 PHP 版本选择。切换前确认平台已经提供包含此次安全修复的版本，并查看是否有多个站点、应用池或容器需要分别设置。
4. 先分批处理，再覆盖全部节点。拥有多台服务器时，可以先升级并观察一部分节点，再按照同一流程处理其余节点。最终必须确保所有接收互联网流量的应用节点都不再运行易受影响的版本，不能只升级负载均衡器前面的其中一台服务器。
5. 升级后重新确认实际 Web 版本。不要只再次运行 php -v。应从主机控制面板、PHP-FPM 配置、应用运行信息或平台提供的实例状态中确认网站实际使用的版本，并查看 PHP、Web 服务器和 WordPress 日志。

材料没有表明 WordPress、主题或插件的更新可以替代 PHP 补丁。相关组件仍应保持更新，但它们与 PHP 运行时属于不同层级：前者是网站应用代码，后者是执行这些代码的服务器环境。

如果暂时无法升级，应该怎么做

PHP 开发者表示，安装修复是解决问题的唯一缓解方式。欧盟计算机应急响应团队和英国国家网络安全中心都建议，无法立即修复的平台应先将面向互联网的应用与公共网络隔离，必要时临时下线。这里的重点是减少外部攻击面，而不是把网站后台换一个地址就视为已经修复。

GrapheneOS 曾因担心针对该问题的概念验证利用代码正在开发，临时关闭其用户讨论论坛。安全研究机构 Sansec 预计，补丁发布后可能在 15 分钟内出现大规模攻击；Cloudflare 首席技术官也表示已经看到针对 PHP 网站的早期攻击，并临时调整防火墙规则作为过渡措施。

防火墙、WAF 或访问限制可以在升级窗口期间降低风险，但不能替代 PHP 修复。若当前无法安装补丁，应至少暂时隔离面向互联网的应用、限制不必要的入口，并在无法可靠隔离时考虑下线服务器；PHP 开发者称，在无法修复的情况下关闭服务器可能是更稳妥的选择。

升级完成后还要检查什么

完成 PHP 切换后，应继续观察站点是否出现 5xx 错误、白屏、后台无法登录、插件报错、文件上传失败、定时任务中断或支付流程异常。确认网站正常后，再更新仍受维护的主题、插件和扩展；对于无法兼容且非必要的组件，应停用或移除，不要为了恢复功能长期降级回存在漏洞的 PHP 版本。

如果升级前网站曾长期暴露在互联网，或者已经出现异常访问、页面被篡改、陌生管理员账户或不明文件，升级 PHP 只能修复运行时漏洞，不能自动清除此前可能留下的后门。此时还应检查管理员账户、网站文件、异常定时任务、PHP 配置和访问日志，并根据站点的事件响应流程进一步处理。

对于暂时回退到旧版本的情况，应把它视为短期应急措施，同时限制后台入口、缩小网站暴露面，并尽快恢复到包含安全修复的 PHP 版本。真正完成处置的标准，不是 WordPress 后台显示更新成功，而是每个实际处理 Web 请求的 PHP 环境都已经升级并经过验证。

原始来源： https://www.theverge.com/tech/1015257/php-vulnerability-patch-website-security-wordpress