Falha no PHP: o risco para quem vende pela internet vai além da invasão

Por Agência Lastro · Sites, e-commerce e segurança · Última revisão: outubro de 2026

Na quarta-feira, 21 de outubro, o site do Porto de Roterdã, o portal do governo holandês e páginas de hospitais saíram do ar de propósito. Na Finlândia, o órgão de TI do Estado desligou os serviços públicos na internet. Não havia invasão confirmada. As equipes simplesmente preferiram fechar a porta a deixá-la aberta por algumas horas diante de uma falha que permite executar código no servidor sem login.

Para um governo, tirar o site do ar por precaução é um incômodo. Para uma loja virtual com campanha rodando, é receita parada no meio do dia enquanto a mídia continua sendo cobrada. Essa é a parte da notícia sobre a falha no PHP que quase não apareceu na cobertura. A correção técnica é simples: atualizar. O problema está no que acontece quando a atualização demora, ou quando a empresa descobre que ninguém era responsável por ela. A conta chega em vendas, anúncios, posição no Google e dados de clientes.

O que é a falha no PHP, em uma resposta

Uma das falhas aparece quando o PHP fica sem memória no meio de uma requisição e, na limpeza, passa a tratar dados incompletos como válidos. A outra deixa informações de uma requisição esquecidas na memória, prontas para serem reaproveitadas pela próxima visita atendida pelo mesmo processo. O comunicado oficial do PHP considera o risco maior em servidores Apache com mod_php, onde já existe um ataque demonstrado que dispara antes de qualquer linha do site ser executada.

Dois detalhes ajudam a dimensionar o caso. A Cloudflare relatou tentativas iniciais de exploração antes mesmo da correção sair e chamou as regras de firewall que publicou de medida paliativa. E as falhas foram encontradas em agosto por pesquisadores da Wiz e da Calif com apoio de modelos de IA, que ajudaram a transformar um defeito antigo em um ataque funcional. Os próprios pesquisadores da Wiz classificaram o achado entre os mais graves já vistos no PHP.

Por que o WordPress atualizado não protege

WordPress, WooCommerce, Magento, Drupal e boa parte dos sistemas de orçamento, área do cliente e landing pages rodam sobre o PHP. Segundo a W3Techs, citada pelo Canaltech, a linguagem está em 69,3% dos sites cujo servidor é identificável.

Atualizar plugins, tema e o próprio WordPress resolve problemas da camada do site. Esta falha está uma camada abaixo, no interpretador que executa o site. No cenário de mod_php, o ataque acontece antes de o WordPress carregar, ou seja, antes de qualquer plugin de segurança, regra de acesso ou tela de login entrar em cena. Um site com tudo em dia no painel pode continuar vulnerável se o servidor estiver numa versão do PHP sem a correção.

Onde o prejuízo aparece primeiro

A cobertura tratou a falha como assunto de TI. Para quem vende pela internet, ela é um risco operacional com pelo menos quatro portas de saída de dinheiro.

Anúncios reprovados justamente quando a mídia mais importa

Se um invasor usar a falha para injetar código no site, como um redirecionamento ou um script que copia dados de cartão no checkout, o problema passa a ser também de mídia. A política de sites comprometidos do Google Ads reprova anúncios que levam a destinos invadidos, incluindo sites em CMS com vulnerabilidades conhecidas que foram exploradas. Depois da limpeza, é preciso reenviar os anúncios e aguardar até 72 horas pela nova análise.

Estamos a cinco semanas da Black Friday, marcada para 27 de novembro. Três dias de campanha parada em novembro custam mais do que três dias em fevereiro, e o custo não termina na receita perdida. Campanhas que param e voltam perdem histórico de aprendizado, e o investimento que estava planejado para o pico precisa ser redistribuído às pressas.

O aviso de “site invadido” no Google

