Fireworks再遭入侵，Notion聊天外泄

Fireworks AI的安全事件已经波及下游客户：Notion确认，黑客获取的数据中包含部分Notion AI聊天记录，受影响范围低于Notion工作区总数的1%。

这不是Notion自身系统被攻破，而是典型的AI供应链入侵。攻击者先进入Fireworks AI的开发环境，再接触到由Fireworks代为处理或保存的客户数据，最终让风险沿着“云服务商—AI基础设施平台—SaaS产品—企业用户”这条链路向下扩散。(techcrunch.com)

Notion已于11月3日切断与Fireworks的所有连接、删除存放在Fireworks系统中的数据，并停止向其发送流量；目前，Notion还停用了Insights功能，不再通过Fireworks提供开放权重模型的推理服务。11月11日，Notion进一步表示，已撤销在受影响用户消息中发现的Notion API密钥。(notion.com)

先看清楚发生了什么

Fireworks AI是一家为开发者和企业提供模型推理、训练及开放模型托管能力的AI基础设施公司。它处在用户看不见、却决定AI产品能否运行的底层：Notion负责产品界面和工作区体验，Fireworks则承担部分分类任务和模型推理工作。

Notion的Insights是一项面向企业管理员的AI使用分析功能。为了判断员工如何使用Notion AI，Insights需要对部分AI对话进行分类，而Fireworks正是承担这类处理任务的供应商之一。

这次遭到访问的聊天记录，就是为Insights分类而处理的模型输入和输出。Notion称，绝大多数受影响工作区的数据没有标注具体用户或工作区，也不包含工具调用结果；但聊天文本本身仍然完整存在，其中可能出现姓名、客户信息、内部项目名称、密码或其他凭据。(notion.com)

“无法归属”不等于“无法识别”。一段对话即使没有附带用户ID，只要内容里出现公司名称、项目代号、客户姓名或未发布产品信息，攻击者仍可能通过上下文完成身份关联。

事件时间线

这次事故不是一次孤立的误操作，而是Fireworks在不到一个月内披露的连续安全问题。

| 日期 | 事件 | 影响 | |---|---|---| | 10月6日 | Fireworks发现内部凭据遭到未授权使用 | 部分客户评估任务中的环境变量、密钥和令牌可能被访问 | | 10月9日 | Fireworks发布首份安全公告 | 公司撤销相关凭据，并通知已识别的受影响客户 | | 10月23日 | 托管Fireworks研发机器的第三方云服务商发生安全事件 | 攻击者获得进入Fireworks研发环境的新路径 | | 10月24日 | 攻击者进入Fireworks开发机器并运行未授权工作负载 | 更多客户数据受到影响，Fireworks当天发现异常 | | 11月2日 | Fireworks首次通知Notion存在数据访问事件 | 当时识别出的主要是Notion AI合成测试数据 | | 11月3日 | Notion全面切断Fireworks连接 | 删除Fireworks侧数据，并停止训练和数据传输 | | 11月6日 | Fireworks再次通知Notion可能涉及客户数据 | Notion启动第二轮内部调查 | | 11月8日 | Fireworks确认最终受影响数据集 | Notion发现其中包含Insights使用的AI聊天记录 | | 11月9日 | Notion通知受影响客户 | 影响范围低于全部工作区的1% | | 11月11日 | Notion撤销聊天内容中发现的Notion API密钥 | 降低凭据被进一步利用的风险 |

Fireworks表示，自10月25日起，没有再发现攻击者成功进入其客户使用的平台；但该公司的调查仍在继续，因此现有范围不能被视为最终结论。(notion.com)

泄露的不只是聊天记录

Fireworks确认，受影响的内部应用能够访问资源元数据、账单资料，以及部分客户的数据集和不完整模型权重。

