Duas falhas críticas no PHP, ambas avaliadas em 9,2 de 10 no CVSS v4.0, levaram o projeto a programar uma atualização de segurança para 21 de outubro de 2026, às 14h UTC. A recomendação oficial é preparar a atualização agora e instalá-la assim que a versão corrigida estiver disponível.
O alerta interessa a quem administra sites, lojas virtuais e aplicações web, inclusive instalações de WordPress. Mas há um ponto importante: atualizar o WordPress, os temas e os plugins não atualiza automaticamente o PHP executado pelo servidor. Em muitos planos de hospedagem, essa responsabilidade fica com o provedor.
O que já está confirmado
O comunicado do projeto PHP confirma duas vulnerabilidades críticas e a pontuação CVSS de 9,2. Também informa que os detalhes completos, as versões afetadas e as versões corrigidas seriam publicados junto com a atualização.
Na manhã de 21 de outubro, portanto, ainda não era seguro tratar listas de versões ou condições de ataque divulgadas por terceiros como informação definitiva. A designação “PHP2Shell”, usada em parte da cobertura, também não é o nome oficial dado pelo projeto.
Isso não reduz a urgência. Uma falha capaz de permitir execução remota de código pode dar a um invasor a possibilidade de executar comandos com as permissões do processo PHP. O impacto potencial inclui alteração de páginas, acesso a dados e instalação de ferramentas maliciosas. O alcance real, porém, depende das versões e das condições que o aviso técnico oficial confirmar.
Por que atualizar o WordPress não basta
O PHP é a camada que processa grande parte do código de sistemas como WordPress, Drupal, Joomla, Magento e aplicações desenvolvidas com frameworks como Laravel. O painel do WordPress cuida do núcleo do sistema, dos plugins e dos temas; a versão do PHP pertence ao ambiente de hospedagem ou ao servidor.
Em hospedagem compartilhada ou gerenciada, o provedor costuma controlar essa camada. Em servidores virtuais, máquinas próprias ou ambientes em nuvem, a responsabilidade pode ser da equipe técnica. A primeira ação, por isso, não é clicar em uma atualização qualquer: é descobrir quem administra o PHP e qual canal oficial será usado para entregar a correção.
Também não se deve concluir que todo site com PHP está automaticamente vulnerável. Até a publicação do boletim completo, faltavam as versões e os requisitos exatos para avaliar cada ambiente.
O que preparar antes da atualização
- Identifique o responsável técnico. Confirme se o PHP é mantido pelo provedor de hospedagem, pela empresa que cuida do site ou por uma equipe interna.
- Registre a versão e o ambiente atuais. Use o painel oficial da hospedagem, o inventário do servidor ou o suporte do provedor. Não exponha páginas públicas com informações detalhadas do PHP apenas para fazer essa verificação.
- Garanta um backup testado. Preserve arquivos, banco de dados e configuração fora do mesmo servidor. Verifique se existe um procedimento de restauração antes de alterar o ambiente.
- Planeje uma janela de manutenção. A atualização pode exigir reiniciar serviços e testar componentes. Lojas, áreas de login, formulários e tarefas agendadas merecem verificação específica.
- Acompanhe apenas canais confiáveis. Dê prioridade ao PHP.net e aos avisos do sistema operacional ou do provedor. Evite pacotes, comandos e supostas correções recebidas por mensagens ou fóruns.
Trocar de uma versão antiga para outra linha principal pode causar incompatibilidades com aplicações e extensões. Se o provedor oferecer uma correção dentro da mesma linha suportada, essa costuma ser a mudança mais previsível. Uma migração maior deve ter testes e plano de retorno próprios.
O que conferir depois de aplicar a correção
Depois da atualização, confirme a versão efetivamente carregada pelo servidor e teste as funções críticas do site. Abrir apenas a página inicial não é suficiente: autenticação, pagamentos, formulários, envio de email, integrações e tarefas em segundo plano podem usar caminhos diferentes.
Revise também os registros do servidor e da aplicação em busca de erros novos ou atividade incomum. A correção fecha a vulnerabilidade, mas não remove uma possível invasão anterior. Contas administrativas desconhecidas, arquivos inesperados, alterações não autorizadas ou conexões suspeitas exigem preservação de evidências e resposta a incidentes, não apenas a reinstalação do PHP.
O CERT-EU recomenda ação imediata quando a correção estiver disponível. Para sistemas expostos à internet que não possam ser atualizados, isolar a aplicação ou retirá-la temporariamente do ar pode ser necessário. Essa decisão interrompe o serviço e deve ser tomada pelo responsável técnico com base no boletim final, no nível de exposição e no plano de continuidade.
O que muda para quem só é dono do site
Quem contratou hospedagem e não administra servidores deve abrir um chamado com perguntas objetivas: qual versão do PHP atende o site, se o ambiente está entre os afetados e quando a correção será aplicada. A resposta deve vir do provedor, não de uma ferramenta desconhecida instalada no WordPress.
O alerta é global e não depende de o site estar no Brasil ou em Portugal. O fator decisivo é o modelo de hospedagem e quem controla o ambiente PHP. Preparar essa cadeia de responsabilidade agora reduz o tempo entre a publicação da correção e a proteção efetiva do site.
