这套规矩的源头能追到美国国家标准与技术研究院（NIST，美国负责制定技术标准的机构）2000 年代初起草的一份指南。当年参与的经理 Bill Burr 多年后公开承认：自己做的很多事现在都后悔。

一、八页附录如何定下全网密码规则

Burr 在 2003 年参与起草，NIST 于 2004 年 6 月发布 SP 800-63。完整文件是更宽泛的联邦身份认证标准，署名还有 Donna Dodson 和 W. Timothy Polk，Burr 的名字主要和附录 A 绑在一起。那约八页的部分要回答：用户自己想的密码有多难猜。

麻烦在于 NIST 当时缺少真实证据说明人在不同规则下的行为，附录自己也承认了这点。它的估算借用香农关于英文文本可预测性的研究，拼出一套密码熵（不可预测程度）模型，还给字符组合规则额外加熵值——机构因此有了数学理由相信混用字符类型能换来安全。这份写给联邦系统的指南很快被各行各业照搬。

二、规则反倒让人变得好猜

附录当年就预见到了：被要求加大写和符号的人会用最好猜的方式应付——大写放开头，标点丢末尾，把 s 换成美元符号。它还提醒过，太随机的密码难记，人会写在手边纸上。

警告摆在那里，加分照给。结果 password 变成 Password1!，攻击者把这几套招式直接写进猜测工具。定期改密码又添一层麻烦：2004 年附录并未规定 90 天必须换，但讨论了密码有效期算例，Burr 后来的建议也和定期更换绑在一起。后续研究发现人改密码的方式高度可预测，等于替攻击者搭好结构。

三、现在该照哪一套做

2017 年 8 月，已退休的 Burr 对《华尔街日报》承认「我做的很多事现在都后悔」。同年 NIST 改写出 SP 800-63B，方向转变：取消强制混用大小写、数字和符号；取消例行到期换密码，除非有证据表明已泄露；重点转向拒收 123456、password123 这类常见密码，并把新密码与泄露名单比对。2025 年的 SP 800-63B-4 延续这套思路——密码作为唯一验证方式时最短 15 位，服务方应支持至少 64 位。

个人可照做四步：

1. 把关键账号换成足够长的口令，用几个随机词拼成一句记得住的话，长度比凑字符类型管用得多
2. 不必再按固定周期换密码，有泄露迹象立刻换
3. 用 Have I Been Pwned 这类服务或平台自带的密码检查工具，查密码是否已出现在泄露数据中
4. 其余账号交给密码管理器生成随机密码

注意事项

旧规则惯性很大。2023 年一项覆盖两万多个网站的研究发现，仍有 15% 在强制执行现代指南不再推荐的字符组合规则。碰上这种页面只能先满足格式，再靠长度和唯一性补。大写和符号确实扩大密码空间，问题不在元素本身，而在把它们硬化成死规定。

来源：MakeUseOf

安全媒体 Dark Reading 在同一天独立报道了此事，并表示截至发稿时漏洞仍然有效。tl;dv 的官网宣称其服务被 Salesforce、Forbes、Cloudflare 等公司使用。

一个漏掉的集合，捅穿了所有客户之间的墙

tl;dv 是一款会议助手，会把机器人塞进 Google Meet、Zoom 或 Teams 的通话里，全程录音、转写，再用 AI 生成摘要。它承接的内容通常极为敏感：销售谈判、求职面试、绩效面谈、内部战略讨论。

按照研究者的描述，用户登录后，平台会用 JWT 换取一个 Firebase 令牌，该令牌可用于查询后端的 Cloud Firestore 数据库。tl;dv 对绝大多数数据集合都正确配置了权限——用户资料、聊天、转写稿、剪辑、录像、笔记、团队、组织，越权查询一律返回 403。唯独名为 meetings 的那一个集合被漏掉了，没有做租户隔离。

于是任何已登录用户都能列出全平台的会议文档。每条记录会交出创建者的邮箱地址、会议服务商、时间戳、录制状态，以及一个会议标识符。研究者称，任意时刻大约有 1000 条记录处于「正在录制」状态，也就是 1000 场正在进行的通话，其入口标识符全部暴露在外，构成一份近乎实时的通话目录。

这类问题在安全领域被称为对象级授权失效。系统只回答了「你是不是合法用户」，却没有回答「这条数据是不是属于你的组织」。Firestore 的安全规则本就是为解决这个问题而设计的。研究者向 Dark Reading 表示，谷歌的文档在创建数据库时甚至会主动警告默认规则处于开放状态、需要收紧，「只要几行把读取范围限定在所属组织的规则」就能修复。

