一則 Twitch 聊天訊息如何變成實況主電腦的遠端程式碼執行漏洞：OBS Studio 重大安全風險全揭露

一個有漏洞的聊天外掛、一個未啟用沙箱機制的 Chromium 渲染引擎，以及一個已被駭客在野外實際利用的 V8 漏洞——這三者的組合，足以將觀眾可控的文字內容轉化為實況主電腦上的原生程式碼執行，而 OBS 本身全程維持在預設設定狀態。

我發現了一個 Twitch 聊天外掛，它將觀眾的訊息以原始 HTML 的形式直接渲染在 OBS 的瀏覽器來源（Browser Source）內部。這意味著觀眾能夠在 OBS 內嵌的 Chromium 瀏覽器中執行 JavaScript。當時最新版本的 OBS 所搭載的 Chromium 編譯版本在執行時並未啟用其標準的沙箱機制，且其內建的 V8 引擎版本仍存在 CVE-2024-7971 的漏洞——一個已經在真實世界中遭到利用的資安缺陷。

整體串連起來，這則訊息從 Twitch 聊天開始，最終演變為對實況主機器的全面控制。

攻擊實證：OBS 32.2.2 上的遠端程式碼執行

一切的起點是一張截圖

我的一位朋友用 AI 輔助編寫（vibecoded）了一個小型的 Twitch 聊天外掛給 OBS 使用，並在社群媒體上分享了其截圖。如果你從未接觸過直播設定，聊天外掛基本上就是一個由 OBS 透過瀏覽器來源疊加在直播畫面上的小型網頁。它可以擷取即時聊天訊息、跑馬燈通知、捐贈提示，或任何你希望觀眾在畫面上看到的內容。

那張截圖恰好也顯示了部分程式碼內容，其中一行立刻引起了我的注意：聊天訊息被直接以 HTML 的形式插入到頁面中，完全沒有經過任何過濾或消毒處理。

引發這整個調查的推文

這是一個典型的 XSS（跨站腳本攻擊）漏洞。你很可能已經看過完全相同的設定模式：觀眾控制訊息內容，外掛將其視為 HTML 而非純文字處理，攻擊者可控的內容因此得以在頁面中執行程式碼。我相信不少人看到這裡已經在搖頭了，而這反應完全合理。

這讓我想起 Micode 過去拍攝的一部影片，內容是關於透過 OBS 的 WebSocket 介面發動攻擊。當時的概念是利用聊天 XSS 作為入侵點，再與 OBS 的本地端 WebSocket 伺服器進行通訊，進而觸發切換場景或停止直播等操作。

不過這條攻擊路徑在今天已經不太可行了。OBS 的 WebSocket 伺服器在預設情況下是關閉的，即便啟用也需要輸入密碼（系統會自動產生一組）。

我想要的是更強大的效果：僅需一則 Twitch 訊息、搭配最新版的 OBS、維持原廠設定、無需實況主任何互動，直接在機器本體執行程式碼。

WebSocket 這條路無法達成目標。

瀏覽器或許可以。

OBS 內部其實藏著一個完整的瀏覽器

OBS 的瀏覽器來源是透過 CEF（Chromium Embedded Framework，Chromium 嵌入式框架）驅動的 Chromium 引擎所運作。它被廣泛用於聊天視窗、跑馬燈、捐贈小工具、動畫效果以及自訂外掛。同樣的瀏覽器元件也支撐著瀏覽器面板（browser docks）和各項服務整合功能。

因此，這個看似迷你的聊天版面，其實是在 OBS 內嵌的一個完整 Chromium 瀏覽器中運作。

在 XSS 漏洞就位後，觀眾可控的 JavaScript 已經能夠在實況主機器上的 Chromium 中執行。

但光靠這點還不足以在 Windows 上達成程式碼執行。瀏覽器設有專門的安全邊界，正是為了防止網頁內容取得對主機的控制權。

然而 OBS 的瀏覽器缺少了一道關鍵防線。

Chromium 沙箱機制處於關閉狀態

Chrome 正常情況下會透過沙箱機制隔離渲染進程（renderer process）。即使攻擊者成功利用記憶體損毀漏洞，並在渲染進程內達成原生程式碼執行，通常仍須突破這層沙箱才能觸及主機系統。

OBS 在初始化其內嵌的 CEF 瀏覽器時，使用了以下設定：

CefString(&settings.log_file) = log_path_abs;
settings.windowless_rendering_enabled = true;
settings.no_sandbox = true;

uint32_t obs_ver = obs_get_version();
uint32_t obs_maj = obs_ver >> 24;

這段設定直接存在於目前的 obs-browser 原始碼中。

XSS 漏洞仍然只能為我們提供 JavaScript 執行能力。但若這段 JavaScript 能進一步利用 V8 引擎漏洞，並在渲染進程內升級為原生程式碼執行，則沒有任何 Chromium 沙箱可供逃逸了。

於是我檢查了 OBS 當時搭載的 Chromium 版本。只能說，結果並不如我所期望的那樣樂觀。

接著，CVE-2024-7971 加入了戰局

本文撰寫當時所測試的最新版 OBS（亦即我所檢測的版本），使用的是 Chromium 127.0.6533.120 以及 V8 12.7.224.18。

這個情況之所以值得關注，是因為 CVE-2024-7971——一個存在於 V8 中的型別混淆（type confusion）漏洞——會影響 128.0.6613.84 之前的所有 Chromium 版本。Google 於 2024 年 8 月 21 日在 Chrome 128 中修補了該漏洞。

這並非一個純理論性的瀏覽器漏洞。微軟已記錄到北韓威脅行為者（微軟將其代號命名為 Citrine Sleet）正在實際利用該漏洞，美國網路安全暨基礎設施安全局（CISA）也已將其列入已知遭利用漏洞（Known Exploited Vulnerabilities）目錄中。

