觀點 · 資訊分享
Pydantic AI 1.102.0 補上 SSRF 防護缺口：開了 allow-local 的專案要更新
AI 代理框架 Pydantic AI 發布 1.102.0，補上雲端中繼資料封鎖清單的繞過問題：只有在把網址設成允許本機存取、且網路會轉送特定 IPv6 轉換格式時才受影響。官方給的 CVSS 是 6.8（中度）。
- 發布
- 2026-05-24
- 篇幅
- 約 4 分鐘 · 1,829 字
- 結構
- 7 節 + 3 題常見問題
- 標籤
一句話看懂：Pydantic AI 1.102.0 補上一個 SSRF 防護缺口，只有主動開了 allow-local 的專案才會受影響，官方評為中度。
先用白話講：這個防護在擋什麼？
想像你家有一位助理，幫你去網路上抓檔案。你交代：「不要去碰公司內部的保險庫。」助理就有一張「禁止地址清單」，看到保險庫的地址就不去。
問題是，同一個地址可以用好幾種「寫法」，清單只認其中幾種，其他寫法就會漏掉。這次修的就是這個：清單漏掉了幾種 IPv6 的寫法，雲端主機上放著暫時性憑證的「中繼資料位址」就可能被繞過去連到。
Pydantic AI 是常見的 Python AI 代理框架。這個防護，是它預設會擋掉對內部位址的請求。
發生什麼事
Pydantic AI 在 2026 年 5 月 23 日發布 1.102.0，並同步公開 GitHub 安全公告 GHSA-cg7w-rg45-pc59（SSRF 雲端中繼資料封鎖清單，透過額外的 IPv6 轉換格式被繞過），官方評為中度，CVSS 3.1 為 6.8。
官方列出的必要條件很窄：
- 應用程式主動把某個網址設為允許本機存取：
FileUrl（含ImageUrl、AudioUrl等）設force_download='allow-local'，或web_fetch_tool(allow_local_urls=True)，這兩個預設都是關的 - 這個網址可能受不受信任的輸入影響
- 網路真的會轉送這些 IPv6 格式：NAT64 設定的網路（部分 IPv6-only 或雙堆疊加 NAT64 的 Kubernetes 環境）或有 ISATAP 通道的網路
標準雙堆疊的雲端虛擬機或容器，實務上不會轉送這些格式，不受影響。
受影響範圍
| 套件 | 受影響版本 | 修正版本 |
|---|---|---|
| pydantic-ai、pydantic-ai-slim | 1.56.0 到 1.102.0 之前 | 1.102.0 |
| 同上（2.0 beta） | 2.0.0b1 到 2.0.0b3 之前 | 2.0.0b3 |
官方也說明，用內建整合（Agent.to_web、clai web、VercelAIAdapter、AGUIAdapter）接收使用者輸入的專案不受影響。
給開發者的技術細節
- 這是前一次修補（GHSA-cqp8-fcvh-x7r3 / CVE-2026-46678）的補強：前一次只解碼了 IPv4-mapped IPv6、6to4 與 NAT64 的標準前綴；這次補上 IPv4-compatible、NAT64 的本地用前綴、營運者自選的 NAT64 前綴，以及 ISATAP
- 同版的其他修正：Bedrock 不再把
strict=None的工具自動升為嚴格模式；停用 Bedrock 上 Opus 4.7 的原生結構化輸出；VercelAIAdapter接受動態工具訊息部件的providerExecuted與title；WebFetchTool的網域比對會正規化結尾的點與大小寫 - 檢查方式：在程式碼裡搜尋
allow-local與allow_local_urls，沒有就不是這個漏洞的受害條件
我的看法
這個漏洞看起來條件很多，但值得學的是它的模式：「封鎖清單」永遠追不完各種變體。要擋 SSRF，最穩的還是白名單，只允許已知的網域；真的要碰內部網路，就在網路層（防火牆、安全群組）擋住中繼資料位址，不要只靠應用程式的檢查。
另外，AI 代理框架讓模型自己決定要抓哪個網址，風險比一般程式高，因為網址來源其實是模型的輸出，而模型的輸入可能受到外部內容影響。如果你的專案有開 allow_local_urls，建議重新檢查是不是真的需要。
名詞小辭典
- SSRF：讓伺服器替攻擊者去連原本連不到的內部網址。
- 雲端中繼資料服務：雲端主機內部用來取得自己的設定與暫時憑證的位址。
- NAT64 / ISATAP：讓 IPv6 與 IPv4 網路互通的轉換技術。
- CVSS：替漏洞嚴重程度打分數的標準，滿分 10 分。