資安雷達 2026 年 9 月 4 日

2026-09-04 — SiYuan 一次揭露 18 份公告、Apache Allura 四個 CVE、OpenStack Glance 再爆 SSRF

primary=https://github.com/advisories/GHSA-fph3-ghq9-vw66 primary=https://github.com/advisories/GHSA-5fhr-f75j-8wr9 primary=https://www.openwall.com/lists/oss-security/2026/09/03/4 primary=https://www.openwall.com/lists/oss-security/2026/09/03/3 primary=https://www.openwall.com/lists/oss-security/2026/09/03/2 primary=https://security.openstack.org/ossa/OSSA-2026-038.html

SiYuan 筆記軟體同日曝光 18 份資安公告:發布模式下的 SQL 注入與權限繞過連環爆

GitHub Security Advisories · 2026-09-03

漏洞機制

開源筆記軟體 SiYuan(思源筆記)在 2026 年 9 月 3 日同一天釋出 18 份 GHSA 資安公告,全部集中在 kernel 模組的「發布模式」(publish mode)存取邊界與 SQL 查詢層。其中最嚴重的 GHSA-fph3-ghq9-vw66(CVE-2026-69083)出在 /api/search/fullTextSearchAssetContent 端點:Method 2 直接把使用者傳入的 SQL 陳述式丟給 assetContentDB.Query() 執行,完全沒有像姊妹端點 fullTextSearchBlock 那樣限定管理員才能用;Method 3 則是用字串拼接組出 REGEXP 子句,卻沒有做單引號跳脫,對照組的 block 搜尋建構子則有呼叫 ReplaceAll(regexp, "'", "''")。這條路徑打中的是可讀寫的 asset-content 資料庫,且底層驅動支援 statement stacking,等於任何發布模式下的匿名訪客或 reader token 都能跨筆記本讀寫資料。GitHub 將其標為 Critical,CVSS 給到滿分 10.0。

第二份深入檢視的公告 GHSA-5fhr-f75j-8wr9(CVE-2026-72800)則是另一種模式:三支 API——getAttributeViewKeysByIDgetBlockDefIDsByRefTextgetBlockRelevantIDs——都漏掉了發布模式該做的存取過濾,分別會洩漏資料庫欄位結構(含下拉選單詞彙與樣板邏輯)、跨筆記本的 block ID,以及筆記本解鎖時的加密結構關係。程式碼裡剛好有一個做對的對照組 getAttributeViewKeys 確實套用了過濾,證明這條邊界原本就存在,只是這三支端點各自漏接。屬於 CWE-862(Missing Authorization),CVSS 3.1 為 5.8,標記 Moderate,影響僅止於機密性。

候選資訊裡把這批 18 份公告概括為四種類型:發布模式權限繞過、SSTI-to-SQL 串接、未授權 SQL 執行,以及 key/schema 洩漏。所謂 SSTI-to-SQL,概念上是指使用者可控的樣板或公式內容(例如筆記中的動態查詢區塊)先在伺服器端被求值,求值後的輸出又未經處理直接拼進 SQL 查詢字串,讓原本停留在樣板層的注入變成資料庫層的攻擊面。本文僅實際查證上述兩份公告的技術細節,其餘 16 份因批次公告的揭露節奏一致,推測落在同樣四種類型之中,但未逐一開啟公告頁面確認個別敘述。

受影響版本

兩份查證過的公告都指向同一個 Go module github.com/siyuan-note/siyuan/kernel,SiYuan 用的是 Go 的偽版本(pseudo-version)機制而非傳統語意化版號。CVE-2026-69083 影響所有早於 0.0.0-20260721004815-cf42dd5680c8 的建置,CVE-2026-72800 則是早於 0.0.0-20260724103335-f36331956ae9。兩個修補提交時間只差三天(7 月 21 日與 7 月 24 日),但一直到 9 月 3 日才對外統一揭露,顯示這是內部稽核後累積多個提交、再集中公告的批次處理模式。

修補與緩解

