Vulnerabilidades críticas do PHP: o que os proprietários de sites WordPress precisam saber

English version: Critical PHP Vulnerabilities: What WordPress Site Owners Need to Know

O PHP lançou correções para duas vulnerabilidades críticas em 21 de outubro de 2026. Atualizar o WordPress ou plugins não as corrige. Saiba como verificar se seu ambiente de hospedagem foi afetado e quais medidas tomar.

Resumindo: o que aconteceu?

Em 21 de outubro de 2026, o projeto PHP lançou correções para duas vulnerabilidades críticas no ambiente de execução do PHP, CVE-2026-109618 e CVE-2026-109619, ambas classificadas com nota 9.2 sob o CVSS v4.0. Sob certas condições, elas permitem que um atacante não autenticado execute código no servidor web. Essas falhas estão no próprio PHP, não no núcleo do WordPress, em temas ou plugins, portanto, a correção deve vir de uma versão do PHP atualizada e instalada no servidor.

Ação recomendada: Peça ao seu provedor de hospedagem para confirmar se a versão do PHP que serve o seu site está corrigida contra ambas as vulnerabilidades. Se você gerencia o servidor por conta própria, instale um pacote PHP corrigido e reinicie o PHP.

Os avisos do projeto PHP os denominam RCE via corrupção por falta de memória (CVE-2026-109618) e RCE via estado global obsoleto (CVE-2026-109619). Em ambos os casos, uma requisição que falha no momento errado pode deixar dados internos em um estado inválido que o PHP utiliza posteriormente.

Um ataque bem-sucedido executa código com os privilégios da conta sob a qual o PHP é executado. Dependendo da configuração do servidor, isso pode permitir que um invasor leia wp-config.php e as credenciais do banco de dados nele contidas, acesse ou altere o banco de dados ou modifique os arquivos e o conteúdo do site. Um processo de trabalho do PHP comprometido não concede automaticamente ao invasor acesso root ao servidor.

Situação da exploração (em 21 de outubro de 2026)

A PHP Foundation afirmou que sua equipe de segurança não encontrou nenhuma exploração funcional no código de prova de conceito (PoC) divulgado antes do lançamento, mas que o desenvolvimento da PoC foi acelerado. Em 21 de outubro, a Cloudflare, que se refere às vulnerabilidades como “php2shell”, relatou ter observado tráfego de ataque direcionado a seus clientes e que os invasores estavam modificando seus payloads para tentar burlar suas proteções. Nenhuma das fontes relata uma violação bem-sucedida confirmada. O tráfego de ataque mostra que os invasores estão tentando ativamente, mas isso por si só não confirma que algum site foi comprometido. Atualizaremos esta seção conforme a situação se desenvolva.

Quem pode ser afetado?

Potencialmente, qualquer site hospedado em uma instalação PHP sem as correções necessárias pode ser afetado, independentemente das versões do WordPress, temas e plugins que utiliza. O aviso do projeto PHP abrange todas as instalações do PHP que atendem a requisições web, incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed.

O projeto PHP considera o mod_php o de maior risco, pois demonstrou uma vulnerabilidade que pode ser explorada por uma requisição não autenticada antes da execução de qualquer código da aplicação. Isso não significa que outras configurações sejam seguras. Toda instalação do PHP que realiza requisições web precisa da correção.

Como verificar a versão do PHP e o status dos patches

No painel do WordPress, acesse Ferramentas → Saúde do Site → Informações e expanda a seção Servidor . Ela mostra a versão do PHP e a API SAPI (API do servidor) do PHP que atende ao seu site. A maioria dos painéis de controle de hospedagem exibe as mesmas informações. Se você usa o WP Cerber, WP Cerber → Ferramentas → Diagnóstico também lista a versão do PHP e a API do servidor.

As seguintes versões upstream do projeto PHP contêm as correções:

