Spring gRPC EUVD-2026-26054

Exploitation requires three concrete conditions: (1) the application must use Spring gRPC 1.0.0 through 1.0.2; (2) the gRPC service must accept both authenticated requests (to populate ThreadLocal identity) and unauthenticated requests (to inherit it), typically in services that expose public and private endpoints; (3) the attacker must already possess valid credentials to trigger the initial access-denied condition and must be able to send a follow-up unauthenticated request to the same worker thread before context cleanup occurs. This limits exploitation to services with mixed authentication models. Systems using Spring gRPC only for authenticated-only endpoints, or only for unauthenticated endpoints, are not vulnerable. Default Spring gRPC configurations without explicit mixed-auth design are less likely to be vulnerable.

CVSS 4.3 (AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N) indicates moderate but not critical severity with two significant constraints: the attacker must already be authenticated (PR:L), and attack complexity is high (AC:H), likely due to the requirement to trigger the exact thread reuse timing window. The vulnerability requires precise coordination - an attacker must first make an authenticated request that is denied, then immediately send an unauthenticated request to the same worker thread before context cleanup. No EPSS score or KEV status provided; absence of active exploitation reporting combined with AC:H suggests this is a real vulnerability with limited practical exploitation likelihood. The scope being unchanged (S:U) indicates no ability to impact other security domains. Defenders should prioritize patching systems where gRPC services handle both authenticated and unauthenticated requests, but this does not represent immediate critical risk compared to unauthenticated remote execution vulnerabilities.

An attacker with valid credentials makes an authenticated gRPC call to a protected method, triggering a server-side access denial that fails to clear the authentication context. The attacker immediately sends a second unauthenticated request to the same gRPC service, exploiting the fact that the worker thread still holds the previous user's identity. The unauthenticated request is processed with inherited permissions, allowing the attacker to read or modify data they should not have access to. Success requires millisecond-level timing precision and knowledge of thread pool behavior.