PHP2Shell: a falha que deixa invadir um site em PHP sem senha, e o que fazer hoje

O que você leva deste artigo

• São duas falhas: CVE-2026-109618, execução remota de código por corrupção depois de falta de memória, e CVE-2026-109619, execução remota por estado global que sobra de uma requisição para a outra.
• Não precisa de login nem de defeito no seu código. O problema está no próprio PHP, e a configuração padrão é vulnerável.
• Versões corrigidas: 8.5.12, 8.4.27, 8.3.36 e 8.2.35, publicadas em 21 de outubro de 2026.
• O projeto PHP afirma que não há mitigação completa. A Cloudflare, que bloqueia o ataque no firewall, pede para atualizar mesmo assim.
• PHP 8.1 e anteriores não recebem correção do projeto. Alguns fornecedores de hospedagem publicaram correção própria, e só o seu pode confirmar.
• A falha foi encontrada com modelos de IA, a primeira parte pela Calif com o GPT-5.6 Sol em agosto, e estava no código desde 2012.
• Quem rodou versão vulnerável depois da divulgação deve tratar senha e chave guardadas no servidor como possivelmente vazadas.

O que foi corrigido em 21 de outubro

Na manhã de 21 de outubro de 2026, horário de Brasília, o projeto PHP publicou quatro versões de uma vez, 8.5.12, 8.4.27, 8.3.36 e 8.2.35, junto com um aviso de segurança cujo título dispensa interpretação: falhas críticas de execução remota de código, atualize agora. São duas falhas, registradas como CVE-2026-109618 e CVE-2026-109619. Os pesquisadores chamaram o conjunto de PHP2Shell, porque o resultado prático é ganhar um terminal no servidor de outra pessoa.

A primeira é descrita pelo PHP como execução remota de código por corrupção depois de falta de memória. A segunda, como execução remota por estado global que fica velho de uma requisição para a seguinte. Nenhuma das duas exige login, senha ou um formulário vulnerável no seu site. E a segunda tem um efeito que preocupa tanto quanto a invasão: ela devolve pedaços da memória do servidor, que é por onde passam as senhas, os tokens de sessão e as chaves de API das outras requisições.

O que define a urgência está numa frase repetida em cada uma das quatro notas de versão: não existem mitigações completas, e atualizar é a única escolha segura. Quando o próprio mantenedor da linguagem escreve isso, ajuste de configuração e bloqueio temporário viram paliativo. O que resolve é a versão nova rodando no servidor.

A divulgação também saiu antes do previsto. Segundo o resumo da Tenable, os identificadores das falhas vazaram em 20 de outubro, e o PHP, que tinha marcado a correção para o dia 22, adiantou a publicação em um dia.

Por que uma falha no PHP pesa tanto

O PHP é a linguagem de servidor de 69,3% dos sites cuja linguagem a W3Techs consegue identificar. Nessa conta entram quase todo WordPress, boa parte das lojas virtuais, sistemas de agendamento, áreas de membros, painéis de hospedagem e muito CRM feito sob medida. Quando o defeito está na linguagem, ele vale para tudo o que roda em cima dela ao mesmo tempo.

A diferença para a falha de plugin, que a maioria das empresas já conhece, está no lugar onde o problema mora. Plugin desatualizado expõe o site que usa aquele plugin. Aqui, o site pode estar com WordPress, tema e plugins em dia e continuar vulnerável, porque o defeito está no interpretador que lê a requisição antes de o WordPress rodar. A Sansec, empresa que acompanha ataques a lojas virtuais, diz que a configuração padrão é vulnerável e lista WordPress, WooCommerce, Magento, Drupal, Joomla, Laravel e phpMyAdmin entre os sistemas afetados nos testes dos pesquisadores.

O modo de instalação também não salva ninguém. O aviso cobre Apache com mod_php, PHP-FPM, php-cgi, FrankenPHP e LiteSpeed, este último comum em hospedagem compartilhada. O PHP considera o risco mais alto no mod_php, o modo em que o PHP vive dentro do processo do Apache, porque ali o ataque pode acontecer antes de qualquer linha de código da aplicação.

Como o ataque funciona, sem receita

