實證研究 發布於 AIA: 2026年8月5日

Pydantic AI SSRF 漏洞：訊息歷史紀錄竟成為伺服器端請求的出站權限

CVE-2026-25580 允許攻擊者透過未受信任的 Pydantic AI 訊息歷史 (message history) 與 URL 附件，誘使應用程式伺服器發起連線至攻擊者指定的目標位址。惡意構造的 URL 可連至內部服務、Link-local 區域連線的雲端中繼資料服務 (IMDS)，或外部呼叫端無法直接觸及的私有系統。隨後發現的兩項 IPv6 轉換型位址繞過漏洞，則影響主動開啟本機下載權限的應用。此案例證明：當還原序列化對話會觸發伺服器端 I/O 時，訊息歷史便已具備主動輸入的攻擊屬性。

Data ExfiltrationInput ValidationAgentic AIWeb Security
4 項對應的 AIDEFEND 防禦手法
來源: Server-Side Request Forgery (SSRF) in URL Download Handling 
作者: Douwe Maan
原文發布: 2026年2月6日

威脅分析

  • 主動觸發攻擊的輸入源為可重新載入的對話物件 (message history)。 應用程式接收未經信任的訊息歷史時，可能包含以 URL 形式呈現的圖片、音訊、影片或文件。Pydantic AI 內建的 download_item() 函式隨即利用伺服器本身的網路權限連線下載該 URL。
  • 原始 SSRF 漏洞的前提為攻擊者能控制訊息歷史或 URL 欄位。 惡意檔案 URL 能指向 localhost (127.0.0.1)、私有網域服務或雲端中繼資料 (IMDS)。僅採用寫死 (hardcoded) URL 的應用不受此路徑影響。官方於 1.56.0 版本加入了 Scheme、IP 位址、DNS 解析與重新導向 (Redirect) 的嚴格校驗。
  • 後續兩項繞過漏洞的攻擊條件較為侷限。 CVE-2026-46678 與 CVE-2026-48782 利用了 IPv6 轉換型位址形式，但僅在應用程式明確對外部輸入傳入 force_download='allow-local' 設定時方可成立。預設的內建 Adapter 並未開啟該選項，且部分形式尚需網路具備 NAT64 或 ISATAP 路由支援。官方修復版本依序為 1.99.0、1.102.0 與 2.0.0b3。
  • 資安通告證明了漏洞攻擊可行性，而非已發生的真實入侵。 目前尚無公開證據顯示上述 SSRF 攻擊路徑已被用於實際惡意活動。

適用的 4 項 AIDEFEND 防禦手法

AID-H-003.010
Deployed AI Software Vulnerability Remediation Lifecycle
極高
將所有應用程式實際執行中的 Pydantic AI 套件版本與三份 CVE 漏洞通告進行全面校驗，以最新支援版本重新建置並實施分階段部署，最後回檢所有執行個體以確認舊版套件與容器映像檔已全數下線。切勿止步於 1.56.0 版，以免暴露於後續的 IPv6 轉換型位址繞過風險。
AID-H-019.001
URL Normalization & Allowlist Filtering
極高
伺服器連線抓取訊息歷史中的任何 URL 前，必須先執行正規化 (Normalization)、解析並固定連線目標 IP (IP Pinning)，一律拒絕 RFC1918 私有網段、Loopback、Link-local、雲端 metadata 及 IPv6 轉換型網段，嚴密校驗每次重新導向，並從同一條已驗證的 Socket 連線讀取位元組。此為阻擋原始 SSRF 及解析器差異繞過的直接防禦控制。
AID-I-002.002
Secure External AI Service Connectivity
高
將應用程式工作負載的對外連線預設全部阻擋，只允許通過已驗證 DNS 與 SNI 規則、且指向核准外部服務的連線，並明確阻擋雲端 metadata 路由。當應用層驗證遭繞過時，這道網路邊界仍能獨立阻擋；不過，它無法判斷某個核准的公開 URL 是否符合業務語意。
AID-H-002.002
Inference-Time Prompt & Input Validation
中
在應用程式入口處驗證外部訊息歷史的 schema 結構，僅允許業務必需的 URL 欄位型態，阻擋未預期欄位，並嚴禁外部呼叫端指定 force_download 或同等的本機抓取例外權限。此舉能移除序列化請求中的危險權限；但格式正確的 URL 仍需交由 AID-H-019.001 執行專用安全抓取檢查。

身為資安防禦者，我們應該這麼做

  • 全面升級 Web 介面、AG-UI、Vercel AI 及自訂 Adapter 部署中的 pydantic-ai 與 pydantic-ai-slim 套件至目前支援版本。實地確認實際執行中的套件版本與容器映像檔雜湊值 (image digest)，而非僅查看 lockfile。
  • 全面清查所有接收序列化訊息歷史或 URL 附件的 API 端點。嚴禁允許外部呼叫端控制 force_download、allow-local 或同等的安全政策覆寫參數。
  • 針對 Loopback、RFC1918 私有網段、Link-local 雲端 metadata、IPv4-mapped IPv6、6to4、NAT64、ISATAP、DNS Rebinding 及重新導向鏈執行 SSRF 安全抓取測試，確保「檢查合格的 IP」與「實際連線發起的 IP」完全一致。
  • 在工作負載層級，將對外連線預設全部阻擋，並一律拒絕連往雲端 metadata (如 169.254.169.254) 的路由；符合條件的對外連線應盡可能透過受控的 Proxy 代理伺服器發起。
  • 排查對外連線與雲端中繼資料服務日誌。僅在有明確證據顯示特定機密憑證 (secrets) 確實出現在 SSRF 回應並暴露時，才進行憑證輪替 (Rotate)；單純存在 SSRF 漏洞風險不等於憑證已外洩。

結論

這個案例劃出的關鍵資安邊界，不在於「文字對話與檔案上傳」的區別，而在於未經信任的對話資料能否驅動伺服器運用自身的網路權限發起對外 I/O。團隊可參考 AIDEFEND  對應的防禦手法，升級至最新支援版本以修補漏洞、嚴格驗證訊息 schema、建立具備 SSRF 防護的 URL 抓取機制，並從應用層外部強制執行對外連線政策。只要重新載入與執行對話紀錄會引發抓取、開啟、執行或觸發外部動作，就必須將訊息歷史視為主動的攻擊輸入源。