在微軟觀察到的攻擊中，利用 V8 漏洞可在 Chrome 受沙箱保護的渲染進程內達成程式碼執行。攻擊者仍需仰賴另一個漏洞才能逃逸出沙箱。

但在 OBS 內部，這道屏障早已處於關閉狀態。

所有環節就這樣串連起來：

XSS 漏洞 → 未受沙箱保護的 V8 漏洞利用 → 渲染進程內的原生程式碼執行 → 主機系統控制權

攻擊鏈的建構過程

由於當時並無針對我所測試的特定 CEF 版本公開的漏洞攻擊實證，我自行建構了一套攻擊程式。

在開發過程中，我啟用了 Chromium 遠端除錯功能，並透過 DevTools 協定來檢查渲染進程及對漏洞利用程式進行除錯。

概括而言，V8 漏洞賦予了網頁原本不應擁有的記憶體存取能力。從這裡開始，漏洞利用程式將其擴展為更廣泛的進程記憶體存取能力，最終達成原生程式碼執行。

我刻意不在本文中公開漏洞利用的內部細節。

最終的結果比較容易說明：一名觀眾發送一則惡意的 Twitch 聊天訊息，有漏洞的外掛將其轉化為 JavaScript 執行，V8 漏洞利用程式再將其升級為原生程式碼執行，最終攻擊者得以在實況主的機器上執行任意程式碼。

關於「預設設定」的說明

這並不意味著任何全新的 OBS 安裝都能被 Twitch 聊天中的任何使用者遠端利用。在我的展示中，零點擊（zero-click）的入侵點在於那個有漏洞的外掛：實況主必須正在使用一個將觀眾可控內容未經妥善過濾即進行渲染的瀏覽器來源。

然而，一旦該頁面被載入，我並未對 OBS 進行任何弱化處理以使後續的攻擊鏈得以運作。不需要設定 WebSocket、不需要管理員權限、不需要使用者變更任何沙箱選項，也不需要實況主點擊任何東西。

Twitch 聊天外掛只是接觸到該瀏覽器的其中一種方式。更廣泛來說，任何被載入至 OBS 瀏覽器來源或瀏覽器面板的攻擊者可控頁面，原則上可能直接從瀏覽器漏洞利用階段開始。而聊天 XSS 是讓這個特定攻擊鏈從觀眾角度而言具備遠端且零點擊特性的關鍵環節。

因此，真正值得關注的部分並非 XSS 漏洞本身，而是攻擊者可控的網頁內容究竟在哪裡執行。

這件事為何重要

直播設定中充滿了網頁內容。聊天視窗、捐贈跑馬燈、追蹤通知以及自訂小工具，全都是網頁形式，而它們的資料有很大一部分來自網路上的陌生人。

如果聊天訊息是純文字，就應該將其作為純文字渲染。如果你確實需要 HTML 格式，請務必對內容進行妥善的過濾與消毒處理。

OBS 團隊的回應與處置

OBS 團隊已確認兩項修補工作都在進行中。

第一項是升級內嵌瀏覽器。主要的障礙在於新版 Chrome Runtime 直到最近才開始支援 OBS 所依賴的離屏渲染（off-screen rendering）機制。Chromium 127 於 2024 年 7 月進入穩定版，這意味著 OBS 32.2.2 所搭載的引擎版本目前已落後約兩年。

這項升級工作已在進行中：一個將 obs-browser 移轉至 CEF 128 以上版本的拉取請求（pull request）目前正在審核中，目標版本為 OBS Studio 33.0（obs-browser PR #523，obs-studio 討論串 #3853）。一旦合併，將可修補本文所使用的特定 V8 漏洞。然而 OBS 是一個主要由志願者維護的開源專案，要將這項升級推進至此階段，需要數個月的測試與相容性工作。

第二項修補是啟用 CEF 沙箱機制，同樣作為同一項更新的一部分進行測試。該機制當初之所以關閉，是因為它破壞了部分服務整合的身分驗證功能，但團隊推測這些問題目前可能已經解決。若沙箱能夠重新啟用，僅利用瀏覽器漏洞本身將不足以完成攻擊：攻擊者還需要第二個漏洞才能逃逸出沙箱。

對於一個核心任務就是渲染潛在不受信任網頁內容的元件而言，這兩層防護都至關重要。讓瀏覽器引擎的安全更新盡可能貼近當前版本，與在其周圍建立沙箱機制同樣重要。

在這些變更正式發布之前，仍掌握在每一個人手中的關鍵，是哪些內容會被載入這些外掛之中。任何瀏覽器來源內的內容都應被視為不受信任的輸入，尤其是絕對不應有任何小工具將觀眾的內容以 HTML 形式直接渲染。這是實況主或外掛開發者今天就能立即採取的修補措施。

漏洞揭露時程

目標版本：Windows 11 上更新至最新狀態的 OBS Studio 32.2.2

2026 年 2 月 14 日：與外掛作者進行協調。

2026 年 7 月：在 Windows 11 上完整重現整條攻擊鏈。

2026 年 8 月 19 日：通報 OBS 團隊。

2026 年 8 月 20 日：OBS 確認收到通報，CEF 更新作業進行中，依其政策不另行指派 CVE 編號。

2026 年 8 月 25 日：OBS 確認沙箱重新啟用作業正作為此次更新的一部分進行測試。

2026 年 9 月 10 日：PR #523 合併至 obs-browser。

2026 年 9 月 17 日：PR #13890 合併至 obs-studio。

2026 年 9 月 22 日：本文公開發布。