11 月 3 日，永豐銀行客戶的錢被不明轉出：419 人（也有報導寫 418 人）、427 筆，轉出逾 4,000 萬元。

5 天前，91APP 公布 25 天調查報告，最大可能影響範圍是 1,329 家品牌、4,798,255 名消費者。

有時候有人問我，為什麼最近資安事件這麼多？

我的答案是：攻擊者在 AI 上進化的速度，跟防禦者完全錯配。我的體感是攻擊者快了 10 倍。

這個 10 倍查不到任何來源，它就是我的體感。所以這篇我把這個論點拿去對公開數據，對得上的留下，對不上的直接講。

30 秒定位

指標 之前 現在 變化 來源
發布的 CVE（1/1–10/23） 38,569 86,292 2.2 倍 CyberHire
掛名 AI 發現的 CVE 34 769 22 倍，只是下限 CyberHire
每月實際被利用的漏洞 10.5 18 約 1.7 倍 GTIG
修補時間中位數 32 天 43 天 慢了 34% Verizon DBIR 2026
CISA KEV 完全修補比例 38% 26% 掉了 12 個百分點 Verizon DBIR 2026

先看最後兩列。找洞的數字往上衝，修補的數字往下掉。

這張表也有一件事對我不利：沒有任何一列是 10 倍以上的攻擊速度。後面會回來講。

台灣這兩週：先把證據層級分清楚

對象 目前能講到哪裡 誰說的
91APP 確認遭入侵。未更新套件的 Appsmith 被當入口，再從 GitLab 取得資料庫金鑰。系統內發現 ARTEX 91APP 官方報告
永豐銀行 確認異常轉帳。歸因於新網銀系統的供應商程式原生瑕疵。款項已全數返還 永豐新聞稿
莫筆克（ERP） 10 月 31 日發現主機遭未授權執行惡意指令 莫筆克說明，經 iThome
meepShop 商家轉述：11 月 2 日凌晨遭外部攻擊，部分訂單資料可能遭取得。meepShop 未回覆 iThome 品牌公告，經 iThome
1shop 10 月 28 日接獲通報，詐騙信內容吻合真實訂單。Mailgun 金鑰外洩是它自己的推論，沒有證實系統遭入侵 1shop 公告
SHOPLINE 10 月 21 日說未發現平台遭入侵的證據。11 月 3 日的事件在第三方 ERP 那一端，平台本身未遭入侵，已換 API Token SHOPLINE 公告，經 iThome
Cyberbiz 有品牌發防詐公告提到異常讀取，平台還沒公開說明 品牌公告，經 iThome

這七個對象裡，只有 91APP 跟 AI 工具有官方連結。 永豐的新聞稿和報導都沒有提到 AI。iThome 也寫明，其他電商業者是否涉及 AI 輔助攻擊，仍待調查。

所以這些案例不能當「AI 造成」的證據。我拿它們當情境：補洞和供應鏈跟不上時，現場長什麼樣子。

91APP 報告裡有一句話，我覺得是這篇的題眼：

防護與修補管理未跟上攻擊速度

攻擊者這邊變快的四件事

1. 門檻：Cyber Agent 把專案管理產品化

ARTEX 是今年 7 月 26 日出現在 GitHub 的開源 AI 滲透測試系統。10 月 7 日 CrowdStrike 的韓國案、10 月 19 日 GMO 的日本約 20 家企業、10 月 22 日的 91APP，都出現它的名字。

我之前拆過它的架構。它是 harness，把偵察、規劃、執行、驗證、紀錄包成可以自架的系統，模型可以換。

91APP 25 天報告明確寫了，這次的工具鏈和韓、日同一波相同。但它還是沒有公布 ARTEX 實際跑了哪幾段。韓國金融保安院的說法仍然是：不是 AI 自主攻擊，是駭客用了 AI 工具。

所以門檻降低這件事我相信，但目前的證據是「有人這樣用」，還不是「門檻降了多少」。

2. 揭露：漏洞被找出來的速度

我的體感是 10 到 100 倍。

查得到的數字沒有這麼誇張。全部 CVE 是 2.2 倍，掛名 AI 發現的是 22 倍，而且 22 倍的分母只有 34，769 也只算有公開標註的單位。GTIG 的月揭露量，從 1 月的 5,045 爬到 8 月的 10,740。

