Apache CXF 以 32 位元雜湊快取已驗證 token，可繞過認證
oss-security（Apache CXF 團隊公告） · 2026-10-09
Apache CXF 的 STSTokenValidator 與 Security Token Service（STS）把「已驗證過的 token」存進快取，快取鍵卻只是 32 位元、非密碼學的雜湊值，而且快取命中就等於驗證通過。攻擊者只要做出雜湊相同的 token，就能跳過密碼、簽章與 STS 檢查。
這是 CVE-2026-97468，Apache 評為 Important，由 Colm O hEigeartaigh 於 2026-10-09 在 oss-security 發布，發現者為 MopMonk-AI。
原本的問題
SOAP 的 WS-Security 驗證成本不低：UsernameToken 要比對密碼，SAML Assertion 要驗簽章與信任鏈，必要時還要呼叫 STS。為了省下重複驗證，CXF 把驗證成功的 token 記進快取，下次看到同一個 token 就直接放行。
這個設計本身合理，前提是快取鍵能唯一代表 token。問題出在鍵的算法：公告指出，鍵是 Java 的 Arrays.hashCode() 或 hashCode() 算出的 32 位元值。
漏洞機制
32 位元雜湊只有約 43 億種值，而且 Java 的 hashCode() 不是為抗碰撞設計的，攻擊者可以刻意構造碰撞。公告的描述是：攻擊者製作一個雜湊與快取中某筆相同的 token，例如 UsernameToken 或自簽的 SAML Assertion，CXF 就把它當成「已驗證過」。
- 不做密碼驗證
- 不做簽章與信任檢查
- 不呼叫 STS
結果是攻擊者能以另一位使用者的身分通過認證。若再走 STS 的驗證或更新流程，還能拿到由 STS 簽發、代表該身分的 token，影響會從單一服務擴散到信任該 STS 的其他服務。
| 預期行為 | 漏洞下的行為 | |
|---|---|---|
| 快取鍵 | 能唯一識別 token | 32 位元雜湊，可構造碰撞 |
| 命中時 | 代表同一個已驗證 token | 碰撞的任意 token 一併放行 |
受影響版本
公告列出的範圍如下，原文照錄：
- Apache CXF 4.2.0 之後、4.2.4 之前
- 4.0.0 之後、4.1.9 之前
- 3.6.13 之前的所有版本
修正版本為 4.2.4、4.1.9、3.6.13。
影響範圍與修補
會中招的是用 CXF 做 WS-Security、並啟用 STS 或 STSTokenValidator 的服務，例如以 SAML 或 UsernameToken 對接內部 SSO、企業 SOAP 閘道的 Java 後端。只走一般 REST、沒用 STS 驗證的服務，不在公告描述的路徑上。
檢查方式：看 pom.xml 或 gradle 的 CXF 版本，再確認設定裡是否使用 STS 的 token 驗證與快取。公告只給升級一條路，未提供設定層面的緩解辦法。公告也未提供 CVSS 分數與在野利用資訊。
cxf.version: 4.2.0 ~ 4.2.3 -> 4.2.4
cxf.version: 4.0.x ~ 4.1.8 -> 4.1.9
cxf.version: < 3.6.13 -> 3.6.13