Em resumo: O handler PHP do Plesk define como o PHP corre para um site: como aplicação FPM com pool partilhado, como Dedicated FPM com pool próprio por site, como aplicação FastCGI ou como módulo Apache (mod_php). Do ponto de vista da segurança, o Dedicated FPM é em Linux geralmente a melhor escolha e o módulo Apache a pior. O próprio Plesk classifica-o como obsoleto ou inseguro e, no PHP2Shell, a equipa do PHP vê o maior risco precisamente no mod_php.
Porque é que o handler é mais do que uma questão de desempenho
No Plesk, escolhe para cada site uma versão do PHP e um handler. Muitos tratam o handler como um detalhe de desempenho e memória. Mas ele decide também até que ponto os sites estão separados uns dos outros, onde atuam as definições de segurança e que processos têm de ser reiniciados depois de uma atualização.
Depois do PHP2Shell, esta escolha torna-se concreta. As vulnerabilidades CVE-2026-109618 e CVE-2026-109619 afetam todos os modos de operação habituais, mas a equipa do PHP classifica o risco como mais elevado no mod_php. Quem ainda opera domínios com o módulo Apache no seu servidor Plesk deve alterá-lo agora. Como verificar versões e aplicar patches está descrito na página Servidores Plesk: verificar e aplicar patches às versões do PHP; aqui trata-se da escolha do modo de operação.
Os handlers PHP do Plesk em resumo
A visão geral seguinte baseia-se na documentação do Plesk para o Plesk Obsidian, complementada com a perspetiva de segurança. Em Linux, segundo o Plesk, os handlers FPM podem ser servidos à escolha através do Apache ou do nginx, o FastCGI sempre através do Apache.
| Handler | Servido através de | Isolação | Recomendação segundo o Plesk | Perspetiva de segurança |
|---|---|---|---|---|
| Dedicated FPM application | Apache ou nginx | pool próprio por site | Linux com alojamento partilhado | melhor separação, valores próprios por pool |
| FPM application | Apache ou nginx | pool partilhado por versão do PHP | servidores Linux dedicados | um site com falhas pode perturbar outros com a mesma versão |
| FastCGI application | Apache (Linux) | processos persistentes, boa separação | servidores Windows | sólido, em Linux geralmente substituído pelo FPM |
| Apache module (mod_php) | Apache | PHP no processo do servidor web | não recomendado | maior risco do PHP2Shell segundo a equipa do PHP |
| CGI application | Apache | novo processo por pedido | não recomendado | obsoleto |
Os antecedentes dos próprios modos de operação são explicados nas páginas PHP-FPM explicado e Porque é que o mod_php tem o maior risco.
Pool partilhado ou próprio?
A diferença entre FPM e Dedicated FPM é muitas vezes subestimada. No handler FPM normal, segundo o Plesk, todos os sites com a mesma versão do PHP partilham um pool de processos. Isso poupa memória, mas significa também: um site que cause problemas pode arrastar todos os outros com a mesma versão, e a cache comum é partilhada.
O Dedicated FPM dá a cada site um pool próprio. Segundo o Plesk, melhora a isolação e o desempenho, mas custa mais memória. Do ponto de vista da segurança, o pool próprio é a base para definir separadamente por site valores como open_basedir, limites de memória ou limites de upload. Como separar os pools de forma consequente está descrito no artigo Isolar os pools PHP-FPM por site.
nginx ou Apache: a armadilha do .htaccess
Se escolher um handler servido através do nginx, muda algo fundamental: segundo o Plesk, estes handlers ignoram o ficheiro .htaccess. O que lá está deixa de ter efeito.
Isto é uma questão de segurança. Muitas aplicações e administradores guardam regras de proteção no .htaccess, como a proibição de executar ficheiros PHP em pastas de upload ou bloqueios de ficheiros de configuração. Depois de passar para o nginx, estas regras ficam silenciosamente sem efeito. Verifique por isso, antes da mudança, que regras de proteção constam do .htaccess e transponha-as para a configuração nginx do domínio.
Uma mudança de handler é uma alteração da configuração de segurança. Depois, teste de forma dirigida se os caminhos bloqueados continuam bloqueados, e não apenas se a página inicial carrega.
Verificar e alterar o handler
Primeiro, faça um levantamento de que domínios usam que handler. Os comandos são apenas de leitura.
# Todos os handlers registados com ID, versão e tipo
plesk bin php_handler --list
# Domínios que usam um determinado handler (ID da lista)
plesk bin php_handler --get-usage -id <handler-id>
# O PHP corre no processo do Apache? (Debian/Ubuntu: apache2ctl, família RHEL: httpd)
apache2ctl -M 2>/dev/null | grep -i php
Para a alteração, proceda domínio a domínio:
- Registar as regras de proteção do
.htaccess, caso o novo handler seja servido através do nginx. - Definir para o novo handler os valores provisórios contra o PHP2Shell, como
session.upload_progress.enabled=0. No FPM, pertencem às diretivas adicionais do pool comophp_admin_value; no FastCGI atuam outras vias. - Mudar o handler nas definições de PHP do domínio, de preferência primeiro numa cópia.
- Testar as funções e verificar se o domínio é servido por processos com código atual.
- Se o módulo Apache já não for usado por nenhum domínio, desativar o handler.
Por que ordem alterar?
Num servidor Plesk que foi crescendo, raramente é possível alterar tudo num dia. Uma ordem por risco ajuda a usar bem o tempo escasso:
- Primeiro os domínios com o módulo Apache, porque aí o risco do PHP2Shell é o mais elevado segundo a equipa do PHP e o Plesk desaconselha-o de qualquer modo.
- Depois os domínios com dados sensíveis, como lojas, portais de clientes ou formulários com dados de saúde ou contratuais. Aqui o pool próprio compensa especialmente.
- A seguir os domínios em versões antigas do PHP, que de qualquer modo têm de ser migrados. Handler e versão podem ser mudados juntos numa janela de manutenção.
- No fim a passagem do pool partilhado para o pool próprio nos restantes domínios, desde que a memória do servidor o permita.
Antes do último passo, verifique a ocupação da memória. O Plesk alerta para o facto de o Dedicated FPM precisar de mais memória e aconselha a monitorização com muitos sites. Um servidor que passa a usar swap depois da migração fica lento, e uma memória escassa não é um bom estado precisamente com o PHP2Shell.
Como ajuda concretamente a PHP SOS?
- Registamos que domínios do seu servidor Plesk usam que handler e assinalamos os domínios com módulo Apache.
- Passamos para Dedicated FPM e transpomos as regras de proteção do
.htaccesspara a configuração nginx, onde necessário. - Definimos valores provisórios e limites por pool e verificamos que atuam no contexto web.
- No âmbito do hardening de servidores, desativamos handlers obsoletos e documentamos a configuração.
Perguntas frequentes
Que handler PHP recomenda o Plesk?
Segundo a documentação do Plesk, o FPM é o handler recomendado em servidores Linux dedicados, o Dedicated FPM em servidores Linux para alojamento partilhado e o FastCGI em servidores Windows. O módulo Apache, o CGI e o ISAPI são classificados pelo Plesk como muito obsoletos ou inseguros.
Porque é que o handler módulo Apache é particularmente crítico depois do PHP2Shell?
O handler corresponde ao mod_php. A equipa do PHP classifica o risco do PHP2Shell como mais elevado no mod_php, porque aí foi demonstrado um exploit antes de o código da aplicação correr. Além disso, o próprio Plesk desaconselha este handler.
O que muda se o PHP for servido através do nginx em vez do Apache?
Segundo o Plesk, os handlers servidos através do nginx ignoram o ficheiro .htaccess. As regras de segurança que lá estão, como bloqueios do PHP em pastas de upload, deixam então de funcionar e têm de ser transpostas para regras do nginx.
Tenho de reiniciar o PHP depois de mudar de handler?
Depois da mudança, verifique que processos PHP correm para o domínio e desde quando. No Dedicated FPM, o domínio recebe um pool próprio. Um processo antigo com código desatualizado já não deve trabalhar para o domínio.
O Dedicated FPM é sempre a melhor escolha?
Para a isolação, sim, porque cada site recebe um pool próprio. O preço é uma maior necessidade de memória. O Plesk aconselha a monitorizar servidores com muitos sites.