門沒換，
只是敲門的
變多了

第 1 章 · 事實資料 · FACTUAL INFORMATION

1.191APP：被打的是什麼

91APP 是替品牌架官網與 App 的電商 SaaS，品牌的訂單與會員資料放在 91APP 的系統裡。被非法存取的是 Commerce Cloud 裡一座「短期訂單資料庫」，存放 18 個月內的交易資料，其中部分資料遭竊。官方說法 數產署 10/19 行政檢查後也確認部分資料確實遭未經授權擷取，但沒有公布筆數。已證實

可能外洩的欄位：姓名、電話、配送地址（超商取貨者沒有地址）、電子郵件與訂單紀錄。不含密碼、信用卡與任何支付資料。Marketing Cloud、91APP Payments、iCHEF 不受影響。官方說法

因為無法判定實際被拿走哪些訂單，91APP 用最大可能範圍認定：2025-04-04 到 2026-10-14 成立的線上訂單，共 1,329 家品牌、4,798,255 名消費者。這個數字是上限。官方說法 品牌端自己估的數字陸續出現，例如台灣無印良品初估約 18 萬名會員。已證實

1.291APP：時間軸

1.391APP：攻擊鏈

兩份報告與記者會給的鏈是一致的。官方說法

1. 未修補的 AppsmithAppsmith 是開源的低程式碼工具，用來拼內部後台與儀表板。91APP 稱它為「內部效率工具」，有已知漏洞但沒套更新。
2. 進入內部網路從 Appsmith 這台機器取得內網的立足點。
3. 在 GitLab 找到訂單資料庫的金鑰原文是「從內部 GitLab 系統上找到其中一座訂單資料庫的金鑰」。是寫在 repo、CI 變數還是設定檔，沒說。
4. CI 主機上的未授權執行緒（10/3）調查是在這台 CI 主機上找到入侵紀錄的。
5. Commerce Cloud 短期訂單資料庫部分資料被拿走。

官方沒有公布的部分：是哪一個 CVE、Appsmith 有沒有對外開放、攻擊者怎麼拿到讀 GitLab 的權限、資料是怎麼送出去的。未知

從防堵措施反推事發時的狀態

一份事後補洞的清單，等於一份事發時有哪些洞的清單。

1.4ARTEX 是什麼，出現在哪

ARTEX 是一套開源的 AI 滲透測試系統，不是模型。它用 Go 寫，把偵察、找漏洞、規劃路徑、執行、記錄做成 planner 與多個 worker 的流程，模型是插上去的，可以接 Anthropic、OpenAI、DeepSeek 或任何自訂端點。CrowdStrike 指出它由中國開發。依 Wisely Chen 整理的 fork 說明，原作者在 2026 年 7 月以 AGPL 授權上架，10/8 以被濫用為由下架，但 fork 與鏡像仍在流通。已證實

9–10 月，ARTEX 在多份獨立調查裡出現：

同一個工具出現在營利集團與兩個國家級團體手上，代表它已經是商品。也因此，沒有任何公開資料把 91APP 案歸到上面任何一個行為者。未知 91APP 說「工具鏈相同」，但工具相同不代表人相同。

1.5永豐銀：被打的是什麼

永豐銀行的「新網銀」是一套新的網路銀行交易系統與 App，採用國外一家知名廠商的新技術。官方說法 11 月 3 日上午，418 個帳戶出現 427 筆異常轉出，合計 4,176 萬元，多數一筆 10 萬元，全部轉進台北富邦銀行的同一個帳戶。金管會統計為 419 人。已證實

收款帳戶的持有人是一位 70 多歲的退休教師，退休後曾遭投資詐騙。到案時表示不知情，警方初步查證沒有發現他提供人頭帳戶的跡象。台北地檢署以妨害電腦使用罪方向偵辦，檢警不排除駭客的目的是「炫技」。已證實

時間軸（11/3）

攻擊鏈

永豐以已進入司法程序為由，沒有說明繞過的是哪一道驗證。以下是從公開說法拼出來的。