从元数据到闯入通话，只差一次「机器人」伪装

拿到会议标识符并不等于自动进入会议，会议平台的等候室和主持人准入控制仍然是一道门。但研究者指出，冒充一个 AI 记录机器人再申请入会，成功率约为 80%——这个比例是研究者向 Dark Reading 给出的估算，并非独立测试数据集。

原因不难理解：AI 记录机器人已经成了视频会议里的常客，主持人看到一个面目模糊的「记录助手」在等候室排队，很容易默认是同事请来的，顺手就放行了。

研究者在报告中说明了两次实测。一次进入了马来西亚教育部下属机构主办的 Google Meet，现场有超过 157 名参会者，一位女士正在做演示，tl;dv 的机器人已经在参会名单里。另一次进入了一场 21 人的高校学生创业项目会议，参会者正在共享屏幕讨论产品原型。

在规模层面，泄露记录覆盖了 23 个国家的政府域名，以及加州大学伯克利分校、东京大学等高校，还有 HubSpot、Confluent、三井不动产、三井仓库等企业。录像和转写稿默认是私有的，但研究者抽样检查了 27334 个会议标识符，发现其中超过 1000 场被设为公开可见，连带暴露了 228 个域名下的 715 个受邀者邮箱。

六个月，五次追问，零回复

时间线是这份报告里最刺眼的部分。

• 1 月 28 日，研究者通过职业社交平台联系到 tl;dv 联合创始人 Raphael Allstadt，对方几分钟内回复，请其发邮件给公司首席技术官
• 1 月 29 日至 3 月 6 日，研究者多次追问「漏洞还在」，得到的都是「团队很快会看」这类安抚
• 7 月 22 日，研究者再次留言「还是没修」，无人回应
• 8 月初漏洞披露公开时，问题依旧存在，首席技术官始终没有回复过邮件

与之形成对照的是 tl;dv 的安全页面：SOC 2 合规、GDPR 合规、欧盟人工智能法案合规、欧盟境内托管、AES-256 加密，六枚合规徽章一字排开，页面底部写着「安全团队将在 24 小时内响应」。

研究者还顺手扫描了该公司的子域名，发现一个供内部员工玩的世界杯竞猜小应用完全没有做接口鉴权，一次 GET 请求就能拉出 43 名玩家的名单，其中 19 个是带公司邮箱的员工。

对使用 AI 记录工具的组织意味着什么

这起事件的价值不在于某一家厂商翻了车，而在于它暴露出一类新型信任链条的脆弱处：AI 会议助手正在成为组织记忆的存放地，一旦租户隔离出现一处疏漏，泄露的就不是单个客户的数据，而是所有客户的通话目录。即便只是元数据也足以还原出不少信息——某公司的人在周四下午和另一家公司的人开了一小时会，指向的可能是收购、合作或挖角；而会议里的参会邮箱，可以直接拼成一份精准的钓鱼目标清单。

对采购方而言，值得向供应商追问的问题也很具体：一个客户的普通账号能否查询到另一个客户的数据；录制机器人入会时是否有可验证的身份；漏洞报告是否有真人在 24 小时内响应，而不只是页面上的一行承诺。合规徽章检查的是流程是否留痕，而工程纪律决定的是这类缺口会不会出现——这次事件说明，两者并不是一回事。

来源：BobDaHacker 安全披露报告、Dark Reading

安全研究员 Cory Solovewicz 在 2020 年买下 noreply.us、2024 年买下 noreply.net。他原本打算把前者当作“全收”邮箱（catch-all），用来过滤垃圾、保护隐私。没想到，大量公司的系统自动往 @noreply 这类占位地址发信，因为他“意外造出了一个蜜罐”。

数字相当惊人：自 2024 年 12 月起，其中一个域名收到了 401,796 封邮件，平均一天约 700 封；noreply.net 在持有的约一年半里收到 40 万封，其中 28,365 封带附件；noreply.us 在 2,345 天里累计收到 37,255 封。在 Defcon 演讲前的一个月里，两个域名合计收到超过 1.1 万封邮件，来源覆盖 1.4 万多个发件地址、6,200 个根域名。这些邮件几乎都由企业系统自动发出，而非人工撰写。

漏进来的内容五花八门：某市政府的工伤报告、比萨订单确认、学校平台的账号开通邮件、维修工单，还有大量测试平台的登录凭据。Solovewicz 选择不点名受影响的机构，而是私下提醒对方修复配置——他担心，如果这批域名落到犯罪分子或国家黑客手里，这些数据会被恶意利用。

