CVE-2026-87900 no WP Toolkit: usuário cPanel pode modificar bancos de outras contas

A CVE-2026-87900 afeta a criação de bancos pelo WP Toolkit para cPanel. Segundo o boletim oficial, um usuário cPanel autenticado pode explorar versões vulneráveis para realizar modificações em bancos pertencentes a outras contas. O problema rompe a separação esperada entre clientes de um servidor compartilhado e foi corrigido no WP Toolkit 6.11.3.

O que aconteceu

O WP Toolkit automatiza instalação, clonagem, staging, atualização e administração de WordPress, incluindo a criação de banco e usuário MySQL. O aviso informa que o tratamento dos comandos usados na criação do banco não preservava corretamente a fronteira de autorização entre contas. Assim, uma sessão cPanel válida podia influenciar operações fora do conjunto de bancos do próprio usuário.

O fornecedor não divulgou parâmetros, payload ou pré-condições adicionais, e não é seguro inferir uma técnica específica. O impacto confirmado é modificação entre contas; o boletim não afirma execução como root. Mesmo assim, alterar banco de outro cliente pode modificar conteúdo, credenciais e configurações de WordPress, causar indisponibilidade ou preparar tomada da aplicação. A ausência de detalhes públicos não deve atrasar o patch.

Uma classificação de vulnerabilidade descreve o pior cenário plausível, não confirma que cada servidor tenha sido explorado. A análise correta separa quatro perguntas: o componente existe, a versão está no intervalo afetado, as pré-condições estão presentes e houve evidência de abuso. Essa distinção evita tanto falsa tranquilidade quanto interrupções desnecessárias.

Versões e ambientes afetados e corrigidos

A exploração exige autenticação em uma conta cPanel, mas não confiança administrativa. Em hospedagem compartilhada, cada cliente é uma fronteira de segurança independente; uma credencial roubada, revendedor malicioso ou conta já comprometida pode satisfazer essa condição. Restringir SSH não bloqueia uma falha acionada pelas funções do painel.

Em pacotes de distribuição, o número upstream nem sempre muda quando o mantenedor aplica um backport. Por isso, a comparação deve considerar o release completo do pacote, o advisory do fornecedor e, quando aplicável, o estado do livepatch. Apenas comparar o primeiro número exibido pelo software pode produzir falso positivo.

Nível de risco e impacto

Alto, sem CVSS público confirmado na data desta revisão. A vulnerabilidade cruza contas e alcança integridade de bancos de outros tenants. Dependendo do banco alterado, o invasor pode criar usuário WordPress, trocar URL, injetar JavaScript, alterar pedidos ou derrubar a aplicação. Como o registro CVE ainda não fornecia métrica pública, este alerta evita inventar pontuação; a prioridade alta decorre do impacto multi-tenant confirmado.

Em hospedagem, uma conta local ou um site comprometido não deve ser tratado como ator confiável. Código obtido por plugin desatualizado, credencial roubada ou upload malicioso pode satisfazer a condição “acesso local” e transformar uma falha de kernel ou painel em comprometimento de outras contas. Quando o efeito inclui root, escape, execução de PHP ou tomada de administrador, considere também bancos, chaves, tokens, e-mail e backups conectados.

Como verificar se o servidor ou site está vulnerável

Execute o inventário como root e compare a versão completa, inclusive o build após o hífen. Verifique também se o pacote está instalado por RPM e se o comando em PATH aponta para a instalação esperada. Não tente criar ou modificar banco de outra conta para testar: isso altera dados de terceiros e pode constituir incidente.

wp-toolkit --version 2>/dev/null || /usr/local/bin/wp-toolkit --version 2>/dev/null
rpm -qa | grep -Ei '^wp-toolkit|wp-toolkit-cpanel'
readlink -f /usr/local/bin/wp-toolkit 2>/dev/null
stat /usr/local/bin/wp-toolkit 2>/dev/null

