這週的 IT 人，應該度過了如同地獄般的一週，這週最大的資安議題是 PHP2Shell，10 月 21 日 PHP 一次釋出 8.5.12、8.4.27、8.3.36、8.2.35 四個安全版本，修的是兩個不用登入就能遠端執行程式碼的漏洞；隔天 Arista 公告 SD-WAN 管理平台的漏洞，而且這個公告出來的時候已經有人在打；再隔天 PHP 又發了一則公告，還有一個 RCE 這次沒修到；期間還夾著 LiteLLM 被入侵，很多公司拿它來統一呼叫各家模型，攻擊者卻推上一個夾帶竊資程式的新版本。
讓這週像地獄的不只是數量，還有速度，Amazon 架來引誘攻擊者的誘捕系統在 10 月 17 日就記錄到 PHP2Shell 的利用嘗試，比修補早了四天，找到這組漏洞的 Wiz 研究團隊在報告裡也寫到，這是 PHP 裡存在很久的缺陷，是 AI 模型把攻擊門檻大幅降低，才變成能用的 exploit；同一週微軟公開 Storm-0940 的攻擊紀錄，這個組織用一個名為 ARTEX 的開源 Agentic AI 滲透框架，由 AI 自己決定下一步、自己呼叫工具，好幾次花不到 3 小時就從鎖定目標到拿到特權，微軟也提到 AI 自動化攻擊可以 24 小時持續執行，即使週末跟國定假日也不會停。
這幾批 Critical 漏洞，從修補到被利用隔了多久？#
AI 讓找漏洞、寫 exploit、打進去都變得又快、門檻又低，但防守這邊的修補跟告警流程，卻還是照著攻擊者是人的前提在安排，才會被打得措手不及。
Mandiant 的 M-Trends 2026 估計，2025 年遭利用的漏洞，平均被利用時間是負 7 天，意思是修補還沒出來就已經被利用了，下表的 PHP2Shell 跟 Arista 就是實際的例子。
Fortinet 10 月發布強化更新時的說明裡寫到，AI 工具已經能幫攻擊者在幾小時到幾天內，把修補內容反推成能用的 exploit，下表的 Langflow 跟 Plex 就是案例，照 Fortinet 的說法，修補釋出到被打之間的緩衝會越來越短。
| 事件 | 修補釋出 | 安全公告或 PoC 公開 | 開始被利用 |
|---|---|---|---|
| PHP2Shell（PHP 核心 RCE） | 10/21 | 10/21 | 10/17，誘捕系統就記錄到利用嘗試 |
| Arista VeloCloud Orchestrator（SD-WAN 管理平台） | 10/22 | 10/22 | 公告時已遭利用 |
| Langflow（AI 工作流程工具） | 4 月（1.9.0 版） | 9/10 安全公告 | 9/19 |
| Plex2Shell（Plex 影音伺服器） | 8/4 | 10/16 研究者公開 PoC | 10/17 |
把這陣子幾起 Critical 漏洞跟入侵事件的時間軸，對回原廠公告跟研究報告重新排過一次，可以看到兩種時間差：
- 修補時間差，是從原廠釋出修補到修好的版本真的在正式環境跑起來
- 偵測時間差，是從被打進來到攻擊真的被擋下來（這裡刻意算擋下來，不是算到告警響起）
修補時間差：每月一次的修補窗口，是照人的速度排的#
多數公司的修補流程，會每個月固定檢查一次系統、框架、套件的安全性更新包，確定要修補前，會先在測試環境跑一輪，走變更管理流程，在核准後才安排更版作業，但近期的案例裡，修補出來的時候攻擊已經開始了，修補跟緩解要用更短的時間來算。
此外 AI 讓研究人員找漏洞變快了，因此漏洞的量也在變大，微軟 10 月的 Patch Tuesday 一次修了 1,400 多個 CVE，Oracle 10 月的季度更新是 1,295 個安全修補，今年上半年 CVE 就發了 35,364 個，比去年同期多了快五成，靠人一筆一筆看公告、每個月重新討論哪個先修，根本排不完，所以哪幾類漏洞不等每月檢查、直接走緊急更版，就需要事先寫進公司政策。
修補也不是裝完就結束，PHP2Shell 就是一週內修不完的例子，8.1 跟更早的版本，官方沒有出正式版，只給使用者自己編譯用的原始碼修補，10 月 23 日 PHP 發的公告給的也不是修補，是先把 session.upload_progress.enabled 關掉的緩解。
偵測時間差：ARTEX 不到 3 小時拿到特權，你多久擋得下來？#
Railway 在 10 月 21 日發了資安公告，存放客戶環境變數的系統被入侵，請所有客戶馬上把環境變數裡的 API Key 全部換掉。
根據 Railway 的初步報告，這次算是發現得快的，攻擊一開始，內部監控就因為延遲異常呼叫了值班工程師，不到 3 小時就認定是外部攻擊者在想辦法拿更高的權限，先把 Build 停掉，第 15 個小時，Railway 撤銷了已知被入侵系統的存取，但攻擊者還是在接下來兩個小時內拿到 CI 環境的 Credential，用它取得了一部分客戶的環境變數，告警後大約 19 個半小時，Railway 通知 OpenAI、Anthropic、GitHub 等上游供應商撤銷這些 Key，等到內部系統全部換上新的 Credential 重建完，離第一次告警大約一天半左右，我們可以看到，即使是 Railway 的偵測反應非常及時，仍然還是造成了資訊外洩。
flowchart TD
A["0 小時
監控因延遲異常呼叫值班工程師"]
B["3 小時內
認定是外部攻擊，停掉 Build"]
C["約 15 小時
撤銷已知被入侵系統的存取"]
D["15 到 17 小時
攻擊者拿到 CI 環境的 Credential"]
E["17 到 19 小時
確認部分客戶環境變數已被解密"]
F["約 19.5 小時
通知上游供應商撤銷 Key"]
G["38 到 40 小時
換上新 Credential 重建內部系統"]
A --> B --> C --> D --> E --> F --> G
台灣這邊，根據經濟日報轉述 91APP 的調查報告，攻擊者用 AI 自動化滲透工具，從沒更新的 Appsmith 打進內網，再從 GitLab 拿到資料庫金鑰，現場留有 ARTEX 等工具的痕跡，這個攻擊 10 月初就開始了，客戶通報消費者收到詐騙訊息後，91APP 才開始盤查，從攻擊開始到完全阻斷大約花了 11 天半的時間，主管機關數產署後續的行政檢查，重點之一就是異常存取有沒有被即時偵測到。
入侵的當下，誰有權先斷線、先隔離？#
今年 Q3 時，我到一個遭 APT 入侵的組織，協助藍隊分析攻擊者的行為，攻擊者在極短的時間內撈走了大量帳號密碼跟網路架構圖，在會議過程中我發現，客戶最在意兩件事：
- 鑑識能不能找到通報要用的完整資訊
- 評估買一套 SIEM，想看到整體的攻擊面
SIEM 要評估、採購、導入、調規則，通常以月計，它確實能解決下一次看不看得到的問題，但類似的攻擊要怎麼及時擋下來？
NIST 2025 年改版的事件應變指引 SP 800-61r3 寫到，組織如果有事先定好判斷條件跟流程，當下要選擇怎麼隔離、怎麼清除，會比較容易也比較快，同一份文件也要求事先寫清楚，哪些角色有權沒收、斷線或關掉設備。
NIST AI RMF 的治理，搬到 AI 自動化攻擊上怎麼用？#
NIST AI RMF 沒有講怎麼防攻擊者用 AI 打你的公司，可是它處理風險的方式，有幾個概念可以搬過來用：
重估機率：AI RMF 定義的風險，看的是事件發生的機率，跟發生之後影響有多大。以前大量嘗試登入靠的是固定腳本，打進去之後下一步還是要人來判斷，但 ARTEX 打進去之後，下一步由 AI 自己決定、自己呼叫工具，每個對外的服務跟入口點，被打的機率跟被打之後的影響，都要重新評估。
事先授權：AI RMF 的 GOVERN 要治理層定好風險容忍度，哪幾類漏洞（比如已遭利用、PoC 已公開的高風險漏洞）可以不等變更管理流程，直接走緊急修補，哪幾台主機一出現異常就能先隔離再報告，下班時間跟假日由誰判斷，這些都先寫進政策，出事當下就能直接動手，不必等漫長的流程。
量兩個時間差：AI RMF 的 Profile 是把現況跟目標並排，找出中間的差距，把修補時間差跟偵測時間差寫成兩個數字，現況多少、目標多少列進 KPI，每季重算一次，不要只看修補完成率。
技術還沒追上，先從政策補起#
每個月檢查一次更新包、測試完走變更管理才更版，主機要不要隔離等主管開會決定，這套流程是照著攻擊者是人的速度安排的，這個月的案例裡，PHP2Shell 修補還沒出來就有人在打，Langflow 從安全公告到被利用只隔了 9 天，ARTEX 好幾次不到 3 小時就拿到特權，照原本的節奏走，修補跟防禦都會落在攻擊之後。
很多公司已經有偵測機制，但告警響了之後，還是要等人看到、判斷是不是攻擊，才會決定要不要擋下來。就算 Railway 偵測得算快，還是有一部分客戶的環境變數被解開，如果換成發現出事才開始開會決定怎麼處理的公司，應變的時間只會拉得更長，先把哪些漏洞直接走緊急修補、哪些主機一有異常就先隔離、下班時間跟假日由誰判斷寫進政策，請主管事先簽核，再用修補時間差跟偵測時間差兩個數字，每季看一次有沒有縮短。