Em resumo: a CVE-2026-109618 é uma das duas vulnerabilidades por trás do PHP2Shell. Um estado de falta de memória pode interromper o PHP enquanto os dados do pedido estão apenas parcialmente inicializados; na limpeza, dados inválidos podem então ser tratados como válidos. Isso permite a execução de código sem autenticação. O erro está corrigido no PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
O que é a CVE-2026-109618?
A CVE-2026-109618 (identificador GitHub GHSA-w8hw-w9fx-j79w) é uma vulnerabilidade de erro de memória no núcleo do PHP. Tem CVSS v4.0 de 9,2. Em conjunto com a CVE-2026-109619, constitui aquilo a que os meios de comunicação chamam PHP2Shell.
O efeito é a chamada unauthenticated Remote Code Execution: um atacante pode executar código no servidor web, remotamente e sem conta de utilizador. Com isso, a vulnerabilidade pertence à classe mais perigosa de fraquezas que um servidor web pode ter.
Como a vulnerabilidade surge, em termos gerais
Quando o PHP processa um pedido web, cria internamente estruturas de dados para esse pedido, por exemplo para dados de formulário enviados. Se o PHP atinge o seu limite de memória, termina com um estado de falta de memória (out of memory). Segundo o php.net, isto pode acontecer enquanto os dados do pedido estão apenas parcialmente inicializados.
No fim de cada pedido, o PHP limpa e liberta a memória. É exatamente aí que está o erro: a limpeza pode tratar como válidos dados inválidos, apenas meio criados. Deste comportamento incorreto pode derivar-se, em certas condições, a execução de código.
Porque é que um erro destes é tão grave? Um erro de memória na linguagem de programação afeta todas as aplicações que nela correm, independentemente do cuidado com que foram programadas. Uma instalação WordPress bem mantida, com plugins atualizados, está tão afetada como um desenvolvimento próprio antigo. Por isso, não ajuda aqui uma atualização da aplicação, mas apenas uma atualização do PHP.
Outros pormenores técnicos sobre a exploração não os publicamos, de propósito. Para a defesa não são necessários: o que importa é se o seu servidor usa uma versão corrigida e se os processos novos estão realmente em execução.
Versões e modos de operação afetados
| Ramo do PHP | Último nível antes da correção | Corrigido a partir de |
|---|---|---|
| 8.5 | 8.5.11 | 8.5.12 |
| 8.4 | 8.4.26 | 8.4.27 |
| 8.3 | 8.3.35 | 8.3.36 |
| 8.2 | 8.2.34 | 8.2.35 |
| 8.1 e anteriores | sem atualização oficial | apenas backports mínimos do código-fonte para 7.4, 8.0, 8.1 |
Estão afetados os modos de operação PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. A equipa do PHP classifica o risco como o mais elevado no mod_php. As distribuições e os fornecedores de alojamento aplicam por vezes backports, de modo que é apresentado um número de versão mais antigo, apesar de o erro estar corrigido. O que conta são o estado do pacote e a confirmação do fornecedor.
Quanto à dimensão: a Palo Alto Networks (Unit 42) contou mais de 22,6 milhões de instâncias expostas e potencialmente vulneráveis. O BSI declarou o nível de alerta 3 (laranja) e contava com uma exploração rápida e em larga escala.
Corrigir a CVE-2026-109618: atualização e reinício
A única solução completa é a atualização. Verifique primeiro a versão e o estado do pacote. Os nomes dos pacotes variam conforme a distribuição; os exemplos partem do PHP 8.3:
php -v
apt policy php8.3-fpm # Debian/Ubuntu
dnf info php-fpm # RHEL, AlmaLinux, Rocky, Fedora
rpm -q --changelog php-fpm | grep -i "CVE-2026-109618"
Se o changelog do pacote menciona o número CVE, o backport está instalado. Se não o menciona, isso não significa automaticamente que o pacote esteja vulnerável; nesse caso, ajuda a comparação com a tabela de versões ou a consulta ao fornecedor.
Depois da atualização, todos os processos PHP têm de ser reiniciados, por exemplo com systemctl restart php8.3-fpm ou, no caso do mod_php, com um reinício do Apache. Como assegurar que já não corre nenhum worker antigo, consta de Reiniciar o PHP-FPM e todos os workers.
Medidas provisórias quando a atualização ainda não é possível
O php.net publicou medidas provisórias para o PHP2Shell. Aplicam-se às duas vulnerabilidades em conjunto e são expressamente uma proteção incompleta. O facto de várias delas se referirem a limites de memória condiz com o gatilho de falta de memória da CVE-2026-109618; não existe, porém, atribuição oficial de medidas individuais a CVEs individuais.
; Exemplo de pool FPM, p. ex. /etc/php/8.3/fpm/pool.d/www.conf (o caminho varia conforme a distribuição)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M ; 32M, se forem necessários carregamentos de ficheiros
php_admin_value[upload_max_filesize] = 6M ; immer unter post_max_size
php_admin_flag[session.upload_progress.enabled] = off
Os valores têm de ser definidos de modo que as aplicações não os possam sobrepor, daí o php_admin_value. Com memory_limit=-1, o serviço precisa de um limite de memória vindo de fora, através de contentor ou cgroup, e não através de RLIMIT_AS ou RLIMIT_DATA. No PHP 8.5 acresce fatal_error_backtraces=0. Todos os pormenores constam de Medidas imediatas quando ainda não pode aplicar o patch.
Se nem a atualização nem as medidas provisórias forem possíveis de imediato, o BSI recomenda desligar temporariamente da rede os servidores web afetados.
Como ajuda concretamente a PHP SOS?
Através do nosso serviço de patches PHP, fechamos a CVE-2026-109618 de forma estruturada:
- Registar o estado atual: ramo do PHP, modo de operação, fonte de pacotes e estado de backport por servidor.
- Instalar a atualização a partir da fonte de pacotes adequada ou, onde isso não for possível, aplicar corretamente as medidas provisórias na configuração do pool ou do servidor.
- Verificar o reinício: controlamos que já não correm processos PHP antigos.
- Comprovativo: recebe uma documentação com versões e estados de pacote antes e depois da intervenção, por exemplo para a administração, a seguradora ou a proteção de dados.
Perguntas frequentes
Quão crítica é a CVE-2026-109618?
A vulnerabilidade tem CVSS v4.0 de 9,2 e é, portanto, crítica. Permite a execução remota de código malicioso sem autenticação. O BSI (Gabinete Federal Alemão para a Segurança da Informação) declarou para o PHP2Shell o nível de alerta 3 (laranja).
Basta aumentar o memory_limit?
Não. O php.net indica memory_limit=-1, definido de forma fixa na configuração do servidor, como uma de várias medidas provisórias. É expressamente uma proteção incompleta e exige um limite de memória através de contentor ou cgroup. A solução continua a ser a atualização.
Que identificador GHSA corresponde à CVE-2026-109618?
No GitHub Security Advisory, a vulnerabilidade consta como GHSA-w8hw-w9fx-j79w. A segunda vulnerabilidade do PHP2Shell, a CVE-2026-109619, tem o identificador GHSA-6wmf-4rv5-p3rp.