Se o seu site ficou mais lento, deu erro ou você recebeu um e-mail da hospedagem falando em “atualização emergencial” nesta semana, o motivo tem nome: PHP2Shell.

Na quarta-feira, 21 de outubro de 2026, a equipe do PHP lançou uma correção para duas falhas graves que permitem a um invasor executar comandos no servidor sem precisar de login nem senha. Tribunais federais aqui no Brasil e sites de governo na Europa chegaram a ficar fora do ar por precaução.

Se você não é técnico e está meio perdido no meio de tanta notícia, tudo bem. A falha está numa camada do site que quase ninguém olha no dia a dia, e a maior parte das matérias foi escrita para quem cuida de servidor. Aqui a ideia é o contrário: ao terminar a leitura, você vai saber se o seu site corre risco, como conferir isso em poucos minutos e o que pedir para quem cuida da sua hospedagem.

Resposta rápida: o PHP2Shell são duas vulnerabilidades críticas (CVE-2026-109618 e CVE-2026-109619, nota 9.2 de 10) que afetam praticamente toda instalação de PHP que atende páginas na internet. A correção está nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Se o seu site roda em PHP e o servidor ainda não foi atualizado, ele está exposto, mesmo que o WordPress e os plugins estejam em dia.

Neste post:

O que é o PHP2Shell?

PHP é a linguagem de programação que roda “por trás” de boa parte dos sites. WordPress, Joomla, Drupal, Magento e muitos sistemas sob medida são feitos em PHP. Segundo a W3Techs, ele está em cerca de 69% dos sites cuja linguagem de servidor é conhecida.

PHP2Shell é o apelido dado a duas falhas encontradas no próprio motor do PHP. Plugin e tema não têm culpa aqui. Em linguagem simples:

  • CVE-2026-109618: quando o PHP fica sem memória no meio de uma requisição, ele pode deixar dados “pela metade”. Na hora de limpar a requisição, trata esses dados quebrados como se fossem válidos.
  • CVE-2026-109619: informações de uma visita podem sobrar na memória depois de apagadas e ser reaproveitadas pela próxima visita atendida pelo mesmo processo.

Parece detalhe técnico, mas o resultado é sério: com uma requisição montada do jeito certo, um invasor consegue rodar código no servidor.

As falhas foram reportadas à equipe do PHP em agosto por pesquisadores da Calif e da OpenAI. Depois, a Wiz encontrou outras formas de explorar o mesmo problema. Calif e Wiz contaram que usaram modelos de inteligência artificial durante a pesquisa, o que acelerou bastante a descoberta.

Ficha técnica

  • Nome: PHP2Shell
  • CVEs: CVE-2026-109618 e CVE-2026-109619
  • Gravidade: crítica, CVSS v4.0 9.2
  • Precisa de login? Não. O ataque pode vir de qualquer visitante.
  • Impacto: execução remota de código (RCE) e vazamento de dados da memória
  • Versões corrigidas: 8.5.12, 8.4.27, 8.3.36 e 8.2.35
  • Data da correção: 21/10/2026
  • Ação necessária: atualizar o PHP do servidor

O que um invasor consegue fazer

Executar código no servidor é a chave da casa. Com ela, o invasor pode:

  • alterar páginas do site ou colocar links e conteúdos maliciosos;
  • copiar o banco de dados, com cadastros de clientes, pedidos e formulários;
  • instalar uma “porta dos fundos” para voltar depois, mesmo após a correção;
  • usar o seu servidor para atacar outros sites ou enviar spam.

A Wiz também mostrou que uma das falhas pode vazar pedaços da memória do servidor, onde às vezes ficam senhas, tokens e chaves de API.

E isso não ficou só no papel. A Cloudflare informou que as tentativas de ataque saltaram de milhares para milhões em poucas horas depois do anúncio. A Amazon registrou uma tentativa em 17 de outubro, quatro dias antes da correção sair. Foi por isso que o TRF-1, o TRF-4, o TRF-6 e a Anatel suspenderam o acesso externo a sistemas, e órgãos na França e na Holanda tiraram sites do ar enquanto atualizavam. O governo federal informou que o Gov.br não foi afetado.

