PHP2Shell: a falha crítica no PHP que pede atualização hoje

Na quarta-feira (21/10/2026), a equipe do PHP lançou uma atualização de emergência para corrigir duas falhas críticas no núcleo da linguagem: CVE-2026-109618 e CVE-2026-109619. Apelidadas de PHP2Shell, as duas receberam nota 9,2 de 10 na escala CVSS v4.0 e podem permitir que um invasor, sem nenhum login, execute código no servidor que roda o seu site ou sistema. Se a sua empresa tem site, e-commerce, portal ou sistema feito em PHP, este texto é para você. A boa notícia é que a correção existe. A má é que ela só protege quem aplicar.

O que aconteceu, sem tecniquês

O PHP é a linguagem por trás de uma enorme parte da web, incluindo WordPress, Drupal e Joomla. As duas falhas estão no próprio motor do PHP, não em um plugin nem em código mal escrito do seu projeto. São erros no jeito como o PHP gerencia a memória: em termos simples, ele pode deixar sobras de uma requisição na memória, e um atacante consegue manipular essas sobras para rodar comandos próprios. O PHP avisou publicamente no dia 20/10 que viria uma correção e liberou os detalhes e as versões corrigidas no dia 21/10. A descoberta é da Wiz Research, que identificou versões afetadas desde o PHP 5.4 até o 8. A agência americana CISA classificou o caso como crítico, disse que ele atinge instalações de PHP que atendem requisições web e pediu atualização imediata. Sobre exploração: até o alerta da CISA, em 21/10, não havia ataques observados. Mas empresas de segurança já apontavam que a pesquisa estava sendo reproduzida de forma independente e que um exploit público deveria surgir em breve. Na prática, a janela para atualizar é curta.

Quem está em risco

• Qualquer site ou sistema em PHP que responda a requisições pela internet: institucional, e-commerce, landing page, portal, intranet, API.
• Instalações de WordPress, Drupal e Joomla. A pesquisa da Wiz demonstrou execução remota sem autenticação nesses três.
• Sistemas em versões antigas do PHP. A lista oficial de correções cobre as versões 8.5, 8.4, 8.3 e 8.2.
• Sites em hospedagem compartilhada ou gerenciada. Nesse caso quem atualiza é o provedor, mas vale confirmar por escrito.

Como identificar se você está exposto

1. Descubra a versão. No servidor, rode php -v. Atenção: o PHP de linha de comando pode ser diferente do PHP que atende o site (PHP-FPM ou Apache). Confira os dois.
2. Compare com as versões corrigidas: 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Se você instala o PHP pelo gerenciador de pacotes do sistema operacional, a numeração pode ser outra. Nesse caso, confira no aviso do fabricante da sua distribuição se o pacote já traz a correção.
3. Olhe os containers. Não basta atualizar o servidor: é preciso conferir a imagem base e reconstruir as imagens.
4. Pergunte à hospedagem. Peça a versão do PHP e a confirmação de que a correção foi aplicada.
5. Faça o inventário. Liste todos os sites e sistemas PHP da empresa, inclusive os esquecidos: campanhas antigas, ambientes de teste abertos na internet, sistemas de terceiros.

Sinais clássicos de invasão para procurar: arquivos .php novos ou alterados (principalmente em pastas de upload e temporárias), processos estranhos disparados pelo servidor web, conexões de saída para endereços desconhecidos, picos de memória e erros 500 sem explicação, usuários administradores que ninguém criou e tarefas agendadas desconhecidas.

Como resolver

1. Faça backup completo, de arquivos e banco, antes de mexer em qualquer coisa.
2. Atualize para uma versão corrigida.
3. Reinicie o serviço (PHP-FPM ou Apache). Atualizar o pacote sem reiniciar pode manter rodando o processo antigo.
4. Teste os fluxos críticos: login, formulários, checkout, integrações. O ideal é testar antes em um ambiente de homologação.
5. Revise os sinais de invasão listados acima, olhando principalmente as últimas semanas.
6. Se encontrar indício de invasão: isole o ambiente, preserve os logs, restaure de um backup limpo, troque todas as credenciais (banco de dados, chaves de API, senhas de administrador, arquivos .env) e avalie a obrigação de comunicar a ANPD e os titulares, conforme a LGPD.

E enquanto não dá para atualizar? O próprio PHP afirma que não há mitigação completa e que atualizar é a única escolha segura. Ajustes de configuração e filtros na frente da aplicação podem reduzir a superfície de ataque por algumas horas ou dias, mas são paliativo, não solução.

Como prevenir o próximo

• Inventário vivo: saber o que roda PHP, onde e em qual versão.
• Atualização como rotina: uma janela fixa por mês e uma trilha rápida para falhas críticas.
• Homologação e testes mínimos, para atualizar sem medo de quebrar.
• Versões com suporte: evitar PHP fora do ciclo de manutenção.
• Menos privilégio: usuário do servidor web com o mínimo de permissões, banco com acesso restrito e segredos fora do código.
• Backups testados: backup que nunca foi restaurado é só uma esperança.
• Monitoramento: alerta para arquivos alterados, processos incomuns e tráfego fora do padrão.
• Assinar os avisos de segurança do PHP e do seu CMS ou framework.

Como a Roant pode ajudar

A Roant trabalha com engenharia de software e consultoria de tecnologia, e manter sistemas seguros e no ar faz parte disso. Em um caso como o PHP2Shell, atuamos em três frentes:

• Diagnóstico de exposição: mapeamos os sites e sistemas PHP da sua operação (versões, hospedagem, dependências) e entregamos uma lista priorizada do que corrigir primeiro, em linguagem clara.
• Correção e mitigação: atualizamos com teste, reiniciamos e validamos. Enquanto a janela de atualização não chega, aplicamos medidas para reduzir a exposição e investigamos sinais de invasão. Se houver incidente, ajudamos na contenção e na recuperação.
• Prevenção: montamos a rotina de atualização, documentamos como o ambiente está configurado e treinamos o seu time. Sem lock-in: o conhecimento fica com você. Para sistemas legados em versões antigas do PHP, planejamos a migração.

Não tem certeza se a sua empresa está exposta? Conte o problema. Se não for para a gente, dizemos e indicamos quem é. Fale conosco em roant.com.br ou em contato@roant.com.br. Fontes: CISA (alerta de 21/10/2026), notas da versão PHP 8.4.27 no GitHub, Wiz Research, Rapid7, Qualys, Cisco Security Advisory e UW-IT.