# Configurar o php.ini com segurança

> Configurar o php.ini com segurança: definições para erros, sessões, uploads e memória, mais as medidas transitórias do php.net para o PHP2Shell, prontas a copiar.

Fonte: https://phpsos.de/pt/ratgeber/php-ini-sicher-konfigurieren/  
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:** para a segurança do php.ini contam sobretudo quatro áreas: nenhuma mensagem de erro para o exterior, cookies de sessão seguros, uploads limitados e valores bloqueados que as aplicações não podem substituir. Após o PHP2Shell juntam-se as medidas transitórias do php.net, sobretudo `session.upload_progress.enabled=0`. Uma configuração segura nunca substitui, porém, a atualização.

## Porque é que o php.ini voltou a estar em foco após o PHP2Shell

O php.ini é o ficheiro de configuração central do PHP. Em muitos servidores foi configurado uma vez e depois quase não foi tocado. Com o PHP2Shell isso mudou: para as duas vulnerabilidades CVE-2026-109618 e CVE-2026-109619, o php.net indica medidas transitórias que atuam precisamente aqui.

As vulnerabilidades em si estão no interpretador PHP. Estão corrigidas no PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, publicados a 21/10/2026. Uma boa configuração ajuda, ainda assim, de duas formas: pode dificultar a exploração e limita o dano se, mesmo assim, algo passar.

Além disso, muitos operadores não sabem ao certo que definições valem no seu servidor. Esse é o primeiro passo.

## Que php.ini vale no seu servidor?

Consoante o modo de operação, o PHP pode ler ficheiros de configuração diferentes. A linha de comandos, o PHP-FPM e o Apache com mod_php têm, por exemplo em Debian e Ubuntu, pastas próprias em `/etc/php/<versão>/`. Quem altera apenas o ficheiro da CLI não altera nada no site.

```bash
# Ficheiros de configuração da linha de comandos
php --ini
# Configuração do PHP-FPM (adapte o número de versão)
php-fpm8.3 -i | grep -E "Loaded Configuration|Scan this dir"
# Verificar valores individuais do PHP-FPM
php-fpm8.3 -i | grep -E "^(expose_php|display_errors|session.upload_progress.enabled) "
```

