Chrome 修了个零日漏洞，你的 VS Code 和 Cursor 可能还在裸奔

9 月 3 号 Chrome 紧急推了个安全更新，修了 V8 引擎里一个零日漏洞，编号 CVE-2026-85046，CVSS 8.8，Google 确认已经在野被利用。如果你只用了 Chrome，自动更新完就没事了。但问题是------VS Code、Cursor、Discord、Slack 这些你天天打开的 Electron 应用，内嵌的 V8 引擎跟 Chrome 是同一套，而且它们不会自动更新 Chromium。 CISA 已经把这个漏洞列入 KEV 目录（已知被利用漏洞），要求联邦机构 9 月 18 号前完成修补。

你每天用的编辑器里跑着一模一样的 JS 引擎

很多人不知道，VS Code 底层跑的不是"类似 Chrome 的东西"------它直接内嵌了完整的 Chromium，包括 Blink 渲染引擎和 V8 JavaScript 引擎。Cursor 也是 Electron 应用，Discord、Slack 也是。这意味着 Chrome 里 V8 出了漏洞，这些应用里的 V8 一样有。这次 CVE-2026-85046 的问题出在 V8 的 JIT 编译器上。 V8 有两个优化编译器------TurboFan 和 Maglev------本质上是在赌。它观察到一段代码里某个变量一直是整数类型，就赌它永远是整数，据此生成快速路径的机器码。赌对了性能起飞，赌错了就是类型混淆。

具体到这个漏洞：V8 看到一个数组里全是小整数，标记成 PACKED_SMI_ELEMENTS，后续所有操作都按整数来处理。问题在于，如果攻击者能构造一个数组，让它的元数据标记是 PACKED_SMI_ELEMENTS，但实际存的是对象指针------V8 就会把指针当整数读出来。内存地址直接泄露，ASLR 形同虚设。反过来，写入时攻击者可以构造一个整数，V8 会把它当原始指针写入堆内存，任意地址写就到手了。报告这个漏洞的安全研究员 Salvatore Gulizia（网名 Serotav）描述得很具体，核心就是这种"类型标签"和"实际内容"不匹配的数组。两个编译器管线都有这个问题。

但沙箱还没被突破

有一个事实需要说清楚：这个漏洞能实现的是渲染进程沙箱内的代码执行。也就是说，攻击者通过一个精心构造的 HTML 页面，可以在 Chrome 的渲染器进程里运行代码，但这不等于拿到了整台机器的控制权。要从渲染沙箱逃逸到操作系统层面，还需要再链一个沙箱逃逸或者提权漏洞。 Google 没有公开说明在野攻击是否已经组合了沙箱逃逸，底层的 Chromium Issue Tracker 在补丁推送完成之前也限制访问。

不过话说回来，渲染器 RCE 本身就很危险了。你在浏览器里打开的每一个标签页都跑在渲染器里，如果攻击者能控制渲染器，至少可以做到窃取当前页面的所有数据、利用浏览器 API 做坏事，再配合一个尚未公开的沙箱逃逸就是完整的系统沦陷。

更关键的一点是，Electron 应用的渲染器和浏览器标签页的安全边界不太一样。很多 Electron 应用为了功能需要，开了 Node.js 集成（nodeIntegration）或者远程加载内容（remote 模块）。这意味着一旦渲染器被控制，攻击者可能直接获得文件系统访问、执行系统命令的能力------不需要沙箱逃逸，因为 Electron 自己把墙拆了。

不是说所有 Electron 应用都这样。VS Code 的安全模型做得相对严格，渲染进程和主进程之间的 IPC 通信有白名单校验。但 Cursor、Discord 这类应用的安全边界到底画在哪，说实话我不确定，它们的源码又不公开。 Firefox 和 Safari 不受这个漏洞影响------它们用的是 SpiderMonkey 和 JavaScriptCore，完全不同的引擎。但这不代表它们安全，只是说这次不是它们的问题。

这个漏洞是 8 月 4 号被报告给 Google 的，Gulizia 拿到了 1000 美元的赏金。从报告到补丁上线用了一个月，期间漏洞已经在野被利用。1000 美元赏金 vs 一个可用的渲染器 exploit 在黑市上的价格，这个差距本身就说明了很多问题。

Chrome 用户基本没事

Chrome 的自动更新机制会帮你搞定这件事。9 月 3 号的更新把版本推到了 152.0.7977.82（Linux）和 152.0.7977.82/.83（Windows/macOS）。确认方法也简单，地址栏输入 chrome://version，看 Google Chrome 那一行的版本号。只要 ≥ 152.0.7977.82 就没问题。如果你开着 Chrome 但一直没重启，更新可能还没生效------Chrome 的更新经常需要重启浏览器才会加载。 Edge 和 Brave 这些 Chromium 浏览器也在跟进各自的补丁，只是节奏比 Chrome 慢几天。去各自设置页面检查更新就行。但 Electron 应用完全是另一回事。

Electron 应用不会自动更新 Chromium

说实话，Electron 这个"打包时冻结 Chromium"的设计，在安全角度就是个坑。应用内嵌的 Chromium 版本在打包时就冻结了。应用不会自己去更新 Chromium，只有应用开发者发了包含新版 Chromium 的新版本，你安装之后才算补上这个漏洞。中间的更新延迟，攻击者早就利用完了。

