2026-08-25 — Apache Camel 七連發 CVE、rust-postgres 生態圈 panic DoS、LLM 推論引擎主機控制風險三則資安動態

Apache Camel 同日公布七個 CVE：header 過濾與路徑邊界檢查各自失守

openwall.com (oss-security) · 2026-08-24

Apache 軟體基金會於 2026 年 8 月 24 日在 oss-security 郵件論壇一次公布七個 Camel 元件的漏洞，橫跨 camel-undertow、camel-atmosphere-websocket、camel-platform-http-main、camel-google-storage、camel-azure-storage-blob、camel-knative 與 camel-azure-storage-datalake 七個模組。七個 CVE 的修補者同為 Andrea Cosentino，多數同步修復於 4.14.9（LTS）、4.18.4 與 4.22.0 三條版本線。問題可歸為兩類：協定專屬 header 未被過濾、以及檔案下載時缺少路徑邊界檢查，分屬不同元件卻在同一天被揭露。

漏洞機制

第一類集中在 WebSocket 與事件傳輸層。CVE-2026-78329（camel-undertow）的成因是 UndertowEndpoint 預設使用了通用的 HttpHeaderFilterStrategy，而非該元件專屬的過濾策略，導致 websocket.* 前綴的內部 header 未被攔截。CVE-2026-71300（camel-atmosphere-websocket）情況類似，外部呼叫者可以直接塞入 websocket.connectionKey.list 這類 header 來劫持訊息的派送目標。CVE-2026-63621（camel-knative）則是結構化模式（application/cloudevents+json）下的 CloudEvent 擴充欄位被原封不動複製進 Camel 訊息 header，讓攻擊者能注入 CamelHttpUri、CamelFileName 等內部欄位。三者的共同點是過濾邏輯只覆蓋了部份傳輸路徑，另一條路徑被遺漏。

// 簡化示意：CVE-2026-78329 的過濾策略遺漏模式
public class UndertowEndpoint extends DefaultEndpoint {
    // 修補前：退回使用通用 HTTP 過濾策略
    private HeaderFilterStrategy headerFilterStrategy
        = new HttpHeaderFilterStrategy();

    // 4.14.9 / 4.18.4 / 4.22.0：改用 Undertow 專屬策略
    // = new UndertowHeaderFilterStrategy();
}

第二類是三個雲端物件下載元件共用的路徑穿越問題。CVE-2026-66907（camel-google-storage）、CVE-2026-66906（camel-azure-storage-blob）與 CVE-2026-60093（camel-azure-storage-datalake）都是把雲端回傳的物件名稱直接拼接到本機下載目錄，未做正規化或邊界檢查。由於物件名稱可以包含 ../ 這類上層目錄片段，攻擊者若能影響儲存桶內的物件命名，就能讓 Camel 進程以自身權限在任意路徑寫入或覆蓋檔案。三者修補方式一致：升級後強制正規化解析路徑，並提供 regex 選項供使用者過濾物件名稱。

七個 CVE 中影響評級最高的是 CVE-2026-66908（camel-platform-http-main，Important）。當內嵌 HTTP 伺服器只設定了 keystore、卻未設定 jwtIssuer 或 jwtAudience 時，JWTAuthenticationConfigurer.buildJwtOptions 會回傳 null，使得核發者與受眾檢查被靜默略過。結果是任何由受信任金鑰簽署、尚未過期的 JWT 都會被接受，無論其實際核發者或目標對象為何。4.14.9 與 4.18.4 只先加入設定選項但預設值仍不安全，直到 4.22.0 才會在缺少必要設定時直接拒絕啟動。

受影響版本

• camel-undertow（CVE-2026-78329）：4.11.0–4.14.8、4.15.0–4.18.3、4.19.0–4.21.x
• camel-atmosphere-websocket（CVE-2026-71300）：4.0.0–4.14.8、4.15.0–4.18.3、4.19.0–4.21.x
• camel-platform-http-main（CVE-2026-66908）：4.8.0–4.21.x
• camel-google-storage（CVE-2026-66907）：4.0.0–4.14.8、4.15.0–4.18.3、4.19.0–4.21.x
• camel-azure-storage-blob（CVE-2026-66906）：4.0.0–4.14.8、4.15.0–4.18.3、4.19.0–4.21.x
• camel-knative（CVE-2026-63621）：3.15.0–4.14.8、4.15.0–4.18.3、4.19.0–4.20.x
• camel-azure-storage-datalake（CVE-2026-60093）：4.0.0–4.14.8、4.15.0–4.18.3、4.19.0–4.21.x