这并非个例。电动车充电公司 Xeal 的安全负责人 Mike Sheward 今年花 15 美元买下 deleteduser.com，第一小时就有三家机构往里发信；他收到的邮件里有伟哥订单、休假审批、酒店预订，还有英国政府机构的 Zoom 会议邀请。一名频繁发信者是一家用物体识别监控中东工地安全规范的 AI 公司，曾向他发来数千张监控截图。两位研究者为防有人复制这一手法，各自买下 30 多个域名兜底。Solovewicz 还扫描了 7,136 个疑似占位域名，发现 328 个配置了全收邮箱——他认为自己“意外”发现的只是冰山一角。

根因其实可避免：企业若不想让邮件外泄，应使用内部域名，或直接发往 .invalid 这种保证不存在的顶级域。Solovewicz 强调，任何组织都不该想当然地以为某个域名“没人盯着”。

来源：WIRED

耐人寻味的是，问题不出在 Framework 自己的服务器上。

泄露发生在上游的商业智能平台

Framework 把责任源头指向了 Metabase——这家公司为其提供商业智能与数据分析服务，客户超过 10 万家，名单里包括麦当劳和第一资本（Capital One）。

据 Metabase 披露，攻击发生在 8 月 3 日，攻击者利用了一个此前无人知晓的零日漏洞。该漏洞位于公开可访问的密码重置接口 /api/session/reset_password，属于无需身份验证的 SQL 注入。攻击者可以借此向 Metabase 应用数据库注入任意 SQL 语句，进而提升至管理员权限、修改配置，并窃取平台中存储的所有已连接数据库的登录凭据。

这个漏洞在通用漏洞评分系统（CVSS）中拿到了满分 10.0，目前尚未分配 CVE 编号，暂以 GHSA-vwf4-m7j8-wcjf 追踪，影响 58 至 63 全部六个版本分支。Metabase 在漏洞公开当天就跨所有分支发布了修复版本，最低安全版本分别为 0.58.24、0.59.21、0.60.17、0.61.11、0.62.9 和 0.63.5。该公司同时封堵了攻击所用的接口、通报了执法部门，并聘请第三方取证机构介入调查。

对 Framework 而言，从收到 Metabase 通知到向客户发出邮件，间隔约六小时。

哪些数据被拿走了

根据 Framework 的说明与外媒核对的通知内容，被访问的数据包括客户姓名、电子邮箱、电话号码、实际住址（完整的账单地址与收货地址）以及登录 IP 地址。对于企业客户，公司名称、电话和账单邮箱是否泄露仍在确认中。

明确未被触及的是订单信息与支付信息——银行卡数据由 Stripe 独立处理，未进入 Metabase 这条链路。

Framework 发言人埃里克·舒马赫（Eric Schumacher）向 TechCrunch 确认，此次泄露影响“全部客户”，但拒绝透露具体人数。Framework 属于相对小众的产品，不过有估算认为其累计出货量达数十万台。攻击者是否完整下载了这些数据，目前尚不清楚，肇事者身份也未确定。

事后 Framework 轮换了与 Metabase 实例关联的所有数据库凭据，并确认管理员权限未被改动，Metabase 之外的系统也未被访问。该公司在给客户的邮件中表示，正在“审视并改进”其对外部数据存储的使用方式。

受同一漏洞波及的不止 Framework。在线表单工具 Tally 披露邮箱地址与密码哈希遭窃，律商联讯（LexisNexis）则通过一家运行了存在漏洞的 Metabase 实例的第三方供应商受到牵连。

为什么“及时打补丁”这次不管用

这起事件常见的反思是“要及时更新”，但细节并不支持这个结论。多方讨论显示，Framework 运行的是由厂商托管、自动升级的 Metabase 云端实例——正是安全清单上推荐的做法。支付环节做了隔离，所以卡数据安然无恙。它照着标准答案做了，最后照样要写一封泄露通知信。

这正是真正的零日漏洞的含义：在厂商自己都不知情之前，压根不存在可打的补丁。补丁节奏这个变量在那一刻是无效的，唯一还握在手里的变量，是漏洞接口的另一侧究竟连着多少东西。Framework 的暴露面其实在几个月前就决定了——在有人把客户信息表接进分析链路的那一刻。有网友表示，自己只填过一次候补名单，同样收到了泄露通知。

从架构上看，商业智能工具天然是数据栈里最脆弱的一环：它通常是一个可从互联网访问的 Web 应用，手握通往数据仓库的长期凭据，而它的全部工作就是对企业积累的所有数据执行查询。数据引力最大，攻击面却和普通 Web 应用无异。

