CVE-2026-49060 - Hippoo Mobile App for WooCommerce Incorrect Privilege Assignment / Privilege Escalation

Executive Summary

This repository contains a local Docker lab for reproducing and validating CVE-2026-49060, an Incorrect Privilege Assignment vulnerability affecting the WordPress plugin Hippoo Mobile App for WooCommerce.

The vulnerable behavior is exposed through Hippoo's cloned REST API namespace:

/wc-hippoo/v1/ext/

In the vulnerable target, an unauthenticated visitor can access a cloned WordPress REST users route and can update the administrator user's password through an unauthenticated HTTP request. In the patched target, the same request is blocked with 403 Forbidden.

This lab compares two Hippoo versions:

Service	Hippoo version	Purpose	URL
vuln	1.9.4	Vulnerable comparison target	http://localhost:8081
patched	1.9.5	Patched comparison target	http://localhost:8082

The demonstrated vulnerability chain is:

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

This lab validates the vulnerable-versus-patched authorization behavior using Hippoo 1.9.4 and Hippoo 1.9.5.

The lab is intentionally scoped to local Docker services. It does not target external systems and does not include persistence, web shells, malware, or external callbacks.

Verified Facts

Claim	Evidence	How to verify in this lab
CVE-2026-49060 affects Hippoo Mobile App for WooCommerce through version 1.9.4.	Public advisories identify Hippoo <= 1.9.4 / through 1.9.4 as affected.	Review the References section and compare the vuln service version.
Hippoo 1.9.5 is used as the patched comparison target.	Public advisory metadata identifies 1.9.5 as a patched version for the affected range.	Run docker compose logs init-vuln init-patched and confirm the initialized plugin versions.
The vulnerable behavior is exposed through Hippoo's cloned REST namespace.	Hippoo re-registers external REST routes under /wc-hippoo/v1/ext/.	Run python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082.
Hippoo 1.9.4 allows unauthenticated access to the cloned users route in this lab.	The lab PoC receives 200 OK from http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1.	Run the read-only validation command against 8081.
Hippoo 1.9.5 blocks the same unauthenticated request in this lab.	The lab PoC receives 403 Forbidden from http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1.	Run the read-only validation command against 8082.
The vulnerable target can update the administrator password through an unauthenticated POST in this local lab.	The active PoC receives 200 OK from the vulnerable target when --update-password is used.	Run python3 poc/poc.py --update-password http://127.0.0.1:8081.
The patched target blocks the unauthenticated password update request.	Hippoo 1.9.5 returns a forbidden response for the same cloned users route.	Run active validation against both targets.
The PoC is HTTP-only.	poc/poc.py sends HTTP requests only and does not call Docker, WP-CLI, or container APIs.	Inspect poc/poc.py.

Assumptions and Unknowns

This lab uses Hippoo 1.9.4 as the vulnerable comparison target because public advisories identify versions through 1.9.4 as affected.

This lab uses Hippoo 1.9.5 as the patched comparison target because public advisory metadata identifies 1.9.5 as the fixed version for the demonstrated affected range.

The public CVE-2026-49060 record describes the issue at a high level as Incorrect Privilege Assignment / Privilege Escalation. This lab focuses on the observable authorization behavior in Hippoo 1.9.4 and compares it against Hippoo 1.9.5.

The root cause summary in this README is based on source comparison between the vulnerable and patched Hippoo versions used in the lab.

This lab does not claim to test every Hippoo route. It focuses on the cloned WordPress users REST route:

/wc-hippoo/v1/ext/wp/v2/users/<id>

The lab does not demonstrate:

• persistence,
• web shell upload,
• arbitrary command execution,
• external callbacks,
• malware behavior,
• attacks against non-lab systems,
• or post-compromise activity beyond the local password update validation.

Root Cause Summary

The root cause is a permission logic flaw in Hippoo's role and permission handling.

Hippoo exposes cloned WordPress and WooCommerce REST routes under its own namespace:

/wc-hippoo/v1/ext/

The route-cloning behavior is security-sensitive because the cloned route must preserve or strengthen the original route's authorization requirements. If the cloned route receives a permissive permission callback, unauthenticated users may be able to reach REST endpoints that should require authentication and authorization.

The relevant route-cloning behavior follows this pattern:

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

The intended security model is:

Original protected REST route
→ cloned into Hippoo namespace
→ permission callback still denies unauthenticated access