WordPress 曝史诗级漏洞链 CVE-2026-64638：一次登录失败竟能接管整台服务器

全球超过四成的网站正在使用的 WordPress，最近被安全团队 pwn.ai 抛出一颗重磅炸弹。编号CVE-2026-64638的漏洞链，别名XSS2Shell，其危险程度足以让任何一位站长夜不能寐——攻击者只需要在登录框里输入一段精心构造的"用户名"，就能把一次再普通不过的登录失败，演变成对服务器底层的完全远程代码执行。更棘手的是，这段有问题的代码从 WordPress 4.7 时代起就静静躺在核心文件里，几乎覆盖了市面上所有仍在维护的 WordPress 站点。在官方补丁发布之前，粗略估计有超过五亿个网站暴露在风险之下。

一切从 wp-login.php 开始

故事的起点熟悉得令人不安：就是每个 WordPress 站点都有的那个默认登录页。当你在登录框里填了一个根本不存在的用户名并点击提交后，系统会照例返回一条错误提示。这个看似无害的反馈机制，恰恰是整起事件的突破口。

WordPress 内部调用了wp_strip_all_tags函数来"清洗"用户输入。理论上，它应该剥掉所有潜在的 HTML 标签，防止恶意代码混进页面。然而 pwn.ai 的研究人员发现，只要在左尖括号和标签名之间插入一个空格——比如写成< area这种形式——PHP 底层的strip_tags解析器就会把它当成普通文本放行。可耐人寻味的是，WordPress 自家的 KSES 清理器在下一轮处理时，又会把这个字符串重新识别为合法的 HTML 元素。

这种"你认为是文本，我当作标签"的解析器分歧，成了攻击者绕过过滤的绝佳缝隙。不需要账号，不需要提前拿到任何凭证，攻击者就能把<area>、<div>、<button>这类实时可控的元素，神不知鬼不觉地塞进渲染后的登录页面里。

注入的元素如何"活"过来

这些被偷偷植入的元素本身并不是<script>标签，所以乍一看似乎造不成什么实质伤害。但问题出在了 WordPress 自带的user-profile.js文件上——这是密码重置功能遗留下来的一段脚本，页面加载时会自动扫描特定选择器。

攻击者正是掐准了这个时机。他们注入的元素恰好匹配了这段脚本要查找的目标，于是浏览器在加载登录页的瞬间，会自动触发一次点击事件。紧接着，一个 AJAX 请求被发了出去。而攻击者通过DOM 覆盖技术，把请求的目标 URL 悄悄换成了自己控制的地址。随后借助方法重写和 JSONP 参数，把请求指向 WordPress 的 REST API，返回的数据被包裹在一段可执行的 JavaScript 中。

到了这一步，攻击者已经能在 WordPress 的域名下运行任意脚本，而且全程零身份验证。单是这个XSS 攻击的层面，就已经足够严重了。

从跨站脚本到远程控制：漏洞链的致命跳跃

如果故事止步于 XSS，那 CVE-2026-64638 顶多算一个高危的跨站脚本漏洞。真正让它晋升为"漏洞链"的，是后续向远程代码执行（RCE）的升级路径。

假设某位已登录的管理员不慎访问了攻击者构造的第三方恶意页面，并与页面发生了交互，那么攻击者植入的脚本就能"借用"这位管理员当前的会话身份。接下来的操作堪称行云流水：先通过管理员权限获取 WordPress 应用密码，再利用管理员默认拥有的unfiltered_html权限，发布一个嵌入了攻击者 JavaScript 的页面。最后，通过管理员在不知情状态下触发的、看似合法且已经过身份验证的 WordPress API 调用，上传一个伪装成插件的 ZIP 压缩包——里面藏着的，正是一个PHP WebShell。

一旦 WebShell 落地，整台服务器的控制权就彻底易主了。文件读写、数据库拖库、横向渗透，都在攻击者的弹指之间。

官方定级与背后的考量

WordPress 安全团队在公告中确认了这条完整的攻击链路。不过他们也强调，从 XSS 跃升到 RCE 并非无条件自动触发，中间需要社会工程学的配合，以及管理员明确的交互行为——比如主动点击某个链接或执行某个操作。正因为这些环节超出了攻击者的直接掌控，该漏洞的 CVSS 评分最终定格在8.9，而非理论上的最高分。

话虽如此，8.9 分依然属于"严重"级别。对于承载着企业官网、电商平台、内容博客的无数 WordPress 站点而言，这个分数背后的现实威胁不容小觑。毕竟在互联网的暗处，针对管理员的钓鱼和诱导点击，从来都不是什么稀罕手段。

写在最后

CVE-2026-64638 再次给整个开源生态敲响了警钟。一个存在了数个主要版本、藏在核心代码深处的解析差异，竟能在被忽视多年后，演变成影响数亿站点的攻击链。对于站长来说，除了紧盯官方补丁、第一时间升级内核之外，限制登录入口的暴露面、为管理员账号启用双因素认证、对插件上传保持高度警惕，都是眼下切实可行的加固措施。在补丁全面铺开之前，没有任何一个 WordPress 安装可以被理所当然地视为安全。