Versão 6.11.2-10794 ou inferior deve ser tratada como vulnerável. Saída ausente não comprova que o WP Toolkit não existe: confirme pacotes, plugins do WHM e diretórios antes de concluir. Se mais de uma instalação aparecer, determine qual delas o cPanel realmente chama e remova versões órfãs somente após avaliar dependências.

Como corrigir ou mitigar

Atualize para 6.11.3 ou posterior usando o instalador oficial indicado pelo cPanel. Faça backup dos bancos e configurações, preserve acesso WHM/SSH alternativo e não baixe o script de espelho não confiável. Como contenção de curtíssimo prazo, restrinja o acesso ao WP Toolkit e suspenda contas suspeitas, mas mantenha o patch como solução definitiva.

bash <(curl -fsSL https://wp-toolkit.plesk.com/cPanel/installer.sh || wget -qO- https://wp-toolkit.plesk.com/cPanel/installer.sh) --version 6.11.3
wp-toolkit --version 2>/dev/null || /usr/local/bin/wp-toolkit --version 2>/dev/null

Antes da mudança, confirme backup restaurável, acesso alternativo, espaço em disco e integridade dos repositórios. Depois, valide o serviço e a aplicação em vez de considerar o comando concluído como prova suficiente. Mitigações reduzem exposição durante a janela de manutenção, mas devem ser documentadas e removidas ou reavaliadas após o patch definitivo.

Validação posterior e resposta a incidentes

Abra o WP Toolkit pelo WHM e por uma conta de teste, valide listagem, instalação, clone, staging, backup e acesso ao banco apenas dentro da própria conta. Revise logs do painel, MySQL/MariaDB e WP Toolkit em busca de criação, alteração, exclusão ou concessões incomuns. Compare usuários e privilégios do banco, administradores WordPress, URLs, opções e conteúdo crítico.

Atualizar impede novas explorações pela falha conhecida, mas não remove persistência criada antes do patch. Se houver usuário inesperado, arquivo alterado, webshell, cron desconhecido, chave SSH nova, processo anormal ou acesso administrativo sem explicação, isole o ativo, preserve logs e acione resposta a incidentes. Faça rotação de segredos a partir de um equipamento confiável e só restaure o serviço depois de entender o alcance.

Medidas adotadas pela WebinHost

Nos servidores cPanel gerenciados, a WebinHost inventaria o build ativo, preserva backups, aplica o instalador oficial e testa o WP Toolkit e o banco após a atualização. Imunify360 ajuda a bloquear o comprometimento inicial de sites e detectar código malicioso; CloudLinux/CageFS limita processos entre contas. Como esta falha ocorre na camada administrativa de criação de bancos, essas tecnologias complementares não substituem o WP Toolkit 6.11.3+.

Nos serviços em que o gerenciamento da camada de servidor faz parte do contrato, o fluxo da WebinHost inclui acompanhamento dos canais de segurança dos fornecedores, inventário do componente, avaliação de exposição, aplicação controlada da correção disponível e validação posterior. Quando o kernel e a distribuição são compatíveis, o KernelCare reduz a janela de exposição ao aplicar live patches sem aguardar uma reinicialização; quando a correção exige um novo kernel ou o fornecedor não oferece live patch, a equipe planeja a atualização e o reboot conforme o risco e a janela operacional.

O Imunify360 complementa essa resposta com firewall de aplicação, detecção de malware, defesa proativa e inteligência de reputação nos planos elegíveis. Essas camadas ajudam a bloquear ou detectar tentativas, mas não substituem a correção do pacote vulnerável. CloudLinux e CageFS também aumentam o isolamento entre contas, sem transformar uma versão desatualizada em versão segura.

Referências oficiais e técnicas

• cPanel — boletim oficial CVE-2026-87900
• CVE.org — CVE-2026-87900
• WP Toolkit — instalador oficial para cPanel

Nota técnica: distribuições Linux e painéis frequentemente aplicam backports. O número exibido por um pacote pode ser diferente da versão upstream e ainda conter a correção. Compare sempre o pacote com o advisory da distribuição ou do painel. Não execute prova de conceito em produção; os comandos deste boletim são de inventário e verificação.