2026-07-03 — Steeltoe 與 SimpleSAMLphp 齊爆多則 CVE，Apache HttpComponents HTTP/2 解碼器現記憶體耗盡漏洞

Steeltoe .NET 微服務框架一次揭露 7 個安全公告，含 TLS 私鑰外洩與 OAEP 加密降級

GitHub Advisory Database · 2026-07-02

.NET 微服務框架 Steeltoe 在 2026 年 7 月 2 日一口氣公開了 7 則安全公告，涵蓋 TLS 私鑰外洩、加密演算法選擇錯誤、Eureka 服務註冊表污染、Actuator 權限控管失效等問題。Steeltoe 是 Pivotal（現屬 Broadcom）主導的開源專案，替 .NET 應用程式提供 Cloud Foundry 服務綁定、Spring Cloud 相容的服務發現（Eureka）、組態加密與 Actuator 監控端點，廣泛用於企業將 .NET 系統遷移到雲端微服務架構的場景。這批公告的 CVE 皆標示為 2026 年 5 月 29 日建立，此次是集中對外揭露，受影響版本集中在 Steeltoe 3.x 與 4.0.0–4.1.0 系列。

漏洞機制

最嚴重的一則是 GHSA-rxrh-4j9h-xgg9（CVE-2026-50267）：Steeltoe Connectors 在處理 MySQL／PostgreSQL 的 Cloud Foundry 服務綁定時，會用 File.CreateText 把 TLS 用戶端私鑰寫進 Path.GetTempPath()，在 Linux 上檔案權限是 世界可讀的 0644，且永遠不會被刪除；相對地，同一份資料在 /proc/<pid>/environ 中卻正確保護在 0400。這代表在 Cloud Foundry 上與該應用同機、以不同 UID 執行的其他行程，可以直接讀走私鑰去冒充應用程式建立資料庫連線。

另一則有趣的是 GHSA-4j9m-h44m-2hv8（CVE-2026-50268）：Steeltoe 組態加密模組原意是讓使用者透過 encrypt:rsa:algorithm=OAEP 啟用 OAEP 填充（一種比傳統 PKCS#1 v1.5 更能抵抗選擇密文攻擊的 RSA 填充方案），但因為 BouncyCastle 的轉換字串寫錯，實際上仍然套用 PKCS#1 v1.5，等同該設定完全沒生效，一旦解密功能被暴露在信任邊界之外，就有遭受 Bleichenbacher 類型攻擊的風險。

服務發現方面，GHSA-j8ph-6fxj-g533（CVE-2026-50196）指出 Steeltoe.Discovery.Eureka 的 DataCenterInfo.FromJson 只認得 "MyOwn" 與 "Amazon" 兩種資料中心名稱，一旦遇到 Java Eureka 規格中合法但 Steeltoe 未實作的 "Netflix" 就會丟例外，且該例外會被吞掉，導致整個服務登錄表被單一異常註冊搞到永久清空或過期，等於任何一個用戶端註冊一筆非預期的資料中心名稱，就能讓所有連到同一 Eureka 的 Steeltoe 用戶端服務發現全部失效。

其餘四則同樣值得留意：GHSA-7fqc-p256-7pwj（CVE-2026-50202）的 TokenKeyResolver 只用 JWT 的 kid 當快取鍵、不區分授權來源也不設過期時間，多身分提供者情境下可能被跨 Scheme 偽造簽章金鑰接受，撤銷或輪替的金鑰也會一直被信任到應用重啟；GHSA-227r-jm2g-7cp4（CVE-2026-50201）讓 heapdump／env／thread dump 這類敏感 Actuator 只需要 EndpointPermissions.Restricted 就能存取，繞過了 Cloud Foundry 原本設計來管控敏感端點的 read_sensitive_data 權限；GHSA-q62h-354g-5r85（CVE-2026-50200）的環境變數過濾器只比對 password、secret 等字尾，漏掉 ConnectionStrings:<name> 這類 .NET 慣用命名，導致內嵌在連線字串裡的資料庫密碼透過 /actuator/env 直接外洩；GHSA-58f6-6rj2-3v8r（CVE-2026-50194）則是管理端點中介軟體只靠 HTTP Host 標頭而非實際連線埠來判斷是否為受隔離的管理埠，攻擊者偽造 Host 標頭即可繞過埠隔離直接打到未驗證的 Actuator。

受影響版本

