Resposta a Incidente PHP: Foi Invadido via PHP2Shell?

A resposta a incidente PHP virou prioridade de diretoria em outubro de 2026. O PHP2Shell, par de falhas críticas que permite executar código no servidor sem login, vazou antes do patch, e a Unit 42 já descreveu uma invasão que chegou a hashes de senha e segredos de MFA em duas horas. Este guia mostra como descobrir se você foi atingido, conter, rotacionar credenciais e cumprir a LGPD.

TL;DR

• PHP2Shell é o apelido de duas falhas: CVE-2026-109618 e CVE-2026-109619, ambas com nota 9.2 no CVSS 4.0 e exploráveis sem autenticação. A correção saiu em 21/10/2026 nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
• A investigação deve começar a partir de 17/10/2026, quando a Amazon registrou a primeira tentativa de exploração, quatro dias antes da divulgação.
• Atualizar fecha a porta, mas não diz se alguém já entrou. Quem rodou versão vulnerável exposta à internet precisa procurar sinais de invasão e rotacionar segredos.
• As mitigações por configuração (memory_limit=-1, session.upload_progress.enabled=0) reduzem o risco, mas não resolvem. O próprio projeto PHP diz que só a atualização é correção completa.
• Se houve dado pessoal envolvido, a Resolução CD/ANPD nº 15/2024 dá 3 dias úteis para comunicar a ANPD e os titulares.

O que é o PHP2Shell e por que a janela começou antes do patch

O PHP2Shell não é um bug do WordPress, do Laravel ou do Moodle. Ele mora no motor do PHP, na forma como o interpretador trata erros fatais durante uma requisição. Por isso, uma aplicação com código impecável continua vulnerável se o PHP por baixo dela estiver desatualizado.

Segundo o FAQ da Tenable, as duas falhas funcionam assim:

• CVE-2026-109618 (corrupção em out-of-memory): quando a memória acaba no meio da preparação de uma requisição, a rotina de limpeza trata dados parcialmente inicializados como válidos. Isso abre caminho para execução remota de código.
• CVE-2026-109619 (estado global obsoleto): um use-after-free, ou seja, uso de memória já liberada. Sobra estado de uma requisição apontando para memória liberada, e a próxima requisição no mesmo processo reaproveita esse lixo. O projeto PHP também confirma vazamento de memória do processo como impacto.

O aviso oficial do PHP diz que toda instalação que atende requisições web está em risco: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O risco é maior no mod_php, em que um exploit demonstrado dispara antes de qualquer linha da aplicação rodar. Autenticação da aplicação não ajuda, porque o ataque acontece antes dela.

A linha do tempo que define o seu período de investigação

Data	O que aconteceu	Fonte
17/10/2026	Amazon detecta tentativa de exploração no honeypot MadPot	Tenable
20/10/2026	Detalhes vazam em um post no Hacker News; PHP antecipa a correção	Huntress, php.net
21/10/2026	Saem 8.5.12, 8.4.27, 8.3.36 e 8.2.35; Wiz demonstra RCE em WordPress, Drupal e Joomla	php.net, Huntress
23/10/2026	Unit 42 publica o caso europeu; PHP emite alerta da CVE-2026-115560	Unit 42, php.net

A consequência prática: o patch aplicado no dia 22 não apaga o que pode ter acontecido entre os dias 17 e 22. É aqui que a atualização termina e a resposta a incidente PHP começa.

O caso da Unit 42: duas horas até hashes e segredos de MFA

O boletim da Unit 42, da Palo Alto Networks, relata um ataque contra uma entidade governamental na Europa. Em até duas horas depois da exploração inicial, os atacantes já tinham:

1. Acessado hashes de senha e segredos de autenticação multifator (MFA).
2. Montado um túnel de NTLM relay para dentro do Active Directory.
3. Tentado escalar privilégio até Domain Admin.

Duas horas é menos que o tempo médio entre um alerta e alguém olhar para ele numa empresa sem equipe de plantão. O ponto mais importante para quem opera servidor PHP, porém, é o segundo item: o servidor web foi só a porta. O alvo era a rede.

O que muda quando o atacante é uma IA agêntica

