Sim, você está no caminho certo: a falha está no PHP. Seu WordPress pode ter o core e os plugins atualizados e continuar exposto se o interpretador que executa o site não tiver o patch. Mas mudar de versão no seletor da hospedagem também não demonstra, por si só, que já esteja corrigido.
Vou te contar como abordei isso, porque na SYSDOP passamos dois dias intervindo em servidores por causa disso e, para completar, ainda vieram os avisos de Node.js e Java. Foram incidentes distintos, cada um com sua revisão; ter WordPress não significa que você também esteja usando esses outros runtimes.
A primeira coisa foi identificar qual PHP cada domínio executava de fato. Em um mesmo servidor você pode ter vários ramos, FPM, LiteSpeed e versões privadas usadas pelo próprio painel. O «php -v» do console pode mostrar uma versão diferente da que serve o seu site. Por isso verifiquei o handler, o binário e o pacote correspondente a cada caso, em vez de dar o servidor como coberto com uma única consulta.
Aí apareceu uma armadilha importante: alguns provedores incorporaram a correção mantendo a versão base do PHP. No CloudLinux, por exemplo, tive que verificar a revisão do pacote e seu changelog para confirmar os CVE-2026-109618 e CVE-2026-109619. Ver um número aparentemente antigo não demonstrava que faltava o patch; também não bastava o painel dizer «atualizado».
Enquanto os pacotes chegavam aos diferentes repositórios, apliquei medidas temporárias e revisei as regras do WAF. Mas desativar o progresso de upload de sessões ou bloquear uma forma conhecida do ataque só reduzia a exposição: não tratei isso como substituto do patch.
O próprio aviso do PHP esclarece que não há uma mitigação completa:
https://www.php.net/archive/2026.php#2026-10-21-5
Por exemplo, estas foram as diretivas temporárias.
A segunda é exclusivamente para o PHP 8.5; não se deve copiá-la para os ramos anteriores:
INI:
session.upload_progress.enabled = Off
; Solo en PHP 8.5
fatal_error_backtraces = Off
Elas precisam ficar no php.ini que esse PHP carrega, ou na sua configuração de servidor/pool antes de processar as requisições. Colocá-las em ini_set() dentro do WordPress chega tarde; também não adianta confiar no .user.ini com FPM neste caso. Depois é preciso reiniciar todos os workers afetados e verificar os valores efetivos. Desativar o progresso de upload também pode afetar as aplicações que usam essa função.
Depois de atualizar, verifiquei os processos que continuavam atendendo requisições. Um pacote novo em disco pode conviver com processos que ainda têm o binário anterior carregado. Era preciso renovar os processos correspondentes e verificar outra vez. Com o Node.js encontrei justamente esse problema, além de instalações por usuário e contêineres com seu próprio runtime. Com o Java também era preciso revisar qual JVM cada serviço usava e seu caminho de inicialização; atualizar o Java do console não resolvia automaticamente todas as aplicações.
A parte forense trabalhei separada da aplicação dos patches. Revisei logs de acesso e do WAF, erros e quedas de processos, arquivos modificados, tarefas agendadas e acessos persistentes. Houve tentativas bloqueadas, mas uma requisição marcada como suspeita não demonstra por si só que tenham entrado. Até uma resposta 200 exigia olhar o que tinha sido servido e cruzar com os demais logs. No que foi revisado não encontrei evidência de exploração bem-sucedida; isso descreve o alcance daquela revisão, não uma garantia absoluta.
No seu WordPress eu acrescentaria a comparação dos arquivos do core com seus checksums oficiais, a revisão de plugins e temas segundo sua procedência, administradores e senhas de aplicação desconhecidos, e PHP inesperado em uploads. Tudo isso precisa de contexto: um arquivo recente pode ser uma atualização legítima, e encontrar uma string suspeita dentro das assinaturas do Wordfence não transforma esse arquivo em uma backdoor. Um escaneamento ajuda, mas não certifica por si só que esteja limpo.
Se você tem SSH e WP-CLI, a partir da pasta do WordPress pode começar por estas consultas, com o usuário da conta:
Bash:
wp core verify-checksums --include-root
wp plugin verify-checksums --all
wp user list --role=administrator --fields=ID,user_login,user_registered
A primeira compara o core e avisa sobre elementos adicionais na raiz; a segunda confere os plugins para os quais o WordPress.org oferece checksums; a terceira lista os administradores para revisá-los. Um plugin comercial pode não ter checksums lá, e um aviso de arquivo adicional não significa automaticamente malware. Nenhuma dessas três consultas revisa sozinha o servidor inteiro.
Se você está em hospedagem compartilhada, eu começaria pedindo uma confirmação concreta: que o PHP que executa o seu domínio tem os dois CVE corrigidos, qual pacote ou compilação comprova isso e que os processos que o usam foram renovados. Você não precisa pular para outro ramo maior se o seu provedor corrigiu o atual; se ele está fora de suporte e não tem essa correção, aí é preciso planejar a migração verificando a compatibilidade.
E se aparecerem indícios de intrusão, antes de apagar ou restaurar eu preservaria os logs e uma cópia do estado afetado. Restaurar sem corrigir a porta de entrada pode te deixar no mesmo ponto, e trocar senhas enquanto uma backdoor continua lá também não encerra o caso. Também comparei os sites e serviços antes e depois das mudanças: era preciso corrigir a vulnerabilidade e verificar que os sites continuassem funcionando.
