Patches para o php2shell já estão disponíveis para as versões do PHP 5.2 a 8.1

Principais conclusões

• php2shell é o nome dado a duas falhas críticas de execução remota de código (RCE) no núcleo do PHP, CVE-2026-109618 e CVE-2026-109619.
• O PHP corrigiu esses problemas nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35, mas os ramos com fim de vida útil não recebem patches do desenvolvedor original.
• Foram relatadas tentativas de ataque antes do lançamento; portanto, aplique a correção agora e reinicie todos os workers do PHP.
• O Endless Lifecycle Support (ELS) da TuxCare para ambientes de execução já disponibiliza compilações corrigidas para versões do PHP que chegaram ao fim da vida útil.

A versão resumida

Ir para a versão completa ↓

O que é: php2shell é o apelido que os pesquisadores deram às vulnerabilidades CVE-2026-109618 e CVE-2026-109619, duas vulnerabilidades críticas de execução remota de código no próprio PHP, e não em qualquer framework ou CMS. A notícia sobre elas vazou em 20 de outubro de 2026, antes da divulgação planejada, e a equipe de segurança do PHP antecipou sua versão de emergência para 21 de outubro.

Impacto: Ambas as vulnerabilidades permitem que um invasor não autenticado execute código na conta do usuário do processo de trabalho do PHP; no entanto, o grau de vulnerabilidade de um determinado servidor depende da forma como o PHP é executado nele. O PHP confirmou a possibilidade de RCE total contra o mod_php do Apache com limites padrão e também validou uma via de exploração contra o PHP-FPM. Ir para esta seção →

Gravidade: A equipe de segurança do PHP atribui a ambas a classificação 9,2 segundo o CVSS v4.0, o que corresponde a “crítico”. A classificação 10,0 que circulou com o vazamento nunca foi atribuída pelo PHP. Ir para esta seção →

Quem é afetado: os alertas do PHP abrangem as versões afetadas em todos os quatro ramos suportados, enquanto a ferramenta de exploração que vazou afirma funcionar até a versão 5.4.0. O projeto original (upstream) corrige apenas as versões 8.2 a 8.5; portanto, o PHP 8.1, 8.0, 7.x e 5.x não recebem nenhuma correção do php.net, e Mallory contabilizou cerca de 884.000 hosts expostos à Internet que executam uma dessas versões. Ir para esta seção →

Status: Dane Knecht, diretor de tecnologia (CTO) da Cloudflare, relatou tentativas iniciais de ataque contra sites em PHP às 07h43 UTC do dia 21 de outubro, horas antes do lançamento, embora não esteja claro quantas delas tenham sido bem-sucedidas. As compilações do Endless Lifecycle Support (ELS) para Runtimes, que corrigem ambas as vulnerabilidades (CVEs), já estão disponíveis para todos os ramos em fim de vida, do PHP 5.2 ao 8.1.

Faça isso agora: identifique todas as instalações de PHP que você possui, incluindo as cópias integradas em softwares de fornecedores e painéis de controle, e comece por qualquer sistema que esteja executando o mod_php do Apache, sem deixar de lado os hosts que usam o FPM. Atualize os ramos compatíveis a partir do código-fonte original ou da sua distribuição e transfira aqueles que chegaram ao fim da vida útil para uma versão ELS fixa ou retire-os da internet pública. Em seguida, reinicie ou substitua todos os workers do PHP, pois o código antigo continua atendendo às solicitações até que esse processo seja encerrado. Para verificar o que está realmente em execução:

ps aux | grep -E '[p]hp-fpm|[p]hp-cgi|[l]sphp|[h]ttpd|[a]pache2'

Enquanto você analisa a lista, fique atento a processos de trabalho do PHP que estejam iniciando shells ou baixando ferramentas. É assim que geralmente se manifesta uma exploração.

Ir para esta seção →

A maioria das emergências em PHP começa com um aplicativo. Um plugin do WordPress, uma extensão do Magento, um pacote do Laravel que ninguém mexe desde 2019. Você o atualiza, altera algumas chaves secretas e segue em frente. Nada disso afeta o interpretador subjacente.

O php2shell não funciona assim. As vulnerabilidades estão no interpretador; portanto, o software afetado é, basicamente, “qualquer coisa que execute PHP”, e a correção só é implementada em quatro ramificações mantidas. Quem ainda estiver executando o PHP 7.4 em um aplicativo de faturamento legado (e há muitos deles) descobriu que existe uma vulnerabilidade crítica de RCE para a qual não há previsão de patch do desenvolvedor original, nunca.

