Em resumo: se a atualização do PHP ou o backport é a escolha certa depende de quanto tempo o seu sistema ainda deve funcionar e de quão bem está comprovado o backport. Um backport da própria distribuição num sistema operativo suportado é um caminho de pleno valor. Backports de código-fonte, fontes de terceiros e suporte comercial de longo prazo para o PHP 8.1 e anteriores são pontes com data de validade. A longo prazo, só ajuda a mudança para uma versão do PHP que o projeto PHP ainda suporte oficialmente.
Porque é que a pergunta é urgente depois do PHP2Shell
A 21/10/2026, o projeto PHP corrigiu o PHP2Shell nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Para o PHP 8.1 e anteriores já não existem versões oficiais, apenas backports mínimos de código-fonte para 7.4, 8.0 e 8.1. Segundo a imprensa especializada, estão afetadas praticamente todas as versões até ao PHP 5.4.
Com isto, muitos operadores de sistemas antigos enfrentam a mesma pergunta: basta remendar a vulnerabilidade de alguma forma, ou é agora que tem de vir a atualização de versão adiada há anos? O que uma atualização significa na prática descreve-o a nossa oferta de migração do PHP 8.1 e anteriores. O que se aplica sem atualização oficial está em PHP 8.1 e anteriores: o que se aplica agora. Este artigo ajuda na ponderação entre os dois.
Que tipos de backports existem
«Backport» é um termo genérico. Significa sempre que uma correção de uma versão mais recente é transferida para uma mais antiga. Quem o faz e quão bem é verificado difere, porém, muito.
- Backport da distribuição: o Debian, o Ubuntu, a Red Hat e outros incorporam correções de segurança nos pacotes PHP das suas versões suportadas. O número de versão mantém-se muitas vezes igual; segundo relatórios, o Ubuntu 24.04, por exemplo, continua a mostrar 8.3.6 depois da atualização. A correção comprova-se através do changelog do pacote e dos alertas de segurança da distribuição.
- Fonte de terceiros: o repositório sury.org de Ondřej Surý disponibilizou, segundo relatórios, compilações para todos os ramos de 5.6 a 8.5. Não é o arquivo de segurança do Debian. Os pormenores estão em O repositório sury.org.
- Backport de código-fonte do projeto PHP: para 7.4, 8.0 e 8.1 existem patches mínimos no código-fonte, mas não versões prontas. Quem os usa tem de compilar o PHP, testá-lo e, no futuro, mantê-lo por si próprio.
- Suporte comercial de longo prazo: fornecedores como o TuxCare ELS ou a Zend/HeroDevs oferecem manutenção para versões antigas. Se e quando cobrem o PHP2Shell tem de ser confirmado por escrito; nas fontes conhecidas isso não estava comprovado. Mais sobre isto em Suporte de longo prazo para versões antigas do PHP.
Atualização do PHP ou backport: a comparação
| Critério | Atualização para versão suportada | Backport (consoante o tipo) |
|---|---|---|
| Proteção contra o PHP2Shell | Sim, com 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 | Sim, se completo e comprovado |
| Futuras atualizações de segurança | Oficiais até ao fim do suporte da versão | Só enquanto o respetivo fornecedor der manutenção |
| Comprovativo | Número de versão mais reinício | Changelog do pacote com números CVE, confirmação do fornecedor |
| Esforço agora | Médio a elevado, são necessários testes de compatibilidade | Baixo na distribuição, elevado na compilação própria |
| Esforço mais tarde | Baixo até ao próximo salto de versão | Cresce com cada nova vulnerabilidade |
| Risco para a aplicação | Incompatibilidades com código e extensões antigos | Baixo, o comportamento mantém-se em grande parte |
| Adequação como solução duradoura | Sim | Só o backport da distribuição, no âmbito de um sistema operativo suportado |
A linha «Esforço mais tarde» é a mais importante. O PHP2Shell não terá sido a última vulnerabilidade. Cada mês numa versão sem suporte oficial significa que o próximo alerta volta a levantar a mesma pergunta.
Que versão de destino na atualização?
Segundo o php.net, para cada ramo do PHP aplica-se: dois anos de suporte ativo e depois dois anos apenas de correções de segurança. Daí resultam estas datas finais do suporte de segurança:
| Versão | Suporte de segurança até |
|---|---|
| PHP 8.2 | 31/12/2026 |
| PHP 8.3 | 31/12/2027 |
| PHP 8.4 | 31/12/2028 |
| PHP 8.5 | 31/12/2029 |
Uma atualização para a 8.2 é por isso apenas uma curta etapa intermédia. Quem de qualquer modo migra deve apontar a uma versão com horizonte mais longo, desde que o CMS, a loja e as extensões a suportem. Verifique-o nos requisitos de sistema do fabricante, e não de memória. Como funciona o ciclo de lançamento, explica-o Versões do PHP e ciclo de lançamento.
Seja qual for o caminho: depois da instalação, todos os processos PHP têm de ser reiniciados. Um backport que está apenas no disco não protege enquanto houver workers antigos em memória.
Uma sequência pragmática para sistemas antigos
- De imediato: aplicar medidas provisórias segundo o php.net ou retirar o sistema temporariamente da rede, se não houver correção comprovada disponível.
- Nos próximos dias: instalar um backport comprovado, de preferência da própria distribuição ou com confirmação escrita do fornecedor.
- Em paralelo: verificar a compatibilidade da aplicação com uma versão suportada e definir um calendário.
- Nos próximos meses: atualização para a versão de destino, preparada numa cópia de teste, com plano de recurso.
Ver o backport como ponte, e não como destino, é a ideia decisiva.
Quando não precisa de um prestador de serviços para isto
Se o seu servidor corre num Debian, Ubuntu ou RHEL suportado e a distribuição fornece o backport, bastam uma atualização regular com reinício e um olhar ao changelog. Um administrador experiente consegue fazê-lo sozinho. A ajuda compensa em compilações próprias, fontes de terceiros, versões muito antigas ou numa aplicação cuja compatibilidade ninguém consegue já avaliar.
Como ajuda concretamente a PHP SOS?
- Verificamos que versões do PHP e fontes de pacotes correm nos seus servidores e se existe uma correção comprovada.
- Instalamos backports, reiniciamos e documentamos o comprovativo através do changelog.
- Testamos a sua aplicação numa cópia contra a versão de destino e identificamos incompatibilidades.
- Planeamos e acompanhamos a atualização no âmbito da migração do PHP 8.1 e anteriores.
Conclusão
O backport da distribuição é um caminho de pleno valor, todos os outros backports são pontes. Quem está preso ao PHP 8.1 ou anterior deve usar o backport para ganhar tempo para a atualização, e não para a adiar ainda mais.
Perguntas frequentes
Um backport é tão seguro como uma atualização de versão?
Para a vulnerabilidade concretamente corrigida, um backport pode ser equivalente, se for completo e comprovado. Corrige, porém, apenas o que foi retroportado. Uma atualização para uma versão suportada traz, além disso, todas as futuras atualizações de segurança oficiais.
Como reconheço que o meu backport cobre o PHP2Shell?
Pelo changelog do pacote: aí devem constar os números CVE CVE-2026-109618 e CVE-2026-109619. No Debian e no Ubuntu, mostra-o o apt-get changelog; na família RHEL, o rpm -q --changelog. O número de versão, por si só, não é prova.
Durante quanto tempo o PHP 8.2 ainda recebe atualizações de segurança?
Segundo o php.net, o suporte de segurança do PHP 8.2 termina a 31/12/2026. Quem hoje atualiza para a 8.2 deve por isso planear logo também o passo seguinte.
Compensa o suporte comercial de longo prazo para versões antigas do PHP?
Pode ser uma ponte quando uma atualização de versão é impossível a curto prazo. Peça confirmação escrita de se e a partir de quando o PHP2Shell está coberto. Nas fontes conhecidas até agora, isso não estava comprovado.