Em resumo: o PHP2Shell afeta todos os modos de operação habituais, mas no Apache com mod_php a equipa do PHP classifica o risco como o mais elevado. Aí foi demonstrado um exploit antes sequer de o código da aplicação ser executado. Quem opera o mod_php deve atualizar primeiro o PHP e reiniciar o Apache por completo.
O que é o mod_php?
No mod_php, o PHP é um módulo dentro do servidor web Apache. Cada processo do Apache contém um interpretador PHP completo e executa o código PHP diretamente. Este modo de operação foi durante muito tempo o padrão e continua difundido em servidores mais antigos, em muitos pacotes de distribuições e em algumas imagens Docker.
A alternativa é o PHP-FPM: aí, o PHP corre como serviço próprio, com processos próprios, e o Apache ou o Nginx limita-se a reencaminhar os pedidos. Ambas as variantes estão afetadas pelo PHP2Shell, tal como o php-cgi, o FrankenPHP e o LiteSpeed.
Ambientes típicos com mod_php são servidores root mais antigos que correm inalterados há anos, instalações padrão do Apache a partir de pacotes de distribuições e imagens Docker com Apache e PHP num só contentor. Quem não sabe ao certo que modo de operação o seu servidor usa deve verificá-lo, em vez de o presumir.
Porque é que a vulnerabilidade do mod_php é considerada particularmente arriscada?
A equipa do PHP fez uma avaliação clara sobre o PHP2Shell: no mod_php, o risco é o mais elevado. Fundamentação: aí foi demonstrado um exploit que atua antes sequer de o código da aplicação ser executado.
Para os operadores, isto tem uma consequência incómoda. Muitas medidas de proteção estão na aplicação: plugins de segurança no WordPress, módulos de firewall em lojas, verificações no código próprio. Todas elas são código da aplicação. Se a exploração ocorre antes, chegam tarde demais.
Acresce a estreita ligação: no mod_php, o PHP partilha o processo com o Apache. O que compromete o PHP corre com os direitos do servidor web e na memória deste. No PHP-FPM, em contrapartida, os pools podem ser separados com utilizadores próprios por site, o que pode limitar as consequências de uma intrusão.
Para a priorização, isto significa: se opera vários servidores, os que têm mod_php vêm primeiro, e neles é particularmente importante uma verificação posterior de vestígios.
O que não sabemos: quantas das 22,6 milhões de instâncias expostas e potencialmente vulneráveis contadas a nível mundial usam mod_php. Não foram publicados números fiáveis a esse respeito.
O meu servidor usa mod_php?
Os comandos seguintes são apenas de leitura. Os nomes de serviços e de comandos variam conforme a distribuição: o Debian e o Ubuntu usam apache2, a família RHEL usa httpd.
apachectl -M 2>/dev/null | grep -i php # p. ex. php_module ou php8_module
httpd -M 2>/dev/null | grep -i php # RHEL, AlmaLinux, Rocky
a2query -m | grep -i php # Debian/Ubuntu
apt policy libapache2-mod-php8.3 # Debian/Ubuntu, versão do pacote do módulo
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619" # família RHEL
Se não aparecer nenhum módulo PHP, o Apache usa provavelmente o PHP-FPM através de proxy_fcgi. Então aplicam-se, por analogia, as indicações de Proteger o Nginx com PHP-FPM.
O que os operadores de mod_php devem fazer agora
- Atualizar o módulo PHP para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ou para um backport confirmado da sua distribuição.
- Reiniciar o Apache por completo, e não apenas recarregar. No mod_php, o código PHP antigo está em cada processo do Apache.
sudo systemctl restart apache2 # Debian/Ubuntu
sudo systemctl restart httpd # família RHEL
ps -o pid,lstart,cmd -C apache2 # verificar a hora de arranque; no RHEL: -C httpd
- Aplicar medidas provisórias, se a atualização ainda não for possível. O php.net indica, entre outras, limites fixos que as aplicações não podem sobrepor:
# configuração do servidor ou VirtualHost, não .htaccess
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
Com memory_limit=-1, faz parte um limite de memória através de cgroup, e não através de RLIMIT_AS ou RLIMIT_DATA. Estas medidas não são uma proteção completa; os pormenores constam de Medidas imediatas quando ainda não pode aplicar o patch. Se nenhuma das duas coisas for possível de imediato, o BSI recomenda desligar temporariamente o servidor web da rede.
Se o seu Apache com mod_php esteve desprotegido na Internet entre 17 de outubro e o patch, guarde os registos desde 20 de outubro e mande verificar o servidor quanto a vestígios. O patch, por si só, não prova que nada aconteceu.
A médio prazo: abandonar o mod_php
Depois do patch, vale a pena olhar para a arquitetura. A mudança para o PHP-FPM com Apache mpm_event e proxy_fcgi ou com Nginx separa o PHP do servidor web, permite pools e utilizadores próprios por site e torna os reinícios e as mudanças de versão mais simples. Não fecha o PHP2Shell, mas reduz a superfície de ataque de vulnerabilidades futuras.
A mudança exige planeamento. As definições que até agora eram feitas com php_value no .htaccess deixam de funcionar no PHP-FPM e têm de passar para o pool. Utilizadores e direitos mudam, as pastas de uploads e de cache podem precisar de novas permissões. Num ambiente de teste, isto é bem controlável; em produção, sob pressão de tempo, não. Indicações sobre a mudança encontra-as em Proteger o Apache com mod_php.
Como ajuda concretamente a PHP SOS?
- Reconhecer: verificamos que servidores usam mod_php e de que fonte de pacotes vem o módulo.
- Aplicar o patch e reiniciar: através do serviço de patches PHP, instalamos a atualização e controlamos que já não corre nenhum processo antigo do Apache.
- Proteger a transição: onde a atualização está bloqueada, aplicamos as medidas do php.net na configuração do servidor.
- Mudar: no âmbito do hardening de servidor, planeamos e testamos a mudança para o PHP-FPM com pools separados.
Perguntas frequentes
Como reconheço se o meu Apache usa mod_php?
Com apachectl -M ou httpd -M vê os módulos carregados. Se aparecer um módulo como php_module ou php8_module, o PHP corre diretamente no Apache. No Debian e no Ubuntu, também o a2query -m mostra se um módulo php está ativo.
Um plugin de segurança no WordPress protege-me com o mod_php?
Nesta vulnerabilidade, não. Segundo a equipa do PHP, no mod_php foi demonstrado um exploit antes sequer de o código da aplicação ser executado. Um plugin é código da aplicação e chega, por isso, tarde demais. A proteção só a oferece a atualização do PHP com reinício do Apache.
Devo agora mudar do mod_php para o PHP-FPM?
Primeiro aplicar o patch, depois mudar. A mudança para o PHP-FPM faz sentido, a médio prazo, para a maioria das configurações, porque o PHP passa a correr separado do servidor web. Mas não fecha o PHP2Shell, pois o PHP-FPM também está afetado.