Istio
CVE-2026-31837
HIGH
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify mesh using RequestAuthentication JWT auth
-
DeliveryJWKS resolver unavailable or fetch fails
-
ExploitProxy falls back to hardcoded defaults
-
ExecutionSend request with invalid/crafted token
-
ImpactReach protected service, disclose data
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V14 - Data Protection Data exposure prevention
MITRE ATT&CK
2 techniques across 2 tactics: Collection, Discovery The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires that Istio's JWKS resolver be unavailable or that a JWKS fetch fail for an issuer configured in a RequestAuthentication resource; under that condition the proxy uses hardcoded defaults instead of the operator's keys, weakening JWT enforcement. The primary limiting factor is this precondition - under healthy JWKS resolution the fail-open default is not reached - so deployments using inline jwks (no network fetch) or with highly available JWKS endpoints are far less exposed. The flaw only matters where RequestAuthentication-based JWT authentication is actually configured and depended upon for access control; meshes not using request authentication are not meaningfully affected. Per the CVSS vector the request path is network-reachable and unauthenticated (PR:N). |
| Impact | Signals are mixed and warrant nuance. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H) rates this 8.7 High, treating it as network-reachable, unauthenticated, low-complexity with high confidentiality impact and no integrity/availability impact. However, exploitation is explicitly conditioned on the JWKS resolver being unavailable or a fetch failing - a precondition the attacker does not directly control under default healthy operation - which in practice raises attack complexity or introduces an attack requirement beyond what AC:L/AT:N suggest; defenders should weigh this. Corroborating low-urgency signals: EPSS is 0.05% (15th percentile), there is no public exploit identified at time of analysis, and it is not in CISA KEV. Net: a legitimate confidentiality/authorization-bypass concern for mesh operators relying on RequestAuthentication, but realistic risk is gated on a JWKS outage condition, so this is a patch-on-normal-cycle priority for most rather than an emergency, with elevated urgency for environments where JWKS endpoints are flaky or externally hosted. |
| Exploit ScenarioDerived | An attacker targets a service mesh whose RequestAuthentication relies on a remotely fetched JWKS; during a JWKS endpoint outage (or by inducing one), the proxy falls back to hardcoded defaults and no longer correctly enforces JWT validation, letting the attacker reach protected endpoints with crafted or otherwise-rejected tokens. No public exploit is identified at time of analysis, and the CVSS network/low-complexity vector means the request itself is trivial to send once the JWKS fetch is failing. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv3 – Jun 30, 2026
Authentication enforcement in Istio service mesh fails open: prior to 1.29.1, 1.28.5, and 1.27.8, when the JWKS resolver is unavailable or a key fetch fails, the proxy falls back to hardcoded defaults instead of denying the request, undermining JWT validation configured via the RequestAuthentication resource and exposing protected services to unauthorized access. The flaw (CWE-200, vendor CVSS 4.0 8.7) is remotely reachable without authentication, but is conditioned on a JWKS fetch failure. There is no public exploit identified at time of analysis, EPSS is very low (0.05%, 15th percentile), and it is not listed in CISA KEV.
Earlier versions of this analysis (2)
Sensitive information disclosure / authentication fallback in Istio service mesh allows protected workloads to silently revert to insecure hardcoded defaults when the JWKS resolver cannot be reached. Affecting Istio releases prior to 1.29.1, 1.28.5, and 1.27.8, the flaw means that if fetching the JWT signing keys (JWKS) fails or the resolver is unavailable, the configured RequestAuthentication policy is effectively ignored, exposing default behavior regardless of operator intent. There is no public exploit identified at time of analysis and EPSS is very low (0.05%), but the CVSS 4.0 base score of 8.7 reflects high confidentiality impact via an unauthenticated network vector.
Istio is an open platform to connect, manage, and secure microservices. Prior to 1.29.1, 1.28.5, and 1.27.8, a user of Istio is impacted if the JWKS resolver becomes unavailable or the fetch fails, exposing hardcoded defaults regardless of use of the RequestAuthentication resource.
RemediationAI
Vendor-released patch: upgrade Istio to 1.29.1, 1.28.5, or 1.27.8 (whichever matches your minor branch) per GHSA-v75c-crr9-733c (https://github.com/istio/istio/security/advisories/GHSA-v75c-crr9-733c). Red Hat / OpenShift Service Mesh users should apply the corresponding errata: RHSA-2026:5948, RHSA-2026:5950, RHSA-2026:5952, or RHSA-2026:10184 (https://access.redhat.com/errata/RHSA-2026:5948). If immediate patching is not possible, reduce reliance on the failing path: prefer inline jwks values in RequestAuthentication over remote jwksUri fetches to remove the network-fetch failure mode, and ensure JWKS endpoints are highly available and reachable from the mesh (caching, local mirroring) so the fail-open default is never triggered - note this does not remove the code-level defect, only the precondition. As defense in depth, pair RequestAuthentication with AuthorizationPolicy rules that explicitly require validated principals/claims so a JWT-validation fallback alone does not grant access; the trade-off is added policy-management overhead and potential request denials if claims are misconfigured.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Istio is a Kubernetes-native service mesh that offloads request-level authentication to its Envoy sidecar proxies. The RequestAuthentication custom resource configures origin (end-user) JWT validation, and the istiod control plane / proxy resolves the issuer's JSON Web Key Set (JWKS) - either from an inline jwks value or by fetching jwksUri over the network - to obtain the public keys used to verify token signatures. The root cause is an information-exposure / fail-open condition (CWE-200): when the JWKS resolver cannot retrieve keys (resolver unavailable or fetch failure), the code substitutes hardcoded default values rather than failing closed, so signature validation no longer reflects the operator's intended trust configuration. Affected CPE is cpe:2.3:a:istio:istio across version ranges below the three fixed branches.
Know when Istio gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Network-reachable and unauthenticated (AV:N/PR:N), but gated on a JWKS fetch-failure precondition the attacker does not reliably control (AC:H); impact is authorization/confidentiality only (C:H, I/A:N).
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
4DescriptionCVE.org
Istio is an open platform to connect, manage, and secure microservices. Prior to 1.29.1, 1.28.5, and 1.27.8, a user of Istio is impacted if the JWKS resolver becomes unavailable or the fetch fails, exposing hardcoded defaults regardless of use of the RequestAuthentication resource. This vulnerability is fixed in 1.29.1, 1.28.5, and 1.27.8.
Executive ViewAI
Istio service mesh versions prior to 1.29.1 contain an authentication bypass where JWT validation fails open if the JWKS resolver becomes unavailable, potentially exposing protected microservices to unauthorized access without credentials. This affects any organization using Istio's RequestAuthentication for service-to-service security and could enable attackers to access sensitive internal services when key resolution fails. Vendor patches are available and should be deployed to all affected instances.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Affected Products (CPE)CVE.org
Denial of service against HTTP/2 server implementations allows remote unauthenticated attackers to exhaust server resour
Remote code execution is possible in Node.js releases that bundle a vulnerable Brotli decoder: a malformed brotli-compre
Istio before 1.8.6 and 1.9.x before 1.9.5 contains a remotely exploitable vulnerability where an external client can acc
Istio 1.3.x before 1.3.5 allows Denial of Service because continue_on_listener_filters_timeout is set to True, a related
Envoy 1.12.0 allows a remote denial of service because of resource loops, as demonstrated by a single idle TCP connectio
Istio before 1.1.13 and 1.2.x before 1.2.4 mishandles regular expressions for long URIs, leading to a denial of service
Istio 1.1.x through 1.1.6 has Incorrect Access Control. Rated high severity (CVSS 7.5), this vulnerability is no authent
In Istio 1.5.0 though 1.5.8 and Istio 1.6.0 through 1.6.7, when users specify an AuthorizationPolicy resource with DENY
Istio before 1.8.6 and 1.9.x before 1.9.5 has a remotely exploitable vulnerability where an HTTP request path with multi
Istio is an open platform to connect, manage, and secure microservices. Rated critical severity (CVSS 9.8), this vulnera
Istio (1.8.x, 1.9.0-1.9.5 and 1.10.0-1.10.1) contains a remotely exploitable vulnerability where credentials specified i
Istio is an open platform-independent service mesh that provides traffic management, policy enforcement, and telemetry c
NVD
CVE.org
EPSS
GitHub
VulDB
Exploit-DB