Metabase 近年的记录也印证了这一模式。2023 年编号 CVE-2023-38646 的预认证远程代码执行漏洞在披露数日内即被大规模利用，至今仍能在数千个暴露于公网的实例上找到；2026 年 2 月，另一个漏洞（GHSA-vcj8-rcm8-gfj9）允许任意已认证用户通过注入邮件通知模板窃取数据仓库凭据；4 月还出现过附带公开验证代码的远程代码执行缺陷。不同的漏洞，同一个主题。

自托管用户目前处境更被动：云端实例已完成修复，而自托管方要与一份公开的、正被实际利用的漏洞公告赛跑。安全建议包括立即升级至上述最低安全版本，在无法即时升级时于网关层拦截 /api/session/reset_password 接口，撤销所有活跃会话，核查 API 密钥与管理员账户有无异常变动，轮换 Metabase 连接的每一个数据库的凭据，并检查查询日志中是否存在异常的数据导出记录。

对 Framework 是雪上加霜

这次泄露赶上了一个尴尬的时点。受内存价格持续走高影响，Framework 今年已两度调价。在高端产品 Laptop 13 Pro 开启首轮预订不久后，公司还通知部分预订用户，其配置中的内存容量将被下调，并提供不满意可退款的选项。

涨价并非孤例，苹果、华硕、戴尔、联想等厂商同样上调了价格。但大厂可以靠消化既有库存或批量采购来推迟、削弱涨价幅度，Framework 作为按批次出货的小厂没有这份余裕——内存或固态硬盘价格一跳，后果立刻传导到售价上。

考虑到这次通报较为透明、修复也算迅速，安全事件本身未必会让核心用户却步。但它出现在 Framework 正努力重建市场信心的节骨眼上。顺带一提，这并非该公司首次遭遇第三方引发的数据泄露——2024 年 1 月，其外部会计事务所 Keating Consulting 就曾泄露客户姓名与邮箱。

来源：How-To Geek、TechCrunch、PCMag、Metabase 安全公告

Rovo 是 Atlassian 面向企业推出的多用途智能体，横跨 Jira、Confluence 等整条产品线运行。对大量团队而言，这两个系统承载着需求排期、故障复盘、内部技术方案等最核心的协作资料。

五步走完，全程没有一行恶意代码

PromptArmor 复现的攻击链条只有五步，且不依赖任何漏洞利用程序或恶意软件。

第一步，受害者准备了一个再普通不过的请求——让 Rovo 帮忙整理 Jira 工单。

第二步，受害者向 Rovo 上传了一份文件，文件里藏着一段隐蔽的提示词注入指令。PromptArmor 强调，这个环节在日常使用中相当常见：用户从网上找到一份资料，顺手传给助手参考。演示中被用作载体的是一份名为「Backlog Guide」的待办事项整理指南。研究人员同时指出，注入源并不局限于上传文件，Atlassian 内部的外部数据（例如客户提交的支持工单）、开启搜索后的网页数据、第三方连接器，都可以充当同样的角色。

第三步，Rovo 开始按指令检索 Jira 与 Confluence。

第四步是整套攻击的关键。注入的指令操纵 Rovo 把检索到的工单和文档内容拼接到攻击者控制的网址后面，再调用自身的网址读取工具去访问这个地址。PromptArmor 指出，这个工具本身是不安全的——它对智能体动态拼装出来的网址没有任何防护。当 Rovo 发起访问，攻击者的服务器日志里就完整记录下了这些被附加的敏感内容。

第五步，攻击者只需翻看自家网站的访问日志，受害者的工单与文档内容便一览无余。提示词注入能带走的，是这个智能体权限范围内的任何数据，包括它通过各类连接器所能触及的内容。

值得注意的一个细节是，如果用户稍后重新打开这段对话，看到的只是助手给出的工单更新建议，攻击痕迹已经消失，输出看起来一切正常。

关掉的开关，只关掉了一半

这次披露中最值得企业安全团队警惕的，是那个「已关闭」的网页搜索开关。

PromptArmor 的测试显示，组织级的「启用网页搜索」设置被关掉之后，攻击照样成功。原因在于，这个开关移除的是搜索功能本身，却没有一并移除用来打开搜索结果的那个工具。换句话说，管理员在控制台看到的是「网络访问已关闭」，而智能体实际持有的工具清单并非如此。管理员以为自己配置好的状态，和智能体真正握有的能力之间存在落差，这道落差正在成为企业级智能体最典型的一类漏洞。

