WordPress 网站紧急安全提醒：PHP 爆出两个严重 RCE 漏洞，宝塔用户应立即检查升级（2026）

一、2026 年 10 月，PHP 爆出两个严重安全漏洞

2026 年 10 月 21 日，PHP 官方发布紧急安全更新，修复了两个可能导致远程代码执行（RCE）的严重安全漏洞。

本次漏洞涉及 PHP 语言运行时本身，并非某个 WordPress 插件或主题的独立漏洞。由于 WordPress 使用 PHP 处理网站请求，因此运行在受影响 PHP 版本上的 WordPress 网站也需要及时检查和修复。

本次漏洞的编号为：

CVE-2026-109618： 与内存耗尽情况下的内存损坏有关。
CVE-2026-109619： 与错误处理过程中残留的内存状态有关，可能引发释放后使用（Use-After-Free）问题。

PHP 官方将两个漏洞的严重程度评为 CVSS v4.0 9.2/10，并发布了对应的安全修复版本。

官方公告：

PHP 官方网站：https://www.php.net/
WordPress 官方安全提醒：https://wordpress.org/news/2026/10/critical-php-security-release/

需要明确的是，这不是 WordPress 核心代码突然出现了同一漏洞，而是 WordPress 所依赖的 PHP 运行环境存在安全风险。即使 WordPress 核心、主题和插件全部更新到最新版本，只要 PHP 运行环境仍然存在未修复的漏洞，网站就依然面临风险。

二、PHP 漏洞对 WordPress 网站有什么影响？

WordPress 网站的运行涉及多个层级，包括 Web 服务器、PHP 运行环境、WordPress 核心、主题、插件和数据库。

当 PHP 运行时本身存在严重安全漏洞时，风险可能超出某个插件或主题的影响范围。

1. 远程代码执行风险

远程代码执行（Remote Code Execution，简称 RCE）是 Web 安全领域中风险较高的漏洞类型。

在满足特定攻击条件时，攻击者可能通过构造恶意请求触发漏洞，在服务器上执行代码。

如果攻击成功，可能产生以下后果：

执行恶意脚本或命令。
修改网站文件，植入恶意 PHP 文件。
窃取数据库配置、网站业务数据等敏感信息。
创建后门，维持对网站的访问。
利用服务器权限和环境配置，尝试进一步扩大影响范围。

实际影响取决于 PHP 的运行方式、进程权限、服务器隔离措施以及具体攻击路径。漏洞存在不代表网站已经被入侵，也不意味着攻击者一定能够获得服务器最高权限。

2. WordPress 企业网站同样需要重视

很多站长认为，自己的 WordPress 网站只是企业展示站，没有会员系统，也没有在线支付，因此安全风险较低。

这种判断并不准确。

企业网站通常会安装表单插件、文件上传组件、SEO 插件、缓存插件及其他扩展。网站即使没有开放用户注册，也需要通过 PHP 处理前台请求和后台操作。

对于使用宝塔面板、Nginx、PHP-FPM 部署 WordPress 的网站，不能因为没有使用 Apache，就直接认定不受影响。PHP 官方已将 PHP-FPM 等 Web 请求处理环境列入受影响范围。

3. 搜索引擎排名和网站信誉也可能受到影响

如果网站遭到入侵，攻击者可能植入垃圾页面、恶意跳转或隐藏链接。

这些行为可能进一步影响：

百度、必应、Google 等搜索引擎的索引质量。
网站在搜索结果中的表现。
用户访问网站时的安全体验。
企业品牌信誉及客户信任。
网站恢复、排查和后续维护成本。

因此，PHP 安全更新不只是服务器维护工作，也是 WordPress 网站长期运营和 SEO 风险控制的一部分。

三、哪些 PHP 版本受到影响？应该升级到哪个版本？

根据 PHP 官方 2026 年 10 月 21 日发布的安全更新，以下版本已经包含本次漏洞的修复。

PHP 分支	修复版本	建议
PHP 8.2.x	8.2.35	升级至 8.2.35 或更高的安全修复版本
PHP 8.3.x	8.3.36	升级至 8.3.36 或更高的安全修复版本
PHP 8.4.x	8.4.27	升级至 8.4.27 或更高的安全修复版本
PHP 8.5.x	8.5.12	升级至 8.5.12 或更高的安全修复版本

注意：这里的“更高版本”是指同一分支中包含相应安全修复的后续正式版本，不包括尚未正式发布的测试版本。

以下几个版本尤其值得注意：

PHP 8.2.31：低于修复版本，存在风险。
PHP 8.2.34：虽然此前已经发布过安全更新，但仍低于本次修复版本。
PHP 8.5.2：同样低于 PHP 8.5.12，不能认为已经修复本次漏洞。

判断 PHP 是否安全，不能只看它是不是 PHP 8.2 或 PHP 8.5，而要核对具体版本号及其安全补丁状态。

官方版本信息：

https://www.php.net/

PHP 8.2 还值得继续使用吗？

截至本文发布时，PHP 8.2 的官方安全支持计划将于 2026 年 12 月 31 日结束。

这意味着，即使将 PHP 8.2 升级至 8.2.35，也需要提前规划后续的 PHP 版本升级。

对于运行稳定的 WordPress 企业网站，可以先安装当前分支的安全修复版本，再安排兼容性测试，逐步迁移到仍受官方支持的 PHP 分支。

不建议仅仅为了追求更高的版本号，就直接将重要的生产网站切换到另一个 PHP 大版本。

四、宝塔面板只能更新到 PHP 8.2.34，应该怎么办？

这是部分 WordPress 站长可能遇到的实际问题。

例如，宝塔面板中的 PHP 管理界面显示：

当前版本：PHP 8.2.31。
面板显示的最新版：PHP 8.2.34。
官方最新修复版本：PHP 8.2.35。

