PHP2Shell

01Sumário executivo

PHP2Shell é o nome dado a duas vulnerabilidades críticas no núcleo do interpretador PHP, a CVE-2026-109618 e a CVE-2026-109619, corrigidas pelo projeto PHP em 21 de outubro de 2026 [1] [2] [3]. As duas permitem execução remota de código sem autenticação e receberam a mesma pontuação CVSS v4 de 9.2, com vetor de rede, sem privilégios e sem interação do usuário [1] [2]. Como o defeito está no interpretador, e não em um framework ou aplicação, ele alcança praticamente todo servidor que usa PHP para atender requisições web: Apache com mod_php, PHP-FPM, php-cgi, FrankenPHP e LiteSpeed [3] [4].

O ataque acontece antes de qualquer código da aplicação. A requisição maliciosa é um POST com corpo multipart montado para esgotar a memória do PHP enquanto ele ainda interpreta a própria requisição; por isso o erro registrado aparece em Unknown on line 0, sem arquivo de script [4]. Em campo, o mecanismo de progresso de upload da sessão (session.upload_progress) foi o caminho usado para vazar endereços e consumir o estado corrompido [4] [7].

A exploração começou antes do anúncio público: segundo a Datadog, a AWS relatou tentativas em 17 de outubro, três dias antes da divulgação [4]. Um honeypot registrou execução remota de código contra Apache com mod_php rodando PHP 8.4.26 [6], e a pesquisa da Dream documentou uma campanha que encadeou o PHP2Shell com uma falha do kernel Linux para obter root em 25 servidores [7]. Essa campanha é analisada em detalhe no relatório Da webshell ao root do CiberLab.

A ação é uma só: atualize para PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, comece pelos servidores expostos à internet e reinicie todos os processos do PHP [1] [3]. Quem roda PHP 8.1 ou anterior, fora de suporte, deve tirar o sistema do ar até migrar, como orienta a CISA [3]. Este relatório traz, na seção 6, a verificação da plataforma CiberLab: a aplicação não usa PHP, mas o painel que a publica, sim.

02Identificação do objeto analisado

03Contexto técnico: o processo que sobrevive à requisição

Para entender as duas falhas, é preciso conhecer duas decisões de projeto do PHP: como ele reaproveita processos entre requisições e como ele aborta uma requisição que deu errado.

3.1Processos persistentes e memória por requisição

Nas formas usuais de servir PHP (mod_php dentro do Apache, PHP-FPM, FrankenPHP, LiteSpeed), o mesmo processo trabalhador atende muitas requisições seguidas [2] [3]. A memória que pertence a uma requisição vive num espaço próprio, liberado em bloco no fim dela; o estado global do processo, como informações de erro, de sessão e de extensões, permanece entre uma requisição e a seguinte [2]. Esse arranjo é eficiente, mas exige uma disciplina: tudo o que o estado global aponta dentro da memória de uma requisição precisa ser zerado antes de essa memória ser liberada [2].

3.2O salto de emergência: longjmp()

Quando o PHP fica sem memória, estoura o tempo de execução ou encontra outro erro fatal, ele não desfaz a pilha de chamadas passo a passo. Usa longjmp(), uma instrução da linguagem C que salta direto de volta a um ponto de recuperação, abandonando o que estava no meio do caminho [1] [5]. O salto é rápido, mas não executa nenhuma limpeza das funções que abandonou. Se uma delas estava no meio da montagem de uma estrutura, a estrutura fica pela metade [1].

3.3Progresso de upload na sessão

O recurso session.upload_progress grava na sessão do usuário o andamento de um upload em curso, para que a aplicação mostre uma barra de progresso [2]. Ele roda durante a leitura do corpo da requisição, antes de qualquer script, e manipula a sessão do usuário a partir de campos do próprio formulário, como PHPSESSID e PHP_SESSION_UPLOAD_PROGRESS [4]. É um dos dois consumidores precoces de estado global citados no aviso da CVE-2026-109619 [2] e o ponto de entrada usado na campanha documentada pela Dream [7].

04Mecanismo das vulnerabilidades e causa raiz

4.1CVE-2026-109618: memória lida antes de existir

Em alguns contextos, a memória da requisição se torna alcançável antes de estar totalmente inicializada [1]. Se uma alocação falha nesse intervalo, o longjmp() abandona a inicialização, e a rotina de encerramento da requisição depois lê essa memória ou toma decisões com base nela [1]. O aviso destaca que a alocação que falha não precisa ter relação com a estrutura inválida: basta acontecer no momento errado [1].

A Datadog descreve um caso concreto na tabela de dispersão do PHP (Zend/zend_hash.c): a função _zend_hash_str_add_or_update_i() incrementa os contadores da tabela antes de alocar a chave; se essa alocação falha, a limpeza visita um elemento cuja chave e cujo valor nunca foram escritos [4]. Um atacante que controla o conteúdo dessa memória controla o que a limpeza faz com ela.

