A CVE-2026-19632 é uma falha crítica no TranslatePress Multilingual que pode expor um link de redefinição de senha e permitir tomada de conta sem autenticação. A vulnerabilidade afeta versões até 3.3.1 e foi corrigida na 3.3.2.
O que aconteceu
O endpoint AJAX público trp_get_translations_regular podia devolver strings armazenadas pelo mecanismo de tradução. Em uma combinação específica, o URL de redefinição de senha do WordPress era capturado no dicionário de traduções e podia ser consultado por um visitante.
A cadeia depende do salvamento automático de strings, habilitado por padrão, e de o idioma do perfil administrativo ser um idioma secundário publicado. Nessas condições, a mensagem de redefinição pode passar pela tradução e armazenar o endereço que contém login e chave secreta.
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
| Produto ou linha | Afetado / exposto | Corrigido / protegido |
|---|---|---|
| TranslatePress Multilingual | 3.3.1 e anteriores | 3.3.2 ou superior |
A versão vulnerável por si só exige correção; a exposição prática cresce quando salvamento automático está ativo e o administrador usa idioma secundário publicado. Não altere configurações como substituto permanente do patch.
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
Crítico. CVSS 9,8. O atacante não precisa de conta, e o material exposto pode permitir redefinir a senha de um administrador. Com acesso administrativo, é comum chegar à instalação de plugin, execução de PHP e controle total do conteúdo.
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
Confirme versão e configuração do plugin, idioma dos administradores e usuários privilegiados. Evite consultar endpoints com chaves reais; use inventário e logs.
wp plugin get translatepress-multilingual --fields=name,status,version,update,update_version
wp option get trp_settings --format=json
wp user list --role=administrator --fields=ID,user_login,user_email,locale
Versão até 3.3.1 deve ser atualizada mesmo que uma pré-condição pareça ausente. Revise logs de redefinição/login, novos administradores e alterações de perfil. Um idioma vazio no WP-CLI normalmente significa o padrão do site.
Como corrigir ou mitigar
Atualize para 3.3.2 ou posterior. Em seguida, invalide sessões administrativas e considere gerar novos salts se houve janela de exposição. Até concluir, limite o endpoint no WAF somente com regra testada, ou desative o plugin se isso não quebrar a operação.
wp plugin update translatepress-multilingual
wp plugin get translatepress-multilingual --field=version
wp user session destroy --all
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
Teste páginas traduzidas, seletor de idiomas, formulários e e-mails. Revise administradores, sessões, plugins instalados e mudanças de senha. Se houver login suspeito, troque credenciais e salts e faça varredura completa de arquivos e banco.
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
Imunify360 pode bloquear padrões e detectar arquivos maliciosos nos planos elegíveis, enquanto WP Toolkit ajuda no inventário e atualização. A WebinHost prioriza a infraestrutura e componentes contratualmente administrados; contas, plugins e conteúdo do cliente exigem coordenação para evitar perda funcional.
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.
Tutoriais, downloads e serviços relacionados
Use estes materiais para continuar a verificação com segurança:
Referências oficiais e técnicas
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.