Há também um terceiro problema. Essas falhas vieram a público na forma de rumores antes de serem divulgadas como correções, e os invasores começaram a testar as vulnerabilidades antes mesmo que as correções fossem lançadas.

A pontuação atual do CVSS 4.0 do NIST é 9,2 (Crítica), mas havia outros números não confirmados circulando por aí. Na manhã de 20 de outubro, uma postagem no Hacker News alegava que duas falhas de execução remota de código no PHP, classificadas com 10,0 e que remontavam ao PHP 5, seriam divulgadas na quinta-feira, 22 de outubro. O autor da postagem não apresentou nenhuma evidência além de “fonte: confia em mim, cara”. A postagem foi removida, mas capturas de tela já estavam por toda parte.

Esse boato não morreu, porque o watchTowr publicou que a informação era verdadeira, que as falhas estavam sob embargo e que todos deveriam esperar até quinta-feira. Às 19h33 UTC daquela noite, Jakub Zelenka enviou o aviso prévio da equipe de segurança do PHP para a lista php.announce. O comunicado confirmou duas vulnerabilidades críticas, ambas com pontuação 9,2 segundo o CVSS v4.0, com lançamento previsto para o dia seguinte, 21 de outubro, e reservou-se o direito de lançar a correção antes do previsto caso os detalhes viessem a público ou surgissem tentativas de exploração.

O embargo perdeu um dia, e muitas outras pessoas estavam vendo as mesmas capturas de tela. Às 07h43 UTC da manhã seguinte, o diretor de tecnologia (CTO) da Cloudflare afirmou que a empresa estava observando os primeiros ataques surgindo, e suas regras provisórias do WAF foram aplicadas a todos os planos, incluindo o plano gratuito.

A nota prévia do PHP não mencionou nenhum dos dois CVEs, aliás. Os identificadores circularam inicialmente por meio do material vazado e das reportagens do watchTowr, e os alertas do PHP os confirmaram quando as correções foram lançadas.

Antes da divulgação, as informações disponíveis ao público eram escassas. A watchTowr afirmou acreditar ter reproduzido a vulnerabilidade CVE-2026-109618; a Huntress não havia criado uma prova de conceito; e, segundo a Sansec, a captura de tela vazada do PHP2Shell mostrava um banner alegando cobertura de todas as versões a partir da 5.4.0. Os dois alertas do PHP, divulgados em 21 de outubro, preencheram a maior parte das lacunas.

CVE-2026-109618, “RCE por meio de corrupção de OOM”, resume-se à forma como o PHP lida com erros de falta de memória. Ele utiliza longjmp() para abortar a solicitação; e, se alguma alocação falhar enquanto a memória da solicitação estiver apenas parcialmente inicializada, o código de desligamento posteriormente detecta esse estado de falha ou executa um desvio de instrução com base nele. A análise em partes oferece aos invasores várias maneiras de provocar um erro de memória insuficiente (OOM) sem ultrapassar os limites aparentes, como partes com um número ilimitado de cabeçalhos. No mod_php, tudo isso ocorre durante a inicialização da solicitação, antes que qualquer código do aplicativo seja executado.

CVE-2026-109619, “RCE via estado global desatualizado”, é uma vulnerabilidade do tipo “use-after-free” que se estende por várias solicitações. Um erro fatal, incluindo OOM, pode fazer com que um worker persistente mantenha ponteiros para a memória que pertencia a uma solicitação já encerrada. Uma solicitação posterior no mesmo worker então acessa esse estado obsoleto antes que a inicialização normal o reinicie. É mais complicado de ser executado, mas o PHP ainda confirmou a RCE contra o mod_php e validou o caminho da sessão contra o PHP-FPM.

Portanto, a forma como você executa o PHP é importante. O mod_php é o pior cenário para ambos. O FPM encerra um processo filho quando a inicialização da solicitação falha, o que bloqueia a sequência mais limpa de OOM, mas o PHP ainda o trata como vulnerável. O PHP considera o FrankenPHP provavelmente vulnerável a ataques de OOM independentes da aplicação, assim como o mod_php, e o LSAPI se comporta mais como o FPM.

A conexão do progresso do upload

