2026-06-25 — Hoppscotch CVSS 10.0 JWT 金鑰竄改、curl 一次修補 18 個漏洞、美國行政命令 2030 後量子遷移期限

Hoppscotch 初始化漏洞：無需登入即可竄改 JWT 金鑰，CVSS 滿分 10.0

GitHub Security Advisories (GHSA-j542-4rch-8hwf) · 2026-05-28

開源 API 測試平台 Hoppscotch 的後端元件存在一個嚴重程度為 CVSS 10.0 的漏洞，編號 CVE-2026-50160。攻擊者毋須任何身份驗證，便可在系統初始化階段覆寫 JWT_SECRET 與 SESSION_SECRET，進而偽造任意使用者的身分令牌。受影響版本為 hoppscotch-backend ≤ 2026.4.1，修補版本為 2026.5.0。

漏洞機制

這個漏洞並非單一疏漏，而是四個設計缺陷環環相扣所形成的攻擊鏈。第一個問題在於 NestJS 的 ValidationPipe 沒有設定 whitelist: true，導致客戶端傳入的任何額外欄位都能穿透至服務層，不受 DTO（資料傳輸物件）的定義限制。第二個問題在於服務層直接以 Object.entries(dto) 迭代整個請求物件，攻擊者傳入的惡意鍵值（例如 JWT_SECRET）便會被一併處理。

第三個缺陷存在於 validateEnvValues 方法：該方法以 switch 語句逐一驗證欄位，但 default 分支僅執行 break 而不拋出錯誤，使任何未被明確列舉的安全關鍵欄位都能悄然繞過驗證。最後，問題最深的一環是：這個初始化端點完全不需要身份驗證，只依賴 usersCount === 0 這個條件判斷，意即只要系統資料庫中尚無使用者，任何人皆可呼叫此端點。

完整攻擊流程如下：攻擊者在實例剛上線、尚未完成初始設定的時間窗口內，向 onboarding 端點發送一個包含 JWT_SECRET: "attacker-controlled-value" 的 POST 請求。後端將以攻擊者指定的金鑰重新設定整個 JWT 簽發基礎，此後攻擊者便能自行簽發任意使用者（包括管理員）的合法 token，實現完全的帳號接管與資料竊取，且即便事後重設密碼亦無法撤銷這個持久後門。

受影響版本

• 受影響：hoppscotch-backend 所有 2026.4.1 及更早版本
• 已修補：2026.5.0 及之後版本
• 特別高風險情境：自架（self-hosted）實例於首次部署後、完成 onboarding 前對外網路可達時

修補與緩解

官方修補方案包含三個層次的防禦：在 ValidationPipe 中啟用 whitelist: true 以過濾未宣告的 DTO 欄位；修正服務層迭代邏輯，不再直接使用 Object.entries 處理未驗證輸入；以及在 validateEnvValues 的 default 分支加入明確的錯誤拋出。自架 Hoppscotch 的維運團隊應立即升級至 2026.5.0，並檢查系統環境變數是否已遭竄改——尤其是 JWT_SECRET 的值是否仍為原始設定。若懷疑已遭入侵，應全面輪換 JWT 金鑰並使所有現存 session 失效。

原始來源：GitHub Advisory GHSA-j542-4rch-8hwf

curl 8.21.0 安全更新：一次修補 18 個漏洞，憑證洩漏問題尤須重視

curl Security Advisories · 2026-06-24

curl 開發團隊於 2026 年 6 月 24 日同步釋出 8.21.0 版本與 18 份安全公告，涵蓋從記憶體損壞（double-free、UAF）到多種跨連線憑證洩漏的廣泛問題。雖然大多數漏洞被評為低嚴重度，但其中四個中等嚴重度的憑證洩漏問題在企業環境中具有實際風險。所有漏洞均已在 8.21.0 中修復，受影響的使用者應立即升級。

漏洞機制：憑證洩漏四連發

此次更新中最值得關注的是四個中等嚴重度的認證相關漏洞，它們共同的問題根源是 libcurl 在連線複用或切換代理時未能正確清除認證狀態。

CVE-2026-8925（SASL 雙重釋放）是其中唯一涉及記憶體損壞的中等漏洞。在 libcurl 以 libgsasl 支援進行 SASL 認證時（適用於 IMAP、POP3、SMTP），程式邏輯會在未清除指標的情況下兩次釋放同一個 GSASL context，構成 CWE-415 雙重釋放。由於伺服器行為能影響記憶體釋放的時序，研究員 Joshua Rogers 指出此問題在特定情境下具備有限的可利用性。受影響版本為 8.15.0 至 8.20.0。

