Em resumo: no Apache com mod_php, o PHP corre diretamente no servidor web. A equipa do PHP classifica o risco do PHP2Shell como o mais elevado precisamente neste modo de operação, porque foi demonstrado um exploit antes sequer de o código da aplicação ser executado. Aplique o patch de imediato, reinicie o Apache por completo e planeie depois a migração para PHP-FPM.
O que é o mod_php e porque conta agora
No mod_php, o Apache carrega o PHP como módulo em cada um dos seus processos de trabalho. Cada pedido a um ficheiro PHP é executado diretamente nesse processo. Durante muito tempo foi o padrão e é simples de configurar. Mas também significa: todos os sites do servidor correm com o mesmo utilizador, e o PHP partilha o processo com o servidor web.
O PHP2Shell engloba as vulnerabilidades CVE-2026-109618 e CVE-2026-109619, ambas com CVSS v4.0 9.2. Na segunda, o estado interno de um pedido pode persistir depois de a memória ser libertada e ser usado por um pedido posterior no mesmo processo. Para o mod_php, a equipa do PHP determinou o risco mais elevado. O contexto e o enquadramento estão em Porque é que o mod_php tem o risco mais elevado.
Reconhecer o Apache mod_php e verificar a versão
Verifique primeiro se o seu Apache usa de todo o mod_php. Os comandos seguintes apenas leem. Os nomes de comandos e de pacotes diferem consoante a distribuição e são exemplos.
# Debian/Ubuntu: módulos carregados
apache2ctl -M 2>/dev/null | grep -i php
# Família RHEL
httpd -M 2>/dev/null | grep -i php
# Que MPM está ativo? O mod_php exige prefork
apache2ctl -V 2>/dev/null | grep -i mpm
# Nível de pacotes do módulo (exemplos)
dpkg -l | grep libapache2-mod-php
rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common'
Se aparecer um módulo como php_module, o mod_php está em uso. A versão PHP mostrada não é, por si só, prova do patch, porque as distribuições costumam instalar as correções como backport. As versões corrigidas do projeto PHP são 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Nos pacotes das distribuições conta o registo de alterações com os números CVE.
Aplicar o patch e reiniciar o Apache por completo
Instale a atualização através da gestão de pacotes. Como o PHP está dentro do processo do Apache, o serviço inteiro tem de reiniciar depois. Recarregar a configuração não é aqui o caminho seguro.
# Debian/Ubuntu
systemctl restart apache2
# Família RHEL
systemctl restart httpd
# Verificação: hora de arranque de todos os processos do Apache
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep
Todos os processos do Apache têm de mostrar uma hora de arranque posterior à atualização. Se no mesmo servidor correr também PHP-FPM ou php-cgi, reinicie também esses serviços.
Se ainda não existir patch para a sua versão PHP, o BSI recomenda retirar temporariamente o servidor web da rede. No mod_php isto pesa particularmente, porque o ataque pode atuar antes do código da aplicação.
Medidas provisórias na configuração do Apache
O php.net indica medidas provisórias que reduzem o risco, mas não oferecem proteção completa. No mod_php, defina os valores com php_admin_value ou php_admin_flag na configuração do Apache, para que o .htaccess e as aplicações não os possam sobrescrever.
# Exemplo: na configuração do VirtualHost ou de todo o servidor
<IfModule php_module>
php_admin_flag session.upload_progress.enabled off
php_admin_value post_max_size 8M
php_admin_value upload_max_filesize 6M
</IfModule>
Com função de upload, o php.net indica post_max_size = 32M, com upload_max_filesize abaixo disso. No PHP 8.5 acresce fatal_error_backtraces=0. A indicação sobre memory_limit=-1 só a aplica em conjunto com um limite de memória para o serviço através de cgroups, por exemplo com MemoryMax num complemento do systemd, e não através de RLIMIT_AS ou RLIMIT_DATA. Depois, reinicie o Apache por completo. Todas as medidas num resumo: Medidas imediatas sem patch.
O caminho para sair do mod_php
Depois do patch urgente, compensa migrar para PHP-FPM. Aí o PHP corre em processos próprios, separados do servidor web. Cada site pode ter um pool próprio com utilizador próprio, é possível definir limites por pool e os reinícios afetam apenas o PHP. O Apache liga-se ao PHP-FPM através de mod_proxy_fcgi e pode então usar, em vez de prefork, um MPM mais moderno como o event.
Planeie a mudança num ambiente de teste: criar pools por site, adaptar as permissões de ficheiros aos novos utilizadores, transferir entradas php_value do .htaccess para as definições do pool, fazer testes de carga. Como é uma configuração limpa mostra-o Proteger o Nginx com PHP-FPM; os princípios aplicam-se igualmente ao Apache com PHP-FPM.
Independentemente do modo de operação, vale que: um patch não remove software malicioso já introduzido. Guarde os registos a partir de 20/10/2026 e verifique se o servidor apresenta vestígios.
Na busca de vestígios em servidores mod_php, compensa olhar para o utilizador partilhado. Como todos os sites correm sob o utilizador do Apache, por exemplo www-data ou apache, um atacante que tenha tomado conta de um site pode, em regra, também ler e alterar os ficheiros dos outros. Por isso, não verifique apenas o site que lhe parece suspeito, mas todos os document roots do servidor. Preste especial atenção a ficheiros PHP com data de alteração recente nos diretórios de upload e de cache, a código de programa que pertença ao utilizador do Apache e a entradas desconhecidas no crontab desse utilizador. Se encontrar algo, preserve primeiro o estado e não apague precipitadamente, para que a causa continue a poder ser reconstituída mais tarde.
Como ajuda concretamente a PHP SOS?
- Verificamos o modo de operação, o MPM e o nível dos pacotes e avaliamos se o seu servidor tem realmente patch.
- Através do serviço de patches PHP, instalamos a atualização, reiniciamos o Apache por completo e documentamos o comprovativo.
- Até ao patch, definimos as medidas provisórias de forma a não poderem ser sobrescritas e limitamos a memória ao nível do serviço.
- No âmbito do reforço de servidores, planeamos e testamos a migração para PHP-FPM com pools separados.
Perguntas frequentes
Como reconheço se o meu servidor usa mod_php?
Se o Apache tiver um módulo PHP carregado, ele aparece na lista de módulos como php_module ou com o número de versão no nome. Além disso, uma saída de phpinfo mostra em Server API a entrada Apache 2.0 Handler. Apague de imediato esse ficheiro de teste.
Porque é que o mod_php é particularmente crítico no PHP2Shell?
Segundo a equipa do PHP, o risco é aí o mais elevado; foi demonstrado um exploit antes sequer de o código da aplicação ser executado. Assim, nem uma aplicação bem mantida protege. Uma atualização rápida tem por isso a máxima prioridade.
Basta um reload do Apache depois da atualização?
O seguro é um reinício completo do serviço, porque o PHP está dentro dos processos do Apache como módulo. Verifique depois a hora de arranque de todos os processos do Apache. Não devem sobrar processos mais antigos do que a atualização.
A mudança para PHP-FPM dá muito trabalho?
Na maioria dos casos é bem planeável: instalar o PHP-FPM, criar pools, mudar o Apache para proxy_fcgi e passar de prefork para outro MPM. Teste-o antes numa cópia do ambiente.