Publicado em 21 de outubro de 2026. Vou atualizar este artigo conforme surgirem novidades.

Se o seu site é WordPress, ou se a sua loja é WooCommerce, ele roda em PHP. E no dia 21 de outubro de 2026 o PHP lançou uma correção de emergência para duas falhas críticas, apelidadas de PHP2Shell. Em resumo: um invasor, sem senha e sem login, consegue mandar uma única requisição para o seu servidor e rodar os comandos que quiser lá dentro.

Não é exagero de quem vende segurança. Pesquisadores da Wiz, que explicaram as falhas, escreveram que elas estão “entre as vulnerabilidades mais graves já encontradas no PHP”. O pesquisador Kevin Beaumont previu que a situação “vai gerar uma massa de incidentes”. E no mesmo dia da correção já apareceram tentativas de ataque.

Neste artigo eu explico, sem tecniquês, o que está em jogo para quem tem site ou loja, como descobrir em cinco minutos se o seu está exposto e o que fazer, na ordem certa.

Resumo rápido

  • O que é: duas falhas no próprio PHP (CVE-2026-109618 e CVE-2026-109619), apelidadas de PHP2Shell, com nota de gravidade 9,2 de 10.
  • O risco: alguém de fora executa código no servidor do seu site sem precisar de senha nenhuma.
  • Quem está exposto: todo site em PHP que ainda não recebeu a correção, o que inclui WordPress e WooCommerce.
  • Versões corrigidas: PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12.
  • Pior cenário: PHP 8.1 ou mais antigo, que não recebe mais correção oficial do PHP.
  • O que fazer hoje: confirmar a versão do PHP, cobrar a hospedagem, ligar um firewall e procurar sinais de invasão.

O que é o PHP2Shell

O PHP é a linguagem que faz o WordPress funcionar. Cada vez que alguém abre uma página do seu site, coloca um produto no carrinho ou faz login, é o PHP que trabalha no servidor para montar a resposta.

As duas falhas estão no “motor” do PHP, e não em um plugin ou tema. Por isso não adianta o seu WordPress estar com tudo atualizado: se o PHP do servidor é vulnerável, o site é vulnerável.

  • A primeira falha acontece quando o PHP fica sem memória no meio do processamento de uma requisição. Ele deixa dados pela metade e depois os trata como se estivessem certos. É por essa brecha que o invasor consegue executar código.
  • A segunda falha faz o PHP guardar informações de uma visita depois de já ter liberado aquela memória. Uma visita seguinte pode ler o que sobrou. Segundo a Wiz, isso pode vazar senhas, tokens, chaves de API e certificados, além de também permitir execução de código.

As falhas existem há muitos anos no código do PHP. O que mudou agora é que os detalhes vazaram antes da hora e, com ferramentas de inteligência artificial, ficou bem mais fácil montar um ataque que funciona.

Linha do tempo: o que aconteceu e quando

Data O que aconteceu
20 de outubro O PHP avisa que vai lançar uma atualização de segurança crítica. Detalhes começam a circular antes da divulgação oficial.
21 de outubro, manhã Empresas de firewall publicam as primeiras regras para barrar o ataque conhecido. A Cloudflare libera regras para todos os clientes, inclusive no plano gratuito.
21 de outubro, tarde Saem as versões corrigidas 8.2.35, 8.3.36, 8.4.27 e 8.5.12, com o comunicado completo do PHP.
21 de outubro A watchTowr registra exploração real na sua rede de armadilhas espalhada pelo mundo. A Cloudflare relata as primeiras tentativas de ataque.
Dias seguintes Hospedagens e distribuições Linux liberam os pacotes corrigidos aos poucos, cada uma no seu ritmo.

Essa última linha é a que mais pesa para você. Entre o PHP corrigir e a sua hospedagem aplicar a correção no seu servidor, existe uma janela. E é nessa janela que os ataques em massa acontecem.

