PHP2Shell: duas falhas críticas no PHP colocam milhões de aplicações web em risco. Entenda os impactos e como se proteger.

Redação

há 9 minutos

13 min de leitura

CVE-2026-109618 e CVE-2026-109619 permitem a execução remota de código sem autenticação. Governos e empresas já adotaram medidas emergenciais, enquanto especialistas alertam que atualizações são a única correção definitiva.

Em 21 de outubro de 2026, a comunidade responsável pelo PHP publicou correções emergenciais para duas vulnerabilidades críticas identificadas como CVE-2026-109618 e CVE-2026-109619, ambas classificadas com severidade 9,2 na escala CVSS 4.0.

O conjunto de vulnerabilidades, denominado PHP2Shell, permite, sob condições exploráveis, que atacantes executem código remotamente em servidores vulneráveis, sem precisar de credenciais de acesso.

O problema é especialmente relevante porque não está localizado em uma aplicação, biblioteca ou plugin específico. As vulnerabilidades estão no próprio mecanismo de execução do PHP, utilizado por plataformas como WordPress, Drupal, Joomla, Magento, Laravel e milhares de sistemas desenvolvidos sob medida.

Segundo dados de utilização da tecnologia, o PHP está presente em aproximadamente 70% dos websites cujo ambiente de programação do lado do servidor é identificado. Isso não significa que 70% da internet foi comprometida, mas demonstra a dimensão potencial da superfície de ataque.

O que acontece tecnicamente?

As duas vulnerabilidades envolvem falhas no gerenciamento de memória do interpretador PHP. Elas permitem explorar situações em que o processo mantém ou utiliza estruturas internas em condições inconsistentes.

CVE-2026-109618: corrupção de memória durante falhas de alocação

O PHP utiliza mecanismos de interrupção quando uma operação não consegue alocar a memória necessária, situação conhecida como Out of Memory (OOM). Em determinados cenários, essa interrupção ocorre antes que estruturas internas sejam completamente inicializadas. Quando o interpretador tenta liberar os recursos da requisição, pode tratar dados inválidos como estruturas legítimas.

Um atacante pode utilizar requisições HTTP especialmente construídas para provocar essa condição e explorar a corrupção de memória resultante. O impacto pode variar entre encerramento inesperado do processo, exposição de informações da memória e execução remota de código.

CVE-2026-109619: reutilização indevida de memória liberada

A segunda vulnerabilidade está relacionada ao problema conhecido como Use After Free (UAF). O PHP pode manter referências a regiões de memória pertencentes a uma requisição já encerrada. Quando outro pedido é processado pelo mesmo trabalhador (worker), essas referências podem ser utilizadas antes que o estado interno seja corretamente reinicializado. Isso possibilita acessar informações antigas, corromper estruturas internas e, em condições exploráveis, executar código arbitrário. O problema é particularmente sensível em servidores que reutilizam processos para atender múltiplas requisições.

Por que isso é diferente de uma vulnerabilidade convencional?

Em uma falha tradicional de aplicação, o atacante normalmente explora um erro na lógica do sistema, como uma validação insuficiente ou uma consulta insegura ao banco de dados. Neste caso, a aplicação pode seguir boas práticas de desenvolvimento e ainda permanecer vulnerável, porque a falha está no ambiente que executa o código.

Os pesquisadores demonstraram ataques contra instalações de WordPress, Drupal e Joomla, inclusive sem explorar defeitos específicos dessas plataformas. Ambientes Apache com mod_php apresentam risco particularmente elevado, pois existe exploração demonstrada antes mesmo que o código da aplicação seja executado. Instalações com PHP-FPM, php-cgi, FrankenPHP e LiteSpeed também precisam ser avaliadas. O uso de uma dessas alternativas não garante imunidade.

Como essas vulnerabilidades foram descobertas?

A descoberta resultou de pesquisas de segurança independentes que posteriormente passaram a integrar um processo coordenado de correção.

Em agosto de 2026, pesquisadores da Calif Research, com apoio da OpenAI, e pesquisadores da Wiz Research identificaram problemas críticos no código-fonte do PHP. As análises utilizaram modelos avançados de inteligência artificial para examinar comportamentos complexos do gerenciador de memória.

