# Atualização do PHP ou backport? A decisão para sistemas antigos

> Atualização do PHP ou backport após o PHP2Shell? Que tipos de backport existem, o que valem e quando só a mudança para uma versão suportada ajuda.

Fonte: https://phpsos.de/pt/blog/php-upgrade-oder-backport/  
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:** 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](https://phpsos.de/pt/leistungen/php-migration-legacy/). O que se aplica sem atualização oficial está em [PHP 8.1 e anteriores: o que se aplica agora](https://phpsos.de/pt/php2shell/php-8-1-und-aelter/). 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.

1. **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.
2. **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](https://phpsos.de/pt/blog/sury-repository-php/).
3. **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.
4. **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](https://phpsos.de/pt/blog/langzeitsupport-alte-php-versionen/).

## 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](https://phpsos.de/pt/php/release-zyklus/).

> **Importante:**
> 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

1. **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.
2. **Nos próximos dias:** instalar um backport comprovado, de preferência da própria distribuição ou com confirmação escrita do fornecedor.
3. **Em paralelo:** verificar a compatibilidade da aplicação com uma versão suportada e definir um calendário.
4. **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](https://phpsos.de/pt/leistungen/php-migration-legacy/).

## 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.

## Fontes

- [PHP: versões suportadas](https://www.php.net/supported-versions.php)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [Debian Security Tracker](https://security-tracker.debian.org/)
- [Ubuntu Security Notices](https://ubuntu.com/security/notices)