A Unit 42 aponta indícios fortes de atacante agêntico, isto é, um sistema de IA que executa tarefas em sequência e decide o próximo passo sozinho. Os sinais citados:

• Lotes de comandos embrulhados em delimitadores como ==SHELLUSER== e ==PASSWD==, que geram saída fácil de um modelo de IA ler.
• Tarefas curtas e em série, com mudança rápida de rota depois de cada falha.
• Enumeração sistemática do servidor comprometido.

Para quem defende, isso tem duas implicações. A primeira é velocidade: o reconhecimento que levava uma tarde agora leva minutos. A segunda é escala: o mesmo agente ataca milhares de alvos em paralelo. O Cortex Xpanse, da Palo Alto, contou mais de 22,6 milhões de instâncias expostas potencialmente vulneráveis. Ninguém precisa ser alvo escolhido para ser atingido.

Resposta a incidente PHP: primeiro descubra se você está exposto

Antes de caçar invasor, confirme o que roda de fato. Na minha experiência operando servidores PHP e Moodle, o erro mais comum é checar a versão errada: o php -v do terminal mostra o PHP de linha de comando (CLI), que muitas vezes não é o mesmo binário que atende o site.

Verifique cada runtime separadamente:

php -v                       # PHP de linha de comando (CLI)
php-fpm8.3 -v                # o FPM que atende o site (ajuste a versão)
apache2ctl -M | grep php     # mod_php carregado no Apache?
docker ps --format '{{.Image}}'   # imagens com PHP embutido

Uma página temporária com phpinfo(), apagada logo depois, também mostra a versão que o servidor web realmente usa.

Tabela de exposição por versão

Ramo do PHP	Situação	O que fazer
8.5.x	Corrigido na 8.5.12	Atualizar e reiniciar todos os workers
8.4.x	Corrigido na 8.4.27	Atualizar e reiniciar todos os workers
8.3.x	Corrigido na 8.3.36	Atualizar e reiniciar todos os workers
8.2.x	Corrigido na 8.2.35 (fim de vida em 31/12/2026)	Atualizar agora e planejar migração
7.4 a 8.1	Sem versão oficial; só backports mínimos de código-fonte	Pacote da distribuição, isolar ou migrar
5.4 a 7.3	Fim de vida, sem correção do projeto	Tirar da internet e migrar

Atenção a um detalhe que confunde muita gente: distribuições Linux corrigem sem mudar o número da versão. O Ubuntu, por exemplo, publicou pacote corrigido do 8.1 para o 22.04. Nesses casos, confira o boletim de segurança da sua distribuição em vez de confiar só no php -v, como orienta a Datadog Security Labs.

Se o servidor rodou versão vulnerável, exposta à internet, em qualquer momento depois de 17/10, trate como possivelmente comprometido até provar o contrário. Isso não é alarmismo. É o ponto de partida de qualquer resposta a incidente PHP bem feita.

Sinais de que você foi invadido via PHP2Shell

Nenhum sinal isolado prova invasão. O que dá certeza é correlacionar requisição estranha, erro no log e processo suspeito na mesma janela de tempo. A Datadog, a Huntress e a Unit 42 publicaram os indicadores abaixo.

Nos logs de erro

• PHP Fatal error: Allowed memory size of ... bytes exhausted acompanhado de Unknown on line 0. O "line 0" indica que a falha aconteceu na inicialização da requisição, antes de qualquer script rodar.
• No Apache, AH00052: child pid ... exit signal Segmentation fault (11), que pode ser uma tentativa de adivinhar endereço de memória que deu errado.
• Uma rajada curta de erros de memória num mesmo worker. Segundo a Datadog, um ataque bem-sucedido pode gerar apenas dois a quatro erros e depois silêncio.

Nas requisições

• Uploads multipart com campos PHPSESSID ou PHP_SESSION_UPLOAD_PROGRESS em rotas que não usam isso.
• Número absurdo de partes: exemplos públicos colocam cerca de 900 partes em menos de 1 MB.
• Nomes de campo gerados por máquina e muito aninhados, como files[R00001][a][a][a].
• Nomes de arquivo contendo <?php ou |O:.