1. 用身分證字號列舉出有效帳戶受害者的身分證字號全部是 P1 開頭（雲林男性）。銀行說駭客用特定手法「隨機試誤」找出有效帳戶，沒有事先拿到客戶資料，也沒有個資外洩的軌跡。官方說法
2. 跳過驗證機制銀行的用語是「利用供應商安全設定」或「供應商程式原生瑕疵」，瑕疵是在系統導入時產生的。哪一道驗證、怎麼跳過，未公開。未知
3. 轉出超過非約定轉帳上限的金額永豐公告的個人非約定轉帳上限是每筆 5 萬元，這次多數一筆 10 萬元。官方沒有解釋。未知

總經理莊銘福明確表示這次「並非代理式 AI 群攻」，是單一駭客發動。官方說法 另有一則 Threads 貼文說自己沒開 App、紀錄卻顯示刷臉確認，目前只有這一則，沒有查證。未知

從防堵措施反推事發時的狀態

供應商是誰，兩邊說法有出入。鏡報與 ETtoday 引述永豐是這套系統在台灣的唯一客戶，中央社寫的是「台灣有 5 家業者使用該系統」。未知

1.6監管、品牌與補償

91APP。數產署的行政檢查列了四個重點：駭客怎麼拿到資料、資料庫權限與防護是否妥適、異常存取有沒有被即時偵測、還有沒有其他系統受影響，若違反個資法將依法處理。截至 11/9 沒有公布結果或裁處。已證實 補償分兩類。有財損者須附報案三聯單與被詐證據。沒有財損者可申請，但要自己描述個資受損的情形。金額、認定方式與財報認列時點都還沒定。官方說法 有申請者反映填完表單後收到釣魚訊息、自己受害的期間落在公告範圍外，這兩點都沒有人查證。未知 若走訴訟，個資法第 28 條在損害難以證明時是每人每事件 500 到 2 萬元、同一事件總額上限 2 億元，企業須證明自己無故意或過失才能免責。已證實

品牌端在雙 11 前先接到客訴。有品牌主管對媒體表示，91APP 一開始告訴他們的影響範圍是「近半年」或「最近兩個月」，最後公布的是 18 個月。已證實

永豐銀。金錢損失由銀行墊付，當天退清。董事長說「歸還款項並不代表事件結束」。銀行要向供應商求償，金額未定。官方說法 金管會在 11/4 提出兩個方向。一是研究讓關鍵供應商加入 F-ISAC 分享資安情資，年底前推動。二是把委外責任分級，訂出 SLA、資料保護、通報時限的參考條款。沒有提到裁處。已證實

第 2 章 · 分析 · ANALYSIS

2.1兩場記者會，兩句相反的話

一家說是 AI，一家說不是 AI。如果 AI 是這兩件事的原因，兩條攻擊鏈應該長得不一樣。結果它們長得一樣。破口都是第三方元件，手法都是十年前就有的，最先察覺異常的都是客戶。AI 這個標籤和根因，是兩件不相干的事。

2.2把 AI 拿掉，再讀一次

對兩條鏈的每一環問同一題。這一環，沒有 AI 做不做得到？

* 永豐這一環的「否」站在銀行自己的說法（單一駭客）與列舉模式上，驗證細節未公開。推論

沒有一環需要 AI。沒修的已知漏洞、放在程式碼平台的資料庫帳密、能直連正式資料庫的 CI 主機，都是例行的弱點掃描與權限盤點本來就該列出來的項目。帳號列舉加上驗證邏輯的洞，是網頁應用程式安全教材的第一章。韓國案的入口也是同一類，給仲介和員工用的周邊系統。

門不會認人。
它只認有沒有鎖。

所以這兩件事真正共同的題目是這些門為什麼開著。91APP 的 Appsmith 是自己架的，修補清單裡沒有它。永豐的新網銀是買來的，驗收時安全設定沒走完。一個是沒人盯，一個是以為對方盯了。

2.3AI 真正改變了什麼

把 AI 拿掉之後，還是要把它放回去，放到對的位置。它改變的是下面三個數字。

