Samuel Arendt

Post-mortem da Laravel mostra que Forge e Vapor não atualizam o PHP por você

Em 4 de novembro de 2026, a Laravel publicou o post-mortem da resposta às versões de segurança do PHP e do Node.js lançadas em 21 de outubro. As versões do PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 corrigem duas falhas de execução remota de código sem autenticação, CVE-2026-109618 e CVE-2026-109619, ambas com nota 9,2 no CVSS v4.0. O relatório mostra que o mesmo aviso exigiu trabalhos diferentes em cada produto da Laravel, e quem fez esse trabalho dependeu do produto contratado.

Cloud aplicou a correção; Forge e Vapor devolveram a tarefa ao cliente

No Laravel Cloud, a empresa trocou o binário do PHP dentro das aplicações em execução, sem novo deploy do cliente. A correção chegou a 100% das regiões às 18:05 UTC de 21 de outubro. Os deploys novos ficaram pausados das 13:54 às 17:33 UTC. Segundo a Laravel, os clientes do Cloud não precisaram fazer nada, e a empresa não encontrou indício de exploração em clientes.

No Forge, o cliente atualiza o PHP em cada servidor. A base de conhecimento do Forge avisa que as atualizações automáticas de segurança do produto não incluem o PHP: ele vem de um repositório de pacotes próprio, e as atualizações automáticas do Ubuntu só aplicam o repositório de segurança do Ubuntu. No dia, o volume de atualizações chegou a cerca de dez vezes o normal, a fila deixou os deploys parados e cerca de 4.800 deploys foram cancelados entre 19:30 e 21:27 UTC. Esses clientes tiveram de repetir o deploy.

No Vapor, a Laravel publicou runtimes novos, e cada cliente precisou refazer o deploy para recebê-los. A orientação mudou durante o incidente: primeiro a empresa disse que faria o novo deploy pelos clientes, e às 19:25 UTC passou a pedir que cada cliente fizesse o seu. O Envoyer ficou fora do ar das 13:52 às 22:58 UTC para atualizar os próprios servidores.

Quem precisa conferir agora

Precisa conferir quem usa Forge, Vapor ou servidores próprios com PHP e ainda não verificou a versão instalada. O próprio post-mortem reconhece que a Laravel não tinha "registro confiável" da versão de software de cada aplicação; se o fornecedor não tinha, vale perguntar se a sua equipe tem.

Para clientes do Cloud, a correção do PHP já foi aplicada pela Laravel. Para equipes que contratam agência ou fornecedor, a pergunta útil é de quem é a responsabilidade de atualizar o runtime, e isso deveria estar escrito no contrato de manutenção. Essa é a parte do custo de uma plataforma que costuma aparecer só no incidente, como discuti em O custo de uma ferramenta inclui o trabalho para substituí-la.

O que fazer e até quando

As falhas são públicas desde 21 de outubro, então o prazo já passou. A sequência indicada pelo Forge serve para qualquer servidor Ubuntu com PHP instalado a partir desses pacotes:

  1. Atualizar todas as versões do PHP instaladas no servidor, inclusive as que nenhum site usa.
  2. Reiniciar os processos de longa duração. Filas, Horizon, Octane e Reverb continuam rodando o PHP antigo até serem reiniciados, mesmo depois que o PHP-FPM sobe com a versão nova.
  3. Conferir com php -v e php-fpm -v que a versão corrigida está ativa.

Para PHP 8.1 ou anterior, que não recebe mais versões oficiais, o mantenedor dos pacotes publicou correções em novas revisões. O número da versão continua igual, e só a revisão do pacote (dpkg -l) mostra se a correção entrou. É uma solução provisória; o Forge recomenda migrar para uma versão suportada.

No Vapor, refazer o deploy para usar o runtime novo e verificar se a aplicação ainda usa o runtime al2, que a Laravel marcou como sem suporte e sobre o qual está contatando clientes. Também entra no planejamento o fim do suporte do PHP 8.2 em 31 de dezembro de 2026, segundo o php.net.

Se a atualização não puder sair hoje, o aviso do PHP lista mitigações parciais, como session.upload_progress.enabled = 0 na configuração do servidor, e diz que nenhuma delas deixa a instalação segura.

O que ainda está em aberto

A Laravel diz que revisa a política de novo deploy para ter uma resposta escrita sobre o que acontece quando não consegue corrigir nem refazer automaticamente o deploy de uma aplicação. Essa política ainda não foi publicada, assim como o texto prometido sobre transformar a resposta em rotina. Do lado do PHP, um aviso de 23 de outubro recomenda desligar o progresso de upload de sessão até a próxima versão de correção, e o detalhamento da CVE-2026-115560 só sai com essa versão.

Se a sua empresa está avaliando algo parecido, me chama no LinkedIn ou no WhatsApp.

Referências

Silhueta de um trabalhador de pé num andaime de tubos metálicos, contra o céu claro

Foto de Jay Ee no Unsplash

#Arquitetura, #Operações, #Radar