Um alerta importante: não confie no código HTTP. No exploit refinado, a requisição maliciosa devolveu 200 e o worker continuou rodando normalmente.

Nos processos e arquivos

Este é o sinal mais forte. Um processo do servidor web (php-fpm, apache2, httpd, php-cgi, lsphp) abrindo um shell é, nas palavras da Datadog, "a evidência mais direta de exploração bem-sucedida". Procure também:

• Comandos de reconhecimento rodando como www-data: whoami, id, uname -a, leitura de /etc/passwd.
• Binários executados de /tmp, /var/tmp ou /dev/shm.
• curl ou wget com saída canalizada para sh, bash, python ou php.
• Leitura de .env, /proc/self/environ, .aws/credentials ou do endpoint de metadados 169.254.169.254.
• Persistência: crontab novo, chave em authorized_keys, usuário criado, serviço systemd habilitado.

Um ponto de partida para a triagem, a ser rodado depois de copiar os logs (veja a próxima seção):

grep -h "Unknown on line 0" /var/log/php*-fpm.log /var/log/apache2/error.log* 2>/dev/null | tail -50
grep -h "AH00052" /var/log/apache2/error.log* 2>/dev/null | tail -20
ps -eo pid,ppid,user,lstart,cmd --forest | grep -B3 -E "sh -c|bash -i|/dev/tcp"
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls
crontab -l -u www-data; ls -la /var/www/.ssh 2>/dev/null

Se aparecer arquivo PHP novo na pasta de uploads, um cron do www-data que ninguém criou ou um shell filho do FPM, pare a triagem e passe para a contenção.

Contenção: o que fazer na primeira hora

A ordem importa mais que a velocidade. O roteiro que sigo em servidor PHP com suspeita de comprometimento tem quatro passos.

1. Preserve a evidência antes de mexer. Copie para fora do servidor os logs do servidor web, do PHP-FPM, auth.log, histórico de shell e a lista de processos e conexões (ps, ss -tunap). Em VPS ou nuvem, tire um snapshot do disco. Sem isso, você nunca vai saber o que foi levado.
2. Isole, não desligue. Bloqueie o tráfego de entrada no firewall ou na Cloudflare e, principalmente, corte a saída do servidor para a internet, porque é por ela que o atacante extrai dados e recebe comandos. Desligar a máquina apaga a memória, onde muitas vezes está a única prova.
3. Atualize o PHP e reinicie todos os workers. Rebuild das imagens de container, reload do FPM e do Apache. Worker antigo rodando é vulnerabilidade ativa.
4. Mapeie o raio de explosão. Que outros sistemas confiam neste servidor? Banco de dados, Active Directory, painel de nuvem, API do WhatsApp, gateway de pagamento. No caso da Unit 42, o servidor foi o trampolim para o AD.

Quando NÃO fazer

• Não apague o webshell assim que encontrar. Primeiro copie, anote o horário de criação e procure o mesmo padrão em outros servidores.
• Não "limpe e reabra" um servidor com sinal de root. Se houve escalada de privilégio, a única opção confiável é reconstruir a partir de imagem limpa e restaurar dados de backup anterior a 17/10.
• Não troque senhas a partir do servidor comprometido. Se o atacante ainda está lá, ele lê a senha nova.

Para sites WordPress, o passo a passo das primeiras horas está em WordPress invadido: o que fazer nas primeiras 24 horas. A lógica de documentar, conter e só depois limpar é a mesma.

Rotação de credenciais: a ordem que importa

O caso europeu mostra o que um invasor busca primeiro: credenciais. Num servidor PHP, elas ficam em lugares previsíveis: .env do Laravel, wp-config.php do WordPress, config.php do Moodle, variáveis de ambiente do FPM. Tudo que o processo PHP conseguia ler, considere lido.

Rotacione nesta ordem, sempre a partir de uma máquina limpa:

1. Acessos de infraestrutura: chaves SSH, usuários do painel de hospedagem, credenciais de nuvem (AWS, GCP, Azure) e tokens de CI/CD.
2. Banco de dados: senha do usuário da aplicação e de qualquer usuário administrativo cujo acesso partia do servidor.
3. Segredos da aplicação: APP_KEY do Laravel, salts do WordPress, chaves de criptografia de sessão. Trocar isso derruba todas as sessões, o que é exatamente o que você quer.
4. Integrações externas: token da API oficial do WhatsApp (o token de usuário do sistema no Meta Business), chaves de gateway de pagamento, SMTP, Google, webhooks assinados.
5. Usuários finais: forçar troca de senha e, ponto mais esquecido, reinscrever o MFA.

Por que o segredo de MFA vazado é o pior caso

O código de seis dígitos do aplicativo autenticador é gerado a partir de um segredo TOTP guardado no banco da aplicação. Se o atacante copiou esse segredo, ele gera os mesmos códigos que o usuário. Trocar a senha não resolve: é preciso apagar e recadastrar o fator de cada usuário afetado. Em plataformas Moodle com MFA ativo, isso significa resetar o fator de professores e administradores, no mínimo. Foi exatamente esse tipo de dado que a Unit 42 viu ser acessado em duas horas.

Se a sua empresa não tem um inventário de onde cada segredo mora, esta é a hora de montar um. É um dos entregáveis mais pedidos na consultoria de TI e segurança da Agathas Web, justamente porque ninguém consegue rotacionar o que não sabe que existe.

Patch, mitigações e o problema do PHP antigo

Se você não consegue atualizar hoje, o projeto PHP lista medidas temporárias:

Medida	Cobre	Limitação
memory_limit=-1 fixado pelo administrador (ex.: php_admin_value no pool FPM)	CVE-2026-109618	Falha em mmap() ainda leva ao caminho vulnerável; exige limite de memória no container
session.upload_progress.enabled=0	CVE-2026-109619	Fecha só o caminho das sessões
fatal_error_backtraces=0 (só PHP 8.5)	CVE-2026-109619	Complemento da anterior
Regras de WAF (ex.: Cloudflare)	Vetores conhecidos	A própria Cloudflare chama de "paliativo"

O aviso oficial é direto: essas mudanças "não tornam uma instalação segura". Também não adianta aplicar via ini_set() ou .user.ini, porque a configuração precisa valer antes de a requisição ser processada. E, depois de qualquer mudança, é obrigatório reiniciar os workers.

PHP 8.1 ou mais antigo

Aqui não há atalho. A CISA recomenda tirar do ar sistemas PHP que não podem ser atualizados, e a CERT-EU sugere isolar aplicações expostas até a correção ser aplicada e verificada. As saídas reais são três: pacote corrigido da distribuição, quando existir; colocar o sistema atrás de VPN; ou migrar de versão. Para quem roda Moodle antigo preso em PHP 7.4, a migração deixa de ser projeto do ano que vem.

E a CVE-2026-115560?

Em 23/10 o PHP publicou um alerta informativo sobre a CVE-2026-115560, também no recurso de progresso de upload de sessão. O vetor é improvável: só se aplica quando a aplicação troca o session.serialize_handler em tempo de execução. A correção virá na próxima versão regular, e a mitigação é a mesma session.upload_progress.enabled=0. Quem já aplicou essa configuração não precisa fazer nada além disso.

Depois do incidente, trate o resto do servidor também. O checklist de hardening de servidor Linux cobre o que costuma ficar aberto: usuário do PHP com permissão demais, saída de rede liberada, logs sem retenção.

LGPD: quando o incidente vira comunicação à ANPD

Se o servidor PHP guardava ou acessava dados pessoais (cadastro de clientes, alunos, pacientes, leads do WhatsApp), a resposta a incidente PHP tem também uma frente jurídica. A Resolução CD/ANPD nº 15/2024 define as regras:

• 3 dias úteis para comunicar a ANPD e os titulares, contados a partir do momento em que você toma conhecimento de que o incidente afetou dados pessoais e pode gerar risco ou dano relevante.
• 20 dias úteis para complementar a comunicação com informações que ainda faltavam.
• Registro do incidente por no mínimo 5 anos, mesmo quando ele não precisa ser comunicado.
• Agentes de pequeno porte têm prazos em dobro.

Na prática, os 3 dias úteis correm em paralelo à investigação técnica. É por isso que preservar evidência no primeiro passo não é capricho: é o que permite dizer à ANPD o que vazou, e o que não vazou, com base em fato. "Não sabemos" é a pior resposta possível, porque obriga a tratar tudo como exposto.