Quais versões do PHP foram afetadas?

Praticamente todas as que estão em uso. Os pesquisadores encontraram o código com problema em versões desde o PHP 5.4.

Versão do PHP Situação O que fazer
8.5 Corrigida na 8.5.12 Atualizar para 8.5.12 ou superior
8.4 Corrigida na 8.4.27 Atualizar para 8.4.27 ou superior
8.3 Corrigida na 8.3.36 Atualizar para 8.3.36 ou superior
8.2 Corrigida na 8.2.35 Atualizar, e planejar a migração: o suporte termina em 31/12/2026
7.4, 8.0 e 8.1 Sem versão oficial; só há correção em código-fonte Migrar para 8.3 ou 8.4, ou usar o pacote corrigido da sua distribuição/hospedagem
7.3 ou mais antigas Sem correção Migrar o quanto antes

Um ponto importante: em servidores Linux, a correção pode chegar com outro número de versão, porque distribuições como Debian, Ubuntu e Red Hat aplicam o patch nos próprios pacotes. Nesse caso, quem confirma é a hospedagem ou o fornecedor do sistema.

Quais servidores foram afetados?

Segundo o comunicado oficial do PHP, toda instalação que atende requisições da web está em risco. Isso inclui as formas mais comuns de rodar PHP:

  • Apache com mod_php: o caso mais grave. Os pesquisadores demonstraram um ataque que funciona antes mesmo de o código do site rodar.
  • PHP-FPM (o mais usado com Nginx e em muitas hospedagens);
  • php-cgi;
  • LiteSpeed (LSAPI), comum em hospedagens compartilhadas;
  • FrankenPHP.

Não importa se o servidor é Apache ou Nginx, compartilhado ou dedicado. Se tem PHP atendendo visitantes, precisa da atualização.

Meu site em WordPress está em risco?

Sim, se o PHP do servidor não foi atualizado. Esse é o ponto que mais confunde, então vale repetir: atualizar o WordPress, os plugins e os temas não resolve o PHP2Shell. A falha está na camada abaixo do WordPress.

O próprio WordPress.org avisou que não vai lançar atualização para isso, porque o problema não é dele. A Wordfence lembrou que a atualização automática do WordPress não instala o novo PHP e que plugins de segurança não bloqueiam a falha.

Ou seja, o seu painel pode estar todo verde e o site, mesmo assim, vulnerável.

Como saber se meu site foi afetado

São duas perguntas diferentes: “meu site está vulnerável?” e “meu site já foi invadido?”.

1. Descubra a versão do PHP (5 minutos)

No WordPress, entre em Ferramentas > Saúde do site > Informações e abra a aba Servidor. A linha “Versão do PHP” mostra o número. Em algumas traduções, o menu aparece como “Diagnóstico”.

Fora do WordPress, a versão costuma aparecer no painel da hospedagem (cPanel, Plesk ou similar). Quem tem acesso ao terminal pode rodar php -v, lembrando que a versão da linha de comando pode ser diferente da que atende o site.

Compare com a tabela acima. Se o número for menor que o da versão corrigida, o site está exposto. Se a hospedagem usa pacote da distribuição, pergunte diretamente se o patch do PHP2Shell já foi aplicado.

2. Procure sinais de invasão

Como os ataques começaram antes da correção, os especialistas recomendam olhar os registros desde 17 de outubro. Alguns sinais apontados pela Wiz:

  • muitos erros 500 em sequência, sem explicação;
  • erros de “memória esgotada” logo depois de envios de formulário ou upload;
  • processos do PHP reiniciando com frequência fora do normal;
  • cookies de sessão (PHPSESSID) estranhos, muito grandes ou malformados.

Também vale conferir o básico: usuários administradores que você não criou, arquivos .php novos na pasta de uploads e páginas com conteúdo que você não publicou. Se encontrar algo, siga o nosso guia Meu site foi hackeado: o que fazer?.

