Summary
When the JWKS (JSON Web Key Set) resolver becomes unavailable or a key fetch fails, Istio falls back to hardcoded default keys regardless of whether a RequestAuthentication resource is configured. This means that JWT-based authentication policies may silently accept tokens signed with the hardcoded defaults rather than enforcing the operator-defined JWKS endpoint.
Impact
Any Istio deployment that uses RequestAuthentication with a remote JWKS resolver is affected by this vulnerability. If the JWKS endpoint becomes unreachable — due to network disruption, upstream service failure, or deliberate disruption — Istio's fallback to hardcoded default keys means that JWT validation effectively stops enforcing the intended cryptographic policy. Tokens signed with the hardcoded defaults may be accepted by the mesh, allowing unauthorized access to services that rely on JWT-based authorization. There is no workaround for users who rely on the JWKS resolver.
Detection
Monitor the Istio control plane logs for JWKS fetch failures or resolver errors. Operators using RequestAuthentication resources should verify that JWKS endpoints are reachable from Istiod at all times. Review your service mesh's audit logs for unexpected authentication successes, particularly during periods when external JWKS endpoints may have been intermittently unavailable.
Mitigation
Upgrade Istio to a patched version on the appropriate release line:
- Istio 1.29.1 or later (for the 1.29 line)
- Istio 1.28.5 or later (for the 1.28 line)
- Istio 1.27.8 or later (for the 1.27 line)
There is no effective workaround for users who rely on a JWKS resolver. Upgrade is the only remediation.