Em resumo: para a vulnerabilidade PHP2Shell no PHP 8.1 não existe atualização oficial. O projeto PHP fornece para 7.4, 8.0 e 8.1 apenas backports mínimos do código-fonte, e não versões prontas. Quem opera estas versões precisa de um backport confirmado do seu fornecedor ou de medidas provisórias e deve planear agora a mudança para uma versão suportada.
Existe uma atualização contra a vulnerabilidade do PHP 8.1?
Não do projeto PHP. A 21 de outubro de 2026 saíram correções oficiais apenas para os ramos suportados: 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O PHP 8.1 e as versões anteriores já não recebem atualizações oficiais.
Estão, no entanto, afetados. Segundo a imprensa especializada, as versões vulneráveis recuam quase sem interrupção até ao PHP 5.4. Quem opera uma destas versões acessível publicamente tem, portanto, uma vulnerabilidade crítica com CVSS v4.0 de 9,2 sem patch pronto.
Para muitas empresas, isto é uma surpresa, pois estes sistemas correm muitas vezes há anos de forma estável e discreta. Que uma versão deixou de receber atualizações não se nota no dia a dia, até surgir uma vulnerabilidade como o PHP2Shell. Os backports do código-fonte para 7.4, 8.0 e 8.1 são uma exceção e não um regresso à manutenção regular.
O que significam os backports do código-fonte
Para 7.4, 8.0 e 8.1 existem backports mínimos do código-fonte. São correções no código-fonte que foram transpostas para estes ramos mais antigos. Não são uma versão oficial, com número de versão, pacote testado e changelog.
Na prática, isto significa: alguém tem de adotar o backport, reconstruir o PHP a partir dele, testá-lo e distribuí-lo. Isso pode acontecer de três formas:
- A sua distribuição incorpora a correção nos seus pacotes, por exemplo no âmbito de uma manutenção de longo prazo.
- O seu fornecedor de alojamento constrói pacotes PHP próprios e aplica o backport.
- Você ou um prestador de serviços constroem o PHP a partir do código-fonte. É exigente e tem de ser repetido a cada nova vulnerabilidade.
Se o seu sistema recebeu um backport, verifique-o no changelog do pacote:
apt changelog php8.1-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # Debian/Ubuntu
rpm -q --changelog php-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # família RHEL
Os nomes de pacotes variam conforme a distribuição e a fonte de pacotes. Se faltar uma entrada, pergunte ao fornecedor. Como funciona a verificação em pormenor, consta de Verificar corretamente a versão do PHP e o nível de patch.
Proteger o servidor antigo até à migração
Enquanto não houver um backport confirmado em execução, aplicam-se as medidas provisórias do php.net: memory_limit=-1 sem poder ser sobreposto, com limite de memória através de cgroup, post_max_size de 8M ou 32M com upload_max_filesize abaixo e session.upload_progress.enabled=0 na configuração do servidor, reiniciando depois todos os workers. Não são uma proteção completa. Pormenores em Medidas imediatas quando ainda não pode aplicar o patch.
A isto juntam-se medidas que reduzem a acessibilidade: áreas de administração só por VPN ou por endereços IP autorizados, desativar sites desnecessários, limitar estritamente os acessos ao servidor. O BSI recomenda desligar temporariamente da rede os servidores sem atualização. Para uma aplicação antiga e de difícil migração, uma solução isolada pode ser a resposta mais honesta do que a operação na Internet aberta.
Se um servidor com PHP 8.1 ou anterior esteve desprotegido na rede desde 17 de outubro, leve isso a sério: o BSI contava com uma exploração rápida e em larga escala. Guarde os registos desde 20 de outubro e mande verificar o servidor quanto a vestígios antes de migrar.
Planear a migração: para que versão?
O destino é uma versão que o projeto PHP suporte e que a sua aplicação suporte. O PHP 8.2 fecha a vulnerabilidade a partir do 8.2.35, mas atinge o fim do suporte a 31/12/2026. Quem migra agora deve, por isso, passar se possível para o 8.3 ou superior, desde que a aplicação o permita. O estado atual é indicado pelo php.net na página das versões suportadas.
Que versão do PHP o seu CMS ou a sua loja suporta, verifique-o segundo os requisitos de sistema do fabricante, por exemplo em wordpress.org, shopware.com ou typo3.org. Muitas vezes, é a própria aplicação que tem de ser atualizada primeiro, antes de o PHP poder mudar. Um caso típico são as lojas mais antigas, que descrevemos na página Shopware 5. Antecedentes sobre as consequências de versões obsoletas encontra-os em PHP End of Life: riscos de versões obsoletas.
| Passo | Conteúdo |
|---|---|
| Inventário | versão do PHP, aplicação, extensões, personalizações próprias |
| Requisitos | versões do PHP suportadas segundo o fabricante |
| Ambiente de teste | cópia com a nova versão do PHP, analisar o registo de erros |
| Mudança | janela de manutenção planeada, via de retorno preparada |
| Trabalho posterior | verificar os valores provisórios, configurar a vigilância |
Como ajuda concretamente a PHP SOS?
Com a migração do PHP 8.1 e anteriores, conduzimo-lo da versão antiga a uma versão suportada:
- Proteger de imediato: verificar o estado de backport, aplicar medidas provisórias, reduzir a acessibilidade.
- Verificar vestígios: guardar os registos desde 20 de outubro e analisá-los quanto a anomalias.
- Preparar a migração: esclarecer a compatibilidade segundo o fabricante, montar um ambiente de teste, corrigir erros.
- Mudar e comprovar: instalar a nova versão do PHP, reiniciar todos os processos, documentar o estado.
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, incluindo o PHP 8.1. O projeto PHP já não publica atualizações oficiais para o 8.1, apenas backports mínimos do código-fonte.
O que é um backport do código-fonte?
Uma correção no código-fonte que foi transposta para um ramo de versão mais antigo. Não é uma versão pronta: alguém tem de a adotar, reconstruir o PHP, testá-lo e distribuí-lo. Isso pode ser assumido pelo seu fornecedor de distribuição, pelo seu fornecedor de alojamento ou por um prestador de serviços.
Basta mudar para o PHP 8.2?
A curto prazo, o PHP 8.2.35 fecha a vulnerabilidade. O PHP 8.2 atinge, no entanto, o fim do suporte a 31/12/2026. Quem migra de qualquer modo deve por isso verificar se a aplicação suporta, segundo o fabricante, também o 8.3 ou superior.
A minha loja só corre com PHP 7.4. E agora?
Então são necessárias duas coisas em paralelo: proteger o servidor com medidas provisórias e isolamento e levar a aplicação a uma versão que suporte uma versão do PHP suportada. Qual seja, consta dos requisitos de sistema do fabricante.