PHP2Shell: a vulnerabilidade crítica no PHP que expôs milhões de sites e como protegemos os nossos clientes no mesmo dia

Mauricio Shinmi

Escrito por Mauricio Shinmi

22 | 10 | 2026
Tempo de leitura 7 min de leitura

Nesta semana, o PHP, a linguagem que roda cerca de 70% dos sites do mundo (incluindo todo site em WordPress), recebeu uma das correções de segurança mais urgentes da sua história. Duas falhas críticas, apelidadas de PHP2Shell (CVE-2026-109618 e CVE-2026-109619), permitem que um atacante execute código no servidor sem precisar de login. Para piorar, os identificadores das falhas vazaram na internet um dia antes da correção sair.

Neste artigo explicamos o que aconteceu, quem divulgou, quem é afetado, quais versões resolvem o problema e como a Oxigenweb protegeu os sites dos clientes no mesmo dia em que a correção foi publicada.

Resumo rápido

O que é: duas falhas no núcleo do PHP que permitem execução remota de código sem autenticação.

Gravidade: CVSS 9,2 (crítica) nas duas.

Quem é afetado: PHP da versão 5.4 até a 8.5.11, em qualquer servidor que atende páginas web.

Correção: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, lançadas em 21 de outubro de 2026.

Sem correção oficial: PHP 8.1 e versões mais antigas.

O que é o PHP2Shell

PHP2Shell é o nome dado ao par de vulnerabilidades corrigido pelo time de segurança do PHP em 21 de outubro de 2026. As duas exploram a forma como o PHP lida com a memória entre uma requisição e outra, ou seja, estão no motor da linguagem, e não em um plugin ou tema.

Falha O que acontece Impacto
CVE-2026-109618 Quando a requisição estoura o limite de memória no momento errado, o PHP guarda dados pela metade e depois os trata como válidos, corrompendo a memória. Execução remota de código. No Apache com mod_php, um único acesso sem login dispara o ataque antes de o site carregar.
CVE-2026-109619 Um erro fatal pode deixar o PHP apontando para memória de uma requisição anterior, que já foi liberada. O próximo acesso no mesmo processo usa esses dados velhos. Execução remota de código e vazamento de memória, que pode expor senhas, tokens e chaves de API.

Na prática, “execução remota de código” significa que o atacante consegue rodar comandos no servidor com as permissões do site: instalar um arquivo malicioso, roubar dados do banco, redirecionar visitantes ou usar o servidor para atacar outros. É o pior tipo de falha que uma aplicação web pode ter.

Quem descobriu e quem divulgou

A história começou bem antes desta semana. Segundo a PHP Foundation, os primeiros sinais do problema de memória apareceram em 2024, durante uma auditoria externa. Em agosto de 2026, a empresa de segurança Calif e a OpenAI relataram de forma independente a causa da falha, e a Wiz enviou seu relatório em 24 de agosto. O time do PHP preparou a correção e combinou uma data de divulgação coordenada com distribuições Linux e provedores, como manda o protocolo.

O plano era publicar tudo na quinta, 22 de outubro. Não deu certo:

Quando (horário de Brasília) O que aconteceu
Ter, 20/10, por volta de 12h Os números das CVEs vazam em um post no Hacker News, com nota de gravidade errada (10,0) e data errada. O post é apagado, mas os prints se espalham.
Ter, 20/10, 16h30 O PHP publica um aviso prévio e antecipa a correção em um dia.
Ter, 20/10, à noite Um vídeo com a prova de conceito do ataque é publicado por engano e circula nas redes sociais.
Qua, 21/10, por volta das 11h Saem as versões corrigidas: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. A Cloudflare libera regras de firewall para todos os planos, inclusive o gratuito.
Qua, 21/10, fim da tarde Calif e Wiz publicam os detalhes técnicos. A Cloudflare relata tráfego de ataque mirando as falhas.

Ou seja: entre o vazamento e o início dos ataques passaram poucas horas. Quem dependia de alguém “lembrar de atualizar um dia desses” ficou exposto.

