Em 5 de novembro de 2026, o projeto PHP publicou o PHP 8.6.0 RC5 e informou que a próxima versão será a primeira estável, o PHP 8.6.0, prevista para 19 de novembro. Entre as mudanças incompatíveis listadas no arquivo UPGRADING, a que mais pode alterar uma aplicação em produção sem nenhuma linha de código nova está na sessão: três configurações passam a vir com valores mais restritivos.
O que muda na sessão do PHP 8.6
A mudança vem da RFC "Secure Session Configuration Defaults", aceita com votação separada para cada configuração. Os novos valores valem tanto como padrão interno do PHP quanto no php.ini-production que acompanha a versão 8.6.
Configuração | Até o PHP 8.5 | No PHP 8.6 | Efeito |
|---|---|---|---|
session.use_strict_mode | 0 | 1 | recusa IDs de sessão que não existem no armazenamento |
session.cookie_httponly | 0 | 1 | o JavaScript da página deixa de ler o cookie de sessão |
session.cookie_samesite | vazio | Lax | o cookie não vai junto em POST vindo de outro site |
As três protegem contra problemas conhecidos: fixação de sessão (quando alguém planta um ID e espera a vítima fazer login com ele), roubo do cookie por script injetado e requisições forjadas a partir de outro site. A própria RFC mostra que Laravel, Symfony e Django já usam HttpOnly e Lax nas suas configurações de sessão.
A versão também traz uma lista longa de depreciações, como return dentro de finally e a extensão mbregex, marcada como obsoleta porque a biblioteca Oniguruma deixou de ser mantida. Essas depreciações geram avisos; a mudança na sessão altera o comportamento da aplicação.
Quais aplicações podem quebrar
O risco maior está em fluxos que dependem do cookie de sessão chegando num POST que começou em outro domínio. A RFC cita o login SAML iniciado pelo provedor de serviço e formulários legados enviados entre origens diferentes. Pela mesma regra do Lax, qualquer retorno que chegue por POST de um sistema externo e conte com a sessão do usuário entra na lista para testar.
Chrome, Firefox e Edge já tratam cookies sem o atributo como Lax; o Safari não, segundo a tabela da RFC. Na prática, um fluxo que hoje só funciona no Safari tende a ser o primeiro a falhar.
Também precisam de atenção:
- código front-end que lê o cookie de sessão por
document.cookie, por exemplo para repassar o ID num cabeçalho; - handlers de sessão próprios que aceitam IDs vindos de fora, como a passagem de sessão entre subdomínios. Os handlers padrão de Redis e Memcached não são afetados, de acordo com a RFC;
- classes que implementam
SessionHandlerInterfacesemcreate_sid()evalidateId(), que passam a emitir aviso de depreciação.
A mudança vale para o valor padrão. Um servidor que mantém o php.ini antigo, com session.use_strict_mode = 0 escrito explicitamente, continua com o comportamento anterior depois da atualização. Quem administra o servidor precisa saber qual dos dois arquivos está valendo, porque o resultado muda nos dois sentidos: a proteção pode não chegar, ou um fluxo pode quebrar sem que ninguém tenha mexido na configuração.
O que fazer antes e depois de 19 de novembro
Não há motivo para colocar o 8.6.0 em produção no dia do lançamento. O próprio anúncio do RC5 pede que ele não seja usado em produção. O que cabe agora é testar em homologação ou no CI:
- registrar os valores de sessão em produção hoje (
php -i | grep sessionouini_get()), para comparar depois; - rodar com o RC5 os fluxos de login único, pagamento e qualquer integração que devolva o usuário por POST;
- procurar leitura do cookie de sessão no JavaScript;
- revisar handlers de sessão próprios.
Para quem decide versão, a data mais próxima é outra. Pela página de versões suportadas, o PHP 8.2 recebe a última correção de segurança até 31 de dezembro de 2026, e o PHP 8.4 sai do suporte ativo na mesma data, ficando só com correções de segurança até o fim de 2028. Quem ainda está no 8.2 tem pouco mais de sete semanas para sair dele, e a escolha passa a incluir a versão de destino: 8.5, já estável, ou 8.6 com a mudança de sessão. Escrevi sobre por que uma versão suportada ainda exige uma decisão de migração; para quem está no 8.2, essa decisão já tem data.
O que ainda não se sabe
A data de 19 de novembro é "planejada", nas palavras do anúncio, e pode mudar se o RC5 revelar algum problema. As fontes consultadas também não informam quando distribuições Linux, imagens Docker e hospedagens gerenciadas vão oferecer o 8.6, nem se vão manter o php.ini antigo dos clientes na atualização. A compatibilidade de frameworks e plugins com o 8.6 depende de cada projeto e ainda não aparece nessas fontes.
Se a sua empresa está avaliando algo parecido, me chama no LinkedIn ou no WhatsApp.
