Istio 1.29.4：修复 Envoy HTTP/2 内存耗尽漏洞与多项 Ambient 模式关键缺陷

Istio 1.29.4 是一个以安全修复和稳定性提升为主的补丁版本。最值得关注的是 CVE-2026-47774——一个 CVSS 7.5 的高危漏洞，攻击者可以通过精心构造的 HTTP/2 请求让 Envoy 进程内存耗尽，导致拒绝服务。此外，Ambient 模式在本版本集中修复了多个生产级问题：CNI 并发 panic、跨网络 Waypoint 路由失败、以及 publishNotReadyAddresses 导致流量被错误路由到未就绪端点的隐患。

Envoy HTTP/2 内存耗尽：CVE-2026-47774

漏洞根因有两层：

1. Cookie 头字节未被完整计入请求头大小校验——Envoy 在验证请求头总大小时漏算了 Cookie 头的部分字节，绕过了本应起作用的 max_request_headers_kb 限制。
2. HPACK 编码字节有上限，但解码后的总头大小无对应限制——HTTP/2 的 HPACK 压缩让少量编码字节就能膨胀出巨大的解码头，Envoy 只限制了编码侧，解码侧没有兜底。

两者叠加，攻击者可以用一个看似合规的 HTTP/2 请求把 Envoy 内存吃光。漏洞不需要认证，任何能触达 Envoy 监听端口的外部流量都可能利用。

影响范围：所有使用 Istio 入口 Gateway 或 Sidecar 代理的集群，只要对外暴露了 HTTP/2 端口，就存在风险。

升级到 1.29.4 是当前唯一的官方修复方式。如果你暂时无法升级，可以在 Gateway 层面限制连接/流参数作为缓解措施：

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: http2-limits-mitigation
spec:
  host: "*.local"
  trafficPolicy:
    connectionPool:
      http:
        h2UpgradePolicy: DEFAULT
        maxRequestsPerConnection: 100

注意：上述配置只是降低攻击面，并不能堵住解码侧无限制的根因。升级仍是必须动作。

nftables 后端启动自检：不再无限重试

Istio CNI 的原生 nftables 后端在移除 Pod 时需要用 JSON 格式读取 nft 配置。但部分宿主机上的 nft 二进制没有编译 JSON 支持，调用会返回 Error: JSON support not compiled-in，CNI agent 随后无限重试，Pod 删除卡死。

1.29.4 在 CNI 启动时新增了检测：如果 nft 不支持 JSON 输出，自动回退到 iptables 后端，并在日志中明确记录。

你可以提前确认宿主机上的 nft 是否支持 JSON：

# 在节点上执行
nft -j list ruleset 2>&1 | head -1

# 如果输出 "Error: JSON support not compiled-in" 则该节点会自动回退到 iptables
# 如果正常输出 JSON 规则集，则 nftables 后端可以正常工作

生产环境中建议在节点初始化脚本里统一检查，避免升级后才发现回退行为：

# 节点就绪检查脚本示例
if ! nft -j list ruleset > /dev/null 2>&1; then
  echo "WARNING: nft lacks JSON support on this node, Istio CNI will use iptables backend"
  # 可选：记录到节点标签供运维追踪
  # kubectl label node $NODE_NAME istio-cni-backend=iptables --overwrite
fi

Ambient 模式三连修复

并发 map 写入 panic

两个 Pod 同时被加入同一节点的 Ambient mesh 时，istio-cni agent 内部的并发 map 写入会触发 fatal panic，导致 CNI 进程崩溃。这在批量扩容或滚动更新场景下极易触发。1.29.4 加了适当的锁保护，消除了这个竞态。

跨网络 Waypoint 路由失败

在多网络 Ambient 架构中，当 A 网络的 Ingress 调用 B 网络的 Service 时，即使 Service 配了 istio.io/ingress-use-waypoint: "true" 注解，流量也不会经过 Waypoint，直接绕过了 L7 策略执行点。1.29.4 修正了 ztunnel 在跨网络场景下对 Waypoint 的路由判断。

