Falha no PHP (PHP2Shell): seu site está em risco? O que fazer agora

Não é falha do WordPress, nem de plugin. É no próprio PHP, a linguagem que roda por trás de boa parte dos sites do mundo. Por isso o alcance é tão grande. Vou direto ao que importa para quem tem site e não é programador: o que aconteceu, como saber se você está exposto e o que cobrar da sua hospedagem ainda hoje.

O que aconteceu

Em 21 de outubro de 2026, o projeto PHP publicou uma atualização de emergência para duas falhas críticas, a CVE-2026-109618 e a CVE-2026-109619. Os pesquisadores apelidaram a dupla de PHP2Shell.

Em português simples: um atacante consegue mandar uma requisição para o seu site e executar comandos no servidor, sem login e sem senha. O nome técnico é execução remota de código. O próprio PHP deu nota 9,2 de 10 às duas falhas, na escala CVSS 4.0.

Tem um detalhe que pesa. O ataque acontece antes de o código do seu site começar a rodar. A Datadog reproduziu a falha e confirmou: nenhuma tela de login do site consegue barrar, porque o PHP processa a requisição maliciosa antes.

No mesmo dia, a CISA, agência de cibersegurança do governo dos Estados Unidos, publicou o alerta "Critical Vulnerabilities in PHP Require Immediate Patching". O título já diz a ordem: corrigir agora.

As datas explicam a pressa:

• 17 de outubro. A Amazon (AWS) registrou a primeira tentativa de ataque, quatro dias antes de a correção existir.
• 21 de outubro. Saíram as versões corrigidas. Quando a CISA publicou o alerta, ainda não tinha visto nenhum ataque bem-sucedido. Mas as tentativas já estavam acontecendo.
• 23 de outubro. A Unit 42, da Palo Alto Networks, relatou o primeiro caso de invasão confirmado: um órgão de governo na Europa.

Quem está exposto

Toda instalação de PHP que responde a visitas na web, segundo o próprio PHP. Isso vale para os jeitos mais comuns de rodar PHP num servidor: Apache com mod_php (o de maior risco, segundo o PHP), PHP-FPM, php-cgi, FrankenPHP e LiteSpeed. Se esses nomes não dizem nada para você, tudo bem. Quer dizer que praticamente qualquer configuração está na lista.

As falhas vêm desde o PHP 5.4, de mais de dez anos atrás, até o 8.5, o mais recente.

Na prática, está exposto quem tem:

• Site em WordPress. O WordPress roda em PHP. Loja em WooCommerce também.
• Site em Joomla, Drupal, Magento ou Moodle. Todos rodam em PHP.
• Sistema sob medida feito em PHP, como área do cliente, painel interno ou loja própria.
• Site antigo esquecido. Aquela página de campanha num subdomínio, ou o site velho que ninguém desligou na outra hospedagem.

O tamanho disso: segundo a W3Techs, em outubro de 2026, o PHP aparece em 69,3% dos sites cuja linguagem de servidor dá para identificar, e o WordPress sozinho está em 39,6% de todos os sites. A Unit 42, equipe de pesquisa da Palo Alto Networks, contou mais de 22,6 milhões de instâncias expostas na internet e potencialmente vulneráveis.

Ninguém precisa escolher o seu site a dedo. Quando uma falha dessas fica pública, robôs passam a varrer a internet atrás de servidores sem a correção. Ser uma marca conhecida ou não muda pouco.

Como saber a versão do PHP do seu site

São três caminhos, do mais rápido ao mais garantido.

1. Pelo próprio WordPress. Entre no painel e vá em Ferramentas, depois Saúde do site, aba Informações, seção Servidor. A linha "Versão do PHP" mostra o número.

2. Pelo painel da hospedagem. Em painéis como cPanel, Plesk e hPanel, procure algo como "Versão do PHP", "Configuração do PHP" ou "MultiPHP". Ali aparece a versão que o site usa.

3. Pelo suporte da hospedagem. É o caminho mais seguro, porque o número sozinho pode enganar. Muitos painéis mostram só "8.3", sem o final. E distribuições Linux e fornecedores de suporte estendido costumam aplicar a correção sem mudar o número da versão. Então a pergunta certa não é só "qual a versão". É "a correção já foi aplicada".

Mensagem pronta para mandar hoje:

Olá. Meu site é (seu endereço). Vocês já aplicaram no PHP do meu plano a correção das falhas CVE-2026-109618 e CVE-2026-109619, a PHP2Shell, publicada em 21/10/2026? Qual versão do PHP meu site usa hoje, com o número completo?