這裡也不全是 AI 的功勞。GTIG 提醒，自動化的 CVE 編號流程會灌水，光描述含 Linux Kernel 的就有約 5,000 個，沒有一個被觀察到當 zero-day 利用。CyberHire 也承認，這份資料證明不了因果，流程改變可能解釋一部分。

個案上比較有感。PHP2Shell 是 Calif 用 GPT-5.6 Sol 找到的，Chrome 156 一次修 353 個安全問題，致謝欄就有 AI 的名字。

3. 時差：每個人都知道最新的洞在哪

AI 讓我們追新聞變快，也讓駭客追 CVE 變快，幾乎沒有時差。

這點要分開講，因為「知道」和「打得出來」是兩段。

打得出來這段，Anthropic 6 月的自測是：Mythos Preview 在 Mozilla 發修補後不到 1 小時就寫出第一支 exploit，18 個修補做出 8 支，約 12 小時。同一篇拿 2017 年的 WannaCry 對比，那次是修補後 59 天。

限制也要一起看。那是廠商自測，跑的是獨立的 jsshell 不是完整瀏覽器，護欄是關的，而且它自己也說 exploit 只是完整攻擊的一步。

真實世界的數字：GTIG 記錄 BeyondTrust 的 CVE-2026-1731 公開後四天開始被利用，七天內又多 5 個攻擊群。PHP2Shell 修補當天凌晨 Cloudflare 就擋到攻擊流量，雖然那時 PHP 團隊還沒看到能動的 exploit。GTIG 的判斷是，攻擊者可能正用 LLM 比對修補版本差異來加速 n-day，原文的用詞就是「可能」。

Mandiant 那個常被引用的「平均 -7 天」也要小心。那是 2025 年的資料，YesWeHack 指出它算的是最早觀察到的利用活動，不是大規模利用的時間表。

所以「幾乎沒有時差」在高價值漏洞上講得通，不能套到每一個 CVE。

4. 外圍：以前沒人有耐心打的子系統

這是我們平常最常漏掉的一點。

駭客本來就會忽略一些外圍子系統。現在紅軍 AI 掃描的速度，我的體感是以前的 100 倍，原本不好掃的子系統，現在都很容易掃出來。

100 倍同樣查不到來源。我手上唯一的第一手數字，是八月在朋友邀請下做的黑箱紅軍：偵察 3 分鐘，人工大概要十幾二十分鐘，換算只有 5 到 7 倍。兩小時挑出 10 個問題。

單一目標上我沒量到 100 倍。如果 100 倍成立，我猜它來自平行，也就是同時開很多條線，不是單條線變快。這是推論，我沒有量過。

但被打的位置，案例是一致的。韓國新韓是給仲介用的查詢服務，91APP 是內部效率工具 Appsmith，莫筆克是 ERP，1shop 懷疑的是寄信用的 Mailgun 金鑰。這幾個入口，沒有一個是主交易系統本體。

永豐的攻擊手法也值得看一眼：隨機試誤找出有效帳戶，受影響者身分證字號首碼相同。這跟新韓那個「隨機試客戶編號」形狀很像。形狀像而已，兩案沒有任何證據有關聯，永豐也沒有 AI 參與的證據。

防禦者這邊為什麼快不起來

1. Patch 上線的速度沒有跟著變快

我原本的說法是「速度跟之前一樣」。查完之後，這句話還太樂觀。

Verizon DBIR 2026 的修補時間中位數，從 32 天變 43 天。CISA KEV 完全修補的比例從 38% 掉到 26%。漏洞利用佔初始入侵的 31%，超過憑證濫用。

就算是最順的路徑也要時間。Anthropic 引的 Windows Autopatch，修補推到 90% 裝置也要約 7 天。

永豐還多一層。系統的瑕疵在供應商的程式裡，新聞稿說台灣目前沒有其他金融業導入，銀行表示會向這家國外供應商求償。新聞稿提到的是阻斷這個手法和加強驗證，沒有公布供應商的修補時程。

你的補洞速度，上限是你最慢那個供應商的速度。 這句是我的推論，不是永豐的說法。

2. 不對稱：失敗的成本完全不一樣

攻擊者可能失敗 100 次，只要成功一次就贏了。這是比喻，不是統計。

防禦者不一樣。就算用 coding agent 快速補洞，也要冒測試不完全、出 bug 造成商務損失的風險。攻擊者失敗一次沒有代價，防禦者上線一個錯的 patch，帳要自己付。

