Falha Crítica no PHP: Como Proteger e Atualizar seu Site

Por Anna Clara · Publicado em 21/10/2026 · 10 min de leitura

⚡ Resposta rápida: Descubra a versão do PHP do seu site (WordPress: Ferramentas > Saúde do site; cPanel: MultiPHP Manager). Se não for 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, faça backup e troque para o PHP 8.3. Versões 8.1 e anteriores não têm correção oficial. Depois, teste as páginas sem cache, o checkout e os eventos do pixel.

Falha Crítica no PHP: Como Proteger e Atualizar seu Site

No dia 21 de outubro de 2026 foram divulgadas duas falhas graves no PHP, a linguagem que roda por trás de boa parte dos sites da internet: o WordPress, o Elementor, a maioria das páginas de vendas e quase toda hospedagem compartilhada. As falhas receberam os códigos CVE-2026-109618 e CVE-2026-109619 e ganharam o apelido de PHP2Shell. Em português claro: um atacante consegue rodar comandos no servidor sem precisar de senha nenhuma.

E por que isso é assunto de quem trabalha com tráfego pago? Porque a sua página de vendas, a sua landing page de captura e o site do seu cliente rodam, muito provavelmente, em PHP. Site invadido vira redirecionamento para spam, pixel adulterado, anúncio reprovado por "site comprometido" e, no pior caso, domínio marcado como perigoso pelo Google. Você paga o clique e o visitante cai numa página de golpe.

Neste artigo eu te mostro, passo a passo, como descobrir se o seu site está em risco, como atualizar o PHP na hospedagem compartilhada e num servidor próprio, o que fazer se você não conseguir atualizar hoje e como conferir se ficou tudo funcionando depois. Sem pânico, mas sem deixar para semana que vem, ok?

O que é a falha PHP2Shell e quem está em risco

As duas falhas afetam todas as versões do PHP do 5 em diante. Não importa se o seu site é um WordPress simples, uma página feita no Elementor, uma loja ou um sistema próprio: se o servidor executa PHP e a versão não é uma das corrigidas, ele está no grupo de risco. Pesquisadores de segurança já publicaram código de ataque, o que significa que robôs começam a varrer a internet atrás de sites vulneráveis em questão de horas.

Pelo que as empresas de segurança descreveram, todos os ataques conhecidos usam requisições do tipo multipart/form-data, o mesmo formato que um formulário usa para enviar arquivo. Por isso, uma parte das medidas provisórias passa por limitar esse tipo de envio, como você vai ver mais abaixo.

Quais versões do PHP já estão corrigidas

O projeto PHP lançou correções no mesmo dia da divulgação. A tabela abaixo resume onde você precisa chegar:

Sua versão	Versão corrigida	O que fazer
PHP 8.5	8.5.12	Atualizar dentro da mesma versão
PHP 8.4	8.4.27	Atualizar dentro da mesma versão
PHP 8.3	8.3.36	Atualizar dentro da mesma versão
PHP 8.2	8.2.35	Atualizar, mas planejar a ida para 8.3 (o suporte de segurança do 8.2 termina em 31/12/2026)
PHP 8.1, 8.0, 7.x ou 5.x	Sem versão oficial corrigida	Subir para 8.3 ou mais nova

A linha mais importante é a última. Quem está no PHP 7.4 ou anterior não tem um "botão de atualizar" que resolva: a correção só existe nas versões 8.2 em diante. E, se for para trocar de versão de qualquer jeito, eu recomendo ir direto para o 8.3: o 8.2 deixa de receber correções de segurança no fim de 2026, então você faria esse trabalho duas vezes em poucos meses.

Passo 1: descubra qual versão do PHP o seu site usa

Você tem três jeitos de descobrir, do mais fácil ao mais técnico:

Cansado de decidir campanha no achismo? As 10 ferramentas da Central Ads — calculadoras, diagnósticos e simuladores — fazem a conta por você.

Pelo WordPress: no painel, vá em Ferramentas > Saúde do site > Informações e abra a seção Servidor. A linha "Versão do PHP" mostra o número exato.
Pelo painel da hospedagem (cPanel): procure por MultiPHP Manager ou Selecionar versão do PHP. Ali aparece a versão de cada domínio.
Num servidor próprio (VPS): no terminal, rode php -v. Lembre que o PHP da linha de comando pode ser diferente do que atende o site; confira também o serviço do PHP-FPM (por exemplo, systemctl list-units | grep fpm).

