Em resumo: uma atualização PHP no Plesk só está concluída quando cada versão PHP instalada tem um nível corrigido, todos os serviços PHP-FPM foram reiniciados e o consegue comprovar com o nível dos pacotes e a hora de arranque dos processos. O número de versão mostrado no painel não chega, porque os backports muitas vezes o deixam inalterado.
O que está em causa com o PHP2Shell nos servidores Plesk
PHP2Shell designa duas vulnerabilidades críticas no próprio PHP (CVE-2026-109618 e CVE-2026-109619, ambas com CVSS v4.0 9.2). Permitem que atacantes executem código no servidor sem autenticação. Estão afetados, entre outros, o PHP-FPM e o Apache com mod_php, ou seja, precisamente os modos de operação que o Plesk configura para os sites.
A 21/10/2026, o projeto PHP publicou as versões corrigidas 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Para o PHP 8.1 e anteriores já não existem atualizações oficiais. Os servidores Plesk têm uma particularidade: aqui correm muitas vezes várias versões PHP lado a lado, umas instaladas pelo próprio Plesk, outras pelo sistema operativo. Cada uma precisa da sua própria verificação.
Uma atualização no painel substitui ficheiros no disco. Enquanto houver processos PHP antigos em memória, a vulnerabilidade continua aberta. Sem reiniciar todos os workers, o patch não tem efeito.
Atualização PHP no Plesk: primeiro, levantar o inventário
Antes de atualizar seja o que for, reúna uma lista de todos os handlers PHP e dos domínios que os usam. Consegue-o através do painel (Ferramentas e definições, Definições do PHP) ou pela linha de comandos. Os comandos seguintes não alteram nada, apenas leem.
# Todos os handlers PHP registados, com versão e caminho
plesk bin php_handler --list
# Versão de cada versão PHP instalada pelo Plesk (caminho como exemplo)
for p in /opt/plesk/php/*/bin/php; do echo "$p"; "$p" -v | head -1; done
Anote para cada handler: a versão, o modo de operação (FPM, FastCGI, módulo Apache) e o número de domínios. Handlers sem domínio não são motivo para descansar. Podem ser atribuídos mais tarde ou correr em subdomínios de teste.
Verificar o nível dos pacotes, não o que é mostrado
O Plesk mostra o número de versão que o próprio PHP comunica. Se o Plesk ou a distribuição entregarem a correção como backport, pode continuar a aparecer, por exemplo, 8.2.34, embora a correção esteja incluída. Inversamente, um número que parece atual pode enganar se um pacote ainda não tiver sido atualizado. Contam o nível dos pacotes instalados e a confirmação escrita do fornecedor.
# Debian/Ubuntu (nomes de pacotes como exemplo)
dpkg -l | grep -E 'plesk-php|php[0-9.]+-(fpm|cli)'
# AlmaLinux/Rocky/RHEL (nomes de pacotes como exemplo)
rpm -qa | grep -E 'plesk-php|^php' | sort
Compare as versões dos pacotes com as indicações dos registos de alterações do Plesk e com as notas da sua distribuição. Se aí não estiver documentado de forma inequívoca que a CVE-2026-109618 e a CVE-2026-109619 estão corrigidas, pergunte ao fornecedor. Encontra um modelo em Perguntar ao fornecedor de alojamento o nível de patch.
Instalar a atualização e reiniciar todos os workers
A atualização propriamente dita faz-se através do instalador do Plesk ou da gestão de pacotes do sistema. Segue-se o passo que mais vezes falta: o reinício. No Plesk, cada versão PHP tem o seu próprio serviço FPM. Reinicie todos, não apenas o do domínio principal.
# Listar todos os serviços PHP-FPM (nomes de serviço como exemplo)
systemctl list-units --type=service | grep -i 'php.*fpm'
# Reiniciar cada serviço, por exemplo:
systemctl restart plesk-php84-fpm
# Verificar a hora de arranque dos processos PHP em execução
ps -eo pid,lstart,cmd | grep -E 'php-fpm|php-cgi' | grep -v grep
Se um domínio correr com Apache e mod_php, reinicie o Apache por completo. Se a hora de arranque de um processo PHP for anterior à atualização, ele ainda não foi renovado. Encontra mais sobre este passo em Reiniciar o PHP-FPM e todos os workers.
Proteção provisória enquanto a atualização não existe
Se ainda não houver patch para uma versão, o php.net recomenda medidas provisórias. Não são uma proteção completa. No Plesk, defina os valores que as aplicações não podem sobrescrever como php_admin_value nas diretivas FPM adicionais do domínio ou, para todo o servidor, no php.ini da respetiva versão.
; Exemplo de diretivas PHP-FPM adicionais no Plesk
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
Para uploads, o php.net prevê post_max_size = 32M, com upload_max_filesize abaixo disso. No PHP 8.5 acresce fatal_error_backtraces=0. A remoção do limite de memória com memory_limit=-1 só deve ser usada em conjunto com um limite ao nível do contentor ou do cgroup. Depois, volta a ser necessário reiniciar todos os workers. Os pormenores estão em Medidas imediatas sem patch. O BSI (Gabinete Federal Alemão para a Segurança da Informação) recomenda retirar temporariamente os servidores web da rede quando a atualização não for possível de imediato.
Depois do patch: preservar os registos e procurar vestígios
Um patch fecha a vulnerabilidade para o futuro. Não remove software malicioso introduzido antes e não prova que não aconteceu nada. Por isso, guarde os registos do servidor web a partir de 20/10/2026. O Plesk guarda-os por domínio no diretório logs; nesta situação, não reduza o período de conservação.
Preste atenção a ficheiros PHP novos ou alterados nos diretórios de upload, a tarefas agendadas desconhecidas e a novas contas de administrador. Até agora não existem Indicators of Compromise publicados e confirmados; a deteção assenta em análise de comportamento. Se encontrar anomalias, não continue por conta própria: preserve primeiro o estado.
Como ajuda concretamente a PHP SOS?
- Levantamos todos os handlers PHP do seu servidor Plesk, associamos os domínios e verificamos o nível real dos pacotes de cada versão.
- No âmbito do nosso serviço de patches PHP, instalamos as atualizações, reiniciamos todos os serviços e documentamos as horas de arranque dos processos como comprovativo.
- Onde falta um patch, aplicamos as medidas provisórias segundo o php.net em todo o servidor e de forma a não poderem ser sobrescritas.
- Preservamos os registos e procuramos vestígios de comprometimento, em caso de achado com resposta a incidentes.
- Depois, reforçamos o servidor de forma duradoura e removemos as versões PHP desnecessárias.
Perguntas frequentes
Porque é que o Plesk continua a mostrar PHP 8.2.34 depois da atualização?
As distribuições e os fornecedores aplicam por vezes as correções de segurança como backport, sem alterar o número de versão. Contam então o nível dos pacotes e a confirmação do fornecedor. O que o painel mostra não prova, por si só, nem que há patch nem que não há.
Basta clicar em Atualizar no painel do Plesk?
A atualização coloca ficheiros novos, mas os processos PHP em execução continuam a trabalhar com o código antigo que está na memória. Só depois de reiniciar todos os serviços PHP-FPM e o servidor web é que o novo nível fica ativo. Verifique depois a hora de arranque dos processos.
Tenho de aplicar patch também às versões PHP que nenhum domínio usa?
Sim, enquanto permanecerem instaladas. Um handler sem uso pode ser atribuído por engano mais tarde ou ficar acessível através de ambientes de teste. As versões desnecessárias é melhor desinstalá-las por completo.
Uma atualização do WordPress no Plesk Toolkit ajuda contra o PHP2Shell?
Não. O PHP2Shell afeta o próprio PHP, não o CMS. Uma atualização do CMS continua a fazer sentido, mas não fecha esta vulnerabilidade.