红帽紧急披露三枚高危漏洞：Kubernetes与FreeIPA权限提升风险全面解析

2026年8月下旬，红帽产品安全团队一次性披露了三个严重程度极高的权限提升漏洞，波及Kubernetes高级集群管理平台和FreeIPA身份认证系统两大核心产品线。其中CVE-2026-67567的CVSS评分高达9.9，属于典型的"严重"级别；另外两枚FreeIPA漏洞CVE-2026-13097和CVE-2026-11861分别拿到9.1和9.6的评分，同样不容小觑。好消息是目前红帽尚未监测到任何野外利用案例，企业仍有窗口期完成补丁部署。

这次漏洞 batch 的杀伤力在于攻击路径的多样性——一个盯上了云原生编排层的HelmRelease控制器，另外两个则精准打击了Linux域控环境下Kerberos票据体系的核心逻辑。换句话说，无论是跑容器集群的运维团队，还是管企业身份域的安全工程师，都得打起十二分精神。

三枚漏洞全景速览

先把底子摸清楚。这次披露的三个CVE横跨两类产品：Red Hat Advanced Cluster Management for Kubernetes（简称ACM）和FreeIPA。前者是企业级K8s多集群管理的标配工具，后者则是开源身份管理套件，集成了LDAP目录、Kerberos认证和Active Directory跨域信任能力。

漏洞评分方面，CVE-2026-67567以9.9分领跑，CWE分类为CWE-441（非规范化的路径遍历或权限配置问题）；CVE-2026-11861拿到9.6分，属于CWE-266（不正确的权限分配）；CVE-2026-13097评9.1分，对应CWE-706（使用错误解析的名称或引用）。三枚漏洞目前状态均为"未被利用"，但鉴于评分极高，企业不应掉以轻心。

HelmRelease控制器成了"特洛伊木马"：CVE-2026-67567深度分析

这是本次披露中最危险的一枚。问题出在ACM的multicloud-operators-subscription组件里，HelmRelease控制器在处理Chart模板时，直接套用了自身拥有高权限的ServiceAccount，却漏掉了对GVK（Group/Version/Kind）和命名空间边界的校验。

通俗点说，任何能在集群里创建HelmRelease资源的租户，都可以借助这个控制器的"免死金牌"把应用部署到整个集群的任意位置。正常来说，多租户K8s环境里Namespace就是隔离边界，但这个漏洞直接把墙拆了。攻击者不需要突破容器沙箱，也不需要利用内核缺陷，只需要一个合法的、权限极低的账号，就能在集群里横着走。

红帽安全公告里把这个问题描述为"权限提升路径"——我觉得这说法还算客气。实际上这更接近于权限绕过，因为HelmRelease控制器替攻击者完成了提权的全部脏活。对于运行着敏感工作负载的OpenShift或ACM环境，这枚漏洞的利用门槛之低、影响面之广，确实配得上9.9的评分。

FreeIPA的"身份危机"：CVE-2026-13097与CVE-2026-11861双响炮

如果说K8s那边的漏洞是"借刀杀人"，FreeIPA这两枚则是典型的"身份冒充"戏码。FreeIPA作为Linux生态里事实上的域控替代方案，承载着大量企业的统一身份认证和Kerberos票据分发职能。两枚漏洞同时命中这个组件，说明其安全模型在边界 case 上存在系统性盲区。

CVE-2026-13097：Kerberos主体的"影分身"

FreeIPA在389-ds目录服务器上对Kerberos主体名称施加了唯一性约束，但实现方式有个致命疏忽——它只比较字面量，没考虑同一主体的不同等价表示形式。举个例子，一个特权主体可能以某种规范形式存在，而攻击者用LDAP写权限创建另一个"看起来不一样、实际上一样"的服务主体，系统会放行。

这个漏洞由Vladislav Plyatsok报告，利用成功后攻击者可以拿到敏感服务的Kerberos服务票据，进而实现完整的域内权限提升。CVSS向量显示攻击复杂度低、无需用户交互、影响范围可扩散到CHANGED级别，意味着一个被攻破的账户可能拖垮整个信任域。

CVE-2026-11861：跨域信任里的PAC盲区

