Vulnerabilidades PHP CVE-2026-109618 e CVE-2026-109619

Foram divulgadas as vulnerabilidades CVE-2026-109618 e CVE-2026-109619, que permitem a execução remota de código (RCE) sem autenticação durante o encerramento anómalo e a gestão do estado dos pedidos no motor principal do PHP. O problema não está em aplicações Web como WordPress ou GNUBoard, mas numa falha de corrupção de memória e Use-After-Free no próprio motor de execução do PHP. Para resolver o problema, actualize imediatamente para versões com os patches de segurança, como PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, e reinicie os processos de trabalho.

Vulnerabilidade do motor PHP que não pode ser bloqueada apenas com a actualização da aplicação Web

Em 21 de Outubro de 2026 (UTC), a equipa de desenvolvimento do PHP anunciou duas vulnerabilidades de segurança classificadas com 9,2 pontos de risco segundo o CVSS v4.0. Um atacante pode executar código arbitrário no servidor apenas enviando um pedido HTTP manipulado, sem passar por qualquer processo de início de sessão.

A falha ocorre na camada principal do PHP, responsável por analisar os pedidos Web e libertar memória. Por isso, mesmo que o CMS ou os plug-ins do site estejam actualizados, o sistema continua exposto se o próprio runtime do PHP estiver desactualizado. Em particular, confirmou-se que, em ambientes com a configuração predefinida mod_php do Apache, é possível executar código através de um único pedido, antes mesmo de o código da aplicação Web ser executado.

Se o ataque for bem-sucedido, o intruso obtém as permissões da conta do sistema onde o processo PHP é executado. Isto não significa que obtenha imediatamente privilégios de root, mas pode criar uma webshell no directório raiz da Web ou consultar as credenciais de acesso à base de dados guardadas nos ficheiros de configuração, exfiltrando ou alterando dados internos. Se vários sites no mesmo servidor partilharem a mesma conta de execução do PHP-FPM, existe também o risco de o comprometimento de um site se propagar a outros sites no servidor.

Princípio da corrupção de memória e do Use-After-Free durante encerramentos anómalos

As duas vulnerabilidades ocorrem porque a memória não é libertada de forma segura quando surge uma situação excepcional durante o processamento de um pedido. As condições de ocorrência e o funcionamento interno são diferentes em cada caso.

CVE-2026-109618 (corrupção de memória durante o processamento de um limite de memória excedido): quando excede o limite de memória permitido (Out-Of-Memory) durante o processamento de um pedido, o PHP chama longjmp() para interromper imediatamente a execução. Se o processamento parar enquanto as estruturas de dados internas do pedido ainda não estiverem totalmente inicializadas, o estado incompleto pode permanecer sem ser revertido. A rotina de limpeza (cleanup) do pedido executada posteriormente confia nessa memória não inicializada como se contivesse dados válidos e acede-lhe, o que pode provocar corrupção de memória e execução remota de código.

CVE-2026-109619 (Use-After-Free ao referenciar memória libertada de um pedido anterior): alguns estados globais internos do PHP ou estados de tratamento de erros apontam temporariamente para uma área de memória pertencente a um único pedido. Quando um pedido termina de forma anómala devido a um erro fatal (fatal error) ou falta de memória, a memória pode ser efectivamente libertada, mas a referência de ponteiro interno que aponta para ela pode não ser inicializada. Em ambientes que reutilizam processos de trabalho, como PHP-FPM ou mod_php, quando o mesmo processo recebe e trata o pedido HTTP seguinte, volta a ler a área de memória já libertada (Use-After-Free), criando um caminho para a execução de código.

O aviso de segurança oficial aponta como caminhos confirmados da CVE-2026-109619 a funcionalidade de progresso de carregamento de sessões (session.upload_progress), os avisos de configuração apresentados antes da inicialização do pedido e os backtraces de erros fatais do PHP 8.5 (fatal_error_backtraces). No entanto, esclarece que podem permanecer outros caminhos alternativos mesmo que estes sejam bloqueados.

Estado dos patches por versão do PHP e âmbito do impacto conforme o ambiente de execução

São afectadas as versões PHP 8.2 a 8.5 anteriores às versões corrigidas. A versão 8.1 e anteriores, que já não são suportadas, não fazem parte das actualizações oficiais do projecto PHP. Em termos de métodos de execução, estão abrangidas todas as instalações que processam pedidos Web, incluindo PHP-FPM, mod_php, php-cgi, FrankenPHP e LiteSpeed; o aviso oficial considera que o risco é maior no mod_php. A Red Hat classifica o PHP-FPM como condicionalmente afectado através de caminhos ao nível da aplicação.