Aquele banner da versão 5.4.0 acabou sendo uma boa pista. O PHP 5.4 introduziu o progresso de upload por sessão, que permite que um script verifique em que ponto um upload multiparte se encontra. Ele vem ativado por padrão, e o próprio comunicado do PHP o descreve como pouco utilizado. Ele também é um explorador confirmado na vulnerabilidade CVE-2026-109619, pois acessa o gerenciamento de sessões antes da inicialização normal e pode recuperar o estado deixado por uma solicitação interrompida, sem session_start() É preciso ligar. A análise de um pesquisador já havia apontado um problema de “use-after-free” nesse caminho de código antes da divulgação dos alertas, e estava bem próximo da verdade.

Desativar o recurso ainda não resolve o problema. Gina Banyard, da equipe principal do PHP, afirmou desde o início que a aplicação de patches é a única medida de mitigação, e ambos os alertas corroboram sua afirmação, indicando que uma atualização é a única solução completa e confiável. Desativar o progresso do upload bloqueia o caminho de sessão demonstrado, mas não bloqueia nenhum dos outros caminhos do ciclo de vida.

Se alguns servidores não puderem receber a correção hoje, a solução provisória do PHP para esse caminho será aplicada php.ini ou uma visita sem agendamento em conf.d, e o Sansec ainda inclui o modo de sessão restrita:

session.upload_progress.enabled = 0
session.use_strict_mode = 1

Os pools do FPM podem substituir as configurações principais do INI; portanto, verifique a configuração efetiva de cada pool. Caso um pool precise de uma substituição específica, utilize estas configurações e, em seguida, reinicie seus workers:

php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[session.use_strict_mode] = on

O modo de sessão restrita é uma funcionalidade própria do PHP orientações sobre segurança de sessão vem defendendo há anos, de modo que a primeira opção custa quase nada, embora o Redis ou os gerenciadores de sessão do banco de dados possam não implementar a verificação de ID da qual ela depende. Outras soluções provisórias incluem fatal_error_backtraces=0 no PHP 8.5 e bloqueando solicitações multipart no front-end caso o aplicativo nunca aceite uploads. Para o CVE-2026-109618, a principal medida provisória de configuração do PHP consiste em impor memory_limit=-1 administrativamente e reiniciando todos os workers, o que elimina o limite previsível por solicitação do qual a vulnerabilidade confirmada depende. Tenha cuidado ao aplicar essa medida, pois ela também desativa a proteção do PHP contra scripts fora de controle, e o próprio PHP afirma que ela não está completa. Nenhuma dessas medidas é uma correção definitiva. Trate-as como medidas provisórias até que todos os servidores recebam o patch.

Por que o PHP em fim de vida é o maior problema

A página de versões compatíveis do PHP é bem clara quanto a isso. As versões 8.4 e 8.5 estão em suporte ativo, as versões 8.2 e 8.3 recebem apenas correções de segurança, e todas as versões mais antigas estão no fim do ciclo de vida. As versões no fim do ciclo de vida não recebem atualizações de segurança do php.net, e nem mesmo uma vulnerabilidade crítica de execução remota de código (RCE) muda isso.

Os números relativos ao que ainda está em uso não são nada animadores. Mallory contabilizou cerca de 884 mil hosts expostos à Internet cujo banner HTTP indicava PHP 8.1 ou versões anteriores em 20 de outubro, o que representa cerca de 59% dos hosts que informaram alguma versão. Os banners não confirmam a exposição, e alguns desses hosts executam pacotes retroportados. Ainda assim, é um número impressionante de hosts expostos à Internet que apresentam versões desatualizadas do PHP.

As instalações que causam problemas são aquelas que ninguém considera servidores PHP. Aparelhos de fabricantes. Softwares do Windows que vêm com seu próprio php-cgi.exe (O ELS for Runtimes também oferece compilações do PHP para Windows, exatamente por esse motivo). Painéis de controle. Uma wiki interna que alguém criou em 2017 e nunca mais mencionou.

Imagine uma agência com 30 funcionários hospedando algumas centenas de sites de clientes no WordPress em um único servidor cPanel, com metade das contas limitadas ao PHP 7.4 porque um tema premium deixa de funcionar corretamente na versão 8.x. Ninguém vai conseguir migrar todos esses sites para o PHP 8 até sexta-feira. A atualização do PHP é um projeto de aplicação, e é exatamente por isso que tantas instalações do PHP 7.x ainda estão em funcionamento.

