Electron 44: Where the Real 2026 Vulnerabilities Are

Short answer: Electron's core isolation defaults are actually solid now — context isolation has been on by default since Electron 12 (2020), and the renderer sandbox since Electron 20 (2022). Seven CVEs disclosed against Electron in 2026 didn't break either of those. Four of them bypass isolation through the contextBridge API itself — the sanctioned channel for passing data between an isolated preload script and the page, not a hole in the sandbox. If your app exposes Promise-returning functions or transferable objects (like VideoFrame) across that bridge, that's the thing worth auditing, not whether contextIsolation is turned on.

The defaults Electron actually got right

It's worth saying plainly, because Electron's reputation as "just a browser with full OS access bolted on" is a few years out of date. Two defaults changed that:

Context isolation, default since v12. Your preload script and Electron's own internals run in a JavaScript context separate from the web content you load. A page can't reach into window and grab whatever your preload script attached — unless your preload script deliberately exposes it.

Renderer sandboxing, default since v20. Renderers lose OS-level access — file system, native modules, shell — unless an app explicitly opts out with nodeIntegration: true or sandbox: false. Chromium's own process sandbox does the enforcing.

Both of these have to be turned off on purpose to create the classic "XSS becomes RCE" failure mode. Most current Electron apps don't do that. Which is exactly why the 2026 CVE list looks different from the sandbox-escape headlines Electron used to make.

Why these defaults exist at all

Electron's isolation defaults weren't a design choice made in a vacuum — they came out of a genuinely bad stretch in 2018. CVE-2018-1000006 let an attacker execute code on a user's machine through a maliciously crafted custom-protocol link, no vulnerability in the host app required, and it hit Skype, Slack, GitHub Desktop, Twitch, and WordPress.com. A few months later, CVE-2018-1000136 showed that a page loaded inside a <webview> tag could flip nodeIntegration to true on itself through a mishandled configuration path — turning full Node.js access on from inside the sandbox, in an app that never intended to grant it. That one landed on Signal Desktop, Slack, Discord, Atom, VS Code, and GitHub Desktop simultaneously, because they all shared the same framework-level gap.

Neither CVE required a mistake in any individual app's business logic. The framework itself was handing out more trust than any of those apps meant to grant. That's the direct reason Electron moved contextIsolation and the renderer sandbox from opt-in to mandatory-by-default over the next few years — the 2018 incidents are the origin story for the defaults section above, not an unrelated history lesson. It's also why the 2026 CVE list reads so differently: none of the seven require an app to have made an unusual configuration mistake. They're edge cases in the API designed to be the safe way to cross the boundary, which is a meaningfully smaller and shallower bug class than "the whole security model can be disabled by a web page."

Seven CVEs, all disclosed in 2026

CVE	Mechanism	Severity	Fixed in
CVE-2026-70601	contextBridge functions returning a Promise can have Function.prototype.bind hijacked, letting web content reach into the isolated preload world	CVSS 7.5	39.8.9, 40.9.2, 41.2.2, 42.0.0-beta.5
CVE-2026-34780	Passing a VideoFrame (WebCodecs API) across contextBridge lets an attacker who can run JS in the page use it to reach the isolated world, including any Node.js APIs the preload script exposes	High	39.x / 40.x / 41.x patch line
CVE-2026-34765	window.open() named-target lookups weren't scoped to the opener's browsing context — a renderer could navigate a window opened by an unrelated renderer and inherit its setWindowOpenHandler permissions	Disputed, up to CVSS 8.8	Patched via GHSA-f3pv-wv63-48x8
CVE-2026-34769	Renderer command-line switch injection through the undocumented commandLineSwitches webPreference, if an app spreads untrusted config into it	CVSS 7.8	Current stable line
CVE-2026-34770	Use-after-free in powerMonitor on Windows and macOS	CVSS 7.0	Current stable line
CVE-2026-70610	Prototype pollution reachable through objects copied across contextBridge	CVSS 5.4	Current stable line
CVE-2026-70612	Sandboxed <iframe>s could still trigger an OS-registered external protocol handler, bypassing the iframe sandbox	CVSS 5.4	39.8.8, 40.9.0, 41.2.1, 42.0.0-beta.3

Look at the pattern rather than any single row: five of the seven touch contextBridge directly, and the other two (window-open scoping, command-line injection) are still about what one part of an Electron app can hand to another across a trust boundary — not the OS-level sandbox Chromium enforces. That boundary held. The API built to cross it safely didn't, in these specific shapes.

Why contextBridge is the boundary that actually matters now

contextBridge.exposeInMainWorld() exists so a preload script can hand a page a narrow, safe API instead of the page getting raw Node.js access. It works by structured-cloning values across the isolation boundary — and structured clone has edge cases. A function that returns a Promise doesn't clone the same way a plain value does. A VideoFrame carries more than its surface API suggests. An object with a crafted __proto__ can pollute the prototype chain on the other side.

None of this is a flaw in the isolation model. It's the cost of the isolation model having a deliberately narrow gate — and every gate is worth checking for what actually passes through it. If your preload script's exposeInMainWorld calls hand back anything more complex than plain data (a function, a class instance, a Promise, a browser-native object), that's the part of your app these CVEs are actually about.

ASAR integrity: stable since v39, off unless you turn it on

