WordPress 于 2026 年 7 月紧急发布 7.0.2，修复两项可被组合利用的核心软件漏洞，并在可行范围内启用强制自动更新。攻击者已经开始针对仍运行 6.9.0—6.9.4、7.0.0—7.0.1 的网站发动攻击。
这起事件最需要重视的，不是“约 9000 万个网站”这一醒目估算，而是漏洞已经越过概念验证阶段，进入实战利用。没有及时更新的站点应立即核验版本；但也不能反过来断言，所有旧版本网站都已暴露，或都能被无条件接管。
WordPress 7.0.2紧急上线，两项核心漏洞已被组合利用
现有材料显示，完整攻击需要串联两项漏洞。在满足相应触发条件、两步利用均成功的情况下，攻击者可能远程取得网站的完全控制权。其中一项漏洞被安全公司 Searchlight Cyber 命名为 WP2Shell。
“完全控制”通常意味着攻击者可能写入恶意文件、创建管理员账号、修改页面、窃取数据库内容，或者把网站用作后续攻击的跳板。但这描述的是成功利用后的权限上限，并不代表每个受影响版本都会自动落入同一结果。
目前公开信息仍有几处关键空白：现有报道没有给出可供独立核验的 CVE 编号、完整触发条件、是否需要预先认证，以及统一的入侵指标。站点管理员不能只凭版本号判断“已经被黑”，也不应因为暂时没有页面异常就认定安全。
WordPress.org 负责核心软件发布与安全更新；Automattic 是经营 WordPress.com、WooCommerce 等业务的商业公司；真正执行更新、备份和日志留存的，仍是各网站运营者或托管服务商。原报道只称前两者未及时回应，不能据此混淆三方的责任边界。
这件事的严重性主要来自两个事实：漏洞位于 WordPress 核心，理论影响面比单个插件更广；攻击已经发生，补丁窗口正在收窄。处置优先级因此很明确——先确认站点是否真正升级到 7.0.2，再排查更新前是否已经遭到入侵。
“约9000万”是外推结果，不能当成受害网站数量
“约 9000 万个网站面临风险”的说法，来自约 4200 个网站样本中“低于 15%”的版本分布，再结合对 WordPress 全球安装规模的假设进行外推。这个数字至少包含两层不确定性：样本是否能代表全球站点，以及外推采用了多大的安装基数。
WordPress 官方的版本占比也不能直接换算成当前未修补网站数量。一个域名是否仍在线、是否启用自动更新、是否经过托管平台统一升级，都会改变实际暴露面。因此，9000 万既不是已确认受害数，也不是经过扫描确认的实时暴露数。
| 口径 | 能说明什么 | 不能说明什么 |
|---|---|---|
| 约 4200 个网站样本 | 样本内旧版本所占比例 | 全球 WordPress 站点的准确版本分布 |
| “低于 15%” | 样本观察到的比例上限 | 仍可被成功利用的站点比例 |
| 约 9000 万站点 | 按特定全球基数得出的估算 | 已遭入侵或仍未安装补丁的网站数量 |
| 官方版本统计 | 不同 WordPress 版本的大致分布 | 每个站点当前的补丁、WAF 和托管状态 |
实际风险还会被几道防线压低。WordPress 已在可行范围内推送强制自动更新；部分托管服务商会代替客户升级核心；Cloudflare 等服务及网站应用防火墙，也可能通过规则拦截已知攻击请求。
这些防线只能缩小暴露面，不能替代核验。自动更新可能因文件权限、磁盘空间、定制代码或维护配置失败；防火墙规则也可能覆盖不全。更重要的是，如果攻击发生在升级前，安装 7.0.2 只能堵住入口，不能自动清除已经写入的后门。
与 WordPress 过去更常见的插件漏洞相比，这次的差别很实际：
| 对比项 | 常见插件漏洞 | 本次核心漏洞 |
|---|---|---|
| 影响对象 | 安装特定插件及特定版本的网站 | 运行相关 WordPress 核心版本的网站 |
| 理论覆盖面 | 受插件安装量限制 | 覆盖面通常更广 |
| 更新责任 | 插件开发者、站长和托管方共同承担 | WordPress.org 发布修复，站长或托管方落实 |
| 缓解条件 | 停用插件、升级或添加 WAF 规则 | 升级至 7.0.2，并结合 WAF 与入侵排查 |
| 现实限制 | 冷门插件可能长期无人维护 | 自动更新能更快压低暴露面，但无法保证全部成功 |
核心漏洞不等于“互联网大面积失守”，却让中小站长更难置身事外。插件漏洞有时可以通过“我没装这个插件”排除风险，核心版本问题则必须查版本、查更新结果，不能靠安装清单侥幸判断。
站长要查版本，托管商要查整批资产和更新失败项
自建 WordPress 网站的企业和个人站长，最现实的动作不是重新建站，也不是立即采购一套复杂安全产品，而是完成版本核验和基础取证。
可以按以下顺序处理：
- 在 WordPress 后台进入“仪表盘—更新”，确认当前核心版本是否为 7.0.2，不要只看“已启用自动更新”的开关。
- 能使用 WP-CLI 的站点，可运行
wp core version核验版本；确认备份可用后，再按内部变更流程更新。 - 检查近期新增的管理员账号、异常计划任务，以及
wp-content/uploads、mu-plugins、插件和主题目录中近期出现或修改的 PHP 文件。 - 查看 Web 服务器访问日志、WordPress 安全日志和主机控制面板记录，重点核对升级前后的异常请求、未知登录和文件写入。
- 暂时无法升级时，启用或加强 WAF 拦截，并限制后台入口；这只是过渡措施，不能代替安装补丁。
如果已经发现陌生管理员、恶意跳转、异常 PHP 文件或不明外联，不要急着覆盖文件后继续营业。更稳妥的顺序是先隔离站点，保存文件系统、数据库和日志快照，再轮换 WordPress 管理员、数据库、主机面板及相关 API 密钥。恢复时应使用确认未受污染的备份，并重新安装可信来源的核心、插件和主题。
负责批量托管和运维的服务商面对的是另一类成本。单站检查后台已经不够，需要先拉出完整资产清单，按版本、自动更新状态和公网暴露情况排序；随后找出升级失败项，并为高风险客户临时增加 WAF 规则。安全预算也应优先投向集中版本管理、日志留存和可验证备份，而不是只买告警服务。
接下来真正能校准风险的变量有三个：WordPress 是否发布更完整的漏洞公告和 CVE 信息，安全机构能否公布可复核的攻击时间线与入侵指标，以及强制自动更新的实际成功率。在这些数据出现前，“9000 万”适合用来描述潜在量级，不适合写进受害统计。