資安雷達 2026 年 8 月 31 日

2026-08-31 — Apache Wicket 三個 CVE 同日曝光、Apache Shiro 現伺服器端請求重導、QubesOS QSB-118 揭露 dom0 任意程式碼執行

primary=https://www.openwall.com/lists/oss-security/2026/08/30/5 primary=https://www.openwall.com/lists/oss-security/2026/08/30/4 primary=https://www.openwall.com/lists/oss-security/2026/08/30/3 primary=https://www.openwall.com/lists/oss-security/2026/08/30/2 primary=https://www.qubes-os.org/news/2026/08/29/qsb-118/

Apache Wicket 同日曝三洞、Apache Shiro 現伺服器端請求重導、QubesOS QSB-118 揭露 dom0 任意程式碼執行

oss-security / Qubes Security Bulletin · 2026-08-29 – 2026-08-30

2026 年 8 月 30 日,Apache 軟體基金會在 oss-security 郵件論壇上一口氣公布三個 Apache Wicket 漏洞,同一批公告裡還包含一個 Apache Shiro 的伺服器端請求重導問題;前一天 Qubes OS 專案也發布了 QSB-118,描述透過複製檔案至虛擬機的錯誤回報通道在 dom0 觸發任意程式碼執行的漏洞。三起事件分屬三個獨立專案,但都與攻擊者可控的輸入未經充分驗證就被用於安全判斷或指令組裝有關。

漏洞機制

三個 Wicket CVE 都集中在 wicket-core。第一個 CVE-2026-71378 出在 ResourceIsolationRequestCycleListener 預設使用的 FetchMetadataResourceIsolationPolicy:這個機制原本是靠瀏覽器送出的 Fetch Metadata 標頭(如 Sec-Fetch-SiteSec-Fetch-Mode)判斷請求是否跨站發起,藉此擋下跨站呼叫 Link.onClick()、Form.onSubmit() 等元件監聽器的 CSRF 攻擊。問題在於該政策把所有「頂層導覽」(Sec-Fetch-Mode: navigate 的 GET 請求)一律放行,也把所有 Sec-Fetch-Site: same-site 的請求(包含 POST 表單)無條件放行,導致攻擊者能用同站的兄弟子網域,或誘導使用者做一次跨站導覽,繞過原本要擋下的來源檢查。

第二個 CVE-2026-71257檔案上傳限制形同虛設:當前置的 servlet、filter 或框架(例如 Spring Boot 自帶的 multipart 解析器)已先消費掉 multipart 請求本體,Wicket 會退回呼叫 HttpServletRequest#getParts() 取得檔案,但這條路徑完全不會套用 Wicket 設定的單檔大小上限與檔案數量上限,也不會拋出例外。受影響元件包括搭配 FileUploadField 的 Form、FileUploadToResourceField 與 AjaxFileDropBehavior,只有透過 Commons FileUpload 解析時依 Content-Length 檢查的整體大小上限仍然有效。

第三個 CVE-2026-70449路徑穿越:資源查找時的 locale、style、variation 屬性會被直接拼進資源路徑字串,但 IPackageResourceGuard 的合法性檢查是在這些屬性被拼接「之前」執行,等於完全沒檢查這段攻擊者可控的路徑片段是否含有路徑分隔符。若前端 servlet 容器會正規化路徑穿越序列,未經驗證的攻擊者就能讀到 WEB-INF 底下平常不會被伺服的檔案,但仍受限於 SecurePackageResourceGuard 預設允許的副檔名清單(如 js、css、png、html、txt 等)。

CVE元件/機制問題修補版本
CVE-2026-71378ResourceIsolationRequestCycleListenerFetch Metadata 政策誤放行同站與頂層導覽請求,CSRF 繞過9.24.0 / 10.11.0
CVE-2026-71257multipart 檔案上傳getParts() 後備路徑未套用大小/數量限制8.19.0 / 9.24.0 / 10.11.0
CVE-2026-70449資源查找(locale/style/variation)路徑穿越,可讀取 WEB-INF 檔案8.19.0 / 9.24.0 / 10.11.0

