Hono 同日爆三個漏洞：SSR 快取外洩、Proxy 標頭殘留與正規表達式阻斷服務
GitHub Security Advisory · 2026-08-03
2026 年 8 月 3 日，輕量 Web 框架 Hono 同時發布三份安全公告，分別涉及 JSX 伺服器端渲染快取、hono/proxy 的回應標頭轉發，以及 languageDetector 中介層的正規表達式效能問題。三者都在同一版本 4.12.34 一次修補完成。由於根因都出在「請求層級狀態」處理不當，官方選擇同批次揭露，而非逐一發稿。
漏洞機制
影響最大的是 CVE-2026-71850（GHSA-f23p-vx2j-j53r），出在 hono/jsx 的 memo()。memo() 只比較傳入的 props 是否相同，卻不會考慮元件內部透過 context 讀到的請求層級資料，因此當元件用 useContext()、useRequestContext() 或 getContext() 讀取當前使用者資料時，只要 props 沒變，第二個使用者的請求就會直接拿到快取住的、屬於第一個使用者的渲染結果。以下為示意性的觸發樣式：
const Greeting = memo(() => {
// props 為空，memo() 視為每次渲染皆相同
const { user } = useRequestContext()
return <div>Hello, {user.name}</div>
})
app.get('/', (c) => c.html(<Greeting />))
// 使用者 A 的請求先渲染並被快取
// 使用者 B 的後續請求會直接拿到 A 的 HTML官方公告指出，這可能導致另一名使用者的帳號或個資外洩，也可能連帶洩漏嵌在 HTML 中的請求層級機密，例如 CSRF token，或是把僅限特定角色可見的內容曝露給不該看到的使用者。CVSS 評為 4.8（中度），攻擊複雜度被標記為高，原因是攻擊者必須先找到會讀取 context 且套用 memo() 的元件才能觸發。
第二個是 CVE-2026-71849（GHSA-79qm-7rj5-m7r9），問題在 hono/proxy 轉發後端回應時，沒有移除來源伺服器在 Connection 標頭中列出的逐跳（hop-by-hop）欄位，違反 RFC 9110 第 7.6.1 節的規範。也就是說，只要後端把某個標頭名稱寫進 Connection: X-Internal-Token，代理層原本該替使用者過濾掉這個欄位，實際上卻原封不動轉發出去，可能外洩內部或連線層級的中繼資料。此問題被列為低嚴重度，CWE 分類為 CWE-200（資訊洩露）。
第三個是 CVE-2026-71848（GHSA-54fx-42gc-7vw4），出在 languageDetector 中介層的 normalizeLanguage 函式。該函式在逐步截斷語言標籤（language tag）時，字串操作的時間複雜度是 O(N²)，只要傳入一個帶有大量連字號分隔子標籤的偽造語言標籤，單一請求就能吃掉可觀的 CPU 時間，重複發送則足以讓服務失去回應。此為典型的演算法複雜度型阻斷服務（Algorithmic Complexity DoS）。
受影響版本
CVE-2026-71850（memo() SSR 快取外洩）：hono>= 3.8.0, < 4.12.34CVE-2026-71849（Proxy Helper 標頭殘留）：hono>= 4.7.0, < 4.12.34CVE-2026-71848（Language Middleware ReDoS 型 DoS）：hono>= 4.12.0, <= 4.12.33
| CVE ID | 受影響元件 | 嚴重度 | 修補版本 |
|---|---|---|---|
| CVE-2026-71850 | hono/jsx memo() | Moderate（CVSS 4.8） | 4.12.34 |
| CVE-2026-71849 | hono/proxy | Low | 4.12.34 |
| CVE-2026-71848 | languageDetector 中介層 | Moderate | 4.12.34 |
修補與緩解
三個問題的修補方式相同：將 hono 升級到 4.12.34 或以上版本。在完成升級前，若元件內部會讀取 useRequestContext() 或其他請求層級狀態，應暫時避免對其套用 memo()，或改為把使用者相關資料以 props 顯式傳入，讓比較邏輯能反映真實差異。
對於 hono/proxy 的部署，若後端服務不受信任或會回傳自訂的 Connection 標頭，建議在升級前於邊界額外套用一層標頭白名單過濾，避免非預期欄位被透傳給使用者端。使用 languageDetector 中介層的服務，若暫時無法升級，可先限制 Accept-Language 或自訂語言參數的長度，降低單一請求可構造出的子標籤數量。
原始來源：GHSA-f23p-vx2j-j53r（CVE-2026-71850）、GHSA-79qm-7rj5-m7r9（CVE-2026-71849）、GHSA-54fx-42gc-7vw4（CVE-2026-71848）
go-git 修補兩個路徑穿越/符號連結漏洞：惡意 Reference 名稱與 Worktree 操作皆可寫出儲存庫外的檔案
GitHub Security Advisory · 2026-07-30
純 Go 實作的 Git 函式庫 go-git 在 2026 年 7 月 30 日同時發布兩份安全公告，都與檔案系統路徑逃逸有關：一個是參照（reference）名稱可穿越到儲存庫目錄外，另一個是 worktree 操作會跟隨既有符號連結。兩者的觸發面不同，但都源自「以字串規則判斷路徑安全」這個共同假設被打破。v5 與 v6 分支都受影響，已分別在 5.19.2 與 6.0.0-alpha.5 修補。
漏洞機制
第一個是 CVE-2026-71557（GHSA-qgq7-7hm3-q39j）。go-git 的檔案系統儲存後端會把鬆散參照（loose reference）直接寫在 .git/<reference-name> 底下，但先前的實作沒有驗證解析後的路徑是否仍落在參照儲存目錄之內，於是像下面這種參照名稱就能被拿來讀寫儲存庫外的檔案：
refs/heads/../../config
// 解析後實際指向 .git/config
// 經過 refspec 映射後也可能變成
refs/remotes/origin/../../config攻擊情境包含連線到惡意 Git 伺服器、或處理來自不受信任來源的參照名稱時觸發 clone／fetch。此問題只影響使用 storage/filesystem 套件的檔案系統實作，記憶體內儲存（in-memory storage）不受影響。CVSS 評為 6.3（中度），CWE 分類為 CWE-22（路徑穿越）。
第二個是 CVE-2026-71556（GHSA-hc8v-wwc9-vgxm），出在 worktree 操作使用的 worktreeFilesystem 包裝層。該包裝層雖然會先用字串規則擋掉明顯不安全的路徑，卻沒有阻止對既存符號連結的跟隨，因此一條「字串上看起來安全」的路徑，實際存取時仍可能經由符號連結指向 Git 中介資料目錄。公告指出，若 worktree 內存在一個指向 .git 的符號連結，寫入該連結最終會改到 .git/config；路徑最後一段本身是符號連結時同樣會被跟隨。此問題 CVSS 評為 7.1（高），CWE 分類為 CWE-59（連結解析錯誤，Link Following）。
受影響版本
CVE-2026-71557（參照名稱路徑穿越）：go-git/v5 <= 5.19.1、go-git/v6 <= 6.0.0-alpha.4CVE-2026-71556（Worktree 符號連結跟隨）：go-git/v5 <= 5.19.1、go-git/v6 <= 6.0.0-alpha.4
| CVE ID | 觸發面 | CVSS | 修補版本 |
|---|---|---|---|
| CVE-2026-71557 | dotgit 參照儲存路徑解析 | 6.3（Medium） | v5 5.19.2 / v6 6.0.0-alpha.5 |
| CVE-2026-71556 | worktreeFilesystem 符號連結跟隨 | 7.1（High） | v5 5.19.2 / v6 6.0.0-alpha.5 |
修補與緩解
兩個問題都在同一組版本修補：v5 使用者升級到 5.19.2，v6 使用者升級到 6.0.0-alpha.5。由於觸發面都要求檔案系統後端，若應用場景允許，改用 storage/memory 或記憶體型檔案系統作為暫時緩解，可讓兩個漏洞都不成立。
在升級之前，處理不受信任的遠端儲存庫或使用者提供的 worktree 內容時，應避免在受害路徑上執行寫入或截斷操作前信任既有符號連結，也建議限制 clone／fetch 的來源僅限已驗證的 Git 伺服器，降低惡意參照名稱被送進解析流程的機會。
原始來源：GHSA-qgq7-7hm3-q39j（CVE-2026-71557）、GHSA-hc8v-wwc9-vgxm（CVE-2026-71556）