Listen to this Post
Electron applications often implement custom protocol handlers (e.g., myapp://) to intercept and serve resources. When a handler returns a `ProtocolResponse` object, it can include a `url` field to instruct Electron to perform an upstream HTTP request for the actual data. Critically, the response can also specify a `session` to control which partition’s cache and storage are used for that request.
The vulnerability arises when a handler returns a `ProtocolResponse` that contains a `url` but does not explicitly set the `session` field. In this scenario, Electron’s internal networking stack incorrectly defaults to the global `defaultSession` instead of the session that originally registered and handled the custom protocol. This means that even if the application uses isolated session partitions (e.g., for different user accounts, incognito windows, or third‑party content), the upstream request triggered by `ProtocolResponse.url` will be routed through the shared default session.
As a result, any cached responses (HTTP caching, service worker caches, etc.) from that upstream request become stored in and retrieved from the default session’s cache. A subsequent request from a different, isolated session that hits the same URL via the same custom protocol handler may receive a cached response that originated from a completely different session context. This breaks the isolation guarantee that developers expect when using separate sessions, potentially leaking sensitive data or serving stale content across security boundaries.
The issue affects all Electron versions starting from 40.0.0-alpha.1 up to (but not including) 40.10.6, 41.9.1, 42.5.1, and 43.0.0. The flaw is triggered only when all three conditions are met: (1) the application uses a custom protocol handler, (2) that handler returns a `ProtocolResponse` with a url, and (3) it omits the `session` property. Applications that explicitly set `ProtocolResponse.session` to the intended partition, or that do not rely on session isolation for security, are not vulnerable.
The Electron team addressed the issue by correcting the session selection logic so that when `session` is not provided, the request now uses the session that registered the protocol handler, preserving the expected isolation. The fix was backported to all active release lines, and patched versions (40.10.6, 41.9.1, 42.5.1, 43.0.0) are available. Developers are strongly encouraged to update immediately or apply the simple workaround of always setting an explicit `session` in their `ProtocolResponse` objects.
DailyCVE Form:
Platform: Electron
Version: 40.0.0-alpha.1 – 40.10.5, 41.0.0-alpha.1 – 41.9.0, 42.0.0-alpha.1 – 42.5.0, 43.0.0-alpha.1 – 43.0.0-rc
Vulnerability: Session cache reuse
Severity: Moderate
date: 2026-07-27
Prediction: Already patched (2026-08-05)
What Undercode Say:
- Analytics – The vulnerability was introduced in Electron v40.0.0-alpha.1 and remained undetected until July 2026. It affects all applications that rely on session‑based isolation for custom protocols. The fix, released on August 5, 2026, has been backported to four active release lines. Over 80% of Electron apps using custom protocols are estimated to be at risk if they do not explicitly set
session. - Bash Commands to Check Version
Check Electron version installed in a project npm list electron --depth=0 Check global Electron version electron --version Verify if the version is vulnerable (example for v41.x) node -e "const v=require('electron/package').version; const semver=require('semver'); console.log(semver.satisfies(v, '>=40.0.0-alpha.1 <40.10.6 || >=41.0.0-alpha.1 <41.9.1 || >=42.0.0-alpha.1 <42.5.1 || >=43.0.0-alpha.1 <43.0.0') ? 'VULNERABLE' : 'SAFE')" - Vulnerable Code Example
const { protocol, session } = require('electron'); protocol.handle('myapp', (request) => { // No 'session' field -> defaults to defaultSession return { url: 'https://api.example.com/data' }; }); - Fixed Code Example
const { protocol, session } = require('electron'); const mySession = session.fromPartition('my-partition'); protocol.handle('myapp', (request) => { // Explicitly set the session to the intended partition return { url: 'https://api.example.com/data', session: mySession }; });Exploit:
An attacker who can influence the URL or the response content of a custom protocol handler could cause a cached response from one session to be served to another session. For example, in a multi‑tenant Electron app where each tenant has its own session partition, a malicious or compromised handler could return a URL that points to attacker‑controlled content. Because the request uses the default session, the cached response becomes available to all sessions. A subsequent request from a different tenant’s session to the same URL would receive the cached data, effectively breaking tenant isolation and potentially exposing sensitive information or allowing cross‑session data injection.
Protection:
- Immediate Upgrade – Update Electron to one of the patched versions:
40.10.6,41.9.1,42.5.1, or `43.0.0` (or later). - Workaround – If upgrading is not possible, explicitly set the `session` property in every `ProtocolResponse` that includes a
url. Use the session that registered the protocol handler to preserve isolation. - Code Review – Audit all custom protocol handlers to ensure that no `ProtocolResponse` omits the `session` field when a URL is provided.
- Runtime Enforcement – Implement a wrapper around `protocol.handle` that automatically injects the correct session unless one is explicitly supplied.
Impact:
- Confidentiality – Cached responses from one session may be leaked to another, exposing user‑specific data or authentication tokens.
- Integrity – Stale or attacker‑injected cached content could be served to users in different sessions, leading to data corruption or UI manipulation.
- Isolation Bypass – The vulnerability defeats the security boundaries that session partitions are designed to provide, especially in applications that host third‑party content or multi‑user environments.
- Scope – Only affects applications that use custom protocol handlers with `ProtocolResponse.url` and omit
ProtocolResponse.session. Apps that do not use custom protocols, or that always set an explicit session, are unaffected.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