Quem é afetado

De acordo com o levantamento citado pela Infosecurity Magazine, o PHP é usado por cerca de 69,7% dos sites cuja linguagem de servidor é conhecida. Isso inclui WordPress, WooCommerce, Drupal, Joomla, Magento e boa parte dos sistemas web sob medida.

O Google Cloud informa que todas as versões do PHP 5.4 até a 8.5.11 são vulneráveis. Segundo o próprio PHP, qualquer instalação que atende páginas web está em risco: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O caso mais grave é o mod_php, em que o ataque acontece antes de qualquer código do site rodar.

Versão do PHP no seu servidor Situação
8.5.x Atualizar para 8.5.12
8.4.x Atualizar para 8.4.27
8.3.x Atualizar para 8.3.36
8.2.x Atualizar para 8.2.35
8.1, 8.0, 7.x ou mais antigo Sem correção oficial. Há apenas remendos mínimos de código-fonte para 7.4, 8.0 e 8.1. O caminho seguro é migrar o site para o PHP 8.2 ou mais novo.

Atenção: distribuições Linux e painéis de hospedagem às vezes aplicam a correção mantendo o número de versão antigo. Por isso, a confirmação deve ser feita com o provedor ou com quem cuida do servidor, e não só olhando o número da versão.

Por que essa falha é diferente das outras

A maioria das brechas em sites WordPress está em plugins: o próprio relatório da Patchstack aponta que 91% das vulnerabilidades do ecossistema estão neles. O PHP2Shell é outra categoria. A falha está na base de tudo, então não importa se o site tem poucos plugins, se o tema é bom ou se a senha do admin é forte.

Outro ponto chama a atenção: a inteligência artificial. A Wiz afirma que as falhas existiam havia décadas, mas que modelos de IA de ponta reduziram muito o esforço para transformá-las em um ataque funcional. O Google também relata que o seu modelo Gemini contribuiu para encontrar a falha, desenvolver a prova de conceito e validar a correção. A mesma tecnologia que ajuda a defender também acelera quem ataca, e o tempo entre a divulgação de uma falha e os primeiros ataques fica cada vez menor.

Como a Oxigenweb respondeu: tudo resolvido no mesmo dia

Na Oxigenweb, segurança de servidor não espera a próxima janela de manutenção. Assim que as versões corrigidas foram publicadas, em 21 de outubro, o nosso time:

1

Aplicou a mitigação recomendada pelo PHP no php.ini, desativando o recurso de progresso de upload de sessão e ajustando os limites usados pelo ataque, para fechar a porta enquanto a atualização era feita.

2

Atualizou o PHP nos servidores que administramos para as versões corrigidas.

3

Confirmou a proteção da Cloudflare, com as regras de firewall (WAF) contra o PHP2Shell ativas nos sites que estão atrás dela.

4

Fez uma varredura nos sites dos clientes, procurando webshells, arquivos PHP novos ou alterados e acessos suspeitos nos logs.

Teve um fator que pesou muito a nosso favor: em setembro, fizemos um mutirão para migrar os sites WordPress mais antigos dos clientes para o PHP 8.2, corrigindo temas e plugins que não rodavam nas versões novas. Foi um trabalho grande, mas é exatamente por isso que os nossos clientes estavam em uma versão que recebeu correção oficial. Quem ainda roda PHP 7.4 ou 8.1, comum em sites antigos e hospedagens baratas, ficou sem atualização oficial nesta semana.

O que fazer agora se o seu site roda em PHP

1

Descubra a versão do PHP. No WordPress, ela aparece em Ferramentas > Saúde do site > Informação > Servidor. No cPanel, em “Selecionar versão do PHP” ou “MultiPHP Manager”.

2

Peça a atualização ao seu provedor e confirme por escrito que a correção do PHP2Shell (CVE-2026-109618 e CVE-2026-109619) foi aplicada.

3

Se estiver no PHP 8.1 ou anterior, planeje a migração para o 8.2 ou mais novo com urgência. Antes, teste o site: temas e plugins antigos costumam quebrar.