Quando o Google identifica páginas alteradas ou páginas de spam criadas por um invasor, pode exibir nos resultados o aviso de que o site pode ter sido invadido. Segundo a ajuda do próprio Google, o aviso só sai depois que o responsável corrige o problema e solicita revisão no relatório de Problemas de segurança do Google Search Console. Enquanto ele está lá, o tráfego orgânico que a empresa levou anos para construir passa a ser recebido com desconfiança, e cada clique perdido é um clique que a mídia paga precisará compensar.

Dados de clientes e o custo de um incidente

Execução remota de código significa, na prática, acesso ao servidor com as permissões do site. Isso pode incluir banco de dados de clientes, pedidos e integrações com ERP, gateway e CRM. Se houver vazamento de dados pessoais com risco relevante, a LGPD obriga a comunicar a Autoridade Nacional de Proteção de Dados e os titulares afetados.

Para dar ordem de grandeza: o relatório Cost of a Data Breach 2025, da IBM, calculou em R$ 7,19 milhões o custo médio de uma violação de dados no Brasil. A exploração de vulnerabilidades foi a porta de entrada em 13% dos casos, com custo médio de R$ 7,61 milhões. É uma média de empresas de portes variados, e o número de uma operação pequena tende a ser bem menor. O que o dado mostra é que a conta de um incidente quase sempre supera, com folga, a de manter o servidor atualizado.

Sair do ar por precaução também tem preço

Os órgãos europeus mostraram a alternativa: desligar até corrigir. O CERT-EU e o NCSC do Reino Unido recomendam isso para quem não consegue atualizar a tempo. É uma decisão defensável, mas não é gratuita. Uma loja que fatura R$ 10 mil por dia e fica quatro horas fora no horário de maior movimento pode perder bem mais do que um sexto desse valor, porque parte desses compradores vai concluir a compra no concorrente. O ponto é que essa decisão precisa ser tomada pelo negócio, com as campanhas pausadas no mesmo minuto, e não descoberta depois por alguém olhando o painel de anúncios.

O que decidir nas próximas 48 horas

A resposta muda conforme a forma como o seu site está hospedado. A tabela resume os cenários mais comuns.

Um roteiro curto para não esquecer nada

1. Faça o inventário de tudo que roda PHP, e não só do site principal. Landing pages de campanhas antigas, blog em subdomínio, ambiente de homologação, sistema de orçamento e área do cliente entram na lista. O NCSC recomenda não limitar a busca às versões antigas, porque todas estavam afetadas até hoje.
2. Confirme a versão em execução. No WordPress, ela aparece em Ferramentas, Saúde do site, Informações, Servidor. O número precisa ser igual ou maior que 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, conforme a sua linha de versão.
3. Atualize e reinicie. Pacote instalado com processo antigo rodando não protege. Se o repositório ainda não tiver a versão corrigida, a orientação da Laravel Forge é aguardar e tentar de novo, em vez de dar o servidor como resolvido.
4. Procure sinais de invasão. Veja o relatório de Problemas de segurança no Search Console, usuários administradores que ninguém criou, arquivos alterados recentemente e anúncios reprovados por site comprometido.
5. Se não der para atualizar hoje, decida conscientemente. O PHP publicou ajustes de configuração que reduzem a exposição, mas afirma que eles não deixam a instalação segura. Ou o servidor é atualizado, ou alguém com autoridade decide entre manter no ar com risco ou desligar com as campanhas pausadas.

O prazo que vem depois: 31 de dezembro

A correção desta semana resolve o problema imediato. Ela não resolve o problema de fundo, que é a quantidade de sites rodando em versões do PHP à beira do fim do suporte.

O próprio anúncio do PHP 8.2.35 lembra que essa linha chega ao fim da vida em 31 de dezembro de 2026, daqui a 71 dias. Depois disso, não recebe mais correções de segurança. Uma compilação da Xictron com dados do WordPress.org, de setembro de 2026, mostra que 62% das instalações de WordPress que reportam versão rodam PHP 8.2 ou anterior, e 37,6% já estão em linhas sem suporte (da 4.4 à 8.1). Para essa parcela, a próxima falha crítica pode chegar sem correção oficial. Desta vez, a equipe do PHP abriu exceção e publicou correções mínimas para as versões 7.4, 8.0 e 8.1, mas fez isso pela gravidade do caso, e não como compromisso.

