# PHP End of Life: riscos de versões desatualizadas

> Perceber o PHP End of Life: o que acontece após o fim do suporte, porque o PHP 8.1 e anteriores são críticos após o PHP2Shell e como planear a migração para 8.2+.

Fonte: https://phpsos.de/pt/ratgeber/php-end-of-life-risiken/  
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:** PHP End of Life significa que o projeto PHP já não disponibiliza atualizações de segurança para esse ramo. O PHP2Shell mostra claramente as consequências, pois para o PHP 8.1 e anteriores não há correção oficial, e o PHP 8.2 termina a 31/12/2026. Quem hoje corre num ramo antigo deve planear agora a migração, e não só na próxima emergência.

## O que significa PHP End of Life

Cada ramo do PHP, por exemplo 8.2 ou 8.3, é mantido pelo projeto PHP apenas durante um período limitado. Primeiro há correções de erros e atualizações de segurança, mais tarde só atualizações de segurança. Depois, o suporte termina por completo. Os períodos atuais são publicados pelo php.net na página das versões suportadas.

Após o fim do suporte, o software continua a funcionar. Mas se for conhecida uma nova vulnerabilidade, o projeto PHP já não disponibiliza patch. O servidor continua vulnerável até que outra entidade faça a correção ou até mudar para um ramo suportado.

Para a gestão e a direção de TI, trata-se sobretudo de uma questão de planeamento. Uma migração pode ser preparada com calma. Sob pressão de tempo, após um aviso crítico, torna-se cara e arriscada.

## O que o PHP2Shell mostra sobre versões desatualizadas

A 21/10/2026, o projeto PHP publicou patches para duas vulnerabilidades críticas, CVE-2026-109618 e CVE-2026-109619. Ambas permitem a execução remota de código malicioso sem autenticação e têm a classificação 9,2 no CVSS v4.0. Segundo a imprensa especializada, quase todas as versões até ao PHP 5.4 estão afetadas.

| Ramo | Estado segundo o projeto PHP | Correção do PHP2Shell |
|---|---|---|
| PHP 8.5 | suportado | 8.5.12 |
| PHP 8.4 | suportado | 8.4.27 |
| PHP 8.3 | suportado | 8.3.36 |
| PHP 8.2 | suportado até 31/12/2026 | 8.2.35 |
| PHP 8.1, 8.0, 7.4 | sem atualizações oficiais | apenas backports mínimos do código-fonte |
| PHP 7.3 e anteriores | sem atualizações oficiais | sem backport do projeto PHP |

