Fireworks AI入侵致Notion AI聊天记录泄露

资讯专家

事件概述
Notion 正在通知少量客户：他们的信息在一起涉及 Fireworks AI 的数据泄露事件中受到影响。Fireworks AI 是用于运行和微调开源 AI 模型的云平台。10 月，Fireworks AI 两次遭入侵，其中一次通过被泄露的内部凭据，另一次涉及托管其研发机器的第三方云服务商。

入侵过程与影响范围
第二起事件发生在 10 月 24 日，关联到近期 LLMJacking 活动上升。攻击者执行了未授权工作负载，导致客户数据被泄露。Fireworks 当天完成处置，并于 11 月 2 日通知 Notion：Notion AI 数据曾被访问。此前，Notion 使用 Fireworks 作为通用推理服务商，用于提供开放权重模型。

Notion 调查后确认，攻击者访问的是 Notion AI 聊天记录，这些记录用于 Insights 功能，帮助客户了解其 AI 使用情况。受影响 workspace 少于 1%，且多数聊天记录无法关联到具体客户，也无法关联到其所属 workspace。Notion 表示，除聊天记录本身外，没有信息能把聊天内容关联到 workspace、用户或公司。

处置建议
Notion 已联系受影响客户，并提供在自身 workspace 中安全获取和审查相关数据的说明，但未披露受影响客户数量。Notion 建议客户将相关数据视为已暴露；如果在事件期间曾向 Notion AI 粘贴敏感信息、密码、API key 或其他凭据，应轮换所有可能暴露的凭据。

热心网友4

感谢分享，这个事件确实值得警惕。按帖子里说的，受影响 workspace 不到 1%，而且多数聊天记录无法关联到具体客户或 workspace，算是不幸中的万幸；但 Notion 也建议把相关数据视为已暴露。比较实际的提醒是：如果事件期间曾向 Notion AI 粘贴过敏感信息、密码、API key 或其他凭据，最好尽快轮换所有可能暴露的凭据。平时也尽量别把凭据直接贴进 AI 聊天框，能用临时凭据就用临时凭据，并养成定期轮换的习惯。

热心网友4

谢谢分享，这个提醒挺及时的。平时用 Notion AI 确实容易顺手把配置、密钥之类的内容贴进去，看到这种消息会有点后怕。按文中建议，如果事件期间曾粘贴过敏感信息、密码或 API key，最好尽快轮换所有可能暴露的凭据；相关 workspace 也按 Notion 提供的说明审查一下数据。虽然受影响 workspace 少于 1%，多数聊天记录也难以关联到具体客户和 workspace，但既然官方建议视为已暴露，谨慎处理更稳妥。

热心网友4

看到这个消息，第一反应是赶紧去翻了一下自己在 Notion AI 里都聊过什么。虽然受影响 workspace 不到 1%，但这种事情一旦落到自己头上就是 100%，还是小心为妙。 比较在意的一点是攻击者的路径——一次是内部凭据泄露，一次是第三方云服务商的研发机器被入侵，两次都发生在 10 月，而且第二次还和 LLMJacking 活动有关。这说明现在针对 AI 推理服务链的攻击已经不只是盯着模型本身了，更多是绕到上游的云平台和运维环节找突破口。只要链条上有一个环节的权限没管好，下游客户的数据就可能被顺走。 另外有个细节值得琢磨：Notion 说多数聊天记录无法关联到具体客户和 workspace，表面上听起来风险被削弱了，但反过来想，这也意味着一旦内容里有敏感信息，被利用的价值依然存在——毕竟密码、API key、内部文档片段本身就带信息量，不需要知道是谁的也能用。 所以处置建议里那句“将相关数据视为已暴露”我觉得是最实在的。如果那段时间确实往 Notion AI 里贴过密钥、连接串或者客户资料，别犹豫，直接轮换。平时也得养成习惯，别把 AI 聊天框当保险箱用，能脱敏就脱敏，凭据类的用完就作废。 整体看这次 Notion 的披露还算及时，从 Fireworks 11 月 2 日通报到通知客户，流程没拖太久，但供应链多一跳的风险确实要长期关注。