Importante: estas são versões upstream, não um teste universal de versão mínima. Distribuições Linux e fornecedores comerciais de suporte de longo prazo (LTS) podem fazer o backport das correções para versões anteriores, incluindo versões dos branches 8.2, 8.3 e 8.4 suportados. Por exemplo, o Ubuntu 24.04 LTS mantém seus pacotes PHP 8.3 com uma string de versão baseada em 8.3.6 e inclui ambas as correções na versão 8.3.6-0ubuntu0.24.04.13. A verificação de integridade do site (Site Health) sozinha não consegue determinar se a versão de um fornecedor contém ambas as correções. Verifique o aviso de segurança ou o changelog do pacote do fornecedor, ou pergunte ao seu provedor de hospedagem. Não mude para um repositório de pacotes PHP de terceiros apenas porque sua versão é inferior à versão corrigida upstream.

PHP 7.4, 8.0 e 8.1. Versões corrigidas dessas ramificações, baseadas nos backports do código-fonte do projeto PHP, resolvem ambas as vulnerabilidades com uma mitigação mínima para versões em fim de vida útil, que é mais restrita do que a correção completa lançada na versão 8.2 e posteriores. Com essa mitigação, um processo PHP que fica sem memória é encerrado imediatamente, de modo que um site que exceda seu limite de memória pode exibir um erro genérico do servidor em vez da tela de erro crítico do WordPress. Nessas versões, a ferramenta de Saúde do Site pode mostrar o mesmo número de versão antes e depois da atualização, portanto, confirme a correção com sua hospedagem ou no changelog do pacote. A recomendação continua sendo a atualização para uma ramificação suportada.

O suporte ao PHP 8.2 termina em breve. O suporte de segurança do projeto PHP para o PHP 8.2 termina em 31 de dezembro de 2026. Se você estiver atualizando do PHP 7.4, 8.0 ou 8.1, escolha o PHP 8.3 ou posterior, faça um backup do site primeiro e verifique se seu tema e plugins são compatíveis. Como alternativa, solicite ao seu provedor de hospedagem uma versão corrigida da sua distribuição atual.

Por que a correção deve ser aplicada no servidor?

O código vulnerável faz parte do ambiente de execução PHP que executa o WordPress, e não faz parte do próprio WordPress.

