没有人偷走密钥。是保险库自己交出去的。

您团队中的一名低权限成员，就可能带走整个组织的保险库密钥。不是某一个共享登录，而是密钥本身。

这就是 CVE-2026-60104，本周在自托管 Bitwarden Server 中披露 [1]。可用的概念验证已经公开，意大利和比利时的国家响应团队都发布了预警 [2][3]。修复很快发布在 2026.6.0 版本中，@Bitwarden 的云客户从未受到影响。如果您运行自己的服务器，请今天就打补丁。

补丁是最简单的部分。它背后的设计才是重点。

漏洞存在于一个名为 Trusted Device Enrollment（受信任设备注册）的功能中。TDE 的存在有其充分理由：它让人无需重新输入主密码，就能在新笔记本电脑上登录。由一台您已经信任的设备，或者一名管理员，来批准新设备，然后该账户的加密密钥就会被交付给它。很方便，甚至可以说很人性化——对于每周都有新人入职的团队而言。

现在请再读一遍。账户的加密密钥是被交付过去的。整个功能建立在一个单一前提之上：只要正确的一方批准，保险库密钥就可以从一方交给另一方。CVE-2026-60104 正是一名低权限成员走到这条批准路径前、索取从来不属于他的密钥时会发生的事情。密码学没有失效。系统完全按照它被设计的方式运行了。它共享了。

@Bitwarden 在这里并没有掉以轻心。他们一天内就发布了修复，其托管用户毫无感知。比一个 bug 更难接受的教训是：当一把密钥在设计上可以被托管（escrow）时，就存在一条说服托管方交出它的路径。每一个审批工作流都是攻击面，因为每一个审批工作流，按其定义，就是一种把密钥转移给新人的方式。

所以我们采用了相反的前提。

在 Clavitor 中，保险库密钥不是服务器保管并发放的秘密。它是您硬件密钥的输出，只有在您物理触碰时才会产生。运营方从不以任何形式存储可以解密任何内容的密钥，因此服务器上没有东西可以释放。不存在会交付保险库密钥的管理员批准流程，因为不存在可以交付的服务端密钥。一名成员无法索取另一名成员的保险库，因为没有任何请求路径以密钥告终。每一次解锁都绑定到执行解锁的设备，并以具名行为者写入审计记录。

诚实的边界在于：您仍然可以添加第二台设备。添加时，密钥会为那枚新硬件密钥重新封装。但这需要您触碰一枚已经持有的密钥，而不是一个陌生人可以写表单说服的审批。密钥绝不会停留在某个工作流可以将其送走的地方。

这就是全部区别。一个能够交付密钥的保险库，就可能被说服把它交给错误的人。一个只对您手中的硬件开启的保险库，无物可交。

我们写下了一份凭证工具绝不该做之事的清单。持有密钥并可在被要求时交出它，排在清单前列。[4]

Clavitor (@clavitorai) 是为 AI 智能体而建、也为了防范它们的凭证保险库。clavitor.ai

---

来源

CVE-2026-60104，美国国家漏洞库（NVD）条目。自托管 Bitwarden Server 认证绕过，已在 2026.6.0 中修复。[1]

CSIRT Italia (@csirt_it)，公告：CVE-2026-60104 的公开概念验证，被归类为安全限制绕过与信息泄露。[2]

比利时网络安全中心（Centre for Cybersecurity Belgium，@CCBalert），预警：认证绕过使低权限组织成员可窃取其他用户的保险库，CVSS 9.3，请升级至 v2026.6.0 及以上。[3]

凭证管理十条法则（The Ten Rules of Credential Management，@clavitorai）。[4]