# Servidores Plesk: verificar e aplicar patches às versões PHP

> Atualização PHP no Plesk após o PHP2Shell: como verificar handlers, pacotes e backports, reiniciar todos os serviços PHP-FPM e comprovar o patch de forma fiável.

Fonte: https://phpsos.de/pt/server/plesk/  
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:** 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.

> **Importante:**
> 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.

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

```bash
# 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](https://phpsos.de/pt/ratgeber/hoster-patch-status-erfragen/).

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

```bash
# 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](https://phpsos.de/pt/php2shell/php-fpm-neustart/).

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

```ini
; 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](https://phpsos.de/pt/php2shell/sofortmassnahmen-ohne-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](https://phpsos.de/pt/leistungen/php-patch-service/), 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](https://phpsos.de/pt/leistungen/incident-response/).
- 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.

## Fontes

- [php.net: avisos de segurança](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: versões suportadas](https://www.php.net/supported-versions.php)
- [BSI (Gabinete Federal Alemão para a Segurança da Informação)](https://www.bsi.bund.de/)