受影響版本

  • CVE-2026-71378:Wicket 9.1.09.23.010.0.010.10.0 受影響(ResourceIsolationRequestCycleListener 於 9.1.0 才引入,8.x 僅用 Origin/Referer 檢查不受此政策影響)。
  • CVE-2026-71257CVE-2026-70449:皆為 8.0.08.18.09.0.09.23.010.0.010.10.0 受影響。

修補與緩解

三個漏洞的修補版本高度重疊,同一批 8.19.0 / 9.24.0 / 10.11.0 釋出即一次補齊。上傳限制的問題官方另提供應用層緩解:在框架或 servlet 容器層另外設定等效限制,例如 Spring Boot 的 spring.servlet.multipart.max-file-size 或 @MultipartConfig,可在 Wicket 修補之前先擋住超額上傳。CVE-2026-71378 與 CVE-2026-70449 分別由 Darren Carreras / Andre Kropp(Nexory)與 Michael Mullins / n0mi1k 回報,CVE-2026-71257 由 GitHub 使用者 @deprrous 回報。

漏洞機制(Apache Shiro)

CVE-2026-58301 出在 shiro-jakarta-ee 整合模組的「表單自動重送」功能:當使用者 session 逾時導致原本的 POST 請求被導去登入頁時,Shiro 會把原始表單資料加密快取起來,等使用者重新登入後自動重放這次請求並預設送回原本的 URI,避免使用者因逾時而遺失輸入內容。問題是這個重放流程對目的地主機/連接埠的驗證不足,讓低權限使用者可以構造請求,誘使伺服器把重放的 POST(含攻擊者可控的資料)送往攻擊者指定的外部主機,形同伺服器端請求偽造。

受影響版本與修補(Apache Shiro)

受影響版本為 2.0.0-alpha-03.0.0(此功能隨 Shiro 2.0.0 的 Jakarta EE 模組一起推出),修補版本為 3.0.1。若無法立即升級,官方提供系統屬性緩解:org.apache.shiro.form-resubmit-host 與 org.apache.shiro.form-resubmit-port,可限制表單重送流程只能連往白名單主機與連接埠。此漏洞由 Liyi Zhou、Ziyue、Strickland、Maurice Chng、Chenchen Yu 回報,修補由 Lenny Primak 開發、Andrea Cosentino 審查。

漏洞機制(QubesOS QSB-118)

QSB-118 描述的是 dom0 上 qvm-copy-to-vm 工具的錯誤回報通道遭濫用。Qubes 的 qfile 傳輸協定設計上會讓「目的地」虛擬機在傳輸結束後回傳確認訊息給 dom0,內容包含所有已傳輸檔案的校驗碼、錯誤代碼(如果有的話),以及最後一個收到的檔案名稱;一旦有錯誤,dom0 就會把這個檔名顯示在 GUI 對話框中。問題在於檔名的清理不完整:負責過濾的 sanitize_remote_filename() 只移除了非 ASCII 字元與引號,卻留下 shell 特殊字元;這個未完全清理的檔名之後被傳入 system() 呼叫,等於讓一個已被入侵、單純扮演複製目的地的 qube,能透過刻意命名的檔案在 dom0 上注入並執行任意指令。

受影響版本與修補(QubesOS QSB-118)

公告指出所有現行 Qubes OS 版本都受影響,目前釋出的修補鎖定 Qubes 4.3:qubes-core-dom0-linux 更新到 4.3.22 版即修正 sanitize_remote_filename() 的過濾邏輯。漏洞由 Tim C. 發現,官方建議使用者依一般更新流程套用更新,不需要額外的手動緩解步驟。

原始來源:oss-security:CVE-2026-71378(Wicket CSRF bypass)oss-security:CVE-2026-71257(Wicket upload limit bypass)oss-security:CVE-2026-70449(Wicket path traversal)oss-security:CVE-2026-58301(Shiro request redirection)Qubes Security Bulletin QSB-118


End of article
0
Would love your thoughts, please comment.x
()
x