夜雨聆风最近看到一则新闻，一名叫Eric Chiang的安全研究员用Claude Opus搭了一套AI辅助的测试框架，系统地翻了一遍市面上主流的SAML开源实现，结果挖出了一串认证绕过漏洞。其中一个漏洞编号CVE-2026-57580，能让攻击者通过一个XML注释直接接管他人账户。
为什么SAML总是“翻车”？
在聊这些漏洞之前，我觉得有必要先解释一个问题：SAML这个东西，为什么总是被爆出安全问题？
因为SAML依赖XML数字签名。而XML签名这个东西，在安全界有个不太光彩的名声——它足够复杂，以至于“每一个SAML库最终都被发现存在完整的认证绕过漏洞”。
根本原因在于：签名验证库和业务应用解析同一个XML文档时，可能得出不同的结论。验证库说“这个签名是有效的”，但应用却去读了另一段内容。攻击者要做的，就是利用这种“解析差异”，让系统接受一个签名有效、但内容已被篡改的SAML断言。
Oblique的研究人员对这件事有一个很直白的评价：SAML本身就是一个“主动危险”的协议。
Claude是怎么挖出这些漏洞的？
Chiang在加入Anthropic的网络验证计划（Cyber Verification Program） 后，建立了一个多代理环境。
他不是让Claude去找某个具体的已知漏洞，而是给它一个威胁模型，让系统自己去研究目标代码库中XML处理、解析和签名验证的异常行为。系统会先搜索潜在的可利用“组件”（比如危险的规范化或转换行为），然后把确认的结果串联成概念验证（PoC）利用代码。中间结果被记录在JSONL文件中，用来筛选、去重、过滤无关问题。
这个过程持续了大约一个月。最终，Claude发现了四个项目的完整认证绕过漏洞。
具体发现了什么？
Authentik（CVE-2026-57580）
在SAML的NameID值中注入一个XML注释，可以截断身份值，让攻击者冒充另一个用户。
Oblique的研究人员在博客里写了一个很形象的描述：这就好比你用“admin”登录，但系统把“admin”后面的注释截断了，结果把“admin”当成“root”来处理。
PHP litesaml/lightsaml（CVE-2026-63182）
一个SAML响应签名包装（signature-wrapping）漏洞。攻击者可以保留一个合法断言的签名，同时把应用导向另一个恶意断言。
OneUptime 和 Java saml-client
同样受SAML响应签名包装漏洞影响。
除此之外，研究还发现了认证请求、属性查询和注销流程中的签名验证绕过，以及恶意XML输入导致的拒绝服务风险。
更有意思的是：Authentik这个漏洞有8个独立的研究人员几乎同时报告了相同的漏洞。这很能说明问题——AI辅助工具正在让那些隐藏很深但模式可重复的实现缺陷，被以前所未有的速度发现。
影响有多大？
Authentik在2026.2.6和2026.5.5版本中已经修复。
lightsaml的修复版本尚未明确，但漏洞已被追踪为CVE-2026-63182。
PortSwigger已经演示了对GitLab EE 17.8.4的实际利用，并确认xmlseclibs 3.1.4和相关Ruby-SAML公告（CVE-2025-66567、CVE-2025-66568）已发布修复。
一点想法
这次研究让我觉得有意思的地方，不是Claude“发现”了什么新漏洞，而是它改变了漏洞研究的方式。
传统的人工代码审计，受限于人的精力和注意力，很难在一个月内系统性地覆盖这么多SAML实现。Claude辅助的框架能做到的是：穷举——一直跑到找出漏洞或者线索耗尽为止。人工审计做不到这种程度的“穷举”，不是因为技术不行，是因为人需要睡觉。
另一个值得注意的点是：那个8个研究员同时发现同一个漏洞的情况，说明AI辅助工具正在把“发现漏洞”这件事从“靠运气和直觉”变成“靠系统和规模”。以前一个漏洞可能藏几年没人发现，现在可能几周内被多组人同时挖出来。
Oblique的研究人员在博客最后说了一句话，我觉得挺准确的：2026年的漏洞研究状态是“暗淡”的。不是因为漏洞变少了，而是因为AI让漏洞被发现的速度，远远超过了厂商修复的速度。
而SAML这个“主动危险”的协议，显然还会继续成为AI辅助研究的重点目标。