Notion AI 的部分對話紀錄在 Fireworks AI 一宗第三方供應鏈保安事故中遭未授權存取。事件並非攻擊者直接入侵 Notion 自家系統：Fireworks 的雲端供應商先出現保安事故，攻擊者再進入 Fireworks 的開發機器，執行未授權工作負載，令客戶資料受影響。48

Notion 表示，少於 1% 的工作區涉及這批用於 Insights 功能的對話紀錄；而在受影響工作區中，絕大部分紀錄無法辨認來自哪位用戶或哪個工作區。34

入侵路徑：由雲端供應商波及 Fireworks 開發環境

Fireworks 表示，託管其研究及開發（R&D）機器的第三方雲端供應商於 2026 年 10 月 23 日發生保安事故。翌日，未獲授權人士利用這條途徑進入 Fireworks 開發機器並執行工作負載；Fireworks 稱當日已偵測到相關活動。414

目前公開資料交代了攻擊由供應商及開發環境延伸的路徑，但未有確認具體利用了哪種技術漏洞，也未交代攻擊者如何逐步接觸到每一類資料。可以確定的是，供應商開發環境遭入侵，進一步造成客戶資料受影響。14

哪些資料受影響？

Fireworks 擴大披露的資料類別包括資源中繼資料、帳單及付款紀錄；部分客戶的資料集、不完整模型權重亦受影響。Fireworks 表示，公司並不儲存付款卡號。4934

至於 Notion，涉事內容是用於 Insights 分類工作的 Notion AI 聊天紀錄。Insights 是協助客戶了解 AI 使用情況的功能。Notion 指少於 1% 工作區受影響，且絕大部分涉事紀錄無法對應到特定用戶或工作區。34

Notion 如何處理事件：11 月 2 日至 11 日

• 11 月 2 日： Fireworks 通知 Notion，有一小批資料被存取。Notion 初步檢視後認為資料是合成測試資料，當時未發現客戶對話紀錄。8
• 11 月 3 日： Notion 切斷與 Fireworks 的連接，並刪除存放在供應商系統內的資料。5
• 11 月 6 日： Fireworks 通知 Notion，攻擊者亦可能存取了客戶資料。5
• 11 月 8 日： Fireworks 確認涉事資料集包括用於 Insights 的 Notion AI 聊天紀錄。8
• 11 月 9 日： Notion 開始聯絡受影響客戶。15
• 11 月 11 日： Notion 撤銷在受影響用戶訊息中發現的 Notion API 金鑰。8

報道亦指出，Notion 暫停了 Insights，並停止透過 Fireworks 提供開放權重模型服務。1011 受影響客戶獲建議，將輸入過助理的密碼、API 金鑰及其他憑證視為可能已外洩，並盡快更換。21

調查與攻擊者動機：目前仍屬 Fireworks 的判斷

Fireworks 聘請 Palo Alto Networks 旗下 Unit 42 協助調查，並通知執法部門及限制部分受影響功能。34 Fireworks 認為，攻擊者可能打算透過非法路由閘道轉售未經授權的模型使用權；這類行為稱為「LLMJacking」。這是 Fireworks 對動機的評估，並不等於已確認攻擊者的身分。7

這次雲端供應商入侵，是 Fireworks 在 10 月披露的第二宗保安事故，並非早前 10 月 6 日識別的事件本身。兩宗事件的入侵途徑不同：本文所述事件始於第三方雲端供應商於 10 月 23 日發生事故，並於 10 月 24 日波及 Fireworks 開發機器。47

AI 供應鏈風險，不止看服務本身

這宗事件提醒企業，使用 AI 服務時，資料可能會經由外判供應商處理；因此，供應商的基建及開發環境也會構成整體保安風險的一部分。今次披露所述的入侵點在 Fireworks 的雲端供應商，受影響的對話則來自 Notion 的一項功能。48

評估 AI 服務時，除了了解模型如何運作，也值得問清楚供應商或次級處理商會保留哪些資料、資料在哪裏處理，以及出事時能否迅速切斷存取。日常使用方面，盡量不要把密碼或 API 金鑰貼進提示；若懷疑憑證曾出現在涉事對話中，應撤銷或更換。企業亦可按實際需要限制資料集、憑證及開發系統的存取權限。