Ambiente verificado: em 22 de Outubro de 2026, num servidor Linux que utiliza o repositório Remi, actualizámos o PHP 8.4.26 para 8.4.27 e verificámos o reinício dos processos de trabalho do PHP-FPM e a aplicação aos pedidos Web.

Procedimento para actualizar pacotes e aplicar definições de mitigação do PHP-FPM

A equipa de desenvolvimento do PHP informa que as alterações de configuração, por si só, não conseguem bloquear todos os caminhos de ataque e que a actualização para uma versão corrigida é a única solução completa. Mesmo depois da actualização, podem ser aplicadas medidas de mitigação que desactivem funcionalidades desnecessárias, reduzindo a superfície de ataque.

1. Instalar a actualização dos pacotes PHP
   Através do gestor de pacotes do sistema operativo, actualize os pacotes para a versão corrigida da família PHP utilizada (por exemplo, 8.4.27 na família 8.4). Depois da instalação, confirme primeiro a versão da CLI no terminal.

   php -v

   Ao executar o comando, serão apresentados no ecra o número da versão actualizada e a data de compilação, como em PHP 8.4.27 (cli). No entanto, a versão da CLI pode ser diferente da versão do processo PHP efectivamente utilizado pelo servidor Web, pelo que deve prosseguir obrigatoriamente para o passo seguinte.

2. Ajustar as definições do PHP-FPM para reduzir a superfície de ataque (opcional e mitigação temporária)
   Se for difícil aplicar imediatamente a actualização ou se pretender acrescentar uma camada de defesa, faça uma cópia de segurança do php.ini ou do ficheiro de configuração do pool do PHP-FPM (por exemplo, /etc/php-fpm.d/www.conf) e ajuste os itens seguintes.

   php_admin_value[session.upload_progress.enabled] = Off
   php_admin_value[post_max_size] = 32M
   php_admin_value[upload_max_filesize] = 30M

   Desactivar session.upload_progress.enabled permite bloquear o caminho de ataque baseado em sessões que foi confirmado. Reduzir post_max_size (para 8M em ambientes sem necessidade de carregamento de ficheiros, ou para 32M em ambientes onde seja necessário, por exemplo) dificulta tentativas de provocar esgotamento de memória através de pedidos de grande dimensão. Neste caso, considerando o tamanho dos cabeçalhos adicionais multipart, defina upload_max_filesize com um valor ligeiramente inferior a post_max_size. Em ambientes PHP 8.5, aplique também fatal_error_backtraces = 0.

3. Testar a sintaxe da configuração do PHP-FPM e reiniciar os processos
   Depois de guardar a configuração, teste se existem erros de sintaxe e reinicie o serviço PHP-FPM.

   php-fpm -t
   systemctl restart php-fpm

   Se não existirem problemas na configuração, a execução de php-fpm -t apresenta no ecra a mensagem NOTICE: configuration file ... test is successful. É necessário reiniciar os processos de trabalho para terminar os processos antigos que permaneciam na memória e aplicar a nova versão corrigida e as definições.

4. Confirmar a versão efectivamente aplicada através de um pedido Web
   Consulte o separador de informações «Estado do site (Site Health)» do WordPress ou uma página de diagnóstico da integração com o servidor Web e confirme que o processo de trabalho do PHP-FPM que trata os pedidos Web responde com uma versão corrigida, como 8.4.27. Se tiver criado temporariamente um ficheiro PHP de diagnóstico para a verificação, elimine-o logo depois para evitar a exposição de informações do sistema ao exterior.

Como proceder quando a actualização é atrasada ou surgem efeitos secundários das alterações de configuração

Quando o pacote não pode ser descarregado devido a um atraso na sincronização de repositórios de terceiros (como o Remi)

Logo após um patch de segurança urgente, a concentração de tráfego ou atrasos de sincronização podem fazer com que os pacotes de actualização não sejam imediatamente encontrados em repositórios de terceiros, como rpms.remirepo.net, ou sejam descarregados lentamente. O aviso oficial informa que as actualizações podem não ser disponibilizadas no repositório gerido por voluntários no próprio dia do anúncio e recomenda mudar para pacotes da distribuição ou para uma compilação a partir do código-fonte.