Anote a versão de cada site. É muito comum o gestor de tráfego ter a página principal atualizada e esquecer aquela pre-sell antiga, a landing de um lançamento de dois anos atrás ou o site de um cliente que "ninguém mexe". Site esquecido é justamente o que é invadido.

Passo 2: faça backup antes de qualquer mudança

Trocar a versão do PHP costuma ser tranquilo, mas pode quebrar plugin antigo ou tema desatualizado. Antes de mexer:

Hospedagem compartilhada: gere um backup completo pelo painel (arquivos e banco de dados) ou use um plugin de backup no WordPress.
Servidor próprio: tire um snapshot do servidor no painel do provedor. É a forma mais rápida de voltar atrás se algo der errado, e custa centavos se você apagar depois de alguns dias. Além dele, exporte os bancos de dados para um arquivo e guarde uma cópia fora do servidor.
WordPress: atualize o núcleo, os plugins e o tema antes de trocar o PHP. Plugin velho é o que mais quebra numa versão nova.

Passo 3: atualizando na hospedagem compartilhada

Se o seu site está numa hospedagem compartilhada, a boa notícia é que o trabalho pesado é da empresa de hospedagem. Ela aplica a correção nas versões que oferece. A sua parte é escolher uma versão corrigida para o seu site:

Entre no cPanel e abra o MultiPHP Manager (ou Selecionar versão do PHP).
Marque o domínio e escolha PHP 8.3.
Abra o site numa janela anônima e navegue pelas páginas principais: home, página de vendas, formulário e checkout.
Se alguma coisa quebrar, volte para a versão anterior no mesmo lugar e descubra qual plugin é o culpado (desative um por um).

Se o painel não mostra o 8.3, ou só oferece versões antigas, abra um chamado no suporte e pergunte diretamente: "a versão do PHP do meu plano já recebeu a correção do CVE-2026-109618?". Hospedagem que não responde isso com clareza é um sinal para pensar em trocar. Se você está avaliando opções, eu comparei algumas no artigo sobre a melhor hospedagem de sites no Brasil.

Passo 4: atualizando num servidor próprio (VPS)

Aqui a responsabilidade é toda sua. E o primeiro obstáculo costuma não ser o PHP, e sim o sistema operacional. Um servidor com sistema muito antigo (por exemplo, uma versão de Linux que já saiu de suporte) não consegue instalar o PHP 8.3, porque os pacotes novos não são feitos para ele. Nesse caso, a ordem é: atualizar o sistema, depois o PHP. Alguns cuidados que aprendi na prática:

Atualize o sistema uma versão por vez. Pular várias de uma vez costuma dar errado. Reinicie o servidor entre uma etapa e outra para confirmar que ele liga normalmente.
Rode a atualização dentro de um screen ou tmux. Se a sua conexão cair no meio, a atualização continua.
Mantenha o PHP novo no mesmo endereço do antigo. Se o seu nginx manda as requisições para uma porta ou socket específico, configure o PHP 8.3 para escutar exatamente ali. Assim você não precisa mexer na configuração de cada site.
Leve junto as configurações do php.ini (limite de memória, tamanho de upload, fuso horário). Versão nova vem com o padrão de fábrica.
Cuidado com o servidor web. Versões novas do nginx removeram diretivas antigas, como o ssl on;. Rode nginx -t antes de reiniciar, sempre.
Revise as tarefas agendadas (cron). É comum o cron chamar o PHP por um caminho fixo, tipo php7.4 script.php. Depois da troca, esse comando simplesmente para de funcionar, e em silêncio.

Não dá para atualizar hoje? Faça o paliativo

Se você precisa de alguns dias para planejar a atualização, existem medidas que reduzem o risco. Elas não fecham a falha, só dificultam os caminhos de ataque conhecidos:

Desligue o session.upload_progress.enabled (coloque 0) na configuração do PHP.
Diminua o post_max_size para o mínimo que o site precisa (8M em sites sem upload, 32M em sites com upload).
Nos sites que não recebem arquivo de visitante, bloqueie requisições multipart/form-data no servidor web ou no firewall da hospedagem.
Desligue versões do PHP que estão instaladas mas não atendem nenhum site.
Reinicie o PHP-FPM depois de qualquer mudança. Processo antigo rodando continua vulnerável mesmo depois do ajuste.

Trate isso como um curativo de poucos dias, não como solução.

Depois de atualizar: o checklist que evita surpresa