Notion AI 的部分對話紀錄在 Fireworks AI 一宗第三方供應鏈保安事故中遭未授權存取。事件並非攻擊者直接入侵 Notion 自家系統：Fireworks 的雲端供應商先出現保安事故，攻擊者再進入 Fireworks 的開發機器，執行未授權工作負載，令客戶資料受影響。48

Notion 表示，少於 1% 的工作區涉及這批用於 Insights 功能的對話紀錄；而在受影響工作區中，絕大部分紀錄無法辨認來自哪位用戶或哪個工作區。34

入侵路徑：由雲端供應商波及 Fireworks 開發環境

Fireworks 表示，託管其研究及開發（R&D）機器的第三方雲端供應商於 2026 年 10 月 23 日發生保安事故。翌日，未獲授權人士利用這條途徑進入 Fireworks 開發機器並執行工作負載；Fireworks 稱當日已偵測到相關活動。414

目前公開資料交代了攻擊由供應商及開發環境延伸的路徑，但未有確認具體利用了哪種技術漏洞，也未交代攻擊者如何逐步接觸到每一類資料。可以確定的是，供應商開發環境遭入侵，進一步造成客戶資料受影響。14

哪些資料受影響？

Fireworks 擴大披露的資料類別包括資源中繼資料、帳單及付款紀錄；部分客戶的資料集、不完整模型權重亦受影響。Fireworks 表示，公司並不儲存付款卡號。4934

至於 Notion，涉事內容是用於 Insights 分類工作的 Notion AI 聊天紀錄。Insights 是協助客戶了解 AI 使用情況的功能。Notion 指少於 1% 工作區受影響，且絕大部分涉事紀錄無法對應到特定用戶或工作區。34

Notion 如何處理事件：11 月 2 日至 11 日

• 11 月 2 日： Fireworks 通知 Notion，有一小批資料被存取。Notion 初步檢視後認為資料是合成測試資料，當時未發現客戶對話紀錄。8
• 11 月 3 日： Notion 切斷與 Fireworks 的連接，並刪除存放在供應商系統內的資料。5
• 11 月 6 日： Fireworks 通知 Notion，攻擊者亦可能存取了客戶資料。5
• 11 月 8 日： Fireworks 確認涉事資料集包括用於 Insights 的 Notion AI 聊天紀錄。8
• 11 月 9 日： Notion 開始聯絡受影響客戶。15
• 11 月 11 日： Notion 撤銷在受影響用戶訊息中發現的 Notion API 金鑰。8

報道亦指出，Notion 暫停了 Insights，並停止透過 Fireworks 提供開放權重模型服務。1011 受影響客戶獲建議，將輸入過助理的密碼、API 金鑰及其他憑證視為可能已外洩，並盡快更換。21

調查與攻擊者動機：目前仍屬 Fireworks 的判斷

Fireworks 聘請 Palo Alto Networks 旗下 Unit 42 協助調查，並通知執法部門及限制部分受影響功能。34 Fireworks 認為，攻擊者可能打算透過非法路由閘道轉售未經授權的模型使用權；這類行為稱為「LLMJacking」。這是 Fireworks 對動機的評估，並不等於已確認攻擊者的身分。7

這次雲端供應商入侵，是 Fireworks 在 10 月披露的第二宗保安事故，並非早前 10 月 6 日識別的事件本身。兩宗事件的入侵途徑不同：本文所述事件始於第三方雲端供應商於 10 月 23 日發生事故，並於 10 月 24 日波及 Fireworks 開發機器。47

AI 供應鏈風險，不止看服務本身

這宗事件提醒企業，使用 AI 服務時，資料可能會經由外判供應商處理；因此，供應商的基建及開發環境也會構成整體保安風險的一部分。今次披露所述的入侵點在 Fireworks 的雲端供應商，受影響的對話則來自 Notion 的一項功能。48

評估 AI 服務時，除了了解模型如何運作，也值得問清楚供應商或次級處理商會保留哪些資料、資料在哪裏處理，以及出事時能否迅速切斷存取。日常使用方面，盡量不要把密碼或 API 金鑰貼進提示；若懷疑憑證曾出現在涉事對話中，應撤銷或更換。企業亦可按實際需要限制資料集、憑證及開發系統的存取權限。