Chrome 9 月 3 号就把 V8 修了，但你 VS Code 里的 V8 可能是几个月前打包的版本。Cursor 也是，Discord 也是，Slack 也是。 VS Code 通常更新比较勤快，微软跟进 Chromium 安全补丁的速度一般在一两周以内。VS Code 目前内嵌的应该是 Electron 32.x，对应 Chromium 128 左右------低于安全线，不过 VS Code 的更新推送比较快，应该很快就会跟进。但 Cursor 这种小团队维护的 Electron 应用就不好说了。Cursor 的更新节奏主要跟功能迭代走，安全补丁的跟进优先级往往排在后面。Discord 和 Slack 就更不用提了------它们的安全更新通知你什么时候收到过？

有些 Electron 应用用了 electron-updater 之类的自动更新框架，但那是更新应用本身，不是更新内嵌的 Chromium。很多人以为应用自动更新了就没问题，实际上内嵌的引擎版本完全取决于开发者什么时候发布包含新版 Electron 的构建。我写了个 bash 脚本，可以一键扫描本地常见的 Electron 应用。Linux 上直接跑，macOS 上部分应用路径可能不同需要自己改改。提前说一下：这个脚本能帮你快速定位哪些应用有潜在风险，但精确的 Chromium 版本还是得靠 DevTools 里的 userAgent 确认。

bash 复制代码

#!/bin/bash
# 查一下你机器上 Chromium 内核的版本
# 低于 152.0.7977.82 就有风险 (CVE-2026-85046)

echo "=== Chromium 版本扫描 ==="
echo "安全线: >= 152.0.7977.82"

# 浏览器
if command -v google-chrome &>/dev/null; then
    ver=$(google-chrome --version 2>/dev/null | grep -oP '[\d.]+' | head -1)
    echo "[浏览器] Chrome: $ver"
fi
if command -v microsoft-edge &>/dev/null; then
    ver=$(microsoft-edge --version 2>/dev/null | grep -oP '[\d.]+' | head -1)
    echo "[浏览器] Edge: $ver"
fi

echo "---"
echo "[Electron 应用]"

# 常见 Electron 应用 - 不在 PATH 里的检测不到，需要自己改路径
declare -A APPS=(
    ["VS Code"]="code"
    ["Cursor"]="cursor"
    ["Discord"]="discord"
    ["Slack"]="slack"
    ["Figma"]="figma-linux"
    ["Notion"]="notion-app"
)

for app_name in "${!APPS[@]}"; do
    bin="${APPS[$app_name]}"
    if command -v "$bin" &>/dev/null; then
        # 获取 Electron 版本
        electron_ver=$(timeout 10 $bin --version 2>/dev/null | grep -E '^[0-9]+.' | head -1)
        if [ -n "$electron_ver" ]; then
            echo "  $app_name: Electron $electron_ver (二进制: $bin)"
        else
            app_ver=$(timeout 10 $bin --version 2>/dev/null | head -1)
            echo "  $app_name: 应用版本 $app_ver (Chromium 版本需从应用内 DevTools 确认)"
        fi
    fi
done

echo "---"
echo "低于 152.0.7977.82 的赶紧更新。Chrome 重启一下就好，Electron 应用去官网看有没有新版本。"
echo "最准的办法：在应用里 Ctrl+Shift+I 打开 DevTools，Console 里输 navigator.userAgent 看 Chrome/ 后面的版本号。"

脚本检测不到的应用（比如从 .deb 包装的、命令不在 PATH 里的），直接在该应用里按 Ctrl+Shift+I 打开 DevTools，Console 里输 navigator.userAgent，返回字符串里就有 Chromium 版本号：

scss 复制代码

// Electron DevTools Console 里执行
console.log(navigator.userAgent);
// 输出类似：... Chrome/128.0.6613.178 Electron/32.1.2 ...
// 看 Chrome/ 后面的版本号，低于 152.0.7977.82 就有风险

今年第六个了

今年 Chrome 已经被薅了六个零日------2 月 CSS 的 use-after-free，3 月 Skia 越界写入加 V8 引擎漏洞连着来两个，4 月 Dawn（WebGPU 组件）也中招，6 月 V8 又出了个越界访问，现在 9 月这个也是 V8。六个里四个直接出在 V8 上。JIT 编译器到现在还是浏览器安全最软的一块。

如果你在开发 Electron 应用，而且涉及敏感数据处理，建议定期跟进 Chromium Stable 的安全更新节奏，别等大版本发布时才顺手更新引擎。Electron 提供了 process.versions.chrome 可以在应用启动时拿到内嵌的 Chromium 版本，加个检查低于安全基线就弹提醒，成本很低。

另外，nodeIntegration: true 这个配置能不开就别开。一旦渲染进程被攻破，Node.js 的直接访问权限等于给攻击者递了把万能钥匙。如果你的应用确实需要 Node 能力，至少用 contextIsolation: true 配合 preload 脚本做一层隔离，把敏感 API 通过 contextBridge 暴露而不是直接挂在 window 上。这些是 Electron 安全文档里反复强调的东西，但说实话，很多项目------包括一些热门项目------都没做到。