這一點現在有數據了。1Password 8 月的研究，用 ChatGPT-5.5 和 Opus 4.8 替 6 個漏洞產出 6,080 份修補：

結果 比例
完全正確 26.0%
修掉漏洞，但改變了不相關的行為 20.1%
沒修好，或引入新漏洞 53.9%

給模型驗證過的正確方向，完全正確也只到 31%。1Password 也提到，發表後有回饋認為實驗的限制可能綁住了 agent 工具的能力，所以這不代表上限。

這組數字修正了我自己的說法。我在 ARTEX 那篇的影片裡講過用無護欄紅軍 AI 加 coding agent 的防守流程。方向我還是認同，但「找到洞就讓 agent 修」不能直接接到正式環境，中間要有 exploit 回歸測試和行為檢查。

人力也卡住。PHP 基金會說，7 月以來發了 15 個 CVE，另外消化了 100 多份無效、重複或重現不了的報告，而能判斷引擎設計該怎麼修的資深工程師太少。工具可以找洞，相容性的取捨和審 patch 還是落在這些人身上。

反方：這個論點哪裡可能是錯的

最強的反駁有兩個。

第一，防守方也有 AI，而且看起來跑得更前面。 那 769 個掛名 AI 的 CVE，掛名本身就代表是回報給維護者的。Patch the Planet、Chrome 的 353 個修補，都是防守方的動作。憑什麼說攻擊者比較快？

這個反駁我接受一半，它逼我改了論點。

「防禦者」其實是兩群人。上游的 AI lab 和大廠，找洞和寫修補確實變快了。下游每一家要把修補測完、排窗口、上線的公司，沒有。上游找得越快，下游的待修清單越長。

所以錯配不在攻擊者和防禦者之間，在攻擊者和最後一哩之間。 攻擊者拿到修補就能比對，下游還在排維護窗口。

第二，真正被打的數字沒有長那麼多。 CVE 是 2.2 倍，GTIG 統計被利用的只佔 0.23%，每月被利用數約 1.7 倍；CyberHire 算的 active 從 163 到 195，只多約 20%。GTIG 也說 zero-day 大致持平。

那「最近事件很多」會不會有一部分是注意力？91APP 之後大家都在查，媒體也在追。

我回應不了全部。這波台灣事件集中出現，確實可能有「大家開始查」的成分。我能講的是，今年 1 到 8 月的 141 個已經超過 2025 全年的 127 個，方向是往上，只是倍數遠小於我的 10 倍體感。

10 倍這個數字，我留著當體感，不當結論。

這會改變什麼決策

以企業 CTO 來看，差別大概是這樣。

決策 之前 之後
預算加在哪 掃描工具，多找一點洞 修補產線：回歸測試、灰度上線、回滾
修補順序 照 CVSS 分數 先看有沒有人在打、系統有沒有對外
盤點範圍 核心系統 任何碰得到客戶資料的東西，含 ERP、郵件服務金鑰、內部工具
暫時修不了 排隊等窗口 先關門，荷蘭 NCSC 對 PHP2Shell 的建議就是隔離公網
供應商 看認證 合約寫修補時限和事件通知時限
Coding agent 補洞 看測試過就上 當候選版本，配 exploit 回歸測試和人工審

第一列我最想講。下游容量不變的話，多掃只是讓清單變長。如果你的團隊現在一季消化不完掃描結果，再買一套掃描工具沒有用。但如果你連外圍系統都還沒盤點，那掃描還是要先做，這個順序因公司而異。

坦白說

這篇的主張要打幾個折。

第一，10 倍、10 到 100 倍、100 倍都是我的體感。我查不到任何量測攻擊者工作流加速倍數的公開資料，也不確定這件事能不能被量。公開數字支持的是方向，不是倍數。

第二，台灣這些案例無法證明是 AI 造成的。只有 91APP 官方提到 ARTEX，而且沒有公布它跑了哪一段。永豐官方歸因於供應商程式瑕疵，沒有 AI 參與的證據。

第三，案例的來源層級不一。這篇的素材之一是 Patty 每日一財經的整理圖卡，資料截至 11 月 3 日。圖卡寫 meepShop「平台證實」、02:43、已報警，我查到的是商家轉述的「當天凌晨」，查不到 meepShop 自己的公告，所以沒有採用這些細節。永豐的人數也有 418、419 兩個版本。這些事件都還在調查中，數字會變。