| 数据类别 | 已披露的具体内容 | 潜在风险 | |---|---|---| | Notion AI聊天记录 | 写入聊天的模型输入与输出 | 内部信息、客户资料和凭据可能出现在正文中 | | 资源元数据 | 资源标识符、名称、描述、创建时间 | 帮助攻击者理解客户的模型与系统结构 | | 账单信息 | 账单及收货地址、付款记录、余额、额度使用情况 | 企业身份识别、诈骗及社会工程攻击 | | 客户密钥与令牌 | 评估任务环境变量中保存的凭据 | 访问第三方服务或产生未经授权的资源消耗 | | 数据集 | 部分客户上传的数据集 | 训练数据、业务语料或内部知识泄露 | | 不完整模型权重 | 部分尚未完成的模型权重 | 模型资产、训练成果和知识产权风险 |

Fireworks没有保存客户的支付卡号，因此信用卡卡号不在已披露的受影响范围内。该公司也表示，目前没有发现Inference、Training SDK和Nexus三项默认采用零数据留存机制的服务受到影响。(fireworks.ai)

这个表述需要谨慎理解：Fireworks不是在说平台上所有数据都安全，而是在说特定默认零留存服务暂未发现影响。Notion的Insights分类任务显然涉及另一条数据处理链路，否则聊天记录不会出现在攻击者可访问的数据集中。

零数据留存不是万能保险

零数据留存（Zero Data Retention，ZDR）是指服务商在完成请求处理后，不把用户输入和模型输出长期保存在持久化存储中。

ZDR能缩短数据暴露窗口，但它不是一项覆盖所有系统的魔法开关。请求日志、错误追踪、评估任务、批量推理、数据集训练、人工审核和使用分析，都可能走不同的数据管道，采用不同的保存策略。

Fireworks此次事件恰好说明，企业不能只问供应商“是否支持ZDR”，还必须问清楚四件事：哪些端点适用、哪些内部任务不适用、数据在内存和临时存储中停留多久，以及日志、评估数据和故障快照是否也被纳入删除策略。

AI产品的数据流比普通SaaS更复杂。一个用户在Notion里输入问题，背后可能先经过权限检索、上下文拼接和内容过滤，再交给外部推理平台；生成结果之后，还可能进入质量评估、安全检测和使用情况分析系统。每增加一个处理节点，就多出一份权限配置、一套日志和一个潜在攻击面。

这也是本次事件最值得警惕的地方：Notion自身没有被攻破，但用户仍然需要按照数据已经泄露来处理。

攻击者盯上的首先是模型访问能力

LLMJacking是一类通过窃取云凭据、模型访问令牌或服务账户权限，非法消耗大模型算力并获取经济利益的攻击活动。

Fireworks表示，现有证据指向一个具有经济动机的网络犯罪团伙，其目标包括窃取大模型访问令牌，再把未经授权的模型调用能力提供给灰色服务。攻击者未必一开始就冲着Notion聊天内容而来，但当其拿到开发环境和内部应用权限后，账单资料、数据集、模型权重和聊天记录都会变成可以顺手获取的资产。(fireworks.ai)

这种攻击模式正在改变AI基础设施的安全优先级。传统云攻击往往围绕数据库、源代码和加密货币挖矿展开；AI平台还额外集中保存模型访问凭据、GPU资源权限、训练数据以及模型权重，任何一项都具有直接变现价值。

Fireworks首次发现的问题正是内部凭据被滥用。攻击者访问了部分客户评估任务所使用的环境变量，其中可能包含第三方服务密钥和令牌；随后发生的第二波活动，则通过遭入侵的第三方云服务商进入Fireworks开发机器，并运行了未授权工作负载。(fireworks.ai)

Fireworks的问题比一次配置失误更严重

连续两波入侵暴露出Fireworks在身份权限、研发环境隔离和供应商风险控制上的薄弱环节。

第一波攻击涉及内部凭据以及客户评估任务中的环境变量，说明高敏感凭据能够被内部身份触达；第二波攻击又从托管研发机器的外部云服务商进入开发环境，说明Fireworks的防御边界不只由自己掌控。

更严重的是横向移动后的数据可见范围。一个受影响的内部应用能够接触账单信息、资源元数据、客户数据集和不完整模型权重，意味着控制面与数据面的隔离至少没有达到理想状态。

Fireworks的处置速度并不算慢。公司在10月24日当天检测到异常，随后撤销并替换凭据、收紧服务账户权限、隔离网络路径、加强日志系统，并暂停Batch Inference和基于数据集训练的自助上传及下载功能。公司还引入Palo Alto Networks Unit 42协助取证分析。(fireworks.ai)

