CVE-2026-34771
Use-After-Free in Electron Permission Request Handler Causes Memory Corruption
Publication date: 2026-04-04
Last updated on: 2026-04-22
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| electronjs | electron | 41.0.0 |
| electronjs | electron | 41.0.0 |
| electronjs | electron | 41.0.0 |
| electronjs | electron | 41.0.0 |
| electronjs | electron | 41.0.0 |
| electronjs | electron | 41.0.0 |
| electronjs | electron | 41.0.0 |
| electronjs | electron | 41.0.0 |
| electronjs | electron | 41.0.0 |
| electronjs | electron | 41.0.0 |
| electronjs | electron | 41.0.0 |
| electronjs | electron | 41.0.0 |
| electronjs | electron | 41.0.0 |
| electronjs | electron | From 39.0.0 (inc) to 39.8.0 (exc) |
| electronjs | electron | From 40.0.0 (inc) to 40.7.0 (exc) |
| electronjs | electron | to 38.8.6 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-416 | The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-34771 is a use-after-free vulnerability in the Electron framework that affects how asynchronous permission requests for fullscreen, pointer-lock, and keyboard-lock are handled via the session.setPermissionRequestHandler() API.
If an application registers an asynchronous permission request handler, and the requesting frame navigates away or the window closes while the permission handler is still pending, invoking the stored callback accesses memory that has already been freed. This can cause the application to crash or lead to memory corruption.
Applications that do not set a permission request handler or respond synchronously to permission requests are not affected by this vulnerability.
How can this vulnerability impact me? :
This vulnerability can lead to crashes or memory corruption in applications built with affected versions of Electron when handling certain asynchronous permission requests.
Because the vulnerability involves use-after-free memory access, it can potentially be exploited remotely (over the network) without requiring privileges, although user interaction is needed.
The impacts include high confidentiality, integrity, and availability risks, meaning sensitive data could be exposed or altered, and the application could become unavailable or unstable.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability is related to the asynchronous handling of permission requests in Electron applications, specifically when using session.setPermissionRequestHandler(). Detection involves identifying if an affected Electron version is in use and if the application registers an asynchronous permission request handler for fullscreen, pointer-lock, or keyboard-lock permissions.
There are no specific network or system commands provided in the available resources to directly detect exploitation attempts or presence of this vulnerability.
To detect if your Electron application is vulnerable, you can check the Electron version in use and review the application code for asynchronous permission request handlers.
- Check Electron version: Run `electron --version` or check the package.json dependencies to identify the Electron version.
- Review application code for usage of `session.setPermissionRequestHandler()` and verify if the handler is asynchronous.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include updating Electron to a patched version and modifying permission request handling.
- Upgrade Electron to one of the patched versions: 38.8.6, 39.8.0, 40.7.0, or 41.0.0-beta.8.
- If upgrading is not immediately possible, modify the application to respond to permission requests synchronously instead of asynchronously.
- Alternatively, deny fullscreen, pointer-lock, and keyboard-lock permission requests if asynchronous handling is necessary.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The provided information does not specify any direct impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.