Em resumo: Para o PHP 8.1 e anteriores, já não existem atualizações oficiais do projeto PHP. O suporte de longo prazo, também chamado Extended Support, vem de distribuições Linux, repositórios de fornecedores terceiros ou serviços comerciais como o TuxCare ELS ou a Zend/HeroDevs. Pode colmatar o tempo até à atualização, se o fornecedor confirmar por escrito a cobertura da sua versão. Não substitui, porém, nem a atualização nem a manutenção do CMS e do código próprio.
Porque é que a questão surge justamente agora
A 21 de outubro de 2026 surgiram as correções do PHP2Shell apenas para os ramos suportados 8.5, 8.4, 8.3 e 8.2. Para o 7.4, 8.0 e 8.1, o projeto PHP disponibilizou apenas backports mínimos do código-fonte, ou seja, correções no código sem lançamento pronto. Segundo a imprensa especializada, estão afetadas quase todas as versões até ao PHP 5.4.
A dimensão do parque mostra-a uma análise da CybelAngel: cerca de 2,24 milhões de hosts PHP acessíveis a partir da Internet, dos quais, segundo a CybelAngel, 59 por cento em versões sem correção oficial prevista. Para muitas empresas, a questão do suporte de longo prazo deixou assim de ser teórica. E vai crescer: o PHP 8.2 chega ao fim do suporte a 31/12/2026.
O que um sistema antigo precisa de imediato descreve-o PHP 8.1 e anteriores: o que vale agora. Este artigo ajuda na questão de médio prazo: que caminho aguenta até à atualização e o que tem de oferecer?
PHP Extended Support: os caminhos em resumo
| Caminho | O que fornece | Limites |
|---|---|---|
| Manutenção de longo prazo da distribuição | Backports nos pacotes, enquanto a versão da distribuição for suportada | só para a versão do PHP que essa distribuição traz |
| Repositório de fornecedor terceiro | p. ex. sury.org, segundo relatos com builds de 5.6 a 8.5 | não é o arquivo de segurança da distribuição, questão de confiança |
| Suporte comercial de longo prazo | pacotes com patch para versões descontinuadas, p. ex. TuxCare ELS, Zend/HeroDevs | pedir confirmação da cobertura por versão e CVE, custos contínuos |
| Build próprio a partir de backports do código-fonte | builds próprios a partir das correções do projeto PHP | trabalhoso, necessário de novo a cada vulnerabilidade |
Sobre as ofertas comerciais: a TuxCare descreve no seu site correções de CVE para versões descontinuadas do PHP 5.2 ao 8.x, entregues através do gestor de pacotes existente, para Windows e distribuições Linux comuns. Uma nota na mesma página comunica correções do PHP2Shell para versões descontinuadas do PHP. Segundo a documentação do cPanel, a TuxCare promete, para vulnerabilidades a partir de CVSS 7, correções no prazo de 14 dias após a publicação; nos servidores cPanel, para isso os domínios são passados de ea-php para alt-php. Sobre a Zend/HeroDevs não dispúnhamos de nenhuma declaração sobre a cobertura do PHP2Shell.
Indicações sobre o caminho do fornecedor terceiro estão no artigo O repositório sury.org.
O que precisa do fornecedor por escrito
O suporte de longo prazo é uma prestação de confiança. Compra a promessa de que futuras vulnerabilidades serão fechadas. Antes da decisão, peça por isso resposta por escrito a estas perguntas:
- Que versões do PHP, sistemas operativos e nomes de pacotes estão exatamente cobertos?
- As CVE-2026-109618 e CVE-2026-109619 estão fechadas para a sua versão, com que estado de pacote e desde quando?
- Como se lida com a CVE-2026-115560 e futuros avisos subsequentes?
- As extensões que usa estão incluídas ou apenas o núcleo do PHP?
- Como verifica você mesmo que um patch foi aplicado, por exemplo através do changelog do pacote?
- Até quando vale a cobertura da sua versão e como é anunciado um fim?
- O que acontece aos pacotes instalados quando o contrato termina?
Respostas que remetem apenas de forma geral para “todas as vulnerabilidades de segurança” não bastam. Para auditores, seguradoras e a sua própria documentação, conta a associação concreta de versão, pacote e CVE.
Os limites: o que o suporte de longo prazo não resolve
O suporte de longo prazo mantém o runtime PHP atualizado. Tudo o que está acima continua a ser tarefa sua. E é justamente aí que, nos sistemas antigos, está geralmente o problema maior.
- A aplicação continua a desatualizar-se: um CMS ou loja que precisa do PHP 8.1 muitas vezes já nem está em uso na versão atual.
- Bibliotecas e extensões: pacotes Composer e plugins muitas vezes deixam de receber atualizações para versões antigas do PHP.
- Não substitui reinício e verificação: também os pacotes com patch só atuam depois do reinício de todos os processos PHP, e não removem software malicioso introduzido antes.
- A dívida técnica cresce: quanto mais longa a ponte, maior o salto na migração posterior.
- Os comprovativos dão mais trabalho: auditores, clientes e seguradoras perguntam cada vez mais pelo estado do patch. Uma versão do PHP descontinuada com patches de terceiros pode ser comprovada, mas exige mais explicação do que uma versão suportada.
Quando é o suporte de longo prazo, ainda assim, a escolha certa? Há três situações típicas: uma aplicação especializada cujo fabricante ainda não autoriza versões mais recentes do PHP; um sistema antigo cuja substituição já foi decidida e que só deve funcionar mais alguns meses; ou uma grande base de código cuja migração tem de ser cuidadosamente planeada. Nos três casos, o suporte de longo prazo compra tempo para uma solução ordenada. Não é uma solução para sistemas de que ninguém quer cuidar.
Se um sistema antigo esteve desprotegido na Internet entre 17 e 21 de outubro, esclareça primeiro se está comprometido. O suporte de longo prazo para um sistema já infetado não protege nada.
Um plano de saída faz parte
O suporte de longo prazo é uma boa decisão quando termina numa data. Defina até quando a aplicação deve correr numa versão suportada, quem é responsável pela migração e que metas intermédias valem. Durante quanto tempo os ramos do PHP são oficialmente mantidos explica-o O ciclo de lançamento do PHP.
Se compensa mais, para o seu sistema, uma atualização ou um backport pondera-o o artigo Atualização do PHP ou backport?.
Como ajuda concretamente a PHP SOS?
- Avaliar a situação: verificamos versão, fonte dos pacotes e estado do patch dos seus sistemas antigos e se mostram vestígios de um ataque.
- Avaliar ofertas: comparamos as garantias escritas de um fornecedor de suporte de longo prazo com o seu parque real.
- Proteger a ponte: até à atualização, aplicamos as medidas provisórias do php.net e restringimos a acessibilidade.
- Executar a saída: com a migração do PHP 8.1 e anteriores, planeamos e testamos a mudança para uma versão suportada.
Perguntas frequentes
O que é o PHP Extended Support?
São ofertas que continuam a fornecer correções de segurança a versões do PHP depois do fim oficial do suporte. Podem ser distribuições Linux, repositórios de fornecedores terceiros ou serviços comerciais como o TuxCare ELS ou a Zend/HeroDevs.
O suporte comercial de longo prazo cobre o PHP2Shell?
A TuxCare indica no seu site ter disponibilizado correções do PHP2Shell para versões descontinuadas do PHP. Para a sua versão, o seu pacote e o seu sistema operativo concretos, deve ainda assim pedir confirmação por escrito e verificar no changelog.
O suporte de longo prazo é uma alternativa à atualização?
Apenas por um tempo. Mantém o runtime PHP com patch, mas não o CMS, as extensões e o código próprio, que muitas vezes também estão desatualizados. Uma data de saída pertence por isso a qualquer decisão de suporte de longo prazo.
O que acontece quando o contrato de suporte de longo prazo termina?
Segundo a documentação do cPanel sobre a TuxCare, os pacotes instalados continuam a funcionar, mas deixam de receber novas atualizações de segurança. O sistema fica então outra vez na mesma situação de antes, só que mais tarde.
O tema aplica-se também ao PHP 8.2?
Sim, em breve. O PHP 8.2 recebe com a 8.2.35 ainda a correção do PHP2Shell, mas chega ao fim do suporte a 31/12/2026. Quem opera a 8.2 deve planear a mudança já.