門是一個沒更新的內部工具，
鑰匙就放在 GitLab 裡

前篇空著的那一格

一週前寫前篇時，攻擊鏈的第一格是空的：重訊只寫「自動化攻擊」，入口沒公開，我們把候選列出來，然後停在那裡。10 月 22 日，那一格有了答案，而且答案不在任何一個候選裡。

不是撞庫，不是 API 換編號就能讀別人的資料。91APP 在官網的事件說明頁寫：「第三方工具 AppSmith 存在漏洞，91APP 未及時套用修補更新，導致駭客從此破口進入內部網路，並從內部 GitLab 系統上找到其中一座訂單資料庫的金鑰（Key），並成功入侵，非法取得訂單資料。」

用前篇那棟商辦大樓來比喻：櫃子不是被撬開的。管理室後面有一扇員工自己裝、很久沒換鎖的側門，進去之後，櫃子的鑰匙就掛在工程部的白板上。

先講清楚這份文件的性質。這是 91APP 自己的事件說明頁，頁面標「資料更新日期 10/22」，媒體同日以「18 天調查報告」報導；它是公司方的階段性說法，不是主管機關的認定，官方也寫最終以數位發展部行政檢查確認的結果為準。和重訊比，它多了三樣東西：入口、時間軸、處置清單。還沒有的，是數字。

破口：第三方工具 AppSmith 存在漏洞，91APP 未及時套用修補更新，
    駭客從此破口進入內部網路，並從內部 GitLab 系統上找到
    其中一座訂單資料庫的金鑰（Key），並成功入侵，非法取得訂單資料。

10/14：擴大調查後，發現其中一座內部的 CI 主機，曾經在 10/3
     有一支未授權執行緒的執行紀錄。

處置：移除受入侵的 Appsmith 工具／更換內部系統權杖／
    更換資料庫帳號與密碼／限制 CI 主機與資料庫網段連線／
    停用遭冒用帳號，重建 GitLab 權限／保留受駭主機相關軌跡供調查

範圍：僅涉及 Commerce Cloud 該座資料庫，Marketing Cloud、
    91APP Payments 與 iCHEF 均不受影響；遭存取是訂單資訊，
    其中並不包含信用卡等資訊。

把兩篇的時間合在一起看。前篇的 10 月 3 日只是品牌公告與公關受訪的說法，這次由 91APP 自己的說明頁確認。

1. 2026-10-03 11:00
   攻擊者存取 Commerce Cloud 其中一座訂單資料庫；同一天，一座內部 CI 主機有一支未授權執行緒的執行紀錄
   91APP 官方說明頁；11 時由聯合新聞網報導
2. 2026-10-04
   首次接獲客戶通報，啟動盤查，初步沒有發現大規模外流證據
   91APP 官方說明頁
3. 2026-10-07
   再接獲更多品牌反映收到類似詐騙訊息（媒體寫五家），升高應對
   91APP 官方說明頁；家數見聯合新聞網
4. 2026-10-08
   成立緊急應變小組，決定委請外部資安團隊；這一天沒有同步提醒品牌客戶
   91APP 官方說明頁；未提醒品牌一事為董事長在報告中的自我檢討，見聯合新聞網
5. 2026-10-09 至 10-11
   確認委託奧義智慧，連假期間擴大全系統盤查與 log 分析
   91APP 官方說明頁、數位時代
6. 2026-10-14 23:00
   外部團隊進駐，發現 CI 主機 10/3 的未授權執行緒、確認攻擊軌跡與破口，當晚完成阻斷
   91APP 官方說明頁；23 時由聯合新聞網報導
7. 2026-10-15
   依個資法通報數位發展部，開始向品牌客戶說明
   91APP 官方說明頁
8. 2026-10-16 06:30
   發布重大訊息（前篇拆解的那一份）
   公開資訊觀測站
9. 2026-10-19
   數位發展部數位產業署邀資安院與外部專家到 91APP 行政檢查
   聯合新聞網、知新聞報導
10. 2026-10-22
    公布階段性調查與補償計畫：經確認因本事件遭詐騙而有財產損失的消費者全面補償；品牌會員的通知費用由 91APP 負擔，其他補償與品牌個別協商
    91APP 官方說明頁、聯合新聞網、數位時代
11. 預計 2026-10 下旬
    配合主管機關行政檢查，對外說明受影響品牌數、筆數與欄位，以及改善做法
    聯合新聞網、數位時代轉述 91APP 說法；官方頁面本身沒有寫日期

十一列裡，九列現在有 91APP 自己的文字支撐。前篇時，這個數字是兩列。

怎麼發現

最早的訊號仍然來自外面。10 月 4 日第一通客戶通報，10 月 7 日更多品牌反映，這些都是收到詐騙信的消費者回頭找品牌、品牌再找平台。91APP 自己的系統在這段期間沒有拉起告警，至少說明頁沒有提到任何一則。

