CVE-2026-49060 - Hippoo Mobile App for WooCommerce Atribuição Incorreta de Privilégios / Escalada de Privilégios

Resumo Executivo

Este repositório contém um laboratório Docker local para reproduzir e validar a CVE-2026-49060, uma vulnerabilidade de Atribuição Incorreta de Privilégios que afeta o plugin WordPress Hippoo Mobile App for WooCommerce.

O comportamento vulnerável é exposto por meio do namespace clonado da API REST do Hippoo:```text /wc-hippoo/v1/ext/

No alvo vulnerável, um visitante não autenticado pode acessar uma rota clonada de usuários da REST API do WordPress e pode atualizar a senha do usuário administrador por meio de uma requisição HTTP não autenticada. No alvo corrigido, a mesma requisição é bloqueada com `403 Forbidden`.

Este laboratório compara duas versões do Hippoo:

| Serviço   | Versão do Hippoo | Finalidade                  | URL                     |
| --------- | -------------: | ---------------------------- | ----------------------- |
| `vuln`    |          1.9.4 | Alvo de comparação vulnerável | `http://localhost:8081` |
| `patched` |          1.9.5 | Alvo de comparação corrigido    | `http://localhost:8082` |

A cadeia de vulnerabilidade demonstrada é:```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 laboratório valida o comportamento de autorização vulnerável versus corrigido usando Hippoo 1.9.4 e Hippoo 1.9.5.

O laboratório é intencionalmente limitado a serviços Docker locais. Ele não visa sistemas externos e não inclui persistência, web shells, malware ou callbacks externos.

Fatos Verificados

Alegação	Evidência	Como verificar neste laboratório
O CVE-2026-49060 afeta o Hippoo Mobile App for WooCommerce até a versão 1.9.4.	Avisos públicos identificam Hippoo <= 1.9.4 / até 1.9.4 como afetado.	Consulte a seção Referências e compare a versão do serviço vuln.
O Hippoo 1.9.5 é usado como alvo de comparação corrigido.	Os metadados dos avisos públicos identificam 1.9.5 como uma versão corrigida para a faixa afetada.	Execute docker compose logs init-vuln init-patched e confirme as versões inicializadas do plugin.
O comportamento vulnerável é exposto por meio do namespace REST clonado do Hippoo.	O Hippoo re-registra rotas REST externas sob /wc-hippoo/v1/ext/.	Execute python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082.
O Hippoo 1.9.4 permite acesso não autenticado à rota de usuários clonada neste laboratório.	O PoC do laboratório recebe 200 OK de http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1.	Execute o comando de validação somente leitura contra 8081.
O Hippoo 1.9.5 bloqueia a mesma solicitação não autenticada neste laboratório.	O PoC do laboratório recebe 403 Forbidden de http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1.	Execute o comando de validação somente leitura contra 8082.
O alvo vulnerável pode atualizar a senha do administrador por meio de um POST não autenticado neste laboratório local.	O PoC ativo recebe 200 OK do alvo vulnerável quando --update-password é usado.	Execute python3 poc/poc.py --update-password http://127.0.0.1:8081.
O alvo corrigido bloqueia a solicitação não autenticada de atualização de senha.	O Hippoo 1.9.5 retorna uma resposta proibida para a mesma rota de usuários clonada.	Execute a validação ativa contra ambos os alvos.
O PoC é somente HTTP.	poc/poc.py envia apenas solicitações HTTP e não chama Docker, WP-CLI ou APIs de contêiner.	Inspecione poc/poc.py.

Premissas e Incógnitas

Este laboratório usa o Hippoo 1.9.4 como alvo de comparação vulnerável porque avisos públicos identificam versões até 1.9.4 como afetadas.

Este laboratório usa o Hippoo 1.9.5 como alvo de comparação corrigido porque os metadados dos avisos públicos identificam 1.9.5 como a versão corrigida para a faixa afetada demonstrada.

O registro público do CVE-2026-49060 descreve o problema em alto nível como Atribuição Incorreta de Privilégios / Escalação de Privilégios. Este laboratório concentra-se no comportamento de autorização observável no Hippoo 1.9.4 e o compara com o Hippoo 1.9.5.

O resumo da causa raiz neste README é baseado na comparação de código-fonte entre as versões vulnerável e corrigida do Hippoo usadas no laboratório.

Este laboratório não afirma testar todas as rotas do Hippoo. Ele concentra-se na rota REST de usuários do WordPress clonada:```text /wc-hippoo/v1/ext/wp/v2/users/

O laboratório não demonstra:

* persistência,
* upload de web shell,
* execução arbitrária de comandos,
* callbacks externos,
* comportamento de malware,
* ataques a sistemas fora do laboratório,
* ou atividade pós-comprometimento além da validação local de atualização de senha.

## Resumo da Causa Raiz

A causa raiz é uma falha de lógica de permissões no tratamento de papéis e permissões do Hippoo.

O Hippoo expõe rotas REST clonadas do WordPress e WooCommerce sob seu próprio namespace:```text
/wc-hippoo/v1/ext/

O comportamento de clonagem de rotas é sensível à segurança porque a rota clonada deve preservar ou fortalecer os requisitos de autorização da rota original. Se a rota clonada receber um callback de permissão permissivo, usuários não autenticados podem alcançar endpoints REST que deveriam exigir autenticação e autorização.

O comportamento relevante de clonagem de rotas segue este padrão:```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,
            )
        );
    }
}

}

O modelo de segurança pretendido é:```text
Original protected REST route
→ cloned into Hippoo namespace
→ permission callback still denies unauthenticated access

O comportamento vulnerável ocorre porque Hippoo 1.9.4 usa o mesmo valor de retorno para dois estados diferentes:```text administrator / unrestricted access unauthenticated visitor / no user

No Hippoo `1.9.4`, o auxiliar de permissão retorna `null` quando não há usuário 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
    }