A falha no PHP que tirou sites de governo do ar na Europa nesta semana é séria: são duas brechas, apelidadas de PHP2Shell, que permitem a um invasor executar comandos no servidor sem precisar de senha. Se você tem um site em WordPress, o que fazer é simples de dizer e fácil de errar: atualizar plugins não resolve, quem corrige é a hospedagem, e o número da versão do PHP pode enganar. Conferimos o nosso próprio servidor na Hostinger e mostro abaixo como você faz o mesmo no seu.
Qual é a falha no PHP e por que ela é grave
São duas vulnerabilidades no núcleo do PHP, a CVE-2026-109618 e a CVE-2026-109619, ambas com nota 9,2 de 10. Em resumo, a primeira aproveita um erro quando o PHP fica sem memória no meio de uma requisição, e a segunda aproveita restos de uma requisição anterior que ficam na memória do servidor. Nos dois casos, o resultado pode ser a execução remota de código, o pior tipo de falha: alguém de fora roda o que quiser no servidor, com as permissões do site.
O alcance é enorme porque o PHP está por trás de 69,3% dos sites cuja linguagem é conhecida, segundo o W3Techs, incluindo todo site em WordPress. O próprio projeto PHP diz que o risco vale para toda instalação que atende páginas na web: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed, com risco maior no mod_php.
| Item | O que se sabe |
|---|---|
| Falhas | CVE-2026-109618 e CVE-2026-109619 (PHP2Shell), nota 9,2 |
| O que permitem | Executar código no servidor sem login |
| Versões corrigidas | PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 (21/10/2026) |
| PHP 8.1 ou mais antigo | Sem versão oficial nova; só correções mínimas para 7.4, 8.0 e 8.1 |
| Ataques | Tentativas confirmadas pela Cloudflare antes da correção |
| Novidade de 23/10 | CVE-2026-115560, risco considerado baixo, sem correção ainda |
Por que sites saíram do ar e quem descobriu a falha
Os sites saíram do ar por precaução, não porque foram invadidos. Os detalhes vazaram antes da data combinada e a Cloudflare confirmou tentativas de ataque, então órgãos públicos da França, dos Países Baixos e da Finlândia preferiram desligar páginas até instalar a correção. A agência de segurança dos EUA, a CISA, recomendou o mesmo para quem não consegue atualizar na hora.
A descoberta tem uma história curiosa: a falha foi encontrada com ajuda de inteligência artificial. A empresa de segurança Calif usou o GPT-5.6 Sol, da OpenAI, guiado por um pesquisador que conhecia falhas antigas do PHP, e em cerca de duas semanas chegou a um ataque funcional. A Wiz achou as mesmas falhas de forma independente. Uma auditoria de 2024 já tinha apontado indícios no gerenciamento de memória, mas, segundo a PHP Foundation, as propostas de correção esbarravam em risco de quebrar sistemas antigos e na falta de gente e de verba para mexer nessa parte do código.
Falha no PHP: o que fazer se você tem um site
O que resolve é a hospedagem atualizar o PHP do servidor. Atualizar WordPress, tema ou plugin é sempre bom, mas não corrige essa falha, porque ela está no PHP, uma camada abaixo. O seu papel é conferir e cobrar:
- Descubra a versão: no WordPress, vá em Ferramentas › Saúde do site › Informações › Servidor e veja a “Versão do PHP”.
- Se for 8.1 ou mais antiga, troque para 8.3 ou 8.4 no painel da hospedagem (na Hostinger, em Avançado › Configuração do PHP), depois de fazer backup.
- Se for 8.2 a 8.5, confira se o número bate com a versão corrigida. Se não bater, não entre em pânico ainda: leia a próxima seção.
- Pergunte ao suporte, por escrito, se o servidor já recebeu a correção das CVE-2026-109618 e CVE-2026-109619.
- Fique de olho no site por alguns dias: usuários administradores novos, arquivos estranhos e alertas do plugin de segurança.
Se o seu site roda num servidor próprio ou numa VPS, a responsabilidade é sua: atualize o pacote do PHP pela sua distribuição e reinicie o PHP-FPM ou o servidor web. Visitantes comuns não precisam fazer nada; o risco é de quem mantém o site.
A versão do PHP pode enganar na hospedagem compartilhada
Pode, e foi o que vimos no nosso servidor. Muitas hospedagens compartilhadas usam os pacotes de PHP da CloudLinux, que costumam aplicar a correção na versão que você já tem, sem mudar o número principal (o chamado backport). A própria CloudLinux avisa que, nesses casos, conferir só o número da versão não basta.
Na nossa conta da Hostinger, em 23/10/2026, o PHP do site aparece como 8.3.35, e a versão corrigida pelo projeto PHP é a 8.3.36. Olhando mais fundo, o pacote instalado é o 8.3.35-6, recompilado em 21/10, no mesmo dia em que saíram as correções, junto com todas as outras versões do servidor. Uma delas, o 8.5.11-5, é justamente o exemplo que a CloudLinux cita como pacote já corrigido por backport.
| O que conferimos | Resultado no nosso servidor |
|---|---|
| Versão do PHP do site | 8.3.35 (pacote 8.3.35-6) |
| Data de compilação | 21/10/2026, dia das correções |
| Outras versões disponíveis | Todas recompiladas em 21/10 (ex.: 8.5.11-5, citado como corrigido pela CloudLinux) |
| Mitigação recomendada pelo PHP | session.upload_progress.enabled = Off, aplicada no servidor em 23/10 |
Tudo indica que a Hostinger aplicou a correção e ainda ligou a proteção extra que o PHP voltou a recomendar hoje. Mesmo assim, pedimos a confirmação por escrito ao suporte, e é o que eu sugiro a você. Uma mensagem curta resolve: “Meu site usa PHP X.Y. O servidor já recebeu a correção das falhas CVE-2026-109618 e CVE-2026-109619 (PHP2Shell)? Se sim, desde quando?”
A nova falha de 23/10 muda alguma coisa?
Para quase todo mundo, não. Nesta sexta, o PHP publicou um aviso sobre a CVE-2026-115560, que só acontece numa combinação rara de configuração e código: o site precisa trocar o formato das sessões durante a execução e manter ligado o recurso de progresso de envio de arquivos. A recomendação é desligar esse recurso (session.upload_progress.enabled=0) até a próxima atualização regular. Quem já tinha feito isso por causa da falha anterior não precisa fazer mais nada.
O olhar de QA
“Está na versão nova?” é a pergunta errada. A certa é “a correção está lá?”. Em teste, a gente aprende cedo que um número na tela é só um rótulo; o que vale é a evidência de que o problema foi resolvido. Se tivéssemos olhado só o 8.3.35, teríamos concluído que o site estava vulnerável e talvez trocado de versão às pressas, com risco de quebrar algo que estava funcionando.
A outra lição é sobre a IA. Ela não achou a falha sozinha: precisou de um especialista fazendo as perguntas certas. Mas encurtou para duas semanas um problema que estava parado desde 2024, e isso vale para os dois lados. Se a defesa usa IA para achar falhas, quem ataca também usa, e o tempo entre a correção sair e o ataque chegar tende a ficar cada vez menor. Para quem tem site pequeno, a defesa mais barata continua sendo escolher uma hospedagem que atualiza rápido e manter backup em dia.
Perguntas frequentes
Qual é a falha do PHP?
São duas falhas no núcleo do PHP, CVE-2026-109618 e CVE-2026-109619 (PHP2Shell), que permitem executar código no servidor sem login. Foram corrigidas em 21/10/2026 nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
Atualizar o WordPress resolve a falha no PHP?
Não. A falha está no PHP do servidor, abaixo do WordPress. Quem corrige é a hospedagem (ou você, se administra o próprio servidor).
Meu site está na versão 8.3.35. Está vulnerável?
Não dá para saber só pelo número. Em hospedagens que usam pacotes da CloudLinux, a correção pode ter sido aplicada sem mudar a versão. Peça a confirmação ao suporte, citando as duas CVEs.
Quem só visita sites corre risco?
Não diretamente. O alvo é o servidor. O risco para o visitante surge se um site invadido for usado para roubar dados ou espalhar golpes, por isso a correção rápida importa.
Sua hospedagem já avisou sobre a falha no PHP? Conta aqui nos comentários qual é e o que responderam.
Resumo
- A falha no PHP (PHP2Shell) permite executar código no servidor sem senha e já tinha tentativas de ataque antes da correção.
- Quem corrige é a hospedagem; atualizar WordPress e plugins não resolve.
- Veja a versão em Ferramentas › Saúde do site; 8.1 ou anterior, troque para 8.3 ou 8.4.
- Na hospedagem compartilhada, o número pode não mudar: no nosso servidor, o 8.3.35-6 foi recompilado em 21/10 e a mitigação extra já estava ativa.
- Peça ao suporte a confirmação por escrito, citando CVE-2026-109618 e CVE-2026-109619.
Se você está escolhendo onde hospedar, contei como é a Hostinger no dia a dia na análise completa e o que mudou quando ligamos o CDN da Hostinger. Os plugins de segurança que usamos estão na lista de plugins do TechDescomplicado, e quem tem acesso ao terminal pode conferir a versão com os comandos do WP-CLI.
Fontes
- PHP: avisos de segurança de 21/10 e 23/10/2026
- CISA: Critical Vulnerabilities in PHP Require Immediate Patching
- BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws
- CloudLinux: situação dos pacotes alt-php
- Canaltech: IA da OpenAI e a falha no PHP
- Cyber Security Brazil: nova vulnerabilidade de 23/10
- W3Techs: uso do PHP na web
