Symfony atualiza 6.4, 7.4 e 8.1 de uma vez: quais correções merecem atenção

PHP · "Loop"

O Symfony aproveitou o sábado, 22 de agosto, para publicar três versões de manutenção: 6.4.44, 7.4.17 e 8.1.5. Não há uma API nova para testar nem um recurso chamativo para colocar no slide da próxima reunião. O lote é formado por correções, mas algumas delas mexem com pontos sensíveis de aplicações reais, incluindo sessão, autenticação, filas, Redis e cópia de arquivos.

A correção que mais chama atenção trata um ID de sessão que podia sobreviver à requisição anterior em determinados ambientes. Outra resolve logins ignorados quando o caminho de autenticação era configurado com um alias de rota. Também há mudanças para handlers do Messenger que compartilham a mesma classe, autenticação do Predis e um caso em que Filesystem::mirror() podia apagar arquivos do diretório de origem.

Três versões para as três linhas mantidas

O lançamento simultâneo acompanha o modelo de manutenção do projeto. Bugs são corrigidos na linha mantida mais antiga que contém o problema e depois seguem para as linhas mais recentes. Por isso, várias mudanças aparecem ao mesmo tempo no Symfony 6.4.44, 7.4.17 e 8.1.5.

  • Symfony 6.4.44: atualização da LTS antiga, compatível com PHP 8.1 ou superior. A linha recebe correções de bugs até novembro de 2026 e correções de segurança até novembro de 2027.
  • Symfony 7.4.17: atualização da LTS atual, que exige PHP 8.2 ou superior. A manutenção de bugs vai até novembro de 2028 e a de segurança, até novembro de 2029.
  • Symfony 8.1.5: atualização da versão estável atual, voltada a projetos em PHP 8.4 ou superior e a equipes que acompanham a cadência regular do framework.

Isso também deixa um recado para quem ainda está no Symfony 8.0: essa linha encerrou a manutenção em julho de 2026. O caminho suportado na série 8 é o 8.1. Ficar no 8.0 significa não receber nem mesmo as correções deste lote.

O ID de sessão que podia vazar de uma requisição para outra

O ponto mais delicado está no HttpKernel. O PHP mantém o ID da sessão em um estado global do processo. O Symfony tenta limpar esse valor entre requisições, mas a limpeza não acontecia quando os headers já haviam sido enviados. Isso pode ocorrer em uma suíte PHPUnit depois de alguma saída no terminal e, de forma mais preocupante, em runtimes com workers persistentes que escrevem em stdout.

Nessa situação, a próxima requisição podia herdar o ID deixado pela anterior e preferi-lo ao cookie enviado pelo cliente. Em testes, o sintoma era um usuário aparentemente deslogado mesmo depois de loginUser(). Em um worker persistente, o risco era associar uma requisição à sessão processada imediatamente antes.

A correção identifica esse valor residual antes de criar a sessão e deixa o cookie da requisição prevalecer. O changelog classifica a mudança como correção de bug, e não houve anúncio de CVE para ela. Ainda assim, quem executa Symfony sobre um runtime PHP persistente deve tratar o patch com prioridade, testar isolamento de sessão e reiniciar todos os workers depois do deploy.

Aliases de rota deixam de confundir o fluxo de login

Outra correção fica no componente Security. O check_path do form_login e do json_login, assim como caminhos de logout e login link, pode ser configurado usando o nome de uma rota. O problema aparecia quando esse nome era um alias: o roteador informava o nome canônico da rota encontrada, a comparação falhava e o autenticador simplesmente ignorava a requisição.

Na prática, o formulário era enviado e o usuário voltava à página de login sem uma explicação útil. Agora, quando a comparação direta do nome falha, o Symfony gera o caminho da rota configurada e o compara com a URL da requisição. A mudança interessa especialmente a aplicações que renomearam rotas, mantêm aliases por compatibilidade ou usam o nome da classe do controller como rota de login.

Dois serviços com o mesmo handler agora são realmente dois

No Messenger, dois serviços registrados com a mesma classe de handler para a mesma mensagem eram exibidos por debug:messenger, mas apenas o primeiro acabava chamado. O framework identificava o handler pelo par Classe::método e concluía que o segundo serviço já havia sido executado.

