CVE-2026-109618 em PHP: falha crítica de memória, risco real e atualização urgente

Publicado em 2026-10-27 por frfrand

CVE-2026-109618 explicada: descoberta, PHP afetados, risco de RCE por memória OOM e medidas oficiais de 21 de outubro de 2026.

O que é CVE-2026-109618 e por que se fala dela?

O 21 de outubro de 2026, a equipe do PHP anunciou duas falhas críticas em seu motor. Uma é CVE-2026-109618, relacionada à forma como o PHP gerencia erros de memória durante o processamento de solicitações. Sua consequência potencial é grave: em determinadas situações, uma solicitação enviada pela Internet poderia provocar corrupção de memória e execução remota de código sem fazer login.

Essa falha não nasce de um plugin do WordPress. Está na plataforma PHP sobre a qual trabalham WordPress, Drupal, Joomla e muitos aplicativos próprios. Por isso, revisar apenas os plugins não é suficiente.

Quem encontrou a vulnerabilidade?

A investigação foi divulgada por Wiz Research em coordenação com a equipe de segurança do PHP. A publicação técnica da Wiz e os comunicados dos fornecedores descrevem o trabalho de descoberta, relato e preparação do patch. É um exemplo de como investigações aprofundadas sobre o motor da linguagem podem detectar problemas que não aparecem em uma auditoria do código de um site.

O que ocorre tecnicamente?

Quando uma aplicação recebe uma solicitação, o PHP reserva memória para interpretar dados internos. Se ocorrer um erro de falta de memória (out of memory, OOM) durante esse processo, certa estrutura pode ficar parcialmente inicializada. Depois, durante a limpeza, o programa pode interpretar esses dados incompletos como se fossem válidos. Essa diferença abre uma possibilidade de corrupção de memória.

Como poderia ser explorado?

A ideia geral é provocar condições que levem à falha de memória durante o processamento de uma solicitação e que alterem o comportamento do trabalhador PHP. Em um cenário explorável, o atacante consegue que o processo execute código com as permissões que lhe são atribuídas. Não equivale a que qualquer solicitação assuma o controle do sistema operacional: a viabilidade depende da integração, da configuração, das proteções de memória e do caminho de execução.

Quais servidores estão afetados e qual corre mais risco?

O PHP alertou sobre instalações que atendem solicitações web: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. Sinalizou especial preocupação por mod_php, com um cenário demonstrado de exploração sem autenticação antes que o código da aplicação comece. Outras integrações podem ter requisitos diferentes e devem ser avaliadas individualmente.

Quais são as versões corrigidas?

O fabricante publicou os seguintes primeiros patches em seus branches: - PHP 8.5.12 - PHP 8.4.27 - PHP 8.3.36 - PHP 8.2.35

As versões anteriores desses branches requerem revisão. PHP 8.1 e anteriores estão fora do suporte principal do projeto. Algumas distribuições e provedores LTS incorporaram patches próprios ou retroportados; consulte o boletim exato se utilizar pacotes do sistema. A equipe PHP também ofereceu retroportações mínimas de código para certos branches antigos, o que não os transforma em branches gerais com suporte.

Como verifico se meu WordPress ou minha API PHP estão expostos?

Identifique todos os ambientes: produção, staging, tarefas agendadas, contêineres e servidores esquecidos. php -v ajuda, mas atenção: a versão do CLI pode diferir do PHP-FPM ou Apache, então contraste a configuração real do servidor web. Veja a versão do pacote e a revisão do provedor, como o tráfego chega ao PHP e quais workers continuam em execução após uma atualização.

Como se soluciona e o que faço enquanto atualizo?

A solução completa é instalar o patch e reiniciar ou reimplantar todos os processos relevantes. O PHP publicou medidas temporárias para reduzir vetores específicos, como ajustar limites de entrada e certos parâmetros de memória sob supervisão técnica. São alterações que podem afetar a disponibilidade e não tornam uma instalação segura sem atualizar; não convém copiá-las sem analisar recursos e configuração. Faça backup, staging, atualização, reinício e verificação de resposta dos aplicativos.

Perguntas rápidas

Atualizar o WordPress corrige o CVE? Não. A correção é do runtime PHP, embora depois você deva validar o WordPress.

Com um WAF chega? Não: é uma barreira adicional, não o reparo do motor.

Como saber se já exploraram meu site? Revise sinais de processos inesperados, alterações de arquivos e acessos, mas não afirme comprometimento apenas por usar uma versão afetada. Diante de indícios, preserve evidências e siga um processo de resposta a incidentes.

Fontes verificáveis: Aviso PHP de 21/10/2026 · Boletim AWS · Resposta do Google Cloud · Registro CVE.

Onde as informações são atualizadas e como solicitar orientação?

Em ArduMaker — CVE e suporte mantemos informações para revisar incidentes e canalizar consultas, especialmente em WordPress e nas tecnologias que o executam. Para avaliar um caso concreto, informe tecnologia, versão, sistema operacional, modo de implantação e mensagens de erro relevantes sem publicar credenciais. Um CVE anunciado não significa que todos os sistemas estejam comprometidos.

Revisão editorial: 27 de outubro de 2026. As recomendações podem mudar com novas publicações do fabricante.

Exemplo prático: atualizar PHP em um WordPress com PHP-FPM

Situação: o administrador atualiza o WordPress, mas o site continua usando PHP 8.4.26. Isso não soluciona CVE-2026-109618, porque o falha está no motor PHP. A primeira correção do ramo 8.4 foi 8.4.27.

Em um VPS Ubuntu com PHP-FPM, comece identificando serviços e versão instalada:

php -v
systemctl list-units --type=service 'php*-fpm.service'

Verifique também qual socket FPM o Nginx/Apache utiliza e a versão do worker que serve o site; a CLI pode ser diferente. Instale o pacote corrigido do repositório confiável, reinicie todos os workers afetados e valide as funções críticas.

Antes: site aparentemente atualizado, runtime PHP vulnerável. Depois: runtime corrigido, imagem Docker ou pacote reconstruído se aplicável, workers novos e testes de fumaça de login, formulários e pagamentos.

Qual risco concreto se reduz? A falha de memória durante uma requisição HTTP que poderia abrir uma via de execução de código com as permissões do processo. Não é necessário «testar o exploit» em produção para confirmar que você instalou a versão corrigida.