Hono Cache Middleware 跨使用者資料洩漏：Vary 標頭未遵循導致快取邊界失效（CVE-2026-44457）
GitHub Security Advisory · 2026-05-09
Hono 框架的 Cache Middleware 在 v4.12.18 之前存在 CVE-2026-44457（GHSA-p77w-8qqv-26rm，CVSS 5.3），問題根源在於未正確處理 HTTP 快取的 Vary 標頭語義：帶有 Vary: Authorization 或 Vary: Cookie 的回應被錯誤地快取，後續不同用戶的請求可能取得前一位用戶的個人化回應。
漏洞機制
HTTP 規格（RFC 9110/9111）要求：若回應宣告 Vary: Authorization 或 Vary: Cookie，快取代理與中介層必須以對應請求標頭的值作為快取鍵的一部分，確保不同認證狀態的用戶取得各自的回應副本。
Hono Cache Middleware 的實作只跳過快取以下情況：Vary: *、Cache-Control: private/no-store/no-cache、以及 Set-Cookie 存在。對 Vary: Authorization 與 Vary: Cookie 的處理遭到遺漏，導致第一位用戶的認證回應被快取，後續其他用戶取得相同的快取內容。受影響場景包含 JWT 驗證後端點、用戶個人化 API 等使用 Bearer token 或 session cookie 認證的端點。
受影響版本
- 受影響：npm 套件
hono < 4.12.18 - 已修補：
hono 4.12.18（2026 年 5 月 6 日發布）
修補與緩解
立即升級至 hono@4.12.18。若無法立即升級，緩解措施是在所有用戶特定端點的回應中明確設定 Cache-Control: private，讓現有 middleware 的過濾邏輯生效。對於已使用 CDN 或反向代理快取的場景，需同時清除這些層的快取，因為被快取的個人化回應可能已滲透至上游快取層。
FreeBSD 本地提權漏洞：execve() 運算子優先權缺陷導致相鄰緩衝區覆寫（CVE-2026-7270）
FreeBSD Security Advisory · 2026-04-29
FreeBSD 安全團隊發布 SA-26:13.exec，記錄 CVE-2026-7270：核心中 execve(2) 系統呼叫的處理程式碼存在運算子優先權（operator precedence）錯誤，導致緩衝區溢位，攻擊者可覆寫相鄰的 execve(2) 參數緩衝區，進而以普通用戶身分取得 superuser 權限。
漏洞機制
execve(2) 是 UNIX 系統載入並執行程式映像的核心系統呼叫，負責設置新程序的記憶體空間，並將執行參數（argv）與環境變數（envp）傳遞到新程序。FreeBSD 核心中處理 execve(2) 的程式碼存在運算子優先權錯誤（operator precedence bug），導致緩衝區邊界計算偏差，使攻擊者控制的資料得以覆寫相鄰緩衝區，並透過精心構造的參數列表達成任意程式碼執行。漏洞可由本地未授權用戶直接觸發。
受影響版本
- FreeBSD 15.0-STABLE 與 15.0-RELEASE
- FreeBSD 14.4-STABLE、14.4-RELEASE、14.3-RELEASE
- FreeBSD 13.5-STABLE、13.5-RELEASE
- 適用平台：amd64、arm64；i386 僅限 FreeBSD 13
修補與緩解
FreeBSD 提供三種更新途徑，均需重開機後生效：
# 套件更新（推薦）
pkg upgrade -r FreeBSD-base
# 二進位發行版更新
freebsd-update fetch && freebsd-update install
# 核心源碼修補
# 至 security.FreeBSD.org 下載對應分支的 patch由於漏洞可由本地用戶直接觸發且可達到完整 root 提權，對多用戶 FreeBSD 系統應視為緊急更新。所有 7 個受影響分支均已提供含 Git commit hash 的修補版本供驗證。
90 天漏洞揭露政策的終結：AI 加速了漏洞發現與武器化，協調揭露假設已崩潰
Himanshu Anand Blog · 2026-05-10
Google Project Zero 推廣的 90 天協調揭露（coordinated disclosure）視窗，建立在兩個假設上：獨立發現同一漏洞的研究者極少，以及從修補程式反向工程出可用 exploit 需要數天到數週。2026 年 5 月的一篇分析認為，這兩個假設在 AI 輔助的漏洞研究時代均已失效。
收斂發現問題
作者記錄了一個關鍵案例：在 6 週內，有 11 個獨立研究團隊向同一廠商回報同一個嚴重漏洞。LLMs 讓具備基礎安全知識的研究者可以快速掃描大型程式碼庫，平行探索多個候選漏洞路徑，不同團隊使用不同工作流程但收斂到相同結論的速度遠超過 90 天視窗的設計假設。
武器化加速
作者測試了從公開的 React 安全修補程式反向工程出 proof-of-concept 的時間：使用 AI 輔助在 30 分鐘內完成，而傳統估計是數天。Copy Fail（CVE-2026-31431）的案例進一步佐證：AI 安全掃描工具在一小時內發現該核心漏洞，伊朗國家行為者在公開後數天內完成武器化。Dirty Frag 在無修補程式的情況下公開，微軟在 24 小時內觀察到主動利用跡象。
提出的替代方案
- 修補即揭露：「修補程式發布的瞬間，假設 exploit 已存在。沒有寬限期。」
- 縮短研究者等待時間：若廠商無法在 7–14 天內回應，研究者的道德義務應轉移。
- CI/CD 整合 AI 安全審查：在程式碼推送時執行 AI 輔助的漏洞掃描，而非依賴月度修補週期。