O erro mais traiçoeiro numa atualização dessas é achar que está tudo bem porque a home abriu. Muitos sites têm cache de página: a home aparece normal, mas é uma cópia guardada, e o site por trás está fora do ar. Confira assim:

Teste sem cache: abra as páginas com um parâmetro qualquer no fim do endereço, como ?teste=1, que costuma furar o cache. Teste também a busca interna e páginas com formulário.
Teste o caminho do dinheiro: página de vendas, botão de compra, checkout e página de obrigado.
Confira o rastreamento: abra o Gerenciador de Eventos da Meta e veja se os eventos do pixel e da API de Conversões continuam chegando. Script de servidor quebrado derruba o envio de evento sem avisar ninguém.
Olhe o log de erros do PHP e do servidor web na primeira hora depois da troca.
Confira as tarefas agendadas no dia seguinte: e-mails automáticos, publicação programada, integrações.
Apague o snapshot depois de dois ou três dias sem problema, para não pagar armazenamento à toa.

Sinais de que o site já pode ter sido invadido

Se o seu site ficou exposto, vale uma olhada rápida nestes sinais:

Visitantes do celular sendo redirecionados para outra página (muitas vezes só no celular, para o dono não perceber).
Arquivos .php estranhos dentro da pasta de uploads do WordPress.
Usuários administradores que você não criou.
Aviso do Google de "este site pode ter sido invadido" na busca ou no Search Console.
Anúncio reprovado por "site comprometido" ou "software malicioso", ou aumento repentino de reprovações. Se isso aconteceu, veja também o que fazer com anúncio reprovado no Facebook.
Arquivos do sistema travados que nem o administrador consegue alterar, ou serviços com nomes estranhos no servidor. Invasores costumam fazer isso para proteger o que plantaram.

Se encontrar qualquer um desses sinais, só atualizar o PHP não basta: o invasor pode ter deixado uma porta dos fundos. O caminho é restaurar um backup limpo de antes da invasão, trocar todas as senhas (painel, banco, FTP, WordPress) e, se o servidor é seu, considerar montar um servidor novo do zero.

Aproveite para fazer uma faxina

Toda atualização dessas é uma boa hora para desligar o que você não usa. Pre-sell de campanha antiga, WordPress de teste, domínio que não aponta mais para lugar nenhum: cada site parado é uma porta aberta que ninguém está vigiando. Não precisa apagar. Tire do ar, guarde o backup e, se um dia precisar, você sobe de novo. Site que não está no ar não precisa de atualização e não pode ser invadido.

E se você está começando um site agora, já comece certo: escolha uma hospedagem que mantenha o PHP atualizado e veja o passo a passo de como criar um site do zero.

Perguntas frequentes

Meu site é WordPress em hospedagem compartilhada. Preciso fazer alguma coisa? Sim. A hospedagem aplica a correção, mas é você quem escolhe a versão do PHP do seu site no painel. Se ele ainda estiver no 7.4 ou no 8.1, continua vulnerável. Troque para o 8.3 no MultiPHP Manager e teste as páginas.

Atualizar o PHP pode quebrar o meu site? Pode, principalmente com plugin ou tema muito antigo. Por isso a ordem é: backup, atualizar WordPress, plugins e tema, e só depois trocar o PHP. Se algo quebrar, você volta a versão anterior no mesmo painel em segundos.

Qual versão do PHP devo escolher? A 8.3. Ela já tem a correção (8.3.36) e recebe atualizações de segurança até o fim de 2027. A 8.2 também está corrigida, mas o suporte dela acaba em 31/12/2026.

Desligar o upload de arquivos resolve a falha? Não. Bloquear envios multipart e ajustar a configuração do PHP só reduz o risco por alguns dias. A única correção de verdade é estar numa versão corrigida do PHP.

Como saber se meu site foi invadido? Veja se há redirecionamento estranho no celular, arquivos PHP na pasta de uploads, administradores desconhecidos, aviso do Google no Search Console ou anúncio reprovado por site comprometido. Achou algum desses sinais? Restaure um backup limpo e troque todas as senhas.

📌 Leia também: como criar um site do zero no WordPress

🎯 Quer um especialista olhando a SUA conta?

Na Consultoria Individual da Descomplica Ads você tem acompanhamento de perto: a gente analisa suas campanhas, corrige o que está travando e monta o plano pra você vender mais — sem achismo.

Quero a consultoria individual →