Adicionalmente, os valores podem estar no pool FPM, na configuração do Apache, no `.htaccess` (apenas mod_php) ou no `.user.ini` (FPM e CGI). Que versão corre realmente no servidor e se inclui um backport, esclarece-o o artigo [Verificar corretamente a versão do PHP e o nível de patch](https://phpsos.de/pt/php2shell/php-version-pruefen/).

## Definições de base para mais segurança do php.ini

Os valores seguintes fazem sentido para a maioria dos servidores de produção. Antes de os usar, verifique num ambiente de teste se a sua aplicação funciona com todos eles.

```ini
; Sem indicação de versão no cabeçalho HTTP
expose_php = Off

; Registar erros, mas nunca os mostrar no navegador
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/error.log

; Não incluir ficheiros de endereços remotos
allow_url_include = Off
; Manter allow_url_fopen ativo só se a aplicação precisar
allow_url_fopen = Off

; Sessões: estritas, só por HTTPS, não legíveis por JavaScript
session.use_strict_mode = 1
session.use_only_cookies = 1
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax

; Limitar tempo de execução e entradas
max_execution_time = 30
max_input_time = 60
max_input_vars = 1000
```

Algumas aplicações precisam do `allow_url_fopen` para atualizações ou interfaces. Desative-o apenas depois de o ter verificado. As funções que executam comandos de sistema podem ser bloqueadas adicionalmente; como o fazer sem efeitos secundários, explica-o o guia [Usar corretamente o disable_functions](https://phpsos.de/pt/ratgeber/disable-functions/).

## Medidas transitórias do php.net para o PHP2Shell

Se não puder aplicar o patch de imediato, o php.net indica várias definições que reduzem o risco. Não são, expressamente, uma proteção completa, mas uma ponte até à atualização.

```ini
; Desativar o session upload progress (também por causa do CVE-2026-115560)
session.upload_progress.enabled = 0

; Limitar o tamanho do pedido: 8M sem uploads, 32M com uploads
post_max_size = 8M
upload_max_filesize = 6M

; Apenas PHP 8.5: sem backtraces em erros graves
fatal_error_backtraces = 0
```

Além disso, o php.net recomenda definir `memory_limit=-1` de modo a que as aplicações não possam substituir o valor, e traçar o limite de memória através de contentor ou cgroup, não através de `RLIMIT_AS` ou `RLIMIT_DATA`. Esta medida pertence ao pool FPM ou à configuração do servidor e deve ser combinada com um limite cgroup funcional. A vista geral completa está em [Medidas imediatas quando ainda não pode aplicar o patch](https://phpsos.de/pt/php2shell/sofortmassnahmen-ohne-patch/).

> **Importante:**
> O `session.upload_progress.enabled=0` só produz efeito a partir do php.ini, do pool FPM ou da configuração do servidor. Definida através de `ini_set()` ou `.user.ini`, a medida não funciona. Depois, reinicie todos os workers.

## Bloquear valores contra substituição

Muitas aplicações definem valores próprios, por exemplo para memória ou uploads. Com `php_admin_value` e `php_admin_flag` fixa as definições de modo a que nem `ini_set()` nem `.user.ini` as possam alterar. No pool FPM é assim:

```ini
; /etc/php/8.3/fpm/pool.d/meine-seite.conf (excerto)
php_admin_flag[display_errors] = off
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_value[error_log] = /var/log/php/meine-seite.error.log
```

No Apache com mod_php aplica-se a mesma lógica com `php_admin_value` e `php_admin_flag` na configuração do VirtualHost. Depois, recarregue o serviço e confirme o valor ativo:

```bash
sudo systemctl reload php8.3-fpm
# Hora de arranque dos processos: é posterior à alteração?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
```

Um reload reinicia os workers do PHP-FPM. Após uma atualização do PHP, em contrapartida, é necessário um reinício completo de todos os processos PHP, para que nenhum processo antigo continue na memória. Com vários sites num servidor vale ainda a pena ter um pool próprio por site; mais sobre isso no guia [open_basedir e isolamento por site](https://phpsos.de/pt/ratgeber/open-basedir/).

## Erros frequentes e uma lista de verificação breve

A maioria dos problemas com o php.ini não resulta de valores errados, mas de valores no sítio errado. Típico é o ficheiro da CLI alterado enquanto o site corre através do PHP-FPM. Igualmente frequente é faltar o reinício após uma alteração, ou um painel de alojamento substituir a definição própria na gravação seguinte.

Um segundo clássico são as mensagens de erro visíveis no site em produção. Revelam caminhos, nomes de bases de dados ou versões e facilitam a orientação dos atacantes. Precisamente após uma mudança ou uma reinstalação, o `display_errors` volta muitas vezes a ficar em `On`.

Estes pontos devem ser controlados após cada alteração e após cada atualização do PHP:

1. Que ficheiro de configuração lê o modo de operação web e contém os seus valores?
2. O `display_errors` e o `expose_php` estão desativados e o registo de erros é gravável?
3. O `session.upload_progress.enabled` está em `0`, definido através do php.ini ou do pool?
4. Os tamanhos de upload e de pedido estão limitados de forma adequada à aplicação?
5. Todos os processos PHP correm com um momento de arranque posterior à última alteração?

Registe o resultado com a data. Assim, mais tarde é possível comprovar que definição valia e quando.

## Como ajuda concretamente a PHP SOS?

- Determinamos que configuração está realmente ativa em cada modo de operação.
- Aplicamos uma configuração de base ajustada e as medidas transitórias do PHP2Shell, testadas com a sua aplicação.
- Bloqueamos os valores relevantes para a segurança contra substituição e reiniciamos todos os workers de forma controlada.
- Documentamos as definições e o resultado da verificação, para que alterações posteriores permaneçam rastreáveis.

Como é uma proteção duradoura, descreve-o o serviço [Reforço de segurança de servidores PHP](https://phpsos.de/pt/leistungen/server-haertung/).


## Perguntas frequentes

**Que php.ini usa realmente o meu servidor web?**  
Muitas vezes não é o mesmo que na linha de comandos. O PHP-FPM, o Apache com mod_php e a CLI costumam ter pastas de configuração próprias. Por isso, verifique o ficheiro ativo através do respetivo modo de operação, por exemplo com php-fpm -i ou com um ficheiro de teste colocado por pouco tempo.

**Um php.ini seguro substitui a atualização do PHP?**  
Não. As definições reduzem a superfície de ataque e dificultam a exploração, mas não fecham nenhuma vulnerabilidade no interpretador PHP. Também as medidas transitórias do php.net para o PHP2Shell não são, expressamente, uma proteção completa.

**Qual é a diferença entre php_value e php_admin_value?**  
Os valores definidos com php_value podem ser alterados de novo pela aplicação durante a execução. Os valores definidos com php_admin_value no pool FPM ou na configuração do Apache ficam, em contrapartida, bloqueados para a aplicação, também para ini_set() e .user.ini.

**Tenho de reiniciar depois de alterar o php.ini?**  
Sim. O PHP-FPM e o Apache com mod_php só leem a configuração no arranque. Os novos valores só valem depois de reiniciar ou recarregar todos os serviços afetados.

## Fontes

- [php.net: avisos de segurança](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [BSI IT-Grundschutz (proteção de base de TI)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)