Em resumo: o php-cgi é a forma mais antiga de operar o PHP atrás de um servidor web e continua a correr em muitos servidores, muitas vezes sem ser notado. A vulnerabilidade php-cgi do PHP2Shell afeta expressamente este modo de operação. Aplique o patch, termine todos os processos php-cgi em execução e planeie a mudança para PHP-FPM.
O que é o php-cgi e onde ainda corre
O PHP existe em várias variantes: como programa de linha de comandos, como módulo do Apache, como PHP-FPM e como php-cgi. O php-cgi é um programa que o servidor web inicia e ao qual entrega os pedidos por CGI ou FastCGI. Sem gestão de processos própria, é mais simples do que o PHP-FPM, mas também menos controlável.
Os locais típicos são painéis de alojamento mais antigos, o Apache com mod_fcgid, scripts wrapper próprios para várias versões PHP e o PHP no Windows com IIS através de FastCGI. Em agências e organismos públicos encontram-se além disso servidores que foram configurados há anos e desde então apenas operados.
A vulnerabilidade php-cgi no PHP2Shell
O PHP2Shell engloba as vulnerabilidades CVE-2026-109618 e CVE-2026-109619 no próprio PHP, cada uma com CVSS v4.0 9.2. Ambas permitem a execução de código malicioso sem autenticação. O projeto PHP indica expressamente o php-cgi entre os modos de operação afetados, a par do PHP-FPM, do mod_php, do FrankenPHP e do LiteSpeed.
Estão corrigidos o PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Para o PHP 8.1 e anteriores já não existem atualizações oficiais, apenas backports mínimos do código-fonte para 7.4, 8.0 e 8.1. Precisamente as configurações php-cgi correm com frequência acima da média em versões antigas. O php-cgi também não é afetado pela primeira vez: já em 2024, uma vulnerabilidade no php-cgi no Windows (CVE-2024-4577) causou sensação. Legados deste tipo merecem por isso atenção especial.
Encontrar o php-cgi no servidor
Os comandos seguintes apenas leem e ajudam a localizar o php-cgi. Caminhos e nomes de módulos são exemplos.
# Processos php-cgi em execução com hora de arranque e utilizador
ps -eo pid,lstart,user,cmd | grep -E 'php-cgi|php[0-9.]*-cgi' | grep -v grep
# Programas php-cgi instalados
ls /usr/bin/php*-cgi /usr/lib/cgi-bin/php* 2>/dev/null
# Apache: o mod_fcgid ou o mod_cgi está carregado?
apache2ctl -M 2>/dev/null | grep -Ei 'fcgid|cgi'
grep -RniE 'FcgidWrapper|AddHandler.*php|Action.*php' /etc/apache2 /etc/httpd 2>/dev/null
Se encontrar entradas FcgidWrapper ou handlers que apontem para um programa php-cgi, este modo de operação está em uso. Para cada programa encontrado, verifique a versão com -v. Nos pacotes das distribuições, é o registo de alterações com os números CVE que comprova o patch, porque os backports muitas vezes não alteram o número de versão.
Aplicar o patch e terminar todos os processos
Instale a atualização através da gestão de pacotes ou da origem de onde vem o php-cgi. Depois, todos os processos php-cgi em execução têm de desaparecer. Com mod_fcgid, o Apache mantém processos disponíveis durante algum tempo; um reinício completo do Apache termina-os.
# Reiniciar o Apache por completo (Debian/Ubuntu ou família RHEL)
systemctl restart apache2 # ou: systemctl restart httpd
# Verificação: ainda há processos php-cgi mais antigos do que a atualização?
ps -eo pid,lstart,cmd | grep -E 'php-cgi' | grep -v grep
Se o php-cgi correr através de um gestor de processos próprio ou de um serviço do painel, reinicie-o. No Windows com IIS, recicle os pools de aplicações; veja PHP no Windows e no IIS.
Se o php-cgi correr com PHP 8.1 ou anterior num servidor acessível publicamente, falta um patch oficial. Aplique de imediato as medidas provisórias e considere, segundo a recomendação do BSI, retirar temporariamente o servidor da rede.
Medidas provisórias no php-cgi
O php.net recomenda medidas provisórias que não oferecem proteção completa. No php-cgi, os valores pertencem ao php.ini que o respetivo programa carrega ou à configuração do servidor. Ficheiros .user.ini e ini_set() não bastam, segundo o php.net, para session.upload_progress.enabled.
; php.ini da instalação php-cgi
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Com função de upload, o php.net indica post_max_size = 32M. No PHP 8.5 acresce fatal_error_backtraces=0. Os limites de memória defina-os através de cgroups para o serviço do servidor web, e não através de RLIMIT_AS ou RLIMIT_DATA. Depois, reinicie todos os processos.
O caminho para o PHP-FPM
A longo prazo, o php-cgi não é uma boa escolha. O PHP-FPM oferece pools por site, utilizadores próprios, limites por pool, páginas de estado e reinícios controlados. A mudança é, na maioria dos casos, bem planeável: instalar o PHP-FPM, criar pools, mudar o servidor web para FastCGI com PHP-FPM, remover scripts wrapper. Como é uma configuração limpa mostra-o Proteger o Nginx com PHP-FPM. Se correr além disso uma versão PHP antiga, combine a mudança com a atualização de versão.
Até a mudança estar feita, deve verificar criticamente a configuração existente. O servidor web só deve passar ao php-cgi ficheiros com a extensão .php e não caminhos que apontem para ficheiros inexistentes. Nos diretórios de upload, não deve ser possível executar PHP. Nos scripts wrapper que carregam um php.ini próprio por site, verifique se esses ficheiros anulam de novo os valores provisórios. Se um programa php-cgi estiver diretamente num diretório acessível publicamente, como cgi-bin, deve ser removido de lá. Estes legados vêm muitas vezes de instruções de instalação de anos passados e são simplesmente esquecidos em reformulações posteriores. Documente cada achado com o caminho e a finalidade, para que a reformulação posterior não deixe nada escapar.
Continua a ser importante: um patch não remove software malicioso introduzido antes. Guarde os registos a partir de 20/10/2026.
Como ajuda concretamente a PHP SOS?
- Localizamos instalações php-cgi, wrappers e handlers e associamo-los aos sites.
- Aplicamos o patch, terminamos todos os processos antigos e documentamos o nível.
- Para o PHP 8.1 e anteriores, planeamos consigo a migração para uma versão PHP suportada.
- No âmbito do reforço de servidores, substituímos o php-cgi por PHP-FPM com pools separados.
Perguntas frequentes
Estarei a usar php-cgi sem o saber?
É mais frequente do que se pensa. Painéis mais antigos, configurações FastCGI com mod_fcgid e PHP no Windows com IIS iniciam muitas vezes o PHP como php-cgi. Uma lista de processos ou o Server API no phpinfo mostram-no de forma fiável.
FastCGI é o mesmo que php-cgi?
Não exatamente. O FastCGI é um protocolo. O PHP-FPM e o php-cgi podem ambos falar FastCGI, mas o php-cgi é o programa mais antigo e mais simples, sem pools nem gestão de processos. O PHP2Shell afeta expressamente o php-cgi.
O que significa CGI clássico no PHP?
No CGI clássico, o servidor web inicia um novo processo PHP para cada pedido. É lento e hoje raro. Mais frequente é o php-cgi atrás de mod_fcgid ou FastCGI, onde os processos tratam vários pedidos.
Tenho de reiniciar alguma coisa depois da atualização?
Sim. Nas configurações FastCGI, os processos php-cgi continuam a correr durante algum tempo. Reinicie o servidor web ou o gestor de processos e verifique que nenhum processo php-cgi é mais antigo do que a atualização.