此时，即使点击“立即更新”，也只能更新到面板当前提供的版本，不能保证修复本次漏洞。

第一步：确认 WordPress 网站实际使用的 PHP 版本

进入 WordPress 后台：

工具 → 站点健康 → 信息 → 服务器

查看 PHP 版本。

也可以登录宝塔面板，在网站设置中查看该网站绑定的 PHP 版本。

需要注意，服务器命令行中的 php -v 显示的是命令行 PHP 版本，不一定与网站实际使用的 PHP-FPM 版本相同。

因此，排查时应以网站实际运行的 PHP 版本为准。

第二步：刷新宝塔软件列表

进入宝塔面板的“软件商店”，找到已安装的 PHP 8.2，查看是否可以更新至 8.2.35。

如果仍然只显示 8.2.34，不要反复点击更新，也不要直接删除原来的 PHP 安装目录。

建议依次检查：

宝塔面板版本是否过旧。
软件列表和软件源是否已经同步。
当前 PHP 是快速安装还是编译安装。
宝塔官方是否已经提供对应的安全修复包。
当前服务器系统及架构是否支持目标版本。

第三步：优先使用可信的软件源或官方修复包

如果宝塔尚未提供 8.2.35，可以等待其安全更新包同步，或按照 PHP 官方及服务器发行商提供的可靠升级方案处理。

对于重要生产站点，不建议直接从第三方网站下载来历不明的 PHP 二进制文件，也不建议在没有备份的情况下手动替换 PHP 运行文件。

如果需要手动编译或更换 PHP，应同时考虑 PHP 扩展、编译参数、PHP-FPM 配置、文件权限和服务启动方式。

第四步：重启并确认 PHP-FPM 已加载修复版本

完成升级后，应根据实际安装方式重启对应的 PHP-FPM 服务。

随后重新检查网站实际使用的 PHP 版本，并确认服务运行正常。

仅仅下载或安装了新的 PHP 文件，并不一定代表正在处理网站请求的进程已经加载了修复版本。

五、WordPress 网站升级 PHP 前，需要做哪些准备？

安全更新应尽快执行，但不能忽视生产环境的稳定性。

特别是使用 Elementor、WooCommerce、ACF、TranslatePress 等扩展的 WordPress 网站，建议先完成以下准备工作。

1. 备份网站文件和数据库

至少准备：

WordPress 网站文件备份。
MySQL 或 MariaDB 数据库备份。
当前 PHP 配置备份。
PHP 扩展及相关配置记录。
当前网站绑定的 PHP 版本信息。

对于重要的电商网站，最好先在测试环境中验证升级结果。

2. 记录 PHP 扩展

检查当前 PHP 使用的扩展，例如：

mysqli 或 pdo_mysql
curl
mbstring
openssl
gd 或 imagick
intl
zip
opcache
redis

实际需要哪些扩展，取决于网站、主题和插件的功能。

更换 PHP 版本时，不应只关注 PHP 主版本号，还需要确保所需扩展已经安装并正确启用。

3. 检查 Elementor 和 WooCommerce

对于使用 Elementor 的企业网站，升级后建议检查：

Elementor 编辑器能否正常打开。
页面布局、响应式样式和动态内容是否正常。
循环列表、轮播组件和弹窗是否正常。
表单能否提交并正确发送通知。

对于 WooCommerce 网站，还应检查：

产品详情页及产品图片。
商品分类和搜索。
购物车、结账和账户页面。
支付网关及回调处理。
优惠券、订单状态和邮件通知。
后台订单管理及定时任务。

如果网站依赖第三方插件，建议在升级前核实插件兼容性。安全修复版本通常应优先安装，但跨 PHP 大版本迁移需要额外的兼容性测试。

六、PHP 升级后，还需要检查网站是否被入侵吗？

需要。

安全更新解决的是漏洞本身，不能自动清除攻击者此前可能植入的恶意文件或后门。

如果网站曾经运行在受影响的 PHP 版本上，应结合服务器日志、文件变更记录和 WordPress 安全状态进行检查。

建议重点检查以下内容

1. Nginx 访问日志

查看异常请求、异常请求频率、可疑参数和异常状态码。

对于使用宝塔的站点，可以先检查对应网站的访问日志和错误日志。

2. WordPress 文件变更

重点关注近期新增或被修改的 PHP 文件，特别是：

wp-content/uploads/ 中不符合预期的 PHP 文件。
主题和插件目录中近期出现的异常文件。
WordPress 根目录下不明来源的文件。
与官方文件或原始部署包不一致的代码。

注意：文件修改时间异常只是排查线索，不能单独作为入侵结论。

3. WordPress 管理员账户

检查是否出现未知管理员账户、异常登录记录或不符合预期的权限变更。

4. 数据库和计划任务

检查异常的定时任务、可疑选项、异常跳转代码，以及被修改的网站设置。

5. 文件完整性和服务器权限

可以通过可信的恶意软件扫描工具、WordPress 核心文件校验以及主题插件来源核验等方法辅助排查。

如果发现明确的入侵迹象，应先保留证据、隔离风险，再进行清理和恢复。不要简单地认为升级 PHP 后网站就一定恢复安全。

七、为什么不能只依赖 WordPress 插件更新？

WordPress 安全维护需要多个层级共同配合。

安全层级	主要工作
服务器操作系统	安装系统安全补丁，维护运行环境
PHP 运行环境	及时升级 PHP 安全修复版本
Nginx 和其他服务	更新软件并合理配置访问限制
WordPress 核心	安装官方安全更新
主题与插件	更新到可信的修复版本，清理不再使用的扩展
账号和权限	使用强密码、最小权限和必要的多因素认证
备份与监控	定期备份，监控异常访问及文件变化