--- title: "開店平台被駭，品牌要扛什麼？91APP 事件後，電商老闆這週該做的五件事" description: "開店平台被駭時，品牌最該先做的是發防詐公告、向平台要書面的受影響範圍，並輪替所有串接金鑰。本文整理 91APP 事件已公開的時間線與外洩欄位、CYBERBIZ 商家通知的已知與未知，以及個資法下品牌與平台的責任分工，給在平台上開店的老闆一份這週就能照做的五步清單、平台追問表與防詐公告範本。" canonical: "https://yotron-ai.com/blog/ecommerce-platform-breach-brand-response-91app" published: "2026-11-02" last-updated: "2026-11-02" --- # 開店平台被駭，品牌要扛什麼？91APP 事件後，電商老闆這週該做的五件事 開店平台被駭時，品牌最該先做的是發防詐公告、向平台要書面的受影響範圍，並輪替所有串接金鑰。本文整理 91APP 事件已公開的時間線與外洩欄位、CYBERBIZ 商家通知的已知與未知，以及個資法下品牌與平台的責任分工，給在平台上開店的老闆一份這週就能照做的五步清單、平台追問表與防詐公告範本。 > 文／Laban（優創智能 AI 導入工程師） 開店平台資安事件，是指品牌用來架官網、收訂單的 SaaS 電商平台（例如 91APP、CYBERBIZ、SHOPLINE）遭入侵，導致品牌顧客的訂單資料外洩。結論先講：**平台被駭，資料卻是品牌蒐集的，詐騙信上寫的也是品牌名稱**。品牌不能等平台公告，這週就該做三件事：發防詐公告、向平台要書面的受影響範圍、輪替所有串接平台的 API 金鑰。 本文分成三部分：91APP 事件已公開的**事實**與 CYBERBIZ 傳聞的**已知與未知**、品牌與平台**責任怎麼分**的分析，以及在平台上開店的老闆可以照做的**五個步驟**。本文不是事件鑑識報告，也不構成法律意見；資料截至 2026 年 11 月 2 日。 --- ## 一、已知事實：91APP 事件時間線 ### 1. 從入侵到通報花了 13 天 | 日期 | 事件 | 來源 | | --- | --- | --- | | 2026-10-03 | Commerce Cloud 訂單資料庫遭自動化攻擊 | 遠見、91APP 調查報告 | | 2026-10-14 | 91APP 阻斷入侵 | 科技新報 | | 2026-10-16 | 91APP 發布重大訊息，品牌客戶此時才接到通知 | 遠見 | | 2026-10-20 | 數位發展部會同資安院與外部專家展開行政檢查 | iThome | | 2026-10-22 | 公布 18 天調查報告，說明入侵路徑 | iThome | | 2026-10-29 | 記者會公布 25 天調查報告與最大可能影響範圍 | 科技新報 | | 2026-11-02 起 | 取得品牌授權後，以 Email 與簡訊通知每位受影響消費者 | 科技新報 | 遠見雜誌的報導指出，入侵到品牌接獲通知之間，詐騙集團已經拿著真實訂單資料聯絡消費者，話術包括「定期購設定錯誤」「升級 VIP 批發會員」「訂單重複扣款」，再要求操作網銀。 ### 2. 入侵路徑：一個沒更新的內部工具 依 91APP 10 月 22 日的 18 天調查報告（iThome 報導），攻擊者先利用一套**未更新套件的第三方內部工具 Appsmith** 進入內網，再從 **GitLab 取得資料庫金鑰**，進而存取訂單資料庫。科技新報 10 月 29 日的報導補充，攻擊屬於 ARTEX 自動化攻擊，工具鏈與 2026 年 9 至 10 月韓國、日本的同一波攻擊相同。 91APP 資安長林大維在記者會上表示，過去調查以外部節點為主，這次事件源自內部系統，公司承認調查方式有誤。 ### 3. 影響範圍與補償 | 項目 | 內容（2026-10-29 公布） | | --- | --- | | 品牌數 | 最大可能 1,329 家 | | 消費者數 | 最大可能 4,798,255 名 | | 訂單期間 | 2025-04-04 至 2026-10-14 成立的所有訂單 | | 可能外洩欄位 | 姓名、電話、配送地址、電子郵件、訂單紀錄 | | 不包含 | 密碼、信用卡、任何支付資料 | | 補償 | 不論在哪個品牌購買、不論有無財產損失，都可向 91APP 申請，期限至 2027-02-01 | 補償條件有變過：10 月 22 日的報告寫的是「經確認因本次事件遭詐騙而**受有財產損失**」的消費者提供全面補償；10 月 29 日改為**不論有無財產損失**都可申請。品牌客服回覆顧客時，要用最新版本。 ### 4. CYBERBIZ：目前只有商家通知的轉述 2026 年 11 月 2 日，Threads 使用者 @lidien.fu 發文轉述 CYBERBIZ 商家後台的兩則通知：一則說 10 月 31 日晚間發現異常存取、部分訂單資料被讀取；另一則請商家提供固定 IP，準備接收新金鑰。 **我們沒有找到 CYBERBIZ 的公開聲明或媒體報導，無法證實這兩則通知的內容。** 截至同日，我們也沒有看到公開聲明或報導指出 SHOPLINE、meepShop 受到影響。在 CYBERBIZ 上開店的品牌，請以自己後台收到的通知與客服書面回覆為準。 值得注意的是「請商家提供固定 IP、準備接收新金鑰」這個動作本身：它代表平台打算**換掉商家用來串接的金鑰，並把新金鑰的使用限制在指定 IP**。不管事件規模多大，這都表示你的 ERP、物流、行銷工具接下來會有一次斷線與重新設定，最好現在就開始準備。 --- ## 二、編輯分析：為什麼是品牌在扛 ### 1. 法律上，平台是你委託的處理者 個人資料保護法第 4 條規定，受委託蒐集、處理或利用個資者，在本法適用範圍內視同委託機關。對顧客來說，他是在**你的品牌官網**下單、把資料交給**你**；平台是你委託處理資料的廠商。第 12 條則要求個資被竊取或洩漏時通知當事人（該條已於 114 年修正，修正條文施行日期由行政院另定）；第 29 條規定非公務機關違法致個資受侵害時負損害賠償責任，能證明無故意或過失者除外。 這不代表品牌一定要賠，實際責任怎麼分，要看你和平台簽的合約與主管機關的認定。但它代表一件事：**「這是平台的問題」不是一個能對顧客說出口的答案。** 91APP 這次主動承擔通知與補償費用，是平台的選擇，不是每家平台都會這樣做。 ### 2. 未上市櫃的平台，沒有義務告訴你 91APP 是上市公司，有發重大訊息的義務，所以外界看得到時間線。多數開店平台沒有上市櫃，沒有這個義務。你能知道多少，取決於**合約寫了什麼，以及你問了什麼**。這是為什麼步驟 2 要用書面追問。 ### 3. 金鑰外洩比資料外洩更急 91APP 的入侵鏈裡，關鍵一步是「從 GitLab 拿到資料庫金鑰」。資料外洩是已經發生的事；**金鑰外洩是還會繼續發生的事**。你的品牌在平台上開過的 API 金鑰、Webhook 密鑰、第三方 App 授權，如果放在平台或你自己的系統裡被一起讀走，攻擊者可以用它繼續讀新訂單。這也是 Threads 貼文裡那句「懂的人看到這裡，心裡大概有數了」的意思。同一時期 Zeabur 也遭入侵並宣布停運，我們在〈[Zeabur 停運與資安事件的企業教訓](/blog/zeabur-shutdown-security-incident-enterprise-lessons)〉整理過雲端服務出事時的盤點方式；設備端的同類問題，可參考 [Synology NAS 勒索攻擊的六個步驟](/blog/synology-nas-c3rb3r-ransomware-sme-response)。 --- ## 三、五個步驟：這週就能開始做 以下步驟適用於任何在 SaaS 開店平台上經營官網的品牌，不論你的平台目前有沒有傳出事件。 ### 步驟 1：今天發防詐公告 在官網首頁公告欄、LINE 官方帳號、會員 Email 與社群同步發布。公告不需要說明事件細節，只要說清楚品牌**不會做什麼**： > 【防詐騙提醒】近期有詐騙集團假冒電商客服，以「訂單重複扣款」「定期購設定錯誤」「升級會員」等理由聯繫消費者。本品牌不會以電話、LINE 或簡訊要求您操作網路銀行、ATM 或提供信用卡資料，也不會傳送附件或要求加入其他 LINE 帳號。如接到可疑來電，請直接掛斷並撥打 165 反詐騙專線，或透過官網客服與我們確認。 同時給客服一份統一話術：不臆測、不承認或否認個別顧客資料是否外洩，引導顧客撥 165，並記錄來電內容。 ### 步驟 2：用書面向平台問清楚六件事 用 Email 或工單寄出，要求書面回覆，不要只靠業務在電話裡說： | 要問的事 | 為什麼要問 | | --- | --- | | 我的商店在不在受影響範圍？ | 決定要不要主動通知顧客 | | 受影響的訂單期間與欄位？ | 決定公告與通知的內容 | | 我串接的 API 金鑰、Webhook 密鑰是否可能外洩？ | 決定步驟 3 的範圍 | | 平台會不會通知消費者？以誰的名義、何時、費用誰付？ | 避免重複通知或漏通知 | | 消費者補償與申訴窗口在哪？ | 客服可以直接轉介 | | 是否已依個資法通報主管機關？ | 確認你自己還要不要通報 | 收到的回覆存檔，連同寄出時間。這是之後釐清責任時最重要的紀錄。 ### 步驟 3：盤點並輪替所有串接金鑰 把所有連到開店平台的系統列成一張表，逐一換掉金鑰： | 類型 | 常見例子 | 動作 | | --- | --- | --- | | 平台 API 金鑰 | ERP、進銷存、POS 同步 | 在平台後台重新產生，舊的立即撤銷 | | Webhook 密鑰 | 訂單通知、出貨回寫 | 重新產生並更新接收端 | | 第三方 App 授權 | 物流、電子發票、評價、行銷自動化 | 移除不用的，保留的重新授權 | | 廣告與追蹤 | Meta、Google 轉換 API 權杖 | 檢查是否存在平台設定中，必要時輪替 | | 你自己系統裡的副本 | 程式碼、`.env`、共用試算表、Git 倉庫 | 找出所有寫死的金鑰，改放到密鑰管理 | 如果平台支援 IP 白名單，順便把**金鑰使用與後台登入限制在固定 IP**。家用網路與手機熱點多半是浮動 IP，設錯會把自己鎖在外面，先跟網路供應商確認公司有沒有固定 IP。 ### 步驟 4：收斂後台帳號與匯出權限 到平台後台的管理員清單，刪掉離職員工、前代操公司、外包工程師的帳號，所有管理員開啟兩步驟驗證。把「顧客匯出」「訂單匯出」權限收到最少人，並檢查近期的登入與匯出紀錄有沒有陌生 IP 或時段。 這一步跟這次事件無關，卻是我們在導入現場最常看到的缺口：**平台再安全，後台有五個沒人管的管理員帳號，就等於門沒關。** ### 步驟 5：留存紀錄，準備下一次 把這次的平台通知、你的公告、客服來電紀錄、金鑰輪替時間整理成一份文件。然後回頭檢查你和平台的合約：有沒有寫資安事件通知時限、通知內容、費用分擔與退出時的資料匯出。下次續約時，這幾條要補進去。 **驗收標準**：完成後應能回答三個問題——顧客打電話來問，客服能不能用同一套說法回答；所有串接平台的金鑰是不是都在這週換過；如果平台明天再出事，合約有沒有要求它在幾天內書面通知你。三題都能回答，才算補上這次事件暴露的缺口。 --- ## 四、結語：平台是你的供應商，不是你的資安部門 選開店平台時，大多數品牌比的是金流、模板與月費，很少問「出事時誰通知誰、多久通知」。這次事件讓答案變得很具體：**平台負責它的系統，品牌負責它的顧客；顧客不會區分這兩者**。 如果你的團隊想盤點電商後台的帳號、金鑰與串接系統，或想在導入 AI 客服與自動化之前先把權限整理乾淨，歡迎與優創智能聯繫，我們可以從一張「哪些系統連到平台、用哪把金鑰、誰負責」的清單開始。 --- *免責說明：本文依截至 2026 年 11 月 2 日的公開資料整理，事件仍在發展，受影響範圍以 91APP 官方與數位發展部後續公告為準。CYBERBIZ 相關內容僅為 Threads 貼文轉述，未經官方證實。本文不構成法律意見或資安鑑識意見。* --- **參考來源** - 科技新報，〈91APP 訂單資訊外洩！波及千家品牌、480 萬名消費者，承諾全面負責〉，2026-10-29：https://infosecu.technews.tw/2026/10/29/91app-security-incident-20261029/ - iThome，91APP 18 天調查報告報導，2026-10：https://www.ithome.com.tw/news/179923 - 遠見雜誌，〈91APP 詐騙信風暴始末》電商老闆：他們被駭，要我們去扛〉，2026-10（經遠見 Threads 帳號 @gvmonthly 轉載）：https://www.threads.com/@gvmonthly - 鉅亨網，〈91APP 遭駭客入侵訂單資料庫 受害消費者恐近 480 萬人〉：https://news.cnyes.com/news/id/6640777 - @lidien.fu（Threads），CYBERBIZ 商家通知轉述，2026-11-02：https://www.threads.com/@lidien.fu/post/DfOOD75k4MK - 全國法規資料庫，〈個人資料保護法〉：https://law.moj.gov.tw/LawClass/LawAll.aspx?pcode=I0050021 - CYBERBIZ DOCS，〈資安防護總覽與最佳實務〉：https://help.cyberbiz.io/ec/website-management/security-best-practices/ --- ## 相關推薦與延伸閱讀 - [Uber 一週只有 4 趟叫車來自 AI 代理：台灣企業該不該現在為代理下單開入口？](/blog/ai-agent-orders-uber-doordash-reality-check-taiwan)：AI 代理下單目前仍是極小眾，台灣企業應先縮短自家 LINE 與官網的下單步驟，再決定要不要為代理開專用入口。Uber 財報會議揭露，十月最忙一週約 3.2 億 - [AI Agent 的權限邊界怎麼設：企業導入前必須畫好的三條線](/blog/ai-agent-permission-boundary-sandbox)：企業導入 AI Agent 前，權限邊界比模型選型更該先決定。本文用 2026 年 OpenAI–Hugging Face 事件與 Google Gemini - [Claude Dispatch 被瀏覽器擴充功能接管（ThisBash）：AI 桌面代理的遠端控制與核准按鈕，企業該先關掉與盤點什麼](/blog/claude-dispatch-thisbash-browser-extension-agent-remote-control)：AI 桌面代理的遠端控制若能從網頁登入觸發，一個惡意擴充功能就能叫公司電腦執行指令。Forever Security 於 2026 年 11 月 4 日公布 T