Electron: Custom protocol with supportFetchAPI but not corsEnabled allows cross-origin reads
Published 5 Aug 2026 · Updated 5 Aug 2026
Affected packages
- Affected
- >=42.0.0-alpha.1 <42.0.0
- Fixed in
- 42.0.0
npm install electron@42.0.0- Affected
- >=41.0.0-alpha.1 <41.4.0
- Fixed in
- 41.4.0
npm install electron@41.4.0- Affected
- >=40.0.0-alpha.1 <40.9.3
- Fixed in
- 40.9.3
npm install electron@40.9.3- Affected
- <39.8.10
- Fixed in
- 39.8.10
npm install electron@39.8.10Details
Impact
A custom scheme registered with supportFetchAPI: true but without corsEnabled: true was not subject to CORS enforcement. A page loaded from a remote origin could therefore fetch() or XMLHttpRequest that scheme cross-origin and read the full response body, rather than the read being blocked.
Apps that serve sensitive data from such a scheme and load remote or untrusted content in a renderer are affected. Apps that set corsEnabled: true, or that do not load untrusted content, are not affected.
Workarounds
Set corsEnabled: true on schemes that must enforce CORS, and validate the request Origin in your protocol handler before returning sensitive data.
Fixed Versions
42.0.041.4.040.9.339.8.10
For more information
If you have any questions or comments about this advisory, email Electron at [security@electronjs.org](mailto:security@electronjs.org)
Is GHSA-v3j7-r9gq-3gjw in any of your client repos?
Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected electron, and gives you the command that fixes it.
References
Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.