# Porque é que o mod_php tem o risco mais elevado

> Porque a equipa do PHP classifica o risco do PHP2Shell como o mais elevado no Apache com mod_php, como reconhecer o mod_php e o que aplicar e alterar agora.

Fonte: https://phpsos.de/pt/php2shell/mod-php-risiko/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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`.

```bash
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](https://phpsos.de/pt/server/nginx-php-fpm/).

## O que os operadores de mod_php devem fazer agora

1. **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.
2. **Reiniciar o Apache por completo,** e não apenas recarregar. No mod_php, o código PHP antigo está em cada processo do Apache.

```bash
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
```

3. **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:

```apache
# 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](https://phpsos.de/pt/php2shell/sofortmassnahmen-ohne-patch/). Se nenhuma das duas coisas for possível de imediato, o BSI recomenda desligar temporariamente o servidor web da rede.

> **Agir de imediato:**
> 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](https://phpsos.de/pt/server/apache-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](https://phpsos.de/pt/leistungen/php-patch-service/), 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](https://phpsos.de/pt/leistungen/server-haertung/), 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.

## Fontes

- [php.net: avisos de segurança](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Gabinete Federal Alemão para a Segurança da Informação](https://www.bsi.bund.de/)