AI再度立功，Claude找出Vim與GNU Emacs的資安漏洞
一句話版本
研究員用 Claude 協助挖到 Vim 的高風險 RCE 漏洞，之後又用類似方法在 GNU Emacs 找到同類問題，代表 AI 已經唔只係幫人寫 code，而係開始明顯加速真實世界漏洞發現。
點解重要
AI 搵漏洞已經由示範階段變成實戰階段：呢單唔係講理論推演，而係真係導向已修補嘅 CVE，同埋有可利用嘅 PoC，表示大型模型已經可以參與有實際安全影響嘅研究流程，我哋唔可以再當佢只係輔助寫腳本嘅工具。門檻被壓低咗：研究員只係靠提示就令模型指出可導致遠端程式碼執行嘅方向，意味住漏洞探索嘅起步成本下降，之後無論係防守方定攻擊方，都更容易快速試探老牌軟體嘅危險邊界。老牌、本地工具一樣係高風險面：Vim 同 Emacs 呢類經典編輯器通常俾人視為穩定成熟，但今次顯示只要涉及開檔、解析內容、外部工具鏈互動，本地工具都可能變成 RCE 載體，唔可以因為「唔係網路服務」就放鬆。開檔即中招嘅情境特別麻煩：文章提到攻擊者只要誘使用戶開啟檔案就可能利用，呢種攻擊模式好貼近日常工作流，對開發者、維運同內容處理人員尤其現實，因為大家本身就會頻繁打開未知來源檔案。漏洞嚴重度會隨認知更新而上升：Vim 呢個問題由初步 8.2 分上修到 9.2 分，反映早期判斷未必捉到完整衝擊；對我哋嚟講，收到初始通報時唔應只睇第一版評分，而要留意後續 re-score 同 exploitability 變化。同一種挖掘方法可以橫向複製：研究員喺 Vim 搵到之後，再用近似做法去 Emacs 搵到類似弱點，說明一旦某種提示策略有效，佢可能可以批量套用喺同類軟體上，形成更快嘅「漏洞家族式」搜尋。供應商回應差異本身就係風險：Vim 團隊即刻出 9.2.0272 修補，GNU Emacs 團隊就將責任歸去 Git 而唔處理，代表同樣類型問題，實際風險唔只取決於漏洞本身，仲取決於維護方肯唔肯承認同修補。責任邊界會變得更模糊：如果一個漏洞牽涉編輯器同外部工具之間嘅互動，維護者可能互相指向對方，呢種情況會拖慢修補，令使用者長時間暴露喺「大家都話唔係自己問題」嘅灰色地帶。公開提示同 PoC 會加速雙向擴散：研究員公開咗提示方式同概念驗證碼，對防守方係學習材料，但同時亦代表其他人可以更快複製研究路線，之後類似產品可能會短時間內迎來更多主動掃描同利用嘗試。AI 對安全團隊嘅價值開始偏向放大器，而唔只係助手：真正值得留意唔係 Claude「自己發現」漏洞，而係研究員用佢快速形成假設、試方向、擴展到第二個目標，呢種放大研究效率嘅模式對攻防兩邊都會持續發酵。
我哋點睇
- 我哋做本地控制系統時，要假設「開一個檔案」都可能係攻擊入口，所以所有會 ingest、解析、預覽、轉換外來內容嘅步驟，都應該當成高風險邊界去設計。
- 對 OpenClaw 呢類單機、資料庫為中心嘅架構，重點唔係追求花巧 AI 自動化，而係用可審計、可重播嘅流程包住 AI 產出；即使模型幫手發現異常，最終都要經 evidence、verification、review 先可以推進狀態。
- 我哋應該主動做一輪「AI 輔助嘅危險路徑盤點」：特別睇檔案接收、內容抽取、外部 CLI 調用、Git/patch 處理同 Slack 輸入轉任務呢幾個位，因為呢啲最似今次事件所反映嘅利用面。