CVE-2026-70602

This CVE affects Electron applications that use session.loadExtension with separate session objects as a security control. If your app loads extensions into sessions other than the default, expecting that isolation to prevent extensions in one session from accessing contexts in another, your threat model is currently invalid. The API accepted the isolation parameter, the documentation described session-scoped behavior, but the implementation never enforced the boundary at the extension level. Check your code: if you're using session.loadExtension and passing anything other than session.defaultSession, verify whether you're doing so specifically to achieve security isolation between extension contexts. If you are, you have a vulnerability. The fix requires upgrading to version 39.5.0+, 40.5.0+, 41.0.0+, or 42.x-beta.3 and later — note that this spans multiple major versions, so review breaking changes in the Electron changelog before upgrading. The irony here is significant: you're only vulnerable if you invested in session-based extension isolation as a security measure. Developers who ignored session boundaries entirely are unaffected. This means the population most likely to be hit by this is exactly the population that believed they'd architecturally eliminated the risk. If you're in that group, your defensive investment created a false sense of security — the control you relied on was present in the API but absent in enforcement. This is a platform reliability failure, not a classic code vulnerability. Electron exposed a security-relevant API with documented isolation semantics that the implementation didn't actually honor. Treat any session-based extension loading patterns in your codebase as compromised until you've upgraded and re-verified your threat model.

Reviewed through automated stages and approved by a human before publication.