但处置迅速不能抵消架构层面的疑问。对于一家承载数万客户、服务数十万开发者的AI基础设施平台，开发机器被突破后能够影响客户数据，本身就是需要重新设计权限边界的信号。

Notion的应对基本合格，但供应商治理仍需解释

Notion在收到第一轮通知后的次日就切断Fireworks连接，这个动作是正确的。

11月2日的初步信息只显示合成测试数据受到访问，但Notion仍在11月3日上午完成断连、数据删除和通信终止；当Fireworks在11月6日表示可能涉及客户数据后，Notion重新调查，并在11月9日通知受影响客户。(notion.com)

这种“先隔离、再确认范围”的策略比等待完整取证报告更可靠。供应链事件中，供应商给出的初始影响范围经常会随着日志分析扩大，Fireworks从最初只确认密钥暴露，到后来承认账单数据、数据集和不完整模型权重受到影响，就是一个典型例子。

Notion仍需要回答更深层的问题：为什么Insights分类所需的聊天数据会处于可被访问的状态、保存周期究竟多长，以及企业管理员是否能够在事件发生前关闭这条数据处理链路。

低于1%的工作区并不是一个足以淡化风险的数字。Notion拥有大量企业客户，即使比例较低，一旦受影响对象包含研发团队、律师事务所、咨询机构或金融企业，单个工作区中的信息价值也可能非常高。

企业现在应该做什么

企业需要把AI聊天记录视为正式业务数据，而不是员工与机器人之间的临时对话。

• 检查Notion通知： Notion表示已经联系已识别的受影响客户；没有收到通知的工作区目前无需执行事件专项操作，但仍应关注后续更新。
• 下载并审查受影响数据： 已收到通知的管理员应通过Notion提供的安全入口查看具体聊天内容，不要只依赖“无法归属”的描述。
• 立即轮换凭据： 只要员工曾在Notion AI中输入密码、访问令牌、云服务密钥或数据库连接信息，就应视为已暴露并完成更换。
• 核查访问日志： 凭据轮换只能阻止后续使用，不能判断攻击者此前是否已经访问数据或消耗资源。
• 限制敏感内容输入： 产品路线图、未公开财务数据、客户隐私和生产环境凭据，不应直接粘贴进通用AI聊天窗口。
• 重新审查AI供应商： 企业采购不应只审查用户直接使用的SaaS，还要追踪其模型提供商、推理平台、向量数据库和云服务商。
• 拆分AI权限边界： 评估、训练、推理和使用分析不应共享高权限服务账户，也不应让开发环境默认接触生产客户数据。

这次事件真正改变了什么

Fireworks事件证明，AI产品的安全边界已经从一个厂商扩展成一整条基础设施供应链。

用户看到的是Notion AI，数据实际可能经过Notion、Fireworks以及Fireworks使用的第三方云环境。任何一层遭入侵，都可能让最上层应用中的聊天内容暴露，而最上层厂商甚至需要等待下游供应商多轮调查，才能确定客户究竟受到什么影响。

“平台没有被黑”因此不再是充分的安全解释。对于企业用户而言，真正重要的问题是数据去过哪里、被谁处理、保存了多久，以及供应商的供应商是否也能接触这些数据。

Fireworks目前没有披露受影响客户总数、数据量、第三方云服务商名称，也没有说明攻击者具体运行了什么工作负载。只要这些关键问题仍然没有答案，这起事件就不能被视为已经结束。

这也是Fireworks必须面对的信任成本：AI基础设施公司的卖点是让客户不用自己管理复杂的模型和GPU系统，但客户交出去的不只是计算任务，还有数据、凭据和模型资产。底层平台如果无法证明研发环境、客户数据和外部供应商之间存在足够强的隔离，那么性能再快、模型再多，也很难获得企业长期信任。

参考来源

• iThome：Fireworks AI遭骇波及Notion，部分AI对话记录遭未授权存取——整理Notion受影响范围、事件时间线以及Fireworks披露的数据类别。