Em resumo: Nos fornecedores cloud e PaaS, o patch não é aplicado automaticamente pelo fornecedor. Se ele gere o runtime PHP, atualiza-o, mas muitas vezes só com o deployment seguinte. Se constrói imagens ou builds você mesmo ou opera a plataforma, tem de reconstruir e publicar. Decisivo é sempre o runtime que o seu site está a servir neste momento.
Atualização do PHP em PaaS: a quem pertence o runtime?
Os serviços de plataforma, no jargão PaaS (Platform as a Service), tiram às empresas a operação do servidor. Carrega o código, a plataforma constrói-o e opera-o. No PHP2Shell, daqui nasce uma incerteza típica: quem tem afinal de atualizar o PHP?
A Vercel resume-o no seu boletim sobre o PHP2Shell: uma atualização do ambiente de desenvolvimento local, do código da aplicação ou dos plugins não basta. Decisivo é o runtime PHP do deployment que de facto responde aos pedidos. Se este runtime tem patch depende de quem o fornece e de quando foi construído pela última vez.
Quatro modelos de operação em comparação
As designações dos fornecedores diferem. Para a questão do patch, a maioria das ofertas pode ser atribuída a um destes modelos:
| Modelo | Quem atualiza o PHP? | O que tem de fazer |
|---|---|---|
| Runtime gerido pelo fornecedor | Fornecedor | Obter confirmação e, se necessário, fazer novo deployment para que o novo runtime atue |
| Runtime baseado em build (buildpack) | O fornecedor disponibiliza a nova versão, o seu build fixa-a | Desencadear um novo build e verificar a versão no registo do build |
| Imagem de contentor própria | Você | Reconstruir a imagem com o PHP corrigido e publicá-la |
| Plataforma operada por si | Você, para a plataforma e as aplicações | Aplicar patch à plataforma e a cada aplicação individualmente |
Muitas empresas usam vários modelos em simultâneo, por exemplo um runtime gerido para o site e contentores próprios para ferramentas internas. Cada aplicação precisa por isso de uma resposta própria.
Há uma armadilha na palavra “gerido”. Mesmo que o fornecedor mantenha o runtime, uma aplicação já publicada continua muitas vezes a correr com o estado com que foi construída. A nova versão só atua então no build ou deployment seguinte. Algumas plataformas mantêm além disso acessíveis deployments mais antigos ou ambientes de pré-visualização em endereços próprios. Por isso, não pergunte apenas se o fornecedor aplicou o patch, mas também a partir de quando as suas instâncias em execução usam o patch e o que acontece aos deployments antigos.
O que a Vercel e a Coolify dizem sobre o PHP2Shell
Dois fornecedores tornaram públicas as suas indicações. São instrutivas, porque nomeiam com clareza os limites das próprias medidas de proteção.
A Vercel ativou, segundo o seu boletim, antes da publicação, regras de proteção na sua Web Application Firewall (WAF), um filtro de pedidos web. Aplicam-se automaticamente às funções PHP na Vercel e aos pedidos que a Vercel reencaminha para servidores PHP externos. Ao mesmo tempo, a Vercel exige que o runtime PHP seja imediatamente atualizado para uma versão corrigida. Os deployments em contentores devem ser reconstruídos com uma imagem base PHP atualizada e publicados. Os pedidos que contornam a Vercel e vão diretamente para um servidor PHP externo não são cobertos pela WAF.
A Coolify, uma plataforma que se pode operar por conta própria, esteve ela mesma afetada, segundo o seu advisory: todos os ramos da versão 4. Como primeiras versões corrigidas, a Coolify indica 4.0.1, 4.1.3, 4.2.1, 4.3.24 e 4.4.7 e recomenda a 4.4.7. É importante o aditamento: a atualização da Coolify não atualiza as aplicações PHP que opera através dela. Os seus runtimes ou imagens têm de ser atualizados em separado e reconstruídos ou publicados. Segundo a Coolify, isto vale também para clientes da Coolify Cloud e também atrás da Cloudflare, porque as regras da Cloudflare só verificam o tráfego que passa pela Cloudflare.
O que as regras da Cloudflare conseguem é enquadrado pelo artigo Regras de proteção da Cloudflare contra o PHP2Shell.
Como verificar o runtime em serviço
Os passos seguintes funcionam independentemente do fornecedor. Visam uma prova, não uma sensação.
- Listar todos os ambientes: produção, staging, deployments de pré-visualização e serviços em segundo plano como workers de filas. Cada ambiente pode ter um runtime diferente.
- Ler a versão do runtime por ambiente: na consola do fornecedor, no registo do build ou no ficheiro de configuração do projeto.
- Verificar a data do último deployment: se for anterior a 21/10/2026, é muito provável que ainda corra o runtime antigo, a menos que o fornecedor confirme expressamente outra coisa.
- Verificar na instância em execução: se a plataforma oferecer uma consola, o comando seguinte mostra a versão da instância.
- Incluir servidores PHP externos: os servidores para os quais a plataforma reencaminha pedidos precisam de uma atualização própria e não devem ser acessíveis diretamente a partir da Internet.
# Na consola da instância em execução (se oferecida pelo fornecedor)
php -v
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'
Espera-se 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ou um backport confirmado pelo fornecedor. Tenha em atenção que a linha de comandos de uma instância nem sempre usa o mesmo runtime que o processo web. Não crie para a verificação nenhum ficheiro phpinfo acessível publicamente. Como interpretar corretamente o número de versão e o estado de backport está descrito em Verificar a versão do PHP e o estado do patch.
Um novo deployment não elimina software malicioso que tenha chegado antes a armazenamento persistente, como volumes de upload ou a base de dados. Verifique estas áreas em separado.
Registar a responsabilidade por escrito
O PHP2Shell mostra como é muitas vezes pouco clara a fronteira entre a plataforma e o cliente. Registe, para cada aplicação, quem fornece o runtime, quem reconstrói perante avisos de segurança e como o fornecedor anuncia patches. Faz parte disso saber quem tem acesso à consola da plataforma quando há urgência e quem pode desencadear um novo build fora do horário de expediente.
Para a documentação própria basta uma tabela curta por aplicação: plataforma, modelo de operação, ramo do PHP, data do último build, responsável. Quem tiver esta lista à mão no próximo aviso poupa os dias que muitas equipas passaram à procura depois de 21 de outubro. Nas aplicações em contentores, faz parte disso saber quem mantém a imagem base; os antecedentes estão explicados em PHP em contentores.
Para servidores geridos sem caráter PaaS valem perguntas semelhantes, que resumimos em Servidor gerido: esclarecer a responsabilidade.
Como ajuda concretamente a PHP SOS?
- Atribuir: associamos cada uma das suas aplicações a um modelo de operação e esclarecemos quem fornece o runtime PHP.
- Comprovar: verificamos o runtime, a data do build e o deployment por ambiente e documentamos o resultado.
- Reconstruir e publicar: através do serviço de patch PHP, atualizamos imagens e builds e publicamo-los de forma controlada.
- Fechar lacunas: verificamos se os servidores PHP externos são diretamente acessíveis e restringimos o acesso.
Perguntas frequentes
O meu fornecedor PaaS aplica o patch ao PHP automaticamente?
Depende do modelo. Se o fornecedor gere o runtime, atualiza-o, mas muitas vezes só para novos deployments. Se constrói as imagens ou os builds você mesmo, tem de reconstruir e voltar a publicar. Peça confirmação do estado para a sua aplicação.
A WAF do meu fornecedor de plataforma basta contra o PHP2Shell?
Não. A Vercel e a Coolify escrevem expressamente que as regras de proteção não substituem a atualização do runtime PHP. Além disso, só atuam sobre o tráfego que passa pela plataforma.
Tenho de fazer um novo deployment depois do patch?
Muitas vezes sim. A Vercel indica, para deployments em contentores, a reconstrução com uma imagem base PHP atualizada e um novo deployment. Nas plataformas baseadas em build, o runtime fica fixado no build; só um novo build incorpora o patch.
Uso a Coolify. A atualização da Coolify basta?
Não. Segundo o advisory da Coolify, a atualização só atualiza a própria Coolify. Os runtimes PHP ou as imagens de contentor das suas aplicações têm de ser atualizados em separado e reconstruídos ou republicados.