漏洞被找到的速度在加快，組織修補的速度沒有跟上，中間那段空窗就是攻擊者的工作時間。ARTEX 這類工具把「偵察、試、失敗、換路」做成可以平行跑的流程，一個操作者能同時盯很多個目標。以前不值得花人力去打的後台小工具，現在試一次幾乎不花錢。奧義智慧科技創辦人邱銘彰的說法是「駭客也被賦能了」，連納骨塔的系統都有人打。已證實

所以 AI 改變的是分母，也就是有多少扇門會被試。它沒有改變分子，這扇門會不會開。91APP 用了 11 天才找到破口，就是修補速度那條線的具體例子。

2.411 天與 4 小時 18 分

兩案最先響的偵測器都是客戶。91APP 是收到詐騙訊息的消費者，永豐是發現錢不見的存戶。時間軸裡沒有任何一步是內部監控先發現的。推論 差別在客戶響了之後。永豐在客訴後 4 小時 18 分下架系統，當天退款。91APP 從第一次通報到找到破口花了 11 天。

官方給的原因是調查方向。一筆訂單會經過品牌端電腦、訂單管理系統、物流與 91APP 平台，過去查訂單外洩時習慣先查外部節點，這次也先往外查。10/6 詐騙訊息的資料又對不上，更強化了「不是我們」的判斷。資安長在記者會上承認應該一開始就內外同時查。官方說法 永豐沒有這個問題，錢從自己的系統轉出去，沒有別人可以查。

還有一個差別決定了事後能說什麼。寫入的路徑有帳本，讀取的路徑沒有。永豐能精確到 427 筆、每一筆的金額與去向，因為轉帳本來就會留下紀錄。91APP 只能給上限 479 萬，因為事後無法從紀錄裡重建攻擊者查了哪些資料、送出去多少。推論 這讓兩個平常被當成成本的設定，變成這次的直接損失。

• 查詢層的稽核紀錄。有的話，479 萬可能可以縮成實際筆數；沒有，就只能全部通知、全部受理。
• 資料保留期。這座「短期」資料庫留了 18 個月，影響範圍就是 18 個月。如果只留 6 個月，訂單數大約只剩三分之一（人數不會等比例縮，回購的人會重疊）。

2.5「先查明再通知」錯在哪

個資法第 12 條要求的是「查明後」通知當事人，所以 91APP 對消費者這一端，等到 10/29 才公布範圍，在條文上說得通。問題出在另一條線，也就是品牌。依個資法，受委託處理資料者在適用範圍內視同委託機關，委託的品牌也有監督受託者的義務。品牌是被消費者追問的第一線，卻在 10/4 到 10/15 之間沒有收到平台的任何警示，只能自己比對詐騙信去猜範圍。

對平台型業者，「已確認」和「已足以通知客戶」是兩個不同的門檻。91APP 把兩個門檻當成同一個，董事長在兩份報告裡都為此道歉。永豐的做法剛好是反例。中午還沒查出原因，就先決定不論結果全額退還。（本段是條文層面的整理，我不是律師。）

2.6自己架的門，買來的門

對品牌來說，選 91APP 是把會員資料的資安外包出去。對攻擊者來說，打一座平台資料庫等於一次打一千多家品牌。對永豐來說，買國外廠商的新網銀是把交易系統的安全外包出去。對攻擊者來說，一個設定上的洞就是 418 個帳戶。這是外包的規模經濟，也是它的集中風險。

兩案的責任分配不一樣。91APP 的 Appsmith 是開源軟體，沒有人可以求償，責任全在自己。永豐可以向供應商求償，但銀行自己也承認驗收時「有些例外」。金管會這週提的兩個方向，供應商加入 F-ISAC、委外責任分級，就是在回答這一題。買來的門，誰負責確認它有鎖。

2.7為什麼「AI 攻擊」這個說法這麼好用

對公司，它把責任往外推，新型態的攻擊聽起來不是任何人該預見的。對媒體，它新鮮。對資安業，它好賣。這三方的誘因剛好對齊，所以這四個字會先於根因出現在標題上。

