Duas falhas anunciadas em 21/10/2026 podem permitir rodar código, sem login, em servidor que ainda não recebeu a correção, e a correção não vem por plugin nem por tema: vem por uma versão nova do PHP, que quase nunca é você quem instala. O que perguntar à hospedagem, como conferir a resposta e o que fazer se o seu site ainda roda PHP 8.1 ou anterior.
Afinal, o que aconteceu com o PHP?
PHP é a linguagem em que o WordPress roda, e com ele o WooCommerce e muitos outros sistemas de site e de loja. Ele não aparece para quem navega: fica no servidor, montando cada página antes de ela chegar ao navegador. Quando o PHP tem uma falha, todo site que roda sobre ele herda a falha, por mais atualizado que o site esteja.
Em 21/10/2026 a equipe do PHP publicou a correção de duas falhas, registradas como CVE-2026-109618 e CVE-2026-109619 (CVE é o registro público de uma falha de segurança, com número único). As duas podem permitir executar código no servidor sem login, em servidor sem a correção e sob certas condições. A nota oficial de gravidade é 9,2 numa escala que vai até 10 (CVSS 4.0). Na véspera do anúncio circulou a nota 10,0, que estava errada, depois que os identificadores vazaram antes da data combinada, como explicou a PHP Foundation.
A correção são quatro versões novas: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Qualquer versão anterior a essas está vulnerável, a menos que a hospedagem tenha portado a correção para a versão que usa. Executar código, aqui, é rodar comandos no servidor com as permissões da conta do site. O setor apelidou as duas falhas de PHP2Shell.
A falha não é só teoria. A watchTowr, empresa de segurança que mantém uma rede de servidores-isca para observar ataques, registrou tentativas reais de exploração desde o dia 21. Sobre as provas de conceito: no dia do anúncio, a equipe do PHP não tinha identificado nenhuma funcional. Depois do vazamento, um vídeo com prova de conceito saiu por engano, outras apareceram, e uma imagem já corrigida foi publicada antes da data, o que dá a quem ataca material para estudar a correção. Até 23/10 o catálogo de falhas exploradas do governo americano (o KEV, da CISA) ainda não listava as duas. Não espere por esse aviso para agir.
Por que atualizar o WordPress não resolve
A falha é do PHP. O WordPress não tem o que corrigir, e o WordPress.org informou que nenhuma atualização do WordPress é necessária nem está planejada para isso. Manter WordPress, tema e plugins atualizados continua sendo obrigação de rotina. Contra esta falha, não protege.
Ela atinge o PHP em qualquer forma de execução: PHP-FPM, Apache com mod_php, CGI, LiteSpeed e FrankenPHP. Esses nomes são os jeitos de o servidor rodar o PHP; você não escolheu nenhum deles, a hospedagem escolheu. O pior caso é o mod_php, em que o ataque pode ter sucesso antes de qualquer código do site rodar. Um plugin de segurança instalado no WordPress também é código do site, então, nesse caminho, ele não chega a entrar em ação.
Há pontos que as fontes ainda não esclarecem, e prefiro dizer isso a preencher a lacuna: qual das duas falhas está sendo explorada, em que volume e por quem; e se um WordPress sem plugin vulnerável é alcançável. Enquanto não está claro, trate o seu site como alcançável.
Quem atualiza o PHP do seu site
Esse é o ponto que separa quem resolve rápido de quem fica exposto sem saber. Quem troca a versão do PHP é quem administra o servidor, e isso depende de como o seu site está hospedado.
- Hospedagem compartilhada ou gerenciada, o caso de quem paga um plano mensal e nunca viu o servidor: a hospedagem atualiza. Pelo painel do WordPress você não tem como fazer isso, mas muitos planos deixam escolher a versão do PHP no painel da própria hospedagem.
- VPS ou servidor próprio, uma máquina alugada ou sua, que alguém configura: ninguém faz por você. Quem administra, você ou quem você contratou, precisa aplicar a atualização.
- Plataforma fechada, em que você nunca escolheu versão de PHP nem servidor: a responsabilidade é da plataforma, e vale perguntar ao suporte dela se o sistema usa PHP e se a correção foi aplicada.
Se você não sabe em qual caso está, a pergunta da próxima seção resolve as duas dúvidas de uma vez.
A pergunta para a hospedagem, por escrito
Abra um chamado ou mande um e-mail. Por escrito, para a resposta ficar registrada com data. A pergunta é esta:
Vocês aplicaram a correção do PHP de 21/10/2026 (CVE-2026-109618 e CVE-2026-109619)? Qual versão do PHP o meu site está rodando?
Três respostas são possíveis. “Sim, aplicada em tal data”: guarde a resposta e siga para a conferência abaixo. “Estamos avaliando” ou “em breve”: peça o prazo, também por escrito, e volte no dia marcado. Resposta vaga ou nenhuma resposta: insista, anote a data em que perguntou e guarde o silêncio como informação sobre a hospedagem.
Uma resposta merece desconfiança: “estamos protegidos por firewall”. Firewall é camada, não correção. Peça a data em que o PHP foi atualizado e se os processos foram reiniciados. E lembre que estar corrigido agora não prova que nada aconteceu antes: as tentativas reais começaram em 21/10. Se a hospedagem demorou, peça também uma checagem de arquivos novos e de usuários administradores que você não reconhece.
Como conferir a versão, e a pegadinha do número
No WordPress, o caminho é Ferramentas, Diagnóstico do site, aba Informação, seção Servidor. Você precisa ser administrador do site para ver essa tela. Lá aparece a versão do PHP em uso. Versão corrigida é 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou uma versão mais nova da mesma linha.
A pegadinha: algumas distribuições de servidor aplicam a correção sem mudar o número da versão. A CloudLinux, por exemplo, publica o PHP 8.4 corrigido como 8.4.26-2, e não 8.4.27, e diz que o pacote tem a correção das duas falhas mesmo com o número mais baixo. Um número novo prova que está corrigido. Um número antigo não prova que a hospedagem atrasou; prova que você precisa da resposta por escrito. A hospedagem confere isso no registro de mudanças do pacote, procurando os dois CVE.
Se o site roda PHP 8.1 ou anterior
PHP 8.1, 8.0, 7.4 e anteriores não têm versão oficial corrigida, informa a watchTowr. A equipe do PHP publicou só correções mínimas de código-fonte, para quem compila o próprio PHP, e distribuições e fornecedores de suporte estendido podem ter pacotes próprios, que dependem de quem mantém o servidor. PHP 7.3 e anteriores, incluindo o 5, ficam sem correção da equipe do PHP.
Se o seu site está numa dessas versões, a conversa com a hospedagem muda de assunto: peça, por escrito e esta semana, a migração para uma versão com suporte ou a correção portada para a versão que você usa. Prefira o PHP 8.3 ou mais novo (8.4 ou 8.5, se o tema e os plugins aguentarem): o PHP 8.2 só recebe correção de segurança até 31/12/2026, então serve de ponte, não de destino. Antes, backup completo e teste numa cópia do site, porque a troca de versão pode quebrar tema ou plugin antigo. É trabalho, e é o único caminho com correção oficial.
Se o servidor é seu e você não consegue migrar, o WordPress.org cita a orientação do centro de segurança cibernética do Reino Unido (NCSC): considerar tirar o sistema do ar até a mitigação completa.
Paliativos e camadas extras: ajudam, não substituem
O aviso do PHP lista desligar a opção session.upload_progress.enabled como medida parcial para a CVE-2026-109619: ela bloqueia os caminhos de sessão confirmados, não outras variantes. Em 23/10 o PHP recomendou aplicar essa medida, ou mantê-la se já estiver aplicada, até o próximo release regular, por causa de uma terceira falha, a CVE-2026-115560, cujo aviso completo sai com esse release. O PHP avisa que a opção só vale se aplicada no php.ini, no pool do servidor ou na configuração do servidor web, e que ini_set() e .user.ini não servem. Ou seja: é pedido para a hospedagem, não tentativa do dono do site, e não substitui a atualização.
Sobre as camadas na frente do site: a Cloudflare ativou regras contra a falha em todos os planos com WAF (firewall de aplicação, um filtro que examina o tráfego antes de ele chegar ao servidor). Se o seu site passa pela Cloudflare, confira se as regras estão em modo de bloqueio, e não só de registro, como recomenda o Codeable. No servidor, a CloudLinux, que mantém o Imunify360, diz que as regras de firewall já bloqueiam padrões conhecidos de ataque, inclusive no LiteSpeed nas versões mais novas do conjunto de regras, mas que nenhuma bloqueia ainda o caminho de falta de memória da primeira falha. É proteção parcial: reduz, não corrige.
O que fica desta semana
- A falha é do PHP. Mexer em plugin e tema não resolve.
- Descubra quem atualiza o PHP do seu site: hospedagem, você ou a plataforma.
- Pergunte por escrito se a correção de 21/10/2026 foi aplicada e qual versão está rodando.
- Confira em Diagnóstico do site, lembrando que número antigo não prova atraso.
- Se estiver em PHP 8.1 ou anterior, migre para 8.3 ou mais novo, ou peça a correção portada por escrito, esta semana, com backup e teste.
- WAF e regras extras são camadas. A atualização é a correção.
Já escrevi que loja virtual é operação viva. Esta semana, a operação é uma pergunta por escrito e a leitura atenta da resposta.
Leia também: Golpe do QR Code do Pix: 90 lojas virtuais infectadas e o que isso revela sobre manutenção de e-commerce, outro caso em que o problema mora numa camada que o dono da loja não enxerga e por isso não cobra.
Fontes: PHP Foundation, “Today’s PHP Security Release” (21/10/2026) · PHP.net, avisos de 21 e 23/10/2026 · WordPress.org · watchTowr, FAQ do PHP2Shell (CVE-2026-109618) · CloudLinux · Codeable, o que donos de WordPress devem fazer