A Calif trabalhou com o GPT-5.6 Sol, enquanto a Wiz utilizou ferramentas como Wiz Atlas, Gemini 4 Argon e GPT-5.6 Sol. Parte das condições que originaram os problemas já havia sido discutida em pesquisas anteriores, inclusive em uma auditoria realizada em 2024. Entretanto, ainda não existia uma demonstração prática suficientemente convincente de execução remota de código para esses caminhos.

O uso de IA acelerou a identificação das relações entre diferentes falhas de tratamento de memória, permitindo construir e validar cenários de exploração que exigiriam análises manuais muito complexas. Após a confirmação dos problemas, os pesquisadores trabalharam com os mantenedores do PHP e empresas de infraestrutura para preparar correções.

Em 20 de outubro, o PHP Security Team anunciou antecipadamente a necessidade de uma atualização crítica. No dia seguinte, foram disponibilizados os pacotes corrigidos. A divulgação foi especialmente sensível porque detalhes técnicos circularam antes da publicação coordenada das correções.

Ataques aconteceram antes da publicação?

Sim. A Amazon Threat Intelligence identificou retrospectivamente uma tentativa de exploração datada de 17 de outubro de 2026, quatro dias antes da divulgação pública das vulnerabilidades. A atividade foi encontrada na telemetria do MadPot, a rede de sistemas utilizados pela AWS para observar ataques.

Em 21 de outubro de 2026, outras tentativas foram detectadas, incluindo o uso de diferentes códigos de exploração e infraestruturas de origem. Isso não comprova que todos os ataques foram bem-sucedidos, mas confirma que o risco não era apenas teórico. O episódio evidencia uma mudança importante na segurança de aplicações: o intervalo entre a descoberta de uma vulnerabilidade, a disponibilização de sua exploração e os ataques em escala está diminuindo.

Quais são os impactos para empresas?

Uma exploração bem-sucedida pode comprometer diretamente a confidencialidade, a integridade e a disponibilidade de sistemas.

Entre os principais impactos estão:

Vazamento de dados: acesso a informações processadas pela aplicação, credenciais, tokens de autenticação, chaves de API e outros dados disponíveis na memória.
Execução de código não autorizado: execução de instruções com os privilégios do processo PHP, possibilitando alterações no ambiente e novas ações maliciosas.
Comprometimento de aplicações: modificação de páginas, arquivos, código e funcionalidades do sistema.
Interrupção operacional: encerramento de processos, instabilidade, indisponibilidade ou comprometimento de serviços essenciais.
Movimentação lateral: utilização de um servidor comprometido como ponto de partida para atacar bancos de dados, serviços internos ou outros recursos acessíveis.

É importante esclarecer que a execução remota de código não significa necessariamente acesso imediato como administrador ou root. O atacante inicialmente obtém os privilégios associados ao processo comprometido.

Entretanto, configurações inadequadas, permissões excessivas e credenciais disponíveis no ambiente podem ampliar consideravelmente os danos. Além das consequências técnicas, organizações afetadas podem enfrentar paralisação comercial, perda de confiança e obrigações de investigação e comunicação conforme a legislação aplicável, incluindo a LGPD no Brasil.

Quais versões do PHP estão vulneráveis?

As falhas atingem uma ampla faixa de versões, incluindo implementações antigas desde o PHP 5.4. O projeto PHP disponibilizou quatro versões corrigidas em 21 de outubro:

Linha PHP	Primeira versão oficial corrigida
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1 e anteriores	Sem nova release oficial

As versões 8.1 e anteriores estão fora do ciclo de suporte do projeto principal, mas isso não significa que toda instalação antiga esteja necessariamente sem possibilidade de correção. Algumas distribuições Linux e fornecedores de suporte estendido disponibilizam correções incorporadas às versões anteriores, chamadas backports.

O Ubuntu, por exemplo, publicou correções para seu PHP 8.1 no Ubuntu 22.04 LTS, preservando a versão principal do interpretador. O próprio PHP Security Team também disponibilizou backports mínimos em código-fonte para as linhas 7.4, 8.0 e 8.1. Por isso, não basta comparar o número da versão exibido pelo servidor. É necessário verificar a origem do pacote, seu histórico de atualizações e os boletins de segurança do fornecedor.

