Istio 发布的 ISTIO-SECURITY-2026-006 同时涉及捆绑的 Envoy 代理、Istiod 控制面以及 BackendTLSPolicy。问题覆盖 HTTP/2、HTTP/3、QUIC、ext_authz、RBAC、路径匹配和管理端统计页面等组件，最高 CVSS 评分为 7.7。运行 Istio 1.29.0 至 1.29.6 或 1.30.0 至 1.30.3 的集群，应把升级作为优先安全维护事项。
影响范围不只是一组 Envoy CVE
本次公告列出了 14 个 Envoy 相关 CVE，风险类型包括：
- HTTP/2、HTTP/3 和 QUIC 处理路径中的 use-after-free、进程异常终止和内存耗尽。
ext_authz处理 CONNECT 请求或授权回调时的进程终止与 use-after-free。safe_regex对非 UTF-8 请求头的处理可能让使用负匹配的 RBAC 策略 fail open。- 路径参数、点号路径段和
ignore_path_parameters_in_path_matching导致代理与后端对同一个 URL 得出不同匹配结果，进而绕过路径认证或授权。 - 通用 HTTP upgrade 在共享上游连接中的跨用户响应污染。
- HTML 统计接口
/stats?format=html中动态统计名称引入存储型 XSS。
是否实际触发某个漏洞，取决于网格启用的功能。例如，没有启用 HTTP/3 的环境不会走部分 QUIC 和 HTTP/3 代码路径；但这不应成为长期停留在受影响版本上的理由，因为版本中包含多个相互独立的安全修复。
三类 Istio 侧风险
1. Istiod 的 EnvoyFilter 正则表达式 DoS
EnvoyFilter.spec.configPatches[].match.proxy.proxyVersion 接受的正则表达式长度此前没有限制。拥有某个命名空间 EnvoyFilter 创建或更新权限的用户，可以提交超大表达式，迫使 Istiod 在准入校验和配置分发阶段消耗过多 CPU 与内存，甚至导致控制面崩溃。
由于验证 Webhook 配置为 fail closed，Istiod 不可用时，整个网格的配置变更也可能被拒绝。因此在多租户集群中，影响范围可能超出攻击者所在命名空间。修复版本将该表达式限制为 1024 个字符；不受支持的旧 Istio 版本也受到影响。
2. BackendTLSPolicy 可能对 sidecar 明文发送流量
当 sidecar 上游流量使用 BackendTLSPolicy，且 caCertificateRefs 指向的 ConfigMap 被删除、改名或根本不存在时，策略可能 fail open：sidecar 继续以明文访问上游，而不是阻断连接。这会丢失策略要求的加密和 CA 校验。
该问题影响 mesh sidecar 上游流量，Gateway 入站代理不受影响，Gateway 会 fail closed。使用 BackendTLSPolicy 的团队应把 CA 引用完整性纳入配置审计和删除保护流程。
3. 权限边界决定控制面 DoS 是否可被利用
如果只有网格管理员能管理 EnvoyFilter，攻击者就无法直接提交恶意 proxyVersion 表达式；如果命名空间租户拥有创建或更新权限，则需要立即收紧 Kubernetes RBAC。即使暂时无法升级，也应先完成这个缓解措施。
升级与临时缓解
官方修复建议为：
- Istio
1.30用户升级到1.30.4或更高版本。 - Istio
1.29用户升级到1.29.7或更高版本。
可以先确认控制面与数据面版本，再执行对应升级。下面的命令假设使用 istioctl，并且当前上下文已经指向目标集群：
istioctl version
istioctl x precheck
# 根据当前大版本选择一个已修复版本
istioctl upgrade --set revision=default
# 升级完成后再次检查控制面和代理状态
istioctl version
istioctl proxy-status
具体升级参数应与现有安装方式、revision、Helm values 和多集群拓扑保持一致。生产环境建议先在 canary revision 或预发布集群验证 HTTP/3、ext_authz、RBAC、Gateway 和自定义 EnvoyFilter 行为。
在升级前限制不受信任用户管理 EnvoyFilter，可以采用命名空间级 RBAC。下面是一个最小示例，假设租户不需要创建或修改 EnvoyFilter；实际角色绑定应按组织的管理员组调整：
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: tenant-config-editor
namespace: tenant-a
rules:
- apiGroups: ["", "apps"]
resources: ["configmaps", "deployments", "services"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
# 故意不授予 networking.istio.io/envoyfilters 的 create/update 权限
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: tenant-config-editor
namespace: tenant-a
subjects:
- kind: Group
name: tenant-a-developers
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: tenant-config-editor
apiGroup: rbac.authorization.k8s.io
如果集群中已经存在更宽的 ClusterRole 或 RoleBinding，仅删除这个 Role 不足以完成限制，还需要检查用户实际获得的所有权限：
kubectl auth can-i create envoyfilters.networking.istio.io \
--as=alice@example.com \
-n tenant-a
kubectl auth can-i update envoyfilters.networking.istio.io \
--as=alice@example.com \
-n tenant-a
kubectl get role,rolebinding,clusterrole,clusterrolebinding -A -o yaml \
| rg -n "envoyfilters|EnvoyFilter|networking.istio.io"
上面的 kubectl auth can-i 结果应为 no。管理员仍应保留经过审计的 EnvoyFilter 变更流程，避免为了缓解 DoS 而完全失去必要的代理配置能力。
一份可执行的排查清单
- 记录 Istio 控制面版本、代理版本和安装 revision，确认是否落在受影响区间。
- 搜索网格中的
EnvoyFilter，重点检查proxyVersion是否由非管理员用户提交或修改。 - 检查是否启用了 HTTP/3、QUIC、
ext_authz、RBAC 负匹配、路径参数匹配和共享上游连接。 - 检查是否使用
BackendTLSPolicy，并验证每个caCertificateRefs指向的对象存在且具备变更保护。 - 升级到
1.30.4+或1.29.7+，然后观察 Istiod 重启、Webhook 拒绝、代理连接和授权日志。 - 在升级后验证受保护路径、CONNECT 请求、HTTP/3 流量、统计页面和 TLS 上游连接。
这次公告的处理重点不是逐个判断 CVE 是否命中，而是尽快离开受影响的 Istio 版本，同时收紧 EnvoyFilter 权限并确认 BackendTLSPolicy 不会在 CA 引用失效时退回明文。对于无法立即升级的集群，RBAC 限制可以降低控制面 DoS 风险，但不能替代包含 Envoy 修复的正式版本升级。