Perl 的 Punk::OAuth2::Server 授權檢查形同虛設，用戶端能自己升級 token 範圍
oss-security mailing list · 2026-08-22
CPAN Security Group 的 Timothy Legge 於 2026 年 8 月 22 日在 oss-security 信件列表公告 CVE-2026-75866：Perl 的 OAuth2/OIDC 套件 Punk::OAuth2::Server 在 0.03 及之前版本，完全沒有檢查用戶端請求的 grant type 與 scope 是否符合註冊內容。任何已註冊的用戶端都能自行核發超出授權範圍的 token，且不需要額外權限即可觸發。
漏洞機制
authorize 函式會把 query string 裡的 scope 原封不動寫進 authorization code 記錄，完全不比對用戶端註冊時登記的範圍；token 端點的 dispatcher 也只按請求 body 給的 grant_type 執行對應邏輯。一個只登記 authorization_code 流程的用戶端，改請求 client_credentials 照樣能過。核發出來的 at+jwt access token 因此可以夾帶用戶端自稱的任意 scope，下游只要用 Punk::OAuth2::Checker 驗證這個 token，就會照單全收。更麻煩的是，沒有登記 secret 的用戶端光靠 client_id 就能通過驗證，等於任何知道這個 ID 的人都能替它要 token。
修補與緩解
升級到 Punk-OAuth2 0.04 後，grant_types 與 scopes 會被強制核對、預設一律拒絕（deny by default）。暫時無法升級的部署，可以在 Punk::OAuth2::Server 前面加一層 proxy，擋掉用戶端請求中未登記的 grant type 或 scope。
同一套 Punk 框架再中一刀：Session 沒給 secret 就用空 HMAC 金鑰簽章
oss-security mailing list · 2026-08-22
同一天，Timothy Legge 也在 oss-security 公告了 Perl MVC 框架 Punk 本體（非 OAuth2 擴充）的問題，編號 CVE-2026-75870：0.18 版之前，宣告 session 時若沒提供 secret，框架會直接把 HMAC-SHA256 簽章金鑰設成空字串。Cookie 因此可以被離線偽造出任意內容，而不需要碰到伺服器一次。
漏洞機制
公告指出，session 這個 keyword 只是把開發者傳入的選項原封凍結進應用程式設定，「不會要求 secret，不會警告，也不會拒絕啟動」。一旦專案漏填 secret，簽章金鑰的長度就是零，攻擊者只要知道 cookie 的序列化格式，就能在本機算出合法簽章，偽造出帶有任意使用者 ID 或角色的 session，直接繞過登入。
修補方式是升級到 Punk 0.18：這個版本讓 secret keyword 改為 fail closed，只要金鑰來源（設定或環境變數）缺失，應用程式會直接啟動失敗，不再悄悄退回空字串簽章。
插隨身碟就變 root：Linux NTFS3 驅動的「InjectionBunny」SUID 注入手法
Phoronix · 2026-08-22
研究者 Vova Tokarev 在 Linux 核心 ntfs3 mailing list 公開一套名為 InjectionBunny 的手法：光是掛載一張刻意製作的 NTFS 映像檔，就能讓掛載者瞬間取得一個 setuid-root 的執行檔。此問題兩個月前已私下回報，直到 2026 年 8 月 22 日才被公開揭露，公開當時仍未修補。
漏洞機制
Windows 的 WSL 會把 Linux 檔案權限存成 NTFS 的擴充屬性（extended attribute），也就是 $LXUID（owner）、$LXGID（group）、$LXMOD（mode）這幾個保留名稱；NTFS3 驅動掛載時會把這些值直接讀回 inode。問題出在 fs/ntfs3/xattr.c 第 1022 行：inode->i_mode = le32_to_cpu(value[2]); 把磁碟上完全不受信任的資料直接塞進 i_mode，沒有濾掉 setuid／setgid 位。攻擊者不需要呼叫 setxattr()，只要在映像檔的 MFT 裡預先寫好 $LXUID=0、$LXGID=0、$LXMOD=0104755，隨身碟插上去掛載的那一刻就會生出一個 root 擁有的 setuid 執行檔。
修補與緩解
inode->i_mode = le32_to_cpu(value[2]) & ~(S_ISUID | S_ISGID);討論串提出的修法是掛載時直接拔掉繼承來的 setuid/setgid 位，並擋下使用者透過 setxattr() 直接寫入這幾個保留 $LX* 名稱的請求，只留給核心內部的 ntfs_save_wsl_perm() 更新用。有回應者也指出這其實是掛載帶 suid 選項檔案系統的已知風險，任何自動掛載可移除媒介的工具都應該加上 nosuid 選項。