O que fazer agora

  1. Descubra quem cuida do servidor. Pode ser a hospedagem, a sua equipe de TI ou uma agência. É essa pessoa que atualiza o PHP.
  2. Peça a confirmação por escrito: “o PHP do meu site já está na versão corrigida do PHP2Shell (CVE-2026-109618 e CVE-2026-109619)?”.
  3. Se estiver em versão sem suporte (8.1 ou anterior), aproveite para migrar. Antes, teste o site numa cópia, porque plugins e temas antigos podem quebrar em PHP mais novo.
  4. Reinicie os serviços do PHP depois da atualização, para que todos os processos usem a versão nova.
  5. Verifique os sinais de invasão listados acima, mesmo depois de atualizar. A correção fecha a porta, mas não expulsa quem já entrou.
  6. Troque senhas e chaves (banco de dados, painel, APIs) se houver qualquer suspeita.

Se não der para atualizar hoje

O PHP publicou medidas temporárias que reduzem o risco, mas deixa claro que elas não tornam o servidor seguro. São ajustes para quem administra o próprio servidor:

  • definir memory_limit como -1 de forma que o site não consiga mudar, e manter o post_max_size baixo;
  • desativar session.upload_progress.enabled;
  • no PHP 8.5, desativar fatal_error_backtraces;
  • reiniciar todos os processos do PHP depois das mudanças.

Quem usa a Cloudflare, inclusive no plano gratuito, recebeu regras de firewall para os ataques conhecidos. Ajuda, mas só protege o tráfego que passa pela Cloudflare e não substitui a atualização.

Se nada disso for possível rápido, a orientação do NCSC (centro de cibersegurança do Reino Unido), repetida pelo WordPress.org, é considerar tirar o sistema do ar até corrigir. Foi exatamente o que os tribunais fizeram.

Por que isso pegou tanta gente de surpresa

Muitos sites ficam anos no mesmo servidor sem ninguém olhar a versão do PHP. Enquanto tudo funciona, parece que está tudo certo. Falhas como essa mostram que a manutenção de um site vai além de atualizar plugin: inclui saber em que servidor o site roda, que versão está instalada e quem responde quando surge um alerta como esse. Já falamos disso no post sobre a falha no cPanel e WHM, e o padrão se repete.

Perguntas frequentes

O PHP2Shell afeta só WordPress?
Não. Afeta qualquer site ou sistema feito em PHP: WordPress, Joomla, Drupal, Magento, lojas virtuais e sistemas sob medida.

Atualizar o WordPress resolve?
Não. É preciso atualizar o PHP do servidor para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou o pacote corrigido da distribuição).

Minha hospedagem atualiza sozinha?
Muitas hospedagens estão atualizando, mas não dá para supor. Peça a confirmação. Em servidor VPS ou dedicado, a atualização normalmente é responsabilidade de quem administra o servidor.

Meu site está no PHP 7.4. E agora?
Não existe versão oficial corrigida para o 7.4. O caminho seguro é migrar para uma versão com suporte, de preferência 8.3 ou 8.4, testando antes numa cópia do site.

Atualizei. Preciso fazer mais alguma coisa?
Sim: reinicie os serviços do PHP e verifique sinais de invasão desde 17/10. Se o site foi invadido antes da atualização, a porta dos fundos continua lá.

Quer ter certeza de que o seu site está protegido?

Na AGT Online, cuidamos de sites e sistemas em PHP há mais de 10 anos. Se você não sabe em que versão o seu site roda, ou não tem certeza se a hospedagem já aplicou a correção, nossa equipe cuida disso para você: verificamos a versão do PHP, aplicamos a atualização ou planejamos a migração e procuramos sinais de invasão.

Os ataques já estão acontecendo, e cada dia com o PHP desatualizado é um dia de porta aberta. Fale com a AGT e peça um orçamento da verificação do seu site.

Fontes