Como ler a resposta:

• 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou mais novo dentro da mesma série: corrigido.
• 8.2, 8.3, 8.4 ou 8.5 com número final menor: precisa atualizar, a não ser que a hospedagem confirme por escrito que aplicou a correção por conta própria.
• 8.1, 8.0, 7.x ou mais antigo: o projeto PHP não atualiza mais essas versões. Leia o próximo bloco com atenção.

Ferramentas online que tentam ler a versão pelo endereço do site ajudam pouco aqui. Muitos servidores escondem a versão. E, quando mostram, não dizem se a correção foi aplicada por fora.

O que fazer hoje

Se você está em hospedagem compartilhada, o plano comum em que você não cuida do servidor: em geral, quem atualiza o PHP é a hospedagem. Seu trabalho é cobrar e confirmar. Mande a mensagem acima e só sossegue com um "sim, aplicado" por escrito.

Se o seu site usa PHP 8.1 ou mais antigo: não existe atualização oficial. O projeto PHP diz que essas versões não recebem mais correções e orienta falar com o fornecedor ou subir para uma versão suportada. A CISA foi mais dura: quem não consegue atualizar agora, ou ainda usa PHP 8.1 ou anterior, deve tirar o sistema do ar até corrigir. O caminho é subir o site para uma versão suportada, como 8.4 ou 8.5. Não pare no 8.2: ele deixa de receber correções em 31 de dezembro de 2026. Num WordPress antigo, a troca pode quebrar tema ou plugin velho. Faça backup e teste antes, de preferência numa cópia do site.

Se você tem servidor próprio, VPS ou nuvem: quem cuida dele precisa atualizar o PHP para a versão corrigida e reiniciar todos os processos do PHP. Um cuidado que a Datadog destaca: a versão que aparece no terminal pode não ser a mesma que atende o site. Confira a que o site realmente usa.

Peça também um ajuste extra. Em 23 de outubro, o PHP recomendou desligar uma função pouco usada, a session.upload_progress, até a próxima versão regular, para fechar um caminho de ataque improvável. Isso não substitui a atualização. Soma a ela.

Firewall de aplicação ajuda, mas não corrige. A CISA diz que um firewall de aplicação web pode dar alguma proteção enquanto a atualização não sai. Alguma. A correção continua sendo atualizar o PHP.

O que não fazer

• Não confie só no paliativo. Circulam ajustes de configuração, como desligar o session.upload_progress ou mexer no memory_limit. O próprio PHP avisa que eles reduzem a exposição a caminhos específicos, mas não deixam a instalação segura. A Datadog chegou à mesma conclusão. Só a atualização resolve.
• Não ache que plugin de segurança resolve. O ataque acontece antes de o WordPress começar a rodar. Um plugin dentro do WordPress não tem como barrar.
• Não ache que atualizar o WordPress resolve. A falha está no PHP, no servidor. Manter WordPress, tema e plugins em dia continua sendo boa prática, mas não fecha esta porta.
• Não espere a próxima manutenção. As tentativas de ataque começaram antes mesmo de a correção existir.
• Não cole no servidor comando achado em fórum. Em toda crise aparece correção milagrosa em grupo e rede social. Atualize pelos canais oficiais da hospedagem ou do sistema operacional.
• Não entre em pânico nem refaça o site. Na maior parte dos casos, é uma atualização no servidor. O site continua o mesmo.

Próximo passo

Se você não sabe onde seu site está hospedado, quem tem o acesso ao painel ou qual versão do PHP ele usa, isso já é um sinal. Me chama no WhatsApp que eu te ajudo a descobrir e a cobrar a hospedagem certa. Os sites one-page que a 27LAB entrega hoje são páginas estáticas, sem PHP rodando no servidor, e ficam fora da PHP2Shell. Para ver a máquina de IA da 27LAB funcionando todo dia, siga o @bnd.g no Instagram. Ou fala comigo pelo LinkedIn, Bernardo Garcia.

Fontes

• PHP: alerta de segurança de 21/10/2026 e aviso de 23/10/2026
• PHP, alertas técnicos: CVE-2026-109618 e CVE-2026-109619
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• Palo Alto Networks Unit 42: Threat Brief sobre a PHP2Shell
• Datadog Security Labs: PHP2Shell
• The Hacker News: correções de emergência e tentativa de ataque em 17/10
• Também cobriram: Rapid7, Qualys, Sansec e Wiz
• W3Techs, outubro de 2026: uso do PHP e uso do WordPress