# Serviço de patches PHP: atualização com reinício e comprovativo

> Atualização do PHP feita por nós: aplicamos patches nas versões corrigidas, reiniciamos todos os workers e comprovamos o estado por escrito. Para empresas e agências.

Fonte: https://phpsos.de/pt/leistungen/php-patch-service/  
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:** quem quer mandar instalar uma atualização do PHP precisa de mais do que pacotes novos: o que conta é o estado de pacote correto, o reinício de todos os processos PHP e uma prova disso. É exatamente isso que o nosso serviço de patches PHP entrega. Recebe um comprovativo escrito por servidor, que pode apresentar internamente ou a terceiros.

## Porque é que uma atualização do PHP, por si só, muitas vezes não basta

Desde 21/10/2026 existem patches para as vulnerabilidades PHP2Shell CVE-2026-109618 e CVE-2026-109619. O BSI recomenda a atualização imediata. Na prática, vemos três obstáculos típicos.

Primeiro, o número de versão nem sempre mostra o estado real. As distribuições e os fornecedores de alojamento aplicam por vezes backports; então o Plesk, por exemplo, continua a indicar 8.2.34, embora o estado do pacote tenha o patch aplicado. Segundo, depois da instalação continuam muitas vezes a correr processos PHP antigos. Ficheiros novos no disco não protegem enquanto os workers antigos estiverem a trabalhar na memória. Terceiro, num servidor correm frequentemente várias versões do PHP em paralelo, e uma delas é esquecida.

## Mandar instalar a atualização do PHP: as versões corrigidas

| Ramo | Corrigido a partir de | Estado anterior | Nota |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.11 | verificar adicionalmente `fatal_error_backtraces` |
| PHP 8.4 | 8.4.27 | 8.4.26 | |
| PHP 8.3 | 8.3.36 | 8.3.35 | |
| PHP 8.2 | 8.2.35 | 8.2.34 | o suporte termina a 31/12/2026 |
| PHP 8.1 e anteriores | sem atualizações oficiais | – | apenas backports mínimos do código-fonte para 7.4, 8.0, 8.1 |

