OBS 里的一条弹幕，能在你电脑上跑代码

直播间的观众消息，一直被当成一行文字。它落在画面上的时候，其实是一段可以被执行的代码。中间不需要主播点任何东西，也不需要管理员权限。

安全研究员 Dylan Iffrig-Bourfa 把这条链路完整跑通了，过程记在他的技术博客里。起点是一个直播间悬浮窗：它把观众发来的消息直接塞进网页，当成 HTML 渲染，没有做任何转义。观众因此能在那个页面里跑 JavaScript，也就是教科书里的跨站脚本漏洞。

到这一步，观众拿到的还只是脚本。让事情变严重的是直播软件 OBS Studio 的浏览器部件。弹幕框、打赏提醒、关注提示这些挂件，全跑在 OBS 内嵌的 Chromium 里，走的是 CEF 这个框架。而 OBS 把 CEF 的 Chromium 沙箱关掉了。

沙箱本来是最后一道墙。攻击者就算在渲染进程里拿到代码执行，还得再找一个沙箱逃逸漏洞，才能碰到真正的系统。墙不存在，这一步就被省掉了。

同一段代码，两种墙：普通浏览器有沙箱，OBS 内嵌的沙箱被关掉

最后一步用的是老漏洞。OBS Studio 32.2.2 打包的 Chromium 是 127.0.6533.120，V8 引擎是 12.7.224.18。CVE-2024-7971 是 V8 里的类型混淆问题，Google 在 2024 年 8 月的 Chrome 128 就修掉了，CISA 把它列进了已知被利用漏洞清单，微软也记录过朝鲜黑客组织拿它打真实目标。两年之后，带着这个漏洞的引擎版本还在直播软件里跑。

这笔账拖了多久：内嵌引擎 127，修好要 128 以上

所以这条链上每一环都不新鲜：不转义的悬浮窗、关掉的沙箱、没升级的引擎。新鲜的是它们刚好凑在同一条路径上，而路径的入口，是任何一个人都能往直播间发的一句话。

这里得说清边界。默认装好的 OBS 不会被随便一条弹幕打穿，前提是主播用了那个把观众内容当 HTML 渲染的悬浮窗。研究员本人也没有为演示去削弱 OBS：没开 WebSocket 接口，没提权，没改沙箱选项，没要点任何一次点击。决定风险大小的，是往浏览器源里塞了什么。凡是能往浏览器源、浏览器面板里加载页面的位置，都可能从浏览器利用那一步直接起步。

OBS 团队的响应不算慢。2026 年 8 月 19 日报过去，第二天就确认收到；8 月 25 日确认在测试把沙箱重新打开；9 月 10 日 obs-browser 的 PR #523 合并；9 月 17 日 obs-studio 的 PR #13890 合并。两个改动的内容，是把内嵌浏览器升到 CEF 128 以上，再试着恢复沙箱。沙箱当初被关，是因为它会影响部分服务集成的登录，团队现在认为那些兼容问题已经解决了。

从复现到合并：2026 年 2 月联系作者，9 月两个修复合并

慢的地方在别处。桌面直播软件要把画面渲染在屏幕外，新的 Chrome 运行时很长一段时间不支持这种离屏渲染，升级 CEF 的改动卡在了这里。Chromium 127 在 2024 年 7 月进入稳定版，也就是说 OBS 手里的引擎落后了两年多，而修好它的 33.0 只走到测试版。官方下载页上挂着的稳定版，还是 8 月 14 日发布的 32.2.2。今晚还要开播的人，装不到修好的版本。

别急着把悬浮窗删掉就完事，它有个坑：挂件换掉一批，跑的仍是同一个旧引擎，风险留在原地。今天能做的只有一件事，把浏览器源里的观众输入当成不可信内容，观众消息按纯文本插入，需要 HTML 的应用自己先做转义。

判断自己在不在里面也不难。把场景里的浏览器源挨个打开，看地址从哪来。页面是自己写的，风险取决于自己的代码；挂件是别人给的，风险取决于那个作者怎么处理观众输入。来源说不清的，先停用再说。

这事最讽刺的是：被利用的那个漏洞，在浏览器世界里两年前就补上了，它的寿命是被一个不升级的决定拖长的。

最贵的漏洞，是那个你决定不升级的引擎。