O WordPress corrigiu a CVE-2026-64638, um XSS refletido pré-autenticação na tela de login. Um site malicioso pode induzir a vítima a abrir uma requisição especialmente criada; sob condições adicionais fora do controle direto do invasor, a cadeia pode chegar à execução remota de código. A linha atual foi corrigida no WordPress 7.0.3.
O que aconteceu
A vulnerabilidade está no WordPress Core e não depende de um plugin específico. Como é refletida, a carga não precisa ficar salva no site-alvo: ela volta na resposta da página de login. Ainda assim, o ataque exige engenharia social e interação explícita da vítima com conteúdo preparado.
O advisory atribui CWE-79 e CVSS v4 8,9. A possibilidade de RCE não é automática; depende de condições adicionais e do contexto da vítima. Administradores são o alvo mais relevante porque seu navegador autenticado possui permissões para instalar ou modificar componentes.
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 |
|---|---|---|
| WordPress 7.0 | 7.0.0–7.0.2 | 7.0.3 |
| WordPress 6.9 / 6.8 / 6.7 | até 6.9.5 / 6.8.6 / 6.7.5 | 6.9.6 / 6.8.7 / 6.7.6 |
| WordPress 6.6–6.0 | releases anteriores ao backport | 6.6.6 / 6.5.9 / 6.4.9 / 6.3.9 / 6.2.10 / 6.1.11 / 6.0.13 |
| WordPress 5.9–5.0 | releases anteriores ao backport | 5.9.14 / 5.8.14 / 5.7.16 / 5.6.18 / 5.5.19 / 5.4.20 / 5.3.22 / 5.2.25 / 5.1.23 / 5.0.26 |
| WordPress 4.9 / 4.8 / 4.7 | até 4.9.29 / 4.8.28 / 4.7.33 | 4.9.30 / 4.8.29 / 4.7.34 |
O projeto publicou backports até a linha 4.7, mas recomenda usar a versão atualmente suportada. Receber este patch pontual não torna uma linha antiga equivalente à versão moderna em suporte, recursos e endurecimento.
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. O CVSS v4 é 8,9. A interação da vítima reduz automatização, porém uma campanha direcionada a administradores pode usar a sessão do navegador para ações privilegiadas. Painéis expostos e equipes numerosas elevam a superfície de engenharia social.
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
Leia a versão do Core e valide checksums. Compare a linha exatamente com a matriz de releases corrigidos, sem depender apenas de um scanner externo.
wp core version --extra
wp core check-update
wp core verify-checksumsSe a versão é anterior ao release corrigido da própria linha, atualize. Checksums válidos mostram que arquivos oficiais não foram modificados, mas não provam que banco, uploads, plugins e contas estejam íntegros.
Como corrigir ou mitigar
Atualize preferencialmente para a versão estável atual. Quando uma aplicação legada não puder mudar de linha imediatamente, instale ao menos o backport indicado e planeje a migração. Oriente administradores a não abrir links de login recebidos por canais não confiáveis.
wp core update
wp core update-db
wp core verify-checksumsAntes 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 login, logout, recuperação de senha, editor, cron, integrações e cache. Revise usuários, sessões e plugins instalados. Examine logs para URLs de login com parâmetros anormais e correlacione com ações administrativas no mesmo período.
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
A WebinHost mantém a camada de servidor e oferece ferramentas de atualização, isolamento CloudLinux e Imunify360 nos planos elegíveis. Em serviços WordPress administrados, o rollout inclui backup, atualização e teste; fora desse escopo, o proprietário do site deve autorizar e validar mudanças do Core e extensões.
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.
Assistente IA WGS