Nos pacotes de distribuições ou de fornecedores de alojamento, não conta o número a seguir a “PHP”, mas o estado do pacote que o fornecedor confirma como tendo o patch aplicado. Como pode verificá-lo por si, vê-se em [Verificar corretamente a versão do PHP e o nível de patch](https://phpsos.de/pt/php2shell/php-version-pruefen/).

## Como ajuda concretamente a PHP SOS?

1. **Inventário:** registamos todas as instalações PHP no servidor, o modo de operação (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed) e que site usa que versão.
2. **Instalar a atualização:** instalamos as versões corrigidas a partir da fonte de pacotes da sua distribuição, do seu painel ou do projeto oficial. Para contentores, construímos consigo novas imagens.
3. **Reinício de todos os processos:** reiniciamos por completo o PHP-FPM, o Apache, o LiteSpeed ou os respetivos workers e verificamos que nenhum processo é mais antigo do que a atualização. Os antecedentes constam de [Reiniciar o PHP-FPM e todos os workers](https://phpsos.de/pt/php2shell/php-fpm-neustart/).
4. **Verificação de funcionamento:** acedemos às páginas e funções mais importantes, por exemplo a página inicial, o início de sessão, os formulários e o checkout, e verificamos os registos de erros.
5. **Comprovativo:** recebe, por servidor, um protocolo com a versão, o estado do pacote, o momento do reinício e os pontos em aberto.

Um passo de verificação típico depois do reinício é este:

```bash
# versão da CLI do PHP e do binário FPM (caminho conforme o sistema)
php -v
php-fpm8.3 -v
# hora de arranque dos processos FPM: tem de ser posterior à atualização
ps -o pid,lstart,cmd -C php-fpm8.3
```

## Casos especiais: painéis, contentores e várias versões do PHP

Em servidores com **Plesk ou cPanel**, as versões do PHP vêm muitas vezes das fontes de pacotes do painel e não da distribuição. Aí verificamos cada versão instalada individualmente, mesmo as que de momento não estão atribuídas a nenhum site. As versões antigas e não utilizadas, removemo-las após acordo, para que não sejam reativadas por engano.

Em ambientes **Docker e Kubernetes**, uma atualização no anfitrião não basta. O PHP está na imagem, e só uma imagem reconstruída com a base já corrigida, distribuída por todos os contentores em execução, fecha a vulnerabilidade. Verificamos também se imagens mais antigas continuam a ser usadas em registos ou em deployments. Os pormenores constam de [Aplicar patches ao PHP em contentores Docker](https://phpsos.de/pt/php2shell/docker-container-patchen/).

No **mod_php**, o PHP corre diretamente no processo do Apache. A equipa do PHP classifica aí o risco como o mais elevado. Depois da atualização, o próprio Apache tem por isso de ser totalmente reiniciado; um simples recarregamento da configuração nem sempre basta.

## O que recebe de nós

- um protocolo de patch por servidor: pacotes instalados, versões, fonte, momento
- a prova de que todos os processos PHP foram reiniciados
- uma lista dos sites e funções verificados
- indicações sobre sistemas a que não foi possível aplicar o patch, com fundamentação
- uma recomendação para o passo seguinte, por exemplo no caso do PHP 8.2, devido ao fim próximo do suporte

## O que precisamos de si

- **Acesso:** SSH com direitos de administrador ou acesso ao painel (Plesk, cPanel ou semelhante)
- **Janela de manutenção:** quando é permitido um breve reinício
- **Interlocutor:** para dúvidas e para a aprovação depois da verificação de funcionamento
- **Cópias de segurança:** confirmação de que existe uma cópia atual ou a incumbência de criar uma antes
- **Indicações sobre desenvolvimentos próprios:** extensões PHP ou configurações especiais que devam ser respeitadas

Em alojamento partilhado sem acesso próprio ao servidor, não podemos aplicar o patch nós mesmos. Ajudamo-lo então a colocar as perguntas certas ao fornecedor de alojamento e a avaliar a resposta.

## O que não prometemos

O serviço de patches fecha a vulnerabilidade conhecida. Não responde se o servidor já tinha sido comprometido antes da atualização e não remove software malicioso introduzido. Se quiser saber isso, a encomenda adequada é a [ajuda imediata PHP2Shell](https://phpsos.de/pt/leistungen/php2shell-soforthilfe/) com busca de vestígios.

Para o PHP 8.1 e anteriores já não existem atualizações oficiais. Aqui aplicamos medidas provisórias e recomendamos a [migração para uma versão suportada](https://phpsos.de/pt/leistungen/php-migration-legacy/). Não damos uma garantia de compatibilidade para o seu CMS de memória, mas verificamo-la com base nos requisitos de sistema do fabricante.


## Perguntas frequentes

**Porque é que o meu servidor ainda mostra a versão antiga do PHP depois da atualização?**  
Pode haver duas razões. Ou a distribuição aplicou um backport, e então o número de versão fica igual, embora o estado do pacote tenha o patch aplicado. Ou ainda correm processos PHP antigos na memória, que têm de ser reiniciados.

**Que versões do PHP corrigem o PHP2Shell?**  
A vulnerabilidade está corrigida no PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, publicados a 21/10/2026. Nos pacotes de distribuições conta o estado do pacote que o fornecedor confirma como tendo o patch aplicado.

**A atualização pode deixar o meu site inoperacional?**  
Uma atualização dentro da mesma versão principal, por exemplo de 8.3.35 para 8.3.36, é em regra pouco crítica. É no entanto necessário um breve reinício dos processos PHP. Combinamos consigo a janela de tempo e verificamos as páginas depois.

**Com o patch fica tudo resolvido?**  
Quanto à vulnerabilidade em si, sim, assim que todos os processos forem reiniciados. Se alguém já tinha entrado antes do patch, o patch não o mostra. Para isso é necessária uma verificação própria.

## 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/)