Por que a migração costuma ficar para depois

Trocar a versão do PHP raramente é apertar um botão. Temas antigos, plugins abandonados e código feito sob medida quebram em versões novas, e o teste precisa acontecer numa cópia do site, não em produção. Em projetos que passaram por várias mãos, ninguém sabe exatamente o que vai parar de funcionar, e a migração vira um projeto que ninguém quer assumir antes do fim de ano.

Vale fazer a conta com honestidade. Em muitos casos, atualizar o site existente é o caminho certo e mais barato. Em outros, quando o site é antigo, depende de plugins sem manutenção e já não converte bem, o custo de remendar se aproxima do de refazer. Aí a pergunta deixa de ser só técnica e passa a ser de negócio: faz sentido investir para manter vivo um site que já não ajuda a vender? Se ele também é o destino da sua mídia, a análise do funil e da taxa de conversão do e-commerce ajuda a separar o que é problema de infraestrutura do que é problema de experiência.

Quem é o dono do PHP na sua empresa?

Esta é a pergunta que mais importa, e a que menos aparece nas matérias. Em muitas empresas, a versão do PHP não tem dono. A agência entregou o site e seguiu em frente. A hospedagem entende que a escolha da versão é do cliente. O marketing acha que é assunto da TI. A TI não sabe que existe um blog num subdomínio, montado para uma campanha de três anos atrás.

O site é tratado como peça de marketing, mas funciona como infraestrutura de receita: recebe a mídia, converte o lead, processa o pedido e guarda os dados do cliente. Por isso merece o mesmo cuidado que a empresa dá às campanhas. Três decisões resolvem a maior parte do risco:

• Um responsável nominal por versão de PHP, backups e atualizações, com nome de pessoa ou fornecedor, e não de área.
• Um inventário atualizado de tudo que está no ar com o domínio da empresa, incluindo páginas de campanhas encerradas.
• Um contrato que diga quem atualiza o quê, com prazo de resposta para falhas críticas, seja com a agência, a hospedagem ou o time interno.

O que ainda não se sabe

Alguns pontos pedem cautela antes de transformar o alerta em pânico.

• Não há confirmação de invasões em massa. A Cloudflare relatou tentativas iniciais e a Patchstack registrou varreduras logo após a correção. A agência de cibersegurança da Austrália disse não ter conhecimento de exploração ativa.
• Os detalhes técnicos ainda estão se acomodando. Parte do que circulou antes da correção, a partir de um vazamento, estava errada. Vale acompanhar o comunicado oficial em vez de posts de redes sociais.
• As medidas paliativas são incompletas. Regras de firewall e ajustes de configuração reduzem caminhos de ataque conhecidos. O próprio PHP afirma que só a atualização resolve.
• O custo médio da IBM é uma referência, não uma previsão. Ele mostra a ordem de grandeza de um incidente, não quanto a sua empresa perderia.

Atualizar é a parte fácil

Na maioria dos sites, a correção da PHP2Shell leva minutos. O que costuma demorar é descobrir quem deveria aplicá-la, onde estão todos os endereços que rodam PHP e quem tem autorização para tirar o site do ar se a correção não vier a tempo. A falha desta semana expôs menos um defeito de software e mais um defeito de gestão: sites que geram receita sem ninguém cuidando da camada que os mantém de pé.

A urgência de hoje é atualizar. A de dezembro é sair das versões que vão ficar sem suporte. E a permanente é tratar o site com a mesma seriedade com que se trata o orçamento de mídia que leva o cliente até ele.

Para projetos maiores, como lojas com integrações ou migração de plataforma, a página de desenvolvimento de sites e lojas virtuais explica como a Lastro trabalha.