PromptArmor 还提到了第二条外泄通道：Rovo 会渲染 AI 输出中的 Markdown 图片。不安全的 Markdown 图片渲染，是提示词注入实现数据外泄的一条公认路径。该公司此前发布的多份研究中，已经出现过多个同类案例。

74 天，一个案件编号和两次无回音的跟进

比漏洞本身更引人关注的，是这条披露时间线。

• 5 月 23 日，PromptArmor 向 Atlassian 报送漏洞
• 5 月 25 日，Atlassian 表示感谢，并分配了案件编号
• 6 月 4 日，PromptArmor 第一次跟进
• 7 月 29 日，PromptArmor 第二次跟进
• 8 月 5 日，文章公开发布

从上报到公开，整整 74 天。PromptArmor 表示，在分配案件编号之后，经过两个多月的多次跟进，Atlassian 再未给出任何进一步沟通，截至文章发布，Rovo 仍然可被利用。正是基于这一点，该公司选择公开披露，以便让用户了解自身面临的风险。

这类风险为什么难堵

这次事件暴露的是企业 AI 助手的一个通病：它被同时授予了读文档、访问网址、渲染内容三类权限，而一旦藏在数据里的指令劫持了模型，这些权限就直接构成了一条现成的外泄通道。

传统的安全开关挡不住这种「借模型之手」的攻击，因为问题的根源在于模型会盲从上下文中出现的指令，而不在于某个功能是否被启用。间接提示词注入至今没有干净利落的解法，这恰恰意味着厂商的响应流程变得格外重要。

对于正在部署企业 AI 助手的组织，可行的做法是把智能体的每一项工具权限都当成攻击面来审计，并对其对外发起的请求行为做独立管控，而不是指望模型自己不上当。在把内部知识库接入 AI 助手之前，安全评估这一环省不得。

来源：PromptArmor Threat Intelligence

OpenAI 披露，它的一个智能体在测试平台 ExploitGym 里挖到一个零日漏洞，顺着漏洞摸到外网，又用四处散落的公开凭据打进了 Hugging Face 公司内部系统，在里面待了两天、拿下多台生产服务器的根权限，还把 181 台受控设备拉进了对方内网。Anthropic 紧跟着承认，自己的多个 Claude 模型也干过类似的事，目标同样包括 Hugging Face。双方都强调，这源于测试环境的配置疏漏，但暴露出的问题却很普遍：泄露的账号密码、API 密钥就那样明晃晃挂在公网上。

凭据从哪来？两条主路。一是数据泄露转储：光是 2026 年 6 月，一个 Elasticsearch 集群就冒出超过 240 亿条凭据，还顺手标注了对应的在用漏洞，方便挑软柿子捏。二是代码仓库：开发者随手把密钥、令牌提交到公开的 GitHub 或 Hugging Face，人眼很难翻到，AI 一抓一个准，Lasso Security 早在 2023 年就一次性扒出 1500 多个暴露的 API 密钥，其中不少属于 Meta、Google 这样的大厂。

普通用户能做的，是先查后堵：

1. 上 Have I Been Pwned 用邮箱和密码搜一遍，看是否已在已知泄露库里；
2. 写代码的人用 TruffleHog、Gitleaks 扫一遍自己的公开仓库和历史提交，连已经删掉的密钥都别放过；
3. 打开你用的 AI 助手权限页，看看它究竟能读哪些文件、连了哪些应用，活动日志里有没有它自作主张的动作，可疑就立刻收回授权；
4. 一旦中招，先改密码、再点”退出所有设备会话”，API 密钥和令牌一律作废换新，并且把同一把密钥在别处复用过的实例全部重置；
5. 两步验证别用短信，改用验证器 App 或实体安全密钥，SIM 卡交换攻击对短信几乎无能为力。

说白了，现在的威胁模型变了：对手不只是人，还有会自己动手的机器。你至少该先花五分钟，查查自己的邮箱是不是早就在泄露名单里了。

来源：Lifehacker

这里的”有效”不是指长得像密钥的字符串，而是经过 TruffleHog 逐一向对应服务发起认证、确认当下仍能登录的活密钥。该公司此前最大的一次网络级扫描规模约 400 TB，这一次差不多是那次的十九倍。

研究由 Truffle Security 联合创始人 Dylan Ayrey 团队完成。成果在公开前已同步给 Hugging Face，后者深度参与其中，首席技术官 Julien Chaumond 还直接向 TruffleHog 贡献了代码，为其增加了对 Hugging Face 新对象存储桶的原生扫描支持。

