事件概要：WordPress 7.1.3 发布，修复 7 个安全漏洞
2026 年 10 月 6 日，WordPress 发布 7.1.3 维护与安全版本，修复核心中的 7 个安全漏洞并解决 4 个程序 Bug。官方明确建议立即更新。
这次发布最受关注的一点，是漏洞报告来源的变化：7 个漏洞中有 3 个由 AI 公司 Anthropic 报告，Trail of Bits 与 Patchstack 各报告 1 个，1 个由三名独立研究者提交，1 个由 WordPress 安全团队自行发现。
值得注意的细节：Anthropic 此前也报告过 7.1.1 里 11 个漏洞中的 2 个。AI 厂商连续参与到核心漏洞的发现流程中，这已经不是偶发事件了。
本次发布由 Jake Spurlock 主导。安全修复正在向后移植到仍可接收安全更新的分支（目前可追溯至 4.7），但官方同时提醒：只有最新版本才处于积极维护状态。
最重要的一条：唯一「无需认证」的漏洞被各家媒体漏掉了
IT之家那篇报道挑了三个漏洞展开，但漏掉了本次发布中唯一被官方明确标注为「未经认证即可利用」（Unauthenticated）的漏洞——这恰恰是普通站长最该先看的一条。
| # | 漏洞 | 利用前提 | 报告者 |
|---|---|---|---|
| 1 | 评论管理页面的存储型 XSS（经由待审评论） | 无需账号提交 + 管理员/编辑点击 | Thomas Chauchefoin（Trail of Bits） |
| 2 | 私密与未发布文章的评论泄露 | 无需任何认证 | Ananda Dhakal（Patchstack） |
| 3 | WP_Http::make_absolute_url() 拒绝服务 |
投稿者（Contributor）及以上 | Anthropic |
| 4 | WXR 导出中的二阶 SQL 注入 | 管理员执行导出 | Anthropic |
| 5 | 作者（Author）角色越权置顶文章 | 作者及以上 | Anthropic |
| 6 | Imgur 嵌入存在 XSS | 投稿者及以上 + 有人浏览 | Zhengyu Liu、Jingcheng Yang、Gavin Zhong |
| 7 | {status}_{type} 钩子动作名冲突 |
插件传入未注册的 status/type | Alex Concha（WP 安全团队） |
漏洞 2 详解：私密文章的评论，任何人可读
这条是本次唯一不需要任何账号、不需要受害者配合的漏洞，也是最容易被忽视的一条。
技术原理：WordPress 的每篇文章都有一个独立的评论 Feed。当系统为单篇文章构建这个 Feed 时，它先去查询了评论，然后才检查访客有没有权限看这篇文章。权限检查这一步确实起作用了——它把「文章」清掉了，但已经加载好的评论没有被清掉。而评论 Feed 在文章不可见时不会返回 404，于是直接把这些评论打印了出来。
修复方式很朴素：把评论查询挪到权限检查之后。访客看不到文章，评论就根本不会被查询。代码上只是把一个 37 行的代码块整体下移，一行都没改。
实际影响场景：这个漏洞最要命的不是新站，而是「先公开、后转私密」的内容——
- 会员专属文章（先发出来攒评论，再改成仅会员可见）
- 撤回的公告（发布后收集了反馈，随后下架）
- 客户页面（临时下线，但此前已有访客评论）
在这些场景下，一个未登录的访客可以通过评论 Feed 读到这些文章的已审核评论，包括评论者姓名。需要说明的是，该 Feed 只选取已审核通过的评论，编辑备注（Notes）不在其中。
关于「评论 XSS」的版本范围，有个细节要留意
评论管理页这条 XSS，机制是这样的：后台「帮助」标签的点击处理器把链接的 href 直接交给了 jQuery 的 $()，而 $() 会把任何看起来像 HTML 的字符串当作 HTML 构建出来。藏在待审评论里的链接，可以塞进这样一段 href。
触发链条是：陌生人提交一条评论（首次评论默认进待审队列，无需账号）→ 管理员或编辑在后台打开评论管理页并点击那个链接 → 脚本在管理员浏览器里执行。
根据 Patchstack 的分析，该攻击路径影响 7.1.0 至 7.1.2。原因是访客评论在 7.1.0 之前无法携带 class 属性，而 7.1.0 为 @提及功能增加了 span class 支持。7.1.3 把 $() 换成了只读取选择器的 .find()。
三个漏洞的「坑」在哪儿：看代码比看描述更有用
这次修复有个共同特点——都不是「写错了」，而是「写漏了」。看这几个案例的成因，比看漏洞名称本身更有参考价值。
| 漏洞 | 真正的成因 | 修复方式 |
|---|---|---|
拒绝服务make_absolute_url() |
一个用来折叠 segment/../ 路径对的循环，遇到 a//../b 这类相对路径时永远不会退出——正则匹配不到任何东西，路径也始终不变，于是死循环 |
当某轮替换「什么都没替换掉」时直接跳出循环。触发路径是投稿者通过区块编辑器的链接预览指向一个自己控制的页面 |
| 二阶 SQL 注入 WXR 导出 |
导出功能从 _thumbnail_id 元数据里直接取特色图片 ID，没有确认它是整数，就拼进了查询字符串 |
在三处加上 absint()。「二阶」的含义是：恶意输入先被存进数据库，等到有人执行导出时才成为威胁。该代码自 6.5.0 起存在，且只在导出单一内容类型时才会走到 |
| 越权置顶 作者角色 |
REST API 只在用户同时缺少 edit_others_posts 和 publish_posts 两个权限时才拒绝置顶请求。作者角色拥有 publish_posts，因此顺利通过 |
把判断条件从 &&（与）改成 ||（或）。置顶文章按默认角色划分本应是编辑的职责 |
这三个案例合起来说明一件事：权限判断写成「与」还是「或」、循环有没有出口、拼 SQL 前有没有强制类型转换——这些最基础的编码细节，才是核心系统出漏洞的高频位置。而第一个和第二个漏洞都由 Anthropic 报告，也从侧面说明自动化/LLM 辅助的代码审计，在识别这类「边界与类型」问题上确实有效。
两个必须注意的附带影响
第一：Imgur 已从可信 oEmbed 提供方中移除
WordPress 会把来自不可信 oEmbed 提供方的 HTML 过滤成沙箱化的 iframe。而 Imgur 原本在可信名单上，会跳过这层过滤——于是 Imgur API 返回的内容被直接输出到页面上，其中包含上传者自己填写的图片/相册文本，攻击者可控的内容就未经过滤地落到了页面上。
本次修复直接把 Imgur 从可信提供方名单中移除。也就是说，以后 Imgur 链接不再以「受信任内容」的方式自动嵌入。
这是一个容易踩的坑：更新核心并不会清除已缓存的 oEmbed 内容（即
_oembed_*文章元数据和oembed_cache文章）。也就是说，此前嵌入的恶意内容仍会继续渲染。如果你站内有历史 Imgur 嵌入，更新后务必清一次缓存并复查这些页面的实际渲染效果——但别盲目删除正常内容，逐篇确认后再决定是替换为普通链接还是改用安全的上传流程。
第二：钩子名冲突，可能让插件误以为「文章被删了」
WordPress 会用文章自身的数据拼接动作名：文章状态变化时触发 ${new_status}_{$post_type}，比如发布 post 会触发 publish_post。
问题在于，不少互不相关的动作遵循同一套命名规则——delete_post（文章被删除时触发）、comment_post（新增评论时触发）。7.1.2 在拼接名字前没有检查状态和文章类型是否已注册：一篇以 delete 为状态、post 为类型保存的文章，会触发 delete_post，与真实删除触发的是同一个动作，所有挂在这个钩子上的回调都会按「文章刚被删除」来执行。7.1.3 收紧了触发条件，只在状态与类型均已注册时才触发。
这条对站长基本是「无感」的，主要影响开发者与插件作者——如果你写的插件会把未经校验的 status/type 直接传进 wp_insert_post()，需要检查一下。
和上一次别搞混：7.1.2 才是那个「紧急」版本
这里有个非常容易混淆的点，值得单独说清楚，因为不少第三方标题把两次发布混为一谈。
| 版本 | 发布日 | 性质 | 紧急程度 |
|---|---|---|---|
| 7.1.2 | 2026 年 9 月 22 日 | 修复 1 个严重级别（Critical）漏洞（CVE-2026-87902）：未认证访客可触发本地文件包含，在特定 PHP 配置下升级为远程代码执行 | 最高，官方曾对受影响版本强制开启自动更新 |
| 7.1.3 | 2026 年 10 月 6 日 | 7 个安全修复 + 4 个 Bug 修复，官方未将其中的任何一条标注为新的大规模严重漏洞 | 建议尽快，但不是「立即中断一切」的级别 |
需要核对的是：7.1.3 的 7 个漏洞中，没有任何一个被官方标为「严重」（Critical）。但正如上面分析的，其中两条从「无需任何权限」的陌生人开始，所以开放评论的站点优先级最高。多作者站点、会员站、电商站则需要重点核查投稿者（Contributor）与作者（Author）账号，因为好几个修复都跟这些角色的能力边界有关。
站长现在该做什么
第一步：确认版本并更新
后台 仪表盘 → 更新，点击「立即更新」即可。开启了自动后台更新的站点会自动升级。命令行环境可以直接用：
# 查看当前版本
wp core version
# 更新核心
wp core update
# 更新数据库（如提示需要）
wp core update-db
# 确认已到目标版本
wp core version宝塔面板用户路径：网站 → 找到对应站点 → 打开网站根目录 → 确认 wp-includes/version.php 中的 $wp_version。
顺带一提：本站已完成更新，检测到的生成器版本为 WordPress 7.1.3。你可以用下面的方法自查——浏览器打开首页，右键「查看网页源代码」，搜索
generator，即可看到当前版本号。这是最快的免登录自查方式。
第二步：清缓存（这次不是可选项）
因为 Imgur 那条漏洞的修复不会自动清除已缓存的 oEmbed 内容，所以更新后必须清一次缓存：WordPress 对象缓存、页面缓存、以及 CDN 缓存都要清。用 CDN 的站点别漏了回源缓存。
第三步：审一遍账号权限
本次 7 个漏洞里有 3 个与「投稿者 / 作者」角色相关。建议去「用户」列表核对一遍：谁持有 Contributor 或更高的角色？这些账号是否都还有存在的必要？离职员、外部投稿人、测试账号，是最该清理的一批。角色权限越大，能走到的攻击路径越多。
第四步：复查评论相关设置
本次有两条漏洞与评论直接相关。如果你的站点根本不需要评论，直接在「设置 → 讨论」里关闭评论，等于一次性消除了两条攻击路径。如果必须开放评论，请确认待审评论的审核流程规范，且不要把「点开待审评论里的链接」当作家常便饭。
第五步：顺便检查异常痕迹
更新完成不等于没事。建议顺手看一眼：最近有没有陌生的管理员账号被创建、文章是否被意外改为私密、评论里有没有可疑链接、以及站点是否被注入了垃圾页面或跳转。
为什么说这是「SEO 事故」而不只是安全问题
这几条漏洞如果被利用，落到搜索表现上的后果是直接的，值得单独提醒：
- 注入垃圾页面 → 索引污染，站点被判定为低质；
- 篡改内链、加跳转 → 被判作弊，排名下滑；
- 修改 canonical 标签 → 权重被引走，收录异常；
- 泄露私密内容 → 本该只对会员或内部可见的内容被搜索引擎抓到。
核心程序的安全维护，本质上属于技术 SEO 的日常动作，而不是一个可以外包给「安全团队」的独立事项。等到排名掉了再排查，成本要高得多。
小结
三条结论：
- 7.1.3 该更，但不是 7.1.2 那种「立刻停下手头所有事」的级别。7.1.2 修的是未认证的 LFI 可升级为 RCE，那才是真正紧急的那个；
- 本次最该优先处理的是两条「从陌生人开始」的漏洞——私密文章评论泄露（完全无需认证）和评论管理页存储型 XSS（无需账号提交 + 管理员点击）。开放评论的站点优先级最高；
- 更新完别忘了清缓存。Imgur 那条修复不会自动清除历史缓存，老嵌入可能仍在渲染。
另外提一句：本次 7 个漏洞中 3 个由 Anthropic 报告，且其报告的拒绝服务、SQL 注入、越权三条，都是典型的「边界条件与类型校验」问题。这类问题的特征是逻辑上说得通、语法上挑不出错、但边界上就是个洞——恰好是自动化代码审计比人工更容易覆盖的区域。这个趋势值得做安全的人持续关注。
数据来源与说明：本文事实依据 WordPress 官方发布公告《WordPress 7.1.3 Maintenance and Security Release》（2026 年 10 月 6 日）、官方版本说明页，以及 Patchstack 发布的技术分析。漏洞利用前提与受影响版本范围以 Patchstack / WPScan 的技术分析为准。截至本文发布时，该批次 7 个漏洞尚未分配 CVE 编号，也暂无官方严重级别评分；后续如有更新，请以 WordPress 安全团队公告为准。
