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.
# 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.
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.
; 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.
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.
; 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.
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:
; /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:
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.
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:
- Que ficheiro de configuração lê o modo de operação web e contém os seus valores?
- O
display_errorse oexpose_phpestão desativados e o registo de erros é gravável? - O
session.upload_progress.enabledestá em0, definido através do php.ini ou do pool? - Os tamanhos de upload e de pedido estão limitados de forma adequada à aplicação?
- 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.
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.