4.2CVE-2026-109619: o ponteiro que sobrevive à requisição

Os processos persistentes guardam estado global de erro, sessão, objetos e extensões que aponta para memória de uma única requisição, e esse estado nem sempre é zerado antes de a memória da requisição ser liberada [2]. Erros fatais, incluindo falta de memória e tempo de execução esgotado, podem pular o zeramento; diagnósticos emitidos tarde, durante o encerramento, podem repovoar o estado de erro depois de ele ter sido limpo [2]. A requisição seguinte usa então um ponteiro para memória já liberada, antes que a inicialização normal rode: um uso após liberação (use-after-free) [2].

O aviso nomeia os dois consumidores precoces desse estado: os diagnósticos de configuração (INI) aplicados antes da inicialização da requisição e o tratamento de progresso de upload da sessão [2]. O caso de execução confirmado usa o recurso fatal_error_backtraces do PHP 8.5 e afeta o mod_php [2]; no PHP-FPM, segundo a Datadog, a execução depende de a aplicação realizar uma operação adequada depois da inicialização [4].

4.3CVE-2026-115560: o aviso que veio depois

Em 23 de outubro, dois dias depois da correção, o projeto PHP publicou um aviso informativo sobre uma terceira falha de execução remota, a CVE-2026-115560, ainda sem correção [9]. Ela exige uma combinação incomum de configuração e código: a aplicação define session.serialize_handler como php_binary ou php_serialize, troca para php em tempo de execução com ini_set() antes de session_start(), e mantém o progresso de upload ligado [9]. A mitigação é a mesma da CVE-2026-109619, session.upload_progress.enabled=0, e as versões de 21 de outubro não a corrigem [9]. Não havia exploração relatada na data deste relatório [9].

05Exploração em campo e linha do tempo

As fontes divergem em detalhes de horário, mas concordam na sequência. A tabela reúne os marcos com a fonte de cada um:

5.1A cadeia observada pela Dream

A Dream recuperou o exploit de um operador e descreveu o estágio PHP2Shell em quatro passos, contra o servidor de gerenciamento de firewalls [7]:

1. Pressão de memória: requisições multipart construídas para esgotar a memória e moldar o comportamento do alocador do PHP [7].
2. Vazamento de endereço: um identificador de sessão forjado faz o servidor devolver, no cabeçalho Set-Cookie, um ponteiro da biblioteca libphp.so, o que permite calcular os demais endereços [7].
3. Referência obsoleta: nova pressão de memória cria a referência para memória liberada; uma entrada forjada de tabela de dispersão desvia uma rotina de limpeza para a função system() [7].
4. Execução: o comando roda com a conta sem privilégios do servidor web, nobody no caso documentado [7].

O operador seguiu com a falha de kernel Fragnesia (CVE-2026-46300) para virar root e instalou uma webshell PHP de 103 bytes; a cadeia completa levava menos de 15 minutos por alvo [7]. A pós-exploração, com túneis, roubo de credenciais e ataque ao Active Directory, está no relatório Da webshell ao root.

06Verificação: a exposição do CiberLab

A plataforma CiberLab foi verificada em duas camadas: a aplicação em si e a infraestrutura que a publica. A conclusão é que a aplicação não é afetada, mas o painel de publicação usa PHP e precisa estar na versão corrigida.

07Detecção

A detecção vai do mais barato (o registro de erros que já existe) ao mais caro (a telemetria de processos no host). Os sinais abaixo vêm da Datadog [4] e da Unit 42 [5].

7.1Registros de erro

Dois padrões merecem alerta imediato [4]:

PHP Fatal error:  Allowed memory size of 16777216 bytes exhausted
  (tried to allocate 3500032 bytes) in Unknown on line 0

AH00052: child pid 12345 exit signal Segmentation fault (11)

O local Unknown on line 0 significa que a memória acabou antes de qualquer script rodar, ou seja, durante a leitura da requisição [4]. Uma rajada curta desses erros num mesmo trabalhador pode ser a preparação do ataque; cadeias mais novas produzem só dois a quatro erros antes de silenciar [4].

7.2Padrões na requisição

1. Campos de sessão inesperados: POST multipart com campos PHPSESSID e PHP_SESSION_UPLOAD_PROGRESS onde a aplicação não os usa [4].
2. Estrutura anômala: centenas de partes (os exemplos públicos usam cerca de 900 partes em menos de 1 MB) e nomes de campo com aninhamento profundo, como files[R00001][a][a][a] [4].
3. Corpo gigante de campo único: application/x-www-form-urlencoded com um único campo de 3 a 60 MB, contendo bytes nulos e caracteres de controle [4].
4. Nomes de arquivo com código: uploads cujo nome contém <?php ou |O: [4].
5. Cookie de sessão fora do padrão: respostas com Set-Cookie: PHPSESSID= anormalmente longo ou codificado, sinal do vazamento de endereço [4] [7].

