No dia 21 de outubro de 2026, o projeto PHP publicou correções de emergência para duas falhas críticas no próprio motor da linguagem. O apelido que pegou foi PHP2Shell: um atacante sem login, sem senha e sem conhecer nada do seu sistema consegue, em determinadas condições, executar código no seu servidor.
O detalhe que muda tudo é onde a falha está. Não é num plugin, num tema ou num formulário mal escrito. Está no PHP. Seu código pode estar impecável e o site continua exposto. E o PHP roda por baixo de boa parte da web — WordPress, WooCommerce, Magento, Moodle, Laravel e a maioria das hospedagens compartilhadas com cPanel.
Este texto explica o que aconteceu, o que ainda está em disputa entre as fontes, o que fazer esta semana — e por que o PHP2Shell é o terceiro capítulo de uma história que já tinha passado por 2021 e 2024.
O que é o PHP2Shell
São duas vulnerabilidades, ambas com nota 9.2 (crítica) no CVSS v4.0:
- CVE-2026-109618 — corrupção de memória em falta de memória. Quando o PHP estoura o limite de memória no meio de uma requisição, ele interrompe o processamento abruptamente. Se isso acontece enquanto estruturas internas ainda estão sendo montadas, elas ficam pela metade — e um atacante pode provocar esse estado de propósito.
- CVE-2026-109619 — estado global "velho" entre requisições. Dados que pertenciam a uma requisição sobrevivem depois que a memória deles foi liberada, e a próxima requisição usa o que sobrou. É o clássico use-after-free.
O resultado das duas é o mesmo: execução remota de código com as permissões do processo web. Na prática, isso significa ler o banco de dados, roubar credenciais, instalar uma backdoor ou transformar o servidor em ponto de partida para outros ataques.
A descoberta é creditada de forma independente à Calif e à Wiz. A Wiz afirma que todas as versões do PHP lançadas na última década são afetadas por pelo menos uma das falhas, desde a 5.4 — e que ferramentas de IA tiveram papel na pesquisa. Guarde essa informação; volto a ela no final.
Quem está exposto
Os avisos citam PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O mod_php é considerado o de maior risco, porque a exploração pode acontecer antes mesmo de o código da aplicação rodar.
As versões corrigidas são:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Para 8.1, 8.0 e 7.4 não existe versão oficial: o projeto publicou correções avulsas no código-fonte, e quem usa essas versões depende do pacote da distribuição Linux ou do fornecedor. Para 7.3 e anteriores — incluindo o PHP 5 que ainda aparece em mais servidor do que deveria — não existe correção. A única saída é atualizar de versão.
Está sendo explorado ou não?
Aqui as fontes não batem, e acho mais útil mostrar a divergência do que escolher um lado:
- watchTowr relata tentativas ativas de exploração das duas falhas.
- AWS disse em 21 de outubro que a vulnerabilidade já estava "amplamente explorada" e identificou uma tentativa datada de 17 de outubro — antes da divulgação pública.
- Cloudflare reportou sinais de exploração antes da publicação das correções.
- Rapid7 não observou exploração bem-sucedida em ambiente real e diz que as provas de conceito públicas só funcionam em combinações específicas de sistema operacional, versão do PHP e servidor web.
- Até 22 de outubro, a CISA não tinha incluído nenhuma das duas no catálogo de vulnerabilidades sabidamente exploradas (KEV).
Leitura honesta: há gente tentando, há exploits públicos, e ainda não está claro quantas invasões deram certo. Para quem administra um servidor, essa incerteza não muda a decisão. Atualizar custa uma janela de manutenção. Esperar para ver custa, no pior caso, o servidor.
Isso não é a primeira vez
O PHP2Shell chama atenção pelo alcance, mas o ecossistema PHP já passou por dois episódios recentes que ajudam a entender o padrão.
2024: CVE-2024-4577, o PHP-CGI no Windows
Em junho de 2024 foi corrigida uma falha de injeção de argumentos no PHP-CGI rodando em Windows, com nota 9.8. Ela contornava a proteção de uma falha de 2012 (CVE-2012-1823) explorando a forma como o Windows converte certos caracteres — o recurso chamado "Best Fit". Afetava em cheio instalações com XAMPP.
O intervalo entre correção e ataque foi de dois dias. A Imperva registrou exploração a partir de 8 de junho, distribuindo o ransomware TellYouThePass. Em janeiro de 2025, a GreyNoise contou 1.089 IPs diferentes tentando explorar a falha, e a Cisco Talos ligou a CVE a uma campanha contra empresas japonesas, com roubo de credenciais e Cobalt Strike. A falha entrou no catálogo KEV da CISA.
A lição de 2024 é sobre tempo: o atacante lê o mesmo boletim de segurança que você, só que mais rápido.
2021: a backdoor no código-fonte do PHP
Em 28 de março de 2021, alguém invadiu o servidor Git oficial do projeto (git.php.net) e inseriu dois commits no código-fonte do PHP — um em nome de Rasmus Lerdorf, criador da linguagem, e outro em nome de Nikita Popov, um dos mantenedores. A mensagem era um inocente "Fix typo". O código adicionado executava qualquer comando enviado num cabeçalho HTTP específico, e citava a Zerodium, conhecida compradora de falhas de dia zero, que negou envolvimento.
Os mantenedores perceberam e reverteram antes que o código chegasse a uma versão oficial. O projeto abandonou o servidor próprio e passou a usar o GitHub como repositório principal.
A lição de 2021 é sobre confiança: até a origem do software pode ser atacada.
O que fazer esta semana
Se você tem qualquer coisa rodando em PHP — site institucional em WordPress, loja virtual, sistema interno, painel de hospedagem — esta é a ordem que eu seguiria:
- Descubra a versão. No servidor,
php -v. Na hospedagem compartilhada, o painel (cPanel, Plesk, hPanel) mostra a versão por domínio. Num WordPress, vá em Ferramentas → Saúde do site → Informações → Servidor. - Atualize para a versão corrigida do seu ramo. 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. Se o servidor é Linux gerenciado por você, os pacotes das distribuições chegaram antes da divulgação; rode a atualização do sistema e confira a versão de novo.
- Reinicie os processos do PHP. Atualizar o pacote e não reiniciar o PHP-FPM ou o Apache deixa a versão antiga rodando na memória.
- Está em 8.1 ou anterior? Pergunte ao seu provedor se ele aplicou as correções avulsas. Se a resposta for vaga, trate como não corrigido e planeje a migração de versão agora, não no próximo trimestre.
- Em hospedagem compartilhada, cobre o provedor. A correção depende deles. Peça por escrito a confirmação de que o PHP2Shell foi corrigido nos servidores onde seu site roda.
Enquanto a atualização não sai
A Rapid7 lista medidas temporárias que reduzem a superfície de ataque. Elas precisam ser aplicadas na configuração do servidor (php.ini, pool do FPM ou config do Apache) — ini_set() dentro da aplicação ou .user.ini chegam tarde demais:
session.upload_progress.enabled=0fatal_error_backtraces=0(PHP 8.5)- limitar
post_max_sizeeupload_max_filesize, e restringir o tamanho das requisições no proxy ou CDN - reiniciar todos os workers depois de mudar
Dois avisos importantes. Esconder erros (display_errors, error_reporting, @) não protege contra nenhuma das falhas. E a ausência de registros suspeitos no log não prova que você não foi atacado. Os próprios mantenedores do PHP disseram que não há mitigação completa: o único caminho seguro é atualizar.
O que isso diz sobre o momento
Três episódios, três vetores diferentes. Em 2021, o ataque foi à origem do software. Em 2024, a uma configuração específica que todo mundo achava nicho. Em 2026, ao núcleo que roda em praticamente toda instalação.
E tem um quarto elemento novo. A Wiz atribui parte da descoberta do PHP2Shell a ferramentas de IA. Isso é uma boa notícia — falhas que dormiam havia dez anos estão sendo encontradas e corrigidas. Mas a mesma capacidade está disponível para quem ataca. O intervalo entre a divulgação de uma falha e a primeira tentativa de exploração, que em 2024 foi de dois dias, tende a encolher. Em 2026, segundo a AWS, a tentativa veio antes da divulgação.
Para quem tem negócio rodando na web, a conclusão prática é menos técnica do que parece: alguém precisa ser responsável pela atualização do seu servidor, com nome e prazo. Não o plugin de segurança, não a esperança de que a hospedagem resolva sozinha. Uma pessoa que, no dia em que sai um boletim desses, sabe em que versão você está e quanto tempo leva para corrigir.
Se você não sabe responder hoje em qual versão do PHP o seu site roda, essa é a primeira tarefa da semana.
Se quiser ajuda para auditar a infraestrutura do seu site — versões, hospedagem, cabeçalhos de segurança e o que pode te derrubar —, é parte do trabalho que eu faço. Me chama.
Referências
PHP2Shell (CVE-2026-109618 e CVE-2026-109619)
- PHP — anúncio oficial das versões corrigidas
- GitHub Security Advisory — falta de memória (GHSA-w8hw-w9fx-j79w)
- GitHub Security Advisory — estado global após liberação (GHSA-6wmf-4rv5-p3rp)
- Rapid7 — análise técnica e mitigações
- Wiz — descoberta e o papel da IA
- watchTowr — perguntas frequentes
- Recorded Future — status de exploração
- The Hacker News — correções de emergência
- Help Net Security — PHP2Shell corrigido
- Fortune — a corrida entre correção e ataque
- Vercel — boletim de segurança
CVE-2024-4577 (PHP-CGI no Windows)
- Help Net Security — falha explorada para distribuir ransomware
- Security Affairs — exploração em massa
- Computing — aumento global de ataques
- Orca Security — análise da CVE-2024-4577
Backdoor no git.php.net (2021)
Escrito por
Paulo Victor Fraga
Comentários(0)
Seja o primeiro a comentar.