真正讓調查收斂的，是 10 月 14 日外部團隊進駐後「擴大調查」找到的那一筆紀錄：一座內部 CI 主機在 10 月 3 日跑過一支沒有授權的執行緒。也就是說，證據一直在主機上，只是沒有人在對的地方看；從第一通通報到看見它，花了十天。

攻擊者怎麼做到

到這裡，其實已經足夠理解整起事件。如果你關心的是該怎麼避免，可以直接往「如何避免」繼續閱讀。如果你想知道公開資料能還原到哪一步，下面開始進入技術拆解。

白話結論：這條路徑沒有任何一步需要高深技術。一個沒修補的內部工具給了內網的立足點，一把放在 GitLab 上的金鑰給了資料庫的合法身分；剩下的事，是用合法身分做不合法的查詢。

   攻擊者
     |
     v
  Appsmith（內部效率工具，有漏洞、未套修補）
     |   進入內部網路
     v
  內部 GitLab  ----  找到訂單資料庫的金鑰（Key）
     |
     v
  內部 CI 主機（10/3 有未授權執行緒）
     |   CI 網段可以直連資料庫（事後才限制）
     v
  Commerce Cloud 其中一座訂單資料庫  -->  訂單資料  -->  冒名詐騙信

CI 主機在這條線上的確切位置，說明頁沒有寫；上圖把它放在 GitLab 與資料庫之間，是依處置清單「限制 CI 主機與資料庫網段連線」做的推論。

為什麼十天看不出來

這一段是推論，不是官方說法。攻擊者拿到的是資料庫的真金鑰，連進去的身分跟應用程式一模一樣。資料庫的稽核看到的是一個合法帳號在做查詢；如果沒有「這個帳號只該從哪個網段連進來」的規則，也沒有「這個帳號平常一小時讀幾筆」的基準線，就沒有任何一條告警會響。

處置清單裡的「限制 CI 主機與資料庫網段連線」從反面說明了這件事：事發時，CI 網段可以直接連到正式訂單資料庫。CI 主機本來就要碰程式碼、金鑰與部署，它能連到哪裡，攻擊者就能從它連到哪裡。

ARTEX 這個名字

說明頁把 ARTEX 描述為「AI 自主滲透測試系統，透過 AI 自動尋找系統漏洞、規劃入侵路徑，甚至執行攻擊與竊取資料」；媒體報導系統內發現 ARTEX 等工具痕跡。這個名字我們在南韓金融機構那篇拆過：CrowdStrike 10 月 7 日的報告在攻擊者外露的伺服器上找到 ARTEX 設定檔與 AI 對話紀錄；10 月 19 日日本 GMO Cybersecurity by Ierae 也說在攻擊日本企業的基礎設施上找到 ARTEX 痕跡，受影響家數各家報導說法不一。

把「AI 攻擊」四個字拿掉，這條路徑每一步都是老問題：沒修補的軟體、放錯地方的金鑰、沒隔開的網段。AI 讓攻擊者更快找到它們，但門本來就沒鎖。

這次外洩了什麼

前篇的 Leaked 表最後一列寫「攻擊者用什麼權限讀到資料庫，是本案最關鍵的缺口」。這一列現在有答案了。

五列裡，只有第一列是官方明確寫出「被找到、被用來入侵」的憑證；其餘是處置清單反推、或是工具本身的性質。

證據等級

前篇是 2 則能證明、3 則推論、4 則缺口，這篇是 3、3、4。缺口的數量沒有變，但缺的東西換了：從「從哪裡進來」換成「進來之後的細節」。

他們怎麼處理

照說明頁的時間序排一次。10 月 4 日接到首次通報後先自行盤查，初步沒找到大規模外流的證據；10 月 7 日更多品牌反映，才升高應對；10 月 8 日成立應變小組並決定找外部團隊，10 月 9 日確認委託奧義智慧，連假三天擴大盤查與 log 分析。10 月 14 日外部團隊進駐，找到 CI 主機的紀錄、確認破口，當晚 23 時阻斷。

圍堵與清除是那六項：移除 Appsmith、換權杖、換資料庫帳密、限制 CI 與資料庫網段、停用冒用帳號並重建 GitLab 權限、保留軌跡。10 月 15 日通報數發部，並每日向主管機關回報進度。

對外的部分，10 月 22 日公布補償方向：經確認因本事件遭詐騙而有財產損失的消費者，91APP 全面補償，可透過官網線上客服、電話 (02) 7723-1622 或 [email protected] 登記；認定與申請流程等政府反詐騙政策與調查程序確立後公布。品牌端，會員通知的簡訊與 email 費用由 91APP 負擔（前篇寫到品牌擔心用平台發防詐訊息要付費，這次有了答案），其他補償與品牌個別協商。