Por que isso é problema de quem tem WordPress e WooCommerce

Quem ataca não escolhe o seu site a dedo. Robôs varrem a internet atrás de qualquer servidor que responda em PHP e testam o ataque em todos. O seu site entra na lista pelo simples fato de existir.

E num site WordPress, quem consegue rodar código no servidor alcança praticamente tudo:

  • O arquivo de configuração, com a senha do banco de dados.
  • O banco de dados inteiro: clientes, e-mails, telefones, endereços e histórico de pedidos.
  • As chaves de integração que a loja guarda: gateway de pagamento, ERP, frete, marketplace, e-mail marketing.
  • Os arquivos do site, onde dá para esconder uma porta dos fundos que continua lá mesmo depois que o PHP for corrigido.

Na loja, o estrago vai além do técnico. Um site invadido pode redirecionar visitantes para golpes, ser marcado como perigoso pelo Google, perder posição nas buscas e ter anúncios reprovados. E se houver vazamento de dados de clientes, entra também a dor de cabeça com a LGPD.

O mais traiçoeiro: a correção do PHP fecha a porta, mas não tira quem já entrou. Um site invadido antes da atualização continua invadido depois dela.

Como saber se o seu site está vulnerável

Você descobre a versão do PHP em menos de cinco minutos, sem instalar nada:

  1. Entre no painel do WordPress. Use o login de administrador.
  2. Abra Ferramentas > Saúde do site. No menu lateral, clique em Ferramentas e depois em Saúde do site.
  3. Clique na aba Informações. Ela fica no topo da página.
  4. Abra a seção Servidor. A linha “Versão do PHP” mostra o número que o seu site usa.
  5. Compare com a tabela abaixo. Ela diz se a sua versão está corrigida ou não.
Sua versão Situação
8.2.35, 8.3.36, 8.4.27, 8.5.12 ou mais nova Corrigida.
8.2, 8.3, 8.4 ou 8.5 abaixo desses números Provavelmente vulnerável. Confirme com a hospedagem (veja o alerta logo abaixo).
8.1, 8.0, 7.x ou mais antiga Situação mais grave. O PHP não lança mais correção oficial para essas versões. A saída de verdade é migrar para uma versão suportada.

Um alerta importante sobre hospedagem compartilhada. Muitas hospedagens corrigem o PHP por conta própria, aplicando só o “remendo” na versão que já usam. Nesse caso o número que aparece no painel não muda, mesmo com a correção aplicada. O contrário também acontece: o número pode parecer em dia e a correção ainda não ter chegado ao seu servidor. Por isso o número sozinho não basta. Peça para a hospedagem confirmar por escrito que o PHP do seu plano está corrigido contra as falhas CVE-2026-109618 e CVE-2026-109619.

Como resolver: o passo a passo

A ordem importa. Primeiro fechar a porta, depois conferir se alguém entrou, depois deixar o site preparado para a próxima falha, que vai existir.

1. Atualize o PHP ou cobre a hospedagem

Em servidor próprio (VPS ou dedicado), atualize os pacotes do PHP pelo gerenciador da sua distribuição e reinicie o PHP e o servidor web. Em hospedagem compartilhada, abra um chamado e peça a confirmação por escrito de que o seu plano já recebeu a correção. Se a resposta for vaga, trate o site como vulnerável até prova em contrário.

2. Saia das versões abandonadas

Se o seu site ainda roda PHP 7.4, 8.0 ou 8.1, ele já estava sem correções oficiais antes desta falha. Agora isso virou urgência. O destino seguro hoje é o PHP 8.3 ou mais novo.

O motivo de tanta gente continuar em versão velha é o medo de quebrar o site, e esse medo tem fundamento: tema desatualizado e plugin abandonado costumam dar erro em PHP novo. O caminho certo é fazer um backup completo, testar a versão nova numa cópia do site, corrigir ou trocar o que quebrar e só então virar o site de verdade.

