2026-08-30 — rsyslog RainerScript 現堆積溢位、graphql-go/graphql 同批三個未修補漏洞

rsyslog RainerScript 的 replace() 函式現堆積緩衝區溢位,CVE-2026-78002 波及橫跨八年的版本線

rsyslog GitHub Security Advisory (GHSA-g72f-gc6v-f2w3) · 2026-08-26

rsyslog 專案於 2026-08-26 發布安全公告,確認 RainerScript 的 replace() 函式與三參數版本的 wrap() 存在堆積緩衝區溢位,編號為 CVE-2026-78002。受影響版本橫跨排定發行的 8.6.0 到 8.2608.0,以及 2026-08-24 之前釋出的每日穩定版。漏洞由 David Korczynski 回報,並由 Ada Logics 藉助 Anthropic 的 Claude 進行模糊測試後人工驗證,揭露郵件已於 2026-08-29 透過 oss-security 論壇公開。

漏洞機制

RainerScript 執行字串取代時分兩趟掃描來源字串:第一趟計算輸出所需的緩衝區大小,第二趟才實際寫入取代後的內容。問題出在兩趟掃描對「部分匹配失敗」的處理並不一致——取代表達式遇到特定的部分匹配失敗情形時,兩趟掃描會從不同的來源位置繼續往下掃描。這導致負責配置記憶體的計算趟得出的大小,小於實際寫入趟所需的空間,寫入階段便超出配置範圍造成堆積溢位。

由於三參數 wrap() 內部共用同一段取代邏輯,同樣的錯誤也存在其中。只要設定檔把 replace() 或 wrap() 套用在來自網路的未信任訊息內容上,遠端就有機會送出觸發特定部分匹配失敗模式的字串來破壞 rsyslogd 行程,例如下列樣板:

template(name="norm" type="string"
  string="%replace(%msg%, \"pattern\", \"repl\")%"
)

受影響版本

• 排定發行版本:8.6.0 至 8.2608.0
• 每日穩定版(daily stable):2026-08-24 之前的所有建置

修補與緩解

官方已在 2026-08-24 之後的每日穩定版建置中修正此問題,修補提交為 667e3f61aec5ee02c5c2ee6f0f8accf6fe4301a9,對應 PR #7525,並將併入即將發行的 8.2610.0。CVSS v3.1 評分為 7.5(High),影響型態限於阻斷服務與行程當機,公告中未展示可導致遠端程式碼執行的證據。升級前可先盤點設定檔中是否有對外部輸入呼叫 replace() 或 wrap() 的樣板,作為暫時風險評估的依據。

原始來源:GHSA-g72f-gc6v-f2w3、oss-security 公開揭露郵件

graphql-go/graphql 0.8.1 以下版本同批揭露三個未修補漏洞,其中一個型別混淆可致堆疊溢位當機

oss-security 郵件論壇 · 2026-08-29

資安研究員 William Carrier 於 2026 年 8 月 25 日至 29 日,在 oss-security 郵件論壇連續揭露 github.com/graphql-go/graphql(注意非 graph-gophers/graphql-go)的三個獨立瑕疵。三者都影響到目前最新的 v0.8.1 及以前所有版本,且截至揭露當下都沒有修補版本。其中兩個是演算法複雜度型阻斷服務(DoS),一個是純量型別驗證缺失導致的型別混淆與堆疊溢位,已取得編號 CVE-2026-80051。

漏洞機制

第一個瑕疵出在查詢驗證階段:當查詢引用未知型別名稱時,KnownTypeNamesRule 會對綱要(schema)中每一個型別呼叫 lexicalDistance(Levenshtein 距離)計算,產生「你是不是要打」的建議清單。只要在單一查詢中塞入大量未知型別名稱,計算量就會隨型別數與查詢長度呈平方成長,單一約 200 KB 的請求即可佔滿一顆核心近一分鐘。

第二個瑕疵藏在錯誤訊息的呈現邏輯裡。gqlerrors.highlightSourceAtLocation 在畫出語法錯誤的插入符號(caret)時,以逐字元附加空白字元的方式組字串,形成 O(n²) 的字串串接迴圈。只要送出一個含未閉合字串字面值的查詢,單一語法錯誤就能讓伺服器耗費約 54 秒 CPU,例如:

query { field(arg: "AAAA....AAAA
# 字串長度約 200 KB,結尾故意不加雙引號,觸發單一語法錯誤

第三個瑕疵則是規格遵循問題:coerceString 與 coerceBool 沒有依照 GraphQL 規格驗證傳入的純量變數是否符合宣告型別,錯誤型別的值會直接被接受。後續以 fmt.Sprintf 格式化這些值時,若輸入是刻意打造的深層巢狀陣列或結構,會在格式化套件內觸發無邊界遞迴,最終以 fatal error: stack overflow 讓整個行程直接中止,而非回傳規格要求的請求層級錯誤。

受影響版本

三個瑕疵都影響 graphql-go/graphql 自最早版本到目前最新的 v0.8.1,沒有任何分支或標籤已套用修補。前兩個 DoS 瑕疵的 CVE 編號仍在申請中,只有第三個型別混淆瑕疵取得 CVE-2026-80051。

修補與緩解

截至三篇揭露郵件發出時,上游都尚未釋出任何修補版本。在等待修補期間,可行的緩解方向包括:對查詢請求本體設定大小上限、在驗證層限制單一查詢中未知型別與語法錯誤可觸發的重複次數,以及在把使用者輸入格式化前先行檢查其型別是否與綱要宣告一致,避免依賴函式庫內部的隱式型別轉換。

原始來源:oss-security #4、oss-security #3、oss-security #2