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.
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.
Como ajuda concretamente a PHP SOS?
- 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.
- 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.
- 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.
- 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.
- 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:
# 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/
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.
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.