Electron packages an app's code into a single app.asar archive. ASAR integrity checking validates that archive against a build-time hash at runtime, and refuses to launch if it's been tampered with — useful against a distributed build getting patched after the fact. It went stable in Electron 39. It is not enabled by default.

Turning it on means setting the EnableEmbeddedAsarIntegrityValidation fuse at build time — and it's worth pairing with the onlyLoadAppFromAsar fuse too, otherwise the check can be sidestepped by loading app code from outside the archive entirely. As of Electron 41, macOS builds can also embed a digest of the integrity data itself, so the check can't be quietly stripped out of the packaged app.

This is a completely different kind of gap from the CVEs above — nobody has to find a bug for it to matter. It's a real, working protection that most Electron apps simply haven't turned on.

Auditing your own Electron app: where to actually look

Most of this comes down to reading two files carefully — every BrowserWindow's webPreferences, and the preload script it points to.

Check every BrowserWindow constructor for its webPreferences. contextIsolation and sandbox should both be at their default (unset, or explicitly true). If either is set to false, or nodeIntegration is set to true, that window needs a real reason — a specific feature that genuinely can't work otherwise — not a leftover from an early prototype that never got cleaned up.

Read every contextBridge.exposeInMainWorld() call and check what it returns. Plain data — strings, numbers, plain objects and arrays of those — is fine. A function that returns a Promise, a class instance, or a browser-native object like VideoFrame is the shape CVE-2026-70601 and CVE-2026-34780 target. If you're exposing something more complex than plain data, either simplify what crosses the bridge, or confirm you're on a patched Electron version (39.8.9 / 40.9.2 / 41.2.2 or later).

Check commandLineSwitches and any other webPreference built from a config object. If any part of that object's shape comes from something outside your own codebase — a remote config, a user setting, an env var you don't fully control — spreading it directly into webPreferences is the pattern CVE-2026-34769 exploits.

If you use setWindowOpenHandler to grant elevated webPreferences to child windows, confirm the app doesn't also open multiple top-level windows with different trust levels using the same window.open() target name — that combination is what CVE-2026-34765 depends on.

Check whether the EnableEmbeddedAsarIntegrityValidation and onlyLoadAppFromAsar fuses are set in your build config (electron-builder or electron-packager, depending on which you use). If neither shows up in your fuse configuration, ASAR integrity checking isn't running, regardless of what Electron version you're on.

Confirm what Electron version is actually in the shipped build, not what's in package.json's dependency range. Electron only backports fixes to the latest three stable majors — a ^38.0.0 range that hasn't been bumped in eight months can resolve to a version that's already outside the support window.

None of these are large changes. They're each a few minutes of reading real code against a known pattern — which is the whole point. The 2026 CVEs aren't asking for an architectural rework, they're asking for the same kind of specific, boring review any dependency update deserves.

What this looks like on a real build

Matchups, the branded sports browser we built on Electron, is a useful example of exactly why this boundary matters — not because it shipped with any of these specific CVEs, but because of why we chose Electron for it in the first place. Matchups needed multiple isolated browser sessions running at once, each with its own cookies, storage, and login state, with zero bleed between them. Chromium's own architecture draws a hard line against that kind of session control at the application layer. Electron's full Node.js runtime and OS access is what made it possible — we built the isolated-profile system ourselves, at the application layer, specifically because Chromium's sandboxing explicitly prevents an app from doing that from the outside.

That's the honest trade this whole post is about. The same power that let us build real session isolation for Matchups — a full runtime, deliberate control over what crosses which boundary — is exactly the category of surface these 2026 CVEs live on. Electron not fighting you the way Chromium does is a feature when you're the one deciding what gets exposed. It's the reason to actually look at what your own contextBridge calls hand back, instead of assuming the framework's isolation defaults cover it for you.

What's on by default vs. what's still your job

	On by default	Still your responsibility
Renderer isolation	contextIsolation since v12, sandbox since v20	Not re-enabling nodeIntegration or sandbox: false without a real reason
contextBridge exposure	Structured-clone boundary enforced	Auditing what functions/objects you expose — Promises, transferables, deep objects
Build tampering	ASAR integrity code shipped, stable since v39	Enabling the EnableEmbeddedAsarIntegrityValidation + onlyLoadAppFromAsar fuses
Security patches	Fixes ship on the current stable line	Actually staying within Electron's 3-supported-release window — 8-week major cadence means falling behind compounds fast
Window/webPreferences trust	Chromium process model	Not granting elevated webPreferences to windows opened via setWindowOpenHandler without checking who opened them

---

Running an Electron app that hasn't had a real security pass since it shipped? Isolation defaults changing over several major versions means an app built two or three years ago is worth auditing against what's current, not just left alone because it hasn't broken yet. Our desktop app development team builds and hardens Electron apps for exactly this — if you'd rather have someone else own the contextBridge audit and the update cadence, hire Electron developers who already do this work.

Sources: Electron Security guidance and Context Isolation docs; ASAR Integrity and Electron Fuses docs; Electron Releases timeline and Electron 44 release notes; CVE-2026-70601, CVE-2026-34780, CVE-2026-34765 (GHSA-f3pv-wv63-48x8), CVE-2026-34769, CVE-2026-34770, CVE-2026-70610, and CVE-2026-70612 advisories; CVE-2018-1000006 and CVE-2018-1000136 historical disclosures. Matchups architecture details from our own delivered project.