PHP 核心两个严重漏洞紧急修复：WordPress 站点如何自查与打补丁

PHP 官方发布两个可让攻击者在未登录状态下执行代码的严重漏洞修复，所有对外提供网页请求的 PHP 环境都受影响，Apache 的 mod_php 模式风险最高。文章给出了具体版本号、WordPress 后台自查路径，以及无法立即打补丁时的临时处置方式。

漏洞影响范围与修复版本

• 修复版本为 PHP 8.5.12、8.4.27、8.3.36、8.2.35，官方表示没有能完全替代升级的临时规避方案。
• 所有处理网站请求的 PHP 安装都处于风险中，用 mod_php 把 PHP 直接跑在 Apache 里的服务器风险最高，攻击可在站点自身代码执行前发生。
• PHP 8.1 及更早版本已进入 EOL，不再获得常规更新；官方仅为 7.4、8.0、8.1 提供了有限的源码级修复，供自行编译 PHP 的团队使用，这不等于恢复长期支持。

WordPress 站点先确认 PHP 版本

• 更新 WordPress 本体或插件不会更新 PHP，必须由主机商安装修复版本。
• 在 WordPress 后台打开 Tools > Site Health，进入 Info 面板，展开 Server 一项即可看到当前 PHP 版本。
• 如果主机面板（如 cPanel）允许自行切换 PHP 版本，切换后要确认所选版本已包含本次补丁。
• 使用 8.1 及更早版本时，先备份站点，再安排升级，同时向主机商确认能否先应用厂商提供的临时修复。

无法立即打补丁时的临时处置

• 可与主机商讨论先把受影响站点下线，直到完成更新。
• WAF（如 Cloudflare）能拦截部分攻击尝试，但不能替代安装修复。
• 若使用防火墙，要确保所有访问都经过它；攻击者若能直连源站服务器，就能绕过检查。
• 下线打补丁期间，让主机商返回带 HTTP 503（Service Unavailable）的维护页，这是 Google 推荐的做法，可由 Web 服务器或 CDN 直接提供，不依赖 PHP。

打补丁之后还要查是否已被入侵

• 补丁只能堵住入口，不能清除已有的入侵。
• 检查是否存在 web shell（给攻击者留后门的恶意脚本）、陌生的管理员账号、以及异常的 PHP 文件改动。
• 让技术团队审计代码并监控可疑活动，同时和主机商明确：紧急补丁由谁打、站点无法保护时由谁负责下线。

为什么这类事件会越来越频繁

• 本次补丁发布前已有攻击工具在流传，说明攻击者的节奏可能快于厂商出修复的速度。
• 作者认为，去掉安全限制的模型加上蒸馏训练，会让更强的攻击能力流向恶意使用者，严重漏洞被发现得更频繁、留给站长的响应窗口更短。
• 站点被攻破不仅泄露客户数据，也会损害搜索可见性，因此应急响应流程要提前约定好。