Em 21 de outubro de 2026, o projeto PHP publicou uma atualização de emergência para corrigir duas falhas críticas, registradas como CVE-2026-109618 e CVE-2026-109619. As duas receberam nota 9,2 de 10 (CVSS v4.0) e podem permitir que alguém execute código no servidor sem usuário e sem senha.
Resposta rápida: se o seu site roda em PHP (e todo site WordPress roda), a versão do PHP precisa ser 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ou mais nova. Atualizar o WordPress e os plugins não resolve: a correção é no servidor. Quem cuida do PHP é a sua hospedagem ou quem administra o seu servidor.
Clientes da W2 Websites: todos os nossos servidores foram atualizados em menos de 24 horas após o alerta, sem tirar nenhum site do ar, inclusive os que ainda usam versões antigas do PHP. Você não precisa fazer nada.
O que são as duas falhas, sem tecniquês
O PHP é a linguagem que monta as páginas do site no servidor a cada visita. As duas falhas estão na forma como ele organiza a memória entre uma visita e outra:
- CVE-2026-109618: quando o PHP fica sem memória no meio de uma requisição, alguns dados internos ficam “pela metade”. Na limpeza, ele pode tratar esses dados como válidos, e isso abre caminho para executar código.
- CVE-2026-109619: uma informação de uma visita pode sobrar na memória depois de liberada e ser reaproveitada pela visita seguinte, antes de ser zerada.
Na prática, um invasor pode montar uma requisição feita para provocar essas situações. O ponto mais grave: o ataque acontece antes de o WordPress carregar. Plugin de segurança, senha forte e WordPress atualizado não chegam a entrar em ação.
Isso é ameaça real ou exagero?
É real. A equipe do Wordfence, um dos plugins de segurança para WordPress mais usados, testou as duas falhas em laboratório:
- na CVE-2026-109619, conseguiu executar código num PHP configurado de um jeito específico; no PHP comum, o mesmo teste derrubou o processo;
- na CVE-2026-109618, o PHP vulnerável falhou numa requisição que o PHP corrigido tratou normalmente.
A conclusão deles: o ataque pode precisar ser adaptado a cada servidor, mas isso não torna seguro um servidor sem a correção. O próprio WordPress.org publicou um aviso pedindo a atualização imediata, e algumas agências nacionais de segurança recomendam até tirar o sistema do ar quando não for possível corrigir logo.
Quem está exposto
| Situação | Risco | O que fazer |
|---|---|---|
| PHP 8.2, 8.3, 8.4 ou 8.5 sem a versão corrigida | Alto | Atualizar e reiniciar o PHP |
| PHP 8.1, 8.0, 7.4 ou mais antigo | Alto, e não haverá versão nova oficial | Migrar para 8.3 ou aplicar o patch publicado pelo time do PHP (só quem compila o PHP) |
| Hospedagem compartilhada | Depende da hospedagem | Pedir confirmação por escrito de que a correção foi instalada |
| Servidor próprio (VPS, nuvem, dedicado) | Alto até alguém atualizar | Atualizar, reiniciar todos os processos do PHP, recriar containers |
O comunicado oficial do PHP diz que o risco é maior no mod_php (PHP rodando dentro do Apache), mas nenhum modo de execução está livre.
Como descobrir a versão do PHP do seu site
- No painel do WordPress, vá em Ferramentas → Saúde do site → Informações.
- Abra a seção Servidor e veja a linha Versão do PHP.
- Compare com a lista: 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 (ou mais nova dentro da mesma série).
Também dá para ver no painel da hospedagem (cPanel, DirectAdmin, hPanel etc.), em algo como “Selecionar versão do PHP”.
Atenção a um detalhe que confunde muita gente: o número da versão nem sempre muda. Distribuições Linux e alguns fornecedores aplicam a correção numa versão antiga e mantêm o mesmo número. O mesmo vale para o 7.4 e o 8.1 corrigidos com o patch oficial: continuam aparecendo como 7.4.33 e 8.1.34. Nesses casos, quem confirma a correção é a hospedagem, pela data de compilação ou pelo aviso de segurança dela.
O que fazer agora, conforme o tipo de hospedagem
Hospedagem compartilhada ou gerenciada
Quem atualiza o PHP é a hospedagem, não você. Abra um chamado e peça uma confirmação específica do seu servidor:
- se as duas correções (CVE-2026-109618 e CVE-2026-109619) foram instaladas;
- se o PHP foi reiniciado depois disso.
Muitas hospedagens também ativaram regras extras de firewall (WAF) contra o ataque. Isso ajuda, mas não substitui a atualização.
Servidor próprio: VPS, nuvem ou dedicado
- Backup do site e do banco antes de mexer.
- Atualize o PHP para a versão corrigida da sua série.
- Reinicie o PHP-FPM, o Apache ou o LiteSpeed. O processo que já está rodando continua com o código antigo na memória até ser recarregado.
- Se usa Docker, recrie as imagens a partir de uma base atualizada.
- Teste as páginas principais: formulários, carrinho, login, área do cliente.
- Confira o painel de administração do servidor. Alguns painéis rodam com um PHP próprio, separado do PHP dos sites, que também precisa de correção ou não deve ficar aberto para a internet.
Não dá para atualizar hoje?
O comunicado do PHP lista medidas que reduzem a exposição, mas avisa que não deixam a instalação segura:
- para a CVE-2026-109619: desligar
session.upload_progress.enablednophp.iniou na configuração do pool e reiniciar o PHP; - para a CVE-2026-109618: ajustes de
memory_limitepost_max_sizefeitos no servidor (não no.htaccessnem comini_set()).
São ajustes de servidor e podem afetar o funcionamento do site. Se não tiver certeza, peça a quem administra o servidor.
Como foi do nosso lado
Na W2 Websites, o alerta chegou na tarde de 21 de outubro. Nos servidores que administramos:
- atualizamos o PHP 8.3 para a versão 8.3.36 e o 8.4 para a 8.4.27;
- aplicamos o patch oficial do time do PHP nas versões 7.4 e 8.1, que alguns sites ainda usam por compatibilidade;
- recarregamos todos os processos do PHP e conferimos, um por um, que nenhum continuava rodando o código antigo;
- tudo isso sem tirar nenhum site do ar.
Também atendemos clientes que estão em outras hospedagens. Num servidor em nuvem, o PHP do site foi de 8.2.32 para 8.2.35, com backup completo antes, 14 páginas testadas antes e depois e o painel de administração do servidor (que usava um PHP antigo sem correção) retirado do acesso público. Num site em hospedagem compartilhada, onde a atualização depende da própria hospedagem, pedimos a confirmação por escrito e, enquanto isso, bloqueamos a execução de PHP na pasta de uploads e desativamos a edição de código pelo painel do WordPress.
E se o site já tiver sido atacado?
Corrigir o PHP fecha a porta, mas não remove quem já entrou. Fique atento a:
- arquivos
.phpnovos dentro dewp-content/uploads; - usuários administradores que você não criou;
- redirecionamentos para sites de apostas ou golpes, às vezes só no celular ou só para quem vem do Google;
- avisos de “site perigoso” no navegador ou no Search Console.
Se notar algo assim, siga o nosso guia site WordPress hackeado: o que fazer agora. Uma invasão pode não deixar sinal nenhum na tela.
Perguntas frequentes
Preciso atualizar o WordPress por causa dessa falha?
Não. A falha é no PHP, não no WordPress, e o WordPress.org confirmou que não haverá atualização do WordPress para isso. Manter WordPress e plugins atualizados continua importante, mas não corrige essas duas falhas.
Meu site está na versão 7.4. Estou vulnerável?
Sim, a menos que a hospedagem tenha aplicado o patch publicado pelo time do PHP para essa versão. O PHP 7.4 não recebe versões novas desde 2022. O caminho definitivo é migrar para o PHP 8.3, testando o site antes.
A hospedagem disse que tem firewall. Basta?
Não. O WAF pode bloquear as tentativas conhecidas, mas o próprio comunicado do PHP diz que só a atualização resolve por completo.
Atualizar o PHP pode quebrar o site?
Dentro da mesma série (8.2.x para 8.2.35, por exemplo), é raro. Mudar de série (7.4 para 8.3) pode quebrar tema ou plugin antigo. Por isso, backup antes e teste depois.
Como saber se a minha hospedagem já corrigiu?
Pergunte por escrito, citando os dois códigos (CVE-2026-109618 e CVE-2026-109619), e peça a confirmação de que o PHP foi reiniciado.
Precisa de ajuda?
Se o seu site não está com a W2 e você não sabe se o PHP já foi corrigido, nós verificamos o servidor, fazemos backup, atualizamos e testamos as páginas principais. Funciona em qualquer hospedagem, inclusive servidor próprio.
- Site já invadido: remoção de malware, a partir de R$ 497.
- Para não depender de alerta no e-mail: manutenção de sites, a partir de R$ 200/mês, com atualizações e acompanhamento de segurança.
- Hospedagem já atualizada: hospedagem de sites, a partir de R$ 49/mês, ou servidor dedicado gerenciado.