• Steeltoe.Configuration.Abstractions：≥4.0.0，≤4.1.0（私鑰外洩）
• Steeltoe.Configuration.Encryption：≥4.0.0，≤4.1.0（OAEP 降級）
• Steeltoe.Discovery.Eureka：≥4.0.0 且 ≤4.1.0；以及 ≤3.3.0（Eureka 污染）
• Steeltoe.Security.Authentication.CloudFoundryBase（≤3.3.0）、Steeltoe.Security.Authentication.JwtBearer／OpenIdConnect（均 ≤4.1.0）（JWKS 快取）
• Steeltoe.Management.Endpoint（≤4.1.0）與 Steeltoe.Management.EndpointBase／EndpointCore（≤3.3.0，其中管理埠繞過另涉及 ≥3.2.2）

修補與緩解

7 則公告的修補版本集中在同一批次釋出：3.x 系列一律升級到 3.4.0，4.x 系列一律升級到 4.2.0。由於這些問題散落在 Connectors、Encryption、Discovery.Eureka、Security.Authentication 與 Management.Endpoint 五個不同套件，使用 Steeltoe 的團隊需要逐一檢查專案實際引用了哪些套件並個別升級，單純升級單一套件並不會涵蓋其餘六個問題。

對於還無法立即升級的環境，可先個別緩解：確認部署環境未設定 encrypt:rsa:algorithm=OAEP 卻誤以為已生效；檢查 Actuator 是否對外暴露、必要時以額外的反向代理規則限制存取來源而非只依賴 Host 標頭；以及定期清理 /tmp 下的憑證暫存檔。

原始來源：GHSA-rxrh-4j9h-xgg9、GHSA-4j9m-h44m-2hv8、GHSA-j8ph-6fxj-g533、GHSA-7fqc-p256-7pwj、GHSA-227r-jm2g-7cp4、GHSA-q62h-354g-5r85、GHSA-58f6-6rj2-3v8r

SimpleSAMLphp 連發三則公告：跨 IdP 驗證繞過、XPath Transform 阻斷服務與 TLS 驗證邏輯混淆

GitHub Advisory Database · 2026-07-02

SimpleSAMLphp 是一套廣泛部署的開源 SAML 2.0 身分識別提供者（IdP）與服務提供者（SP）函式庫，許多學術聯盟（如 eduGAIN）、企業 SSO 都以它作為聯合身分驗證的實作基礎。2026 年 7 月 2 日，GitHub Advisory Database 揭露了三則與 SimpleSAMLphp 及其底層 simplesamlphp/saml2 套件相關的公告，全部圍繞在 SAML 協定中最容易出錯的環節：簽章驗證的邊界條件與訊息完整性檢查。三個 CVE 均標示為 2026 年 5 月 29 日建立，此次一併對外發布。

漏洞機制

影響最直接的是 GHSA-6929-8p9f-26jx（CVE-2026-49283）：HTTP-Artifact 綁定流程中，SOAPClient::validateSSL() 在 TLS 公鑰不匹配時竟然正常返回而非丟出例外，而 SAML2\Message::validate() 又把「沒有例外」直接當成「驗證成功」。串起來的結果是：攻擊者能讓來自某個 IdP 的合法 ArtifactResponse，被拿去驗證一個聲稱來自「另一個」IdP、且本身未簽章的回應，形成跨 IdP 的身分驗證繞過。這類問題屬於 SAML 生態中經典的一類漏洞——XML 簽章驗證與訊息來源綁定沒有正確地互相制約。

GHSA-q8r6-xj3f-wrrm（CVE-2026-49284）則出在多 IdP 部署場景：當一個未簽章的 Response/@InResponseTo 搭配一個「已簽章但簽章範圍不包含 SubjectConfirmationData/InResponseTo」的 Assertion 一起送到 SP 時，程式只記錄警告訊息，卻繼續往下處理，而不是直接拒絕。結果是信任等級較低的 IdP 可以冒充成 SP 原本預期的另一個 IdP，滿足原本應該只有特定 IdP 才能滿足的登入狀態。

第三則 GHSA-5cjr-mxj5-wmrx（CVE-2026-49289）走的是資源耗盡路線：SAML 訊息中的 XML 簽章允許附加 XPath Transform，用來指定簽章實際涵蓋文件中的哪一段內容，但 SimpleSAMLphp 對 Transform 的數量與型別沒有限制，構造惡意的巢狀或大量 XPath Transform 可以讓解析端耗費大量運算資源做 DoS 攻擊。修補方式是直接把允許的 Transform 數量限制在 SAML 2.0 Core 規格明確列出的範圍內，並明確拒絕 XPath Transform本身，而不是嘗試把它解析得更快。

受影響版本

• simplesamlphp/simplesamlphp：≥2.5.0 且 ≤2.5.1；以及 ≤2.4.6（IdP 回應驗證問題）
• simplesamlphp/saml2：≥6.0.0 且 <6.2.1；≥5.0.0 且 <5.0.6；以及 <4.20.2（TLS 驗證邏輯混淆）
• simplesamlphp/saml2 與 simplesamlphp/saml2-legacy：均 ≤4.20.2（XPath Transform DoS）

