Electron: shell.openPath path validation bypass via embedded null byte
Published 5 Aug 2026 · Updated 5 Aug 2026
Affected packages
- Affected
- >=42.0.0-alpha.1 <42.0.0-beta.1
- Fixed in
- 42.0.0-beta.1
npm install electron@42.0.0-beta.1- Affected
- >=41.0.0-alpha.1 <41.1.1
- Fixed in
- 41.1.1
npm install electron@41.1.1- Affected
- >=40.0.0-alpha.1 <40.9.0
- Fixed in
- 40.9.0
npm install electron@40.9.0- Affected
- <39.8.6
- Fixed in
- 39.8.6
npm install electron@39.8.6Details
Impact
shell.openPath() did not reject paths containing embedded null bytes. Apps that perform string-only validation of file paths (for example, checking the file extension) before passing them to shell.openPath() could be bypassed, allowing an attacker-controlled path to open a different file than the one that passed validation.
Apps are only affected if they pass paths derived from untrusted input to shell.openPath() and rely on string-based validation without a filesystem check. Node's fs APIs already reject paths containing null bytes, so apps that call fs.existsSync(), fs.stat(), or similar before shell.openPath() are not affected. Apps that do not call shell.openPath() with untrusted input are not affected.
Workarounds
Reject any path containing a null byte before passing it to shell.openPath():
if (filePath.includes('\0')) throw new Error('invalid path');Fixed Versions
42.0.0-beta.141.1.140.9.039.8.6
For more information
If you have any questions or comments about this advisory, email us at [security@electronjs.org](mailto:security@electronjs.org)
Is GHSA-5c9j-mhmv-5xgx 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.