# Proteger o Apache com mod_php

> Apache mod_php após o PHP2Shell: reconhecer o modo de operação, aplicar patch ao módulo PHP, reiniciar o Apache por completo e preparar a migração para PHP-FPM.

Fonte: https://phpsos.de/pt/server/apache-mod-php/  
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:** 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](https://phpsos.de/pt/php2shell/mod-php-risiko/).

## 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.

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

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

> **Agir de imediato:**
> 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.

```apache
# 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](https://phpsos.de/pt/php2shell/sofortmassnahmen-ohne-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](https://phpsos.de/pt/server/nginx-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](https://phpsos.de/pt/leistungen/php-patch-service/), 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](https://phpsos.de/pt/leistungen/server-haertung/), 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.

## 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/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)