第四，修補數據和 CVE 暴增不在同一段時間。DBIR 2026 是 5 月發布的，早於今年下半年的高峰，所以 43 天不能說是被這波 CVE 擠慢的。放在同一張表是我的對照，不是因果。之後的 DBIR 才看得出 AI 有沒有把修補拉快，也可能證明我講錯了。

第五，CVE 總數和掛名 AI 的數字只有 CyberHire 一個來源，方法公開但沒有第三方複算。1Password 只測 6 個漏洞，成績依程式碼庫差異很大。

關鍵洞察

用「最後一哩」看待自己的位置。 上游找洞變快對你不一定是好消息，它同時是攻擊者的情報來源。要問的是你的修補產線一個月能消化多少，而不是這個月掃出多少。

修補順序先看「有沒有人在打」和「有沒有對外」。 只有約 0.23% 的揭露漏洞被觀察到實際利用，全部都補做不到，也不必。

coding agent 的修補是候選版本。 在 1Password 的測試裡，只有 26.0% 完全正確。導入前先準備好 exploit 回歸測試和回滾，這兩樣沒有，補得越快風險越大。

外圍子系統修不動就先關門。 內部工具不必對外的就收掉，這比等修補快。

大概是這樣子，數字會變，10 倍這個體感我也會繼續對。

常見問題 Q&A

Q: 為什麼 2026 年資安事件好像變多了？

可以確認的是揭露和利用都在增加。依 CyberHire 統計，2026 年 1 月 1 日到 10 月 23 日發布的 CVE 有 86,292 個，是去年同期 38,569 個的 2.2 倍；Google 威脅情報團隊（GTIG）統計，每月實際被利用的漏洞從 2025 年的平均 10.5 個升到 2026 年的 18 個。但修補沒跟上，Verizon DBIR 2026 的修補時間中位數從 32 天變 43 天。部分增幅也可能來自 CVE 編號流程的改變和事件曝光度，因果還無法定論。

Q: 永豐銀行和 91APP 事件是 AI 攻擊造成的嗎？

目前不能這樣說。永豐銀行 2026 年 11 月 4 日的新聞稿，把異常轉帳歸因於新網銀系統的供應商程式原生瑕疵，遭駭客以隨機試誤方式利用，沒有提到 AI。91APP 的調查報告則說系統內發現 ARTEX 痕跡，並說攻擊者利用 ARTEX 自動化攻擊進入內網，破口是未更新套件的第三方工具 Appsmith，但沒有公布 ARTEX 實際執行了哪些步驟。1shop、meepShop、Cyberbiz 是否涉及 AI，iThome 的報導寫明仍待調查。

Q: ARTEX 是什麼？和 ARTEK 一樣嗎？

正確名稱是 ARTEX。它是 2026 年 7 月 26 日出現在 GitHub 的開源 AI 自主滲透測試系統（Autonomous Penetration Testing System），把模型接上規劃、執行工具、資產圖和審批流程，模型可以替換，所以它是 harness，不是模型。2026 年 10 月，韓國金融機構案、日本約 20 家企業案和台灣 91APP 的調查都出現這個名字。韓國金融保安院的說法是，這是駭客使用 AI 工具，不是 AI 自主決定攻擊。

Q: 可以直接讓 Coding Agent 自動修補資安漏洞嗎？

目前不建議直接上正式環境。1Password 2026 年 8 月的研究，用 ChatGPT-5.5 和 Opus 4.8 替 6 個漏洞產出 6,080 份修補（Security Patch），只有 26.0% 完全正確，20.1% 修掉漏洞但改變了其他行為，53.9% 沒修好或引入新漏洞。研究者也提到實驗限制可能低估了 agent 工具的能力。比較穩的做法，是把 agent 的修補當候選版本，配上漏洞利用回歸測試（Exploit Regression Test）、行為檢查和資深工程師審查。

Q: 資源有限的企業，修補順序怎麼排？

依 GTIG 統計，2026 年揭露的漏洞只有約 0.23% 被觀察到實際利用，所以只看 CVSS 分數排序容易浪費人力。比較實際的順序，是先處理已知被利用（CISA KEV 清單）且對外暴露的系統，再把盤點範圍擴大到內部工具、ERP、郵件服務金鑰這類碰得到客戶資料的外圍子系統。暫時修不了的先隔離公網或下線，同時在供應商合約裡寫明修補與事件通知的時限。

資料來源