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, a vista geral completa em Que versões do PHP estão afetadas?.
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.
- 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, 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:
# 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:
- 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.
- Verificar a compatibilidade: CMS, extensões, temas e código próprio. As indicações constam da página oficial de cada fabricante.
- Montar o staging: uma cópia do site com a nova versão do PHP, incluindo a base de dados.
- Testar: todos os processos importantes, do formulário de contacto ao processo de encomenda, e ainda o registo de erros quanto a avisos.
- 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.
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.