GHSA-x562-297c-g43g: Medium severity npm/electron vulnerability
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
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/electronto a version that resolves this vulnerability.Fixed in 42.11.9 - Upgrade
Upgrade
npm/electronto a version that resolves this vulnerability.Fixed in 43.7.6 - Upgrade
Upgrade
npm/electronto a version that resolves this vulnerability.Fixed in 44.5.0 - Upgrade
Upgrade
npm/electronto a version that resolves this vulnerability.Fixed in 45.0.0-alpha.13 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 42.11.9 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 43.7.6 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 44.5.0 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 45.0.0-alpha.13 - Configuration
Deny the pointerLock permission for web contents that embed untrusted frames.
pointerLock permission = deny
Event History
Frequently Asked Questions
Which applications are affected by this issue?
Applications are affected only if they embed untrusted content in cross-origin iframes and make pointerLock decisions by origin in session.setPermissionRequestHandler(). Applications that do not embed untrusted content, or that deny pointerLock for that content, are not affected.
What does an attacker need to exploit this behavior?
An attacker needs their content to be embedded in a relevant cross-origin iframe and needs the application to grant pointerLock based on the requesting origin supplied to the permission handler. The incorrect frame identity can cause the embedded content to be evaluated as though it were the top-level page.
What can be done if upgrading is not immediately possible?
Deny the pointerLock permission for web contents that embed untrusted frames. This prevents untrusted embedded content from receiving pointer lock through the affected permission-request handling path.
Which Electron releases contain fixes?
Fixed releases are 45.0.0-alpha.13, 44.5.0, 43.7.6, and 42.11.9.