Falha no PHP: o que fazer se sua loja roda WordPress

Em 21 de outubro, o projeto que mantém o PHP corrigiu a falha que ficou conhecida como php2shell: duas brechas que permitem a um atacante executar código em um site PHP sem fazer login. O PHP roda cerca de sete em cada dez sites, e toda loja em WordPress, WooCommerce ou Magento é um deles. A OpenAI, cujo parceiro encontrou uma das brechas com um modelo de IA, chamou o caso de "um dos problemas de segurança de maior impacto recente".

Nossa opinião, antes dos detalhes. Pela primeira vez nessa escala, quem encontrou a falha foi uma máquina trabalhando para a defesa. A OpenAI diz que, até onde sabe, a IA achou as brechas antes dos atacantes, e isso viabilizou dois meses de preparação silenciosa: correções para quatro versões do PHP, regras de firewall na Cloudflare e em outros provedores, e avisos a governos. Os detalhes vazaram um dia antes da liberação das correções, e o tráfego de ataque começou horas antes dos patches saírem. Esse é o novo formato de uma falha crítica, e a própria OpenAI espera "que descobertas semelhantes aumentem bastante nos próximos meses". A lição para uma loja não é sobre IA. É que o tempo entre "existe uma correção" e "a correção está no meu servidor" é a única variável que você controla, e ele precisa encolher de semanas para um dia. Para registro: checamos enquanto escrevíamos este texto, e nenhum dos nossos sistemas roda PHP.

O que é a falha no PHP

O PHP lançou as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 para corrigir as CVE-2026-109618 e CVE-2026-109619. O aviso do projeto é direto: toda instalação de PHP que atende requisições web está em risco, e atualizar é a única solução completa. A CISA, a agência de cibersegurança dos Estados Unidos, mandou as organizações corrigirem imediatamente e, se não puderem, ou se rodarem PHP 8.1 ou anterior, tirarem esses sistemas do ar até conseguirem. Partes da Wikipédia, fóruns grandes e alguns sites do governo holandês fizeram exatamente isso por algumas horas. Nada disso precisou de um funcionário clicando em alguma coisa, que é o padrão que descrevemos no artigo sobre ataques sem clique.

Quem é afetado

Se a sua loja roda em WordPress com WooCommerce, ou em Magento, ela roda em PHP, e a falha fica embaixo do código da loja. A Sansec, especializada em segurança de lojas, foi clara: as lojas são afetadas mesmo quando o próprio código está limpo, e o ataque foi demonstrado contra versões atuais de WordPress e Magento. Outras plataformas construídas em PHP estão na mesma posição, e também aquele blog em WordPress que fica separado de uma loja que roda em outra plataforma. Plataformas hospedadas, que cuidam dos próprios servidores, precisam confirmar que já aplicaram a correção, e nesse caso não há nada para você atualizar.

Uma coisa não muda nada: atualizar o WordPress, um tema ou um plugin. O próprio WordPress disse isso. Nenhuma atualização do WordPress é necessária ou planejada, porque a correção está no PHP.

O que fazer primeiro

• Descubra a sua versão do PHP. No WordPress: Ferramentas, Diagnóstico, Informações, Servidor. No Magento ou no painel da hospedagem, o seletor de PHP. Você precisa das versões 8.2.35, 8.3.36, 8.4.27 ou 8.5.12.
• Se a hospedagem cuida do PHP, que é o caso da maioria das lojas, leia o comunicado dela ou pergunte por escrito. A Hostinger, por exemplo, está aplicando a correção nos planos gerenciados e deixando os clientes de VPS atualizarem por conta própria.
• Se você está no PHP 8.1 ou anterior, esta é a atualização forçada. Um terço dos sites em PHP ainda roda versões que o projeto não corrige mais. Algumas hospedagens aplicaram a correção às versões antigas; pergunte qual versão elas usam.
• Mantenha o firewall ligado. As regras da Cloudflare entraram no ar antes da correção e bloqueiam as tentativas conhecidas, inclusive no plano gratuito. O conselho da própria Cloudflare é atualizar mesmo assim.
• Depois de corrigir, procure sinais. Usuários administradores novos, páginas de checkout ou pagamento alteradas, redirecionamentos, plugins que você não instalou. Uma das duas brechas pode vazar a memória do servidor, senhas e chaves incluídas, então a Patchstack recomenda trocar as credenciais de qualquer servidor que ficou exposto.