Quem avisa quem, e com que texto, está detalhado em plano de resposta a vazamento de dados. O portal oficial da ANPD recebe a comunicação.

Quanto custa e quando não fazer sozinho

O custo de uma resposta a incidente PHP raramente está na atualização em si, que leva minutos. Está nas horas de investigação, no sistema fora do ar enquanto se reconstrói, na rotação de dezenas de integrações e, se houve dado pessoal, na exposição regulatória.

Dá para conduzir sozinho quando

• Você tem acesso root, sabe ler logs e correlacionar horários.
• O servidor não guarda dados pessoais nem conversa com outros sistemas internos.
• A triagem não encontrou shell filho do PHP, arquivo novo nem cron estranho.
• Existe backup anterior a 17/10, testado.

Não conduza sozinho quando

• Apareceu qualquer sinal de execução de comando pelo processo PHP.
• O servidor tem acesso ao Active Directory, à VPN ou ao painel da nuvem.
• Há dados pessoais e o relógio da ANPD já está correndo.
• O PHP é 8.1 ou mais antigo e não dá para simplesmente atualizar.
• Ninguém na equipe sabe dizer onde estão todos os segredos da aplicação.

Nessas situações, uma investigação mal feita custa mais do que a ajuda. Apagar evidência por pressa elimina a chance de saber o que foi levado, e reabrir um servidor com persistência ativa entrega o acesso de volta ao atacante. É o tipo de diagnóstico que fazemos na consultoria da Agathas Web.

Como a Agathas Web resolve isso

A Agathas Web desenvolve e opera sistemas PHP desde 2008: Moodle, Laravel, WordPress, integrações com a API oficial do WhatsApp e servidores Linux em produção. A resposta a incidente PHP entra na nossa frente de consultoria, com escopo fechado.

O que está incluso:

• Conversa inicial gratuita (30 a 60 minutos) para entender o cenário, a stack e o que já foi feito. Se o incidente está em andamento, diga isso na primeira mensagem.
• Triagem de exposição e de comprometimento: inventário de todos os runtimes PHP, versões reais (inclusive backports da distribuição), correlação de logs, processos e arquivos desde 17/10.
• Plano de contenção e rotação de credenciais: mapa de onde cada segredo mora, ordem de troca e reinscrição de MFA quando necessário.
• Apoio técnico ao registro de incidente da LGPD: o que foi acessado, quando, e o que pode ser afirmado com evidência, para o encarregado e o jurídico.
• Auditoria pontual de segurança (OWASP Top 10 e ASVS em código, infraestrutura e API), em 2 a 3 semanas, com investimento de R$ 6 a 12 mil e orçamento fechado depois da conversa inicial.
• CTO as a Service (8 a 40 horas por mês) para quem quer alguém sênior acompanhando patches e decisões de infraestrutura daqui em diante.

Como funciona: assinamos NDA bilateral antes de qualquer acesso, trabalhamos com acesso read-only que você revoga quando quiser, e você sai com um relatório. Implementar com a gente, com outro fornecedor ou com o time interno é decisão sua.

Para contratar, fale com a gente pela página de consultoria em TI e segurança e conte o que está acontecendo.

Conclusão: atualizar fecha a porta, não diz quem entrou

O PHP2Shell vai continuar sendo explorado por semanas, em escala, por ferramentas automatizadas que não escolhem alvo. Atualizar para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 é obrigatório, mas é o começo. A resposta a incidente PHP completa responde à pergunta que o patch não responde: alguém entrou entre 17/10 e o dia da atualização, e o que levou?

Se você rodou versão vulnerável exposta à internet, faça a triagem desta semana: versões reais, logs desde 17/10, processos filhos do PHP, arquivos novos e crons. Se encontrar qualquer coisa, ou se não tiver quem faça, agende a conversa inicial da consultoria. Ela é gratuita, e a gente sai dela com o escopo do que o seu servidor precisa.

Fontes: php.net, Unit 42, Tenable, Datadog Security Labs, Huntress, watchTowr e BleepingComputer.