WordPress 在 2026 年 9 月 22 日发布 7.1.2，官方公告对它的定性只有一句：这是一次修复「严重（critical）级别安全漏洞」的安全版本。对应的 GitHub 安全公告是 GHSA-7hp8-65ch-5whp，漏洞编号 CVE-2026-87902，CVSS v4 评分 9.2。三天后的 9 月 25 日，美国 CISA 把它加入「已知被利用漏洞」目录，依据是「有证据显示正在被实际利用」，给联邦机构的处置期限是 9 月 28 日。
漏洞是什么，什么条件下能执行代码
官方的描述是：未经身份验证的攻击者，在特定条件下可以让页面模板解析去包含当前主题目录之外、一个由攻击者指定的本地可读 PHP 文件；如果服务器环境和当前主题的前提同时满足，就能导致远程代码执行。公告列出的前提有两类：
- 主题条件：当前使用的子主题或父主题里，有一个名字以
page-开头的顶层目录（例如page-templates）。公告点名的有老的 Twenty Twelve、Twenty Fourteen，以及 Neve、Hestia、Sydney 等常用第三方主题。 - 服务器条件：服务器上存在一个 Web 账户可读、可被利用的 PHP 文件。公告举的例子是
pearcmd.php：当register_argc_argv为 On 时可以借它执行代码。公告写明官方 Docker php 镜像受影响，使用 PHP 8.5 之前版本的默认 cPanel 配置也受影响。
受影响和已修复的版本
受影响范围是 4.7.0 到 7.1.1 的各个分支。修复已回移植到所有仍接收安全修复的分支：7.1.2、7.0.6、6.9.9……一直到 4.7.37。也就是说，不管你停在哪个大版本，都有对应的修复版，关键是确认它真的装上了。
前后还有两次安全更新
这次不是孤立的一次。9 月 17 日的 7.1.1 带了 11 个安全修复，10 月 6 日的 7.1.3 又修了 7 个安全问题。三份公告都写着：支持后台自动更新的站点会自动开始更新。但在自己管理的服务器上，自动更新可能因为文件权限或配置被关掉，所以不要默认它已经更新过了。
在 VPS 上这样检查
- 看版本：后台「仪表盘 → 更新」，或在服务器上用 WP-CLI 执行
wp core version。低于你所在分支的修复版（例如 7.1 分支低于 7.1.2）就立即更新；7.1.3 已经发布，7.1 分支直接升到 7.1.3 更省事。 - 看主题目录：在
wp-content/themes/下，检查当前主题（以及它的父主题）根目录里有没有以page-开头的目录。 - 看 PHP 设置：确认网站实际使用的 PHP（FPM 或 Apache 模块，不是命令行）里
register_argc_argv的取值，以及服务器上有没有用不到的pearcmd.php。用官方 Docker php 镜像跑站的尤其要查。 - 怀疑已被利用：9 月 22 日之后才更新的站点，最好按 VPS 被入侵后的排查清单查一遍，看有没有陌生的 PHP 文件、计划任务和管理员账号。
WordPress 的基础搭建见在 VPS 上搭建 WordPress 网站；更新前先按 VPS 数据备份方案做一次备份；顺手把 ufw 防火墙和 SSH 密钥登录也检查一遍。