O que aconteceu em 21 de outubro
O comunicado oficial do projeto PHP resume: as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 corrigem duas vulnerabilidades críticas que podem permitir execução remota de código sem autenticação. São as CVE-2026-109618 e CVE-2026-109619, com severidade 9,2 na escala CVSS, e segundo a análise publicada pelo Google Cloud afetam todas as versões do PHP da 5.4 até a 8.5.11. Em outras palavras: praticamente todo PHP em produção no mundo, até aquela data.
A divulgação foi atropelada. Segundo a PHP Foundation, o embargo combinado entre os fornecedores foi quebrado mais de seis horas antes da hora marcada, e o lançamento, previsto para 22 de outubro, foi antecipado em um dia. A raiz do problema vinha sendo investigada desde uma auditoria de 2024 e foi reportada de forma independente por mais de uma equipe de pesquisa em agosto de 2026. A CISA, agência de segurança cibernética do governo americano, publicou alerta no mesmo dia e, em 26 de outubro, incluiu as duas falhas no catálogo de vulnerabilidades exploradas ativamente (KEV). O FBI publicou aviso próprio em 23 de outubro.
Por que mod_php é o pior caso e PHP-FPM não está a salvo
A PHP Foundation descreve o cenário mais grave em uma frase: no Apache com mod_php, uma requisição sem autenticação pode disparar a falha antes de qualquer código da aplicação rodar. Isso significa que não importa se o sistema tem login, se o framework é moderno ou se o código foi revisado: a falha está no tratamento da requisição pelo próprio PHP, antes de o seu programa começar. É a configuração típica de hospedagens compartilhadas antigas e de servidores montados há dez anos e nunca revisitados.
Quem roda PHP-FPM, o modelo mais comum em servidores configurados recentemente, está em situação melhor, mas não segura: a mesma fonte confirma execução remota de código em PHP-FPM através de caminhos de código da aplicação. A diferença prática é que, no FPM, a exposição depende do que a aplicação faz com uploads e sessões; no mod_php, basta o servidor existir. Em ambos os casos, a única solução completa é a atualização.
A parte que importa para quem tem sistema antigo: 8.1 e anteriores não têm correção
O comunicado do projeto é direto: PHP 8.1 e versões anteriores não recebem mais atualizações do projeto PHP. A equipe de segurança publicou backports mínimos em código-fonte para 7.4, 8.0 e 8.1, destinados a quem compila o próprio PHP ou não tem um fornecedor com suporte estendido, e orienta a contatar a distribuição Linux ou o fornecedor para saber se há correção retroportada. Para a empresa que tem um sistema em PHP 7 numa hospedagem comum, isso se traduz em: ninguém vai corrigir isso por você.
A orientação da CISA para esse caso é a mais dura que uma agência costuma dar: organizações que não conseguem atualizar imediatamente, ou que continuam usando PHP 8.1 ou versões anteriores sem suporte, devem tirar os sistemas baseados em PHP do ar até que possam ser corrigidos ou atualizados. Foi o que se viu no Brasil em 21 de outubro: segundo o Tecnoblog, serviços da Anatel ficaram inacessíveis e o SEI, Sistema Eletrônico de Informações usado por órgãos públicos, continuava fora do ar no dia seguinte. E o calendário segue: o PHP 8.2 chega ao fim da vida em 31 de dezembro de 2026. Quem estiver nele em janeiro volta à mesma situação.
Mitigação temporária quando não dá para atualizar hoje
O projeto PHP publicou medidas para quem não consegue atualizar de imediato, com uma ressalva em letras garrafais: elas reduzem a exposição a caminhos de ataque específicos, mas não tornam a instalação segura. A primeira é contraintuitiva: definir memory_limit como -1, ou seja, sem limite, de preferência via php_admin_value no pool do FPM ou na configuração do Apache, para que a aplicação não consiga sobrescrever. A razão é que a CVE-2026-109618 explora justamente a falha de alocação de memória controlada pelo atacante; remover o limite do PHP elimina esse gatilho, embora uma falha de alocação do sistema ainda possa alcançar o código vulnerável.
A segunda é reduzir post_max_size: 8M para aplicações sem upload de arquivos, 32M quando o upload é necessário, mantendo upload_max_filesize abaixo disso. A terceira, para a CVE-2026-109619, é desativar session.upload_progress.enabled e reiniciar todos os workers, pela configuração do servidor e não por ini_set, que chega tarde demais. O comunicado também recomenda limites de tamanho e de quantidade de campos no servidor web ou proxy e corrigir erros fatais que um atacante consiga provocar. E repete: não existem mitigações completas; atualizar é a única escolha segura.
Como a JBKR tratou os sistemas sob sustentação (método, não heroísmo)
Na semana da divulgação, o roteiro foi o mesmo para todos os clientes com sistemas em PHP sob plano mensal, e ele não tem nada de especial: é o que um inventário mantido permite fazer. Primeiro, a lista de versões por sistema e por servidor, que já existia porque faz parte do diagnóstico de entrada de cada cliente. Segundo, a ordem por exposição: mod_php exposto à internet primeiro, PHP-FPM exposto em seguida, sistemas internos por último. Terceiro, a ação por faixa: quem estava em 8.2 ou superior recebeu a versão corrigida; quem estava em 8.1 ou anterior recebeu as mitigações temporárias no mesmo dia e uma data para a atualização de versão, que agora deixou de ser opcional.
Quarto, o registro: o que foi feito, em que servidor, em que hora, por escrito, para o cliente e para o eventual questionamento futuro de um auditor ou de um titular de dados. Esse registro é também o que permite dizer com segurança a um cliente que ele não foi afetado, em vez de supor. O plano de sustentação da JBKR prevê resposta no mesmo dia útil e início do atendimento a falhas críticas em até 24 horas; uma vulnerabilidade com exploração ativa conta como falha crítica, mesmo que o sistema esteja funcionando normalmente.
Custo de adiar: a falha como argumento de modernização
A conversa sobre atualizar o PHP costuma ser adiada porque o sistema funciona e porque atualizar tem custo: bibliotecas incompatíveis, funções removidas, testes que ninguém escreveu. O artigo sobre manter ou modernizar um sistema PHP, Java ou .NET traz as faixas de custo de cada caminho, e a atualização de versão é quase sempre o mais barato deles. O que o PHP2Shell mudou foi a outra coluna da conta: o custo de não atualizar deixou de ser teórico e passou a ter data, 21 de outubro, e consequência concreta, sistema fora do ar por orientação oficial.
Vale ser honesto sobre o que a atualização resolve e o que não resolve. Subir de PHP 7.4 para 8.3 não torna um sistema antigo moderno; resolve a exposição a esta falha e às próximas, que virão, porque o PHP corrige vulnerabilidades em versões suportadas e só nelas. É o primeiro passo de qualquer roadmap de modernização, e por isso aparece como a primeira ação em praticamente todo diagnóstico que a JBKR entrega. O artigo sobre migração para a nuvem explica por que atualizar a versão e mudar de servidor são decisões separadas, mesmo quando acontecem juntas.
Checklist de uma página e próximo passo
Para quem tem um sistema PHP e não sabe por onde começar: descubra a versão exata em cada servidor, incluindo o de homologação e aquele que só roda o relatório mensal. Descubra se roda em mod_php ou PHP-FPM. Se a versão for 8.2 ou superior, aplique a versão corrigida hoje. Se for 8.1 ou anterior, aplique as três mitigações do projeto PHP hoje, pergunte à hospedagem se há correção retroportada e marque a data da atualização de versão para as próximas semanas, não para o próximo ano. Confirme que existe backup restaurável de antes de 21 de outubro, assunto do artigo sobre backup e ransomware. Registre tudo por escrito.
Se a resposta a qualquer item for "não sei", esse é o sinal de que o sistema não tem dono técnico, e esse é um risco maior que a falha. Na JBKR o diagnóstico inicial de 30 minutos é gratuito, e para sistemas PHP, nesta semana, ele começa pela versão.
