WordPress: bugs críticos na interseção de componentes
Técnicas e Métodos de Ataque2026-07-29, 09:03
Três novos estudos foram publicados analisando vulnerabilidades recentes do WordPress. Embora duas das vulnerabilidades tenham sido encontradas no núcleo e a terceira no plugin Temporary Login, elas compartilham uma causa raiz comum: todas surgem de interações entre diferentes componentes do WordPress.
• Vulnerabilidades de núcleo WP2shell
CVE-2026-63030 — uma vulnerabilidade que surge quando várias chamadas REST Batch API são combinadas através de
/wp-json/batch/v1 (também disponível via ?rest_route=/batch/v1) em uma única solicitação HTTP. A solicitação pode ser validada contra as regras de um endpoint, mas executada pelo manipulador de outro endpoint, ignorando a tipagem e sanitização de parâmetros.CVE-2026-60137 — uma vulnerabilidade de injeção SQL em
WP_Query: o valor da string author__not_in não foi sanitizado, mas ainda foi incluído na consulta SQL.Na cadeia WP2shell, a primeira vulnerabilidade entrega uma string não verificada ao
WP_Query, enquanto a segunda a transforma em uma injeção SQL pré-auth e, sob uma configuração adequada, potencial RCE:REST Batch API → dessincronização de rota e resultado de validação → bypass de validação e sanitização de esquema REST → string reaches author__not_in → WP_Query insere no SQL → injeção SQL → RCE (sob uma configuração adequada) Pesquisadores da Fullhunt apresentaram um scanner para verificar se os sistemas são vulneráveis ao WP2shell.
Uma descoberta interessante da pesquisa da Hacktron é que a revisão de IA e SAST frequentemente detectavam a dessincronização de array, mas a tratavam como um erro comum resultando em uma resposta HTTP 500. Seu impacto na segurança tornou-se aparente apenas ao analisar a interação entre o roteamento REST e
WP_Query.• Vulnerabilidade do plugin Temporary Login
CVE-2026-7567 está na maneira como o plugin procura um usuário:
get_users([ 'meta_key' => '_temporary_login_token', 'meta_value' => $token, ]); Os desenvolvedores esperavam uma correspondência exata de token. No entanto, no WordPress, ummeta_valuevazio desativa a filtragem de valor, eWP_User_Queryverifica apenas a condiçãometa_key = '_temporary_login_token'. Para bypassar a verificaçãoempty($_GET['temp-login-token']), é suficiente passar o parâmetro como um array. É considerado não vazio porempty(), mas apóssanitize_key()torna-se uma string vazia. Como resultado, a consulta retorna qualquer usuário com um_temporary_login_tokendefinido. O plugin trata o primeiro usuário encontrado como o proprietário de um token válido e passa esse usuário para a API de Autenticação do WordPress, que cria uma sessão totalmente autenticada.
Todos esses estudos destacam mais uma vez a importância de testar não apenas componentes individuais, mas também suas interações.
Artigo 1: https://fullhunt.io/blog/2026/07/17/wp2shell-wordpress-core-pre-auth-rce-cve-2026-63030.html
Artigo 2: https://www.hacktron.ai/blog/wp2shell
Vulnerabilidades
Pesquisadores
Fornecedor
Produto
Mais