Apache APISIX jwe-decrypt 外掛完整性校驗缺陷導致身份驗證繞過（CVE-2026-49230）
Openwall OSS Security · 2026-06-19
2026 年 6 月 19 日，Apache APISIX 安全團隊透過 oss-security 郵件清單披露漏洞 CVE-2026-49230，涉及 jwe-decrypt 外掛在預設組態下的完整性校驗邏輯缺陷。受影響版本橫跨 Apache APISIX 3.8.0 至 3.16.0，攻擊者可在不持有合法金鑰的情況下繞過驗證，使未授權請求被轉發至後端服務。官方修復版本為 3.17.0，已於同日釋出。
jwe-decrypt 外掛的工作原理
jwe-decrypt 外掛負責在請求進入 APISIX Route 或 Service 之前，對請求頭中的 JWE（JSON Web Encryption，RFC 7516）令牌進行解密與驗證。JWE 令牌採用五段結構：Base64url 編碼的標頭、加密金鑰（對稱加密時留空）、初始向量（IV）、密文，以及認證標籤（Authentication Tag）。標頭中的 kid（Key ID）欄位指定使用哪個 Consumer 的 32 字元 AES-256-GCM 對稱共享金鑰進行解密。
AES-256-GCM 是同時提供加密與驗證的 AEAD（Authenticated Encryption with Associated Data）模式，其安全性同等依賴加密機密性與 Authentication Tag 的完整性驗證。若認證標籤的校驗邏輯可被規避，攻擊者即使不知道正確的共享金鑰，也能讓外掛接受偽造的 JWE 令牌並視之為合法身份。外掛的 strict 參數（預設啟用）僅能拒絕缺少令牌的請求，無法阻擋結構完整但內容偽造的令牌。
漏洞機制
根據 oss-security 披露，此漏洞被歸類為「Improper Validation of Integrity Check Value」，存在於外掛的預設組態下。核心缺陷在於 AES-256-GCM 認證標籤的比對邏輯實作有誤，導致攻擊者可構造特製的惡意 JWE 令牌通過校驗。具體而言，當攻擊者送出一個標頭格式正確（包含合法 Consumer 的 kid）但密文或認證標籤被篡改的 JWE 時，外掛在不完整的完整性驗證下依然接受該令牌，最終將請求轉發至後端，並附帶被解密（或錯誤解密）的 payload 內容。
此攻擊路徑無需攻擊者掌握任何 Consumer 的共享金鑰，僅需知道任意一個合法 Consumer 的 kid 值（此值通常記錄在路由組態或開發文件中）即可構造繞過。漏洞由資安研究員 lokerxxx 發現並依負責任披露流程向 Apache 安全團隊回報。
受影響版本
- Apache APISIX
3.8.0（含）至3.16.0（含） - 所有在上述版本範圍內啟用 jwe-decrypt 外掛的部署均受影響
- Apache APISIX
3.17.0已修復，不受影響
修補與緩解
官方修補措施為升級至 Apache APISIX 3.17.0，該版本修正了 jwe-decrypt 外掛的完整性校驗邏輯，確保 AES-256-GCM 認證標籤的驗證正確執行且無法被規避。
對於無法立即升級的部署，可考慮下列緩解措施：
- 暫時停用 jwe-decrypt 外掛，改採 jwt-auth 或 key-auth 等其他驗證外掛
- 在 APISIX 前端部署額外的網路層存取控制，限制外部請求直接觸達受外掛保護的路由
- 啟用請求日誌並監控異常的身份驗證模式，以偵測潛在的繞過嘗試
- 將 jwe-decrypt 保護的路由限制為僅接受來自可信 IP 範圍的請求
鑑於身份驗證繞過漏洞可在無憑證的情況下完全失效保護機制，任何在生產環境中使用 jwe-decrypt 外掛的 APISIX 部署應將本次修補列為緊急項目，優先排入升級計畫。
SurrealDB JWKS 獲取器跟隨重新導向繞過網路能力控制形成 SSRF（GHSA-h5rg-8p7f-47g2）
GitHub Security Advisories · 2026-06-19
2026 年 6 月 19 日，SurrealDB 發布安全公告 GHSA-h5rg-8p7f-47g2，揭露 JWT 存取方法的 JWKS 金鑰獲取邏輯存在伺服端請求偽造（SSRF）漏洞。受影響版本為 SurrealDB 3.1.5 以前的所有版本，問題根源在於 core/src/iam/jwks.rs 中使用的裸 reqwest 客戶端會自動跟隨 HTTP 重新導向，而不對重新導向目標重新執行網路能力校驗。CVSS v3.1 評分為 4.1（Moderate），向量字串為 CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N。
漏洞機制
當使用者透過 DEFINE ACCESS ... TYPE JWT URL 或 TYPE RECORD ... WITH JWT URL 語法設定 JWT 存取方法時，SurrealDB 需從指定的 URL 獲取 JWKS（JSON Web Key Set）文件以驗證 JWT 簽名。JWKS 獲取器使用的裸 reqwest 客戶端預設自動跟隨 HTTP 3xx 重新導向，而 SurrealDB 的網路能力控制機制（--allow-net / --deny-net）僅在初始請求發出前對原始 URL 執行一次校驗。一旦伺服器回傳 3xx 回應，reqwest 自動跟隨至新目標，不再觸發能力校驗。
擁有 Owner 角色（資料庫層級或以上）的攻擊者，可將 JWKS 端點設於合法允許清單中的主機，再讓該主機回傳重新導向至受 --deny-net 封鎖的內部目標，例如 AWS EC2 後設資料端點（169.254.169.254）、回環地址（loopback）或內部網路服務，從而探測網路拓樸。值得注意的對比是：SurrealDB 用於 HTTP 函式的 HttpClient 在 3.1.0 版本中已針對同類問題加固，每次重新導向都會重新執行能力校驗，但 JWKS 獲取器未獲得相同保護，形成安全不一致性。
此漏洞的實際影響受到多重技術限制：JWKS 獲取為盲探操作——伺服器僅嘗試解析回應為 JWKS 格式，非 JWKS 回應只會得到不透明的 InvalidAuth 錯誤，攻擊者無法讀取回應內容。請求逾時強制限制為 1 秒，攻擊者只能透過計時側通道（timing side-channel）推斷目標主機是否存在，無法讀取任何資料、修改狀態或影響可用性。
受影響版本
- SurrealDB
3.1.5以前的所有版本均受影響 - SurrealDB
3.1.5（含）以上已修復 - 攻擊需要資料庫層級或以上的 Owner 角色，屬高權限（PR:H）場景
修補與緩解
官方修補措施於 3.1.5 版本中為 JWKS 獲取器實作了重新導向策略（redirect policy），對每個重新導向目標重新執行網路能力校驗，並強制套用 max_http_redirects 上限，與 3.1.0 版本中加固的 HttpClient 行為對齊。
對於無法立即升級的部署，可採取以下緩解措施：
- 將 Owner 角色的授予嚴格限制在高度信任的操作人員
- 在網路層部署出口過濾，封鎖 SurrealDB 進程對 RFC 1918 私有地址及
169.254.0.0/16鏈路本地地址的存取 - 確保 JWKS 端點使用不會產生重新導向的可信主機，或改用本地金鑰定義（local key definition）代替遠端 JWKS URL
LangSmith SDK TracingMiddleware 標頭注入與型別混淆組合導致任意伺服端檔案讀取（GHSA-f4xh-w4cj-qxq8）
GitHub Security Advisories · 2026-06-19
2026 年 6 月 19 日，LangChain 安全團隊披露 LangSmith SDK 的 TracingMiddleware 元件存在任意伺服端檔案讀取漏洞，公告編號為 GHSA-f4xh-w4cj-qxq8。受影響版本為 langsmith Python SDK 0.8.18 以前的所有版本，漏洞由追蹤傳播標頭注入與型別檢查守衛失效兩個缺陷組合觸發，CVSS v3.1 評分為 7.7（High），向量字串為 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N，已於 0.8.18 修復。
漏洞機制
此漏洞由兩個獨立缺陷疊加觸發，缺一不可。第一個缺陷為追蹤傳播標頭注入（CWE-346，Origin Validation Error）：TracingMiddleware 處理請求時，會讀取特定的追蹤傳播標頭（tracing-propagation header）並將其中的欄位合併至執行記錄（run object）中，而合併過程缺乏必要的輸入驗證。攻擊者可透過惡意標頭注入附件（attachments）相關的 run 屬性，包含指向伺服器本地任意路徑的參數值。
第二個缺陷為型別混淆（CWE-843，Type Confusion）：程式碼中設有一道型別檢查守衛（type check guard），其設計意圖是阻止非預期的檔案系統存取。然而此守衛對「解碼後輸入」的型別判斷存在錯誤——標頭解碼後的資料型別與守衛所預期比對的型別不符，導致安全檢查從未被觸發（guard never engaged）。兩個缺陷組合後，後台追蹤執行緒（background tracing thread）依攻擊者指定的路徑開啟伺服器上的本地檔案，並將其內容作為追蹤附件（trace attachment）上傳至 LangSmith 服務，完成資料竊取。
整個攻擊流程不需要使用者互動（UI:N），且影響範圍越界（S:C，Scope Changed）——攻擊者藉由 TracingMiddleware 存取超出元件本身權限邊界的伺服器檔案系統資源。可讀取的檔案範圍取決於執行 LangSmith SDK 服務的作業系統進程權限，若服務以高權限或 root 執行，攻擊面顯著擴大，理論上可存取 /etc/passwd、私鑰、環境變數檔案等敏感資料。
利用條件的限制
成功完整利用此漏洞需滿足特定前提：攻擊者必須能向啟用 TracingMiddleware 的 HTTP 端點發送請求（網路可達，AV:N），並需具備工作區追蹤讀取（workspace trace-read）權限，才能從 LangSmith 服務取回已上傳的附件內容。若攻擊者僅能發送惡意請求，卻無法讀取工作區的追蹤記錄，則竊取的檔案內容無法被取得，降低了純外部攻擊者在黑盒環境下的完整利用難度。
然而對於具備工作區追蹤讀取權限的惡意內部人員，或通過帳號入侵取得對應存取權限的攻擊者，此漏洞危害仍然顯著。CVSS 要求的權限等級為低（PR:L），意味任何具有基本工作區存取的成員理論上均有觸發條件，無需管理員權限。
受影響版本
- langsmith Python SDK
0.8.18以前的所有版本均受影響 - langsmith
0.8.18（含）以上已修復 - CWE 分類：
CWE-22（路徑遍歷）、CWE-346（來源驗證錯誤）、CWE-843（型別混淆）
修補與緩解
官方建議立即升級至 langsmith 0.8.18。此版本修正了追蹤傳播標頭的輸入驗證邏輯，確保外部提供的欄位無法注入附件屬性；同時修復了型別檢查守衛的型別比對邏輯，使其能正確攔截解碼輸入中的非預期型別，令守衛在所有預期路徑下均正確生效。
對於無法立即升級的部署，可採取以下緩解措施：
- 限制 TracingMiddleware 僅接受來自可信內部服務的 HTTP 請求，不應暴露於未認證的外部網路
- 在應用層或反向代理層過濾並移除追蹤傳播相關的 HTTP 標頭（如
traceparent、tracestate及各框架的自訂傳播標頭） - 以最小權限原則執行 LangSmith SDK 服務，嚴格限制進程可讀取的檔案系統路徑（例如透過 systemd 的
ReadOnlyPaths=或容器檔案系統隔離） - 審計工作區的追蹤讀取權限，撤銷非必要的存取授權以降低竊取資料被取得的風險
原始來源：GitHub Advisory GHSA-f4xh-w4cj-qxq8、LangSmith SDK 官方安全公告