Modown 模板兔主题 SQL 注入漏洞复核：历史情报、原版代码审计与 WordPress 商城安全加固指南

安全研判更新：2026 年 10 月 20 日。围绕 WordPress 商业主题 Modown（模板兔）流传的“重大 SQL 注入、未授权访问与远程代码执行”消息，究竟哪些有证据，哪些仍属于推测？我们对照公开漏洞记录、模板兔官方更新日志，并对保留的多个原版主题样本进行静态代码审计，整理出以下结论与实用加固清单。

核心结论：Modown 有可追溯至 2021 年的 SQL 注入漏洞记录；但目前没有足够证据证明“2026 年 10 月 20 日新披露零日漏洞”、新版 Modown 普遍存在匿名 RCE，或任意站点已被入侵。另一方面，我们在 v9.41～v10.0 样本中确实发现长期保留的 SQL 拼接及请求校验问题，值得运营付费下载、会员和虚拟商品站点的管理员立即排查。本文不公布可用于攻击第三方站点的利用请求。

一、漏洞速览与事实核验

核查项目	截至 2026-10-20 的结论
已知漏洞标识	CNVD-2021-29145；公开转载记录描述为 Modown SQL 注入
历史披露日期	2021 年 4 月 5 日（依据可检索的历史转载信息）
阿里云情报	AVD-2021-698937 页面可定位，但本次未能读取完整详情，不能单独据此确定函数、版本或修复情况
2026 年 10 月新 0day	尚未证实；历史漏洞二次传播不等于当天首次披露
匿名 RCE	尚未证实；SQL 注入、越权和代码执行是不同漏洞类别，不能直接推导
官方公开版本	Modown v10.01，2026 年 8 月 11 日；官方日志仅标注修复 Bug，未提供针对 CNVD-2021-29145 的明确补丁对应关系
本文代码审计范围	v9.41、9.42、9.44、9.50、9.70、9.72、10.0 历史包及独立部署的 v10.0 样本（静态审计，非渗透测试）

需要特别说明：历史情报并未可靠给出完整受影响版本边界。不能因为某个版本中找到 SQL 拼接，就认定它可以通过同一匿名请求被利用；同样，也不能因为官方版本号较新就推断旧问题全部修复。

二、原版代码审计：发现了什么？

1. 工单模块：参数化查询与 CSRF 防护不足

在 inc/ticket.php 中，工单创建、回复、删除等操作存在字符串拼接 SQL 的实现模式。例如工单删除操作将请求取得的记录 ID 直接拼入 SQL；相关代码位于 WordPress 后台工单管理功能中，后台页面本身有权限门槛，但执行删除前未见独立的 nonce 校验。该风险至少涉及输入边界与跨站请求伪造（CSRF）防护，是否能进一步构成可利用 SQL 注入，仍取决于实际调用路径、运行环境和输入处理。

对照历史原版包后，这一类删除语句在 v9.41、v9.42、v9.44、v9.50、v9.70、v9.72 和 v10.0 中均存在。建议维护者对该模块做统一修订：操作前验证权限与 nonce，ID 使用 absint() 规范化，并以 $wpdb->delete() 或 $wpdb->prepare() 替代直接拼接。工单内容、邮箱、附件 URL 等字段亦应审核&查验输入净化及输出转义。

// 防御性写法示意：在具有适当管理权限且 nonce 验证通过后
$id = absint( wp_unslash( $_POST['record_id'] ?? 0 ) );
if ( ! current_user_can( 'manage_options' ) ) {
    wp_die( '权限不足' );
}
check_admin_referer( 'modown_delete_record' );
if ( $id ) {
    $wpdb->delete( $wpdb->prefix . 'tickets', array( 'id' => $id ), array( '%d' ) );
}

上面的代码仅演示防御结构，不是可以直接覆盖主题的完整补丁；实际能力应与工单管理页面的授权策略保持一致，nonce 字段与表单生成逻辑也须配套修改。

2. AJAX 接口：逐个检查未登录入口，而非一刀切禁用

v10.0 样本可见 3 处 wp_ajax_nopriv_* 注册，分别涉及卡密查询、相册密码及付费内容访问。这些接口允许访客到达回调函数，但允许未登录调用不等于允许未授权获得业务数据。例如部分实现具有会话校验、会员条件或令牌判断。

建议逐项确认：是否允许游客访问、令牌是否可重放、是否使用有效期和速率限制、是否泄露可下载资源及订单信息、服务端是否每次重新验证购买/VIP 权限。尤其不要仅凭前端隐藏按钮就授予下载权限。

3. 投稿上传与历史图片组件