CVE-2026-9079（過期代理密碼洩漏）則是 libcurl 在應用程式嘗試清除代理認證憑證時，未能實際移除記憶體中的舊憑證，導致後續轉移請求意外帶上本不應使用的舊密碼。此漏洞僅影響 libcurl 函式庫呼叫者，命令列 curl 工具不受波及，受影響版本為 8.8.0 至 8.20.0。

CVE-2026-11856（跨來源 Digest 認證狀態洩漏）與 CVE-2026-8927（環境變數代理 Digest 認證洩漏）則是同一類型問題的兩種變體：當 libcurl 重複使用同一個連線 handle 對不同 HTTP 來源或不同代理伺服器發出請求時，先前針對甲方的 Authorization 或 Proxy-Authorization 標頭會被錯誤地轉發給乙方。惡意的第二個目標伺服器或代理可藉此擷取認證狀態，對原始目標重放請求。前者最早影響至 7.10.6，後者則追溯至 7.12.0。

受影響版本

修補與緩解

所有 18 個漏洞均已在 curl 8.21.0（2026-06-24 釋出）中修補，這也是目前的官方修復版本。對於無法立即升級的環境，可考慮以下緩解措施：停用 SASL/GSASL 整合以規避 CVE-2026-8925；在應用程式層級避免於單一 libcurl handle 的生命週期內切換代理設定，以降低憑證洩漏風險。值得注意的是，命令列 curl 工具不受四個憑證洩漏漏洞影響，僅直接呼叫 libcurl API 的應用程式才有暴露風險，維運團隊在評估優先序時可參考此區別。

原始來源：curl CVE-2026-8925、curl CVE-2026-9079、curl CVE-2026-11856

美國行政命令強制聯邦系統 2030 年前完成後量子密碼遷移

Cloudflare Blog · 2026-06-23

美國總統於 2026 年 6 月 22 日簽署第 14409 號行政命令《Securing the Nation Against Advanced Cryptographic Attacks》，要求聯邦機構的高價值資產（High Value Assets，HVA）與高影響度系統於 2030 年 12 月 31 日前完成後量子金鑰協商遷移，並於 2031 年 12 月 31 日前完成數位簽章的遷移。這是迄今最具法律約束力的後量子密碼（PQC）政策里程碑，標誌著防禦「先竊取後解密（harvest-now, decrypt-later）」攻擊的部署工作正式進入強制執行階段。

行政命令的核心要求

行政命令設定了明確的雙軌遷移路線：先遷移金鑰建立（key establishment），再遷移數位簽章（digital signatures），兩個截止日期相差一年，反映出業界在替換非對稱加密演算法上的現實部署複雜度。聯邦機構必須在命令生效後 30 天內指定 PQC 遷移負責人，並於 90 天內向管理及預算局（OMB）提交具體遷移計畫。

在演算法層面，命令要求採用 NIST 已完成標準化的三個後量子演算法：ML-KEM（FIPS 203，用於金鑰封裝）、ML-DSA（FIPS 204，用於數位簽章）、以及 SLH-DSA（FIPS 205，無狀態雜湊型數位簽章）。這三個標準均於 2024 年 8 月由 NIST 正式發布，至今已有近兩年的實作空窗期供業界準備。國家安全系統（NSS）則由 NSA 另訂 2030 至 2033 年的獨立時程管理，不適用本行政命令。

命令亦要求聯邦承包商於 2030 年前遵從 NIST PQC FIPS 標準，並建立涵蓋密碼弱點的漏洞揭露計畫（VDP）。FAR 委員會須在 270 天內發布要求承包商合規的採購法規草案，意味著供應鏈合規壓力將逐步向私部門延伸。

Cloudflare 的現況與行動

Cloudflare 在這份行政命令的背景下揭露了自身的部署進度：目前已有超過三分之二流向其網路的瀏覽器流量使用後量子加密，旗下大多數產品也已支援後量子金鑰協商。其 SASE 平台 Cloudflare One 在 TLS、MASQUE 與 IPsec 等協定上均提供後量子保護，且所有後量子升級對所有訂閱層級的客戶均免費提供。Cloudflare 自定的目標是在 2029 年前完成包含數位簽章在內的全面後量子安全，比行政命令的聯邦期限提早一至兩年。

對於非聯邦的企業與組織，行政命令雖未設定硬性截止日，但已透過供應鏈合規要求形成間接壓力。「先竊取後解密」威脅的迫切性在於它是現在式：具備充裕資源的攻擊者今日便可大量截錄加密流量，等待量子電腦成熟後再行解密。因此，金融、醫療、電信等資料保存期長的行業，應將 PQC 遷移列為近期優先項目而非 2030 年前才需處理的問題。

原始來源：White House EO 14409、NIST Post-Quantum Cryptography Project