Outro ponto importante: o PHP 8.2 está previsto para encerrar seu suporte de segurança em 31 de dezembro de 2026. Empresas que precisam realizar migrações devem avaliar preferencialmente versões com maior período de suporte restante.

Como corrigir definitivamente?

A correção deve atuar sobre o interpretador PHP utilizado pela aplicação.

Atualizar apenas o WordPress, Laravel, Drupal ou qualquer outro sistema construído em PHP não elimina essas vulnerabilidades.

1. Identificar todos os ambientes que executam PHP

O inventário deve abranger servidores físicos e virtuais, hospedagens compartilhadas, instâncias em nuvem, contêineres, aplicações internas, sistemas legados e produtos que utilizem PHP como componente embarcado.

Em servidores Linux, uma verificação inicial pode ser realizada com:

php -v

Nos ambientes Debian e Ubuntu, os pacotes instalados também podem ser consultados com:

dpkg -l 'php*'

Esses comandos são apenas o início da identificação. A versão PHP utilizada pela linha de comando pode ser diferente da versão realmente carregada pelo Apache, pelo PHP-FPM ou por uma aplicação específica. Também é necessário verificar múltiplas instalações, pools de PHP-FPM, imagens Docker e ambientes que utilizam PHP embarcado.

2. Aplicar as atualizações disponibilizadas

Nos ambientes Ubuntu e Debian que utilizam pacotes mantidos pelos repositórios do sistema, o procedimento inicial é:

sudo apt update

sudo apt upgrade

Antes da atualização, especialmente em produção, devem ser avaliados backup, compatibilidade, dependências e um plano de reversão. A simples execução desses comandos não comprova que a vulnerabilidade foi corrigida. É necessário confirmar que o repositório utilizado já disponibiliza os pacotes de segurança e que eles foram instalados.

Em distribuições baseadas em RHEL, o processo correspondente utiliza o gerenciador dnf ou a ferramenta de atualização apropriada ao fornecedor. Para ambientes cPanel/WHM, o fabricante publicou versões corrigidas dos componentes EasyApache 4, inclusive para determinadas linhas antigas de PHP.

No CloudPanel, deve-se atualizar os pacotes fornecidos pelo repositório utilizado pela plataforma, não apenas os componentes do sistema operacional. Em contêineres Docker, a correção normalmente exige reconstruir a imagem utilizando uma base PHP corrigida e realizar uma nova implantação. Atualizar somente o host não corrige automaticamente o interpretador existente dentro da imagem.

3. Reiniciar os processos e validar

Após instalar os pacotes corrigidos, é necessário reiniciar os processos que mantêm o PHP carregado, como Apache ou PHP-FPM, conforme a arquitetura utilizada. A validação deve confirmar que:

O serviço em produção efetivamente utiliza uma versão corrigida ou um pacote com backport confirmado.
Todos os workers antigos foram substituídos.
O site, as APIs e as principais operações continuam funcionando.
Não existem contêineres, réplicas ou ambientes secundários executando imagens vulneráveis.
O fornecedor confirmou a remediação das duas CVEs.

A atualização elimina as falhas conhecidas no componente corrigido, mas não desfaz uma eventual invasão anterior. Por isso, a investigação de comprometimento deve fazer parte do procedimento.

E quando não é possível atualizar o PHP?

Esta é uma das maiores preocupações em sistemas legados, especialmente quando a aplicação depende de bibliotecas antigas, frameworks descontinuados ou versões específicas do interpretador.

É importante diferenciar correção da vulnerabilidade de redução temporária da exposição.

A tabela apresenta a avaliação técnica das alternativas disponíveis:

