PHP2Shell: o que se sabe sobre as falhas críticas do PHP e como proteger seus servidores

Na quarta-feira, 21 de outubro de 2026, o projeto PHP publicou uma atualização de emergência para corrigir duas vulnerabilidades críticas que, juntas, ficaram conhecidas como PHP2Shell. As falhas permitem que um atacante, sem login e sem senha, execute código no servidor e leia trechos da memória que podem conter senhas, tokens de acesso e chaves de API.

O alcance é enorme. O PHP é a linguagem por trás de cerca de 70% dos sites cuja tecnologia de servidor é conhecida, segundo a W3Techs, incluindo plataformas como WordPress, Drupal, Joomla e Magento. E, diferentemente de uma falha em um plugin ou em um sistema específico, o problema está no próprio PHP: atualizar o CMS, o tema ou os plugins não resolve.

Neste post, reunimos o que se sabe até agora, explicamos as falhas em linguagem acessível e listamos o que equipes de tecnologia e responsáveis por sites devem fazer.

O que é o PHP2Shell

PHP2Shell é o nome dado ao conjunto de duas vulnerabilidades registradas como CVE-2026-109618 e CVE-2026-109619. As duas receberam nota 9,2 de 10 na escala de gravidade CVSS (versão 4.0), o que as coloca na faixa crítica. O nome faz referência ao objetivo de quem explora a falha: obter um shell, ou seja, a capacidade de executar comandos no servidor.

Segundo a PHP Foundation, as duas falhas estão em partes do PHP que praticamente toda requisição usa: o gerenciamento de memória e o tratamento de erros. É isso que torna o problema tão abrangente.

CVE-2026-109618: quando a memória acaba na hora errada

Toda vez que alguém acessa uma página feita em PHP, o servidor monta uma série de estruturas internas para processar aquela requisição. A primeira falha acontece quando a memória disponível se esgota no meio dessa montagem. O PHP interrompe o processamento, mas a etapa de limpeza que vem depois trata os dados ainda incompletos como se fossem válidos.

Um atacante consegue provocar essa falta de memória de propósito, por exemplo com requisições de envio de formulários e arquivos (multipart) montadas para consumir memória sem ultrapassar os limites aparentes de configuração. Com isso, ele corrompe a memória do processo e pode chegar à execução de código.

CVE-2026-109619: o "estado fantasma" entre requisições

Servidores PHP costumam reaproveitar o mesmo processo (worker) para atender várias requisições seguidas. A segunda falha acontece quando uma requisição termina de forma abrupta, por um erro fatal ou por falta de memória, e deixa para trás referências a uma área de memória que já foi liberada. A próxima requisição atendida pelo mesmo processo pode usar essas referências antes que o PHP as reinicie.

Esse tipo de erro, conhecido como use-after-free (uso de memória após a liberação), permite tanto ler dados que pertenciam a outra requisição quanto executar código. Um dos caminhos confirmados passa pelo recurso de acompanhamento do progresso de upload em sessões (session.upload_progress), que vem ativado por padrão no PHP.

Qual é o impacto prático

Se explorada com sucesso, a vulnerabilidade permite:

Executar código no servidor com as permissões do usuário que roda o servidor web, sem nenhuma autenticação.
Ler a memória do processo PHP, que pode conter senhas de banco de dados, tokens de autenticação e chaves de API.
A partir daí, instalar acessos ocultos, alterar o site, roubar dados ou usar o servidor como ponto de partida para atacar outros sistemas da rede.

A exploração não é trivial: depende da versão, das extensões instaladas, da configuração do servidor e do comportamento da aplicação. Mas os pesquisadores já demonstraram ataques funcionais, e a tendência é que as técnicas fiquem mais acessíveis com o tempo.

Quem está em risco

De acordo com o comunicado oficial do PHP, toda instalação do PHP que atende requisições web está em risco, incluindo:

Apache com mod_php: o cenário de maior risco. Há exploração demonstrada em que uma requisição sem autenticação dispara o ataque antes mesmo de o código da aplicação ser executado.
PHP-FPM: o modelo mais comum em servidores com Nginx. A exploração foi validada em condições específicas da aplicação.
php-cgi, FrankenPHP e LiteSpeed.

O código vulnerável existe desde o PHP 5.4, lançado em 2012. Na prática, isso inclui praticamente todas as versões em uso hoje.

A empresa de segurança Calif, uma das responsáveis pela descoberta, afirma ter confirmado execução remota de código sem autenticação em versões específicas de WordPress, Drupal, Joomla e Magento. Isso não significa que essas plataformas tenham uma falha própria: elas são afetadas porque rodam sobre o PHP vulnerável.

Versões corrigidas

PHP 8.5: atualizar para a 8.5.12.
PHP 8.4: atualizar para a 8.4.27.
PHP 8.3: atualizar para a 8.3.36.
PHP 8.2: atualizar para a 8.2.35. Este ramo tem suporte só até 31/12/2026.
PHP 7.4, 8.0 e 8.1: não há nova versão oficial, apenas uma correção mínima publicada no código-fonte.
PHP 5.4 a 7.3: não há correção. São versões fora de suporte.

