這起事件真正值得警惕的，不只是 Serena 出現一個模板注入漏洞，而是「開啟專案」這個原本偏向讀取資料的動作，已被 AI 程式代理擴張成可能執行程式碼的高權限流程。GitLab 威脅研究團隊指出，攻擊者可把惡意設定藏進程式碼儲存庫；開發者只要透過受影響版本的 Serena 啟用該專案，攻擊程式便可能在代理開始處理第一個模型請求前執行。原始研究見：https://about.gitlab.com/blog/critical-rce-in-serena/
已確認的事件範圍
來源事實：Serena 是在本機執行的 MCP 程式開發工具，替 Claude Code、Cursor、Copilot、Codex 等 AI 助理提供語意導覽、重構與編輯能力。GitHub 官方安全公告把 GHSA-pp25-4cg4-qcr9 標示為 Critical，受影響套件為 serena-agent 1.6.1（含）以前，修補版本是 1.7.0：https://github.com/oraios/serena/security/advisories/GHSA-pp25-4cg4-qcr9
公告於 2026 年 8 月 9 日發布；GitHub 的 1.7.0 發行頁也顯示同日推出：https://github.com/oraios/serena/releases/tag/v1.7.0。截至查核時，官方公告仍寫明沒有已知 CVE 編號，因此不應自行替事件套用尚未核發或無法驗證的編號。
惡意專案如何變成執行入口
來源事實：攻擊鏈起點是儲存庫內的 .serena/project.yml。其中的 added_modes 可以指向另一份 YAML 模式檔；Serena 載入該檔案後，會取出 prompt 欄位，當成 Jinja2 模板建立系統提示。問題在於受影響版本採用一般的 jinja2.Environment()，而非限制物件屬性與方法存取的沙箱環境。
這裡有兩個容易混淆的層次。第一，yaml.safe_load 可以防範危險的 YAML 反序列化，卻不能阻止某個普通字串稍後被當成模板執行。第二，Serena 原有的 trusted_project_path_patterns 會攔截明顯具執行能力的 activation_command，但模式載入與提示渲染走的是另一條未套用信任檢查的路徑。因此，即使設定成沒有任何受信任專案，研究人員仍能觸發模板注入。
Jinja 官方文件確認，SandboxedEnvironment 是為渲染不可信模板而設計，可攔截不安全的屬性、方法與運算；這與 Serena 1.7.0 的修補方向一致：https://jinja.palletsprojects.com/en/stable/sandbox/
為什麼這比傳統專案檔攻擊更值得注意
合理推論：傳統 IDE 也曾面對工作區設定、建置腳本與外掛造成的專案型攻擊，但 MCP 程式代理往往同時接觸檔案系統、Shell、語言伺服器與其他開發工具。若 Serena 行程遭控制，程式碼會繼承啟動 Serena 的使用者權限；開發者帳號可讀取的 SSH 金鑰、雲端憑證、環境變數、內部原始碼與企業網路資源，都可能進入風險範圍。
不過，「可能接觸」不等於已經外洩。現有公告證明的是任意程式碼執行能力，並未證明已有大規模利用、特定台灣組織受害，或每台電腦都存有上述敏感資料。實際衝擊仍取決於 Serena 的版本、執行身分、主機憑證配置及網路權限。
「只要打開」仍有必要條件
限制釐清：使用者並非單純瀏覽 GitHub 網頁、下載 ZIP 或用檔案總管開啟目錄就必然中招。攻擊者必須先讓惡意檔案進入儲存庫，而受害者還要以 1.6.1 或更早版本的 Serena 啟用該專案。官方公告表示，在預設 LSP 後端及 desktop-app 情境下，觸發後不需要額外網路連線、認證或模型工具呼叫；這才是「開啟專案即執行」最精確的意思。
此外，改用 Jinja 沙箱是必要修補，卻不代表整個工具從此沒有風險。Jinja 官方明確提醒，沙箱不是完美安全邊界，惡意模板仍可能造成大量輸出、CPU 或記憶體消耗，應搭配資源限制，且只把必要資料交給模板。
對台灣開發團隊的實際意義
作者觀點：台灣軟體團隊常同時處理開源套件評估、客戶交付程式、外包商分支、求職作業與資安競賽題目；這些正是「程式碼看似可讀，專案設定卻由外部作者控制」的場景。治理重點不應只問 AI 模型會不會產生危險指令，而要把 MCP 伺服器視為本機高權限開發工具，納入軟體資產盤點、版本管理與端點隔離。
MCP 的 SEP-1024 已要求一鍵安裝本機伺服器時顯示完整命令並取得明確同意：https://modelcontextprotocol.io/seps/1024-mcp-client-security-requirements-for-local-server-。但 Serena 事件發生在工具已安裝、開始處理專案之後，證明「安裝時同意」不能取代每次跨越專案信任邊界時的檢查。
現在應做的事與後續指標
- 立即盤點 Serena 實際執行版本，將 1.6.1（含）以前升級至 1.7.0 或更新版本；在完成升級前，不要以 Serena 啟用來源不明的儲存庫。
- 檢查近期取得的專案是否包含
.serena/project.yml、可疑的added_modes路徑及陌生模式檔；這些是調查線索，不代表看到檔案就等同遭入侵。 - 若曾用受影響版本開啟不可信專案，依主機暴露面檢視 Serena 及其子行程、異常外連、憑證存取與檔案變更；有具體異常時再撤銷相關 SSH、雲端或套件倉庫憑證。
- 企業應限制開發工具可取得的長效憑證，並考慮在容器、虛擬機或權限較低的環境評估陌生專案。
- 後續觀察官方公告是否補上 CVE、是否擴大受影響版本或提出更多修補，以及其他 MCP 工具是否存在同類的「專案設定進入模板、命令、外掛或動態載入」路徑。
這起漏洞的核心教訓是：AI 代理並沒有創造全新的模板注入原理，卻把老漏洞接上更寬廣的本機權限。未來真正有效的防線，不只是提醒開發者小心陌生程式碼，而是讓任何由儲存庫控制的內容，在進入模板、命令或載入器之前，都必須重新通過同一套信任判斷。