inc/base.php 的投稿图片 AJAX 上传入口使用了 WordPress 的 wp_handle_upload()，存在登录状态判断，但建议补上独立 nonce、基于业务角色的上传授权以及明确的 MIME/扩展名白名单、文件体积和频率限制。使用 wp_handle_upload() 不能替代完整的业务权限设计。

v10.0 中还保留 timthumb.php，其源码声明的版本为 2.8.14。这是一个历史图片处理组件；其存在并不能单独证明本站可遭远程执行，但建议检查主题选项是否启用，优先改用 WordPress 原生图片裁切和缩略图能力。确认不依赖后，可阻断该独立脚本的外部访问，避免继续暴露不必要的处理入口。

4. 未发现充分证据可将上述问题定性为匿名 RCE

本次为只读静态审计，没有在生产环境执行恶意请求或验证数据库数据外传。代码中存在 base64_decode() 等函数也不能直接视为后门：必须分析其数据来源、调用上下文及后续执行行为。因此，不发布缺乏证据的“已获得服务器最高权限”“所有版本均可直接 RCE”等结论。

三、运营 Modown / Erphpdown 商城的应急处置清单

确认完整组件清单。记录 WordPress、Modown 主主题、子主题、Erphpdown 及支付扩展版本。分别审计主题、插件和子主题，不要把所有业务缺陷归因于同一个组件。
先备份再更新。备份数据库、主题文件、上传目录和订单配置；在可回滚的测试环境验证最新来源可信的原版包。官方公开版本已到 v10.01，但其对历史 SQL 注入的修复对应关系尚未公开确认，应要求开发者提供明确的修复说明。
优先保护可改变业务状态的接口。订单回调、充值与退款、VIP 升级、积分变更、私信/工单操作均需服务端权限验证、请求校验和审计；支付成功必须以支付平台服务端签名及订单金额、币种、状态核验为准，并保证回调幂等。
替换手工拼接 SQL。使用 $wpdb->prepare()、$wpdb->insert()、$wpdb->update()、$wpdb->delete()；输入校验、SQL 参数化和 HTML 输出转义是三道不同的防线。
收紧上传与文件执行。上传目录禁止 PHP 执行；限制 MIME、扩展名、文件大小和上传频率；关闭未使用的直接 PHP 处理入口，避免对整个主题目录盲目封禁导致网站功能异常。
部署有日志和误报复核能力的 WAF。重点观察 /wp-admin/admin-ajax.php、/wp-json/、登录及支付回调相关路径。不要依赖只拦截“SELECT/UNION”等 SQL 关键词的简单规则，也不要无差别关闭 REST API。
排查访问记录与后台变化。结合 Web 访问日志、PHP 错误日志、WordPress 登录与管理审计日志，分析异常参数、重复失败、陌生管理员、主题文件改动、异常定时任务及订单/VIP/余额突变。访问主题静态资源并不能单独证明攻击发生。
有入侵证据时启动凭据轮换与恢复。优先封禁恶意入口、保全日志和受影响文件，检查管理员账户、应用密码、支付密钥、数据库凭据与 WordPress salts。数据库密码轮换必须同步更新站点配置并验证业务恢复；没有泄露证据时不宜在未经备份和评估的情况下盲目同时更改所有密钥。

四、如何判断站点是否已被利用？

SQL 注入的后果可能包含读取或修改业务数据库，但 WordPress 的用户密码通常保存为哈希值，并非数据库一旦泄露就等于直接获得全部明文密码。服务器代码执行也需要独立的缺陷或后续攻击条件。建议按请求证据 → 应用日志 → 数据库记录完整性 → 文件完整性 → 权限与密钥影响的次序调查，不应因出现一次异常 URL 就认定站点已被接管。

对虚拟商城尤其要核对订单支付状态、下载授权、VIP 有效期、余额及提现记录是否存在与真实支付流水不一致的变化。发现可疑改动时，先保存只读取证副本，再通过可信备份恢复，必要时联系服务器和支付服务商协同处理。

五、结论：旧漏洞要复核，新的代码缺陷也不能忽略

Modown 2021 年已有 SQL 注入历史记录；我们在多个后续原版样本中进一步发现值得修补的数据库访问和请求验证问题。但截至本文发布，没有证据支持把这些静态发现全部升级描述为“2026 年新零日”“匿名远程控制服务器”。对站长最有价值的行动，是核对来源与版本、对关键交易入口逐项审计、完成防御性修复并建立日志和备份闭环。

本文的版本判断来自指定时点的官方更新页，代码结论来自所列样本的静态分析；未进行在线利用测试，亦不对未取得的 v10.01 完整源码作安全保证。若后续厂商披露明确的修复版本或漏洞技术详情，影响范围应随证据更新。