Which versions of Istio are affected by CVE-2026-31837?

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…. A patch is available.

How to fix or mitigate CVE-2026-31837?

Within 24 hours: Inventory all Istio deployments, identify versions currently running, and document JWKS resolver configuration and availability. Within 7 days: Apply vendor patches to upgrade affected instances to Istio 1.29.1, 1.28.5, or 1.27.8 or later, prioritizing production clusters; verify JWKS resolver resilience as part of testing. Within 30 days: Confirm patch deployment across all environments, validate JWT authentication enforcement through functional testing, and update Istio version records in your configuration management system.

Istio CVE-2026-31837

Q: What is the CVSS score of CVE-2026-31837?

CVE-2026-31837 has a CVSS 4.0 base score of 8.7 (High). CVSS vector: 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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.1%.

HIGH

Information Exposure (CWE-200)

2026-03-10 security-advisories@github.com

Information Disclosure Istio

8.7

CVSS 4.0 · Vendor: github

Severity by source

Vendor (github) PRIMARY

8.7 HIGH

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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

5.9 MEDIUM

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).

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

SUSE

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Red Hat

7.5 HIGH

qualitative

Primary rating from Vendor (github).

CVSS VectorVendor: github

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Analysis Updated

Jun 30, 2026 - 04:58 vuln.today

v3 (cvss_changed)

Analysis Updated

Jun 30, 2026 - 04:56 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Jun 30, 2026 - 03:24 vuln.today

cvss_changed

CVSS changed

Jun 30, 2026 - 03:24 NVD

7.5 (HIGH) 8.7 (HIGH)

Analysis Generated

Mar 12, 2026 - 21:55 vuln.today

CVE Published

Mar 10, 2026 - 22:16 nvd

HIGH 7.5

DescriptionCVE.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.

AnalysisAI

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.

Technical ContextAI

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.

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.