【已复现】WordPress核心主题预览缺陷可导致RCE漏洞(Click2Shell)"

admin 2026-10-16 11:18:14 网络安全文章 来源:ZONE.CI 全球网 0 阅读模式

【已复现】WordPress 核心主题预览缺陷可导致 RCE 漏洞(Click2Shell)

松杨网络安全资料库

2026年9月21日 16:16
广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

WordPress 核心主题预览功能存在安全缺陷,特制链接可触发主题自动安装与预览。该缺陷与部分第三方主题中缺少校验的 AJAX 安装器结合后,可实现服务器端 PHP 代码执行。

漏洞被命名为 Click2Shell。攻击者无需拥有站点账号,但需要诱导已登录且具备主题安装权限的管理员访问恶意链接。

利用前置条件:

  • 管理员已登录 WordPress 后台,并访问攻击者构造的链接(UI:R)
  • 目标站点 WordPress 版本低于 7.1.1
  • 站点上存在带有同类 AJAX 安装缺陷的主题(未激活亦可,且可由本漏洞自行安装)

完成端到端复现,最终取得 Web 进程权限下的命令执行回显。本文包含完整影响范围、修复方案、技术原理与复现细节。


漏洞概述

项目 内容
漏洞名称 WordPress 主题预览远程代码执行漏洞(Click2Shell)
漏洞编号 LDYVUL-2026-00215704
公开时间 2026-09-18
漏洞类型 代码注入(选择器注入)→ 强制安装 → RCE
POC 状态 已公开
EXP 状态 已公开
技术细节状态 已公开
利用可能性 高
CVSS 3.1 9.3(完整 RCE 链);强制安装原语单独评估 7.1
在野利用状态 公开渠道未发现

01 漏洞影响范围

受影响的 WordPress 核心版本:

WordPress < 7.1.1

含 7.1.0、7.0.x 及 6.x 各分支;官方已将补丁回移至所有受支持分支(低至 4.7),需按分支打对应安全版本。

需要注意的是,漏洞能否最终转化为代码执行,取决于两个条件同时成立:

条件 说明 备注
核心版本 < 7.1.1 决定第一跳「强制安装主题」能否成立 升级核心即可消除
存在带缺陷的主题 决定第二跳「落地为可执行代码」能否成立 升级核心无法消除

02 修复建议

正式防护方案

升级 WordPress 至 7.1.1 或更高版本。

官方未提供配置层面的缓解开关,升级是唯一的根治方式。

仅升级核心还不够

项目 状态
mobile-repair-zone 主题 官方目录已更新至 2.5.5,但 mobile_repair_zone_install _and_activate_plugin() 依旧没有 nonce 与 capability 校验,函数体与 2.5.4 一致
同类第三方主题 公开披露称官方目录中 存在 40 余个带有同类前置缺陷的主题
未激活的主题 同样构成风险 —— Customizer 预览时会加载其 functions.php

缓解措施

在无法立即升级的窗口期,可采取以下措施降低暴露面:

措施 作用
清理站点上未使用、非必要的主题(含未激活) 直接移除第二跳的弹药
限制 /wp-admin/的访问来源(IP 白名单 / 网关认证) 提高诱导链接被打开的门槛
禁止 wp-content/uploads/目录解析 PHP 切断本次复现所用的落地执行路径
监控管理员会话异常发起的 install-theme请求 提供第一跳的检测能力

03 漏洞描述

近期,安全研究团队公开了 WordPress 核心中的一处主题预览缺陷,并将其命名为 Click2Shell。主题预览逻辑将 URL 中的主题标识未经转义拼接到 jQuery 选择器中,攻击者可改变选择目标,使页面自动触发安装操作。官方补丁对输入进行选择器转义,并限制匹配对象为主题卡片。

第一跳:同一个值,被两处解读成两种东西

主题安装器支持 /wp-admin/theme-install.php?theme=THEME_SLUG这样的路由。该值在 wp-admin/js/theme.js中被当作 slug,先交给服务端查目录,再原样拼成前端选择器:

self.view.collection.once( 'query:success', function() {
    $( 'div[data-slug=\"' + slug + '\"]' ).trigger( 'click' );
});

取 payload mobile-repair-zone\"]>*>*>*/*,拆开看它拼出来的选择器:

片段 作用
\"] 提前闭合 [data-slug=\"...\"]属性选择器
>*>*>* 沿子元素层级向下,走进主题卡片内部的操作区
/* 开启 CSS 注释,吃掉 WordPress 后面补的那个 \"]

于是 .trigger('click')点到的不再是主题卡片,而是卡片内部的真实 Install 控件。关键在于:这次点击由 WordPress 自己的 JavaScript 发起,使用的是管理员自己的 nonce 与 install_themes能力,攻击者全程没有账号。

第二跳:未激活的主题,PHP 照样会执行

WordPress 的 Customizer 在准备预览时,会加载目标主题的 functions.php,哪怕该主题并未激活:

/wp-admin/admin-ajax.php?wp_customize=on&customize_theme=mobile-repair-zone

mobile-repair-zone借此注册了一个 AJAX 处理器,其回调直接消费攻击者可控的 POST 参数:

function mobile_repair_zone_install_and_activate_plugin() {
    $post_plugin_details = $_POST['plugin_details'];
    $plugin_url          = $post_plugin_details['plugin_url'];
    ...
}

三个缺陷叠加在一起:

缺陷 后果
没有 check_ajax_referer() 无 nonce 校验,可被任意构造的请求调用
没有 current_user_can() 不检查调用者是否具备安装插件的权限
plugin_url 完全可控 攻击者可指定任意 ZIP 包地址

后续链条为:wp_safe_remote_get()拉包 → 写入 plugins 目录 → unzip_file()解包 → activate_plugin()触发 include。代码最终以站点 PHP 进程权限执行,可能导致站点数据泄露、内容篡改及站点被接管。

官方补丁

改动位于 wp-admin/js/theme.js,作两处收紧(changeset 63664):

// 修复前
$( 'div[data-slug=\"' + slug + '\"]' ).trigger( 'click' );

// 修复后(WordPress 7.1.1)
$( 'div.theme[data-slug=\"' + $.escapeSelector( slug ) + '\"]' ).trigger( 'click' );

一是限定匹配对象必须是真实的 div.theme卡片,二是用 $.escapeSelector()转义 URL 派生值。注入的引号、组合器与注释语法全部退化为字面量,选择器再也走不进 Install 控件。


04 漏洞复现

我们在自有授权靶场构造并发送对应 Payload,成功验证该漏洞可导致远程代码执行,最终取得目标站点的命令执行能力。

复现环境

项目 值
靶站 wordpress:7.0.4-php8.3-apache + mysql:8.0(Docker)
站点地址 http://192.168.x.x:8086
客户端 Windows + Playwright 驱动本机 Chrome
payload 投递 同主机 80 端口静态服务

复现过程与结果如下图所示。


05 排查与核查

请求侧

  • theme-install.php请求中 theme参数出现 \"]、>、*、/*等选择器语法字符
  • admin-ajax.php同时带 wp_customize=on与 customize_theme=的请求,尤其是 action=为插件安装类动作的

文件侧

  • wp-content/themes/下出现从未由管理员安装过的主题目录
  • wp-content/uploads/下出现可执行 PHP 文件
  • wp_options.active_plugins中出现陌生条目

06 参考链接

https://wordpress.org/news/2026/09/wordpress-7-1-1-maintenance-and-security-release/

https://wordpress.org/documentation/wordpress-version/version-7-1-1/

https://core.trac.wordpress.org/changeset/63664

https://pwn.ai/blog/click2shell


MTR和ping两者怎么判断?" 网络安全文章

MTR和ping两者怎么判断?"

本文通过MTR与ping测试百度IP的对比,探讨网络诊断中中间跳点高丢包率与最终目的地正常现象的原因。核心结论是中间路由丢包不代表链路故障,非对称路由及ICMP限速是常见因素,最终目的地RTT=32ms、丢包0%证明网络正常。建议诊断时以最终目的地结果为准,结合双向路由分析。
评论:0   参与:  0