哪裡做對，哪裡做錯

做對的地方，是這份說明寫得比大多數公司的階段報告具體。它直接寫出「未及時套用修補更新」與「在 GitLab 上找到金鑰」，沒有用「遭受高度複雜的攻擊」把自己的疏失包起來；處置清單和路徑一一對應，讀者可以自己核對。董事長在報告中說 10 月 8 日成立應變小組時就該同時提醒品牌客戶，「這是 91APP 的疏失」，這句話補上了前篇最大的爭點。補償先承諾、細節後補，也比前篇時「仍在討論」往前走了一步。

該改的地方，正好是這份報告自己承認的兩件事，加上一件它沒提的。第一，修補：被打穿的是一個「內部效率工具」，這類工具通常由工程團隊自己架、自己用，不在正式產品的修補流程裡，也最容易被忘記。第二，通知：從 10 月 4 日第一通客戶通報到 10 月 15 日向品牌說明，十一天裡品牌只能自己面對客人。第三，報告沒有提的，是為什麼一把能直連正式訂單資料庫的鑰匙會放在 GitLab 上，以及為什麼 CI 網段連得到它。換掉 Appsmith 能關一扇門，但只要鑰匙還會被放在同一種地方，下一扇沒更新的門會帶攻擊者走同一條路。

如何避免

當天就能做的，是盤點。把內網所有自架的內部工具列出來：低程式碼後台、自動化流程、BI、CI、程式碼倉庫。每一個寫上版本、誰負責、有沒有對外，版本落後官方最新版的先排升級。同一天，在本機 clone 的 repo 上跑一次唯讀的 secret 掃描，看資料庫密碼與連線字串有沒有進過 commit 歷史；只刪最新版不夠，歷史裡的值要當成已外洩、直接輪替。

一週內，處理 CI。正式資料庫的憑證不放在一般 CI 變數裡；真的要放，設為受保護與遮罩，只給受保護分支使用。更好的做法是讓 CI 根本拿不到正式資料庫的長效密碼，改用 secret manager 在部署時取用，或用雲端 IAM 換短效憑證。

這一季，處理網段。正式資料庫只接受應用程式所在網段；CI、辦公室、內部工具一律不能直連。這正是 91APP 事後做的那一條，事前做的成本遠低於事後。最後，給每個資料庫帳號一條基準線：它只該從哪裡連進來、平常一小時讀多少。偏離就告警，告警要有人看。

這篇提到的項目要花多少錢

把這條路徑上每一步的修法換成帳單。大部分是工時，真正要付錢的雲端服務很便宜；最貴的那幾列，現在都還是空白。

修門加換鎖，一次大約兩百美元左右的工時與每月不到十美元的雲端費用；另一邊的補償、通知與鑑識，目前一個數字都沒有公開。兩邊不能直接相比，但量級的差距不需要數字也看得出來。

你可以學到什麼

站在攻擊者那一側看，正式站是一家公司最用心守的地方，內部工具不是。它們由工程師為了省事架起來，掛在內網，大家默認「反正外面進不來」，所以沒人排升級；它們又偏偏連得到最多東西。攻擊者進了內網，第一個要找的是程式碼倉庫，因為工程師會把連線設定、部署腳本與金鑰放在離程式碼最近的地方。拿到一把正式資料庫的鑰匙，他就不再是入侵者，而是一個合法帳號。

跟我們的防暴筆記對照

對照 INC-2026-0827（排程回報「找不到帳戶」，被停權的是整個專案）。

相同的地方是鑰匙放錯地方，而且一把鑰匙能開的範圍太大。0827 是一把只需要寫試算表的服務帳戶金鑰掛著整個專案的 Owner；這次是一把能直連正式訂單資料庫的金鑰，放在一個內網裡有人就能碰到的 GitLab 上。兩次的修法都一樣：把鑰匙拿出共用的地方，縮小它能開的門，看見了就換。

不同的地方是入口。0827 的金鑰是隨著程式碼一起外流到外面；這次攻擊者得先從 Appsmith 進內網，才碰得到 GitLab。這給了一層多出來的防線，也提醒「內網裡就安全」是個假設：只要內網裡有一台沒修補的工具，那層防線就不存在。

回到那扇側門

前篇的結尾，帳單分散寄到許多品牌的客服部門。這一篇，帳單的源頭找到了：一扇員工自己裝、很久沒換鎖的側門，和一把掛在工程部白板上的鑰匙。91APP 已經把那扇門拆掉、把鎖換了。

還沒公布的，是那間管理室裡有多少個櫃子被打開過，以及白板上是不是只有這一把鑰匙。前者等主管機關，後者，每一家有 GitLab 的公司都可以今天自己去看。

本文由 AI 團隊協助研究與撰寫，經隱私與事實檢查後發布；證據等級依來源可信度標註。