AI 讓攻擊者更快利用已知漏洞，企業的修補、權限控管與通報流程，都要以 72 小時為單位重新安排。
數位發展部在 2026 年 11 月 11 日表示，近期已接獲 10 多家企業通報遭攻擊或個資外洩，初步調查多數與 AI 攻擊有關。數產署同時提出電商平台與資訊服務業者的五項行動，其中多項以 72 小時為期限。對中小企業來說，這不只是大型平台的事：只要網站、會員系統或後台 API 存有客戶資料，就在同一條攻擊路徑上。
這波攻擊的特徵：快、鎖定個資、利用已知漏洞
結論是，攻擊者多半不是靠全新的手法，而是用 AI 加快利用「已經公開的漏洞」。
根據中央社報導，數發部部長林宜敬指出，通報受害的企業有五、六家規模較大，這類攻擊的特徵是速度很快，會用 AI 工具針對不同漏洞調整手法，目標是個資，取得後常轉賣給詐騙集團。他也提到，直接財損相對小，真正大的是間接損失與品牌商譽。
資安署署長蔡福隆說明，攻擊者利用 PHP、Node.js、GitLab 等軟體的已知高風險漏洞，再透過高權限 API 大量撈取個資。他建議企業盡快修補漏洞、強化系統存取控制，並提到平台業者因為握有大量品牌客戶資料，預期將面臨更嚴格的資安要求。
修補時間正在被壓縮，「下個月再更新」已經來不及
結論是，從漏洞公開到被實際利用的時間，已經從以週計算縮短到以天計算。
資安公司 Rapid7 在 2026 年 3 月發布的全球威脅情勢報告指出，遭實際利用的高風險與嚴重等級漏洞，從 2024 年的 71 個增加到 2025 年的 146 個，增幅 105%。漏洞從公開到被列入美國 CISA「已知遭利用漏洞清單」（KEV）的時間中位數，從 8.5 天縮短到 5.0 天；平均值則從 61.0 天降到 28.5 天。Rapid7 首席科學家 Raj Samani 的說法是，漏洞被利用的時間「越來越常以天、而不是以週來計算」。
近期的例子是 PHP。PHP 官方在 2026 年 10 月 21 日釋出安全更新，修補兩項 CVSS v4.0 基礎分數 9.2 的遠端程式碼執行漏洞（CVE-2026-109618、CVE-2026-109619）。TWCERT/CC 說明，受影響的是所有處理網頁請求的 PHP 環境，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 與 LiteSpeed。修補版本為 8.5.12、8.4.27、8.3.36 與 8.2.35；8.1 及更早版本官方已不再提供正式更新（另提供精簡的原始碼修補），8.2 則在 2026 年 12 月 31 日結束生命週期。
TWCERT/CC 提醒，WordPress、Drupal、Joomla、Magento 等以 PHP 運作的內容管理系統也要一併確認；如果網站由委外廠商維運，應向廠商確認 PHP 版本與修補狀態。無法立即更新時，可以考慮先把對外系統與網際網路隔離或暫停服務，並檢查是否已被植入後門。
數發部提出的五項行動，多數以 72 小時為期限
結論是，主管機關對「發現問題後多快處理」已經有明確的時間期待。
依工商時報報導，數產署副署長黃雅萍針對電商平台與資訊服務業者提出五項行動：
- 國家資通安全研究院或資安主管機關對特定軟體或設備發布重大警訊時，72 小時內完成更新、修補、關閉功能或其他防護措施。
- 72 小時內通報主管機關。
- 72 小時內通知受影響的當事人，並提醒可能的詐騙風險。
- 發生資料外洩時，72 小時內找出原因、修補漏洞、停用功能或採取其他有效措施，避免損害擴大。
- 事件後一個月內提出檢討與改善計畫，並落實「資料最小化原則」以縮小攻擊面。
中央社報導也提到，黃雅萍表示依據規定，數位業者發生個資事故應於 72 小時內通報數發部，並以電子郵件、簡訊或電話通知受影響客戶、提供查詢管道，且應於 1 個月內提出檢討與改善計畫。她同時說明，數發部的行政檢查目的在協助企業應變，不是為了處罰。
政府的防線：AI 對 AI，但基本功還是企業自己的事
結論是，政府會提供情資與工具，但盤點、修補與備份仍要由企業自己做到。
數發部在 11 月 3 日的 2026 台灣資安通報應變年會上，由次長楊佳玲宣布成立「先進 AI 資安風險因應小組」，讓各部會與關鍵基礎設施主管機關快速分享資訊。短期措施包括盤點關鍵系統、減少對外曝露、考慮汰除老舊系統、公布修補指引，以及用 AI 工具掃描重要系統。
林宜敬在 11 月 11 日也提到，政府已取得 Anthropic、OpenAI、Google、Microsoft 等 4 家公司的 AI 模型協助各部會掃描漏洞，並規劃協助民間企業取得這類工具。企業另外可以免費加入 TWCERT/CC 的資安情資分享。
但蔡福隆在年會上講得很直接：優先要把基本功做好，也就是減少曝露，並維持可靠的備份與備援。林宜敬在 11 月 11 日也提醒，企業應該先自保、比攻擊者更早找到漏洞，不要等政府要求才動作。
為什麼高權限 API 是這次的關鍵
結論是，一支權限過大的 API，就能讓一個漏洞變成整批個資外洩。
蔡福隆點出的攻擊路徑，是先利用漏洞進入，再透過高權限 API 大量撈資料。如果後台 API 用同一組高權限帳號存取整個會員資料庫，又沒有限制單次查詢筆數或呼叫頻率，一旦被入侵，攻擊者幾乎不需要額外步驟就能把資料整批帶走。
這也是數產署把「資料最小化原則」寫進五項行動的原因：資料留得越少、API 能看到的欄位越少，同一個漏洞造成的損害就越小。Rapid7 報告也提到，2025 年它處理的事件調查中，有 43.9% 涉及缺少或未落實多因素驗證的有效帳號，帳號與權限管理同樣是入口。
對企業的建議
結論是，先把「72 小時內能做到什麼」演練出來，比買新工具更重要。
- 列出所有對外服務的系統清單，標明使用的語言與框架版本（PHP、Node.js、GitLab 等），PHP 8.1 以前的版本優先規劃升級，8.2 在年底前排定升級時程。
- 跟委外維運廠商確認合約裡的修補時限，讓重大警訊發布後 72 小時內完成更新或暫時關閉功能變成可以執行的流程，而不是事後才協調。
- 盤點後台與對外 API 的權限，拆掉共用的高權限帳號，限制單次回傳筆數與呼叫頻率，並為管理帳號啟用多因素驗證。
- 檢視會員與訂單資料是否真的需要全部保留，依資料最小化原則刪除或遮蔽不必要的欄位。
- 事先寫好個資事故通報與客戶通知範本，並加入 TWCERT/CC 情資分享，讓警訊能第一時間送到負責的人手上。
頡亨資訊取得 ISO/IEC 27001:2022 認證，提供企業流程系統整合，以及政府與校園系統的資安維運服務。不論系統由誰維運，這次的 72 小時要求，都是重新檢視維運合約與修補流程的好時機。