修補與緩解

無法立即升級的使用者可先套用臨時緩解措施。針對 WebSocket 與 Knative 相關的三個 CVE，可在路由中加入 removeHeaders("websocket.*") 或明確指定 headerFilterStrategy=#myStrategy 來補強過濾。三個雲端儲存路徑穿越問題則可透過 endpoint 的 regex 選項限制可接受的物件名稱，排除含路徑分隔符與上層目錄片段的名稱。JWT 驗證問題在未升級到 4.22.0 前沒有安全的臨時解法，只能盡快將 keystore 設定補上明確的 jwtIssuer／jwtAudience。

原始來源：CVE-2026-63621、CVE-2026-78329、CVE-2026-71300、CVE-2026-66908、CVE-2026-66907、CVE-2026-66906、CVE-2026-60093

Rust postgres 驅動生態圈同日修補三個 panic-based DoS 漏洞

github.com · 2026-08-24

GitHub Advisory Database 於 2026 年 8 月 24 日同時發布三個 rust-postgres 家族的安全公告，影響 tokio-postgres 與 postgres-protocol 兩個 crate。三個公告都尚未取得 CVE 編號，但都已標記為 Moderate 至 High 嚴重度。三者的共同根因是用戶端在解析伺服器回傳的資料時，沒有對長度或數值範圍做邊界檢查，只要連線的另一端是惡意或遭中間人竄改的 PostgreSQL 伺服器，就能觸發 panic 或資源耗盡。

漏洞機制

GHSA-3gjw-f78c-vvpw 出在 tokio-postgres：當伺服器回傳的 DataRow 實際欄位數少於 RowDescription 宣告的欄位數時，讀取缺漏的欄位會直接觸發陣列越界 panic。公告特別指出，這個問題連原本設計成不會 panic 的 try_get 也無法倖免，Row 與 SimpleQueryRow 兩種型別都受影響，CVSS v4 評分為 6.9（CWE-125，越界讀取）。

// 簡化示意：DataRow 欄位數不一致引發的越界 panic
let n_expected = row_description.columns.len();
let n_actual = data_row.values.len(); // 伺服器可回傳更少的欄位
let value = &data_row.values[col_index]; // col_index 超出 n_actual 時 panic

GHSA-rgqc-3x5p-6gwg 則在 postgres-protocol 的 hstore 型別解碼路徑：伺服器回傳帶有無效內部長度欄位的二進位 hstore 值時，解碼過程會直接 panic 造成用戶端當掉，CVSS 同樣是 6.9（CWE-20 / CWE-248）。兩個 panic 型漏洞都需要應用程式連線到不受信任的資料庫，或連線被中間人攔截竄改，才會真正暴露風險，只連受信任資料庫的應用程式影響有限。

第三個公告 GHSA-5x78-73v4-xg6w 嚴重度最高，CVSS v4 達 8.7（High，CWE-770）。問題出在 SCRAM-SHA-256 驗證階段：postgres-protocol 直接使用伺服器提供的 PBKDF2 迭代次數做金鑰推導，沒有上限或節流，惡意伺服器只要回傳一個極大的迭代次數，就能讓用戶端的 tokio 工作執行緒長時間卡住，形成 CPU 耗盡型阻斷服務。這與前兩個單純觸發 panic 的漏洞不同，屬於資源濫用而非記憶體存取錯誤。

受影響版本

• tokio-postgres（GHSA-3gjw-f78c-vvpw）：>= 0.7.0, < 0.7.18
• postgres-protocol（GHSA-rgqc-3x5p-6gwg）：< 0.6.12
• postgres-protocol（GHSA-5x78-73v4-xg6w）：0.3.0 – 0.6.11

修補與緩解