要公平地說，91APP 自己的報告寫了，工具新穎不改變公司的責任，修補沒跟上攻擊速度才是要檢討的地方。官方說法 永豐則直接否認是 AI。這一段想指出的是，這個說法會讓真正的檢討跳過去。如果問題是 AI，答案就是買 AI 防禦。如果問題是沒修補、沒驗收、沒紀錄，答案就沒有那麼好買。

第 3 章 · 結論 · FINDINGS

3調查發現

依調查報告的慣例分三類。在運安會的報告裡，天候幾乎從來只出現在「與風險有關之發現」，很少被列為「可能肇因」。它影響了速度，沒有決定哪扇門會開。AI 在這兩案的位置就是天候。

與可能肇因有關之調查發現Findings related to probable causes

1. 1

   91APP 內部使用的 Appsmith 存在已知漏洞，未套用修補，成為入口。官方說法

2. 2

   91APP 一座正式訂單資料庫的金鑰可以從內部 GitLab 取得。官方說法

3. 3

   91APP 的 CI 主機與正式資料庫網段之間可以連通，入侵紀錄出現在 CI 主機上。推論

4. 4

   永豐新網銀交易系統的驗證邏輯存在供應商導入時產生的瑕疵，可被繞過。官方說法

5. 5

   永豐新網銀允許以身分證字號列舉有效帳戶，且未對短時間內的大量查詢設限。推論

與風險有關之調查發現Findings related to risk

1. 6

   兩案最先察覺異常的都是客戶，沒有一步是內部監控先發現的。推論

2. 7

   91APP 測試環境與正式環境沒有隔離。推論

3. 8

   91APP 無法逐筆判定外洩訂單，影響範圍只能以資料保留期（18 個月）為上限。官方說法

4. 9

   10/4 到 10/15 之間，品牌沒有收到 91APP 的事故警示，公司已承認是疏失；初期說明的範圍（半年、兩個月）與最後公布的 18 個月不一致。已證實

5. 10

   91APP 初期調查依過去經驗先查外部節點，延後了找到內部破口的時間。官方說法

6. 11

   永豐新網銀上線時，與供應商確認安全設定的驗收步驟沒有照常走完。官方說法

7. 12

   永豐實際轉出金額超過公告的非約定轉帳上限，原因未說明。未知

8. 13

   漏洞公開到被利用的時間在縮短，組織的修補時間在拉長；AI 工具擴大了被嘗試的目標數量。這是兩案發生的環境，不是任一案的肇因。已證實

其他調查發現Other findings

1. 14

   91APP 系統內有 ARTEX 痕跡，但它在鏈中執行了哪一段、用了哪個模型、背後是誰，都沒有公開；永豐否認 AI 涉入。兩條鏈在去掉 AI 之後每一環仍成立。推論

2. 15

   被利用的 Appsmith 漏洞編號沒有公開。2026 年 Appsmith 公開的高風險漏洞不只一個（例如有在野利用紀錄的帳號接管 CVE-2026-22794、2.1 版以前的 supervisord 指令執行 CVE-2026-50189），但沒有證據指向其中任何一個。未知

3. 16

   永豐新網銀供應商的身分、以及該系統在台灣有幾家客戶，媒體說法互相矛盾。未知

4. 17

   91APP 補償金額、認定方式與財報認列時點尚未決定；數產署尚未公布檢查結果；永豐對供應商的求償金額未定。已證實

5. 18

   「AI 攻擊」這個說法在兩案中都先於根因出現在公開討論裡，對公司、媒體與資安業三方的誘因一致，可能延後對修補、驗收與紀錄的檢討。推論

第 4 章 · 改善建議 · RECOMMENDATIONS

4回頭看自己的系統

這些不是給 91APP 或永豐的建議，是給任何一個有內部工具、有 CI、有客戶資料、有買來的系統的團隊。最後一欄對應上面的發現編號。

附錄 · OPEN QUESTIONS

