10 月 24 日，一个拿到了第三方云服务商权限的攻击者，顺着这条路摸进了 Fireworks 的研发机器，在里面跑了一段未授权负载。11 月 9 日，Fireworks 更新安全公告：部分客户的不完整模型权重和数据集被访问了。
这句话之所以扎人，是因为一个多月前——10 月 9 日——同一家公司发的第一份公告里写得很清楚：没有发现客户模型、数据集、训练数据被访问的证据。
一个月后自己推翻自己，这是本次事件里最值得看的一段。
发生了什么：一起供应链入侵，接在旧伤上
先把时间线拉直。涉事公司是 Fireworks AI，CEO 是 Lin Qiao，做的是模型托管和微调（fine-tuning，也就是企业拿自己的私有数据把模型再训一遍）：企业把私有数据拿过来，在上面训练专属模型再部署。据 RuntimeWire 报道，约 1 万家企业客户在用它。
- 10 月 6 日：Fireworks 发现内部凭据被未授权使用，当天开始处置。这是一起独立事件。
- 10 月 9 日：发首份公告。受影响的是「有限数量客户账户」里评测任务用到的环境变量（存着 API key、token 这类机密），并明确写了「未发现客户模型、数据集、训练数据、推理流量被访问」。
- 10 月 23 日：托管 Fireworks 研发机器的第三方云服务商出事。
- 10 月 24 日：攻击者借这个入口到达 Fireworks 开发机器，跑了未授权负载，造成新的客户数据影响。Fireworks 称当天就检测到并开始处置。
- 11 月 9 日：更新公告，补上新发现的影响——账户与账单信息、部分客户的机密信息、数据集，以及不完整的模型权重。
也就是说，这是两次。第一次是自家凭据被偷，第二次是从上游供应商绕进来。Fireworks 在公告里的措辞是「数周内第二次已知的安全入侵」。
数字与一手细节：到底被摸走了什么
官方更新公告列得很克制，但逐条看并不轻松。
资源元数据：资源 ID、显示名称、描述、创建时间等。
账单信息：账单与收货地址、发票与付款记录、账户余额、额度消耗。支付卡号 Fireworks 不存储，因此不受影响——这是整段里唯一让人松口气的一句。
以及那句最要紧的：对「有限的一批账户」，机密信息、数据集、不完整的模型权重被访问。
这里的「不完整模型权重」需要解释一下。模型权重是模型训练完之后留下的那个大文件，是它全部能力的物理载体。所谓「不完整」，是说被拿到的是训练过程中的中间产物或片段，不是能直接跑起来的成品。但这仍然意味着：企业投喂给它的数据，以及用这些数据炼出来的东西，落到了外人手里。
另外两组数字来自攻击动机那一侧。Fireworks 判断攻击者与一个财务动机的网络犯罪团伙有关，目的是把窃取到的模型访问权转卖——业内叫 LLMJacking，即大模型劫持：偷走别人的云端密钥，用别人的账户额度跑自己的生意。Google 威胁情报组与 Mandiant 在 11 月 2 日发的报告给了量级：单起事件中，一天内的欺诈性资源消耗账单可以超过 10 万美元，累计有的组织在被掐断之前冲到过 100 万美元。注意这里的单位是账单金额，不是数据量。
报告里有个案例对比很说明问题：某团伙 8 小时内执行 50 万次 API 调用，把近 100 万美元的 token（模型计价的字数单位）成本转嫁给受害企业；而它对外卖的服务，包月大约 60 美元。正常市场价这个档位在 100 到 250 美元之间。差价从哪来，不言自明。
反转与对立：卖「私有数据」的生意，被摸到了数据
第一层反转在公告本身：10 月 9 日说模型和数据集没被碰，11 月 9 日说被碰了。这不是文字游戏，是调查范围扩大的结果——官方在更新里明确写「调查仍在进行，可能发现更多信息」。
第二层反转在商业模式上。Fireworks 卖的核心价值是：你的私有数据放在我这里，训练出你自己的专属模型。它卖的不是算力本身，是「数据交给我你放心」。这次被访问的恰好是数据集和不完整权重，正落在这个承诺的中心。
第三层是攻击路径的方向感。第一次是内部凭据泄露，说明自家门锁有问题；第二次是第三方云服务商被攻破后横向进来，说明门锁修好了，墙还是别人的。企业能管住自己的代码和密钥，管不住供应商自己的安全水平。这几乎是所有上云团队共同的处境。
也有值得给 Fireworks 记一笔的地方。它请了 Palo Alto Networks 的 Unit 42 做取证，处置动作列得很具体：吊销并替换凭据与服务账号、收回多余的高权限、限制未授权网络通路并隔离受影响系统、收紧数据存储与分析系统的访问、加固日志与监控。同时主动停掉了自助式的数据集上传与下载（Batch Inference 和基于数据集的训练都受影响），并声明推理服务（模型对外应答的那部分）、Training SDK、Nexus 三条默认零数据留存的产品线未受影响。
停掉一个能收钱的功能去查事故，这个取舍不好做，但做对了。
对读者意味着什么
如果你自己或所在团队用托管平台跑私有数据微调，这件事至少有三层提醒。
第一，托管平台的「隔离」是合同条款，不是物理事实。数据集和权重在对方机房里，你只能依赖对方的分区、权限和审计。一旦对方的上游出事，你的数据是否可及，取决于对方设计时的假设，不取决于你的意愿。
第二，出事之后的披露节奏，比出事本身更值得观察。第一次公告说没碰数据集，第二次改口说碰了。这在安全事件里很常见，初期调查天然不全。但对使用方来说，含义是：首份公告不要当最终结论，尤其涉及「哪些数据没被访问」这种否定性陈述时，要留出复查窗口。
第三，黑产的目标正在从「偷数据卖」转向「偷钥匙卖」。LLMJacking 的生意结构是：拿到云端身份凭据，开通或启用大模型服务，用你的账户跑别人的生意，账单记在你头上。这解释了为什么一次入侵能同时造成两类损失——数据外泄和天价账单。
我该做什么：一份能今天就动手的清单
不用恐慌，但要动手。按紧急程度排：
一，如果你有账号在 Fireworks，先查邮件。受影响客户会收到直接通知，里面点名需要轮换的具体凭据。注意官方那句提醒：把存着的密钥删掉不等于它失效，必须去签发方那里吊销。第三方凭据要去原始服务商那里办。
二，把「预算告警」当安全配置，不是财务配置。报告里那些 10 万美元一天的账单，几乎都是因为额度没有上限、也没人盯。给模型接口（API，程序调用模型的那条通道）设一个按天的硬上限，比事后查日志便宜得多。
三，盯住「验证型小请求」。攻击者拿到 key 之后，常用只花一个 token 的极小请求来试探有效性，这样不会触发流量异常告警。如果你的访问日志里出现大量极短请求的规律性扫描，那可能不是压测。
四，盘点你的上游。这次不是 Fireworks 自己被打穿，是它的云服务商被打穿。你的关键数据流经几家公司？每一家的安全承诺你还记得吗？答不上来，就是风险敞口。
五，涉及模型权重的项目，做一次暴露评估。哪怕只是「不完整」权重，也要按泄露处理——它可能包含训练数据的统计特征，甚至能被反推出部分样本。
最后一句判断：这不会是最后一起。当模型托管变成基础设施，它就成了和云厂商、代码托管平台同等级的攻击目标，而它的安全成熟度还普遍停在创业公司水平。选平台时，除了看价格和响应速度，也把「出事之后它怎么说话」放进评估项——这次 Fireworks 的处置算合格，但公告里那句自我推翻，本身就已经是代价。
—
参考来源
关注 AI 商业快讯，每天一篇 AI 热点深度解读。
相关阅读