Sem entrar em detalhe que ajude quem ataca, o mecanismo é fácil de entender. Todo gatilho conhecido é uma requisição do tipo multipart/form-data, o formato que o navegador usa para enviar formulário com arquivo anexo. O PHP lê esse tipo de requisição sozinho, antes de entregar os dados ao site, e qualquer pessoa pode mandar uma para qualquer endereço em PHP, exista formulário ali ou não.

A primeira falha explora o que acontece quando uma requisição estoura o limite de memória no meio dessa leitura. O motor do PHP deveria abortar de forma limpa e, em vez disso, fica num estado corrompido que pode ser usado para executar código. A segunda deixa sobrar estado de uma requisição para a próxima, o que serve tanto para executar código quanto para ler memória que pertencia a outra pessoa. A Sansec descreve que esse vazamento pode voltar ao atacante dentro do próprio cookie de sessão da resposta.

Isso tem uma consequência para quem precisa investigar depois. O log de acesso padrão do Apache registra endereço, data, caminho, código de resposta e navegador, mas não registra o tipo de conteúdo da requisição. Um ataque bem feito aparece como um POST qualquer, com resposta normal. Log sem erro não prova que nada aconteceu.

O defeito está no interpretador que lê a requisição antes de o site rodar. Atualizar WordPress e plugin não chega nele.

A IA achou a falha, e a IA também encurta o prazo de quem ataca

O defeito estava no código desde o PHP 5.4.0, lançado em 2012, segundo a Sansec. Greg Brockman, da OpenAI, falou em 14 anos. Ninguém encontrou nesse período. Quem encontrou, em 2026, foram equipes usando modelos de IA para revisar código.

Segundo a Fortune, a Calif, empresa da Califórnia especializada em testar sistemas de IA, encontrou a primeira parte do problema em 1º de agosto com o GPT-5.6 Sol, depois de ser convidada pela OpenAI para o programa Patch the Planet. A OpenAI aprofundou a investigação e achou partes que mostraram que a falha era mais grave do que parecia. Em 19 de agosto, a Wiz chegou ao mesmo problema por conta própria, usando o Gemini 4 Argon, o GPT-5.6 Sol e uma ferramenta interna. O aviso do PHP credita Calif, OpenAI e Wiz.

A mesma reportagem registra a ressalva da OpenAI: a capacidade que ajuda a encontrar a falha também ajuda quem quer construir o ataque, e mais rápido. O caso deu exemplo disso no mesmo dia. A Cloudflare ligou regras de bloqueio às 03h02 UTC de 21 de outubro, cerca de nove horas antes da divulgação, e mesmo assim registrou tráfego de ataque e variações do código tentando passar pelas regras. A Sansec situa os primeiros ataques vistos pela Cloudflare às 07h43 UTC, ou 4h43 da manhã em Brasília, horas antes de a correção oficial sair.

Para quem administra site, a lição dura mais que este caso. O intervalo entre uma falha ficar pública e alguém tentar usá-la contra você já era curto e encolheu. Atualização de segurança deixou de ser tarefa para o fim da semana. Escrevemos sobre esse descompasso entre capacidade e verificação quando os laboratórios pediram freio na IA, e este episódio é a versão prática dele.

O que fazer hoje, conforme onde o seu site roda

A pergunta que resolve quase tudo é qual versão do PHP o servidor entrega ao visitante agora. Se o número for 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou maior dentro da mesma linha, essa parte está resolvida. Se for menor, ou se você não sabe, o resto desta seção é com você.

Em hospedagem compartilhada, quem atualiza o PHP é a empresa de hospedagem, e você escolhe no painel qual versão o seu site usa (no cPanel, a tela se chama MultiPHP). Nos servidores compartilhados que conferimos no dia, os pacotes corrigidos foram instalados na mesma manhã da publicação. Confirme qual versão o seu domínio usa e, se for 8.1 ou anterior, pergunte ao suporte se aquele pacote recebeu a correção.

