O que aconteceu
Em 21 de outubro, o projeto PHP lançou correções para duas vulnerabilidades, CVE-2026-109618 e CVE-2026-109619. Ambas têm nota CVSS 9.2 e, segundo a análise da Arctic Wolf, podem permitir que um atacante não autenticado execute código em um servidor que processa requisições web com PHP.
Os bugs estão no próprio ciclo de processamento de requisições do PHP, não em um framework ou plugin:
- CVE-2026-109618 é uma corrupção de memória disparada quando uma condição de falta de memória interrompe o PHP enquanto os dados da requisição estão só parcialmente preparados.
- CVE-2026-109619 é um use-after-free: o estado de uma requisição pode sobreviver e ser lido por uma requisição posterior no mesmo worker, o que também pode vazar conteúdo da memória.
Vale parar nesse segundo ponto. A Qualys observa que a memória vazada de um worker pode conter senhas, tokens e API keys. Então, mesmo que ninguém consiga um shell no seu servidor, segredos podem sair pela porta.
Tudo andou rápido depois do patch, e a escala é grande: o The Hacker News cita estimativas da Censys de mais de 32 milhões de serviços PHP ainda rodando uma versão afetada.
- A equipe de inteligência de ameaças da Amazon disse que os ataques começaram quatro dias antes da publicação das correções, segundo o BleepingComputer.
- Em 24 de outubro, um pesquisador da Perplexity confirmou a execução de código com sucesso contra honeypots (The Hacker News).
- Em 26 de outubro, a CISA adicionou os dois CVEs ao seu catálogo de vulnerabilidades exploradas conhecidas (KEV) e deu às agências federais dos EUA até 29 de outubro para corrigi-las.
Por que isso importa até para apps pequenos
Aqui os atacantes não escolhem alvos pelo tamanho da empresa. Eles varrem a internet atrás de qualquer coisa que responda como PHP e testam o exploit. Um projeto paralelo esquecido em uma VPS é tão acessível quanto um grande e-commerce.
Alguns detalhes tornam este caso especialmente digno de ação:
- Não depende do seu código. A Arctic Wolf destaca que, como as falhas estão no processamento de requisições do PHP, a exposição não depende de qual aplicação você roda. Um app Laravel perfeitamente escrito sobre uma build antiga do PHP continua exposto.
- Muitas configurações de servidor estão no escopo. Apache com mod_php é considerado o maior risco, mas PHP-FPM, php-cgi, FrankenPHP e LiteSpeed também aparecem como afetados, assim como produtos e appliances que embutem PHP.
- PHP antigo é comum. A Qualys relata que cerca de 71% das instalações de PHP cuja versão ela conseguiu identificar já estavam em fim de vida. Se você está no 8.1 ou anterior, não há correção oficial regular para você.
Como verificar seu app
Você procura uma resposta por servidor: tem algo servindo requisições web com PHP e, se sim, em qual versão exata?
1. Liste tudo o que você hospeda. Não só o app principal. Inclua sites de marketing, blogs, documentação, ambientes de staging, ferramentas de administração e qualquer coisa em um subdomínio. Os esquecidos são os perigosos.
2. Olhe os cabeçalhos de resposta. Muitas instalações de PHP se anunciam em um cabeçalho X-Powered-By ou Server. Ausência de cabeçalho não significa ausência de PHP (dá para desativar com expose_php = Off), mas um cabeçalho é um sim rápido. Páginas de erro detalhadas são outra pista: um stack trace de PHP em produção diz ao atacante exatamente o que você roda.
curl -sI https://your-site.example | grep -i -E 'x-powered-by|server'
# X-Powered-By: PHP/8.3.20 <- PHP, and an old patch level3. Verifique a versão que serve o tráfego web, não só a CLI. O php -v no servidor pode mostrar uma build diferente da que o Apache ou o PHP-FPM realmente usam; a Qualys alerta especificamente sobre isso. Confira o binário do FPM ou o módulo PHP do seu servidor web, ou pergunte à sua hospedagem.
php-fpm8.3 -v # or php-fpm -v, depending on your distro
apache2ctl -M | grep php # is mod_php loaded?4. Compare com as versões corrigidas. Se você instala o PHP pela sua distribuição Linux, a correção pode vir como backport em um pacote com número de versão aparentemente mais antigo, então consulte o aviso de segurança da sua distro em vez de confiar só no número da versão. Caso contrário, você precisa de no mínimo:
- PHP 8.5: 8.5.12
- PHP 8.4: 8.4.27
- PHP 8.3: 8.3.36
- PHP 8.2: 8.2.35
5. Hospedagem gerenciada? Se você usa uma hospedagem gerenciada de WordPress ou um PaaS, confira a página de status ou o changelog deles em busca de um aviso sobre PHP2Shell. A maioria vai aplicar o patch por você, mas "a maioria" não é "todos", e uma VPS autogerenciada é responsabilidade inteiramente sua.
Como corrigir
Aplique o patch e depois reinicie. Atualizar o PHP é a única correção completa.
O reinício importa: workers em execução mantêm o código antigo na memória até serem substituídos. No Docker, reconstrua sobre uma imagem base atualizada (por exemplo, uma tag atual de php:8.3-fpm) e faça o deploy de novo. Não basta reiniciar o contêiner antigo.
No Debian ou Ubuntu com PHP-FPM, costuma ser algo assim:
sudo apt update && sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2 # if you use mod_phpSe não der para aplicar o patch hoje, a Qualys resume as mitigações provisórias do PHP. Elas reduzem o risco, mas não tornam seguro um servidor sem patch. Defina-as no php.ini ou na configuração do pool do FPM (não no .user.ini nem com ini_set) e reinicie todos os workers.
Se um serviço está sem patch e não precisa ser público, coloque-o atrás de uma VPN ou de uma allowlist de IPs, ou tire-o do ar até poder atualizar.
; php.ini or FPM pool config (not .user.ini or ini_set)
session.upload_progress.enabled = 0
post_max_size = 8M ; 32M if you need uploads
upload_max_filesize = 6M ; keep below post_max_sizeSe você está no PHP 8.1 ou anterior, planeje a atualização agora. Existem backports limitados para alguns branches antigos, mas você conta com a sorte toda vez que algo assim aparece.
Procure sinais de comprometimento. Verifique processos inesperados, arquivos novos nos diretórios web, cron jobs desconhecidos e conexões de saída a partir do servidor web. A Arctic Wolf também observa que muitas requisições "PHP2Shell" nos logs reutilizam técnicas antigas, então uma linha de log assustadora não significa automaticamente uma invasão bem-sucedida.
Troque os segredos se você esteve exposto. Como o CVE-2026-109619 pode vazar memória dos workers, trate como possivelmente vistos os segredos que passaram por um processo PHP sem patch e exposto à internet. Isso inclui senhas de banco de dados, API keys, chaves de assinatura de sessão e chaves de provedores de pagamento. Laravel e frameworks parecidos guardam isso no .env, então confirme também que esse arquivo nunca esteve acessível pela web.
Checklist rápido
Passe por esta lista para cada domínio que você tem:
- Todos os seus domínios e subdomínios estão listados, incluindo sites antigos de marketing e de staging.
- Você sabe quais usam PHP e a versão exata que serve o tráfego web.
- Cada um está no 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou em uma build corrigida pelo fornecedor.
- Os workers do PHP e os servidores web foram reiniciados após a atualização.
- Tudo o que está sem patch está restrito ou fora do ar, com as mitigações aplicadas.
- Os segredos dos hosts expostos foram trocados.
- A produção não anuncia mais a versão do PHP nem mostra stack traces.
A lição maior
O PHP2Shell vai ser corrigido e esquecido em poucas semanas. O padrão, não. O intervalo entre "correção publicada" e "exploração ativa" agora é de dias, às vezes negativo. Times pequenos não vencem essa corrida no heroísmo. O que funciona é saber o que você roda e perceber rápido quando algo muda.
É a mesma ideia por trás do nosso checklist de lançamento para apps criados com IA: a maioria dos incidentes reais vem de coisas fáceis de verificar, se você realmente as verificar.
O AppSafe escaneia seu site em produção de fora, do jeito que um atacante o veria. Ele procura problemas como cabeçalhos de segurança ausentes, um cabeçalho X-Powered-By que revela seu stack, arquivos expostos e erros detalhados, e entrega correções em linguagem simples. Depois de aplicar o patch, rode um scan gratuito em cada um dos seus domínios para pegar as outras melhorias fáceis de quebra.