Sobre "tirar o site do ar"

A CISA, o Reino Unido e a União Europeia disseram que organizações sem condições de corrigir deveriam considerar tirar os sistemas do ar, e algumas tiraram. A gente não está dizendo para você fechar a loja. Estamos apontando o que significa agências sérias falarem isso: é o nível de falha em que uma hora de vendas perdidas foi considerada mais barata do que uma hora de exposição. Em 22 de outubro, a Sansec informou que a exploração em massa parece menos provável do que se temia, porque os caminhos de ataque conhecidos precisam de condições específicas no alvo, e disse: "Você não precisa tirar sua loja do ar. Atualize o PHP mesmo assim."

O golpe que vem depois de toda falha grande

Em poucos dias, espere e-mails e mensagens de WhatsApp se passando pela sua hospedagem: seu site está vulnerável ao php2shell, faça login aqui para aplicar a atualização. A atualização de verdade nunca pede que você faça login por um link que alguém te mandou. O movimento certo é o do nosso último artigo: entre no site da sua hospedagem, não no link, e avise quem cuida da TI. Se quiser saber quem no seu time clicaria na atualização falsa, faça um teste de phishing gratuito para funcionários.

Perguntas frequentes

Isso é uma falha do WordPress? Não. É uma falha no PHP, a linguagem em que WordPress, WooCommerce, Magento e muitas outras plataformas rodam. Por isso atualizar o WordPress não resolve nada, mas sim atualizar o PHP.

Minha hospedagem diz que corrigiu. Estou seguro? Confira a versão você mesmo no Diagnóstico. Se a hospedagem demorou, ou se você não consegue saber quando corrigiu, troque as senhas de administrador e as chaves de API da loja e procure os sinais acima. A brecha de vazamento de memória significa que um servidor já corrigido ainda pode estar carregando um segredo roubado.

A falha está sendo explorada? A Cloudflare viu tráfego de ataque horas antes da correção. A telemetria da Patchstack em 21 de outubro mostrou sondagens, sem invasões confirmadas. A CISA não tinha observado exploração quando publicou o alerta. Em 22 de outubro, a Sansec avaliou a exploração em massa como menos provável do que se temia no início. As quatro coisas podem ser verdade ao mesmo tempo, e nenhuma delas muda o que você deve fazer.

A IA deixa isso melhor ou pior? As duas coisas, e esse é o ponto. A mesma capacidade que encontrou a falha para a defesa é a que vimos atingir quem só estava ao alcance entre julho e agosto. A janela entre a descoberta e o ataque agora se mede em horas, então a sua atualização também precisa dessa velocidade.

Para o seu time de TI. Faça inventário de uso do PHP além dos servidores web; a CISA lembra que ele vem embutido em outros softwares. Busque estar nas quatro versões corrigidas; para 8.1 e anteriores, use um backport de fornecedor da tabela da Sansec ou atualize para uma versão mais nova. As configurações provisórias do aviso do projeto do PHP reduzem a exposição, mas não deixam a instalação segura. Mantenha as regras do WAF ligadas. Observe processos de worker do PHP abrindo shells ou baixando ferramentas, revise os logs a partir de 20 de outubro e troque os segredos de tudo o que ficou exposto. Veja o que a gente checaria →

---

A versão do PHP que um site anuncia é a primeira linha de todo relatório de exposição que a gente escreve. Se você prefere que o time de segurança que você não precisa contratar faça e leia o seu, fale com a gente.