Nguyen Hung

Atacantes autenticados com nível de acesso de Assinante (Subscriber) ou superior podem elevar seus privilégios para Administrador. Isso ocorre porque o manipulador `ajax ayi action()` não utiliza uma lista de permissões (allow-list) ao processar as variáveis `type` e `postid` do array `$ POST`, aplicando apenas `strip tags(esc sql())` antes de passá-las para a função `update ayi data()`. Esta função, por sua vez, chama `update user meta()`, permitindo que um atacante escreva `['subscriber'=>true,'administrator'=>'administrator']` em seu próprio meta de usuário `wp capabilities` ao definir `type` como `wp capabilities` e `postid` como `administrator`. Consequentemente, o `WP User::get role caps()` reconhece a chave `administrator` como uma função ativa na requisição seguinte.

Existe um bypass de autenticação que permite a tomada de controle de contas de administrador. O problema decorre de uma conflação de lógica na função `get user permissions()` dentro de `HippooPermissions`, que retorna o mesmo sentinela nulo tanto para administradores quanto para visitantes não autenticados. A função `has role access()` interpreta esse valor como acesso total de administrador, levando a `override extension permission callback()` a atribuir ` return true` como o callback de permissão para todas as rotas REST do WordPress e WooCommerce clonadas sob o endpoint '/wc-hippoo/v1/ext/' por `re register external routes()`. Além disso, a guarda de pré-despacho `block unauthorized access()` falha ao bloquear usuários não autenticados devido ao mesmo erro de lógica. Isso permite que atacantes não autenticados invoquem endpoints REST principais sem credenciais, especificamente enviando uma requisição POST para '/wc-hippoo/v1/ext/wp/v2/users/<id>' com a variável `password` no corpo da requisição para redefinir a senha de qualquer usuário, incluindo o administrador do site.

Ocorre uma validação insuficiente do tipo de arquivo quando tipos de lista negra personalizados são configurados, pois o sistema substitui a lista de permissões de extensões perigosas padrão em vez de mesclá-la. Além disso, a função `wpcf7 antiscript file name()` pode ser ignorada usando nomes de arquivos que contenham caracteres não-ASCII. Isso permite que invasores não autenticados façam o upload de arquivos arbitrários, como arquivos PHP, para o servidor, podendo levar à execução remota de código.