Open WebUI GHSA-9pgh-j74g-qj6m：路徑穿越允許將任意檔案寫至伺服器任意位置
GitHub Advisory Database · 2026-05-08
Open WebUI v0.1.123 及以下版本的 /rag/api/v1/doc 上傳端點存在路徑穿越漏洞（GHSA-9pgh-j74g-qj6m，CVSS 7.3 High），認證使用者可在上傳檔案時透過 ../ 序列將內容寫入伺服器檔案系統的任意位置，已在 v0.1.124 修補。
漏洞機制
問題根源在於 /rag/api/v1/doc 端點直接取用客戶端提供的 filename 參數作為磁碟寫入路徑，未對路徑分隔符號或 .. 序列進行任何正規化或過濾。攻擊者只需在 multipart 表單的 filename 欄位中插入如 ../../../etc/cron.d/backdoor 的路徑，即可將內容寫到任意位置。
漏洞的危害程度取決於伺服器啟動帳號的權限。在以 root 執行的 Docker 容器部署中（Open WebUI 的常見部署方式），此漏洞實際上等同於認證後任意檔案寫入，可透過兩條主要路徑達到遠端程式碼執行：
- Python pickle 注入：上傳包含惡意
__reduce__方法的 pickle 物件至模型載入路徑，觸發反序列化時執行任意命令 - SSH 授權金鑰注入：寫入
/root/.ssh/authorized_keys以獲取免密碼 SSH 存取
受影響版本
- 受影響：Open WebUI ≤ 0.1.123
- 已修補：Open WebUI 0.1.124
- 攻擊前提：需要有效的認證 session（需先登入）
修補與緩解
立即升級至 v0.1.124 是唯一完整修補方式。修補後，伺服器端對 filename 參數進行路徑正規化，確保寫入路徑限制在指定的上傳目錄內。如暫時無法升級，可考慮在 Nginx/Caddy 等反向代理層對 /rag/api/v1/doc 路徑的請求限制為僅限信任來源，或在容器層以非 root 帳號執行 Open WebUI 程序以降低利用後的影響範圍。
Let's Encrypt Generation Y 根憑證交叉簽署缺陷：暫停發憑、回退至 Generation X 根
Let's Encrypt Status · 2026-05-08
2026 年 5 月 8 日 18:37 UTC，Let's Encrypt 發現正在進行中的 Generation Y 根憑證部署存在交叉簽署鏈（cross-signed certificate）缺陷，立即暫停所有採用 tlsserver 與 shortlived ACME 憑證配置的發憑作業，並回退至 Generation X 根憑證，於 21:03 UTC 恢復正常服務，影響窗口約 2.5 小時。
漏洞機制
Let's Encrypt 正在進行根憑證世代交替——Generation X 是現行廣泛信任的根，Generation Y 是新一代根，計劃透過 Generation X 對 Generation Y 進行交叉簽署，使 Generation Y 在尚未被所有作業系統/瀏覽器信任之前仍能建立信任鏈。此次發現的問題出在連接兩個根的交叉簽署憑證本身，具體缺陷內容未公開，但足以令 Let's Encrypt 判斷繼續使用 Generation Y 根發憑不安全。
回退決策影響的是 tlsserver 與 shortlived 兩個 ACME 憑證配置。前者是一般 TLS 伺服器憑證，後者是 ACME 草案規格中的短期憑證（24 小時以內）配置，兩者均已切換回 Generation X 根的發憑鏈。
影響範圍
此事件期間已發出的憑證不受影響——只有 18:37–21:03 UTC 這段時間的新發憑請求會因佇列暫停而延遲，並非憑證本身存在問題。Generation X 根的信任廣泛，所有主流作業系統與瀏覽器均已包含，回退後的憑證在用戶端無任何顯示差異。
Generation Y 根的遷移時程將因此次缺陷而延後，Let's Encrypt 預計在問題確認解決後另行宣布重啟計劃。對持有 Let's Encrypt 憑證的服務而言，無需任何操作；自動化更新（如 certbot、acme.sh）在事件結束後正常執行即可。
free5GC 5G 核心網路多處未認證 API：NEF、SMF、NRF 元件批量漏洞
GitHub Advisory Database · 2026-05-08
2026 年 5 月 8 日，GitHub Advisory Database 集中發布針對 free5GC 開源 5G 核心網路的多個嚴重漏洞，涵蓋 NEF（Network Exposure Function）、SMF（Session Management Function）與 NRF（Network Repository Function）元件，共五個 Critical 與兩個 High 等級的 GHSA 編號，均屬缺少認證中介層導致的未授權 API 存取問題。
漏洞機制
free5GC 各元件暴露 HTTP REST API 以供核心網路元件間通訊，部分端點未實作 OAuth2 Bearer Token 驗證或完全缺少認證中介層：
- GHSA-rwww-x45w-p52w（Critical, NEF）：偽造 bearer token 可讀寫 PFD（Packet Flow Description）管理資料
- GHSA-3258-qmv8-frp3（Critical, SMF）：缺少認證中介層，允許未授權執行拓樸操作
- GHSA-cmpj-2x3g-m7g3（Critical, NEF）：OAM handler 完全未認證，允許無限制存取
- GHSA-3p28-73q7-45xp（Critical, NEF）：3GPP traffic-influence API 端點未設認證
- GHSA-5f62-53r8-qrqf（Critical, NEF）：3GPP PFD management API 端點未設認證
- GHSA-p9mg-74mg-cwwr（High, SMF）：節點刪除操作觸發 nil pointer dereference 導致程序崩潰
- GHSA-f8qv-7x5w-qr48（High, NRF）：OAuth2 token 解析器的型別混淆 panic
受影響版本與修補狀態
這批漏洞影響 free5GC 的多個 Go 元件套件，研究者建議在公開網路環境中部署 free5GC 的組織立即檢查 API 端點的認證設定，並評估是否已套用上游的修補版本。free5GC 主要用於學術研究與電信設備廠商的原型驗證，生產環境部署相對有限，但未授權的 5G 核心網路 API 在測試床環境中同樣構成嚴重的安全風險。