Em 21 de outubro de 2026, o projeto PHP publicou um PHP security release que corrige duas vulnerabilidades críticas na linguagem. O problema não é específico do WordPress: afeta qualquer servidor que hospede uma aplicação escrita em PHP.
O Que o PHP Security Release Corrige
O anúncio está no arquivo oficial do php.net, que descreve duas falhas classificadas como críticas e recomenda atualização imediata das instalações. A gravidade é o que define a urgência: falhas com essa classificação normalmente envolvem execução remota de código ou corrupção de memória no processo do servidor web.
Provedores de hospedagem podem estar aplicando patches e regras de WAF para conter o problema. Isso não substitui a atualização do pacote no sistema, porque a regra de firewall bloqueia tentativas conhecidas e não corrige o código vulnerável. Do lado do WordPress, nenhuma atualização do core é necessária ou está planejada para esses casos.
Como Saber Qual Versão de PHP o Servidor Executa
Identificar a branch em uso vem antes de qualquer outra coisa, porque o patch só existe para as linhas ainda mantidas pelo projeto. Em uma instalação WordPress, o caminho é Tools > Site Health > Info > Server, onde aparece a versão do PHP em execução. A maioria dos painéis de hospedagem expõe o mesmo dado na configuração da conta.
Em servidor próprio, php -v na linha de comando resolve em segundos, e o retorno mostra a versão e o build exatos. Vale conferir também qual versão o serviço web está usando de fato, já que uma CLI diferente da do FPM pode reportar números distintos no mesmo host.
Versões Anteriores à 8.2 Ficaram Sem Correção
O projeto PHP encerrou o suporte de segurança para versões anteriores à 8.2, então instalações 8.1 e mais antigas não recebem esse patch. Para esses casos, o único caminho é migrar de branch, e isso pede teste: a tabela de compatibilidade do WordPress com PHP mostra o que cada versão do core suporta.
A ordem que costuma funcionar é subir a versão em staging, rodar o site e os plugins, ler os logs de erro e só então aplicar em produção. Em hospedagem compartilhada, o seletor de versão do PHP no cPanel ou equivalente já resolve. Em contêiner, a tag da imagem precisa ser trocada e o build refeito, senão o host continua subindo a mesma camada antiga.
Quando Tirar o Servidor do Ar É a Decisão Correta
O UK National Cyber Security Centre publicou um aviso recomendando que organizações sem condição de corrigir imediatamente considerem tirar o sistema do ar até a mitigação completa. A orientação é citada pelo próprio anúncio do WordPress e aparece em agências de outros países.
Se houver sinal de comprometimento, o FAQ do WordPress sobre site invadido descreve o passo a passo de limpeza e recuperação. Na prática, acho que a decisão de desligar depende da exposição: um host público com PHP antigo tem risco diferente de um ambiente interno que serve um único cliente. O que não muda é registrar a versão encontrada e o que foi feito, para o próximo ciclo de patch não começar do zero.
Conclusão
O patch do PHP está disponível desde 21 de outubro de 2026, e o que separa um servidor corrigido de um exposto é a branch instalada. Conferir a versão, migrar o que estiver abaixo da 8.2 e verificar se o provedor já aplicou o pacote cobre a maior parte dos casos. Se nada disso for viável no prazo, tirar o sistema do ar é recomendação formal de agência de segurança, não exagero.
Fonte: https://wordpress.org/news/2026/10/critical-php-security-release/org