建議直接把 kernel 模組更新到不早於上述兩個修補提交的版本;由於問題核心在發布模式(publish mode)下的權限邊界,暫時不需要對外公開分享筆記的部署可以先關閉 publish mode 作為權宜緩解。CVE-2026-69083 的修補提交可在 siyuan-note/siyuan@cf42dd5 找到,兩份公告都建議升級到修補提交之後的版本以徹底解決,而非僅靠關閉發布模式治標。

GHSA ID說明
GHSA-fph3-ghq9-vw66(CVE-2026-69083)fullTextSearchAssetContent 端點可執行任意 SQL 與 REGEXP 注入,讀寫 asset-content 資料庫(Critical,CVSS 10.0)
GHSA-5fhr-f75j-8wr9(CVE-2026-72800)三支 API 漏做發布模式權限過濾,洩漏資料庫欄位結構與跨筆記本 block ID(Moderate,CVSS 5.8)
其餘 16 份:GHSA-8x84-r2ff-h8pqGHSA-jv8v-xq2h-657vGHSA-qvq9-hq6p-v378GHSA-vpjw-wf5h-cgpqGHSA-67x2-mq63-v9vmGHSA-6mcf-g667-w3qvGHSA-x67c-8pwr-m8g3GHSA-v7ph-r5r6-4jcjGHSA-3mp7-4rh5-jrv9GHSA-mw8r-mw84-88v2GHSA-q2vg-7qgx-x5fcGHSA-wgwx-479j-23vqGHSA-7j72-f6wg-cxw6GHSA-pm3w-vxp9-ccwcGHSA-36v8-mpjm-8j5rGHSA-69mh-gvh4-8gp7GHSA-7hm9-v7vf-7g4w同批次揭露,推測分屬前述四種類型之一,本文未逐一開啟公告頁面查證個別技術細節

原始來源:GHSA-fph3-ghq9-vw66GHSA-5fhr-f75j-8wr9


Apache Allura 一口氣揭露 4 個 CVE:Webhook SSRF 與雙重儲存型 XSS

oss-security mailing list · 2026-09-03

漏洞機制

Apache 軟體基金會在 2026 年 9 月 3 日透過 oss-security 郵件論壇一次公開 Allura 專案的四個 CVE,涵蓋 SSRF、兩個儲存型 XSS 與一個資訊洩漏。CVE-2026-80181 出在 webhook 功能,Allura 的 webhook 機制存在伺服器端請求偽造(SSRF)缺陷,攻擊者可藉此讓伺服器對外發出未經授權的請求。公告本身沒有寫出 webhook URL 驗證具體是怎麼被繞過的,只標記嚴重度為 Important,回報者是 n0mi1k。

CVE-2026-80180 則是 markdown 轉 HTML 處理流程裡的儲存型 XSS,惡意腳本會被持久化儲存並在渲染時執行,嚴重度標為 Critical,同樣由 n0mi1k 回報。根據候選揭露批次的標題,同批還有 CVE-2026-80190,描述為透過程式碼庫(code repository)瀏覽介面觸發的另一個儲存型 XSS,與 markdown 那個屬於不同注入點但同為輸出未跳脫的問題。本文僅對前兩個 CVE 開啟公告原文查證技術細節,後兩個以公開標題描述為準,未逐一開啟公告頁面。

CVE-2026-81270 依標題描述屬於透過搜尋功能造成的資訊洩漏,推測是搜尋結果回傳了呼叫者原本不該存取的內容或 metadata,但同樣未查證其完整敘述與細節。四個 CVE 在同一天以連號方式分別發信公告,顯示是同一輪內部安全稽核產出的修補批次,而非各自獨立發現。

受影響版本

已查證的 CVE-2026-80181CVE-2026-80180 都標示受影響版本為 Apache Allura 1.20.0 及之前所有版本,修補版本統一為 1.21.0。由於四個 CVE 是同一天、同一個修補版本一起發布,另外兩個 CVE 很可能沿用相同的版本區間,但因未逐一開啟公告頁面,本文不對 CVE-2026-80190CVE-2026-81270 的版本字串做斷言。

