漏洞描述

PbootCMS V3.2.5 的用户管理模块中存在一个SQL注入漏洞。该漏洞位于 /apps/admin/controller/system/UserController.php（第149行）的 mod() 方法以及 /apps/admin/model/system/UserModel.php 的 modUser() 方法中。

field 参数完全由用户通过GET请求控制，且没有任何白名单验证。value 参数同样完全由用户控制，并被直接拼接进SQL UPDATE 语句中。已认证的攻击者可以将任意数据库列指定为 field（例如 password、username、status、role），从而实现任意数据篡改。

根本原因

$field 和 $value 直接取自 $_GET 超全局变量，并被拼接进SQL字符串中，没有任何过滤、没有白名单、也没有使用参数化查询。该字符串随后被传递给 UserModel::modUser()，后者将其转发给基类的 Model::update() 方法。由于该参数是字符串（而非数组），因此绕过了 checkKey() 字段名验证，并被原样嵌入到 SET 子句中：

调用链

影响

已认证的攻击者可以：

1. 修改任意用户的密码 — 包括超级管理员（内置创始人 ucode=10001 除外）。
2. 更改账户状态 — 启用或禁用任意账户。
3. 注入更深层的SQL — value 参数允许单引号转义，可能引发堆叠查询或基于恒真条件的攻击。

这将导致账户接管和对CMS后端的完全控制。

复现步骤

前提条件

• 本地安装 PbootCMS V3.2.5（已在 192.168.1.104、Apache/PHP 7.2.1/SQLite 环境下测试）
• 一个有效的后端管理员账户

步骤 1：登录管理后台

访问 PbootCMS 管理后台，并使用默认的 admin 账户登录。

步骤 2：创建目标用户

导航至 系统管理 → 用户管理 → 添加用户。创建一个新用户：

• 用户名：admin2
• 密码：admin
• 角色：系统管理员

步骤 3：确认用户已存在

用户列表确认 admin2 的 ucode=10002：

步骤 4：确认初始密码

打开一个新的浏览器窗口。尝试以 admin2 身份使用密码 123456 登录 — 此操作失败，因为实际密码是 admin：

步骤 5：构造并执行Payload

使用已登录管理员的浏览器，访问：

14e1b600b1fd579f47433b88e8d85291 是 123456 的MD5哈希值。

mod() 方法执行注入并通过 location(-1) 进行重定向：

步骤 6：验证密码更改

现在尝试使用 admin2 / 123456 登录：

密码已通过SQL注入成功更改。 用户现在可以使用新密码登录，确认了完整的账户接管。

源代码分析

漏洞代码（UserController.php，约第149行）

数据库层（Model.php - update 方法）

当 update() 接收到字符串参数时，该参数会原样用于 SET 子句中，不做任何转义：

修复建议

1. 对 field 参数进行白名单验证 — 仅允许已知的列名（status、username、realname、password）。
2. 使用参数化查询 — 使用预处理语句代替字符串拼接。
3. 转义用户输入 — 至少要对 $value 进行过滤，以防止引号逃逸。
4. 强制密码哈希 — 如果 field 为 password，在存储前对值应用 encrypt_string()。
5. 限制独立修改路径 — mod() 中的“单字段修改”分支应要求有效的CSRF令牌和角色级授权检查。

参考

• PbootCMS 官方网站
• PbootCMS 在 Gitee 上的源码
• CVE-2026-79387

披露：此漏洞已负责任地向厂商披露。如果您正在运行受影响的版本，请立即更新并审计所有后端账户。