> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # Electron: File and HTTP protocol handlers allow cross-origin reads without corsEnabled - URL: https://f4n6.co.uk/security-feed/electron-file-and-http-protocol-handlers-allow-cross-origin-reads-without-corsenabled/ - Published: 2026-09-29T23:53:59.000Z - Updated: 2026-09-29T23:53:59.000Z - Author: Jeff Davies - Tags: #security-feed, CVE-2026-70604 ## 1\. Executive summary Electron has shipped a follow-up fix for CVE-2026-70604, a CORS enforcement gap in custom protocol schemes registered with `supportFetchAPI: true` but without `corsEnabled: true`. A page loaded from a remote origin could `fetch()` or `XMLHttpRequest` such a scheme cross-origin and read the full response body, including data served through `protocol.registerFileProtocol` or `protocol.registerHttpProtocol`. The verified reference data records CVE-2026-70604 at CVSS 7.4 HIGH, CWE-942, EPSS 0%, and not listed in CISA KEV; the advisory text describes this release as the completion of that fix, so the residual exposure is the handler path the earlier patch did not cover. EMEA financial services exposure is limited to desktop and internal tooling built on Electron that registers a custom scheme, serves it through one of those handlers, and loads untrusted content in a renderer that can reach it. Apps that set `corsEnabled: true` or do not load untrusted content are not affected. ## 2\. Regulatory framing | Article | Trigger (the fact in this item) | Practical impact | | ----------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DORA Art. 28: ICT third-party risk, general principles | The affected component is an open-source runtime (Electron) embedded in client-facing or internal applications, and the fix is delivered as a version bump the institution must pull and redeploy. | The institution must be able to identify which of its applications embed Electron, at which version, and how a patched runtime reaches production. Where Electron is consumed through a vendor's packaged product rather than built in-house, the update path runs through that vendor. | | DORA Art. 30: key contractual provisions with ICT third-party providers | Where the Electron-based application is supplied by a third party, the institution depends on that provider to ship the fixed version and to disclose the affected versions. | Contractual provisions covering patch delivery timelines and vulnerability notification are the mechanism by which this fix reaches the institution. Confirm the provider's disclosure obligation covers runtime-level flaws in their packaged product, not only their own code. | No other article in the regulatory reference is directly engaged by this item. There is no evidence in the source material of an incident, so the DORA Art. 17 to 19 incident management and reporting chain and NIS2 Art. 23 are not triggered. NIS2 Art. 21(2)(d) supply chain security measures and UK NIS 2018 OES/RDSP duties may apply to an institution's own supplier management programme, but nothing in this item is distinctive enough to engage them beyond the general obligation to track third-party component risk. ## 3\. Technical analysis & attack chain The flaw is a CORS enforcement gap in Electron's custom protocol registration. A scheme registered with `supportFetchAPI: true` but without `corsEnabled: true` was not subject to CORS enforcement, so a page loaded from a remote origin could issue `fetch()` or `XMLHttpRequest` calls against that scheme cross-origin and read the full response body rather than having the read blocked. The advisory states this completes the fix for CVE-2026-70604, which means the earlier patch addressed part of the same CORS gap and this release covers the `protocol.registerFileProtocol` and `protocol.registerHttpProtocol` handler paths. Confirmed attack chain, as described in the source: 1. The application registers a custom scheme with `supportFetchAPI: true` and does not set `corsEnabled: true`. 2. The application serves responses for that scheme through `protocol.registerFileProtocol` or `protocol.registerHttpProtocol`. 3. The application loads untrusted or remote content in a renderer that can reach the scheme. 4. The untrusted page issues a cross-origin `fetch()` or `XMLHttpRequest` against the custom scheme. 5. CORS is not enforced for that scheme, so the response body is returned to the page in full instead of the read being blocked. The impact is disclosure of whatever the handler serves. Where the handler is `registerFileProtocol`, that is local file content reachable through the scheme; where it is `registerHttpProtocol`, it is the response body the handler returns. The source does not describe privilege escalation, persistence, command-and-control, lateral movement, or code execution, and none should be inferred: this is a read primitive, not an execution primitive. Affected versions, from the advisory: - `< 41.10.6` - `>= 42.0.0-alpha.1, < 42.9.2` - `>= 43.0.0-alpha.1, < 43.4.1` - `>= 44.0.0-alpha.1, < 44.0.0-beta.5` Fixed versions: `41.10.6`, `42.9.2`, `43.4.1`, `44.0.0-beta.5`. Two caveats on scope. First, the advisory's own conditionality is narrow: an app is affected only if it registers such a scheme, serves it through one of those two handlers, and loads untrusted content. An app that sets `corsEnabled: true`, or that never loads untrusted content in a window that can reach the scheme, is not affected. Second, the related advisories in the source set (GHSA-v3j7-r9gq-3gjw, GHSA-v64r-4m7r-3mvq, GHSA-ff2p-hmqr-hxm4, GHSA-m55f-7gqj-fr98, GHSA-v93f-fgjr-hjrj) describe separate Electron flaws with their own fixed-version sets. They are context for the pattern of Electron renderer and protocol-boundary issues, not part of this CVE, and their fixes do not address CVE-2026-70604\. Do not treat a version that clears one of those advisories as clearing this one. Attribution: none. There is no actor named in the source material and no MITRE ATT&CK profile in the verified reference data, so no attribution is made or implied. ## 4\. Mitigation & containment ### P1 (within 24 hours) - Inventory every Electron-based application in the estate, including internal tooling, trading desktops, and vendor-packaged clients. For each, record the Electron version and whether it is built in-house or supplied by a third party. - For each application, determine whether it registers a custom scheme with `supportFetchAPI: true`. Grep the codebase for `registerFileProtocol`, `registerHttpProtocol`, `supportFetchAPI`, and `corsEnabled`. An application that registers no such scheme is not exposed to this CVE. - Where a scheme is registered with `supportFetchAPI: true` and `corsEnabled` is absent or false, apply the vendor workaround immediately: set `corsEnabled: true` on the scheme. This is the documented mitigation and does not require the version upgrade. - Where the application cannot be changed quickly, stop loading untrusted or remote content in any window that can reach the scheme. This is the second documented workaround. ### P2 (within 72 hours) - Upgrade to a fixed version on the branch in use: `41.10.6`, `42.9.2`, `43.4.1`, or `44.0.0-beta.5`. Do not mix branches; pick the fixed release that matches the deployed major line. - In protocol handlers that return sensitive data, validate the request `Origin` header before returning the body. This is defence in depth and holds even if a future regression reintroduces the CORS gap. - For vendor-supplied Electron applications, raise a support case citing GHSA-j84w-jfhq-vhvj and CVE-2026-70604 and request the fixed build and a statement of affected versions. ### P3 (within 7 days) - Add Electron version and custom-scheme registration to the software bill of materials so the next runtime-level advisory can be triaged without a fresh inventory. - Review whether any window that loads remote content shares a session or renderer with a window that can reach a privileged custom scheme. Where it does, separate them. ## 5\. Indicators of compromise No indicators of compromise available in the source material. The source is a vendor security advisory describing a code-level CORS enforcement gap; it contains no hashes, domains, IP addresses, file paths, or command lines. Behavioural indicators, for detection engineering rather than enforcement: | behaviour | where to observe | confidence | | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | | Cross-origin fetch() or XMLHttpRequest from a remote-origin page to a custom scheme registered with supportFetchAPI: true | Electron renderer network activity; application-level request logging in the protocol handler | High for the mechanism, as described in the advisory; no field telemetry supplied | | Protocol handler returning a full response body to a request whose Origin is not the application's own origin | Instrumentation inside registerFileProtocol / registerHttpProtocol handlers | High for the mechanism; requires handler-level logging the source does not describe | | Application registering a scheme with supportFetchAPI: true and no corsEnabled: true | Static review of application source or packaged app.asar | High; this is the affected configuration stated in the advisory | ## 6\. Detection The source material contains no file hashes, command-line flags, mutex names, registry keys, or hard-coded values. The only artefacts are Electron API identifiers and configuration keys, which are legitimate framework symbols present in every Electron application, benign or not. A YARA or Sigma rule built on `supportFetchAPI`, `corsEnabled`, `registerFileProtocol`, or `registerHttpProtocol` would match the framework itself and every application that uses it, not the vulnerable configuration, and would generate noise without detecting the flaw. There is no threat artefact here to write a rule against. Insufficient indicators to author detection rules. Detection effort for this item belongs in static configuration review, not signature matching: identify applications that register a custom scheme with `supportFetchAPI: true` and without `corsEnabled: true`, and treat that configuration as the finding. ## CVE assessment 1 referenced CVE | CVE | CVSS | Exploited | EPSS | Summary | | -------------------------------------------------------------------------------- | -------- | --------- | ---- | -------------------------------------------------------------------------------------------------------------------------------- | | [CVE-2026-70604](https://nvd.nist.gov/vuln/detail/CVE-2026-70604?ref=f4n6.co.uk) | 7.4 High | — | 0% | Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 39.8.10, 40.9.… | ## 7\. Sources - GitHub Security Advisories, "Electron: File and HTTP protocol handlers allow cross-origin reads without corsEnabled" (GHSA-j84w-jfhq-vhvj), https://github.com/advisories/GHSA-j84w-jfhq-vhvj, published 2026-09-29. - GitHub Security Advisories, "Electron: Custom protocol with supportFetchAPI but not corsEnabled allows cross-origin reads" (GHSA-v3j7-r9gq-3gjw), https://github.com/advisories/GHSA-v3j7-r9gq-3gjw. - GitHub Security Advisories, "Electron: HTTP redirect followed into local file loader" (GHSA-v64r-4m7r-3mvq), https://github.com/advisories/GHSA-v64r-4m7r-3mvq. - GitHub Security Advisories, "Electron: contextBridge object copy honors prototype setters" (GHSA-ff2p-hmqr-hxm4), https://github.com/advisories/GHSA-ff2p-hmqr-hxm4. - GitHub Security Advisories, "Electron: Extension tab APIs operate across session boundaries" (GHSA-m55f-7gqj-fr98), https://github.com/advisories/GHSA-m55f-7gqj-fr98. - GitHub Security Advisories, "Electron: window.open features string controls some window options considered privileged" (GHSA-v93f-fgjr-hjrj), https://github.com/advisories/GHSA-v93f-fgjr-hjrj. - GitHub Advisory Database, CVE-2026-102675 entry for GHSA-j84w-jfhq-vhvj, https://github.com/advisories/GHSA-j84w-jfhq-vhvj. ## 8\. Adverse Trace position Adverse Trace assesses CVE-2026-70604 at CVSS 7.4 HIGH (CWE-942), not listed in CISA KEV, with EPSS 0% in the verified reference data. The EPSS figure and the absence of KEV listing are consistent with a code-level CORS gap that requires a specific application configuration to be exploitable, and we do not inflate it: the practical risk is disclosure of whatever a custom protocol handler serves, in applications that both register such a scheme and load untrusted content. The source is a single vendor advisory and the fixed-version and affected-version lists rest on it alone; treat the version boundaries as single-sourced and verify against the release tags before pinning. Client impact is concentrated in institutions that ship Electron-based desktop or internal tooling, and the immediate action is configuration review rather than emergency patching: find the schemes registered with `supportFetchAPI: true` and no `corsEnabled: true`, set `corsEnabled: true` today, then move to a fixed version. We will track the Electron release branches for any follow-up advisory that extends CVE-2026-70604, and we will re-issue this note if a fixed version is found to be incomplete. --- [Read the original source →](https://github.com/advisories/GHSA-j84w-jfhq-vhvj?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*