還在等的答案

• 91APP：被利用的是哪一個 Appsmith 漏洞，那台 Appsmith 是否對外開放；攻擊者如何取得讀 GitLab 的權限；ARTEX 在鏈裡做了哪一段；資料送出多少；數產署的檢查結果；補償金額與認列時點。
• 永豐：繞過的是哪一道驗證；10 萬元如何超過 5 萬元的非約定上限；「沒開 App 卻顯示刷臉」是否屬實；供應商是誰、台灣有幾家客戶；單一駭客的說法有沒有第三方鑑識佐證。

來源 · SOURCES

1. 91APP《2026 遭受駭客攻擊事件 18 天調查報告》，2026-10-22
2. 91APP 遭受駭客攻擊事件說明與後續補償計畫（含根因與防堵措施）
3. 91APP《被駭事件：25 天調查報告》，2026-10-29
4. 91APP*-KY 重大訊息：本公司發生網路資安事件說明（鉅亨網轉載），2026-10-16
5. 數位產業署：91APP 電商平台資料庫遭未授權存取，啟動行政檢查，2026-10-20
6. TechOrange：91APP 遭駭為何花了 11 天才查出破口，2026-10-29
7. iThome：91APP 遭駭事件查出 ARTEX 攻擊痕跡，2026-10-23
8. iThome：臺灣無印良品受 91APP 事件波及，初估約 18 萬人
9. 遠見：91APP 詐騙信風暴始末，2026-10-19
10. 自由財經：資安風暴未歇，10 月來跌逾 1 成，2026-10-30
11. ETtoday：91APP 補償用免費表單挨轟，官方急改，2026-11-07
12. 新頭殼：91APP 補償各品牌分開填還要自己舉證，2026-11-07
13. 中時：消保處曝團訟門檻，2026-11-05
14. 中央社：永豐銀新網銀 APP 釀資安危機，還原遭駭時間軸，2026-11-04
15. 鉅亨網：〈永豐資安事件〉董總二度鞠躬致歉、還原遭駭始末，2026-11-04
16. 鉅亨網：「金錢無損但商譽受創」，將向國外供應商求償，2026-11-04
17. 聯合報：永豐銀遭駭破口揭曉，供應商程式原生瑕疵，2026-11-04
18. 今周刊：新網銀系統遭駭客鎖定、隨機試誤讓 P 開頭用戶受害，2026-11-04
19. 鏡報：永豐總座稱單一駭客所為，2026-11-05
20. ETtoday：收款帳戶持有人是曾遭詐 7 旬翁，2026-11-05
21. 自由財經：金管會：419 人受影響、總金額約 4 千多萬
22. 數位時代（LINE TODAY）：金管會擬祭 2 招，擴大資訊聯防、分級界定委外責任，2026-11-04
23. 優分析：再傳交易異常，永豐銀：跨行轉帳受影響已恢復，2026-11-06
24. 數位時代：91APP、永豐銀遇駭客，資安專家：企業先守住 7 道防線，2026-11-05
25. Mark Lin：門鎖沒壞，鑰匙被借走，2026-11-06
26. Wisely Chen：ARTEX 到底是什麼，2026-10-24
27. Wisely Chen：為什麼最近資安事件這麼多（CVE 2.2 倍、修補中位數 32→43 天），2026-11-04
28. CrowdStrike：Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance，2026-10-07
29. iThome：GMO 確認攻擊者使用 ARTEX 鎖定日本企業，2026-10-21
30. The Hacker News：Microsoft ties Storm-0940 to ARTEX-driven ConnectWise compromise
31. CrowdStrike：VAPOR PANDA Uses AI-Driven ARTEX to Scale a Global Espionage Campaign，2026-10-29
32. Resecurity：CVE-2026-22794；SentinelOne：CVE-2026-50189
33. 個人資料保護法條文

本文依公開資料整理，無第一手鑑識資料，不構成法律意見。查核截至 2026-11-09 09:00（UTC+8）。後續報告公布後，標為「推論」與「未知」的條目可能改變。