LemonLDAP::NG 把 OAuth2 狀態參數誤存成完整 SSO Session，未登入者可直接冒充身分
NVD · 2026-08-16
LemonLDAP::NG 是 OW2 基金會維護的開源 Web SSO 系統，廣泛用於歐洲政府機關與企業內部的身分入口。CVE-2026-19349 顯示，只要 Portal 元件啟用了 GitHub 或 LinkedIn 這兩個 OAuth2 登入後端，未經任何身分驗證的訪客就能取得一組可直接當作已登入 SSO session 使用的識別碼。這個問題橫跨 2.0.0 到 2.23.2 三個發布分支，OW2 已於 2026 年 8 月 16 日同步釋出修補版本。
漏洞機制
OAuth2 授權碼流程原本會產生一組 state 參數，用來防止 CSRF 並在使用者從 GitHub/LinkedIn 導回時比對來源。正常設計下，這組 state 值應該只存在一個短命、與正式登入 session 隔離的暫存區。問題出在 Portal 呼叫 getApacheSession() 時參數給錯（NVD 將根因歸類為 CWE 的「Function Call with Incorrectly Specified Arguments」），導致 state 資料被寫進和已驗證使用者共用的正式 SSO session 儲存表。
由於 state 識別碼會在使用者尚未完成登入前，就以導向網址或 cookie 形式送到瀏覽器端，攻擊者只需要「啟動」一次 OAuth2 登入流程（不必真的用 GitHub/LinkedIn 帳號完成驗證），就能拿到一個實際上已經被寫入正式 session 表的識別碼。把這個識別碼原樣塞回瀏覽器的 session cookie，Portal 後端在查表時無法區分它原本只是個 state token，於是直接當成合法登入放行。
1. GET /oauth2/callback?backend=github (未登入)
-> Portal 產生 state=abcd1234，寫入 SSO session 表
-> 302 導向 GitHub 授權頁，state=abcd1234 一併帶出
2. 攻擊者不完成 GitHub 授權，直接：
Cookie: lemonldap=abcd1234
3. Portal 查表命中 abcd1234 -> 視為已驗證 session -> 放行整個過程完全不需要攻擊者持有真實的 GitHub 或 LinkedIn 帳號密碼，只要能觸發一次登入導向、取得 state 值即可。
受影響版本
| 分支 | 受影響版本 | 修補版本 |
|---|---|---|
| 2.16.x | 2.0.0 – 2.16.8 | 2.16.9 |
| 2.21.x | 2.17.0 – 2.21.4 | 2.21.5 |
| 2.23.x | 2.22.0 – 2.23.2 | 2.23.3 |
只有同時啟用 GitHub 或 LinkedIn OAuth2 認證後端的部署才受影響；純 LDAP、SAML 或本機帳密登入的環境不在此範圍內。截至 2026 年 8 月 16 日，NVD 尚未給出 CVSS 分數評估。
修補與緩解
官方修補的作法是把 state token 的儲存與正式 SSO session 儲存徹底分離，並修正 getApacheSession() 的呼叫參數，讓 state 只會寫入一個獨立、短期過期的暫存區，不會被當成合法 session 查到。管理者應直接升級到 2.16.9、2.21.5 或 2.23.3 對應分支。若短期內無法升級，可先在設定中停用 GitHub 與 LinkedIn 這兩個 OAuth2 後端作為臨時緩解。
研究者揭露 OpenZFS on Linux 八項瑕疵，容器內 CAP_SYS_ADMIN 足以逃逸至宿主機 pool
oss-security 郵件列表 · 2026-08-16
獨立研究者 Erica Windisch 於 2026 年 8 月 16 日在 oss-security 郵件列表發布一份針對 OpenZFS on Linux 的稽核報告，對象是核心模組 spl.ko 與 zfs.ko，稽核版本為開發分支中的 revision 9b7642df931a765509403318553f2910daf71305（對應發布號 2.4.99-1 及更早）。報告一共列出八項瑕疵，合稱可在「主機把 /dev/zfs 暴露給非特權容器」的環境下，構成低權限容器逃逸至宿主機。目前尚未分配 CVE 編號，處於協調揭露階段。
漏洞機制
前兩項瑕疵 OZ-1、OZ-2 屬於授權判斷缺陷：核心對 /dev/zfs 上的 ioctl 只檢查呼叫者是否具備 CAP_SYS_ADMIN，卻沒有確認這個能力是來自宿主機的初始 user namespace，還是容器自己 namespace 內取得的 local capability。容器化環境中，一個被賦予自身 namespace 內 CAP_SYS_ADMIN 的非特權容器，就足以通過這道檢查，進而執行原本應限定宿主機管理者才能做的 pool 匯入與操作。
其餘六項 OZ-3 到 OZ-8 是 import、replay 與 metadata 讀取路徑上的解析器問題：這些路徑直接信任 on-disk 的標籤、uberblock 與 ZIL 紀錄等攻擊者可控欄位，未做邊界檢查，會導致堆疊或堆積溢位，以及無邊界的走訪迴圈造成阻斷服務。當攻擊者能提供一顆惡意構造的 pool 或 vdev 映像（例如掛載的磁碟映像、iSCSI target 或複寫串流），就能把授權缺陷與解析器缺陷串連，從容器內把畸形資料送進宿主機核心處理。
// 有問題的檢查方式（概念示意，非原始 diff）
if (capable(CAP_SYS_ADMIN)) {
// 執行 host 層級的 zpool 操作
}
// 正確應區分能力來源的 namespace
if (ns_capable(&init_user_ns, CAP_SYS_ADMIN)) {
// 只有宿主機初始 namespace 的管理者才放行
}受影響版本
| 瑕疵編號 | 類型 | 影響 |
|---|---|---|
| OZ-1 / OZ-2 | 授權判斷 | namespace-local CAP_SYS_ADMIN 被誤當成宿主機管理權限 |
| OZ-3 – OZ-8 | on-disk 解析器 | import / replay / metadata 讀取路徑產生堆疊、堆積溢位與無界走訪 |
- 核心模組：
spl.ko、zfs.ko - 版本範圍：開發分支
2.4.99-1及更早 - 前提條件：主機將
/dev/zfs暴露給非特權容器（常見於允許容器操作 ZFS 的部署）
修補與緩解
報告發布時，OpenZFS 專案尚未釋出對應的修補版本或 commit，研究者與上游仍處於協調揭露階段，技術細節與完整稽核證據暫未公開。在正式修補釋出前，可行的緩解方式是避免把 /dev/zfs 直接暴露給非特權容器，或不要同時賦予容器 CAP_SYS_ADMIN 與 /dev/zfs 掛載權限；也可以用 seccomp 或 AppArmor 規則限制容器對 ZFS ioctl 介面的存取範圍，降低授權判斷缺陷被觸發的機會。
原始來源：oss-security 郵件列表公告