Em VPS ou servidor próprio, a atualização é sua. Atualize os pacotes do PHP e reinicie o Apache e o PHP-FPM, porque o processo que já estava no ar continua com o código antigo na memória até reiniciar. Atenção a um detalhe do Ubuntu: com o PHP instalado de repositório de terceiro, como o PPA mais usado para versões novas, a atualização automática de segurança, na configuração padrão, só instala pacotes dos repositórios oficiais. O PHP desse repositório fica parado até alguém atualizar à mão.

Confira o resultado pela web, não pelo terminal. O PHP que responde na linha de comando pode ser outra instalação, diferente da que atende o site. Num dos servidores que conferimos, o terminal respondia 8.3 e o site rodava 8.2. No WordPress, a versão real aparece em Ferramentas, Saúde do site, aba Informação, seção Servidor. Fora dele, um arquivo temporário que imprime a versão, aberto pelo navegador e apagado em seguida, dá a resposta certa.

Firewall de aplicação compra tempo e não substitui a atualização. A própria Cloudflare escreveu que os clientes devem corrigir o PHP mesmo com a proteção ligada, e as variações de ataque que ela registrou tentando passar pelas regras mostram o motivo.

• Descubra a versão que o site entrega pela web: 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 estão corrigidas.
• Hospedagem compartilhada: confira a versão escolhida no painel e, se for 8.1 ou anterior, confirme a correção com o suporte.
• VPS: atualize os pacotes do PHP e reinicie Apache e PHP-FPM no mesmo passo.
• Ubuntu com PHP de PPA: a atualização automática padrão não cobre esse repositório.
• Com firewall ou sem firewall, atualize. O bloqueio só segura até a atualização chegar.

Se o seu site ficou exposto antes de atualizar

Como a segunda falha lê memória de outras requisições, o dano possível vai além do servidor invadido. Tudo o que passou pela memória do PHP no período pode ter saído: senha de quem fez login, token de sessão, chave de API de gateway de pagamento, de serviço de e-mail ou de IA, senha do banco de dados. A Sansec cita até chave privada de certificado.

A decisão sensata é tratar como possivelmente vazado o que é caro de perder e barato de trocar. Pela ordem: chaves de pagamento e de serviços cobrados por uso, senha do banco de dados, senhas de administrador e as sessões abertas, que se encerram forçando novo login de todo mundo. Trocar uma chave de API leva minutos. Uma chave vazada nas mãos de outra pessoa custa a fatura do mês e, no caso do gateway de pagamento, o dinheiro do cliente.

Se houver sinal de que dado pessoal de cliente saiu, a LGPD entra na conta. O artigo 48 obriga o controlador a comunicar à ANPD e aos titulares o incidente que possa causar risco ou dano relevante, e a Resolução CD/ANPD nº 15, de 2024, fixou o prazo em três dias úteis contados de quando a empresa fica sabendo, em dobro para agente de pequeno porte. Nessa situação, fale com o seu advogado antes de comunicar. O nosso texto sobre LGPD e dados de cliente ajuda a organizar a conversa.

E guarde os logs do período antes que a rotação apague. Eles não provam que nada aconteceu, mas são a única chance de provar que algo aconteceu, e qualquer perícia vai pedir por eles primeiro.

PHP velho virou risco com data marcada

O aviso do PHP é direto sobre versões antigas: 8.1 e anteriores não recebem mais atualização do projeto. Algumas distribuições e fornecedores publicam correção própria, e a orientação oficial é perguntar ao seu fornecedor ou migrar para uma versão suportada.

Conferimos isso nos pacotes dos servidores que administramos. O PHP 8.1 distribuído pelo cPanel recebeu em 20 de outubro uma correção portada para as duas falhas, e o PHP 7.4 mantido pela CloudLinux recebeu a dele em 21 de outubro, que inclusive desliga o recurso de progresso de envio da sessão, parte do caminho do ataque. Quem está em 7.4 nesses servidores ficou protegido desta vez porque o fornecedor decidiu corrigir. Na próxima falha, ele pode decidir que não.

O PHP 8.2 recebe correção de segurança só até 31 de dezembro de 2026. Muito site roda nele hoje, inclusive em hospedagem bem cuidada, e a migração para 8.3 ou 8.4 pede teste: plugin antigo, tema abandonado e integração feita há anos são o que costuma quebrar. A hora de migrar com calma é agora, com dois meses de folga, e não na primeira semana de janeiro, depois da próxima falha.