如果你正在用多网络 Ambient，检查现有 Service 是否已经标注了该注解但流量实际未经过 Waypoint：

# 查找所有标注了 ingress-use-waypoint 的 Service
kubectl get svc -A -o json | \
  jq -r '.items[] | select(.metadata.annotations["istio.io/ingress-use-waypoint"]=="true") | "\(.metadata.namespace)/\(.metadata.name)"'

升级后这些 Service 的跨网络流量才会真正走 Waypoint。

publishNotReadyAddresses 导致健康策略泄漏

当一个 Service 同时设置了 publishNotReadyAddresses: true 和 trafficDistribution: PreferSameZone（或 PreferSameNode）时，ztunnel 会把 healthPolicy: AllowAll 错误地扩散到同一 trafficDistribution 预设下的所有其他 Service。结果是集群范围内，使用相同流量分布策略的 Service 都会把流量路由到未就绪端点。

这个 bug 的危险在于：一个配置不当的 Service 会污染整组 Service 的健康检查策略，影响面远超预期。升级后每个 Service 的 healthPolicy 计算独立进行，不再互相干扰。

排查是否已经受影响：

# 检查是否存在 publishNotReadyAddresses + trafficDistribution 共存的 Service
kubectl get svc -A -o json | \
  jq -r '.items[] | select(.spec.publishNotReadyAddresses==true and .spec.trafficDistribution!=null) | "\(.metadata.namespace)/\(.metadata.name) — trafficDistribution=\(.spec.trafficDistribution)"'

如果输出非空，升级前这些 Service 关联的端点可能已经在接收不该到达的流量。

Gateway API 两个配置静默失效的修复

ListenerSet 的 TLS 证书缺失

通过 ListenerSet 定义 HTTPS 监听器时，如果父级 Gateway 使用手动部署模式（manualDeployment），TLS 证书不会下发到 Envoy——监听器实际上在无证书状态下运行，握手必然失败，但 Istio 控制面没有报错。

1.29.4 修复了证书下发逻辑。如果你用了这个组合，升级后建议验证证书是否真正生效：

# 检查 Gateway 证书下发状态
istioctl proxy-config secrets <gateway-pod-name>.<namespace> --output json | \
  jq '.dynamicActiveSecrets[] | .name'

HTTPRoute/GRPCRoute 无效头值不再静默丢弃

当 HTTPRoute 或 GRPCRoute 的 filter 中包含无效的 header 值时，旧版本会直接从 Envoy 配置中移除该 filter，不报告任何状态。路由看起来被接受了，但 filter 实际没生效——比如你设了一个 header rewrite，它悄悄消失了。

1.29.4 改为将 filter 标记为 Invalid 状态，路由的 status.conditions 会明确报错：

# 升级后检查是否有被标记为 Invalid 的路由
kubectl get httproute -A -o json | \
  jq -r '.items[] | select(.status.conditions[]?.type=="Accepted" and .status.conditions[]?.status=="False") | "\(.metadata.namespace)/\(.metadata.name): \(.status.conditions[]?.message)"'

这个改动让配置错误从"静默失效"变成"可观测"，对调试效率提升很大。

升级前检查清单

升级顺序建议：先升级控制面（istiod），再逐节点滚动升级 CNI 和数据面。对于多网络 Ambient 集群，建议在低流量时段操作，因为 ztunnel 路由逻辑在升级过程中会短暂重建。

CVE-2026-47774 的修复没有配置 workaround 的余地，尽快升级是唯一正确动作。其余修复虽然不涉及安全漏洞，但 Ambient 模式的并发 panic 和健康策略泄漏在规模化场景下同样会造成生产事故——如果你的集群已经启用了 Ambient，这个补丁版本不应跳过。