Algumas observações importantes:

As distribuições Linux e os fornecedores de suporte estendido receberam as correções com antecedência. Em pacotes de distribuição, a correção pode chegar mantendo o número de versão antigo. Por isso, o certo é conferir o boletim de segurança do fornecedor (Ubuntu, Debian, Red Hat e outros), e não apenas o número da versão.
Para PHP 7.4, 8.0 e 8.1, o time do PHP publicou correções mínimas no código-fonte, voltadas a quem compila o PHP por conta própria. Ainda assim, a recomendação é migrar para uma versão com suporte.
O PHP 8.2 deixa de receber correções de segurança em 31 de dezembro de 2026. Quem usa esse ramo deve planejar a migração desde já.

Linha do tempo

Agosto de 2026: pesquisadores da Calif e da Wiz, trabalhando de forma independente e com apoio de modelos de inteligência artificial, encontram as falhas e as reportam ao time de segurança do PHP.
17 de outubro: a Amazon registra a primeira tentativa de exploração em seus servidores-isca (honeypots), quatro dias antes da divulgação.
20 de outubro: os identificadores das falhas vazam na internet, junto com um vídeo de demonstração publicado por engano. O PHP publica um aviso antecipado, e o CERT-EU, centro de resposta a incidentes da União Europeia, emite alerta.
21 de outubro, madrugada: a Cloudflare ativa regras de firewall de aplicação (WAF) contra as formas de ataque conhecidas, inclusive para clientes do plano gratuito.
21 de outubro, 14h UTC (11h de Brasília): o PHP lança as versões corrigidas, antecipando em um dia a data combinada por causa do vazamento.
22 de outubro: o CTIR Gov, centro de prevenção e resposta a incidentes cibernéticos do governo federal, orienta os órgãos da administração pública a atualizar o PHP imediatamente.

A falha já está sendo explorada?

Sim. Diversas empresas de segurança relatam tentativas de ataque:

A Amazon afirma que o PHP2Shell já é amplamente explorado e recomenda investigar os sistemas expostos a partir de 17 de outubro.
A Hadrian relatou exploração em larga escala horas antes da correção, a maior parte pelo caminho do progresso de upload em sessões.
Cloudflare, Patchstack e watchTowr também registraram tentativas.

Segundo uma estimativa citada pela Tenable, mais de 1,3 milhão de servidores acessíveis pela internet podem estar vulneráveis.

Circulam na internet códigos que prometem explorar as falhas. A PHP Foundation informou que, no momento do lançamento das correções, nenhum dos que analisou funcionava de fato. Mas atenção: códigos de exploração não verificados podem conter vírus e não devem ser executados em nenhum ambiente da empresa.

O papel da inteligência artificial na descoberta

O PHP2Shell chama atenção também pela forma como foi encontrado. O PHP creditou a descoberta a pesquisadores da Calif, da Wiz e da OpenAI, entre outros, e tanto a Calif quanto a Wiz afirmam ter usado modelos de inteligência artificial para analisar o código do PHP.

A Wiz classificou as falhas como "entre as vulnerabilidades mais graves já descobertas no PHP e, possivelmente, na história do software". A OpenAI, por sua vez, afirmou que o PHP2Shell está entre várias vulnerabilidades relevantes que encontrou e que espera um aumento expressivo de descobertas semelhantes nos próximos meses.

Isso tem dois lados. A IA ajuda os defensores a encontrar falhas antigas, que passaram anos despercebidas em um código usado por milhões de sistemas. Ao mesmo tempo, a mesma tecnologia acelera o trabalho de quem quer atacar: entre o vazamento das primeiras informações e as primeiras tentativas de exploração em massa, passaram-se poucas horas.

A janela entre a divulgação de uma falha e os ataques está cada vez menor, e a capacidade de atualizar sistemas rapidamente deixou de ser um diferencial para se tornar uma necessidade. O tema conversa com outra discussão que trouxemos recentemente aqui no blog: quem fiscaliza a inteligência artificial.

O que fazer agora

1. Descubra onde o PHP está rodando

Liste todos os servidores, sites, sistemas internos e serviços que usam PHP, inclusive os esquecidos: sites antigos de campanhas, ambientes de homologação expostos na internet, painéis administrativos e intranets.

Em hospedagem compartilhada ou gerenciada, a atualização do PHP normalmente é responsabilidade do provedor. Entre em contato e peça a confirmação de que a correção foi aplicada.

Para conferir a versão em um servidor:

php -v

A versão exibida no terminal pode ser diferente da usada pelo servidor web. Confira também os pacotes instalados, que incluem o PHP-FPM e o módulo do Apache:

# Ubuntu e Debian
dpkg -l | grep php

# Red Hat, Rocky Linux, AlmaLinux e similares
rpm -qa | grep php