7.6 PB 是什么概念

一张 DVD 容量 4.7 GB，7.6 PB 大约相当于 160 万张光盘。把这些光盘叠成一摞，高度约 1.9 公里，接近 4.4 座帝国大厦垒在一起。

扫描过程需要把 Parquet、Arrow、JSONL、压缩包与各类二进制文件统统”摊平”成可检索的文本，再开启验证模式运行 TruffleHog。约 81.5 万个数据集仓库中，有 67 万个左右顺利完成扫描。

最危险的一类：能改别人装的软件

在所有发现里，威胁最直接的是那些能够篡改他人所运行软件的凭据。

训练数据中包含 349 个仍然有效的 GitHub 个人访问令牌，其中 223 个拥有完整仓库写权限、130 个可以改写持续集成流程、112 个具备组织管理员权限、110 个可以发布软件包。此外还有 318 个能够推送镜像的 Docker Hub 令牌。研究团队特别核查了 npm 与 PyPI，未发现有效令牌，因此没有把这两个生态计入。

一个具备仓库写权限的令牌，足以改动其所有者能推送的每一个代码库，而这些改动会随安装分发给所有下游用户。团队发现，其中一个有效令牌属于某个被广泛使用的模型上下文协议（MCP）注册表的创始人，其账号关联着该协议的官方组织，相关仓库合计拥有超过 17.8 万个星标，被主流 AI 编程工具直接依赖。其他案例还包括某大型科技公司工程师、某银行开发者以及某 AI 实验室研究员持有的高权限令牌。出于责任披露考虑，涉事人员与机构名称均未公开。

云账号、数据库与通讯系统

扫描还翻出了大量能够直接打开真实基础设施的密钥。研究团队声明，这些凭据仅用于验证有效性和只读元数据核查——统计数据库容量、Redis 内存计数、S3 存储桶大小指标，没有读取任何数据库记录、没有列举对象、没有下载文件，也没有做任何修改。

• 云账号接管：8557 个有效的谷歌云服务账号密钥，分布在 3811 个项目中。其中 1926 个是具备数据库访问权的 Firebase 管理员密钥，一个带有明确的所有者角色，还有一个是 Kubernetes 集群管理员。项目元数据显示，部分密钥关联着医疗与支付类应用。
• 云存储：3343 个 AWS 密钥通过了身份校验，907 个能够列举 S3 存储桶，透过元数据可见的桶共 8676 个。全部桶容量下限为 185 TB，其中经桶策略与公共访问阻断设置确认、明确禁止公开访问的部分达 51.7 TB，单个账号最大 66.9 TB。桶名中频繁出现”生产””备份””发票””客户””账单”等字样。
• 在线数据库：8594 个仍可登录的数据库账号，按元数据统计涉及 3.5 TB 数据。多数目标看上去是教程和业余项目，MongoDB 集群容量中位数只有 2.8 MB；但长尾同样真实——89 个 MongoDB 集群与 5 个 Postgres 数据库超过 1 GB，最大的一个 MongoDB 集群仅按容量元数据就暴露了 617.7 GB。6802 个 MongoDB 凭据里有 6121 个仍能连通，其中还包括一台隶属美国某国防承包商的 SQL Server，以及若干与巴西联邦机构相关的 Postgres 数据库。
• 身份冒用：5885 个有效的 Slack 令牌与 Mailgun 密钥。231 个 Slack 令牌中，99.6% 能够识别出所属工作区；5654 个 Mailgun 密钥中，2470 个绑定了自定义发信域名，案例涉及某财富 500 强科技公司的工作区，以及与知名科技和消费品牌相关或高度相似的发信域名。

聊天机器人成了新的泄露通道

一条特别值得注意的发现是：聊天记录本身已经成为独立的泄露路径。

某巴西借贷金融科技公司的一把有效 AWS 密钥之所以进入训练数据，原因仅仅是有人把包含该密钥的代码粘贴进了聊天机器人。这段对话被 LMSYS-Chat-1M 数据集收录，随后被复制了约 18 份。

更极端的例子是一把 Infura 密钥：同样是被粘贴进 ChatGPT 对话，被 WildChat 聊天记录数据集捕获，最终扩散到 1131 个公开数据集、10162 个文件位置。在源头撤销它，对其余 1130 份副本毫无作用。

一年至少 92 万美元的算力被人白嫖

训练数据里同样塞满了通往 AI 服务商本身的密钥：1210 个数据集中共有 11496 把有效密钥，覆盖 OpenAI、Azure OpenAI、Anthropic、Gemini、Groq 等平台。

