Electron: File and HTTP protocol handlers allow cross-origin reads without corsEnabled

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

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:

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

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 →

Published via PulseTrace — Adverse Trace threat intelligence.