CVE-2026-39350: Istio Auth Bypass Vulnerability

CVE-2026-39350 Overview

Istio, an open platform used to connect, manage, and secure microservices, contains an authorization bypass vulnerability in its AuthorizationPolicy implementation. The serviceAccounts and notServiceAccounts fields incorrectly interpret dots (.) as a regular expression matcher rather than as literal characters. This behavior is problematic because the dot character is valid in service account names, leading to unintended matching behavior that can bypass security controls.

Critical Impact

Attackers can bypass Istio AuthorizationPolicy rules by exploiting the regex interpretation of dots in service account names. An ALLOW rule for cert-manager.io inadvertently permits access to cert-manager-io, cert-managerXio, and similar variants, while DENY rules fail to block these unauthorized accounts.

Affected Products

• Istio versions 1.25.0 through 1.27.8
• Istio versions 1.28.0 through 1.28.5
• Istio versions 1.29.0 and 1.29.1

Discovery Timeline

• 2026-04-15 - CVE CVE-2026-39350 published to NVD
• 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2026-39350

Vulnerability Analysis

This vulnerability is classified under CWE-185 (Incorrect Regular Expression), where the AuthorizationPolicy mechanism in Istio improperly handles dot characters in service account name matching. In regular expression syntax, a dot (.) is a metacharacter that matches any single character. However, in Kubernetes service account naming conventions, dots are legitimate literal characters used to construct hierarchical or namespaced identifiers such as cert-manager.io.

When administrators configure AuthorizationPolicy rules using serviceAccounts or notServiceAccounts fields, Istio treats the dot as a regex wildcard instead of escaping it for literal matching. This creates a security gap where policies intended to permit or deny specific service accounts actually match a broader set of accounts than intended.

For example, an ALLOW rule targeting cert-manager.io will match:

• cert-manager.io (intended)
• cert-manager-io (unintended)
• cert-managerXio (unintended)
• cert-manager1io (unintended)

Conversely, a DENY rule targeting cert-manager.io fails to block the variant names, allowing unauthorized service accounts to bypass access restrictions.

Root Cause

The root cause lies in the regex pattern construction within Istio's AuthorizationPolicy validation logic. The serviceAccounts and notServiceAccounts field values are not properly sanitized to escape special regex characters before being used in pattern matching operations. This results in the dot character being interpreted as a regex metacharacter (matching any character) rather than as a literal period.

Attack Vector

The attack vector is network-based and requires an attacker to have low privileges within the Kubernetes cluster. An attacker can create or utilize service accounts with names that exploit the regex matching behavior. By registering a service account named cert-manager-io or similar variants, an attacker can:

1. Gain unauthorized access to resources protected by ALLOW rules targeting service accounts with dots in their names
2. Bypass DENY rules intended to block specific service accounts

The attack does not require user interaction and can be executed by any entity with the ability to create service accounts or control workloads in the mesh.

Detection Methods for CVE-2026-39350

Indicators of Compromise

• Unexpected service accounts accessing resources protected by AuthorizationPolicy ALLOW rules
• Service accounts with names containing hyphens or other characters where dots would normally appear (e.g., service-name-io instead of service-name.io)
• Authorization audit logs showing access granted to service accounts that should be blocked by DENY rules
• Anomalous workload behavior from service accounts with naming patterns similar to legitimate accounts

Detection Strategies

• Review all AuthorizationPolicy resources that use serviceAccounts or notServiceAccounts fields and identify entries containing dots
• Audit Kubernetes namespaces for service accounts with names that could exploit regex matching (e.g., variants of legitimate names with dots replaced)
• Implement Istio access logging to capture and analyze all authorization decisions for anomalies
• Deploy admission controllers to validate service account naming conventions and flag suspicious patterns

Monitoring Recommendations

• Enable and monitor Istio telemetry and access logs for unexpected authorization grants or denials
• Configure alerts for service account creation events with names resembling existing accounts but with character substitutions
• Periodically audit AuthorizationPolicy configurations against the list of service accounts in the cluster
• Monitor for changes to AuthorizationPolicy resources that may introduce vulnerable patterns

How to Mitigate CVE-2026-39350

Immediate Actions Required

• Upgrade Istio to patched versions: 1.29.2, 1.28.6, or 1.27.9
• Review and audit all existing AuthorizationPolicy resources for serviceAccounts and notServiceAccounts fields containing dots
• Identify and remove any suspicious service accounts that may exploit the regex matching vulnerability
• Temporarily implement additional network policies or RBAC rules to restrict service account access until patching is complete

Patch Information

Istio has released security patches addressing this vulnerability. Fixed versions include:

• Version 1.29.2 (for users on 1.29.x)
• Version 1.28.6 (for users on 1.28.x)
• Version 1.27.9 (for users on 1.27.x)

For detailed information, refer to the GitHub Security Advisory.

Workarounds

• Avoid using dots in service account names referenced in AuthorizationPolicy rules until the patch is applied
• Manually escape dots in service account patterns by using \. instead of . if the Istio version supports escaped regex syntax
• Implement additional layers of defense using Kubernetes RBAC and NetworkPolicies to restrict service account access
• Use namespace-level isolation to limit the blast radius of potential exploitation

# Example: Review AuthorizationPolicy resources for vulnerable patterns
kubectl get authorizationpolicies -A -o yaml | grep -E "(serviceAccounts|notServiceAccounts)" -A 5