由於 tokio-postgres 依賴 postgres-protocol，使用者需要同時把兩個 crate 都升級到修補版本才能完整解決問題：postgres-protocol 升到 0.6.12，tokio-postgres 升到 0.7.18。三個公告都強調，只連接受信任、非公開存取的 PostgreSQL 伺服器的應用程式暴露面較小；一旦連線目標可能是使用者自建、第三方託管或存在中間人竄改風險的資料庫，就應優先套用這次更新。目前三個問題都尚未各自對應到獨立的 CVE 編號，僅以 GHSA 識別碼追蹤。

原始來源：GHSA-3gjw-f78c-vvpw、GHSA-rgqc-3x5p-6gwg、GHSA-5x78-73v4-xg6w

研究者示警：惡意開源 LLM 或可利用推論引擎漏洞奪取主機控制權

boydkane.com（經 news.ycombinator.com 討論）· 2026-08-24

獨立研究者 Boyd Kane 於 2026 年 8 月 24 日發表文章〈LLMs could control their host machines by exploiting inference engines〉，隔日登上 Hacker News 首頁並累積 74 分、37 則留言。文章主張執行中的 LLM 若被誘導或自主產生惡意輸出，可以透過特定 token 序列觸發推論引擎（如 vLLM、SGLang）中的漏洞，進而取得承載其模型權重之主機的控制權。文章指出，這類主機同時具備前沿模型所需算力、模型權重存取權，以及資料中心內部網路的較高權限，是極具價值的攻擊目標。

漏洞機制

作者描述的攻擊路徑，是 LLM 產生的 token 序列本身語意上可能毫無意義，卻恰好觸發載入模型、執行推論、解析輸出這條 pipeline 中某個環節的漏洞。文章以 CVE-2025-9141（GHSA-79j6-g2m3-jgfw）作為既有案例：vLLM 針對 Qwen3-Coder 的 XML 工具呼叫解析器，在遇到型別不明的參數時會把整個字串傳入 Python 的 eval()。只要模型被誘導產生特定格式的工具呼叫參數，伺服器端就會執行任意程式碼，該漏洞 CVSS 3.1 評分達 8.8，修復於 vLLM 0.10.1.1。

# 簡化示意：CVE-2025-9141 的 eval() 解析模式
def parse_tool_arg(value, expected_type):
    if expected_type is None:
        return eval(value)  # 型別不明時退回 eval，任意程式碼執行
    return cast(value, expected_type)

文章進一步指出，vLLM 目前支援兩百多種模型架構與多種聊天樣板格式，解析邏輯的複雜度本身就是攻擊面的來源，C++ 與 CUDA 撰寫的底層元件則被視為更誘人的目標，因為記憶體越界存取一旦被觸發，影響範圍是 GPU 或控制 GPU 的主機，而非單純的 Python 進程。作者推測隨著開放權重模型能力增強，會有更多模型運行在較新、審查較少的推論引擎上，觸發並利用此類漏洞的機率也隨之上升。

受影響版本

• 已知具體案例：vLLM < 0.10.1.1（CVE-2025-9141，Qwen3-Coder XML 工具解析器）
• 文章泛稱的潛在風險範圍：vLLM、SGLang 等主流開源推論引擎的 C++／CUDA 執行與輸出解析路徑，無特定版本，屬前瞻性威脅模型而非既有漏洞列表

修補與緩解

作者提出的緩解方向，是把 GPU 運算與負責解析模型輸出的元件拆到不同機器上，讓推論引擎輸出的資料在跨機器邊界時被當作不受信任輸入處理。對承載主機本身也應限制其對資料中心其餘系統的存取權限，避免單一推論引擎漏洞被連鎖利用為橫向移動的跳板。Hacker News 討論串中，也有讀者分享實務作法：把 vLLM 部署在獨立沙箱虛擬機，關閉 DNS 與網域控制器存取，並將日誌基礎設施隔離；另有留言質疑文章對「LLM 為何會主動觸發漏洞」的動機描述過於模糊，認為多數正式環境本來就是多 GPU 叢集而非單機部署。

原始來源：Boyd Kane 原文、Hacker News 討論、GHSA-79j6-g2m3-jgfw