7.3Regra Sigma para registros de erro

A CISA publicou uma regra Sigma própria no seu repositório [3]. A regra abaixo, derivada dos sinais de [4], cobre o registro de erro do PHP, que existe mesmo sem telemetria de rede:

title: Esgotamento de memoria antes do script, possivel PHP2Shell
id: 3f6c2a10-8d47-4b1e-9a52-c07e14d9b8a1
status: experimental
description: Erro fatal de memoria em "Unknown on line 0", sinal de ataque
    as CVE-2026-109618 e CVE-2026-109619 durante a leitura da requisicao
author: CiberLab (Ciência Embarcada)
references:
    - https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
    - https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/
logsource:
    product: php
    category: application
detection:
    selection:
        message|contains|all:
            - 'Allowed memory size of'
            - 'in Unknown on line 0'
    condition: selection
falsepositives:
    - Uploads legitimos muito grandes com memory_limit baixo
level: high
tags:
    - attack.initial_access
    - attack.t1190
    - cve.2026-109618
    - cve.2026-109619

7.4Sinais no host

A evidência mais direta de exploração é um shell ou utilitário de download iniciado por um processo do Apache ou do PHP, por exemplo a árvore apache2 (www-data), sh -c, bash com conexão de saída [4]. A Unit 42 publicou consultas que pontuam sinais desse tipo a partir de processos do servidor web e de contas de serviço (www-data, apache, nginx): reconhecimento, download, gravação em diretório executável, shell reverso e acesso a credenciais [5]. Arquivos PHP novos em diretórios públicos, sobretudo pequenos, são o rastro da webshell [7].

08Mitigação e resposta a incidentes

8.1Correção definitiva

Atualize para PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou para o pacote corrigido da sua distribuição, e reinicie todos os trabalhadores [1] [2] [3]. Comece pelos sistemas expostos à internet [3]. Em contêineres, reconstrua a imagem com a base atualizada: a correção do sistema operacional não alcança um PHP compilado dentro da imagem [4]. Sistemas em PHP 8.1 ou anterior devem sair do ar até a migração [3].

8.2Medidas parciais enquanto a atualização não sai

Os avisos oficiais deixam claro que nenhuma destas medidas fecha a falha; elas apenas estreitam o caminho conhecido [1] [2]:

1. Desligue o progresso de upload: session.upload_progress.enabled=0, recomendado inclusive depois da atualização se o recurso não for usado [2]. Também cobre a CVE-2026-115560 [9].
2. No PHP 8.5, desligue os backtraces de erro fatal: fatal_error_backtraces=0, o que remove o produtor de RCE confirmado [2].
3. Limite o corpo da requisição na borda: mantenha post_max_size conservador, reduza max_input_nesting_level, limite variáveis, partes e uploads, e bloqueie multipart no proxy onde a aplicação não o usa [1].
4. Não use RLIMIT_AS nem RLIMIT_DATA: esses limites provocam justamente as falhas de alocação de que o ataque precisa [1] [4].
5. Recicle os trabalhadores: pm.max_requests=1 no PHP-FPM, se o desempenho permitir, encurta a vida do estado global obsoleto [2].
6. Isole o que não precisa estar público: tire interfaces de gerenciamento da internet e restrinja a origem [3] [5].

8.3Resposta a um comprometimento

Trate como comprometido todo servidor sem atualização com os sinais da seção 7. Preserve os registros, procure PHP novo em diretórios públicos e verifique /etc/pam.d/su, serviços systemd e scripts de inicialização, pontos de escalada e persistência da campanha da Dream [7]. Gire os segredos da conta do servidor web e reconstrua a máquina. Com kernel vulnerável à CVE-2026-46300, assuma que o atacante chegou a root [6] [7].

8.4Mapeamento de técnicas MITRE ATT&CK

IDs e nomes conferidos na base oficial do MITRE ATT&CK for Enterprise [10]:

09Indicadores de comprometimento

Nenhuma fonte publicou IPs, domínios ou hashes do PHP2Shell [5] [7]. Os indicadores são de comportamento e de artefato, do sinal mais forte ao mais fraco:

10Limitações da análise

1. Ausência de detonação: o CiberLab não reproduziu as falhas nem executou exploit. Causa raiz, sinais e cronologia vêm das referências [1] a [9].
2. Sem indicadores de rede: nenhuma fonte publicou IPs, domínios ou hashes. A tabela 6 é de comportamento e artefato; não a use como lista de bloqueio.
3. Regra derivada: a regra Sigma da seção 7.3 foi deduzida de [4] e não foi testada; ajuste o nome do campo ao seu coletor.
4. Exposição da infraestrutura: a versão do Coolify em execução não foi verificada, porque exige acesso ao painel [8].
5. CVE-2026-115560 em aberto: sem correção nem versões afetadas publicadas na data de emissão [9]. Revise este relatório quando o aviso completo sair.