É essa lacuna que o ELS para Runtimes se propõe a preencher. A TuxCare adapta correções de segurança para ramificações em fim de vida útil; assim, um site fixado na versão 7.4 recebe a correção do php2shell sem precisar passar por uma migração forçada para o PHP 8 durante uma vulnerabilidade de execução remota de código (RCE) ativa. A migração ainda precisa ocorrer. A diferença é que ela passa a acontecer de acordo com um cronograma definido pelo usuário.

De onde vem a correção do php2shell, por ramificação, com as datas de suporte do próprio PHP:

Ambos os avisos listam as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 como as versões corrigidas, e o changelog do PHP traz os detalhes por ramo. Instale a versão correspondente e, em seguida, confirme se os processos que atendem às solicitações realmente a executam.

Se o PHP vier dos próprios repositórios da sua distribuição Linux, é o aviso dessa distribuição que prevalece. As distribuições costumam fazer o backport de correções sem alterar o número da versão do desenvolvedor original; portanto, a string da versão, por si só, não é determinante.

Adquira hoje mesmo o ELS para Runtimes →

O PHP já passou por isso antes

Em maio de 2012, foram divulgados detalhes sobre o CVE-2012-1823, uma vulnerabilidade que permite a execução remota de código no php-cgi, foram acidentalmente divulgadas antes que a correção estivesse pronta. O PHP lançou às pressas as versões 5.3.12 e 5.4.2. Stefan Esser e outros demonstraram rapidamente que a correção podia ser contornada, e o PHP teve que lançar novas versões dias depois, já que A revista Computerworld informou que naquela época.

Depois, há o CVE-2024-4577, do Windows php-cgi injeção de argumentos a partir de junho de 2024. A Akamai detectou tentativas de exploração contra seus honeypots em até 24 horas após a divulgação, de acordo com The Hacker News.

Bugs divulgados antecipadamente reduzem o prazo de todos, inclusive dos desenvolvedores responsáveis pela correção, e essas correções apressadas às vezes precisam de uma segunda revisão. Continue acompanhando os alertas por alguns dias após aplicar a correção.

Veja o que o PHP gera

A RCE no nível do interpretador tende a apresentar o mesmo padrão, independentemente de como a falha funcione. Um worker PHP, como, por exemplo, php-fpm, php-cgi, lsphp ou um processo do Apache inicia algo que normalmente não inicia. Shells, Python ou Perl, curl ou wget. Linhas de comando que contenham /dev/tcp/ ou mkfifo são sinais clássicos de um reverse shell, assim como um php -r chamada em uma única linha fsockopen. Uma explosão de whoami, id ou uname -a A execução como usuário do servidor web indica que alguém está fazendo um reconhecimento. Nenhum desses fatores, por si só, constitui prova, já que as ferramentas de administração realizam algumas dessas mesmas ações. O que importa é uma árvore de processos atípica que coincida com uma solicitação ou com um arquivo recém-criado.

Em servidores Linux sem detecção de endpoints, o “process-watcher” gratuito de Florian Roth registra todos os programas iniciados por um processo PHP, juntamente com sua linha de comando completa. Roth deixa claro que a ferramenta não bloqueia nada — ela apenas monitora. Para uma análise rápida de um momento específico, enquanto isso:

ps -eo pid,ppid,user,args --forest | grep -A3 '[p]hp-fpm'

Se algo for detectado, isole o servidor e preserve os logs do servidor web e do PHP antes que alguém “limpe” os registros. Um log de acesso vazio não significa que tudo está em ordem, já que os logs padrão não registram os corpos das solicitações POST. Procure por webshells, novos arquivos na raiz do site, novas tarefas cron e novas contas. Aplicar patches em um host comprometido é como fechar a porta com o invasor ainda lá dentro. Quando não for possível aplicar patches imediatamente, o CERT-EU recomenda considerar retirar os aplicativos expostos à Internet das redes públicas até que uma correção esteja disponível. Um WAF ou uma VPN na frente de uma filial antiga ganha tempo, e isso é tudo o que ganha.

O inventário vem em primeiro lugar, e a lista costuma ser mais longa do que se imagina. Este loop verifica os locais habituais do Linux, as compilações do ELS em /opt/alt/ incluídos e exibe a versão informada por cada arquivo binário. É um ponto de partida, já que compilações personalizadas e pacotes de fornecedores podem estar em qualquer lugar:

for p in /usr/bin/php /usr/bin/php[0-9]* /opt/alt/php*/usr/bin/php; do [ -x "$p" ] && echo "$p $("$p" -r 'echo PHP_VERSION;')"; done

