Skip to content
KitploitKITPLOIT
工具漏洞利用博客
Log in
提交
工具漏洞利用博客
提交

黑客、渗透测试和网络安全工具,武装您的安全武器库!

Kitploit 是一个黑客、网络安全和渗透测试工具的目录。发现最新的项目更新,查找漏洞、分析系统、自动化测试并加强你的安全。

订阅源联系隐私© 2026 Kitploit

工具目录

分类

查看所有分类
Loading categories
wpforms-xss-fix-bypass — WPForms <= 2.0.2.1 中的未认证反射型 XSS —— 在属性名位置绕过 CVE-2026-88996 的 Smart Tag 转义 | Kitploit
工具/GitHubGitHub/dorkerdevil/wpforms-xss-fix-bypass
漏洞分析漏洞利用Web应用程序漏洞利用Web安全渗透测试
GitHubdorkerdevil/wpforms-xss-fix-bypass

wpforms-xss-fix-bypass

WPForms <= 2.0.2.1 中的未认证反射型 XSS —— 在属性名位置绕过 CVE-2026-88996 的 Smart Tag 转义

查看仓库
131个月前尚未审核

最受欢迎

查看全部 →

发现我们社区最常用的工具。

探索所有工具

浏览我们的工具集合

查看所有工具 →
分享

WPForms ≤ 2.0.2.1 — 绕过 CVE-2026-88996 修复(未认证反射型 XSS)

受影响: WPForms – AI Form Builder for WordPress(免费/精简版),版本 2.0.2.1 —— 披露时的最新版本(同时也是包含 CVE-2026-88996 修复的版本)。Pro 版共享 Smart Tag 渲染器。

类别: 未认证反射型跨站脚本(CWE-79),已通过不完整的 CVE-2026-88996 / GHSA-8j5g-9vmv-9mmw 修复验证了 JavaScript 执行。

发现日期: 2026-09-27 ·

报告至 Patchstack: 2026-09-27 ·

被拒绝: 2026-09-28(“该问题仅在站点管理员在 HTML 属性名位置编写了裸 Smart Tag 时出现……并非默认设置,也不是任何人会实际编写的模式”——技术有效性未被质疑)·

公开日期: 2026-09-28。

摘要

针对 CVE-2026-93485 系列反射型 XSS 的 2.0.2.1 修复会转义被替换到标记中的 Smart Tag 值(SmartTags::escape_for_attribute() 对引号和空白进行编码)。只要被替换的值落在带引号的属性值内部,该修复就有效。当表单作者在确认消息的属性名位置放置裸 Smart Tag 时——例如:

<input {field_id="3"}>

包含不含引号且不含空白字符的已提交字段值,例如 onmouseover=alert(1),会被原样插入,并成为一个新的、生效的事件处理程序 属性。转义过程从不编码 =,而属性名既不需要引号也不需要 空白字符。随后返回给匿名提交者的确认信息包含:

<input onmouseover=alert(1)>

对 admin-ajax.php(action=wpforms_submit、wp_ajax_nopriv_*)的匿名提交在设计上对已登出用户不进行 nonce 校验,因此这是一个完全无需认证的反射型 XSS。任意 JavaScript 通过 onmouseover=eval(String.fromCharCode(...)) 在单 token 约束内执行。

证明这是修复缺口的差异

在同一表单上,父 CVE 的载荷形态——从带引号的值内部突破引号,例如 x" onfocus=alert(1) autofocus y="——在每一个位置都被正确转义(观察到 &quot; / &#32; 编码)。2.0.2.1 的转义在所有位置都有效,唯独属性名放置处例外。这是对同一替换汇聚点的不完整修复,而非独立的特性缺口。

复现

# 1. WordPress + WPForms lite 2.0.2.1, create a form with a single-line text field (id 3)
# 2. Set the form's Confirmation message to:
#      A: <input value="{field_id="3"}">  B: <input {field_id="3"}>
# 3. Run the PoC (stdlib-only Python 3):
python3 poc.py --url http://target.example/form-page/

预期输出:

[+] field 3 reflects into the confirmation message
[payload (bypass position)] occurrences: LIVE=1 ESCAPED/INERT=2
    LIVE  -> ...<input onmouseover=alert(poc93485)>...
[control] parent-CVE payload escaped everywhere: YES (fix works at value positions)
=== VERDICT: VULNERABLE — payload reaches attribute-NAME position unescaped ===

poc.py 会自动发现表单、字段和反射字段;匿名提交;并将每次出现分类为 LIVE(属性名注入)与 ESCAPED(带引号的值,即父 CVE 的形态)。退出码 0 = 存在漏洞。

前提条件(如实说明)

表单中由管理员编写的 Confirmation 消息必须在标记内的属性名位置包含一个裸的、会反射输入的 Smart Tag。Patchstack 的研究人员认为这是一种不现实的编写模式;但它仍然是一个有文档记录的功能位置,转义的存在正是为了使标记上下文中的替换安全,并且作者不会收到任何错误——只有静默注入。

建议修复

在标记上下文转义中对 = 进行编码,或者对确认标记进行上下文解析,并仅允许在文本和带引号的属性值位置进行 Smart Tag 替换。

文件

  • poc.py — 自包含 PoC(无服务端步骤,无依赖)
  • poc.sh — 基于 curl 的最小变体

免责声明

仅用于授权测试和教育目的。报告者在一次协调提交尝试被拒绝后发布了此内容;技术发现并未受到质疑。

作者

Ashish Kunwar (@D0rkerdevil)

下载工具