Quando um aviso de segurança diz que uma requisição sem autenticação pode executar código no servidor, a prioridade muda. No dia 21 de outubro, o projeto PHP publicou correções para duas falhas críticas — CVE-2026-109618 e CVE-2026-109619 — e pediu atualização imediata. O nome que pegou na comunidade foi PHP2Shell, mas o trabalho real começa bem longe do apelido.
O ponto importante para quem mantém aplicação, hospedagem ou infraestrutura não é tentar decorar o detalhe do exploit. É descobrir rapidamente onde o PHP está exposto, qual versão está rodando, quem atualiza o pacote e como validar que os workers voltaram saudáveis. Adiar porque “o site está estável” é justamente o tipo de atalho que transforma uma manutenção planejada em incidente.
O que foi corrigido
As versões PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 corrigem duas vulnerabilidades de execução remota de código sem autenticação. A primeira envolve corrupção de estado depois de uma situação de falta de memória; a segunda, estado de uma requisição que pode sobreviver indevidamente para a próxima. Em ambos os casos, o projeto PHP é direto: atualizar é a única correção completa.
Isso alcança instalações que atendem requisições web, como PHP-FPM, Apache com mod_php, CGI, FrankenPHP e LiteSpeed. A exposição e a confiabilidade do ataque variam conforme SAPI, versão, extensões e configuração, mas isso não muda a decisão operacional: servidor web com PHP precisa entrar no inventário agora.
O checklist que vale fazer antes do fim do dia
- Mapeie o que está em produção. Liste aplicações, containers, jobs web e painéis que executam PHP. Não confie só no repositório principal: CMS, ferramentas internas e imagens antigas costumam ficar fora da primeira lista.
- Confirme a versão que está servindo tráfego. A versão da máquina de build não prova a versão do worker. Verifique o runtime, a imagem em uso e os pacotes do fornecedor da distribuição.
- Atualize pelo canal suportado. Em Linux, priorize o pacote corrigido do fornecedor/LTS quando ele estiver disponível; imagens próprias precisam ser reconstruídas. PHP 8.1 e anteriores já não recebem correções regulares do projeto, embora alguns fornecedores possam manter backports.
- Reinicie os workers e valide de verdade. Atualizar um pacote sem recarregar PHP-FPM, Apache ou o container deixa processos antigos atendendo requisições. Confira health checks, logs e uma rota crítica depois do deploy.
- Registre a decisão. Anote versão anterior, versão corrigida, horário, ambiente e responsável. Quando uma equipe precisa responder a uma falha crítica, esse rastro poupa discussões confusas na próxima janela.
Se não der para atualizar imediatamente
Não trate mitigação como “patch alternativo”. A orientação oficial é clara: só a atualização resolve por completo. Ainda assim, se uma mudança emergencial depender de homologação ou de um fornecedor, há medidas temporárias que reduzem caminhos conhecidos e compram tempo para a troca.
Para a CVE-2026-109618, a recomendação inclui reduzir a superfície de requisições multipart: manter post_max_size conservador, limitar tamanho e estrutura de uploads no proxy/web server e bloquear multipart onde ele não faz sentido. A advisory também cita configurar memory_limit=-1 de forma administrativa como mitigação parcial do caminho confirmado; isso exige cuidado, pois muda o comportamento de memória do serviço e não elimina a falha.
Para a CVE-2026-109619, desativar session.upload_progress.enabled e reiniciar workers reduz o caminho de sessão demonstrado. Em PHP 8.5, fatal_error_backtraces=0 também reduz um caso confirmado. Nenhuma dessas mudanças substitui o pacote corrigido — e algumas podem afetar funcionalidades, por isso devem entrar como alteração temporária, documentada e revisada.
O erro comum: olhar apenas para a aplicação
Falhas desse tipo lembram por que inventário é parte da segurança. Um time pode atualizar o monólito principal e esquecer uma instalação de WordPress em subdomínio, uma ferramenta de suporte, um painel legado ou uma imagem de container usada por outro serviço. O risco não acompanha a importância percebida do projeto; acompanha o que está exposto e sem correção.
Se você cuida de infraestrutura, a comunicação também conta. A mensagem para produto ou negócio não precisa entrar em detalhes de memória: “há correção crítica para execução remota sem login; vamos aplicar, reiniciar os processos e validar as rotas principais”. É específica o suficiente para justificar uma janela e evita o vago “precisamos mexer no servidor”.
PHP2Shell não é uma boa pauta para pânico nem para uma lista de comandos copiada às pressas. É uma pauta para inventário, atualização, reinício e verificação. Se alguma dessas quatro etapas ainda é incerta no seu ambiente, é aí que a manutenção deve começar.
