MediumGHSA-x562-297c-g43gCVE-2026-113798

Electron: Pointer lock permission requests can be attributed to the wrong frame

Published 22 Oct 2026 · Updated 22 Oct 2026

Affected packages

Affected
>=45.0.0-alpha.1 <45.0.0-alpha.13
Fixed in
45.0.0-alpha.13
Update to the fixed version for your release line, for example:npm install electron@45.0.0-alpha.13
Affected
>=44.0.0-alpha.1 <44.5.0
Fixed in
44.5.0
Update to the fixed version for your release line, for example:npm install electron@44.5.0
Affected
>=43.0.0-alpha.1 <43.7.6
Fixed in
43.7.6
Update to the fixed version for your release line, for example:npm install electron@43.7.6
Affected
<42.11.9
Fixed in
42.11.9
Update to the fixed version for your release line, for example:npm install electron@42.11.9

Details

Impact

For pointerLock permission requests made from some cross-origin iframes, session.setPermissionRequestHandler() was given the top-level frame's requestingUrl and isMainFrame instead of the requesting frame's. Apps that grant pointer lock based on the requesting origin could grant it to embedded content under the top-level page's identity.

Apps are only affected if they embed untrusted content in iframes and decide pointerLock requests by origin in setPermissionRequestHandler. Apps that do not embed untrusted content, or that deny pointerLock for it, are not affected.

Workarounds

Deny the pointerLock permission for web contents that embed untrusted frames.

Fixed Versions

  • 45.0.0-alpha.13
  • 44.5.0
  • 43.7.6
  • 42.11.9

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-x562-297c-g43g 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.