3. Desligue o recurso usado no ataque conhecido

O ataque mais divulgado abusa de um recurso do PHP que mostra o progresso de envio de arquivos. Quase nenhum site WordPress usa isso. A configuração session.upload_progress.enabled = Off no php.ini desliga o recurso. O próprio PHP recomenda manter desligado mesmo depois da atualização, se você não usa. Vale lembrar que isso reduz o risco, mas não substitui a correção.

4. Coloque um firewall na frente do site

Um firewall de aplicação (WAF) barra a requisição maliciosa antes de ela chegar ao seu servidor. A Cloudflare liberou regras contra o PHP2Shell para todos os clientes, inclusive no plano gratuito. Hospedagens com Imunify360 também receberam regras novas. É a proteção que funciona enquanto a correção não chega, e continua útil depois dela.

5. Procure sinais de invasão

Como a falha já estava sendo explorada antes de muita hospedagem corrigir, vale conferir:

  • Arquivos .php dentro da pasta wp-content/uploads, onde só deveria haver imagens e documentos.
  • Arquivos novos ou alterados nos últimos dias que ninguém da sua equipe mexeu.
  • Usuários administradores que você não reconhece.
  • Tarefas agendadas (cron) estranhas no servidor ou no WordPress.
  • Redirecionamentos para sites desconhecidos, principalmente quando você acessa pelo celular ou vindo do Google.
  • Avisos no Google Search Console sobre problemas de segurança.

6. Troque senhas e chaves se houver qualquer suspeita

Como a segunda falha pode vazar memória do servidor, quem encontrar qualquer sinal de invasão deve trocar tudo: a senha do banco de dados, as chaves de segurança do wp-config.php (o que desloga todo mundo), as senhas dos administradores e as chaves de API das integrações da loja, como pagamento, ERP e frete.

7. Tenha backup fora do servidor

Backup guardado no mesmo servidor do site some junto com ele, ou é corrompido pelo invasor. O backup que salva o seu negócio fica em outro lugar e é testado de tempos em tempos. Sem ele, limpar um site invadido pode virar refazer o site.

8. Deixe alguém de olho, todo dia

O PHP2Shell não vai ser a última falha grave. O que separa o site que sai ileso do site que vira estatística é ter alguém que fica sabendo da falha no dia, sabe exatamente quais sites estão expostos e age antes dos robôs chegarem.

Checklist para hoje

  • ☐ Conferi a versão do PHP em Ferramentas > Saúde do site.
  • ☐ Pedi à hospedagem a confirmação por escrito da correção.
  • ☐ Se uso PHP 8.1 ou mais antigo, já tenho plano para migrar.
  • ☐ O site está atrás de um firewall (Cloudflare ou similar).
  • ☐ Procurei arquivos estranhos, administradores desconhecidos e redirecionamentos.
  • ☐ Tenho backup recente guardado fora do servidor.
  • ☐ Sei quem vai me avisar na próxima falha.

Quando chamar um profissional

Dá para fazer boa parte desse checklist sozinho. Mas tem situações em que tentar resolver por conta própria custa mais caro que pedir ajuda:

  • O site roda PHP 8.1 ou mais antigo e você tem medo de que a atualização derrube tudo.
  • A hospedagem não responde ou responde de forma vaga sobre a correção.
  • Você encontrou algum sinal de invasão e não sabe se limpou tudo.
  • A loja vende todo dia e não pode ficar fora do ar enquanto alguém aprende fazendo.
  • Ninguém cuida do site desde que ele ficou pronto.

É exatamente esse tipo de trabalho que eu faço nos meus próprios sites e lojas e nos sites de clientes: confiro a versão real do PHP em cada servidor, atualizo com backup e teste antes, ponho firewall na frente, procuro sinais de invasão e deixo vigias automáticos avisando quando alguma coisa muda. Os serviços de sites e lojas em WordPress e WooCommerce incluem hospedagem, atualizações, backup e firewall.

