# PHP 8.1 e anteriores: atualização para uma versão suportada

> Atualização do PHP 8.1 sem voar às cegas: verificamos as aplicações, testamos numa cópia, migramos para uma versão suportada e protegemos o período de transição.

Fonte: https://phpsos.de/pt/leistungen/php-migration-legacy/  
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:** quem ainda opera o PHP 8.1 ou anterior já não recebe do projeto PHP atualizações de segurança oficiais, nem sequer para o PHP2Shell. Uma atualização do PHP 8.1 para uma versão suportada não é, por isso, um extra, mas a verdadeira solução. Verificamos as suas aplicações, testamos numa cópia, migramos de forma controlada e protegemos o tempo até lá.

## Porque é que o PHP 8.1 e anteriores são agora um risco agudo

As vulnerabilidades PHP2Shell CVE-2026-109618 e CVE-2026-109619 permitem a execução de código sem autenticação. Estão corrigidas no PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Para o PHP 8.1 e anteriores já não existem atualizações oficiais, apenas backports mínimos do código-fonte para 7.4, 8.0 e 8.1. Segundo a imprensa especializada, estão afetadas quase todas as versões até ao PHP 5.4.

Algumas distribuições e fornecedores de alojamento aplicam backports próprios. Se o seu sistema se inclui nesse grupo, tem de ser o fornecedor a confirmá-lo para o seu estado de pacote concreto. Sem essa confirmação, deve partir do princípio de que o servidor está aberto. O que isso significa em pormenor, descreve-o [PHP 8.1 e anteriores: o que se aplica agora](https://phpsos.de/pt/php2shell/php-8-1-und-aelter/).

## Atualização do PHP 8.1: que versão de destino?

O destino deve ser uma versão que o projeto PHP ainda suporte e que a sua aplicação homologue. O estado atual do suporte é publicado pelo php.net na página das versões suportadas. O PHP 8.2 termina a 31/12/2026; mudar para o 8.2 seria, pois, apenas um passo intermédio com um novo projeto em breve.

Que versão do PHP o seu CMS ou sistema de loja suporta, verificamo-lo com base nos requisitos de sistema do fabricante, por exemplo em wordpress.org, shopware.com ou typo3.org, e não de memória. Muitas vezes, é o próprio CMS que tem de ser atualizado primeiro. As lojas antigas são um caso típico, ver [Shopware 5: lojas antigas numa versão antiga do PHP](https://phpsos.de/pt/plattformen/shopware-5/).

## Como ajuda concretamente a PHP SOS?

1. **Levantamento e proteção:** registamos todas as aplicações, a sua versão do PHP, o estado do CMS, as extensões e o código próprio. Em paralelo, aplicamos as medidas provisórias segundo o php.net, para que o risco diminua até à migração; pormenores em [WAF e patching virtual](https://phpsos.de/pt/leistungen/waf-virtuelles-patching/).
2. **Verificar a compatibilidade:** comparamos os requisitos de sistema dos fabricantes, verificamos as dependências com o Composer e procuramos funções obsoletas no código próprio. Como isto se apresenta nas dependências, descreve-o [Verificar vulnerabilidades nas dependências do Composer](https://phpsos.de/pt/ratgeber/composer-abhaengigkeiten-pruefen/).
3. **Teste numa cópia:** a aplicação corre primeiro num ambiente de teste com a nova versão do PHP. Os erros, corrigimo-los aí ou documentamo-los para a sua agência.
4. **Mudança com via de retorno:** a mudança em produção é feita numa janela de manutenção acordada, com uma cópia de segurança atual e uma via de retorno definida.
5. **Controlo posterior:** verificamos os registos de erros e as funções centrais após a mudança e removemos a versão antiga do PHP quando já não for necessária.

Uma consulta inofensiva sobre que sites usam que versão do PHP é possível em muitos sistemas através dos pools FPM em execução:

```bash
# mostrar masters e pools PHP-FPM em execução
ps -eo pid,cmd | grep -E "php-fpm: (master|pool)" | grep -v grep
# versões do PHP instaladas (Debian/Ubuntu)
ls /etc/php/
```

> **Importante:**
> Uma atualização para uma nova versão do PHP não remove software malicioso que tenha sido introduzido antes. Se o servidor esteve desprotegido na rede desde 17/10/2026, faz parte uma verificação de vestígios.

## Obstáculos típicos na atualização

A maior parte dos problemas na mudança de versão do PHP é previsível, se se souber onde procurar:

- **Extensões obsoletas:** plugins ou módulos que já não são mantidos muitas vezes não funcionam em versões mais recentes do PHP. Precisam de substituição ou de adaptação.
- **Código próprio:** funções que o PHP entretanto marcou como obsoletas ou removeu causam avisos ou interrupções. Verificações de tipos mais rigorosas revelam erros de programação antigos.
- **Dependências:** as bibliotecas integradas através do Composer exigem por vezes elas próprias versões novas e arrastam outras alterações.
- **Extensões PHP no servidor:** nem toda a extensão que estava instalada na versão antiga existe automaticamente para a nova.
- **Cronjobs e linha de comandos:** o site já corre na versão nova, mas as tarefas agendadas ainda chamam a versão antiga do PHP.

Quem verifica estes pontos antes encurta a mudança e evita surpresas na operação em produção.

## O que recebe e o que precisamos

Recebe uma visão geral de todas as aplicações com versão de partida e de destino, um plano de migração com sequência e riscos, um protocolo de testes, a documentação da mudança e uma lista de pontos que a sua agência ou o seu programador ainda têm de tratar.

Precisamos de si:

- **acesso ao servidor ou ao painel** e acesso aos backends dos CMS
- **acesso ao código-fonte e ao repositório**, no caso de desenvolvimentos próprios
- **contacto com a agência ou o programador** que conhecem a aplicação
- **um ambiente de teste** ou a autorização para criar um
- **janela de manutenção** e um interlocutor para a aceitação

## O que não prometemos

Não prometemos que toda a aplicação antiga funcione numa versão nova do PHP sem alterações. Em sistemas sem evolução, pode ser necessária uma reformulação maior ou uma mudança; dizemo-lo abertamente assim que se vislumbrar. As afirmações de compatibilidade assentam nas indicações dos fabricantes. E as medidas provisórias não substituem a migração, apenas cobrem o tempo. Os riscos a longo prazo das versões obsoletas são descritos em [PHP End of Life: riscos de versões obsoletas](https://phpsos.de/pt/ratgeber/php-end-of-life-risiken/).


## Perguntas frequentes

**O PHP 8.1 está afetado pelo PHP2Shell?**  
Segundo a imprensa especializada, estão afetadas quase todas as versões até ao PHP 5.4. Para o PHP 8.1 e anteriores não existem atualizações oficiais do projeto PHP, apenas backports mínimos do código-fonte para 7.4, 8.0 e 8.1. Algumas distribuições aplicam backports próprios, o que tem de ser confirmado pelo respetivo fornecedor.

**Para que versão do PHP devo atualizar?**  
Para uma versão que o projeto PHP ainda suporte ativamente e que a sua aplicação tenha homologada segundo os requisitos de sistema do fabricante. O PHP 8.2 atinge o fim do suporte a 31/12/2026 e, por isso, só serve condicionalmente como destino.

**Não posso simplesmente mudar a versão do PHP no painel de alojamento?**  
Tecnicamente, muitas vezes é possível com um clique. Se a aplicação continua a funcionar depois depende da versão do CMS, das extensões e do código próprio. Sem teste, arrisca falhas ou funções com erros, por exemplo no checkout de uma loja.

**E se o meu CMS não suportar a nova versão do PHP?**  
Nesse caso, o CMS tem de ser atualizado primeiro, eventualmente para uma nova versão principal. Em sistemas sem evolução, pode ser necessária uma mudança. Até lá, protegemos o servidor com medidas provisórias.

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