Spring gRPC leaks authenticated identity to later unauthenticated requests
TL;DR - In Spring gRPC, when an authenticated user is denied access to a gRPC method, their identity can stay bound to the worker thread. The next request that lands on that thread - even an unauthenticated one - can inherit that identity and the permissions that come with it.
What happened
Spring gRPC is Spring's integration layer for building gRPC services with Spring Security. CVE-2026-40968 describes a thread-affinity bug in how SecurityContext is cleaned up after an access-denied decision.
When a gRPC worker thread processes an authenticated request that gets rejected by Spring Security, the authenticated identity isn't always cleared from the thread. A subsequent request routed to that same worker thread can pick up the leftover SecurityContext and proceed as if it belongs to the original user - even if it arrives with no credentials at all.
This is request-to-request identity confusion. It isn't broken crypto or an injection flaw. It's the kind of bug that's nearly invisible in unit tests and only surfaces under real concurrency: mixed authenticated and unauthenticated traffic, with timing that puts the right request on the wrong thread. The failure is silent and the impact is direct privilege escalation.
This class of context-propagation leak is well-documented across thread-pool-based frameworks. The novelty here is that the trigger is an access-denied path - exactly the flow you'd expect to be safe.
Who is impacted
- Services running
Spring gRPCversions1.0.0through1.0.2. Spring notes that older, unsupported versions are also affected. - Highest concern: multi-tenant or internet-facing gRPC services where unauthenticated calls can reach endpoints gated by Spring Security.
| Component | Affected versions | Fix version |
|---|---|---|
Spring gRPC | 1.0.0 - 1.0.2 | 1.0.3 |
What to do now
- Upgrade to
1.0.3immediately. Per the advisory: "Users of affected versions should upgrade to the corresponding fixed version." No additional mitigation steps are required once patched. - If you can't patch right now, add concurrency tests to staging that interleave denied authenticated calls with unauthenticated ones on the same endpoint. Confirm identity doesn't cross request boundaries.
- After patching, review gRPC access logs for unexpected method access following access-denied events. Look for unauthenticated calls that reached protected methods without an explicit auth decision.
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.