A pergunta que vale para qualquer site

Tire o nome da falha da frente e sobra uma pergunta que serve para a próxima: quem atualiza o PHP do seu site, e como você fica sabendo que atualizou? Se a resposta for "a hospedagem, eu acho", você está com a maioria, e isso funciona até o dia em que o site está numa versão que a hospedagem não corrige mais, ou num servidor que ninguém olha desde a entrega.

Na ROO3, a gente faz site que aparece no Google e nas IAs e cuida da parte que ninguém vê: escolhe a versão do PHP, acompanha a correção no dia em que ela sai e mede o que o visitante recebe, em vez de confiar no painel. Em 21 de outubro, esse foi o trabalho nos servidores que administramos: versão configurada de cada site, pacote instalado e versão medida no ar.

Se você não sabe qual versão o seu site roda, ou se ele está num servidor que ninguém atualiza desde que foi entregue, fale com a gente. Conferir leva minutos, e a resposta protege mais que qualquer firewall.

Perguntas frequentes

Meu site em WordPress está vulnerável ao PHP2Shell?

Se ele roda numa versão do PHP anterior às corrigidas, sim, mesmo com WordPress, tema e plugins atualizados, porque a falha está no PHP e não no WordPress. As versões corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35, publicadas em 21 de outubro de 2026.

Atualizar o WordPress e os plugins resolve?

Não. A correção é a atualização do próprio PHP no servidor. Em hospedagem compartilhada quem faz é a empresa de hospedagem; em VPS ou servidor próprio, quem administra o servidor, que também precisa reiniciar o Apache e o PHP-FPM depois.

Como descubro a versão do PHP do meu site?

No WordPress, em Ferramentas, Saúde do site, aba Informação, seção Servidor. Em hospedagem com cPanel, a tela MultiPHP mostra a versão escolhida para cada domínio. A prova definitiva é a versão que o site entrega pela web, porque a linha de comando do servidor pode usar outra instalação do PHP.

Uso Cloudflare. Estou protegido?

Mais protegido, não resolvido. A Cloudflare ligou regras de bloqueio antes da divulgação, registrou variações do ataque tentando passar por elas e recomendou que os clientes atualizem o PHP mesmo com a proteção ativa. O projeto PHP diz que não existe mitigação completa.

Preciso trocar senhas e chaves?

Se o site rodou versão vulnerável depois de 21 de outubro, trate como possivelmente vazado o que passa pela memória do servidor: chaves de pagamento e de serviços cobrados por uso, senha do banco de dados, senhas de administrador e sessões abertas. Uma das falhas lê memória de outras requisições, e o log padrão não mostra se isso aconteceu.

Meu site está em PHP 7.4 ou 8.1. E agora?

O projeto PHP não corrige mais essas versões. Alguns fornecedores publicaram correção própria, e só o seu pode confirmar se o pacote do servidor recebeu. Use o susto para planejar a migração, de preferência para 8.3 ou 8.4, porque o 8.2 deixa de receber correção em 31 de dezembro de 2026.

Fontes

• PHP, Security advisory: Critical remote code execution vulnerabilities, update now (21/out/2026)
• PHP, PHP 8.3.36 Released! (21/out/2026)
• Cloudflare, proteção de WAF para as vulnerabilidades do PHP
• Tenable, PHP2Shell: perguntas frequentes sobre CVE-2026-109618 e CVE-2026-109619
• Sansec, PHP2Shell
• Fortune, AI tools discovered the PHP vulnerability (21/out/2026)
• W3Techs, uso do PHP como linguagem de servidor
• Mattos Filho, ANPD publica regulamento de comunicação de incidente de segurança

Rodrigo Fávaro

Fundador da ROO3, agência de marketing e tecnologia em São José do Rio Preto. Constrói produtos com IA em produção (Tobia, gerar.app, Pense Mercado) e mantém o AI Benchmark, ranking público de modelos de IA. Veja a consultoria em IA da ROO3.

X @rodmf LinkedIn rodrigofavaro