CVE-2026-49060 - Hippoo Mobile App for WooCommerce Assegnazione di privilegi errata / Escalation dei privilegi

Sintesi esecutiva

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.

Fatti verificati

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.

Assunzioni e incognite

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;
    }