修補與緩解

三則修補版本分別為：simplesamlphp/simplesamlphp 升級到 2.5.2 或 2.4.7；simplesamlphp/saml2 依所在分支升級到 6.2.1、5.0.6 或 4.20.2；XPath Transform DoS 則修補於 saml2 與 saml2-legacy 的 4.20.3。由於 simplesamlphp/simplesamlphp 本身依賴 saml2 套件，維運團隊升級時應同時確認兩個套件版本是否都落在修補範圍內，單獨升級其中一個可能仍留下另一個問題。

多 IdP 聯合部署（例如同時信任多個機構的 IdP）風險相對較高，因為三則漏洞的共通條件都涉及「系統中存在一個以上可被信任的簽發者」，建議先盤點自身環境是否為多 IdP 架構，並優先套用升級。

原始來源：GHSA-q8r6-xj3f-wrrm、GHSA-5cjr-mxj5-wmrx、GHSA-6929-8p9f-26jx

Apache HttpComponents Core 的 HTTP/2 HPACK 解碼器爆記憶體耗盡漏洞，SETTINGS 確認前缺乏限制

oss-security Mailing List · 2026-07-01

Apache HttpComponents 專案維護者 Oleg Kalnichevski 於 2026 年 7 月 1 日在 oss-security 郵件論壇公開 CVE-2026-54428，指出 Apache HttpComponents Core 的 HTTP/2 模組在 HPACK 標頭解碼階段沒有做資源限制，攻擊者可藉由送出超大的壓縮標頭區塊觸發記憶體耗盡型阻斷服務。Apache HttpComponents Core 是 Java 生態中最常見的底層 HTTP 用戶端／伺服端函式庫之一，許多知名專案（如 Apache HttpClient 5、Elasticsearch 用戶端等）都以它作為傳輸層基礎，該模組对應的 Maven 座標是 org.apache.httpcomponents.core5:httpcore5-h2。此漏洞由 Henry Huang 回報，嚴重度標示為 Important。

漏洞機制

HTTP/2 協定使用 HPACK 壓縮演算法來縮減重複標頭的傳輸體積，接收端必須先解壓縮才能取得原始標頭內容；而 HTTP/2 的 SETTINGS 訊框則用來協商雙方可接受的標頭列表大小上限（header list size）等參數，理論上應該在連線建立初期盡快生效。這次的問題出在時序落差：在 SETTINGS 確認生效之前，HPACK 解碼器並沒有對即將解壓縮的標頭區塊大小做任何限制，導致攻擊者可以趁著這個尚未套用限制的窗口，傳送刻意膨脹過的壓縮標頭區塊，迫使伺服端解壓縮出遠超正常範圍的資料量，進而耗盡記憶體、造成服務中斷。

這類「資源分配未受限制」的問題屬於 CWE 分類中常見的 資源無限制配置，在 HTTP/2 這種允許用少量位元組觸發大量後端運算或記憶體開銷的協定上尤其危險，此前業界也曾在其他 HTTP/2 實作（例如 Rapid Reset 攻擊）中反覆出現類似「協定層小訊息、放大成大量資源消耗」的模式，差別在於這次的放大機制發生在標頭解壓縮，而非串流建立與重置本身。

受影響版本

• org.apache.httpcomponents.core5:httpcore5-h2：5.5-beta1 及更早版本
• org.apache.httpcomponents.core5:httpcore5-h2：5.4.2 及更早版本

換言之，任何仍使用 5.4.2 以前（含）或 5.5 beta 系列 httpcore5-h2 的服務，只要有對外開放 HTTP/2 端點，都在受影響範圍內。由於 httpcore5-h2 通常是被更上層的 HTTP 用戶端／伺服器框架間接依賴引入，實際受影響的部署面可能比表面上的直接依賴清單更廣，需要往下追依賴樹確認。

修補與緩解

公告原文在郵件內容中未列出明確的修補版本號，僅說明問題已被識別並分類為 Important 等級；使用該模組的團隊應追蹤 Apache HttpComponents 專案後續發布的 5.4.x 或 5.5 正式版本，確認變更紀錄中是否包含此 HPACK 相關修補後再行升級。在修補版本正式釋出前，若無法立即停用 HTTP/2，可考慮在反向代理或負載平衡層對單一連線的標頭區塊大小與解壓縮後資料量設置硬性上限，作為過渡緩解手段。

由於此漏洞的觸發條件僅需要對方能建立 HTTP/2 連線並送出精心構造的請求，不需要任何身分驗證，對外公開服務的優先順序應高於內部服務。

原始來源：oss-security：CVE-2026-54428 Apache HttpComponents Core、CVE-2026-54428 紀錄