Medida	Grau de solução	Limitação
Atualização oficial do PHP para release corrigida	Definitiva para as duas CVEs	Exige validação de compatibilidade
Backport de segurança validado pelo fornecedor	Definitiva para as CVEs cobertas	Não resolve o fim de suporte e outras falhas do legado
Migração para plataforma ou runtime corrigido	Definitiva para as duas CVEs	Pode exigir mudanças na aplicação
Isolamento completo do acesso público	Contenção forte	O software continua vulnerável
WAF com proteções específicas	Mitigação parcial	Não cobre necessariamente todos os caminhos de exploração
Ajustes preventivos na configuração PHP	Mitigação parcial	Reduzem vetores específicos, sem eliminar as falhas
Monitoramento e detecção	Complementar	Não impede necessariamente o ataque
Manter a versão vulnerável sem qualquer medida	Sem solução	Exposição permanece

Essas classificações são qualitativas. Não existe um percentual universal e confiável de proteção que permita afirmar, por exemplo, que um WAF resolve 90% do problema.

Alternativa 1: backport para versões antigas

Organizações que não podem migrar imediatamente devem verificar se o fornecedor da distribuição oferece correções específicas para as duas vulnerabilidades. Canonical, fornecedores de Extended Lifecycle Support e fabricantes de painéis de hospedagem disponibilizam ou podem disponibilizar pacotes corrigidos mantendo versões antigas. Além disso, o PHP Security Team publicou código-fonte com backports mínimos para as versões 7.4, 8.0 e 8.1.

Esses backports não significam que tais linhas voltaram a receber suporte regular. Seu objetivo é atender à emergência. Compilar uma versão personalizada também exige testes de regressão, validação de extensões e um processo confiável para manutenção futura. Esta alternativa pode corrigir integralmente as duas falhas, desde que os patches aplicados sejam completos e verificados.

Alternativa 2: isolamento temporário

Quando não existe um patch aplicável, a medida mais consistente é retirar o sistema vulnerável da exposição pública até que uma correção possa ser disponibilizada. Isso pode envolver restrições por rede privada, VPN, listas de endereços autorizados ou indisponibilidade temporária da aplicação. O isolamento precisa ser efetivo: não adianta restringir o acesso por um domínio e manter o servidor de origem publicamente acessível por outro caminho. O isolamento reduz a possibilidade de exploração externa, mas não corrige o problema no software. Se existirem outros acessos ao servidor, o risco correspondente permanece.

Alternativa 3: utilização de WAF

Um Web Application Firewall pode identificar e bloquear padrões associados às tentativas de exploração. A Cloudflare informou ter disponibilizado proteções específicas para PHP2Shell, inclusive em planos gratuitos, antes da divulgação pública completa das vulnerabilidades.

A empresa também apresentou mecanismos que analisam informações das requisições e respostas HTTP para melhorar a identificação de ataques, apesar disso, o WAF é uma camada adicional. Ele não modifica o interpretador PHP e pode deixar passar caminhos ainda não identificados, portanto, utilizar Cloudflare, Akamai, Imperva ou outra solução equivalente não substitui a instalação dos patches.

Alternativa 4: ajustes emergenciais no PHP

O próprio PHP Security Team publicou configurações que podem reduzir a exposição a determinados caminhos de exploração. Para a CVE-2026-109618, entre as medidas estão:

Configurar memory_limit=-1 administrativamente, impedindo que a aplicação restabeleça limites por requisição.
Utilizar limites conservadores para post_max_size, com referências de 8 MB quando não há uploads ou 32 MB quando necessários, conforme a orientação oficial e a necessidade da aplicação.
Restringir quantidade, profundidade e tamanho dos dados recebidos em requisições, especialmente formulários multipart.
Aplicar controles de memória por contêiner ou cgroup, acompanhados de monitoramento e limites operacionais adequados.

A utilização de memory_limit=-1 elimina um mecanismo previsível de falha de alocação explorado no ataque demonstrado, mas não impede outras falhas de memória. Além disso, remove o limite de memória do PHP por requisição e exige controles de recursos no ambiente para reduzir riscos operacionais. Para a CVE-2026-109619, algumas medidas são:

Definir session.upload_progress.enabled=0 quando essa funcionalidade não for necessária.
No PHP 8.5, configurar fatal_error_backtraces=0 para bloquear um dos caminhos demonstrados.
Remover configurações inválidas ou obsoletas que produzam diagnósticos durante a inicialização.
Corrigir erros fatais alcançáveis por usuários externos e situações que provoquem interrupções inesperadas.