Neste caso, pode especificar directamente, nas definições do repositório, o endereço de um servidor mirror que tenha concluído a sincronização e apresente uma velocidade normal, prosseguindo depois com a actualização. Mesmo que altere manualmente o mirror, mantenha activa a verificação de assinaturas GPG (gpgcheck=1) para impedir a adulteração dos pacotes. Se não for possível utilizar um mirror, use os pacotes oficiais de backport da distribuição do sistema operativo ou compile directamente o código-fonte.

Quando existe preocupação com falta de memória (OOM) ou rejeição de carregamentos após aplicar a mitigação

O aviso oficial apresenta memory_limit = -1 (ilimitado) como medida de mitigação da CVE-2026-109618 quando não é possível actualizar imediatamente e recomenda aplicar em conjunto um limite de memória no contentor ou no cgroup. No entanto, se desactivar o limite de memória num servidor com pouca memória física, um único pedido pode consumir toda a memória do servidor, fazendo com que o OOM Killer do sistema operativo encerre à força um daemon essencial e provoque uma falha do serviço. Esta definição é uma medida temporária até à actualização; depois de actualizar para uma versão corrigida, é mais seguro repor o limite de memória original.

Além disso, antes de reduzir post_max_size face ao valor actual (por exemplo, 64 MB), deve verificar primeiro como o site transfere ficheiros. Num site que permita carregar directamente ficheiros de cópia de segurança de grande dimensão ou plug-ins através da página Web de administração, os pedidos podem ser bloqueados. Por outro lado, se os ficheiros grandes forem transferidos através de SFTP ou rsync, ou se o limite da própria aplicação já estiver definido para 30 MB ou menos, reduzir o limite de carregamento do PHP para 32 MB não afectará o serviço.

Se, após a actualização da versão do PHP, os processos de trabalho do PHP-FPM terminarem ocasionalmente de forma anómala, pode ser útil verificar a configuração de compilação JIT (Just-In-Time) do OPcache. A funcionalidade JIT (por exemplo, opcache.jit=1255) não está directamente relacionada com esta vulnerabilidade de segurança, mas, se já tiver causado problemas de estabilidade durante alterações de versão, pode ser desactivada no ficheiro de configuração com opcache.jit=off para evitar conflitos.

Perguntas frequentes

A actualização do WordPress ou dos plug-ins para a versão mais recente resolve o problema?

Não. Esta vulnerabilidade ocorre no motor principal do PHP, antes de o WordPress ou os plug-ins de segurança serem executados. É possível bloquear temporariamente padrões de ataque conhecidos através de uma firewall de aplicações Web (Cloudflare, AWS WAF, etc.), mas a solução fundamental exige actualizar a própria versão do PHP do servidor através do fornecedor de alojamento ou do administrador do servidor.

Se desactivar session.upload_progress.enabled, fico protegido sem fazer a actualização?

Não. O aviso oficial esclarece que esta definição bloqueia apenas o caminho de sessão confirmado, não impedindo outras variantes. Além disso, a definição deve ser aplicada antes da interpretação do pedido, em locais como php.ini, o pool do FPM ou a configuração do servidor, e não através de ini_set() ou do .user.ini do FPM; todos os processos de trabalho têm de ser reiniciados. A única solução completa é instalar o patch.

Depois de concluir a aplicação do patch, posso colocar o sistema imediatamente em produção sem verificações adicionais?

A actualização impede ataques futuros, mas não indica se já ocorreu um comprometimento. Mesmo depois de concluir a actualização, é recomendável verificar separadamente se houve intrusão anterior. Procure ficheiros PHP criados ou modificados recentemente de forma anómala, como webshells, nos directórios Web e investigue os registos de acesso do servidor Web e os registos de erros do PHP para detectar pedidos POST de grande dimensão fora do normal ou registos repetidos de erros de memória.

Como devo proceder em ambientes de contentores ou imagens de cloud?

Mesmo que actualize os pacotes no servidor anfitrião, o runtime do PHP incluído no contentor não é alterado automaticamente. Por isso, deve reconstruir e redistribuir a imagem do contentor utilizando uma imagem base que inclua as versões corrigidas (8.5.12, 8.4.27, 8.3.36 ou 8.2.35).

Fontes

• PHP: Security Advisory (CVE-2026-109618, CVE-2026-109619)
• PHP: PHP 8.4.27 Release Announcement
• PHP: PHP 8 ChangeLog (8.4.27)
• Red Hat Customer Portal - CVE-2026-109618
• Red Hat Customer Portal - CVE-2026-109619
• PHP 원격 코드 실행 취약점 CVE-2026-109618, CVE-2026-109619 대응 및 PHP 8.4.27 업데이트 (em coreano)