这枚漏洞的触发条件更苛刻一些——需要FreeIPA和Active Directory之间已经建立了信任关系。但恰恰是很多大中型企业的真实组网方式。问题出在KDC策略插件ipa_kdcpolicy_check_tgs处理跨域TGS-REQ请求时，只检查票据里有没有PAC（特权属性证书），却不验证PAC内容和TGS请求中的cname是否匹配。

结果就是，已经通过AD认证的合法用户，可以在票据授予服务里冒用其他客户端身份，绕过GSSAPI保护下的门户、SMB共享和LDAP目录访问控制。红帽把这枚漏洞的实际危害评为"中等"，但9.6的CVSS基础分说明理论风险极高。好在修复版本里已经加入了ipadb_check_trust_pac_content()交叉校验逻辑，堵死了这条冒充路径。

权限提升漏洞为何总被盯上

三枚漏洞虽然技术细节各异，但底层逻辑出奇一致：低信任度用户通过系统内部机制缺陷，获得了远超自身权限的操作能力。CVE-2026-67567是控制器ServiceAccount被滥用，CVE-2026-13097是LDAP唯一性校验失效，CVE-2026-11861是跨域票据验证偷懒。

从攻击者视角看，权限提升永远是性价比最高的突破口。相比从零开始打穿边界，利用系统内部已有高权限组件"搭便车"，不仅隐蔽性更强，而且往往不需要复杂的漏洞利用链。这次红帽披露的漏洞 batch 恰好覆盖了容器编排和身份认证两大基础设施层，一旦组合利用，攻击者可以从一个被攻破的K8s租户账号一路渗透到企业AD域控，这种横向移动的想象空间令人不安。

受影响范围与风险画像

直接受影响的产品线很明确：Red Hat Advanced Cluster Management for Kubernetes、FreeIPA以及依赖FreeIPA做身份管理的Red Hat Enterprise Linux各版本（6/7/8/9/10均在不同程度上受影响）。

风险最高的场景有两类：一类是运行着多租户K8s集群且广泛使用HelmRelease做GitOps部署的企业，另一类是FreeIPA与AD建立了跨域信任、且AD域控制器补丁滞后的环境。后一种情况尤其麻烦，因为CVE-2026-11861的缓解措施部分依赖于AD侧的安全更新，如果Windows域控团队和红帽Linux团队之间沟通不畅，很容易留下攻击窗口。

修复方案与缓解措施

红帽已经在8月20日同步发布了安全公告，建议受影响用户第一时间通过官方渠道获取补丁。对于暂时无法打补丁的环境，可以考虑以下临时缓解策略：

针对ACM侧的CVE-2026-67567，核心思路是收紧HelmRelease资源的创建权限。通过严格的RBAC策略，限制哪些Namespace、哪些ServiceAccount可以提交HelmRelease对象。理想情况下，只有集群级别的平台运维团队才应该拥有这个能力，普通应用租户连看都不该看到HelmRelease的CRD。

FreeIPA侧的两枚漏洞，补丁优先级应该是CVE-2026-13097高于CVE-2026-11861，因为前者不需要任何前置条件就能触发。对于CVE-2026-11861，除了更新FreeIPA本身，还要确保AD域控制器已经安装了最新的安全更新，切断跨域冒充的最后一块拼图。

另外，建议企业在补丁部署完成后，审计过去一段时间内所有HelmRelease创建记录和FreeIPA的Kerberos主体变更日志。虽然红帽表示目前未发现利用案例，但主动排查总比事后救火强。

写在最后

这次红帽漏洞披露再次印证了一个老道理：基础设施组件的权限边界设计，容不得半点马虎。HelmRelease控制器为了便利而借用高权限ServiceAccount，FreeIPA为了兼容而放宽主体名称校验，这些设计上的"小妥协"在正常情况下看似无害，一旦被攻击者盯上，就成了直插心脏的匕首。

对于安全团队来说，三枚高危漏洞同时出现既是压力也是契机。压力在于补丁窗口期有限，契机在于可以借这次事件推动一次全面的权限梳理——K8s侧的RBAC是否过度授权？FreeIPA侧的LDAP写权限是否收得太松？AD域信任关系是否还有存在的必要？这些问题，平时没人关心，现在不问，下次可能就没机会问了。