修補與緩解

Apache 官方的修補建議一致:升級到 Allura 1.21.0 即可涵蓋這四個 CVE。Allura 是 SourceForge 背後的專案託管平台,同時支援 ticket、wiki、程式碼瀏覽與 webhook 通知,若外部無法立即升級,對外開放的 webhook 設定與 markdown 轉 HTML 的訪客輸入來源應優先檢查與限制存取。

CVE類型說明
CVE-2026-80181SSRFWebhook 機制可被誘發對內部或任意網址發出請求(Important)
CVE-2026-80180儲存型 XSSMarkdown 轉 HTML 處理流程未跳脫,腳本被持久化儲存(Critical)
CVE-2026-80190儲存型 XSS程式碼庫瀏覽介面的另一個儲存型 XSS,依標題描述,細節未查證
CVE-2026-81270資訊洩漏透過搜尋功能洩漏不應存取的內容或 metadata,依標題描述,細節未查證

原始來源:oss-security: CVE-2026-80181oss-security: CVE-2026-80180


OpenStack Glance 三個 SSRF 漏洞:DNS Rebinding 繞過過濾打進雲端 Metadata

oss-security mailing list / OpenStack Security Advisory · 2026-09-03

漏洞機制

OpenStack 官方在 OSSA-2026-038 公告中揭露 Glance 映像檔服務裡三個彼此關聯的 SSRF 缺陷,分別編號 CVE-2026-71196CVE-2026-71197CVE-2026-71198,由 Luntry、switch.ch 與 Red Hat 的研究人員回報。第一個問題出在 web-download 匯入方式:預設的過濾規則不夠嚴謹,已通過驗證的使用者可以藉此讓 Glance 去抓取任意內部網址,包括雲端環境的 metadata endpoint。

第二個問題是 URI 驗證器沒有先做 DNS 解析就套用主機過濾規則,攻擊者只要用自己控制的網域名稱,就能在過濾檢查之後才透過 DNS rebinding 把解析結果換成內部 IP,直接繞過黑名單或白名單機制。第三個問題則是 HTTP image location API 在啟用 HTTP store 時完全沒有主機過濾,而且抓回來的內容會被存成可下載的映像檔資料,等於把原本頂多外洩存在與否的 blind SSRF,直接升級成可完整取出內容的資料外洩。三個缺陷組合起來,形成從發起請求到取出資料的完整攻擊鏈。

CVE問題點
CVE-2026-71196web-download 匯入預設過濾不足,可讀取任意內部網址與 metadata endpoint
CVE-2026-71197URI 驗證器未先做 DNS 解析,可用 DNS rebinding 繞過主機過濾
CVE-2026-71198HTTP image location API 未做主機過濾,抓取內容會被存成可下載映像檔,形成資料外洩

受影響版本

公告列出三個版本區間都受影響:Glance 版本 ≥16.0.0 且 <30.2.1、≥31.0.0 且 <31.1.1,以及 ≥32.0.0 且 <32.0.1。這個範圍橫跨 OpenStack 2025.1(epoxy)一路到 2026.2(hibiscus)共四個發行週期,代表問題存在的時間相當長,一直到這次稽核才被同時抓出來並統一編號揭露。

修補與緩解

官方總共釋出 16 個協調修補,分散在 2025.1/epoxy、2025.2/flamingo、2026.1/gazpacho、2026.2/hibiscus 四個發行週期,公告特別註明同一週期的四個修補必須依序套用,不能只挑其中幾個。對應的 Launchpad 追蹤編號為 #2158998、#2158999、#2161330 與 #2160020,尚未能立即套用修補的部署,可先檢查是否真的需要開放 web-download 匯入與 HTTP store,並在網路層面限制 Glance 對內部網段與 metadata 位址的存取。

原始來源:oss-security: OSSA-2026-038OSSA-2026-038


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