Microsoft Semantic Kernel(Python)InMemoryVectorStore 篩選條件被當成程式執行

影響範圍

用 pip show semantic-kernel 看版本,再搜尋程式碼裡有沒有 InMemoryVectorStore 或 InMemoryCollection。

原理

Semantic Kernel 讓開發者把「搜尋資料」這類功能包成外掛,交給 AI 模型自己決定何時呼叫、帶什麼參數。問題出在 InMemory 向量資料庫處理「篩選條件」的方式。

舊版把篩選條件組成一段 Python 程式字串(一個 lambda 函式),再交給 Python 執行。當模型替外掛填參數時,模型產生的文字就會被拼進這段程式裡。

有問題的思路(概念示意,不是原始程式碼):

# 模型決定的參數,被直接拼進程式字串
expr = f"lambda record: record.category == '{model_argument}'"
filter_fn = eval(expr)   # 字串變成真的程式

開發者並非沒有防範:舊版會先把字串解析成語法樹,只允許 lambda、擋掉 eval、exec、open 等危險名稱。但 Microsoft 的研究文章指出,黑名單在 Python 這種高度動態的語言裡「本質上很脆弱」:透過物件的內部屬性一層層找,不必寫出任何被擋的名字也能拿到危險功能。1.39.2 起的版本已改成允許清單(只允許特定語法節點與函式呼叫),但沒有限制屬性名稱,所以 1.39.4 以前的版本都仍受影響。

這就是 CWE-94(程式碼產生控制不當):本來只該是「資料」的篩選值,變成了「程式」。而把資料送進來的是 AI 模型,模型又可能被提示注入操控,於是整條鏈變成「一段文字 → 伺服器執行程式」。

另一種設計(寫自己的應用程式時可參考的概念示意,不是 1.39.4 的實際修補):

# 篩選條件用結構化資料表示,不經過 eval
filter_spec = {"field": "category", "op": "eq", "value": model_argument}
results = [r for r in records if getattr(r, filter_spec["field"]) == filter_spec["value"]]

要注意:semantic-kernel 函式庫本身在 1.39.4 仍然用受限制的 eval 執行篩選字串,並沒有改成上面這種做法。1.39.4 的修補是在原有的語法樹檢查(只允許特定節點類型與函式呼叫)之上,再擋下 44 個危險的內部屬性名稱。對自己的程式來說,更根本的原則是:不要讓模型輸出變成可執行的程式碼。

時間軸

延伸閱讀

• 同一篇 Microsoft 研究也揭露了 CVE-2026-25592:可被 AI 呼叫的檔案下載功能,能讓沙箱寫檔到主機。
• 相關弱點類型:CWE-94 程式碼產生控制不當、提示注入(OWASP LLM Top 10 的 LLM01)。
• 評分差異:GitHub / NVD 為 CVSS 9.9 Critical;MSRC 標示為 Important、CWE-749。本頁採用 CNA(GitHub)與 NVD 的評分。