Spring Boot 4.1 chega com auto-config de gRPC, mitigação de SSRF e Kotlin 2.3

Se você mantém serviços Spring em produção, a chegada do Spring Boot 4.1 no dia 10 de junho de 2026 traz três mudanças que mexem diretamente com decisões de arquitetura e segurança que você provavelmente já vinha adiando: gRPC deixou de depender de starter de terceiros e ganhou auto-configuração oficial, o stack de cliente HTTP recebeu mitigações contra SSRF, e o baseline de Kotlin pulou para a 2.3. Nenhuma dessas é uma feature de vitrine — todas têm consequência prática no código que você escreve e no que você precisa auditar antes de subir.

Esta é a primeira minor depois do salto de major. O Spring Boot 4.0, lançado em novembro de 2025, foi o primeiro release a rodar sobre o Spring Framework 7, com Java 17 como mínimo e suporte first-class ao Java 25. A 4.1 herda toda essa fundação e começa a preencher as lacunas que a 4.0 deixou em aberto.

gRPC com auto-configuração: o que muda no dia a dia

Até agora, quem queria rodar gRPC dentro de uma aplicação Spring Boot dependia de starters da comunidade (o mais popular sendo o grpc-spring do ecossistema grpc-ecosystem) ou montava o servidor na mão. Funcionava, mas você carregava a manutenção desse acoplamento: alinhar versões, configurar interceptors, lidar com o ciclo de vida do servidor Netty fora do contêiner Spring.

O Spring Boot 4.1 incorpora a auto-configuração do Spring gRPC — projeto que chegou ao 1.0.0 GA em dezembro de 2025 — tanto para o lado servidor quanto cliente. Na prática:

• Você adiciona o starter e o servidor sobe sozinho. Há dois caminhos de transporte: um servidor Netty standalone (porta dedicada para HTTP/2) ou a integração via Servlet, que serve gRPC sobre HTTP/2 na mesma porta dos seus endpoints REST. O segundo caminho é o que resolve a dor real de muita gente: ambientes onde abrir uma segunda porta é uma briga com infra, com load balancer, com a malha de serviço. Agora dá para conviver REST e gRPC no mesmo socket.
• @GrpcAdvice para tratamento centralizado de exceções. É o equivalente conceitual ao @ControllerAdvice do mundo MVC: você mapeia exceções da aplicação para Status gRPC em um ponto só, em vez de espalhar try/catch que traduz código de erro em cada método de serviço.
• Observabilidade já cabeada. Vem um ObservationGrpcServerInterceptor auto-configurado, plugado no Micrometer Observation, com suporte a convenções customizadas. Métricas e tracing distribuído de chamadas gRPC passam a sair de fábrica, sem você instrumentar interceptor na mão.

Se você já tem serviços gRPC rodando com starter de terceiros, isso não é uma migração obrigatória de um dia para o outro — mas é o sinal de que o suporte oficial agora é o caminho recomendado, e que vale planejar a transição para reduzir dependências externas.

Mitigação de SSRF: por que isso entra num release de framework

SSRF (Server-Side Request Forgery) é a vulnerabilidade em que um atacante consegue fazer o seu servidor disparar requisições para destinos que ele controla ou que deveriam ser inacessíveis de fora. O cenário clássico: seu serviço recebe uma URL do usuário — um webhook, uma imagem para baixar, um callback — e usa RestClient, RestTemplate ou WebClient para buscá-la sem validar o destino. O atacante passa http://169.254.169.254/... (o endpoint de metadados de instâncias em nuvem) ou http://localhost:8080/admin e, de repente, o servidor que tem acesso à rede interna está fazendo o trabalho sujo por ele.

O problema é insidioso porque o código parece inofensivo: é só um cliente HTTP fazendo um GET. A vulnerabilidade não está na biblioteca, está em confiar numa URL de origem externa. Por isso SSRF está no topo das listas da OWASP para APIs — é fácil de introduzir e difícil de enxergar em code review.

O Spring Boot 4.1 traz mitigações no stack de cliente HTTP para reduzir a superfície desse ataque. As práticas que o framework passa a facilitar são as mesmas que um time de segurança recomendaria manualmente:

• Parsear a entrada para URI/URL antes de usar, para barrar ofuscação básica (encoding, credenciais embutidas, redirecionamentos enganosos).
• Restringir o esquema — recusar tudo que não seja http/https, cortando file://, gopher:// e companhia.
• Allowlist de domínios em vez de blocklist: só deixa sair requisição para hosts explicitamente autorizados.
• Bloquear resolução para IPs internos — loopback, faixas privadas (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local (169.254.0.0/16). Aqui está o detalhe que pega gente experiente: validar a string da URL não basta, porque um domínio público pode resolver para um IP privado (técnica de DNS rebinding). A verificação correta é resolver o host e checar o InetAddress resultante.

A mensagem para você: mesmo com as mitigações do framework, a responsabilidade de validar URLs de origem externa continua sendo sua. O Spring 4.1 te dá ferramentas melhores, não uma blindagem automática. Todo endpoint que aceita URL de fora precisa de validação explícita de esquema, host e IP resolvido.

Kotlin 2.3 e o baseline atualizado

A 4.1 atualiza o suporte para Kotlin 2.3 (especificamente a linha 2.3.21). Para quem escreve serviços em Kotlin, isso significa alinhar o compilador e os plugins do projeto com a versão que o Boot espera — sair de fase aqui costuma gerar avisos de incompatibilidade de metadados ou comportamento estranho nos plugins de serialização e all-open.

Vale reforçar o baseline herdado da 4.0, porque ele define o piso para migrar: Java 17 é o mínimo absoluto, com suporte first-class ao Java 25 e o Framework 7 por baixo. A 4.0 também trouxe a modularização do código em JARs menores e mais focados, null-safety com JSpecey em todo o portfólio, versionamento de API e HTTP Service Clients. A 4.1 ainda adiciona conexões lazy de datasource, propagação de contexto assíncrono para métodos @Async e melhorias no suporte a OpenTelemetry.

O que avaliar antes de migrar

• Você ainda está em Java 11 ou 8? Então a barreira não é a 4.1, é o salto para o Java 17 mínimo. Resolva isso primeiro.
• Já está na 3.x? A travessia maior é 3.x → 4.0 (Framework 7, modularização, possíveis quebras de pacote). Estando na 4.0, ir para a 4.1 é uma minor de baixo atrito.
• Tem gRPC com starter de terceiros? Não precisa migrar amanhã, mas mapeie a equivalência (@GrpcAdvice, interceptor de observação) e planeje sair da dependência externa.
• Tem endpoints que fazem fetch de URLs externas? Audite-os agora, independente da versão. Esse é o trabalho que não migra sozinho.

Fecho

O Spring Boot 4.1 é uma minor que entrega maturidade onde a 4.0 abriu caminho: gRPC oficial em vez de improviso da comunidade, defesa de SSRF embutida no lugar de receita manual repetida em cada projeto, e o ferramental Kotlin em dia. Se você já está na 4.0, a atualização é direta. Se ainda não, o que pesa não é a 4.1 — é a dívida acumulada de Java e de major que ela finalmente te obriga a encarar.

No ângulo de SSRF, antes de confiar em qualquer URL de origem externa, vale inspecionar para onde aquele host realmente resolve. Nossa ferramenta de informações de endereço IP mostra rapidamente se um IP cai em faixa privada, loopback ou link-local — exatamente as faixas que você quer recusar num validador de SSRF. É um jeito rápido de conferir suposições durante o code review, sem montar um script só para isso.