2026年10月6日上午9时（太平洋时间），AI推理与模型定制平台Fireworks AI检测到一起安全事件：有未授权第三方使用了Fireworks内部凭证，访问了少数客户账户中用于评估作业的环境变量。公司当日开始遏制，10月9日轮换全部员工API密钥并发布安全公告，10月10日进一步撤销更多用户API密钥、轮换服务账户令牌，并聘请网络安全专业机构协助调查。
Fireworks在公告中确认，部分受影响账户存储为密钥的环境变量（包括API密钥和令牌）已被窃取。这类在评估作业中配置的第三方凭证，往往指向客户在其他云平台与模型服务商处的资源。Fireworks强调，其平台默认不存储提示词与输出（零数据保留，ZDR），调查暂未发现客户模型、数据集、训练数据、推理流量或个人信息被访问的证据，但对泄露凭证调用记录的核查仍在进行。
影响范围在11月9日再度扩大。根据Fireworks最新通报，受影响内部应用曾提供对资源元数据的访问（标识符、显示名称、创建时间等），账单信息（账单与收货地址、发票与付款记录、账户余额与信用额度）也涉及其中；支付卡号未存储、未受影响。对一小部分客户而言，密钥、数据集以及不完整的模型权重同样被访问。事件还出现了第二条入侵路径：10月23日，托管Fireworks研发机器的第三方云服务商发生安全事件；10月24日，攻击者借道进入Fireworks研发机并运行了未授权负载，导致了上述额外影响。Fireworks于当日检测并采取修复措施，表示截至10月25日未再检测到攻击者在客户所用平台上的进一步成功入侵。
公司已向执法机构报案，并聘请Palo Alto Networks旗下Unit 42开展取证分析。应对措施包括撤销与替换凭证及服务账户、移除多余高权限、封堵未授权网络路径、隔离受影响系统、收紧存储与分析系统访问、强化日志与监控。受调查影响，面向自助数据集上传下载（批式推理与数据集训练所用）的功能已暂停；训练SDK默认零数据留存、Lab训练运行在隔离环境，推理、训练SDK与Nexus暂未发现影响。Fireworks将攻击活动归因于以经济利益为目的的网络犯罪团伙，意图通过非法路由网关转卖未授权的模型访问权，即所谓“LLMJacking”。谷歌威胁情报团队与Mandiant 2026年11月2日的研究称，此类“LLM Mixer”非法网关代理、聚合并转售未授权模型访问；在Mandiant各独立调查中，单日欺诈性资源消耗费用超过10万美元、个别组织累计达100万美元。该数字描述的是更广泛的调查案例，并非Fireworks自身损失。
Fireworks并非孤例。安全厂商Wiz将2026年10月称为“黑色十月”（Black October）：当月至少9家AI开发者平台披露安全事件，包括Fireworks AI（10月6日）、Andromeda（10月9日）、Zeabur（10月14日）、Lightning AI（10月15日）、OpenCode（10月16日至17日）、Railway（10月20日）、Warp（10月23日）、CommandCode（10月28日）和Northflank（10月30日）。云安全联盟（CSA）在10月23日的研究简报中，也将Fireworks与OpenCode Console、Railway事件并列，指出其共享同一模式——攻击者瞄准开发平台为其用户保管的AI服务密钥，但未将各事件归因于同一攻击者。10月，Zeabur遭遇二次入侵后宣布关停，32.18万个账户、约320万条环境变量记录被读取；OpenCode一套停用中的旧系统被未授权访问，存储OpenAI、Anthropic、Google密钥的Console用户中1.4%受影响。这些事件中没有一起是攻击者破解了加密算法，“共同点是凭证长期有效、权限过宽，一直处在可被取用的状态”。Wiz还观测到两个企业案例：被盗AWS密钥被用于直接调用Amazon Bedrock，一个案例约30小时内发起80万次调用（约90%成功），另一个超过13小时发起170万次调用，两案按牌价估算消耗合计可能超过10万美元，流量特征符合转售编码智能体流量。
这起事件的核心不在密码学失守，而在凭证治理失守。评估作业并非自包含：为对模型打分，作业需要访问持有数据集的对象存储、向量数据库、内部API，甚至作为评审模型的第二家模型服务商，每一个都以密钥形式“粘贴”进平台。平台由此在无人刻意设计的情况下，变成客户面向其他系统的“凭证目录”；单一内部凭证的跨租户访问能力，则可能一次性解锁大量客户密钥。更关键的处置细节是：Fireworks明确提示客户，“仅删除平台中存储的密钥并不能使底层凭证失效”，第三方凭证必须回到签发方处轮换或吊销。也就是说，攻击者在暴露窗口内持有的是仍然有效的活体凭证，客户自查平台侧日志并不能排除第三方侧的未授权读取、下载或变更。
云安全的历史已经证明：云安全是云计算市场规模化的前提。同样，AI时代，AI基础设施业务的高速发展更要靠AI云安全技术的保障；不同的是，这一次攻防双线同时抬高——攻击侧瞄准凭证集中池“一次入侵、批量兑现”，防御侧则必须把凭证治理前置为平台的结构性能力。从攻击面看，本轮事件的攻击路径全部围绕身份与凭证展开：失窃的内部凭证（其初始获取方式官方尚未披露）、跨租户的评估作业环境变量、攻击者在平台上自行创建的持久化API密钥、乃至经由第三方云服务商研发机的二次跳板。攻击者无需破解任何加密算法，“合法凭证+过宽权限”即构成完整入侵链。从防御面看，Fireworks的响应：当日遏制、次日通知、轮换员工密钥与服务账户令牌、撤销攻击者自建密钥、聘请外部取证、收紧评估作业的密钥供给机制——符合成熟的事件响应范式，但两次披露范围扩大也说明，影响边界的确认往往滞后于入侵本身，“未检测到证据”与“不存在影响”是两个必须分开表述的命题。
对行业而言，三点判断值得记录。其一，AI开发者平台正在成为继SaaS、云服务商之后新的凭证集中层，其安全水位直接决定下游客户在多家模型与云服务商处的暴露面，AI基础设施正成为网络攻防的“最前线”；其二，凭证治理的价值在AI基础设施语境下被进一步放大，最小权限、短时效、集中密钥管理与常态配置审计，正在取代传统的边界防护成为第一道防线，谷歌威胁情报团队与Mandiant的研究亦将云端身份令牌失窃列为相关案例的主要初始入侵向量，并建议实施集中密钥管理、最小权限访问、例行配置审计、支出控制与异常低量请求监控；其三，对投融资尽调而言，AI基础设施厂商的凭证管理机制与安全事件史正在成为常规风险项，“评估/微调作业如何隔离secrets、内部凭证的权限边界如何收敛”应成为标准问询项。
对使用此类平台的团队，行动清单并不复杂但必须执行到位：收到受影响通知的客户，应按官方指引重建Fireworks API密钥，并将通知中列明的第三方凭证逐一回到签发方轮换，同步核查相关调用日志；未收到通知的账户暂无需事件专属操作，但应检查平台内是否存在无法识别的密钥、用户、评估作业、训练任务与数据集。更重要的是制度性动作：凡向托管平台提交过第三方密钥的团队，都应假定平台侧泄露事件发生时这些密钥即已暴露，将“定期轮换+最小权限+签发方侧监控”作为默认纪律，而不是把安全押注在平台的零事件记录上。
Fireworks事件仍在调查中，两次披露之间的信息增量提醒市场：AI基础设施的安全评估不是一次性命题。平台方需要把凭证治理从“被动的”事件响应向“主动的”架构设计演进，客户方则需要把密钥托管视为持续风险敞口。AI基础设施的安全能力，正在从竞争力项变为准入项。“黑色十月”已经给出了足够清晰的注脚。