Para o 8.1 e anteriores resta, assim, apenas o caminho dos backports de distribuições ou fornecedores de alojamento. Estes continuam muitas vezes a mostrar o número de versão antigo, embora estejam corrigidos. Se um backport está instalado, só o fornecedor o pode confirmar de forma vinculativa. Pormenores estão na página [PHP 8.1 e anteriores: o que se aplica agora](https://phpsos.de/pt/php2shell/php-8-1-und-aelter/), a vista geral completa em [Que versões do PHP estão afetadas?](https://phpsos.de/pt/php2shell/betroffene-php-versionen/).

> **Importante:**
> O PHP 8.2 ainda recebeu a correção do PHP2Shell, mas chega ao fim do suporte a 31/12/2026. Quem migra agora do 8.1 deve apontar diretamente para um ramo mais recente.

## Os riscos das versões PHP desatualizadas em resumo

O risco de segurança está em primeiro plano, mas não é o único. As versões PHP desatualizadas trazem outros problemas:

- **Sem patches para novas vulnerabilidades:** qualquer fragilidade futura permanece aberta ou depende de backports de terceiros.
- **Bibliotecas desatualizadas:** os pacotes atuais exigem ramos mais recentes do PHP. As correções de segurança em bibliotecas já não podem então ser instaladas, como mostra o guia [composer audit](https://phpsos.de/pt/ratgeber/composer-abhaengigkeiten-pruefen/).
- **Dependência do fornecedor:** os fornecedores de alojamento cobram por vezes sobretaxas por versões antigas ou terminam a operação. O prazo é então determinado pelo fornecedor, não por si.
- **Problemas de comprovação:** perante seguradoras, clientes ou em auditorias, uma versão não suportada é difícil de justificar. Se daí resultam consequências contratuais ou jurídicas, esclareça-o com a seguradora ou um advogado.
- **Esforço de migração crescente:** quanto maior a distância à versão atual, mais código tem de ser ajustado.

São afetados com especial frequência os sistemas de loja mais antigos e os desenvolvimentos à medida que há muito ninguém toca. Um exemplo típico é o [Shopware 5](https://phpsos.de/pt/plattformen/shopware-5/), que muitas vezes ainda corre em ramos mais antigos do PHP.

## Inventário: que versões do PHP correm no seu caso?

O primeiro passo é uma imagem completa. Em muitos servidores correm várias versões do PHP em paralelo, por exemplo para um site antigo de que já ninguém se lembra. Estes comandos apenas leem:

```bash
# Versão da linha de comandos
php -v
# Versões instaladas em Debian/Ubuntu
ls /etc/php/
# Versões instaladas no Plesk
ls /opt/plesk/php/ 2>/dev/null
# Processos PHP em execução com a versão no nome
ps -eo user,cmd | grep -E "[p]hp-fpm|[p]hp[0-9.]*-cgi|[l]sphp" | sort | uniq -c
```

Registe para cada site: domínio, versão do PHP, modo de operação, CMS com versão, pessoa responsável. Esta lista é também a base do seu plano de emergência. No alojamento partilhado, as versões encontram-se geralmente no menu de cliente do fornecedor.

## Planear a migração: como proceder

Uma migração para um ramo suportado segue, em regra, os mesmos passos, independentemente do sistema:

1. **Definir o objetivo:** escolher um ramo que, segundo o php.net, seja suportado durante o maior tempo possível e que, segundo os requisitos de sistema do fabricante, seja compatível com o seu CMS.
2. **Verificar a compatibilidade:** CMS, extensões, temas e código próprio. As indicações constam da página oficial de cada fabricante.
3. **Montar o staging:** uma cópia do site com a nova versão do PHP, incluindo a base de dados.
4. **Testar:** todos os processos importantes, do formulário de contacto ao processo de encomenda, e ainda o registo de erros quanto a avisos.
5. **Mudar e reiniciar:** trocar a versão, reiniciar todos os processos PHP, verificar o funcionamento e o registo de erros.

Planeie de forma realista. Um site pequeno com um CMS atual é muitas vezes migrado depressa. Uma loja crescida ao longo de anos, com muitas extensões e código próprio, pode, em contrapartida, exigir um ajuste do código e das extensões, até à mudança para uma nova versão principal do sistema de loja. Esclareça cedo quem decide internamente, que orçamento está disponível e se é preciso envolver programadores externos.

Defina também como vai acompanhar no futuro os fins de suporte. Uma data fixa por ano, em que compara a lista dos seus sites com as indicações do php.net, evita que o mesmo estrangulamento volte a surgir daqui a dois anos.

Até à migração, deve usar as medidas transitórias do php.net, por exemplo `session.upload_progress.enabled=0` na configuração do servidor. Não são uma proteção completa, mas reduzem o risco.

## Como ajuda concretamente a PHP SOS?

- Registamos todas as versões do PHP, modos de operação e aplicações nos seus servidores.
- Avaliamos o risco por site e definimos consigo a ordem e a versão de destino.
- Aplicamos medidas transitórias até à migração e obtemos do fornecedor confirmações sobre backports.
- Migramos através de um ambiente de staging e documentamos o teste e a mudança.

O procedimento está descrito no serviço [PHP 8.1 e anteriores: migração para uma versão suportada](https://phpsos.de/pt/leistungen/php-migration-legacy/).


## Perguntas frequentes

**Quando termina o suporte ao PHP 8.2?**  
O PHP 8.2 chega ao fim do suporte do projeto PHP a 31/12/2026. O ramo ainda recebeu a correção do PHP2Shell com a versão 8.2.35; para vulnerabilidades posteriores, depois disso já não é de esperar nenhuma atualização oficial.

**O PHP 8.1 recebe um patch contra o PHP2Shell?**  
O projeto PHP já não disponibiliza atualizações oficiais para o 8.1 e anteriores. Existem apenas backports mínimos do código-fonte para 7.4, 8.0 e 8.1. Se e como o seu fornecedor de alojamento ou a sua distribuição os instala, tem de perguntar ao fornecedor.

**Uma versão antiga do PHP com backports do fornecedor de alojamento é segura?**  
Os backports podem fechar vulnerabilidades concretas, mas não substituem um ramo suportado. Dependem do fornecedor, chegam muitas vezes mais tarde e não cobrem todas as vulnerabilidades. Como solução permanente são, por isso, inadequados.

**Como sei se o meu CMS funciona com uma versão nova do PHP?**  
Verifique os requisitos de sistema na página oficial do fabricante e teste num ambiente de staging. O mesmo vale para extensões e temas, que muitas vezes são o verdadeiro estrangulamento.

## Fontes

- [php.net: versões suportadas](https://www.php.net/supported-versions.php)
- [php.net: avisos de segurança](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)