Atualizar o WordPress e os plugins costuma ser a resposta padrão a qualquer alerta de segurança. Desta vez, não resolve. Em 21 de outubro de 2026, o projeto PHP publicou correções para duas falhas críticas na própria linguagem que roda o servidor, apelidadas de PHP2Shell, que permitem executar código remotamente sem login. Com o PHP presente na maior parte da web, o alcance é amplo.
O que foi anunciado
Segundo o comunicado oficial do PHP:
- As falhas são a CVE-2026-109618 e a CVE-2026-109619. No aviso prévio de 20 de outubro, o projeto classificou as duas como críticas, com nota 9.2 no CVSS v4.0.
- As versões corrigidas são PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. A liberação foi antecipada para 21 de outubro depois que detalhes das falhas começaram a circular.
- Estão em risco “todas as instalações de PHP que atendem requisições web”, incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O risco é maior no mod_php, em que um ataque demonstrado roda antes de qualquer código da aplicação.
- O PHP 8.1 e anteriores não recebem mais atualizações do projeto. Pela gravidade, a equipe publicou correções mínimas em código-fonte para 7.4, 8.0 e 8.1, voltadas a quem compila o próprio PHP. O PHP 8.2 deixa de receber correções em 31 de dezembro de 2026.
- Ajustes de configuração reduzem caminhos específicos de ataque, mas, segundo o próprio projeto, só a atualização resolve.
A SecurityWeek informou que empresas de segurança já observaram tentativas de exploração, inclusive antes da correção. Órgãos públicos na Europa tiraram sites do ar por precaução, segundo o Search Engine Journal.
Por que isso importa para quem faz marketing
Segundo a W3Techs, o PHP está em 69,3% dos sites cuja linguagem de servidor é identificada, e o WordPress em 39,6% de todos os sites, dados de 21 de outubro de 2026. A W3Techs não publica contagem absoluta, mas essas fatias colocam a exposição na escala de milhões de sites. Blog, landing page, loja e área de membros feitos em WordPress dependem do PHP do servidor, e é a hospedagem que atualiza essa camada, não o painel do WordPress. Para entender onde cada responsabilidade fica, vale rever o básico de segurança em servidores.
O que isso significa para o mercado
Na leitura do Club Martech, a falha expõe um ponto cego comum em equipes de marketing: o site é tratado como conteúdo, e a infraestrutura como assunto de outro time. Um site comprometido coloca em risco formulários, dados de leads, pixels e tags. Também afeta o SEO: John Mueller, do Google, recomendou no Bluesky, como registrou o Search Engine Roundtable, usar HTTP 503 em vez de deixar o site dar timeout, 404 ou 500 enquanto a atualização é feita.
O que fazer agora
- Conferir a versão do PHP. No WordPress, vá em Ferramentas, Saúde do site, Informação, Servidor. Atualizar WordPress ou plugins não atualiza o PHP.
- Pedir a correção à hospedagem. Confirme que o servidor recebeu uma das versões corrigidas ou um patch equivalente do fornecedor.
- Planejar a saída de versões antigas. Quem está no PHP 8.1 ou anterior precisa de backup e migração, além de perguntar se há correção do fornecedor no meio tempo.
- Se precisar tirar o site do ar, use 503. Configure a resposta fora do PHP, por CDN ou DNS, para não prejudicar a indexação.
- Verificar sinais de invasão. Depois de corrigir, procure contas de administrador desconhecidas e arquivos PHP alterados. A correção não remove uma invasão que já aconteceu.
E agora?
Com os detalhes técnicos circulando e tentativas de ataque já relatadas, a janela entre a correção publicada e a exploração em massa tende a ser curta. A atualização deve entrar na agenda de hoje, e não do próximo sprint. Ferramentas de varredura contínua, como a que noticiamos em Claude Security, ajudam no código da aplicação, mas não substituem atualizar a linguagem do servidor.