As novas versões acrescentam o ID do serviço quando existe ambiguidade. Com isso, cada handler recebe uma identidade estável e o Messenger consegue diferenciar tanto a primeira execução quanto uma nova tentativa depois de falha. Há um efeito importante para os testes: uma configuração que esperava, mesmo sem perceber, que apenas o primeiro handler rodasse passará a executar os dois. Se o código usa HandleTrait esperando exatamente um resultado, essa configuração pode agora gerar uma LogicException em vez de esconder o problema.

Predis passa a respeitar todas as formas documentadas de autenticação

O adaptador de cache também tinha uma inconsistência. Ao criar uma conexão com Predis, credenciais informadas pelo parâmetro auth da DSN ou pela opção auth podiam ser descartadas silenciosamente. A tentativa de conexão seguia sem usuário e senha, embora a configuração estivesse presente.

O patch centraliza a leitura das credenciais já normalizadas e alinha o comportamento de Predis, ext-redis e Relay. Configurações de ACL com usuário e senha também passam por uma validação mais clara: arrays em formato inesperado geram uma exceção, em vez de avisos de índice inexistente seguidos por uma conexão sem autenticação.

Um caso raro, mas perigoso, em Filesystem::mirror()

A combinação de um iterador personalizado com a opção delete em Filesystem::mirror() podia fazer a etapa de limpeza percorrer o diretório de origem, quando deveria examinar o destino. Dependendo dos caminhos envolvidos, o método concluía que arquivos válidos eram obsoletos e os removia da própria origem.

Não é uma chamada que aparece em todo projeto Symfony, mas o potencial destrutivo justifica procurar usos antes do deploy. A implementação corrigida cria o iterador de limpeza a partir do destino e preserva o papel do iterador fornecido pela aplicação: selecionar o que será copiado.

O que mais vale conferir no changelog

O lote é grande e alcança muitos componentes. Além dos casos acima, há correções para mensagens canceladas do Scheduler que podiam voltar por transportes assíncronos, respostas sem conteúdo no cache do HttpKernel, serialização de nomes e grupos, cookies com sinal de mais, reconexão SMTP depois de timeout e diferentes situações de cache e concorrência.

Nem todas afetam todo projeto. A melhor leitura não é “o Symfony estava quebrado em dezenas de lugares”, mas “há correções específicas para combinações específicas de recursos”. O trabalho útil é cruzar o changelog com os componentes instalados e com os fluxos mais importantes da aplicação.

Como atualizar sem transformar um patch em aventura

As três versões são patches dentro de linhas já existentes. A política do Symfony reserva esse tipo de lançamento para correções de bugs e recomenda manter a aplicação no patch mais recente. Isso não elimina a necessidade de teste, principalmente porque algumas correções fazem um comportamento antes oculto finalmente aparecer.

composer update "symfony/*" --with-all-dependencies

O comando deve respeitar a linha já definida no composer.json. Ele não é um convite para trocar 6.4 por 7.4 ou 7.4 por 8.1 no mesmo deploy. Se o Composer encontrar conflitos, vale revisar as restrições dos bundles e dependências em vez de abrir versões às cegas.

  • Execute a atualização em uma branch separada e revise as mudanças no composer.lock.
  • Rode os testes de login, logout, troca de usuário e isolamento de sessão entre requisições.
  • Se houver Messenger, confira handlers duplicados, retries, mensagens em trânsito e fluxos que usam HandleTrait.
  • Valide conexões Redis com as mesmas DSNs e credenciais usadas em produção.
  • Procure chamadas a Filesystem::mirror() com iterador e delete, incluindo ferramentas internas e comandos de deploy.
  • Depois do deploy, limpe o cache da aplicação e reinicie consumidores, schedulers e runtimes persistentes.

Para uma atualização de manutenção, esse é um lote com consequências bem concretas. Projetos PHP-FPM tradicionais também recebem várias correções úteis, mas aplicações com workers persistentes, autenticação por alias de rota, múltiplos handlers da mesma classe ou Predis têm os motivos mais claros para não deixar o patch esperando até a próxima faxina de dependências.

Fontes