PHP2Shell: três perguntas ao fornecedor do seu site

O fato: duas falhas, nota 9.2 e um lançamento antecipado

Em 21 de outubro de 2026, a equipe de segurança do PHP publicou uma versão de emergência para corrigir duas falhas críticas. As duas permitem execução remota de código sem autenticação: um atacante consegue rodar comandos no servidor sem precisar de login. Alegações sobre as falhas começaram a circular antes da data marcada, e o projeto antecipou a correção em um dia. Em 20 de outubro, o PHP confirmou o lançamento emergencial e o CERT-EU emitiu alerta.

As falhas receberam os códigos CVE-2026-109618 e CVE-2026-109619. Segundo a Help Net Security, a primeira explora corrupção de memória quando o servidor fica sem memória. A segunda deixa o estado interno de uma requisição sobreviver depois que a memória foi liberada. A equipe do PHP deu nota 9.2 de 10 às duas, na escala CVSS.

As versões corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35, conforme o boletim de segurança da AWS. Tudo abaixo disso, nesses ramos, está vulnerável. O PHP 8.1 e as versões anteriores estão em fim de vida e não recebem correção oficial.

O alerta virou exploração real. No aviso inicial, a CISA, agência de cibersegurança dos Estados Unidos, disse não ter observado ataques. Depois, a watchTowr afirmou ter visto exploração em andamento e, segundo a SOCRadar, em 26 de outubro de 2026 a CISA incluiu as duas falhas no seu catálogo de vulnerabilidades exploradas. A NSA foi mais dura: afirmou que as falhas muitas vezes abrem caminho direto ao sistema de arquivos ou ao banco de dados, e recomendou tirar o sistema do ar se a atualização imediata não for viável. O NCSC, do Reino Unido, recomendou o mesmo.

A tese: o problema não é o bug, é a terra de ninguém

Falhas críticas aparecem todo ano. O que torna esta diferente para quem dirige uma empresa é onde ela mora. O PHP não é o seu site. É a camada embaixo dele, que roda WordPress, Laravel e boa parte dos sistemas web em produção.

E essa camada costuma não ter dono. A agência que fez o site entregou o projeto e saiu. A hospedagem diz que cuida do servidor, mas não da versão da linguagem. O TI interno acha que é com a agência. Na prática, ninguém atualiza nada até que algo quebre.

Os números do VirusTotal mostram o tamanho disso. Cerca de 272 mil endereços IP rodam ramos do PHP ainda suportados, do 8.2 ao 8.5. Cerca de 758 mil rodam ramos em fim de vida, do 5.4 ao 8.1. Para cada servidor que pode simplesmente aplicar a correção, há quase três que dependem de remendo ou migração. As estimativas totais de exposição variam muito: a OX Security fala em quase 2 milhões de servidores PHP expostos, e a Censys identificou mais de 6,2 milhões de hosts que casam com suas consultas. Não há número padronizado. Há, porém, uma conclusão consistente: o legado é a regra, não a exceção.

Um detalhe pega o pequeno e médio empresário de surpresa. Segundo a Wordfence, as atualizações automáticas do WordPress não aplicam essa correção. O painel pode estar todo verde, com plugins e tema em dia, e o servidor continuar aberto. Quem tem e-commerce em WordPress e acredita que "o sistema se atualiza sozinho" está tranquilo pelo motivo errado.

Por que remendo não é solução

Houve paliativos, e eles servem para ganhar tempo. A comunidade convergiu para desligar a opção session.upload_progress.enabled no arquivo de configuração do PHP, recurso ligado ao vetor de ataque e presente desde a versão 5.4. A Cloudflare ofereceu regras de firewall, mas o próprio CTO da empresa chamou a medida de "STOPGAP", um tapa-buraco temporário. Para versões antigas, a equipe do PHP publicou correções mínimas em código-fonte para 7.4, 8.0 e 8.1, e o mantenedor Ondřej Surý empacotou correções como novas revisões de pacote.

Tudo isso compra semanas, não anos. Um servidor em PHP 7.4 remendado continua em uma versão sem suporte, e a próxima falha talvez não tenha voluntário disposto a fazer backport. A decisão real não é "aplicamos o patch?". É "quando migramos?".

Há um agravante que muda o cálculo de risco daqui para frente. Segundo relatos sobre a descoberta, ainda não confirmados em fonte primária, a Wiz e a Calif usaram o GPT-5.6 Sol, da OpenAI, e o Gemini 4 Argon, do Google, para localizar e verificar as falhas. Mesmo com essa ressalva, a direção é clara: a IA acelera a descoberta de vulnerabilidades em código antigo, e a ferramenta que ajuda pesquisadores também ajuda atacantes. Código legado, que parecia seguro por obscuridade, vai ser vasculhado com uma velocidade que nenhum time humano tinha. Manter PHP sem suporte vai sair mais caro do que já saía.

As três perguntas

Não é preciso entender de PHP para cobrar quem entende. Basta mandar agora uma mensagem ao fornecedor do site ou do sistema com três perguntas:

Qual versão de PHP roda aqui, exatamente? A resposta tem que vir com número, não com "está atualizado". Se for 8.2.35, 8.3.36, 8.4.27, 8.5.12 ou superior, ótimo. Se for 8.1 ou anterior, você está em fim de vida e precisa de um plano de migração com data.
Quem é responsável por atualizar essa versão, e em quanto tempo, segundo o contrato? Se a resposta for "depende" ou "não está no escopo", você encontrou a terra de ninguém. Falha crítica explorada pede horas ou poucos dias, não o próximo ciclo de manutenção.
Se este servidor for invadido, o que o atacante encontra? Dados de clientes, senhas de banco, chaves de API de serviços de pagamento ou de IA guardadas em arquivo de configuração. Quanto mais coisa sensível no mesmo servidor, maior o estrago de uma única falha.

A terceira pergunta é a mais desconfortável e a mais valiosa. Muitas empresas conectaram chatbots, integrações e automações de IA ao site, e as chaves dessas integrações frequentemente ficam no mesmo servidor que roda o PHP. Um invasor que toma o servidor pode levar junto a conta de IA da empresa, com a fatura correspondente.

O que isso significa para empresas brasileiras

Até o fechamento deste texto, não encontramos manifestação de órgãos brasileiros, como CTIR Gov, CERT.br ou ANPD, sobre o caso. Isso não reduz o risco. Servidores vulneráveis não respeitam fronteira, e o alerta da Wordfence sobre o WordPress atinge em cheio o varejo online e os sites institucionais que rodam na plataforma.

Para empresas dos setores jurídico, de saúde e financeiro, a conta é ainda mais direta. Escritórios guardam documentos de clientes, clínicas guardam dados de saúde, financeiras guardam dados cadastrais e bancários. Uma invasão nesses ambientes é incidente com dados pessoais, com dever de avaliação e comunicação previsto na LGPD, além do dano de reputação.

A recomendação prática tem duas velocidades. Agora: confirmar a versão, aplicar a correção ou o paliativo e, se não houver como corrigir já, seguir o conselho da NSA. Tirar do ar é mais barato que vazar. Nos próximos 90 dias: colocar no contrato quem responde pela atualização da camada de base, com prazo para falhas críticas, e orçar a migração de tudo que roda em versão sem suporte.

O gestor que fizer as três perguntas nos próximos dias vai descobrir uma de duas coisas: que está protegido, ou que ninguém sabia responder. As duas informações valem muito mais do que o tempo de mandar a mensagem.

PHP2Shell: três perguntas para fazer agora ao fornecedor do seu site