O PHP2Shell exige atenção à correção e aos possíveis efeitos de uma exploração. Saiba como verificar a exposição, investigar sinais de ataque e tratar credenciais e acessos comprometidos.
PHP2Shell: corrigir o PHP não encerra a resposta a um comprometimento
A urgência está em confirmar a exposição, atualizar o ambiente em execução e investigar o que aconteceu antes da correção.
Informações verificadas em 28 de outubro de 2026.
O PHP2Shell exige duas respostas diferentes: corrigir a vulnerabilidade e verificar se alguém a explorou enquanto o ambiente estava exposto. Confundir essas tarefas deixa uma parte importante do risco sem tratamento.
A atualização corrige a falha. Ela não remove, por si só, uma persistência instalada antes da mudança nem revoga credenciais que um atacante tenha obtido.
Esse é o ponto central para as empresas: encerrar o chamado de atualização não equivale a encerrar uma investigação.
O que está confirmado
As vulnerabilidades CVE-2026-109618 e CVE-2026-109619, conhecidas como PHP2Shell, atingem o núcleo do PHP e permitem execução remota de código sem autenticação. O projeto PHP aponta o Apache com mod_php como o cenário de maior risco, com exploração demonstrada antes da execução do código da aplicação. A gravidade foi classificada em 9,2 no CVSS v4.0. Cyber Security Agency of Singapore PHP.net
As duas falhas entraram no catálogo KEV (Known Exploited Vulnerabilities) da CISA, agência de cibersegurança dos Estados Unidos, em 26 de outubro, segundo atualização do Centro Canadense de Segurança Cibernética. A inclusão confirma exploração conhecida; não comprova comprometimento de uma empresa específica. Canadian Centre for Cyber Security
As versões corrigidas, publicadas em 21 de outubro, são:
PHP 8.1 e versões anteriores também são afetadas (a Wiz aponta impacto desde a versão 5.4), mas estão fora do suporte regular do projeto e não recebem novas versões regulares de segurança. Distribuições e fornecedores de suporte estendido podem disponibilizar correções próprias. Nesses casos, o número da versão, isoladamente, não decide a situação: é necessário confirmar o pacote instalado e o boletim do fornecedor. Canadian Centre for Cyber Security
Excepcionalmente, o projeto PHP disponibilizou backports mínimos do código-fonte para PHP 7.4, 8.0 e 8.1. Isso não restabelece o suporte dessas linhas. Quem depende delas deve verificar a correção com o fornecedor e planejar a migração para uma versão suportada. PHP.net
Em Windows, use os builds republicados em 26 de outubro: 8.5.12-1, 8.4.27-1, 8.3.36-1 ou 8.2.35-1. Eles incluem uma correção adicional na biblioteca Brotli, referente à CVE-2026-111497; a versão do interpretador PHP permanece a mesma, por isso a tabela acima não muda. PHP.net
O que muda quando o atacante executa código
Uma aplicação precisa de acessos para funcionar. Ela lê configurações, autentica-se no banco de dados, chama APIs e, em alguns ambientes, utiliza uma identidade de serviço para acessar recursos da nuvem.
Ao executar código no contexto do processo PHP, o atacante passa a atuar com os acessos disponíveis àquele processo. Na prática, alcança os arquivos e recursos que esse processo consegue acessar, dentro das permissões e dos limites de isolamento existentes.
Isso coloca no centro da investigação as variáveis de ambiente, arquivos de configuração, credenciais de banco e tokens disponíveis à aplicação. Se o processo também consegue utilizar uma identidade de serviço da nuvem, as permissões dessa identidade precisam ser avaliadas.
A pesquisa da Wiz que revelou o PHP2Shell demonstrou, além de execução de código, a leitura remota da memória do processo, sem necessidade de executar código. Esse conteúdo pode incluir senhas, tokens, chaves de API e certificados de outras requisições. Portanto, a análise de impacto precisa considerar a exposição de segredos mesmo quando não há evidência de uma ferramenta maliciosa instalada. Wiz Research
A extensão do incidente depende também dos acessos que a aplicação já possuía.
Uma aplicação que precisa consultar um conjunto restrito de dados não deve operar com credenciais capazes de administrar todo o banco. Uma identidade usada para ler um recurso não precisa de permissão para alterá-lo nem para acessar os demais. Essas decisões estabelecem limites antes de qualquer vulnerabilidade ser divulgada.
A investigação começa antes da data do patch
A Amazon Threat Intelligence registrou uma tentativa de exploração em seus sensores em 17 de outubro, quatro dias antes da divulgação pública. Novas tentativas foram observadas a partir de 21 de outubro, e o relato não determinou se alguma delas teria sucesso em sistemas reais. AWS Security Blog
Para as equipes de resposta, essa data é uma referência para buscar atividade anterior ao anúncio. Não é uma garantia de que tentativas mais antigas não existiram, nem prova de invasão de um ambiente específico.
Se houve comprometimento, atualizar o PHP não invalida automaticamente uma credencial copiada nem elimina acessos adicionais criados pelo invasor.
Diante de suspeita ou confirmação, a resposta deve revogar e substituir os segredos expostos, encerrar sessões ativas, revisar as identidades de serviço e analisar as atividades realizadas com esses acessos. Chaves persistentes e tokens temporários exigem tratamento próprio: um token de acesso já emitido pode continuar válido até expirar, mesmo depois da troca da chave. Google Cloud
A correção da vulnerabilidade e a recuperação do ambiente precisam ser verificadas separadamente.
O que fazer hoje
A sequência abaixo organiza a resposta imediata. “Hoje” não significa um prazo de 24 horas: ambientes expostos à internet exigem ação agora.
1. Confirme onde o PHP está rodando
Identifique as aplicações, os servidores e os contêineres que executam PHP, incluindo serviços administrados por terceiros e produtos ou appliances que trazem o PHP embutido. Registre responsável, exposição à internet, versão em execução e situação da correção.
Confirme o ambiente que atende às requisições web. O comando php -v mostra a versão do executável chamado no terminal; isso, sozinho, não comprova a versão usada pelo serviço web (PHP-FPM, mod_php ou equivalente).
Para hospedagens contratadas, peça ao fornecedor a identificação do pacote corrigido e a confirmação de implantação.
2. Corrija e valide a implantação
Atualize o PHP para a versão corrigida da respectiva linha ou aplique o pacote validado pelo fornecedor. Reinicie os serviços e processos necessários para que a mudança entre em execução.
Em contêineres, atualize também a imagem utilizada nas implantações e substitua as instâncias antigas. Corrigir apenas uma instância não impede que uma imagem vulnerável volte ao ambiente.
Quando a correção imediata não for viável, restrinja ou suspenda a exposição pública do serviço afetado enquanto a equipe executa a remediação. Medidas temporárias não substituem o patch. Canadian Centre for Cyber Security
Para reduzir temporariamente a exposição aos caminhos de sessão confirmados da CVE-2026-109619, o projeto orienta definir session.upload_progress.enabled=0 no php.ini, no pool do PHP-FPM ou na configuração do servidor e reiniciar todos os processos de atendimento (workers). A medida não cobre outras variantes e não substitui a atualização. PHP.net
3. Não trate um teste negativo como comprovação de correção
Verificações externas têm limites. Ausência de falha ou de resposta esperada em uma sondagem não comprova que o PHP foi atualizado.
O resultado pode refletir bloqueios, configuração de memória ou um caminho não coberto pelo teste. A confirmação deve se apoiar no ambiente em execução e no pacote instalado. Algumas sondagens também esgotam memória e interrompem processos, por isso exigem avaliação de impacto. Assetnote / Searchlight Cyber
4. Investigue e contenha em paralelo
Preserve registros e evidências relevantes. Busque processos inesperados associados ao serviço web, arquivos e contas novos, comandos suspeitos e conexões de saída incomuns. Essas verificações constam das recomendações do Centro Canadense de Segurança Cibernética. Canadian Centre for Cyber Security
Na busca específica por PHP2Shell, a AWS recomenda procurar requisições POST com PHP_SESSION_UPLOAD_PROGRESS em uploads multipart. A Wiz cita requisições multipart incomuns seguidas de erros de limite de memória ou respostas HTTP 500 repetidas, cookies PHPSESSID excessivamente grandes ou malformados e reinícios inexplicados de workers PHP. Esses sinais orientam a investigação; isoladamente, não comprovam comprometimento. AWS Security Blog Wiz Research
A AWS também publicou endereços IP observados, mas ressalta que eles pertencem a infraestrutura de anonimização compartilhada. A orientação é investigar as ocorrências, sem tratar esses IPs isoladamente como prova de ataque ou como base para bloqueio indiscriminado. AWS Security Blog
Havendo indícios de comprometimento, acione a resposta a incidentes. A equipe deve conter o acesso, avaliar persistência e definir a recuperação a partir de uma base confiável.
Revogue ou substitua os segredos potencialmente expostos e revise os acessos das identidades de serviço. Implante as novas credenciais somente em um ambiente limpo ou reconstruído; caso contrário, elas podem ser expostas novamente. Google Cloud
5. Avalie a CVE adicional
Em 23 de outubro, o projeto PHP publicou uma orientação sobre a CVE-2026-115560, não corrigida pelas atualizações do dia 21. Até 28 de outubro não havia versão corrigida; o projeto informou que tratará a falha no próximo ciclo regular de releases.
Esse caminho exige uma combinação específica: o recurso de progresso de upload da sessão habilitado e uma aplicação que altera o manipulador de serialização de sessão de php_binary ou php_serialize para php durante a execução, antes de iniciar a sessão.
A orientação temporária é desabilitar session.upload_progress.enabled no php.ini, no pool do PHP-FPM ou na configuração do servidor, com reinício dos workers. O projeto alerta que ajustes via ini_set() ou .user.ini não bastam. Quem já aplicou essa medida como mitigação da CVE-2026-109619 deve mantê-la. A equipe deve avaliar essa condição e seguir o aviso oficial, inclusive após corrigir as duas falhas originais. PHP.net
A pergunta que permanece
O PHP2Shell torna concreta uma relação que muitas vezes fica abstrata: a vulnerabilidade abre uma possibilidade de entrada; os acessos disponíveis à aplicação influenciam até onde o incidente consegue avançar.
Conhecer esses acessos permite priorizar a investigação e reduzir permissões desnecessárias. Monitorar seu uso ajuda a identificar movimentos posteriores. Confirmar a correção impede que a exposição continue.
Se o processo da sua aplicação mais exposta fosse comprometido agora, quais dados, credenciais e serviços ficariam ao alcance do atacante? Quanto desse acesso é realmente necessário para ela funcionar?
