PHP2Shell: duas falhas críticas de PHP e como agir

O que foi publicado e por que agir

Atualizado em 22 outubro 2026. PHP publicou em 21 outubro atualizações para CVE-2026-109618 e CVE-2026-109619, conhecidas como PHP2Shell. O problema está no motor que atende pedidos web, não apenas num plugin de CMS. A exploração pode permitir execução de código sem autenticação num servidor vulnerável. Exige urgência, sem demonstrar que um site específico já foi comprometido.

O aviso inclui PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. PHP considera maior o risco em mod_php e documenta exploração demonstrada antes do código da aplicação. Site pequeno, ausência de login ou plugins atualizados não bastam. Identifique o PHP que realmente serve pedidos e confirme a correção. A exposição depende de versão, fornecedor e configuração; este artigo não determina a situação de qualquer servidor individual.

As duas falhas e versões corrigidas

CVE-2026-109618 envolve corrupção de memória durante tratamento de falta de memória. CVE-2026-109619 envolve estado interno que sobrevive à memória associada e pode ser reutilizado por outro pedido no mesmo trabalhador. A PHP Foundation explica os problemas e a correção. A distinção evita uma receita universal de configuração. Não precisa reproduzir ataques para decidir atualizar; não fornecemos exploração de serviços públicos nem comandos para provocar falhas deliberadas.

Os lançamentos de 21 outubro corrigidos são 8.5.12,8.4.27,8.3.36 e 8.2.35. Consulte o aviso atual antes de intervir, pois podem surgir revisões posteriores. Distribuições podem aplicar backports sem esses números base; Ubuntu apresenta os pacotes em USN-8948-1. Confirme pacote e aviso do fornecedor, não apenas a versão do intérprete. PHP 8.1 e anteriores estão fora do suporte do projeto; um patch do distribuidor não restabelece esse suporte.

CVE-2026-109618 / CVE-2026-109619
PHP 8.2.35 | 8.3.36 | 8.4.27 | 8.5.12

O que pedir ao alojamento e verificar

No alojamento gerido, peça confirmação dos dois CVE, pacote instalado, serviço afetado e processos ativos corrigidos. Inclua domínios, pools, contentores e produtos com PHP, não apenas a consola principal. Uma versão de linha de comandos não prova necessariamente a que serve a web. Como administrador, use o canal documentado pelo fornecedor ou distribuição e mantenha acesso de recuperação e cópia adequada. Evite supostos patches de mensagens ou repositórios não verificados.

Renove processos conforme instruções e verifique versão ou pacote em execução. Teste funções essenciais e registe a aplicação da correção. Atualizar apenas CMS ou limpar cache não substitui corrigir o runtime. Havendo indícios de intrusão, preserve provas e inicie resposta a incidentes: o patch não reverte alterações do atacante. São verificações operacionais, não diagnóstico remoto. Uma página inicial novamente visível ainda exige confirmação técnica e validação funcional.

Sem atualização imediata e limites do WikiURL

PHP alerta que só atualizar resolve completamente. Mitigações temporárias reduzem caminhos específicos, mas não tornam a instalação segura. Não copie ajustes de memória ou sessões sem entender efeitos e alcance. ENISA recomenda priorizar sistemas expostos e considerar isolamento de redes públicas quando necessário. Coordene acesso de gestão seguro e comunicação da interrupção. Regra WAF ou aplicação aparentemente funcional não substitui patch nem garante proteção integral.

O verificador WikiURL ajuda a consultar resposta HTTP e destino público após manutenção, mas não identifica o PHP real nem comprova os CVE corrigidos.200 ou cadeado HTTPS não são análise de vulnerabilidades. Não envie segredos nem publique phpinfo como prova. Guarde separadamente confirmação do fornecedor, verificação dos processos e testes. A notícia exige atualização urgente e resultado comprovado, evitando tanto alegações de intrusão sem provas como tranquilidade por uma página que abre. Não certifica o estado de atualização de uma instalação específica.