Essas configurações precisam ser aplicadas no nível administrativo apropriado e acompanhadas da reinicialização dos workers. Nenhuma dessas medidas representa uma correção completa. Algumas também podem produzir efeitos colaterais sobre recursos, desempenho ou funcionalidades da aplicação. Empresas que dependem dessas alternativas devem registrar formalmente o risco residual e estabelecer um plano de atualização.

Como identificar sinais de exploração?

Como existem registros de tentativas de ataque anteriores à liberação das correções, limitar a análise à data da atualização é insuficiente. A recomendação é examinar os registros disponíveis pelo menos desde 17 de outubro de 2026, considerando que ataques anteriores ainda podem ter ocorrido sem detecção.

A investigação deve procurar:

Requisições HTTP incomuns, particularmente operações POST e uploads multipart com comportamento anormal.
Eventos relacionados a PHP_SESSION_UPLOAD_PROGRESS.
Erros recorrentes de alocação de memória e encerramento inesperado de processos PHP.
Execuções de comandos ou novos processos iniciados pelo usuário do servidor web.
Arquivos desconhecidos, alterações não autorizadas e tarefas agendadas suspeitas.
Conexões externas inesperadas originadas nos servidores de aplicação.
Acessos anormais a arquivos de configuração, credenciais e segredos.

Também devem ser correlacionados eventos de WAF, logs do servidor web, PHP-FPM, sistemas de detecção de ameaças e ferramentas de observabilidade.

A ausência desses indicadores não garante que o ambiente esteja seguro ou que nunca tenha sido comprometido.

Quando houver evidências de exploração bem-sucedida, a resposta deve incluir contenção, preservação das evidências, análise de integridade, avaliação de possível vazamento e rotação das credenciais potencialmente expostas.

Em incidentes relevantes, pode ser necessária a reconstrução do servidor a partir de uma origem confiável.

Como governos e empresas reagiram ao redor do mundo?

A gravidade das vulnerabilidades provocou uma resposta internacional coordenada, inclusive com a retirada preventiva de serviços digitais do ar.

Brasil

O CTIR Gov, órgão do Gabinete de Segurança Institucional da Presidência da República, publicou em 21 de outubro a Recomendação Técnica 19/2026. O documento orienta organizações a identificar sistemas PHP, aplicar as correções imediatamente e avaliar o isolamento temporário dos serviços expostos à internet quando a atualização não for viável.

União Europeia

A Comissão Europeia, a ENISA, o CERT-EU, a Europol EC3 e a rede europeia de equipes de resposta a incidentes publicaram uma comunicação conjunta recomendando ações imediatas. A orientação incluiu priorizar sistemas acessíveis pela internet e coordenar a atualização com fornecedores de infraestrutura.

Holanda

O governo holandês confirmou a retirada preventiva de diversos serviços públicos do ar em 21 de outubro. Entre os exemplos divulgados estavam Overheid.nl, MijnOverheid.nl e DigiD, serviços relacionados a informações e identidade digital do governo. O próprio NCSC holandês também retirou temporariamente seu site principal do ar. Essas ações foram preventivas e não constituem, por si, evidência de que os sistemas tenham sido invadidos.

Finlândia

Órgãos governamentais suspenderam temporariamente o acesso a determinados serviços digitais. A autoridade Traficom confirmou a indisponibilidade preventiva de seus serviços My e-Services e Seutuplus.f i. O centro nacional de segurança cibernética finlandês também divulgou orientação emergencial sobre as vulnerabilidades.

Reino Unido

O National Cyber Security Centre recomendou atualizações imediatas e a possibilidade de retirar sistemas vulneráveis do ar. O NHS England publicou um alerta específico, destacando o risco de execução remota de código e exposição de dados da memória dos servidores.

Canadá, Austrália e Nova Zelândia

As respectivas autoridades de segurança cibernética emitiram alertas sobre as vulnerabilidades. A Nova Zelândia também passou a alertar sobre relatos de exploração ativa e a necessidade de investigar eventuais comprometimentos anteriores à correção.