Não sabe se o seu site está protegido?

Me conta qual é o seu site e onde ele está hospedado. Eu digo o que eu conferiria primeiro e o que precisa ser feito, na ordem certa. Atendimento por vídeo para todo o Brasil.

Agendar reunião comigo

Perguntas frequentes

O que é o PHP2Shell?

É o apelido de duas falhas críticas no PHP, registradas como CVE-2026-109618 e CVE-2026-109619 e corrigidas em 21 de outubro de 2026. Elas permitem que alguém execute código no servidor sem precisar de senha.

Meu WordPress está atualizado. Estou protegido?

Não necessariamente. A falha está no PHP do servidor, não no WordPress, nos temas ou nos plugins. Um WordPress todo atualizado em um PHP sem correção continua exposto.

Quais versões do PHP estão corrigidas?

PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12, ou mais novas. Hospedagens e distribuições Linux também podem aplicar a correção sem mudar o número da versão, por isso vale pedir a confirmação ao fornecedor.

Como vejo a versão do PHP do meu site?

No painel do WordPress, em Ferramentas, Saúde do site, aba Informações, seção Servidor. A linha “Versão do PHP” mostra o número.

Uso PHP 7.4 ou 8.1. O que faço?

Essas versões não recebem mais correção oficial do PHP. Algumas hospedagens e fornecedores de suporte estendido aplicam correções por conta própria, mas a saída definitiva é migrar para o PHP 8.3 ou mais novo, com backup e teste numa cópia do site antes.

Trocar a versão do PHP no painel da hospedagem resolve?

Só se a versão escolhida já tiver a correção. Trocar de 8.2 para 8.3 sem a correção aplicada não muda nada. O que resolve é a versão corrigida estar instalada no servidor.

Hospedagem compartilhada é mais segura nesse caso?

Ela tira de você o trabalho de atualizar o PHP, mas você depende do prazo da empresa. Enquanto a correção não chega ao seu plano, o firewall é a melhor proteção.

O firewall gratuito da Cloudflare protege?

Ajuda bastante. A Cloudflare liberou regras contra os ataques conhecidos para todos os clientes, inclusive no plano gratuito. Mas é uma proteção extra, não substitui a correção do PHP.

Como saber se meu site já foi invadido?

Procure arquivos PHP dentro da pasta de uploads, arquivos alterados que ninguém mexeu, administradores desconhecidos, tarefas agendadas estranhas e redirecionamentos para outros sites. Na dúvida, peça uma verificação profissional.

Atualizar o PHP pode quebrar meu site?

Pode, se o tema ou algum plugin estiver muito desatualizado. Por isso a atualização segura começa com backup e teste numa cópia do site. Corrige o que quebrar e só depois aplica no site de verdade.

Se eu atualizar agora, o problema acabou?

A porta fica fechada, mas quem entrou antes pode ter deixado uma porta dos fundos. Depois de atualizar, confira os sinais de invasão e, se houver qualquer suspeita, troque senhas e chaves.


Fontes: PHP (comunicado oficial), Help Net Security, Huntress, watchTowr, CloudLinux e The Hacker News.

Sobre o autor: Maurício Muela é consultor de Google Ads e SEO e vende online desde 2002. Trabalha com WordPress e WooCommerce há mais de 12 anos, no próprio site, nas próprias lojas e nas de clientes. Foi Diretor Comercial na iData Distribuidora e responsável pelo e-commerce na INFOCWB. Atende em todo o Brasil. Saiba mais.

Escrito com apoio de IA, revisado por Maurício Muela. PHP é marca do PHP Group; WordPress e WooCommerce pertencem às respectivas organizações. Este artigo é independente e informativo, e não substitui uma análise do seu servidor.

Precisa de ajuda com isso na prática.

Fale comigo no WhatsApp: (41) 99894-1133

Uma conversa de 30 minutos antes de qualquer proposta.