Isso mostra o que está no disco, não o que cada site executa, já que os pools do FPM, os vhosts e os painéis de controle podem apontar, cada um, para um binário diferente. Verifique essas configurações também. As ramificações suportadas recebem a atualização do upstream ou da distribuição. O ELS for Runtimes realiza a atualização por meio do gerenciador de pacotes normal, usando os comandos descritos na documentação do ELS for Runtimes PHP da TuxCare. Em sistemas baseados em RPM, o comando é `sudo yum update alt-php*`. No Debian e no Ubuntu, atualize as listas de pacotes e faça o upgrade dos pacotes alt-php:

sudo apt-get update
sudo apt-get upgrade alt-php*

Em seguida, a etapa que costuma ser ignorada. Não basta instalar o pacote corrigido enquanto os workers ainda estiverem executando o código antigo. Um servidor PHP-FPM em execução, ou mod_php carregado dentro do Apache, mantém o código antigo na memória até que seja reiniciado, e um contêiner o mantém até que seja substituído. Servidores de hospedagem compartilhada com dezenas de pools de FPM são o caso clássico, em que uma versão é reiniciada e três não. Verifique se todos os mestre do FPM foram iniciados após a aplicação da atualização:

ps -eo pid,lstart,args | grep '[p]hp-fpm: master'

Por fim, não feche o ticket com base na comparação de versão do upstream feita por um scanner. Uma versão do ELS ou da distribuição que tenha sido adaptada para versões anteriores ainda pode informar o número da versão original do upstream; assim, scanners que leem apenas strings de versão podem sinalizar hosts que já estão corrigidos. Quando suas ferramentas permitirem, forneça a elas os dados de segurança legíveis por máquina da TuxCare, que incluem feeds OVAL e CSAF. Registre o pacote instalado, o aviso de segurança ao qual ele se refere e o processo que realmente atende às solicitações, pois é isso que um auditor irá solicitar.

Por que o php2shell é importante

Um runtime é uma dependência, e deixar de oferecer suporte a ele significa que toda nova vulnerabilidade no núcleo pode permanecer sem correção indefinidamente. As equipes monitoram cuidadosamente seus pacotes do Composer e, em seguida, os executam em um interpretador que deixou de receber correções de segurança há anos.

O vazamento também mostrou quão pouco tempo de aviso prévio as pessoas têm. Os primeiros rumores foram confirmados em questão de horas, a correção foi lançada no dia seguinte e as tentativas de ataque surgiram antes mesmo que ela fosse disponibilizada. A frase “Vamos fazer a atualização no próximo trimestre” não se sustenta em um cronograma como esse.

Também surgiu uma opção “faça você mesmo”. O PHP enviou backports para as versões 7.4, 8.0 e 8.1 ao repositório php-src sem marcar as versões, e os scripts da comunidade agora recompilam o PHP compilado a partir do código-fonte com esses backports. Isso pode funcionar para um único servidor compilado pelo próprio usuário, mas corrige apenas o php2shell e nada além disso, ignora os pacotes das distribuições, o `mod_php` e o `lsphp`, e transforma cada CVE futuro do PHP novamente em um projeto de compilação.

Então, aplique as correções nos ramos compatíveis agora e reinicie o que precisar ser reiniciado. Quanto ao PHP que o php.net deixou para trás, transfira-o para uma versão ELS corrigida ou retire-o da internet; depois, coloque a migração de verdade no calendário, em vez de deixá-la na lista de desejos.

Adquira hoje mesmo o ELS para Runtimes →

Linha do tempo

Referências

As fontes principais desta publicação são os alertas de segurança do PHP sobre RCE por meio de corrupção de OOM (CVE-2026-109618) e RCE por meio de estado global desatualizado (CVE-2026-109619), o aviso prévio da equipe de segurança do PHP no php.announce (20 de outubro de 2026), a página de versões suportadas do PHP e o changelog do PHP 8, o FAQ sobre o php2shell da watchTower, a pesquisa sobre o php2shell da Sansec, o relatório de resposta rápida da Huntress, o Alerta de Segurança 2026-018 do CERT-EU, a análise de exposição da Mallory, o process-watcher de Florian Roth, as entradas do NVD para CVE-2026-109618 e CVE-2026-109619, a cobertura do The Hacker News e a documentação do ELS for Runtimes PHP da TuxCare.