A reação das empresas de tecnologia

A mobilização não se limitou aos governos.

Hostinger comunicou aos clientes de VPS a necessidade de verificar a versão instalada e aplicar os patches, com orientações específicas para distribuições Linux e ambientes CloudPanel. Em seus ambientes de hospedagem gerenciada, a empresa informou ter validado proteções adicionais e planejado a disponibilização das versões corrigidas.

DigitalOcean alertou clientes sobre instalações em Droplets, Kubernetes, App Platform, contêineres e imagens de aplicações disponibilizadas em seu Marketplace. O comunicado destacou a necessidade de corrigir instalações já existentes.

Cloudflare implementou proteções específicas em seu WAF e relatou tentativas de exploração contra clientes, incluindo modificações nos padrões de ataque.

AWS publicou orientações para seus clientes e apresentou evidências de exploração anteriores à divulgação pública. A empresa também reforçou a necessidade de investigar sinais de comprometimento, e não apenas instalar atualizações.

Google Cloud orientou clientes a atualizar ambientes PHP e reconstruir ou republicar aplicações em plataformas gerenciadas e contêineres.

Canonical disponibilizou atualizações para versões suportadas do Ubuntu, inclusive por meio de backports para pacotes PHP antigos.

cPanel publicou correções para seus componentes de hospedagem e pacotes EasyApache.

Outros fabricantes, incluindo Cisco, Sophos e fornecedores de soluções de infraestrutura, iniciaram avaliações de seus produtos para determinar a existência de componentes afetados.

A principal conclusão dessas iniciativas é que a segurança depende de responsabilidades compartilhadas. O provedor pode proteger a infraestrutura subjacente, mas aplicações, contêineres e instalações PHP administradas diretamente pelos clientes continuam exigindo acompanhamento específico.

O que as organizações devem fazer agora?

A Inova e-Business recomenda tratar o PHP2Shell como um incidente de exposição crítica, com prioridade para serviços externos e ambientes que armazenam ou processam informações sensíveis. O plano de resposta deve seguir cinco etapas:

1. Inventariar: identificar todas as instalações PHP, suas versões, provedores, aplicações e responsáveis técnicos.

2. Classificar: priorizar ambientes expostos à internet, serviços críticos, sistemas com dados sensíveis e instalações sem manutenção regular.

3. Corrigir ou conter: instalar os patches oficiais ou backports validados. Onde isso não for possível, restringir efetivamente a exposição e adotar proteções temporárias.

4. Investigar: analisar possíveis tentativas de exploração e sinais de comprometimento anteriores e posteriores à atualização.

5. Validar e prevenir: confirmar a correção no runtime efetivamente utilizado, testar as aplicações, revisar a gestão de dependências e estabelecer um processo contínuo de atualização.

O maior risco não está apenas na falha, mas na capacidade de resposta

O PHP2Shell demonstra como problemas antigos de gerenciamento de memória podem permanecer durante anos em componentes amplamente utilizados, até que novas técnicas de pesquisa tornem sua exploração viável. A participação da inteligência artificial na descoberta dessas vulnerabilidades é um aspecto importante. A mesma tecnologia que ajuda pesquisadores a identificar e corrigir problemas também reduz o esforço necessário para desenvolver e adaptar ataques. Isso exige que empresas revisem a forma como administram sistemas legados, dependências e atualizações emergenciais.

Para estas duas vulnerabilidades, o caminho definitivo é utilizar um interpretador PHP com correção validada. WAFs, configurações preventivas, monitoramento e isolamento são recursos importantes, mas não devem ser confundidos com a eliminação da falha. Mais do que atualizar uma linguagem de programação, o episódio reforça uma necessidade estrutural: conhecer os componentes de cada aplicação, acompanhar seu ciclo de suporte e manter capacidade de resposta rápida diante de ameaças críticas.

A Inova e-Business atua na engenharia, modernização, sustentação e segurança de aplicações, apoiando empresas na evolução de ambientes legados e na construção de sistemas mais resilientes. Em um cenário de ameaças aceleradas pela inteligência artificial, velocidade de resposta, engenharia e governança tecnológica precisam caminhar juntas.