Como Aplicar o PHP Security Release Crítico no Servidor

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