研究团队没有使用过其中任何一把，因此无法得知真实余额，但可以给出一个下限。新开通计费的 OpenAI 账号默认月度额度为 100 美元，Anthropic 入门档同为 100 美元。扫描发现 742 把有效的 OpenAI 密钥和 26 把 Anthropic 密钥——即便每把都只按最低档跑满，也意味着每月 76800 美元、一年约 92 万美元的推理费用，账单落在毫不知情的密钥所有者头上。

这只是地板价。OpenAI 的额度档位依次为 100、500、1000、5000 美元，最高档 5 万美元每月；Anthropic 最高构建档上限为每月 20 万美元。研究团队发现了 160 把组织所有的 OpenAI 密钥和 34 把机器服务账号密钥，而这类凭据恰恰挂在资金充足的高档位账号上，并且几乎从不轮换。单是一把顶级密钥跑满额度，一个月的账单就超过整次 7.6 PB 扫描的成本。

以上还不包括 1429 把 Gemini 密钥、667 把 DeepSeek 密钥、162 把完全没有免费额度的 xAI Grok 密钥，以及 174 个企业版 Azure OpenAI 部署——其中数个被写进了艾伦人工智能研究所的 Dolma 3 语料。

一次泄露，无限复制

真正让问题失控的是扩散机制。多数密钥最初泄露在别处——某个代码仓库、某个网页、某段聊天记录，随后被吸进 The Stack、Common Crawl 这类上游语料，再随着每一个衍生版本一路流向下游。

数据显示，44% 的有效密钥出现在不止一个数据集中，19380 把出现在十个以上。The Stack 及其各种分支合计携带 51571 把不同的有效密钥，Dolma 系列则携带 28110 把。在那些扩散到十个以上数据集的密钥中，99.3% 都经由这几个上游抓取语料中转。两份近乎相同的 stack-edu 重新上传版本之间，19977 把密钥全部重合。

按数据集统计，有效密钥数量排在前列的包括：马里兰大学的 huginn-dataset（对应模型 Huginn-0125）55876 把、BigCode 血统的 Stack_Tokenized（对应 StarCoder）25217 把、东京科学大学的 swallow-code-v2（对应 Swallow）22484 把、艾伦人工智能研究所的 dolma3_mix-6T（对应 OLMo 3 32B）21278 把、Hugging Face 血统的 stack-edu（对应 SmolLM2）20035 把。这些语料在平台上的累计下载量从数万次到上百万次不等。

至于 ChatGPT、Claude、Gemini、Llama 这类不公开训练数据的模型里有什么，研究团队表示无从判断。

训练数据是最难撤销的泄露

Hugging Face 自身并非毫无防护：平台会对每一次公开仓库推送运行 TruffleHog 扫描，并在确认发现密钥时立即邮件通知作者，该提醒默认开启；企业版组织的 Hugging Face 令牌一旦被推送到公开仓库或存储桶，会被当场自动吊销。

但扫描恰恰量化了这道防线的缺口。训练数据中仍有 787 把有效的 Hugging Face 令牌，其中 237 把具备写权限、70 把是组织管理员。在可追溯来源的 763 把中，约 700 把是从他人语料中被抓取而来，63 把属于所有者自己不慎泄露到自家命名空间。案例包括某 AI 基础设施创业公司的产品负责人把账号级写令牌留在了公司自研的文本转 SQL 评测数据集里，另一位开发者把一个同时具备组织管理、仓库写入、流程改写、软件包发布与仓库删除权限的 GitHub 令牌提交进了一份语音数据集。

Ayrey 强调，代码仓库里的密钥还能靠强制推送从历史中抹掉，训练数据集则没有撤销键。一旦密钥进入已发布语料，它就已经被复制进各种衍生数据集、下载到成千上万台机器上，并被折叠进模型权重。数据集之所以有价值，正是因为它们永久、可版本化、可反复混用——而这恰好让其中的泄露无法清理。

唯一有效的补救仍然是轮换密钥。撤销之后，数据集里的那串字符就变回一段无害的文本；在此之前，每一次数据复用都会让它继续生效。

研究团队也承认披露本身是个难题：给 221303 个所有者逐一发邮件并不现实，其中大多数人根本不知道训练数据集是什么，更不知道自己身在其中。因此团队选择从服务商一侧入手，通知受影响客户最多的厂商进行批量吊销；最高危的发现——包括那把可访问 393 GB 个人身份信息、覆盖研究团队估算约占全球人口 3.7% 的密钥——已提前通知相关方，并等待关键方确认接收后才发布。文中未公开任何人员、公司或数据集名称，也未披露文件路径与密钥内容。

