CVE-2026-44351：fast-jwt 非同步金鑰解析器回傳空字串可完全繞過 JWT 驗證
GitHub Advisory Database · 2026-05-07 · GHSA-gmvf-9v4p-v8jc
npm 套件 fast-jwt 在 6.2.4 版本前存在嚴重認證繞過漏洞（CVSS 9.1 Critical），當非同步金鑰解析器（async key resolver）回傳空字串時，攻擊者可偽造任何聲明的 JWT，在零先驗知識的情況下假冒任意身分。
漏洞機制
問題根源在 prepareKeyOrSecret 函式缺乏 HMAC secret 長度驗證。當 async key resolver 回傳 ''（空字串）時，函式將其轉換為零長度 Buffer 並傳入 crypto.createSecretKey——Node.js 的 crypto 模組靜默接受零長度金鑰，不拋出任何錯誤。系統隨後預設為 HMAC 算法（HS256/HS384/HS512），而以空字串計算的 HMAC 是任何攻擊者都能輕易重現的數值：
crypto.createHmac('sha256', '').update(header + '.' + payload).digest('base64url')
// 結果完全可被攻擊者預先計算觸發條件（所有條件須同時成立）：應用程式使用 async callback 進行金鑰解析、resolver 在特定條件下回傳空字串或零長度 Buffer、允許 HMAC 簽章算法（預設配置）、攻擊者能提交有效的 exp/iat 聲明。
受影響版本
- 受影響：fast-jwt ≤ 6.2.3
- 已修補：fast-jwt 6.2.4（在
prepareKeyOrSecret加入長度驗證，回傳空金鑰時拋出明確錯誤）
修補與緩解
升級至 fast-jwt@6.2.4 是唯一完整修復。無法立即升級時的緩解方案：在 async key resolver 中明確驗證金鑰非空再回傳，並在應用層要求所有 JWT 使用非對稱算法（RS256、ES256）取代 HMAC。此漏洞影響範圍：CVSS 向量 AV:N/AC:L/PR:N/UI:N（無需任何先決條件的遠端攻擊），成功利用後可完全控制應用程式的身分認證與授權。
原始來源：GHSA-gmvf-9v4p-v8jc — fast-jwt JWT auth bypass via empty HMAC secret
CVE-2026-44244：GitPython 換行注入導致 core.hooksPath RCE
GitHub Advisory Database · 2026-05-07 · GHSA-v87r-6q3f-2j67
Python 套件 GitPython 3.1.48 及以下版本存在高危漏洞（CVSS 7.8 High），攻擊者可透過 config_writer().set_value() 注入換行字符，污染 .git/config 並將 core.hooksPath 重定向至攻擊者控制的目錄，在下次 Git 操作時執行任意腳本。
漏洞機制
GitPython 的 GitConfigParser._write() 在序列化配置值時，將嵌入的換行字符轉換為縮排的續行（indented continuation line），例如 "value\n[core]\nhooksPath=/evil" 會被寫入：
[user]
name = value
[core]
hooksPath = /evil/pathGit 的 config 解析器將縮排的 [core] 視為有效的 section header，因此 core.hooksPath 被成功覆寫。後續任何觸發 Git hook 的操作（commit、merge、checkout）均會從攻擊者指定路徑執行腳本。影響最大的場景是接受使用者輸入的 author_name、author_email 等欄位，直接傳入 config_writer().set_value()。
受影響版本
- 受影響：GitPython ≤ 3.1.48
- 已修補：GitPython 3.1.49（輸入驗證在寫入前拒絕包含 CR、LF 或 null 字節的值，拋出
ValueError）
修補與緩解
升級至 gitpython==3.1.49。無法立即升級的環境，應在所有傳入 set_value() 的字串上進行輸入清理，拒絕包含 \r、\n、\0 的值。此漏洞屬本地提權路徑，需要攻擊者有能力控制傳入 GitPython API 的參數，在接受不受信任輸入的 Web 應用（如代碼審查平台、CI 系統）中風險最高。
原始來源：GHSA-v87r-6q3f-2j67 — GitPython newline injection enables RCE via core.hooksPath
Google 將 Binary Transparency 擴展至 Android 生態系：防止未授權 Google 應用程式發布
Google Security Blog · 2026-05-07
從 2026 年 5 月 1 日起，Google 所有正式生產應用程式在發布時均同步取得 公開 append-only log 中的密碼學條目，作為授權發布的可驗證憑證。這項 Binary Transparency 計畫從 Android 系統映像（System Image Transparency，2023 年啟動）延伸至 Google 應用程式與 Mainline 模組，構建完整的 Android 軟體可驗證性框架。
背景
數位簽章只能證明「誰簽署了這份軟體」，但無法回答「Google 是否意圖發布這個特定版本」。如果 Google 的簽署金鑰遭竊、存在惡意內部人士、或在開發建構環境中發生供應鏈攻擊，攻擊者可以產出帶有合法 Google 簽章但從未被公開授權的應用程式版本。Binary Transparency 的核心概念是：在簽章之外，再加上「公開承諾」——不存在於 log 中的應用程式，Google 即未授權其發布。
技術機制
系統採用 append-only ledger，每份 Google 正式應用程式建構在發布時插入一個密碼學條目。Ledger 的 append-only 屬性確保任何人——包括 Google 自身——都無法在不留下公開記錄的情況下修改或刪除條目。
涵蓋兩個軟體層：
- Google 應用程式：Play Store 上的 Google 正式應用
- Mainline 模組：以 Google Play 動態更新的 Android OS 核心組件，在提升的系統權限下執行，是攻擊的高價值目標
Google 在 Android Binary Transparency 儲存庫提供驗證工具，研究人員和用戶可獨立驗證裝置上的 Google 應用程式是否確實在 log 中有對應記錄。
影響範圍
此方案直接威脅模型包括：竊得簽署金鑰的攻擊者、惡意內部人士推送未授權更新、以及建構系統供應鏈污染。Pixel 用戶的保護最為完整——Pixel 同時啟用 System Image Transparency 與本次的應用程式 Binary Transparency，形成從 OS 映像到應用程式的雙層可驗證覆蓋。非 Pixel Android 設備目前僅 Mainline 模組受 Binary Transparency 保護。