2. Atualize e reinicie

Atualize para o PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou para o pacote corrigido da sua distribuição. Depois, reinicie todos os processos do PHP (PHP-FPM, Apache ou equivalente). Sem o reinício, os processos antigos continuam rodando com o código vulnerável na memória.

Se você usa o repositório comunitário rpms.remirepo.net, o próprio PHP recomenda migrar para os pacotes da distribuição ou compilar a partir do código-fonte, porque o repositório não teria a atualização disponível no dia do lançamento.

3. Se não puder atualizar agora, reduza a exposição

O PHP é direto: não existem mitigações completas, e atualizar é a única escolha segura. As medidas abaixo reduzem caminhos de ataque conhecidos, mas não tornam uma instalação segura. Use-as apenas como ponte até a atualização.

; Bloqueia o caminho confirmado pelo progresso de upload em sessões (CVE-2026-109619)
session.upload_progress.enabled = 0

; Somente no PHP 8.5: bloqueia o caminho pelo backtrace de erro fatal (CVE-2026-109619)
fatal_error_backtraces = 0

; Reduz o tamanho máximo das requisições (CVE-2026-109618)
; 8M para aplicações sem upload de arquivos, 32M se houver upload
post_max_size = 8M

Outros cuidados recomendados pelo PHP e pelos órgãos de resposta a incidentes:

Aplique as configurações no php.ini, no pool do PHP-FPM ou na configuração do servidor web. Não use ini_set() nem o arquivo .user.ini, que entram em ação tarde demais.
Para a CVE-2026-109618, o PHP sugere memory_limit=-1, aplicado de forma que a aplicação não consiga sobrescrever (por exemplo, com php_admin_value). A medida aumenta o risco de esgotamento de recursos, então combine com limites de memória por contêiner ou cgroup.
Limite, no servidor web ou no proxy, o tamanho das requisições e o número de campos, cabeçalhos e partes de upload. Bloqueie requisições multipart onde a aplicação não recebe arquivos.
No PHP-FPM, pm.max_requests = 1 faz cada processo atender uma única requisição, o que elimina o reaproveitamento de estado, ao custo de desempenho.
Reinicie todos os processos depois de qualquer mudança.
Coloque as aplicações atrás de um WAF com regras para o PHP2Shell ou restrinja o acesso pela internet até a correção, como recomendam o CTIR Gov e o CERT-EU.

4. Verifique se houve invasão

Como houve tentativas de ataque antes mesmo da correção, atualizar não basta para quem ficou exposto. Vale:

Revisar os logs de acesso a partir de 17 de outubro, buscando volumes incomuns de requisições multipart, erros de falta de memória e reinícios inesperados de processos.
Procurar arquivos PHP novos ou alterados em diretórios públicos, um sinal típico de webshells (arquivos que dão ao atacante controle remoto do servidor).
Trocar senhas, tokens e chaves de API que estavam acessíveis ao PHP em servidores expostos, já que a falha permite ler a memória do processo.

5. Planeje a saída de versões sem suporte

Versões fora de suporte não recebem correções e continuarão vulneráveis a esta e às próximas falhas. Se a sua aplicação ainda roda em PHP 8.1 ou anterior, o PHP2Shell é o argumento que faltava para priorizar a migração. E o PHP 8.2 entra na mesma situação em 31 de dezembro de 2026.

Lições para quem desenvolve e mantém sistemas

Episódios como o PHP2Shell, assim como o Log4Shell em 2021, reforçam alguns princípios que valem para qualquer tecnologia:

Inventário é a base da segurança. Não dá para proteger o que não se sabe que existe.
Atualização precisa de processo. Rotina, responsáveis e janelas de manutenção definidas fazem a diferença entre corrigir em horas ou em semanas.
Defesa em camadas. WAF, segmentação de rede, privilégios mínimos para o usuário do servidor web e segredos guardados fora do código reduzem o estrago quando uma falha aparece.
Versões sem suporte são dívida de segurança. Cada mês de adiamento da migração aumenta o risco.

Para se aprofundar, leia também nossos posts sobre desenvolvimento seguro de software, segurança da informação em plataformas web e hospedagem segura na AWS.

Se a sua empresa precisa de apoio para mapear aplicações em PHP, planejar a atualização ou revisar a segurança dos seus sistemas, fale com a gente.

Fontes:

PHP: Security advisory: critical remote code execution vulnerabilities, update now, 21 de outubro de 2026.
PHP no GitHub: boletins técnicos GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp.
Tenable: php2shell (CVE-2026-109618, CVE-2026-109619): frequently asked questions.
SecurityWeek: PHP2Shell patches land as first exploitation attempts hit sensors.
Qualys: Two critical PHP flaws could hand attackers your web servers.
Convergência Digital: Governo manda fazer atualização urgente e até tirar do ar sites por conta das vulnerabilidades no PHP, 22 de outubro de 2026.

PHP2Shell: o que se sabe sobre as falhas críticas do PHP e como proteger seus servidores.