• Atualizar o WordPress não resolve essas vulnerabilidades do PHP. Atualizar o núcleo do WordPress, temas ou plugins não altera o ambiente de execução do PHP.
• Plugins de segurança não conseguem corrigir vulnerabilidades em tempo de execução. Algumas vias de exploração podem ser executadas antes do carregamento do WordPress, impedindo que qualquer plugin inspecione a requisição. Regras de firewall de aplicações web (WAF) no nível de hospedagem ou de rede podem reduzir certas vias de ataque, mas não substituem completamente a aplicação de patches.
• Alterar as configurações dentro do site não é uma solução confiável. O aviso do projeto PHP alerta contra o uso de ini_set() ou arquivos ` .user.ini do FPM para aplicar suas medidas de mitigação de configuração, e o mesmo se aplica a configurações do PHP alteradas em wp-config.php ou por um plugin. Mesmo as medidas em nível de servidor descritas no aviso apenas reduzem a exposição a caminhos de ataque específicos e não tornam uma instalação segura.

Nota para usuários do WP Cerber: o WP Cerber é executado dentro do WordPress. Ele não pode corrigir o PHP e não pode inspecionar uma requisição que acione uma dessas vulnerabilidades antes do carregamento do WordPress. Pelo mesmo motivo, os logs do WP Cerber podem não registrar tal tentativa, portanto, um log sem entradas suspeitas não prova que o site não foi alvo de um ataque. O WP Cerber ainda protege o WordPress no nível da aplicação, mas não substitui a atualização do PHP.

O que fazer agora?

Se você não gerencia o servidor

Isso se aplica a hospedagem compartilhada e gerenciada, onde seu provedor é responsável pela manutenção do ambiente de execução do PHP. Peça a eles que confirmem se a versão do PHP que serve seu site contém correções para ambas as vulnerabilidades. Você pode enviar esta pergunta como está:

A versão do PHP que serve meu site está corrigida contra as vulnerabilidades CVE-2026-109618 e CVE-2026-109619? Os processos PHP relevantes foram reiniciados para carregar a versão corrigida?

Se você gerencia um VPS ou um servidor dedicado

1. Atualize o PHP. Instale a versão corrigida do repositório principal ou um pacote de distribuição ou fornecedor cujo aviso ou registro de alterações confirme que contém ambas as correções.
2. Reinicie o PHP. Reinicie ou recarregue o PHP-FPM, o Apache ou qualquer outro serviço que execute o PHP em seus sites. Os processos em execução continuarão usando o binário antigo até serem reiniciados.
3. Verifique. Consulte o Site Health para confirmar se a versão esperada do PHP está sendo executada em cada site. Em seguida, confirme separadamente, no aviso do fornecedor ou no changelog do pacote, se o pacote instalado contém ambas as correções. O Site Health mostra a versão em execução, mas não pode comprovar que um backport está incluído. O comando php -v pode reportar uma instalação do PHP diferente daquela que está sendo executada no seu site, portanto, não confie apenas nele.

Independentemente do caso, mantenha um backup recente que você saiba que pode restaurar. Se você suspeitar que o site foi comprometido antes da atualização do PHP, lembre-se de que atualizar o PHP não remove malware ou backdoors. Nesse caso, entre em contato primeiro com seu provedor de hospedagem, pois o acesso obtido por meio do PHP pode não se limitar aos arquivos do WordPress. Para limpar a instalação do WordPress em si, consulte nosso guia O que fazer se seu site WordPress foi invadido .

Perguntas frequentes

Meu computador ou navegador corre risco ao visitar um site afetado?

Não diretamente. As vulnerabilidades estão no PHP do servidor web, não nos dispositivos ou navegadores dos visitantes. Um site comprometido por meio delas, no entanto, poderia ser alterado para exibir conteúdo malicioso, portanto, os visitantes podem enfrentar riscos indiretos.

Preciso reinstalar o WordPress?

Não, não para corrigir essas vulnerabilidades. Elas são solucionadas atualizando o PHP no servidor, e reinstalar o WordPress não altera o PHP. Uma reinstalação ainda pode ser necessária para limpar um site que foi comprometido.

Posso resolver isso sem a ajuda do meu provedor de hospedagem?

Isso depende de você controlar o ambiente de execução do PHP. Em um VPS ou servidor dedicado, você pode instalar os pacotes corrigidos por conta própria. Em hospedagem compartilhada ou gerenciada, o provedor controla o PHP. Muitos painéis de controle permitem que você altere a versão do PHP de um site, mas se essa versão estará corrigida ainda depende do provedor.

Fontes

• Projeto PHP, Aviso de segurança: Vulnerabilidades críticas de execução remota de código, atualize agora , 21 de outubro de 2026.
• Projeto PHP, GHSA-w8hw-w9fx-j79w: RCE via corrupção OOM (CVE-2026-109618) , 21 de outubro de 2026.
• Projeto PHP, GHSA-6wmf-4rv5-p3rp: RCE via estado global obsoleto (CVE-2026-109619) , 21 de outubro de 2026.
• Fundação PHP, Lançamento de segurança do PHP de hoje e como estamos fortalecendo a segurança do PHP , 21 de outubro de 2026.
• Projeto PHP, Versões suportadas .
• Commit 712e60f do php-src: Evitar corrupção de estado por meio de resgate , a mitigação mínima para versões em fim de vida útil.
• Repositório RPM de Remi, changelog do php74-php , entrada para 7.4.33-31, 21 de outubro de 2026.
• Ubuntu, páginas de status de segurança para CVE-2026-109618 e CVE-2026-109619 , 21 de outubro de 2026.
• Cloudflare implementa proteções contra a vulnerabilidade php2shell , 21 de outubro de 2026.