4

Ative um firewall de aplicação (WAF). As regras da Cloudflare contra o PHP2Shell estão disponíveis até no plano gratuito.

5

Procure sinais de invasão: arquivos PHP novos em pastas como wp-content/uploads, usuários administradores que você não criou, redirecionamentos estranhos e alertas do Google. Se encontrar algo, siga o nosso guia de site WordPress invadido: o que fazer.

6

Troque senhas e chaves do banco de dados e de APIs se houver qualquer suspeita, já que uma das falhas pode vazar dados da memória do servidor.

A lição: site bem feito e manutenção em dia

O PHP2Shell deixa claro algo que repetimos há anos: site não é um projeto que termina no dia em que vai para o ar. Ele roda em cima de uma linguagem, de um servidor e de dezenas de componentes que recebem correções o tempo todo. Dois fatores decidem se uma falha como essa vira só uma notícia ou um site fora do ar:

  • Um site bem construído, com código atualizado e compatível com as versões novas do PHP. Sites feitos com gambiarras ou temas abandonados ficam presos em versões antigas, e foram justamente essas que ficaram sem correção.
  • Manutenção contínua, com alguém monitorando os alertas de segurança e com autonomia para agir no mesmo dia, e não semanas depois.

Se você não sabe em que versão do PHP o seu site está, ou não tem certeza de que alguém atualizou o servidor nesta semana, esse é o sinal. Conheça o nosso serviço de manutenção de sites WordPress e veja também como reforçar a proteção em segurança WordPress além do básico.

Seu site está protegido contra o PHP2Shell?

Fazemos um diagnóstico da versão do PHP, do servidor e da segurança do seu site WordPress e dizemos exatamente o que precisa ser feito.

Quero um diagnóstico

Perguntas frequentes sobre o PHP2Shell

O que é o PHP2Shell?

É o nome dado a duas vulnerabilidades críticas no núcleo do PHP, CVE-2026-109618 e CVE-2026-109619, corrigidas em 21 de outubro de 2026. Elas permitem que um atacante execute código no servidor sem precisar de login.

Meu site WordPress está vulnerável?

Se o servidor roda PHP entre as versões 5.4 e 8.5.11 sem a correção aplicada, sim. O WordPress em si não tem a falha, mas roda em cima do PHP. Confirme com o seu provedor se o PHP foi atualizado para 8.2.35, 8.3.36, 8.4.27 ou 8.5.12.

Atualizar o WordPress resolve?

Não. A falha está no PHP, no servidor. É preciso atualizar o PHP ou pedir ao provedor de hospedagem que faça isso. Manter o WordPress e os plugins atualizados continua importante, mas não fecha essa brecha.

E se o meu site roda PHP 7.4 ou 8.1?

Essas versões estão fora do suporte e não receberam correção oficial. O caminho seguro é migrar o site para o PHP 8.2 ou mais novo. Enquanto isso, isole o site atrás de um firewall de aplicação e aplique as mitigações recomendadas pelo PHP.

Já existem ataques acontecendo?

Sim. A Cloudflare relatou tráfego de ataque mirando as falhas logo após a divulgação, e um vídeo com a prova de conceito circulou nas redes. Por isso a recomendação de todos os órgãos de segurança é atualizar imediatamente.

Como a Oxigenweb protegeu os sites dos clientes?

No mesmo dia da correção, aplicamos a mitigação no php.ini, atualizamos o PHP nos servidores, confirmamos as regras de firewall da Cloudflare e fizemos uma varredura nos sites em busca de sinais de invasão.

Fontes

Sobre o autor

Mauricio Shinmi

Mauricio Shinmi

Com 17 anos de experiência na área de marketing digital e SEO, está na lista dos 50 maiores especialistas de Wordpress do Brasil, faz parte do conselho de tecnologia e inovação de Presidente Prudente - SP, certificado 8'Ps, UX, Google Sales e sócio fundador da Oxigenweb.

Deixe seu comentário

5 × 4 =