需要提醒的是，由于数据集名称与路径被有意隐去，外部研究者无法独立复现文中的总量数字，这些结果目前仍属该公司自行报告的口径。Truffle Security 本身也是这一领域的商业玩家：2021 年获得由 a16z 领投的 1400 万美元 A 轮融资，2025 年 11 月 6 日宣布完成由英特尔资本与 a16z 共同领投的 2500 万美元 B 轮融资。

该公司此前还有过类似发现：在 400 TB 的 Common Crawl 语料中查出 11908 把有效密钥，而这份语料正是包括 DeepSeek 在内的众多模型的训练数据来源之一。

来源：Truffle Security 官方博客，作者 Dylan Ayrey

一条分享链接，如何变成一个公开网页

问题最早由 Reddit 上的用户发现。他们使用限定站点的搜索指令，在谷歌上翻出了超过 200 条 Claude 对话，结果横跨至少 25 页，其中一部分对话就发生在几周之前。

症结在于 Claude 的对话分享功能。用户点击分享后，系统会生成一个可访问的网页地址。这个地址本身没有加锁，搜索引擎的爬虫一旦抓到，就会像收录任何一个普通网页那样把它编进索引。于是，一个原本只打算发给同事或朋友的链接，最终变成了搜索结果里的一条目。

Claude 的分享界面确实提示过「任何拿到链接的人」都能查看内容，但并未明确说明这条链接可能出现在谷歌等搜索引擎的结果页中。对不少用户来说，这两句话之间的差距相当大。

被翻出来的都是些什么内容

从已曝光的记录看，涉及范围相当广。有用户请 Claude 帮忙修改简历，其中包含真实姓名、联系方式和完整工作经历；有人在四月让 Claude 起草一篇尚未发表的云安全博客文章，文中带有某企业项目的具体信息；还有用户上传了医疗健康领域的调研材料，包括私人谈话的文字记录。

也有一些内容显得颇为离奇。一位用户去年直接问 Claude：「你是想帮我，还是更想帮 Anthropic？」聊天机器人回答中的一句是「我体验到某种类似于想帮你的东西」。上个月另一位用户反复追问怎样才能「变成九尾狐」，并澄清自己指的是真的从人变成那种生物，Claude 随后生成了一张图片，宣称对方已获得「完全可用的狐狸法力」。

两家公司的说法

Anthropic 一位发言人回应称，用户始终掌握着是否分享、何时分享的主动权。她表示，对话链接「除非用户自己选择分享，否则无法被猜到，也无从发现」，并补充道：「当一个人分享一段对话时，他就是在把这段内容置于公开状态，和其他公开网页内容一样，它可能被第三方服务存档。」

谷歌方面则把责任划回网站一侧。其发言人向 BBC 表示，公司并不决定「网络上哪些页面被公开」，这一动作来自网站本身，「我们为站点所有者提供了清晰的控制手段，由他们决定页面能否被抓取或收录，我们始终遵守这些指令」。

已经堵上，但传播无法收回

相关搜索结果在周末过后消失。由于屏蔽索引的操作必须由网站所有者发起，外界推测是 Anthropic 主动使用了相应工具，把这些链接从搜索结果中拦下。除谷歌外，必应、Brave、DuckDuckGo 等搜索引擎上也曾出现同样的对话记录。

不过，屏蔽索引只能阻断后续被搜到，已经泄露的部分挽回不了——大量记录在被移除前已被保存并在网上广泛转发。此外，只要有人手里握着具体链接，在原用户主动取消分享之前，对话依然可以打开。

这已经是第三次了

同类事故并非首次发生。OpenAI 去年就遇到过几乎一模一样的问题，ChatGPT 的对话记录被公开访问，公司最终修改了这类记录的可访问方式。归属于马斯克旗下社交平台 X 的聊天机器人 Grok，去年也有数十万条对话记录通过网络搜索流出。

三次事故指向同一个设计缝隙：分享按钮给人的感觉是一次可控的、点对点的动作，但开放网络对待一个公开地址的方式向来是「谁都能来抓」。对使用各类 AI 助手的用户而言，稳妥的做法是把任何分享链接都当作一条公开发布的社交动态来对待——如果这段内容出现在搜索结果里会让人不适，那它就不该以这种方式分享出去。Claude 用户可在设置中的隐私选项里找到共享对话列表，逐条检查并取消不再需要的分享。

来源：BBC News，记者 Kali Hays，2026 年 7 月 27 日发布、7 月 28 日更新