Spring Boot 4.1 lands with gRPC auto-config, SSRF mitigation, and Kotlin 2.3

If you maintain Spring services in production, the arrival of Spring Boot 4.1 on June 10, 2026 brings three changes that directly affect architecture and security decisions you've probably been putting off: gRPC no longer depends on a third-party starter and now ships with official auto-configuration, the HTTP client stack got SSRF mitigations, and the Kotlin baseline jumped to 2.3. None of these is a showcase feature — all of them have practical consequences for the code you write and for what you need to audit before shipping.

This is the first minor release after the major jump. Spring Boot 4.0, released in November 2025, was the first release to run on Spring Framework 7, with Java 17 as the minimum and first-class Java 25 support. 4.1 inherits that whole foundation and starts filling the gaps 4.0 left open.

gRPC with auto-configuration: what changes day to day

Until now, anyone wanting to run gRPC inside a Spring Boot application relied on community starters (the most popular being grpc-spring from the grpc-ecosystem) or wired up the server by hand. It worked, but you carried the maintenance cost of that coupling: aligning versions, configuring interceptors, managing the lifecycle of a Netty server outside the Spring container.

Spring Boot 4.1 incorporates Spring gRPC auto-configuration — a project that reached 1.0.0 GA in December 2025 — for both the server and client sides. In practice:

• You add the starter and the server comes up on its own. There are two transport paths: a standalone Netty server (a dedicated port for HTTP/2) or the Servlet integration, which serves gRPC over HTTP/2 on the same port as your REST endpoints. The second path solves a real pain for many teams: environments where opening a second port is a fight with infra, with the load balancer, with the service mesh. Now REST and gRPC can coexist on the same socket.
• @GrpcAdvice for centralized exception handling. It's the conceptual equivalent of @ControllerAdvice from the MVC world: you map application exceptions to gRPC Status in a single place, instead of scattering try/catch blocks that translate error codes in every service method.
• Observability already wired up. It ships with an auto-configured ObservationGrpcServerInterceptor, plugged into Micrometer Observation, with support for custom conventions. Metrics and distributed tracing of gRPC calls now come out of the box, without you instrumenting an interceptor by hand.

If you already have gRPC services running with a third-party starter, this isn't a forced overnight migration — but it's the signal that official support is now the recommended path, and that it's worth planning the transition to cut external dependencies.

SSRF mitigation: why this lands in a framework release

SSRF (Server-Side Request Forgery) is the vulnerability where an attacker gets your server to fire requests at destinations they control or that should be unreachable from outside. The classic scenario: your service receives a URL from a user — a webhook, an image to download, a callback — and uses RestClient, RestTemplate, or WebClient to fetch it without validating the destination. The attacker passes http://169.254.169.254/... (the cloud instance metadata endpoint) or http://localhost:8080/admin and suddenly the server with internal network access is doing the dirty work for them.

The problem is insidious because the code looks harmless: it's just an HTTP client doing a GET. The vulnerability isn't in the library, it's in trusting a URL from an external source. That's why SSRF sits at the top of OWASP's API lists — it's easy to introduce and hard to spot in code review.

Spring Boot 4.1 brings mitigations in the HTTP client stack to reduce the attack surface. The practices the framework now makes easier are the same ones a security team would recommend by hand:

• Parse the input into a URI/URL before using it, to block basic obfuscation (encoding, embedded credentials, misleading redirects).
• Restrict the scheme — reject anything that isn't http/https, cutting off file://, gopher://, and friends.
• Domain allowlisting instead of blocklisting: only let requests out to explicitly authorized hosts.
• Block resolution to internal IPs — loopback, private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local (169.254.0.0/16). Here's the detail that catches experienced engineers: validating the URL string isn't enough, because a public domain can resolve to a private IP (the DNS rebinding technique). The correct check is to resolve the host and inspect the resulting InetAddress.

The takeaway for you: even with the framework's mitigations, the responsibility to validate externally-sourced URLs is still yours. Spring 4.1 gives you better tools, not automatic armor. Every endpoint that accepts an outside URL needs explicit validation of scheme, host, and resolved IP.

Kotlin 2.3 and the updated baseline

4.1 updates support to Kotlin 2.3 (specifically the 2.3.21 line). For anyone writing services in Kotlin, this means aligning the project's compiler and plugins with the version Boot expects — falling out of sync here tends to produce metadata incompatibility warnings or odd behavior in the serialization and all-open plugins.

It's worth reinforcing the baseline inherited from 4.0, because it sets the floor for migrating: Java 17 is the absolute minimum, with first-class Java 25 support and Framework 7 underneath. 4.0 also brought codebase modularization into smaller, more focused JARs, null-safety with JSpecify across the portfolio, API versioning, and HTTP Service Clients. 4.1 further adds lazy datasource connections, async context propagation for @Async methods, and improved OpenTelemetry support.

What to weigh before migrating

• Still on Java 11 or 8? Then the barrier isn't 4.1, it's the jump to the Java 17 minimum. Solve that first.
• Already on 3.x? The bigger crossing is 3.x → 4.0 (Framework 7, modularization, possible package breaks). Once on 4.0, going to 4.1 is a low-friction minor.
• Have gRPC with a third-party starter? No need to migrate tomorrow, but map the equivalences (@GrpcAdvice, the observation interceptor) and plan to drop the external dependency.
• Have endpoints that fetch external URLs? Audit them now, regardless of version. That's the work that doesn't migrate on its own.

Wrap-up

Spring Boot 4.1 is a minor that delivers maturity where 4.0 cleared the path: official gRPC instead of community workarounds, built-in SSRF defense instead of a manual recipe repeated in every project, and the Kotlin tooling up to date. If you're already on 4.0, the upgrade is straightforward. If you're not, what weighs on you isn't 4.1 — it's the accumulated Java and major-version debt it finally forces you to face.

On the SSRF angle, before trusting any externally-sourced URL, it pays to inspect where that host actually resolves. Our IP address info tool quickly shows whether an IP falls in a private, loopback, or link-local range — exactly the ranges you want to reject in an SSRF validator. It's a fast way to check assumptions during code review, without building a script just for that.