Electron
Monthly
MongoDB Compass versions prior to 1.53.1 ship an Electron runtime whose bundled TLS root store still contains the compromised, recoverable eMudhra intermediate CA certificates, so a party holding a certificate chained to those intermediates can be treated as trusted by the application. Because the attacker must also occupy a man-in-the-middle position on the network path and induce a user to initiate a Compass connection through it, impact is confidential and integrity-related (VC:H/VI:H) rather than an unauthenticated remote take-over. The vendor resolves the issue in Compass 1.53.1, which bundles Electron 44.9.1; no public exploit code or active exploitation has been reported, and the issue is prioritised as this week rather than an emergency.
Electron before 42.11.16, 43.8.1, 44.9.1 and 45.0.0-beta.6 fails to enforce the blocklist for a set of compromised eMudhra intermediate certificates, so a TLS chain terminating in one of those intermediates is still accepted by Chromium networking and by Node.js tls, https and fetch. An attacker who already holds a leaf certificate issued under one of those intermediates and who can intercept the victim app's network traffic can impersonate a TLS server to that app, breaking both confidentiality and integrity of the connection; the CVSS vector scores this 7.4 with AC:H, unauthenticated (PR:N) and no user interaction, reflecting that the MITM position is the binding constraint. Apps that make no network connections are not affected, and the vendor states there are no app-side workarounds - only an update to a patched Electron release closes the gap. No public exploit code has been identified at time of analysis, and the issue is not in CISA KEV, so the practical risk is a conditional interception scenario rather than a broadly exploited one.
Navigation allowlist bypass in EdgeEver Desktop versions 1.6.26 through 1.112.0 allows an attacker who can get crafted content rendered in the app (for example a note-template preview) to load an arbitrary origin into the main window and capture the edgeeverDesktop bridge, including the session token, sidecar RPC, and ACP channels. The flaw is an incorrect-authorization issue (CWE-863) in which the will-navigate handler trusts a string-prefix match, so a URL that places the trusted dev-server prefix in the userinfo portion (e.g. https://devserver@attacker.tld) is accepted while the real origin is attacker-controlled. Exploitation requires a low-privileged authenticated foothold to plant the content and user interaction for the victim to open or preview it, and no public exploit code has been identified at time of analysis; the source CVSS 4.0 vector scores 8.4 (High), driven by high confidentiality and integrity impact that can escalate to command execution through ACP adapters.
Arbitrary local program execution is possible in EdgeEver Desktop 1.92.0 through 1.112.0 because the desktop:acp-probe IPC handler performs no sender validation and spawns whatever executable path is supplied in the caller's input.path, running it with the victim user's privileges. This is not a standalone network RCE: an attacker must first land stored cross-site scripting in a renderer through the template-preview or drag-preview feature, and the victim must then preview that attacker-controlled content so the renderer script can invoke probeAcpAdapter (CVSS v4.0 7.3; independent assessment CVSS v3.1 AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H). No public exploit code and no CISA KEV listing were identified at time of analysis; an upstream fix commit has been referenced, but no patched release version has been independently confirmed.
Remote code execution on the AstronRPA desktop client through version 1.1.6 is achievable by an on-path attacker who intercepts the client's plaintext HTTP auto-update check and serves a malicious update manifest with an unsigned NSIS installer, which electron-updater installs without verifying a publisher signature. The weakness is CWE-494 (download of code without integrity check), rated 7.7 under CVSS 4.0 with High attack complexity and attack requirements Present because the attacker must already hold a man-in-the-middle position and the client must run an update check; there is no public exploit identified at time of analysis and no vendor-released patch identified at time of analysis, so this is a conditional, non-scalable threat rather than a mass-exploitation emergency.
Arbitrary code execution in Obsidian Desktop builds prior to 1.14.0 is possible when a user opens an attacker-supplied Markdown note and manually starts it as a presentation: a crafted data-background-iframe attribute survives DOMPurify sanitization in the bundled Slides core plugin, and Reveal.js then promotes that value into an iframe src without URL-scheme validation, allowing a javascript: payload to reach Node.js APIs through parent.require in Obsidian's Node-integrated, context-isolation-disabled renderer. The attacker is unauthenticated per the assessed vectors (PR:N) but exploitation is entirely local and user-driven, requiring file-based delivery plus two deliberate user actions (opening the note and launching the presentation), which is why the assessed CVSS 3.1 score is 8.5 with S:C. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV; the vendor has published a patched release, so exposure is eliminated by updating.
Path traversal in Legcord's theme IPC handlers (versions 1.1.0 through 1.3.0) allows an attacker who already has script execution inside the embedded Discord page - for example via XSS - to supply unvalidated theme ids to themes.folder, themes.uninstall, and themes.install and escape the themes directory. That yields arbitrary file writes, recursive directory deletion, and local executable launch, i.e. host code execution; CVSS 4.0 scores it 9.2 (Critical) with full confidentiality, integrity, and availability impact, and PR:N means no further authentication is required once the script foothold exists, while AC:H and AT:P capture that prerequisite. No public exploit code was identified at time of analysis and no CISA KEV listing is present.
Code execution as the logged-in user results when someone running the Twine 2 desktop (Electron) application on version 2.12.0 or earlier imports a crafted story file. The importStories() routine renders untrusted markup from the imported file inside the editor window, and a script smuggled in that markup can reach the twineElectron openWithScratchFile IPC bridge to write and then open a .bat file, yielding arbitrary code execution in the user's context. No public exploit code has been identified at time of analysis, and although no authentication is required (CVSS vector PR:N), exploitation depends on the victim actively importing the attacker's file, so delivery is a social-engineering problem; the CVSS 4.0 base score is 8.5 (High) with high confidentiality, integrity, and availability impact on the local host only.
Code cache poisoning in Electron's sandboxed preload machinery allows a compromised renderer to get its own code executed in the more privileged preload context on a later load, affecting desktop applications built on Electron 42.3.3 through versions prior to 42.10.0, 43.0.0-beta.1 through versions prior to 43.5.0, and 44.0.0-alpha.1 through versions prior to 44.0.0-beta.6. Two prerequisites must both hold: the application must load untrusted content (the vendor explicitly states apps that do not load untrusted content are unaffected), and the attacker must already control a renderer process, so this is a local, low-privilege escalation step (CVSS 3.1 vector AV:L/PR:L) rather than a standalone remote attack. Vendor-released patches are available in 42.10.0, 43.5.0, and 44.0.0-beta.6, there are no app-side workarounds, EPSS is 0.09% (0th percentile), and no public exploit code or confirmed active exploitation (no CISA KEV listing) was identified at time of analysis.
Privilege escalation in the Electron framework lets a <webview> guest grant itself Node.js integration inside its Web Workers even when the embedding (embedder) application has Node integration turned off, so untrusted guest content can obtain a more privileged JavaScript execution context than the host application intended to allow. Affected releases are npm/electron before 41.10.6, 42.x before 42.9.2, 43.x before 43.4.1, and 44.0.0-alpha.x before 44.0.0-beta.5 (CPE cpe:2.3:a:electron:electron). Exploitation is not automatic: the independent assessment requires a non-default deployment where the app enables the <webview> tag, runs the embedder unsandboxed with nodeIntegration disabled, and loads attacker-controllable content into the guest - applications that never enable <webview>, keep the embedder sandboxed, or only load trusted first-party content are unaffected. There is no public exploit identified at time of analysis (CISA SSVC: Exploitation none, Automatable no, Technical Impact total) and EPSS is low at 0.45% (37th percentile), although the underlying privilege boundary is a total-compromise class issue where it applies; the NVD-style vector scores 9.8, while our independent assessment reflects the higher attack complexity and changed scope (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) imposed by those preconditions.
Cross-origin information disclosure in the Electron framework allows untrusted web content loaded inside an Electron application to read responses served through custom protocol schemes registered with protocol.registerFileProtocol or protocol.registerHttpProtocol when supportFetchAPI is enabled but corsEnabled is disabled. Affected are Electron builds prior to 41.10.6, 42.9.2, 43.4.1 and 44.0.0-beta.5; exploitation requires that the host application actually exposes such a scheme and loads attacker-influenced content in the same session, so severity is real but conditional rather than universal. The issue is an incomplete remediation of CVE-2026-70604, no public exploit code or active exploitation has been identified at time of analysis, and unauthenticated remote attackers can trigger it through victim interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N, base 7.4).
Sandbox escape in Electron desktop applications lets untrusted content rendered in a CSP-sandboxed top-level document open popup windows that inherit the application's full privileged origin instead of the restricted origin intended by the sandbox, exposing that origin's cookies and localStorage. Exploitation requires the application to load untrusted content into a document sandboxed via a Content-Security-Policy 'sandbox' directive that still permits popups, and requires user interaction (window.open or target=_blank) per the CVSS vector (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N); applications that deny popups with setWindowOpenHandler are not affected. The flaw is fixed in Electron 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5, and no public exploit code has been identified at time of analysis.
Electron before 41.10.4, 42.5.2, and 43.0.0 fails to propagate HTML iframe sandbox restrictions to popups opened through its OpenURLFromTab navigation path, so an untrusted iframe configured with 'allow-scripts allow-popups' (but without 'allow-popups-to-escape-sandbox') can open a new window that runs with the embedding application's full origin, granting same-origin script access to that origin's cookies and storage. Exploitation requires the target application to embed untrusted web content in such a sandboxed iframe and to trigger a popup - via a scripted target="_blank" link or a middle-click - so the assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N rating marks this as unauthenticated but user-interaction dependent, with high confidentiality and low integrity impact and a changed scope. Applications that do not embed untrusted content in sandboxed iframes are explicitly unaffected; no public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fixed by vendor-released versions 41.10.4, 42.5.2, and 43.0.0.
Stored cross-site scripting in SiYuan versions 3.7.0 through 3.8.3 (fixed in 3.8.4) allows an authenticated user with write access to a shared workspace to plant JavaScript inside a database field description that is later rendered unescaped into an aria-label attribute of gallery and kanban (Attribute View) layouts. When the victim views that board in the SiYuan Electron desktop app - where nodeIntegration is enabled by default - the injected script reaches Node.js child_process APIs and can execute arbitrary commands with the victim's privileges, escalating a rendering flaw into full local code execution. Exploitation is access-gated: it requires an authenticated writer, the victim rendering the poisoned view, and the desktop Electron build, so real-world reach is narrower than the 8.6 CVSS 4.0 headline; no public exploit code or confirmed active exploitation was identified at time of analysis.
Stored cross-site scripting in SiYuan before v3.8.4 allows an authenticated attacker with write access to Attribute View content to persist JavaScript in four unsanitized textarea-backed fields - field descriptions, template sources, select option descriptions, and footer calculation templates - which then executes in the browser session of any user who opens the affected database menu. The desktop Electron build escalates the issue to command execution with SiYuan process privileges when nodeIntegration is enabled, while browser or hardened Electron deployments cap impact at script execution in the victim's session. Vendor-released patch: v3.8.4; no public exploit identified at time of analysis, and the vendor/GHSA advisory plus a VulnCheck advisory are the primary references. CVSS 4.0 base score is 8.5; our independent CVSS 3.1 assessment is AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H, consistent with a genuine but conditionally-gated stored XSS whose RCE escalation depends on the nodeIntegration setting.
Stored cross-site scripting in SiYuan Note before v3.8.4 lets attacker-supplied flashcard block content run script inside the desktop client's privileged Electron renderer, which is created with nodeIntegration enabled and contextIsolation disabled, escalating the XSS to arbitrary code execution on the host. Per the independent assessment, exploitation is meaningfully gated: it requires the SiYuan desktop Electron client, an authenticated administrator account (the /api/riff/getRiffCards endpoint keeps its auth and admin-role checks), attacker-controlled flashcard content already planted in the workspace via import, contribution, or shared/synced documents, and the administrator actively opening the card manager view - so this is a targeted, condition-gated RCE risk rather than a broadly exploitable one, despite the 8.6 CVSS-4.0 headline. No public exploit code was identified at time of analysis and active exploitation is not confirmed; vendor fixes are available in v3.8.4.
Stored cross-site scripting in SiYuan through 3.8.4 lets an attacker inject malicious style values into heading attributes that the outline and bookmark docks render without escaping, so the payload executes as JavaScript inside SiYuan's Electron renderer - which runs with full system access, making this effectively an XSS-to-code-execution condition on the host rather than ordinary script execution in a sandboxed browser context. Delivery is either a crafted notebook that the victim imports or opens, or abuse of SiYuan's administrative endpoints (the latter implying authenticated access); the payload only fires when the victim surfaces the affected heading in the outline or bookmark dock, so user interaction is required (UI:A) and exploitation is not purely passive. No public exploit identified at time of analysis; the CVE carries a CVSS 4.0 base score of 8.6 and was independently assessed as CVSS 3.1 9.6 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H), reflecting the notebook-import path being unauthenticated while the administrative-endpoint path requires credentials.
Stored cross-site scripting in SiYuan through 3.8.4 lets an attacker who can set a notebook name containing an HTML payload have that markup rendered unescaped when the Daily Note picker dialog is opened, executing JavaScript inside the Electron renderer where Node.js integration is available and escalating to operating system command execution. Exploitation is gated by two preconditions: the attacker must be able to create or inject a notebook carrying the payload (a shared or synced workspace, a server-mode multi-user deployment, or an imported malicious notebook), and the victim must open the picker; the assessed CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H, while the published CVSS 4.0 score of 8.6 carries PR:N/UI:A, so the two scorings disagree on whether prior privileges are needed. This is treated as a genuine high-priority issue rather than a high-score-but-low-real-risk case, because the impact chain terminates in OS command execution rather than mere client-side script execution; no public exploit code and no confirmed active exploitation were identified at time of analysis, and a purely local single-user instance that never ingests external notebooks has a materially smaller attack surface.
Cross-site scripting in the SiYuan desktop note-taking app before 3.8.4 allows an attacker who can dictate a document title - either by calling the rename API or by delivering a crafted notebook the victim opens - to inject markup that is rendered as HTML in the backlink dock tree and executed inside the Electron renderer. Because the default desktop build exposes Node's child_process to the renderer, successful script execution escalates from XSS to arbitrary command execution on the victim's machine; the CVSS 4.0 vector rates this 8.6 (PR:N, UI:A), and the independent assessment concurs that this is a genuinely high-priority issue rather than an inflated score. Exploitation still depends on user interaction (the victim must view the poisoned title in the backlink dock or import the malicious notebook), no public exploit code was identified at time of analysis, and there is no KEV confirmation of active exploitation; a vendor patch is available in 3.8.4.
Stored cross-site scripting in SiYuan notebook software before 3.8.4 lets an attacker who supplies a crafted .sy notebook file execute arbitrary script inside the Electron renderer, which in the default desktop build has Node.js child_process access and therefore escalates to host-level command execution. The flaw arises because bookmark labels read from imported notebook files are written into the dock tree HTML without escaping, so unescaped markup in a bookmark attribute is rendered as live DOM. No credentials are required (CVSS PR:N) and no public exploit code or CISA KEV entry has been identified at time of analysis, but the vector requires the victim to import or open the malicious notebook (UI:A/UI:R), making delivery dependent on social engineering; EPSS data was not supplied.
Remote code execution in SiYuan desktop before 3.8.2 allows an unauthenticated network attacker to achieve full Node.js-level system access by poisoning a victim's clipboard from a malicious web page. The paste handler in app/src/protyle/util/paste.ts treated the custom text/siyuan clipboard MIME type as implicitly trusted internal content and skipped HTML sanitization before rendering, and a secondary code path used a same-origin hidden iframe to parse large HTML blobs, permitting inline script execution. Because SiYuan's Electron desktop build enables Node.js integration in the renderer process, injected scripts escape the browser sandbox entirely and execute with the privileges of the running user. A vendor-released patch is available at v3.8.2; no public exploit has been identified at time of analysis.
Cross-origin read bypass in Electron's custom protocol handler exposes sensitive application data to remote pages via fetch() and XMLHttpRequest. Electron apps on any branch prior to 39.8.10, 40.9.3, 41.4.0, or 42.0.0 that register a custom scheme with supportFetchAPI: true but omit corsEnabled: true fail to enforce CORS, allowing a malicious remote page loaded in the renderer to read the full response body of privileged custom-scheme requests. No public exploit code is identified at time of analysis and the vulnerability is not in CISA KEV, but the confidentiality impact is rated high by the vendor given the potential to exfiltrate internal application data.
GitHub Electron versions 1.8.2-beta.3 and earlier, 1.7.10 and earlier, 1.6.15 and earlier has a vulnerability in the protocol handler, specifically Electron apps running on Windows 10, 7 or 2008 that. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Cross-site scripting in the PostyBirb Plus submission description editor affects versions through 3.1.75. Crafted description markup loaded through the editor's defaultValue or overwriteDescriptionValue paths can execute in the Electron renderer, but exploitation requires an authenticated local user of the desktop app and user interaction, and impact is limited to integrity with no confidentiality or availability loss. Version 3.1.76 fixes the issue by sanitizing those loaded values; a public PoC reference exists, but it is not verified as working exploit code.
Server-side request forgery in the Request Forwarder of MusicFreeDesktop 0.0.6, 0.0.7 and 0.0.8 allows a crafted proxy request to be relayed to an attacker-chosen destination, giving low confidentiality, integrity and availability impact (CVSS 4.0 base 5.3; independently assessed as CVSS 3.1 AV:N/AC:L/PR:N/UI:R with low C/I/A). The CVSS vector indicates the attack path is unauthenticated (PR:N) but requires user interaction (UI:P/UI:R), for example a user loading or playing attacker-influenced content that causes the app to emit a proxy request; the exact trigger is not described in the available sources. A public PoC reference exists in the form of GitHub issue #443, but it is not verified as working exploit code, there is no CISA KEV listing, and the vendor fix is upstream commit b0d3876247a0a64fa0e430e4b21870e41f503182.
Out-of-bounds memory read in Electron's macOS offscreen rendering (OSR) path lets an attacker who already has code execution inside the GPU process feed inconsistent frame geometry - a content_rect or pixel_size not backed by the underlying shared-memory mapping or IOSurface - to the main process, which then reads past the end of the mapped buffer while building paint-event images. The result is disclosure of main-process memory contents or an application crash, and exploitation is confined to macOS applications that enable OSR; Windows, Linux, and default windowed Electron apps are unaffected. This is a sandbox/boundary-escalation step rather than a standalone entry point: the assessed vector is CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:L/I:N/A:L (3.9), and attack complexity is high with no public exploit identified at time of analysis. Fixed upstream in Electron 42.11.6, 43.7.3, 44.4.3, and 45.0.0-alpha.9.
Out-of-bounds memory read in Electron's frame-capture path (webContents.beginFrameSubscription) affects all versions prior to 42.11.6, 43.7.3, 44.4.3, and 45.0.0-alpha.9. The main process trusted frame geometry and pixel-format metadata relayed from the GPU process - content_rect, coded_size, pixel_size, and pixel_format - without validating it against the actual shared-memory or IOSurface mapping, so a malicious set of values causes the browser to read past the end of the buffer while assembling captured frames, leaking process memory or crashing the app. Exploitation requires that the target application actually use the frame-subscription API and that the attacker already hold code execution inside the GPU process through some other bug; no public exploit code and no active exploitation were identified at time of analysis, and the CVSS 3.9 score reflects that steep prerequisite rather than the severity of the memory-safety class.
Origin confusion in Electron's external protocol handling lets a launch request be attributed to a document other than the one that actually initiated it, so the requestingUrl handed to session.setPermissionRequestHandler can name trusted content for a launch requested by untrusted content. Applications running Electron prior to 42.11.3, 43.7.0, 44.3.0, or 45.0.0-alpha.5 are exposed only if they both grant openExternal based on that requesting origin and permit untrusted content to open or navigate windows, in which case attacker-supplied content may reach an OS-registered external application such as a mail client or custom URL handler. Exploitation additionally depends on a timing condition where the initiating document is gone when the request reaches the browser (a popup whose opener navigated away, or a server redirect to the external URL), which is why the assessed vector carries AC:H; no public exploit code has been identified at time of analysis, and the issue is not confirmed actively exploited (CISA KEV).
Electron's HID and USB permission checks mishandle the requesting frame's origin, so an app whose setPermissionCheckHandler authorizes devices by origin can be tricked into granting WebHID/WebUSB access to a cross-origin untrusted iframe that was never meant to receive it. Only applications that both delegate the 'hid' or 'usb' permission to an untrusted cross-origin frame via permissions policy and make device decisions on the reported origin are exposed, and a matching device must also be attached; default configurations are not affected. Unauthenticated remote attackers can trigger the logic remotely (CVSS 3.1 AV:N/PR:N), but with high attack complexity and low confidentiality/integrity impact scored at 5.4 with a scope change. No public exploit code and no confirmed active exploitation were identified at time of analysis; fixed in 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.5.
Electron mis-attributes pointerLock permission requests originating from cross-origin iframes, causing session.setPermissionRequestHandler() to receive the top-level frame's requestingUrl and isMainFrame values instead of the actual requesting frame's. Applications that embed untrusted iframe content and grant pointer lock based on the requesting origin can therefore be tricked into granting the permission under the top-level page's identity, allowing an embedded attacker-controlled frame to capture the pointer (integrity and availability impact only, no confidentiality impact). Exploitation requires a user gesture and an affected Electron version prior to 42.11.9, 43.7.6, 44.5.0, or 45.0.0-alpha.13; apps that already deny pointerLock for untrusted content are not affected. No public exploit code was identified at time of analysis and the issue is not in CISA KEV, so real-world risk is limited to the narrow population of apps whose permission handlers trust origin strings for pointer lock.
Electron's chrome.tabs.query() implementation returned the url and title of every tab in a session to extensions that held neither the 'tabs' permission nor a matching host permission, letting a loaded extension enumerate the URLs and titles of all webContents in that session. Only applications that explicitly pull in extensions they do not fully trust via session.extensions.loadExtension are exposed, and only on builds prior to 42.11.1, 43.5.1, 44.1.1, and 45.0.0-alpha.4; unauthenticated remote attackers cannot reach the flaw without such an extension already running inside the app. The disclosed data is limited to tab URLs and titles (no page content, DOM, cookies, or code execution), no public exploit code was identified at time of analysis, and the issue does not appear on CISA KEV, consistent with its low CVSS 3.1 score.
Cross-site request forgery bypass in Electron before 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.6 lets untrusted content loaded by a desktop app make credentialed requests to other sites by corrupting how the framework attributes the initiator of links opened into new windows. Because Electron re-issued such top-level navigations as application-initiated loads rather than preserving the originating page's identity, the request could be judged same-site, causing SameSite=Strict cookies to be attached and Sec-Fetch-Site to omit the true initiator. Rated CVSS 4.2 (AV:N/AC:H/PR:N/UI:R, C:L/I:L/A:N), exploitation requires an app that both loads untrusted content and allows it to open popups (popups are disabled by default), a victim who opens the crafted link into a new window, and a target site that depends on SameSite cookies rather than anti-CSRF tokens; no public exploit code identified at time of analysis and the issue is not in CISA KEV.
Improper authorization of custom URL schemes in Nerimity Desktop up to 2.2.2 allows unauthenticated remote attackers to pass attacker-controlled URLs to Electron's shell.openExternal through the Window Open Handler, and publicly available exploit code exists. Exploitation requires the victim to interact with attacker-supplied content and the host OS to have a registered handler for the abused scheme, which limits practical impact to medium severity. Upgrading to 2.3.3 restricts shell.openExternal to http/https URLs and resolves the flaw.
Credential leak in the GDevelop desktop app through 5.6.284 allows unauthenticated remote attackers to exfiltrate a victim's gd_resource cloud session cookie by embedding an attacker-controlled resource URL in a crafted project file, which downloadLocalFile() requests with the cookie attached regardless of destination host; this exposes private GDevelop cloud project resources. Exploitation requires the victim to open the malicious project while holding an active GDevelop cloud session, so impact is limited to confidentiality (CVSS 4.0 base 5.3, medium; independent assessment CVSS 3.1 5.3, UI:R). No public exploit code or CISA KEV entry was identified in the provided intelligence at time of analysis.
Missing authentication in the Remote Control Server component of eremef bandcamp-player through 1.8.33-beta allows unauthenticated attackers with LAN reachability to control the desktop player's remote interface without a device pairing or approval step. The flaw is rooted in how the remoteEnabled setting is handled in database.ts, and it is practically exposed only when the Remote Control feature is switched on and the legacy, non-secure connection mode (plain HTTP/WS, no pairing) is in use; no victim interaction is required against such a server. No public exploit code or active exploitation has been confirmed, and the vendor has released a patched version, 1.8.34-beta, which turns Secure Mode (HTTPS/WSS with QR pairing and desktop approval) on by default.
Cross-site request forgery in Dyad's OAuth Callback Handler affects Dyad through version 1.16.0 and can let a crafted dyad:// callback be accepted without proof that it belongs to a legitimate in-app connection flow, causing an integrity-only credential/integration state change. Exploitation is remote but requires the Dyad desktop app to be installed with its custom-protocol handler registered and requires the victim to launch or approve the crafted protocol link; there is no confidentiality or availability impact per the independent assessment, and the CVSS 4.0 base score is 5.3. Vendor-released patch: 1.17.0-beta.1; no public exploit identified at time of analysis.
Recursive deletion of arbitrary user-writable directories is possible in the LobsterAI desktop application (NetEase Youdao) versions 2026.5.27 through 2026.9.23 because the skills:delete IPC handler trusts the openclawSourceDir path supplied in a skill's _meta.json during uninstall instead of confining cleanup to the skill's own directory. An attacker who persuades a user to install a crafted skill package - the bundled security scanner never inspects _meta.json, so the package passes vetting - can have the victim's home directory or another user-writable location wiped when that skill is later uninstalled, causing high integrity and availability impact (assessed CVSS:3.1 AV:L/AC:L/PR:N/UI:R, vendor CVSS:4.0 6.9, PR:N/UI:P). The attack is not remotely exploitable and requires user interaction twice (install plus uninstall), and no public exploit code has been identified at time of analysis; the issue is patched upstream (commit 82fdfe10d1b85d0ff734aa720e18c866b4be2406) with the fix adding regression tests that confirm bystander and OpenClaw-sourced directories are no longer touched.
A local time-of-check-to-time-of-use (TOCTOU) race condition in Electron's bundled Squirrel.Mac auto-update framework on macOS allows an attacker who already has local access to the machine to redirect the privileged ShipIt helper into overwriting a different application's files with root privileges during an update install. Only macOS Electron apps that ship Squirrel.Mac-based auto-updates are exposed; apps on other platforms, or that do not use Squirrel.Mac, are unaffected. The attacker is an authenticated local user (CVSS PR:L) and must win a narrow race window between path validation and the root-privileged write (AC:H) while an update is actually being installed (UI:R), yielding high confidentiality, integrity, and availability impact if successful; no public exploit code exists and there is no confirmed active exploitation (no CISA KEV listing), and no app-side workaround exists - remediation requires upgrading Electron to 39.8.10, 41.10.5, or 42.0.0-beta.2.
Cross-workspace denial of service in the SiYuan desktop (Electron) app lets a renderer that is connected to an attacker-controlled remote kernel broadcast a lockscreen command through the 'siyuan-send-windows' IPC handler, locking unrelated local workspace windows. The vulnerable handler does not validate the IPC sender or restrict recipients, so it forwards the payload to every window returned by BrowserWindow.getAllWindows(); sibling windows configured with lockScreenMode=1 invoke lockScreen() on receipt, and repeat messages keep those windows locked. Per the CVSS 4.0 vector the IPC path requires no privileges (PR:N) but does require user interaction (UI:P) - the victim must have multiple workspaces open and must have connected one renderer to the hostile kernel - and impact is availability-only, recoverable by manually unlocking; no public exploit code has been identified at time of analysis.
OS command injection in jhen0409's React Native Debugger up to 0.14.0 allows remote, unauthenticated attackers to run arbitrary shell commands on a developer workstation by supplying a crafted host value that reaches the openDevTools function in electron/window.js when the victim uses the 'Open in Editor' feature against an attacker-controlled debug target. Publicly available exploit code exists (the GitHub gist referenced by VulDB), but there is no confirmed active exploitation (CISA KEV) and the vendor was contacted and did not respond, so no vendor-released patch is identified. Scoring is moderate and consistent with a developer-targeted issue rather than a mass-exploitation priority: the vendor-supplied CVSS 4.0 score is 5.3 (UI:P, E:P) and our independent CVSS 3.1 assessment is 7.8 with high confidentiality, integrity and availability impact, reflecting that a successful injection executes with the privileges of the developer's account but requires the developer to connect the debugger to an attacker-influenced host and to trigger the editor/dev-tools launch.
Local code execution in Acer NitroSense v5 (versions up to and including 5.2.63) allows an attacker who already has shell access on the host to run arbitrary code in the privileged context of the application by connecting to an Electron/Chromium DevTools endpoint left enabled in the production build and bound to localhost TCP port 9993. No authentication or user interaction is required against that debug port, and the assessed CVSS:3.1 vector (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) reflects full confidentiality, integrity and availability impact once local access exists, but the exposure is confined to loopback and is therefore not remotely reachable. No public exploit code was identified and there is no CISA KEV listing at time of analysis; this is a moderate, locally-scoped risk rather than a remote emergency, and its main value to an attacker is as a privilege-escalation or persistence primitive on an already-compromised endpoint.
IPC sender-origin spoofing in the Mattermost Desktop App (versions up to and including 6.2.2.0) lets an attacker-controlled server view send a desktopAPI.leaveCall message that tears down an active call belonging to a different, trusted server connected in the same client. Exploitation is unauthenticated from the attacker's perspective (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L, score 3.8 Low) but requires the victim to be running a multi-server configuration with a live call on one server while another connected server is malicious, compromised, or grants the attacker script access; single-server clients and users with no call in progress are unaffected. Impact is limited to call disruption - no data exposure, no code execution - and no public exploit identified at time of analysis; this is a low-priority, low-impact issue.
Native code execution outside the Chromium sandbox is achievable in Electron prior to 39.8.9, 40.9.2, 41.2.1, and 42.0.0-beta.3 via the DevTools 'reveal in file manager' handler, which incorrectly forwarded attacker-supplied paths to the OS shell-open primitive rather than a safe folder-reveal call. Exploitation requires an attacker to already control JavaScript execution within the DevTools frontend - most plausibly through a malicious DevTools extension - while DevTools is open against a window loading untrusted content. No public exploit code exists and the vulnerability is not listed in CISA KEV; patched releases are available across all active Electron stable and beta branches.
Prototype pollution via Electron's contextBridge allows untrusted renderer-side web content to smuggle a malicious prototype across the isolation boundary into preload script context, bypassing context isolation in versions prior to 39.8.9, 40.9.2, 41.2.2, and 42.0.0-beta.4. Exploitation is conditional on preload scripts accepting object arguments from untrusted content and reading inherited properties without own-property guards. No public exploit has been identified at time of analysis, and the flaw is not listed in CISA KEV; however, the scope-change (S:C) CVSS metric reflects that a successful attack crosses the renderer-to-preload privilege boundary, which can have amplified consequences in apps that expose sensitive Node.js APIs through the bridge.
Code injection in Electron's DevTools API permits arbitrary script execution in the DevTools context via an unsanitized `mode` parameter supplied to `webContents.openDevTools()`. Unsandboxed Electron applications where untrusted input reaches the `mode` argument - or where untrusted content embedded in a `<webview>` element can invoke `openDevTools()` - are exposed to full Node.js-level code execution on the host operating system. No public exploit has been identified at time of analysis, but Electron's own GitHub Security Advisory (GHSA-4f78-qhmw-8j8m) confirms the flaw and vendor-released patches are available across all active release tracks.
Session isolation bypass in Electron's custom protocol handler allows cached HTTP responses from defaultSession to leak across otherwise isolated session partitions. Electron versions 40.x through pre-release 43.x are affected when apps use ProtocolResponse.url without specifying ProtocolResponse.session, causing upstream requests to be routed through defaultSession regardless of which session registered the protocol handler. An attacker who can trigger a cross-session cache hit may read confidential session-scoped content (C:H) or partially influence cached responses (I:L) intended for a different, isolated session; no public exploit or CISA KEV listing exists at time of analysis.
Unrestricted HTTP redirect scheme following in Electron's net module (versions prior to 39.8.8, 40.9.0, 41.2.1, and 42.0.0-beta.3) enables server-side request forgery leading to local file disclosure. When net.fetch() or net.request() follows a redirect issued by an attacker-controlled server targeting a local scheme such as file://, the Electron app can be made to read and expose local filesystem contents if it forwards or returns the response body. No public exploit is identified at time of analysis; however, the vulnerability class (SSRF via redirect scheme bypass, CWE-918) is well understood, and the default redirect-following behavior increases the practical surface area across affected apps.
Path validation bypass in Electron's shell.openPath() allows an attacker-controlled file to be opened in place of one that passed string-based extension validation, due to embedded null bytes not being rejected before OS-level path resolution. Electron-based desktop applications that accept untrusted file paths, validate them using only JavaScript string methods (e.g., endsWith(), regex extension checks), and then pass them to shell.openPath() are affected; apps using Node.js fs APIs (fs.existsSync(), fs.stat()) prior to the call are explicitly not vulnerable. Fixed in versions 39.8.6, 40.9.0, 41.1.1, and 42.0.0-beta.1; no public exploit identified at time of analysis.
Session isolation bypass in Electron allows a malicious or compromised Chrome extension loaded into one session to cross session boundaries and access, navigate, and script windows belonging to a completely separate session. Affected are Electron applications prior to versions 39.8.8, 40.9.0, 41.2.1, and 42.0.0-beta.3 that invoke session.loadExtension and rely on multi-session architecture as a security boundary - a narrowly scoped but architecturally significant trust boundary violation. No public exploit code or CISA KEV listing exists at time of analysis; exploitation requires attacker control of an extension the application has explicitly loaded.
Parent process code-sign spoofing in Electron on macOS allows a local low-privileged attacker to bypass fuse-based hardening controls restricting ELECTRON_RUN_AS_NODE and NODE_OPTIONS, injecting code inside the signed Electron application and inheriting its TCC permissions and keychain access. Only macOS deployments of Electron apps that have explicitly enabled same-signed-parent fuse restrictions are exposed; applications without this hardening are unaffected. No public exploit has been identified at time of analysis, and CVSS AC:H reflects the PID-reuse race-condition timing requirement inherent to the attack.
Remote code execution in 5ire 0.15.2 and earlier arises because the desktop AI assistant renders Mermaid diagrams with securityLevel set to 'loose', allowing attacker-supplied HTML/JavaScript embedded in Markdown to execute inside the Electron renderer and potentially reach the host OS. An unauthenticated network attacker can deliver the malicious Markdown through model responses or shared conversations, but exploitation requires the victim to render the content (UI:R). Publicly available exploit code exists; there is no confirmed active exploitation (not in CISA KEV).
Cross-site scripting in DeepChat's Mermaid diagram renderer escalates to full remote code execution on affected desktop installations prior to 0.5.3, because the Electron IPC renderer is exposed to the DOM - rendering attacker-controlled Mermaid content lets injected JavaScript invoke IPC and run arbitrary system commands. Successful exploitation requires the victim to load or render a crafted diagram (CVSS UI:R, AV:N/AC:L/PR:N/S:C), delivered through chat messages, shared content, or AI/tool output, and publicly available exploit code exists. CVSS 9.6 reflects the high confidentiality, integrity, and availability impact plus changed scope; the issue is fixed in version 0.5.3, so patched installs are not exploitable.
Remote code execution in DeepChat 0.5.1 and below is possible through a cross-site scripting flaw in Mermaid diagram rendering: unauthenticated remote attackers can craft Mermaid content that bypasses the MermaidArtifact.vue sanitization regex using unquoted HTML attributes and HTML entity encoding, then reaches the Electron ipcRenderer interface to execute code on the victim's machine. Exploitation requires user interaction because the victim must open or view the malicious Mermaid content, and no vendor fix is available at time of publication; publicly available exploit code exists. The CVSS score is 9.6 with scope change, reflecting high confidentiality, integrity, and availability impact on the host once the payload executes.
Remote code execution in TUUI, the AI-QL desktop MCP client, affects every release prior to 1.3.4: the Markdown rendering component executes arbitrary JavaScript delivered inside ECharts code blocks, and the injected script pivots through the application's exposed IPC interface to spawn arbitrary system processes on the victim's machine. An unauthenticated remote attacker achieves this simply by getting the victim to open a crafted Markdown message in the client - active user interaction is mandatory, so there is no drive-by against an idle client - with the pre-patch CSP's 'unsafe-eval' allowance making the script execution trivially reliable. Risk is tempered in practice by EPSS 0.43% (roughly the 62nd percentile), the absence of any public exploit code or CISA KEV confirmation at time of analysis, and TUUI's very small user base, which makes exploitation targeted rather than opportunistic; a vendor-released fix ships in version 1.3.4.
electron-updater allows for automatic updates for Electron apps. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.
electron-builder is a solution to package and build a ready for distribution Electron, Proton Native app for macOS, Windows and Linux. Rated high severity (CVSS 7.3), this vulnerability is low attack complexity.
Electron is an open source framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Rated high severity (CVSS 7.0), this vulnerability is no authentication required. No vendor patch available.
Electron is a framework which lets you write cross-platform desktop applications using JavaScript, HTML and CSS. Rated medium severity (CVSS 6.6), this vulnerability is low attack complexity. No vendor patch available.
Electron is a framework which lets you write cross-platform desktop applications using JavaScript, HTML and CSS. Rated high severity (CVSS 8.5), this vulnerability is remotely exploitable. No vendor patch available.
Electron is a framework which lets you write cross-platform desktop applications using JavaScript, HTML and CSS. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
The Electron framework enables writing cross-platform desktop applications using JavaScript, HTML and CSS. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Electron is a framework for writing cross-platform desktop applications using JavaScript (JS), HTML, and CSS. Rated high severity (CVSS 7.2), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Electron is a framework for writing cross-platform desktop applications using JavaScript (JS), HTML, and CSS. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Rated medium severity (CVSS 5.0), this vulnerability is remotely exploitable, low attack complexity. This Exposure of Resource to Wrong Sphere vulnerability could allow attackers to access resources from an unintended security context.
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Rated high severity (CVSS 8.6), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Electron before versions 11.0.0-beta.6, 10.1.2, 9.3.1 or 8.5.2 is vulnerable to a context isolation bypass. Rated medium severity (CVSS 5.6), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.
In Electron before versions 11.0.0-beta.1, 10.0.1, 9.3.0 or 8.5.1 the `will-navigate` event that apps use to prevent navigations to unexpected destinations as per our security recommendations can be. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required.
In Electron before versions 7.2.4, 8.2.4, and 9.0.0-beta21, there is a context isolation bypass. Rated critical severity (CVSS 9.9), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
In Electron before versions 7.2.4, 8.2.4, and 9.0.0-beta21, there is a context isolation bypass. Rated critical severity (CVSS 9.0), this vulnerability is no authentication required, low attack complexity. No vendor patch available.
In Electron before versions 7.2.4, 8.2.4, and 9.0.0-beta21, arbitrary local file read is possible by defining unsafe window options on a child window opened via window.open. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
In Electron before versions 6.1.1, 7.2.4, 8.2.4, and 9.0.0-beta21, there is a context isolation bypass, meaning that code running in the main world context in the renderer can reach into the isolated. Rated medium severity (CVSS 6.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
GitHub Electron 1.7.15, 1.8.7, 2.0.7, and 3.0.0-beta.6, in certain scenarios involving IFRAME elements and "nativeWindowOpen: true" or "sandbox: true" options, is affected by a WebPreferences. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. Public exploit code available and no vendor patch available.
Electron version 1.7 up to 1.7.12; 1.8 up to 1.8.3 and 2.0.0 up to 2.0.0-beta.3 contains an improper handling of values vulnerability in Webviews that can result in remote code execution. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.
Github Electron version Electron 1.8.2-beta.4 and earlier contains a Command Injection vulnerability in Protocol Handler that can result in command execute. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This OS Command Injection vulnerability could allow attackers to execute arbitrary operating system commands on the host.
GitHub Electron before 1.6.8 allows remote command execution because of a nodeIntegration bypass vulnerability. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.
Untrusted search path vulnerability in Atom Electron before 0.33.5 allows local users to gain privileges via a Trojan horse Node.js module in a parent directory of a directory named on a require line. Rated high severity (CVSS 7.8), this vulnerability is low attack complexity.
MongoDB Compass versions prior to 1.53.1 ship an Electron runtime whose bundled TLS root store still contains the compromised, recoverable eMudhra intermediate CA certificates, so a party holding a certificate chained to those intermediates can be treated as trusted by the application. Because the attacker must also occupy a man-in-the-middle position on the network path and induce a user to initiate a Compass connection through it, impact is confidential and integrity-related (VC:H/VI:H) rather than an unauthenticated remote take-over. The vendor resolves the issue in Compass 1.53.1, which bundles Electron 44.9.1; no public exploit code or active exploitation has been reported, and the issue is prioritised as this week rather than an emergency.
Electron before 42.11.16, 43.8.1, 44.9.1 and 45.0.0-beta.6 fails to enforce the blocklist for a set of compromised eMudhra intermediate certificates, so a TLS chain terminating in one of those intermediates is still accepted by Chromium networking and by Node.js tls, https and fetch. An attacker who already holds a leaf certificate issued under one of those intermediates and who can intercept the victim app's network traffic can impersonate a TLS server to that app, breaking both confidentiality and integrity of the connection; the CVSS vector scores this 7.4 with AC:H, unauthenticated (PR:N) and no user interaction, reflecting that the MITM position is the binding constraint. Apps that make no network connections are not affected, and the vendor states there are no app-side workarounds - only an update to a patched Electron release closes the gap. No public exploit code has been identified at time of analysis, and the issue is not in CISA KEV, so the practical risk is a conditional interception scenario rather than a broadly exploited one.
Navigation allowlist bypass in EdgeEver Desktop versions 1.6.26 through 1.112.0 allows an attacker who can get crafted content rendered in the app (for example a note-template preview) to load an arbitrary origin into the main window and capture the edgeeverDesktop bridge, including the session token, sidecar RPC, and ACP channels. The flaw is an incorrect-authorization issue (CWE-863) in which the will-navigate handler trusts a string-prefix match, so a URL that places the trusted dev-server prefix in the userinfo portion (e.g. https://devserver@attacker.tld) is accepted while the real origin is attacker-controlled. Exploitation requires a low-privileged authenticated foothold to plant the content and user interaction for the victim to open or preview it, and no public exploit code has been identified at time of analysis; the source CVSS 4.0 vector scores 8.4 (High), driven by high confidentiality and integrity impact that can escalate to command execution through ACP adapters.
Arbitrary local program execution is possible in EdgeEver Desktop 1.92.0 through 1.112.0 because the desktop:acp-probe IPC handler performs no sender validation and spawns whatever executable path is supplied in the caller's input.path, running it with the victim user's privileges. This is not a standalone network RCE: an attacker must first land stored cross-site scripting in a renderer through the template-preview or drag-preview feature, and the victim must then preview that attacker-controlled content so the renderer script can invoke probeAcpAdapter (CVSS v4.0 7.3; independent assessment CVSS v3.1 AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H). No public exploit code and no CISA KEV listing were identified at time of analysis; an upstream fix commit has been referenced, but no patched release version has been independently confirmed.
Remote code execution on the AstronRPA desktop client through version 1.1.6 is achievable by an on-path attacker who intercepts the client's plaintext HTTP auto-update check and serves a malicious update manifest with an unsigned NSIS installer, which electron-updater installs without verifying a publisher signature. The weakness is CWE-494 (download of code without integrity check), rated 7.7 under CVSS 4.0 with High attack complexity and attack requirements Present because the attacker must already hold a man-in-the-middle position and the client must run an update check; there is no public exploit identified at time of analysis and no vendor-released patch identified at time of analysis, so this is a conditional, non-scalable threat rather than a mass-exploitation emergency.
Arbitrary code execution in Obsidian Desktop builds prior to 1.14.0 is possible when a user opens an attacker-supplied Markdown note and manually starts it as a presentation: a crafted data-background-iframe attribute survives DOMPurify sanitization in the bundled Slides core plugin, and Reveal.js then promotes that value into an iframe src without URL-scheme validation, allowing a javascript: payload to reach Node.js APIs through parent.require in Obsidian's Node-integrated, context-isolation-disabled renderer. The attacker is unauthenticated per the assessed vectors (PR:N) but exploitation is entirely local and user-driven, requiring file-based delivery plus two deliberate user actions (opening the note and launching the presentation), which is why the assessed CVSS 3.1 score is 8.5 with S:C. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV; the vendor has published a patched release, so exposure is eliminated by updating.
Path traversal in Legcord's theme IPC handlers (versions 1.1.0 through 1.3.0) allows an attacker who already has script execution inside the embedded Discord page - for example via XSS - to supply unvalidated theme ids to themes.folder, themes.uninstall, and themes.install and escape the themes directory. That yields arbitrary file writes, recursive directory deletion, and local executable launch, i.e. host code execution; CVSS 4.0 scores it 9.2 (Critical) with full confidentiality, integrity, and availability impact, and PR:N means no further authentication is required once the script foothold exists, while AC:H and AT:P capture that prerequisite. No public exploit code was identified at time of analysis and no CISA KEV listing is present.
Code execution as the logged-in user results when someone running the Twine 2 desktop (Electron) application on version 2.12.0 or earlier imports a crafted story file. The importStories() routine renders untrusted markup from the imported file inside the editor window, and a script smuggled in that markup can reach the twineElectron openWithScratchFile IPC bridge to write and then open a .bat file, yielding arbitrary code execution in the user's context. No public exploit code has been identified at time of analysis, and although no authentication is required (CVSS vector PR:N), exploitation depends on the victim actively importing the attacker's file, so delivery is a social-engineering problem; the CVSS 4.0 base score is 8.5 (High) with high confidentiality, integrity, and availability impact on the local host only.
Code cache poisoning in Electron's sandboxed preload machinery allows a compromised renderer to get its own code executed in the more privileged preload context on a later load, affecting desktop applications built on Electron 42.3.3 through versions prior to 42.10.0, 43.0.0-beta.1 through versions prior to 43.5.0, and 44.0.0-alpha.1 through versions prior to 44.0.0-beta.6. Two prerequisites must both hold: the application must load untrusted content (the vendor explicitly states apps that do not load untrusted content are unaffected), and the attacker must already control a renderer process, so this is a local, low-privilege escalation step (CVSS 3.1 vector AV:L/PR:L) rather than a standalone remote attack. Vendor-released patches are available in 42.10.0, 43.5.0, and 44.0.0-beta.6, there are no app-side workarounds, EPSS is 0.09% (0th percentile), and no public exploit code or confirmed active exploitation (no CISA KEV listing) was identified at time of analysis.
Privilege escalation in the Electron framework lets a <webview> guest grant itself Node.js integration inside its Web Workers even when the embedding (embedder) application has Node integration turned off, so untrusted guest content can obtain a more privileged JavaScript execution context than the host application intended to allow. Affected releases are npm/electron before 41.10.6, 42.x before 42.9.2, 43.x before 43.4.1, and 44.0.0-alpha.x before 44.0.0-beta.5 (CPE cpe:2.3:a:electron:electron). Exploitation is not automatic: the independent assessment requires a non-default deployment where the app enables the <webview> tag, runs the embedder unsandboxed with nodeIntegration disabled, and loads attacker-controllable content into the guest - applications that never enable <webview>, keep the embedder sandboxed, or only load trusted first-party content are unaffected. There is no public exploit identified at time of analysis (CISA SSVC: Exploitation none, Automatable no, Technical Impact total) and EPSS is low at 0.45% (37th percentile), although the underlying privilege boundary is a total-compromise class issue where it applies; the NVD-style vector scores 9.8, while our independent assessment reflects the higher attack complexity and changed scope (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) imposed by those preconditions.
Cross-origin information disclosure in the Electron framework allows untrusted web content loaded inside an Electron application to read responses served through custom protocol schemes registered with protocol.registerFileProtocol or protocol.registerHttpProtocol when supportFetchAPI is enabled but corsEnabled is disabled. Affected are Electron builds prior to 41.10.6, 42.9.2, 43.4.1 and 44.0.0-beta.5; exploitation requires that the host application actually exposes such a scheme and loads attacker-influenced content in the same session, so severity is real but conditional rather than universal. The issue is an incomplete remediation of CVE-2026-70604, no public exploit code or active exploitation has been identified at time of analysis, and unauthenticated remote attackers can trigger it through victim interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N, base 7.4).
Sandbox escape in Electron desktop applications lets untrusted content rendered in a CSP-sandboxed top-level document open popup windows that inherit the application's full privileged origin instead of the restricted origin intended by the sandbox, exposing that origin's cookies and localStorage. Exploitation requires the application to load untrusted content into a document sandboxed via a Content-Security-Policy 'sandbox' directive that still permits popups, and requires user interaction (window.open or target=_blank) per the CVSS vector (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N); applications that deny popups with setWindowOpenHandler are not affected. The flaw is fixed in Electron 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5, and no public exploit code has been identified at time of analysis.
Electron before 41.10.4, 42.5.2, and 43.0.0 fails to propagate HTML iframe sandbox restrictions to popups opened through its OpenURLFromTab navigation path, so an untrusted iframe configured with 'allow-scripts allow-popups' (but without 'allow-popups-to-escape-sandbox') can open a new window that runs with the embedding application's full origin, granting same-origin script access to that origin's cookies and storage. Exploitation requires the target application to embed untrusted web content in such a sandboxed iframe and to trigger a popup - via a scripted target="_blank" link or a middle-click - so the assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N rating marks this as unauthenticated but user-interaction dependent, with high confidentiality and low integrity impact and a changed scope. Applications that do not embed untrusted content in sandboxed iframes are explicitly unaffected; no public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fixed by vendor-released versions 41.10.4, 42.5.2, and 43.0.0.
Stored cross-site scripting in SiYuan versions 3.7.0 through 3.8.3 (fixed in 3.8.4) allows an authenticated user with write access to a shared workspace to plant JavaScript inside a database field description that is later rendered unescaped into an aria-label attribute of gallery and kanban (Attribute View) layouts. When the victim views that board in the SiYuan Electron desktop app - where nodeIntegration is enabled by default - the injected script reaches Node.js child_process APIs and can execute arbitrary commands with the victim's privileges, escalating a rendering flaw into full local code execution. Exploitation is access-gated: it requires an authenticated writer, the victim rendering the poisoned view, and the desktop Electron build, so real-world reach is narrower than the 8.6 CVSS 4.0 headline; no public exploit code or confirmed active exploitation was identified at time of analysis.
Stored cross-site scripting in SiYuan before v3.8.4 allows an authenticated attacker with write access to Attribute View content to persist JavaScript in four unsanitized textarea-backed fields - field descriptions, template sources, select option descriptions, and footer calculation templates - which then executes in the browser session of any user who opens the affected database menu. The desktop Electron build escalates the issue to command execution with SiYuan process privileges when nodeIntegration is enabled, while browser or hardened Electron deployments cap impact at script execution in the victim's session. Vendor-released patch: v3.8.4; no public exploit identified at time of analysis, and the vendor/GHSA advisory plus a VulnCheck advisory are the primary references. CVSS 4.0 base score is 8.5; our independent CVSS 3.1 assessment is AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H, consistent with a genuine but conditionally-gated stored XSS whose RCE escalation depends on the nodeIntegration setting.
Stored cross-site scripting in SiYuan Note before v3.8.4 lets attacker-supplied flashcard block content run script inside the desktop client's privileged Electron renderer, which is created with nodeIntegration enabled and contextIsolation disabled, escalating the XSS to arbitrary code execution on the host. Per the independent assessment, exploitation is meaningfully gated: it requires the SiYuan desktop Electron client, an authenticated administrator account (the /api/riff/getRiffCards endpoint keeps its auth and admin-role checks), attacker-controlled flashcard content already planted in the workspace via import, contribution, or shared/synced documents, and the administrator actively opening the card manager view - so this is a targeted, condition-gated RCE risk rather than a broadly exploitable one, despite the 8.6 CVSS-4.0 headline. No public exploit code was identified at time of analysis and active exploitation is not confirmed; vendor fixes are available in v3.8.4.
Stored cross-site scripting in SiYuan through 3.8.4 lets an attacker inject malicious style values into heading attributes that the outline and bookmark docks render without escaping, so the payload executes as JavaScript inside SiYuan's Electron renderer - which runs with full system access, making this effectively an XSS-to-code-execution condition on the host rather than ordinary script execution in a sandboxed browser context. Delivery is either a crafted notebook that the victim imports or opens, or abuse of SiYuan's administrative endpoints (the latter implying authenticated access); the payload only fires when the victim surfaces the affected heading in the outline or bookmark dock, so user interaction is required (UI:A) and exploitation is not purely passive. No public exploit identified at time of analysis; the CVE carries a CVSS 4.0 base score of 8.6 and was independently assessed as CVSS 3.1 9.6 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H), reflecting the notebook-import path being unauthenticated while the administrative-endpoint path requires credentials.
Stored cross-site scripting in SiYuan through 3.8.4 lets an attacker who can set a notebook name containing an HTML payload have that markup rendered unescaped when the Daily Note picker dialog is opened, executing JavaScript inside the Electron renderer where Node.js integration is available and escalating to operating system command execution. Exploitation is gated by two preconditions: the attacker must be able to create or inject a notebook carrying the payload (a shared or synced workspace, a server-mode multi-user deployment, or an imported malicious notebook), and the victim must open the picker; the assessed CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H, while the published CVSS 4.0 score of 8.6 carries PR:N/UI:A, so the two scorings disagree on whether prior privileges are needed. This is treated as a genuine high-priority issue rather than a high-score-but-low-real-risk case, because the impact chain terminates in OS command execution rather than mere client-side script execution; no public exploit code and no confirmed active exploitation were identified at time of analysis, and a purely local single-user instance that never ingests external notebooks has a materially smaller attack surface.
Cross-site scripting in the SiYuan desktop note-taking app before 3.8.4 allows an attacker who can dictate a document title - either by calling the rename API or by delivering a crafted notebook the victim opens - to inject markup that is rendered as HTML in the backlink dock tree and executed inside the Electron renderer. Because the default desktop build exposes Node's child_process to the renderer, successful script execution escalates from XSS to arbitrary command execution on the victim's machine; the CVSS 4.0 vector rates this 8.6 (PR:N, UI:A), and the independent assessment concurs that this is a genuinely high-priority issue rather than an inflated score. Exploitation still depends on user interaction (the victim must view the poisoned title in the backlink dock or import the malicious notebook), no public exploit code was identified at time of analysis, and there is no KEV confirmation of active exploitation; a vendor patch is available in 3.8.4.
Stored cross-site scripting in SiYuan notebook software before 3.8.4 lets an attacker who supplies a crafted .sy notebook file execute arbitrary script inside the Electron renderer, which in the default desktop build has Node.js child_process access and therefore escalates to host-level command execution. The flaw arises because bookmark labels read from imported notebook files are written into the dock tree HTML without escaping, so unescaped markup in a bookmark attribute is rendered as live DOM. No credentials are required (CVSS PR:N) and no public exploit code or CISA KEV entry has been identified at time of analysis, but the vector requires the victim to import or open the malicious notebook (UI:A/UI:R), making delivery dependent on social engineering; EPSS data was not supplied.
Remote code execution in SiYuan desktop before 3.8.2 allows an unauthenticated network attacker to achieve full Node.js-level system access by poisoning a victim's clipboard from a malicious web page. The paste handler in app/src/protyle/util/paste.ts treated the custom text/siyuan clipboard MIME type as implicitly trusted internal content and skipped HTML sanitization before rendering, and a secondary code path used a same-origin hidden iframe to parse large HTML blobs, permitting inline script execution. Because SiYuan's Electron desktop build enables Node.js integration in the renderer process, injected scripts escape the browser sandbox entirely and execute with the privileges of the running user. A vendor-released patch is available at v3.8.2; no public exploit has been identified at time of analysis.
Cross-origin read bypass in Electron's custom protocol handler exposes sensitive application data to remote pages via fetch() and XMLHttpRequest. Electron apps on any branch prior to 39.8.10, 40.9.3, 41.4.0, or 42.0.0 that register a custom scheme with supportFetchAPI: true but omit corsEnabled: true fail to enforce CORS, allowing a malicious remote page loaded in the renderer to read the full response body of privileged custom-scheme requests. No public exploit code is identified at time of analysis and the vulnerability is not in CISA KEV, but the confidentiality impact is rated high by the vendor given the potential to exfiltrate internal application data.
GitHub Electron versions 1.8.2-beta.3 and earlier, 1.7.10 and earlier, 1.6.15 and earlier has a vulnerability in the protocol handler, specifically Electron apps running on Windows 10, 7 or 2008 that. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Cross-site scripting in the PostyBirb Plus submission description editor affects versions through 3.1.75. Crafted description markup loaded through the editor's defaultValue or overwriteDescriptionValue paths can execute in the Electron renderer, but exploitation requires an authenticated local user of the desktop app and user interaction, and impact is limited to integrity with no confidentiality or availability loss. Version 3.1.76 fixes the issue by sanitizing those loaded values; a public PoC reference exists, but it is not verified as working exploit code.
Server-side request forgery in the Request Forwarder of MusicFreeDesktop 0.0.6, 0.0.7 and 0.0.8 allows a crafted proxy request to be relayed to an attacker-chosen destination, giving low confidentiality, integrity and availability impact (CVSS 4.0 base 5.3; independently assessed as CVSS 3.1 AV:N/AC:L/PR:N/UI:R with low C/I/A). The CVSS vector indicates the attack path is unauthenticated (PR:N) but requires user interaction (UI:P/UI:R), for example a user loading or playing attacker-influenced content that causes the app to emit a proxy request; the exact trigger is not described in the available sources. A public PoC reference exists in the form of GitHub issue #443, but it is not verified as working exploit code, there is no CISA KEV listing, and the vendor fix is upstream commit b0d3876247a0a64fa0e430e4b21870e41f503182.
Out-of-bounds memory read in Electron's macOS offscreen rendering (OSR) path lets an attacker who already has code execution inside the GPU process feed inconsistent frame geometry - a content_rect or pixel_size not backed by the underlying shared-memory mapping or IOSurface - to the main process, which then reads past the end of the mapped buffer while building paint-event images. The result is disclosure of main-process memory contents or an application crash, and exploitation is confined to macOS applications that enable OSR; Windows, Linux, and default windowed Electron apps are unaffected. This is a sandbox/boundary-escalation step rather than a standalone entry point: the assessed vector is CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:L/I:N/A:L (3.9), and attack complexity is high with no public exploit identified at time of analysis. Fixed upstream in Electron 42.11.6, 43.7.3, 44.4.3, and 45.0.0-alpha.9.
Out-of-bounds memory read in Electron's frame-capture path (webContents.beginFrameSubscription) affects all versions prior to 42.11.6, 43.7.3, 44.4.3, and 45.0.0-alpha.9. The main process trusted frame geometry and pixel-format metadata relayed from the GPU process - content_rect, coded_size, pixel_size, and pixel_format - without validating it against the actual shared-memory or IOSurface mapping, so a malicious set of values causes the browser to read past the end of the buffer while assembling captured frames, leaking process memory or crashing the app. Exploitation requires that the target application actually use the frame-subscription API and that the attacker already hold code execution inside the GPU process through some other bug; no public exploit code and no active exploitation were identified at time of analysis, and the CVSS 3.9 score reflects that steep prerequisite rather than the severity of the memory-safety class.
Origin confusion in Electron's external protocol handling lets a launch request be attributed to a document other than the one that actually initiated it, so the requestingUrl handed to session.setPermissionRequestHandler can name trusted content for a launch requested by untrusted content. Applications running Electron prior to 42.11.3, 43.7.0, 44.3.0, or 45.0.0-alpha.5 are exposed only if they both grant openExternal based on that requesting origin and permit untrusted content to open or navigate windows, in which case attacker-supplied content may reach an OS-registered external application such as a mail client or custom URL handler. Exploitation additionally depends on a timing condition where the initiating document is gone when the request reaches the browser (a popup whose opener navigated away, or a server redirect to the external URL), which is why the assessed vector carries AC:H; no public exploit code has been identified at time of analysis, and the issue is not confirmed actively exploited (CISA KEV).
Electron's HID and USB permission checks mishandle the requesting frame's origin, so an app whose setPermissionCheckHandler authorizes devices by origin can be tricked into granting WebHID/WebUSB access to a cross-origin untrusted iframe that was never meant to receive it. Only applications that both delegate the 'hid' or 'usb' permission to an untrusted cross-origin frame via permissions policy and make device decisions on the reported origin are exposed, and a matching device must also be attached; default configurations are not affected. Unauthenticated remote attackers can trigger the logic remotely (CVSS 3.1 AV:N/PR:N), but with high attack complexity and low confidentiality/integrity impact scored at 5.4 with a scope change. No public exploit code and no confirmed active exploitation were identified at time of analysis; fixed in 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.5.
Electron mis-attributes pointerLock permission requests originating from cross-origin iframes, causing session.setPermissionRequestHandler() to receive the top-level frame's requestingUrl and isMainFrame values instead of the actual requesting frame's. Applications that embed untrusted iframe content and grant pointer lock based on the requesting origin can therefore be tricked into granting the permission under the top-level page's identity, allowing an embedded attacker-controlled frame to capture the pointer (integrity and availability impact only, no confidentiality impact). Exploitation requires a user gesture and an affected Electron version prior to 42.11.9, 43.7.6, 44.5.0, or 45.0.0-alpha.13; apps that already deny pointerLock for untrusted content are not affected. No public exploit code was identified at time of analysis and the issue is not in CISA KEV, so real-world risk is limited to the narrow population of apps whose permission handlers trust origin strings for pointer lock.
Electron's chrome.tabs.query() implementation returned the url and title of every tab in a session to extensions that held neither the 'tabs' permission nor a matching host permission, letting a loaded extension enumerate the URLs and titles of all webContents in that session. Only applications that explicitly pull in extensions they do not fully trust via session.extensions.loadExtension are exposed, and only on builds prior to 42.11.1, 43.5.1, 44.1.1, and 45.0.0-alpha.4; unauthenticated remote attackers cannot reach the flaw without such an extension already running inside the app. The disclosed data is limited to tab URLs and titles (no page content, DOM, cookies, or code execution), no public exploit code was identified at time of analysis, and the issue does not appear on CISA KEV, consistent with its low CVSS 3.1 score.
Cross-site request forgery bypass in Electron before 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.6 lets untrusted content loaded by a desktop app make credentialed requests to other sites by corrupting how the framework attributes the initiator of links opened into new windows. Because Electron re-issued such top-level navigations as application-initiated loads rather than preserving the originating page's identity, the request could be judged same-site, causing SameSite=Strict cookies to be attached and Sec-Fetch-Site to omit the true initiator. Rated CVSS 4.2 (AV:N/AC:H/PR:N/UI:R, C:L/I:L/A:N), exploitation requires an app that both loads untrusted content and allows it to open popups (popups are disabled by default), a victim who opens the crafted link into a new window, and a target site that depends on SameSite cookies rather than anti-CSRF tokens; no public exploit code identified at time of analysis and the issue is not in CISA KEV.
Improper authorization of custom URL schemes in Nerimity Desktop up to 2.2.2 allows unauthenticated remote attackers to pass attacker-controlled URLs to Electron's shell.openExternal through the Window Open Handler, and publicly available exploit code exists. Exploitation requires the victim to interact with attacker-supplied content and the host OS to have a registered handler for the abused scheme, which limits practical impact to medium severity. Upgrading to 2.3.3 restricts shell.openExternal to http/https URLs and resolves the flaw.
Credential leak in the GDevelop desktop app through 5.6.284 allows unauthenticated remote attackers to exfiltrate a victim's gd_resource cloud session cookie by embedding an attacker-controlled resource URL in a crafted project file, which downloadLocalFile() requests with the cookie attached regardless of destination host; this exposes private GDevelop cloud project resources. Exploitation requires the victim to open the malicious project while holding an active GDevelop cloud session, so impact is limited to confidentiality (CVSS 4.0 base 5.3, medium; independent assessment CVSS 3.1 5.3, UI:R). No public exploit code or CISA KEV entry was identified in the provided intelligence at time of analysis.
Missing authentication in the Remote Control Server component of eremef bandcamp-player through 1.8.33-beta allows unauthenticated attackers with LAN reachability to control the desktop player's remote interface without a device pairing or approval step. The flaw is rooted in how the remoteEnabled setting is handled in database.ts, and it is practically exposed only when the Remote Control feature is switched on and the legacy, non-secure connection mode (plain HTTP/WS, no pairing) is in use; no victim interaction is required against such a server. No public exploit code or active exploitation has been confirmed, and the vendor has released a patched version, 1.8.34-beta, which turns Secure Mode (HTTPS/WSS with QR pairing and desktop approval) on by default.
Cross-site request forgery in Dyad's OAuth Callback Handler affects Dyad through version 1.16.0 and can let a crafted dyad:// callback be accepted without proof that it belongs to a legitimate in-app connection flow, causing an integrity-only credential/integration state change. Exploitation is remote but requires the Dyad desktop app to be installed with its custom-protocol handler registered and requires the victim to launch or approve the crafted protocol link; there is no confidentiality or availability impact per the independent assessment, and the CVSS 4.0 base score is 5.3. Vendor-released patch: 1.17.0-beta.1; no public exploit identified at time of analysis.
Recursive deletion of arbitrary user-writable directories is possible in the LobsterAI desktop application (NetEase Youdao) versions 2026.5.27 through 2026.9.23 because the skills:delete IPC handler trusts the openclawSourceDir path supplied in a skill's _meta.json during uninstall instead of confining cleanup to the skill's own directory. An attacker who persuades a user to install a crafted skill package - the bundled security scanner never inspects _meta.json, so the package passes vetting - can have the victim's home directory or another user-writable location wiped when that skill is later uninstalled, causing high integrity and availability impact (assessed CVSS:3.1 AV:L/AC:L/PR:N/UI:R, vendor CVSS:4.0 6.9, PR:N/UI:P). The attack is not remotely exploitable and requires user interaction twice (install plus uninstall), and no public exploit code has been identified at time of analysis; the issue is patched upstream (commit 82fdfe10d1b85d0ff734aa720e18c866b4be2406) with the fix adding regression tests that confirm bystander and OpenClaw-sourced directories are no longer touched.
A local time-of-check-to-time-of-use (TOCTOU) race condition in Electron's bundled Squirrel.Mac auto-update framework on macOS allows an attacker who already has local access to the machine to redirect the privileged ShipIt helper into overwriting a different application's files with root privileges during an update install. Only macOS Electron apps that ship Squirrel.Mac-based auto-updates are exposed; apps on other platforms, or that do not use Squirrel.Mac, are unaffected. The attacker is an authenticated local user (CVSS PR:L) and must win a narrow race window between path validation and the root-privileged write (AC:H) while an update is actually being installed (UI:R), yielding high confidentiality, integrity, and availability impact if successful; no public exploit code exists and there is no confirmed active exploitation (no CISA KEV listing), and no app-side workaround exists - remediation requires upgrading Electron to 39.8.10, 41.10.5, or 42.0.0-beta.2.
Cross-workspace denial of service in the SiYuan desktop (Electron) app lets a renderer that is connected to an attacker-controlled remote kernel broadcast a lockscreen command through the 'siyuan-send-windows' IPC handler, locking unrelated local workspace windows. The vulnerable handler does not validate the IPC sender or restrict recipients, so it forwards the payload to every window returned by BrowserWindow.getAllWindows(); sibling windows configured with lockScreenMode=1 invoke lockScreen() on receipt, and repeat messages keep those windows locked. Per the CVSS 4.0 vector the IPC path requires no privileges (PR:N) but does require user interaction (UI:P) - the victim must have multiple workspaces open and must have connected one renderer to the hostile kernel - and impact is availability-only, recoverable by manually unlocking; no public exploit code has been identified at time of analysis.
OS command injection in jhen0409's React Native Debugger up to 0.14.0 allows remote, unauthenticated attackers to run arbitrary shell commands on a developer workstation by supplying a crafted host value that reaches the openDevTools function in electron/window.js when the victim uses the 'Open in Editor' feature against an attacker-controlled debug target. Publicly available exploit code exists (the GitHub gist referenced by VulDB), but there is no confirmed active exploitation (CISA KEV) and the vendor was contacted and did not respond, so no vendor-released patch is identified. Scoring is moderate and consistent with a developer-targeted issue rather than a mass-exploitation priority: the vendor-supplied CVSS 4.0 score is 5.3 (UI:P, E:P) and our independent CVSS 3.1 assessment is 7.8 with high confidentiality, integrity and availability impact, reflecting that a successful injection executes with the privileges of the developer's account but requires the developer to connect the debugger to an attacker-influenced host and to trigger the editor/dev-tools launch.
Local code execution in Acer NitroSense v5 (versions up to and including 5.2.63) allows an attacker who already has shell access on the host to run arbitrary code in the privileged context of the application by connecting to an Electron/Chromium DevTools endpoint left enabled in the production build and bound to localhost TCP port 9993. No authentication or user interaction is required against that debug port, and the assessed CVSS:3.1 vector (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) reflects full confidentiality, integrity and availability impact once local access exists, but the exposure is confined to loopback and is therefore not remotely reachable. No public exploit code was identified and there is no CISA KEV listing at time of analysis; this is a moderate, locally-scoped risk rather than a remote emergency, and its main value to an attacker is as a privilege-escalation or persistence primitive on an already-compromised endpoint.
IPC sender-origin spoofing in the Mattermost Desktop App (versions up to and including 6.2.2.0) lets an attacker-controlled server view send a desktopAPI.leaveCall message that tears down an active call belonging to a different, trusted server connected in the same client. Exploitation is unauthenticated from the attacker's perspective (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L, score 3.8 Low) but requires the victim to be running a multi-server configuration with a live call on one server while another connected server is malicious, compromised, or grants the attacker script access; single-server clients and users with no call in progress are unaffected. Impact is limited to call disruption - no data exposure, no code execution - and no public exploit identified at time of analysis; this is a low-priority, low-impact issue.
Native code execution outside the Chromium sandbox is achievable in Electron prior to 39.8.9, 40.9.2, 41.2.1, and 42.0.0-beta.3 via the DevTools 'reveal in file manager' handler, which incorrectly forwarded attacker-supplied paths to the OS shell-open primitive rather than a safe folder-reveal call. Exploitation requires an attacker to already control JavaScript execution within the DevTools frontend - most plausibly through a malicious DevTools extension - while DevTools is open against a window loading untrusted content. No public exploit code exists and the vulnerability is not listed in CISA KEV; patched releases are available across all active Electron stable and beta branches.
Prototype pollution via Electron's contextBridge allows untrusted renderer-side web content to smuggle a malicious prototype across the isolation boundary into preload script context, bypassing context isolation in versions prior to 39.8.9, 40.9.2, 41.2.2, and 42.0.0-beta.4. Exploitation is conditional on preload scripts accepting object arguments from untrusted content and reading inherited properties without own-property guards. No public exploit has been identified at time of analysis, and the flaw is not listed in CISA KEV; however, the scope-change (S:C) CVSS metric reflects that a successful attack crosses the renderer-to-preload privilege boundary, which can have amplified consequences in apps that expose sensitive Node.js APIs through the bridge.
Code injection in Electron's DevTools API permits arbitrary script execution in the DevTools context via an unsanitized `mode` parameter supplied to `webContents.openDevTools()`. Unsandboxed Electron applications where untrusted input reaches the `mode` argument - or where untrusted content embedded in a `<webview>` element can invoke `openDevTools()` - are exposed to full Node.js-level code execution on the host operating system. No public exploit has been identified at time of analysis, but Electron's own GitHub Security Advisory (GHSA-4f78-qhmw-8j8m) confirms the flaw and vendor-released patches are available across all active release tracks.
Session isolation bypass in Electron's custom protocol handler allows cached HTTP responses from defaultSession to leak across otherwise isolated session partitions. Electron versions 40.x through pre-release 43.x are affected when apps use ProtocolResponse.url without specifying ProtocolResponse.session, causing upstream requests to be routed through defaultSession regardless of which session registered the protocol handler. An attacker who can trigger a cross-session cache hit may read confidential session-scoped content (C:H) or partially influence cached responses (I:L) intended for a different, isolated session; no public exploit or CISA KEV listing exists at time of analysis.
Unrestricted HTTP redirect scheme following in Electron's net module (versions prior to 39.8.8, 40.9.0, 41.2.1, and 42.0.0-beta.3) enables server-side request forgery leading to local file disclosure. When net.fetch() or net.request() follows a redirect issued by an attacker-controlled server targeting a local scheme such as file://, the Electron app can be made to read and expose local filesystem contents if it forwards or returns the response body. No public exploit is identified at time of analysis; however, the vulnerability class (SSRF via redirect scheme bypass, CWE-918) is well understood, and the default redirect-following behavior increases the practical surface area across affected apps.
Path validation bypass in Electron's shell.openPath() allows an attacker-controlled file to be opened in place of one that passed string-based extension validation, due to embedded null bytes not being rejected before OS-level path resolution. Electron-based desktop applications that accept untrusted file paths, validate them using only JavaScript string methods (e.g., endsWith(), regex extension checks), and then pass them to shell.openPath() are affected; apps using Node.js fs APIs (fs.existsSync(), fs.stat()) prior to the call are explicitly not vulnerable. Fixed in versions 39.8.6, 40.9.0, 41.1.1, and 42.0.0-beta.1; no public exploit identified at time of analysis.
Session isolation bypass in Electron allows a malicious or compromised Chrome extension loaded into one session to cross session boundaries and access, navigate, and script windows belonging to a completely separate session. Affected are Electron applications prior to versions 39.8.8, 40.9.0, 41.2.1, and 42.0.0-beta.3 that invoke session.loadExtension and rely on multi-session architecture as a security boundary - a narrowly scoped but architecturally significant trust boundary violation. No public exploit code or CISA KEV listing exists at time of analysis; exploitation requires attacker control of an extension the application has explicitly loaded.
Parent process code-sign spoofing in Electron on macOS allows a local low-privileged attacker to bypass fuse-based hardening controls restricting ELECTRON_RUN_AS_NODE and NODE_OPTIONS, injecting code inside the signed Electron application and inheriting its TCC permissions and keychain access. Only macOS deployments of Electron apps that have explicitly enabled same-signed-parent fuse restrictions are exposed; applications without this hardening are unaffected. No public exploit has been identified at time of analysis, and CVSS AC:H reflects the PID-reuse race-condition timing requirement inherent to the attack.
Remote code execution in 5ire 0.15.2 and earlier arises because the desktop AI assistant renders Mermaid diagrams with securityLevel set to 'loose', allowing attacker-supplied HTML/JavaScript embedded in Markdown to execute inside the Electron renderer and potentially reach the host OS. An unauthenticated network attacker can deliver the malicious Markdown through model responses or shared conversations, but exploitation requires the victim to render the content (UI:R). Publicly available exploit code exists; there is no confirmed active exploitation (not in CISA KEV).
Cross-site scripting in DeepChat's Mermaid diagram renderer escalates to full remote code execution on affected desktop installations prior to 0.5.3, because the Electron IPC renderer is exposed to the DOM - rendering attacker-controlled Mermaid content lets injected JavaScript invoke IPC and run arbitrary system commands. Successful exploitation requires the victim to load or render a crafted diagram (CVSS UI:R, AV:N/AC:L/PR:N/S:C), delivered through chat messages, shared content, or AI/tool output, and publicly available exploit code exists. CVSS 9.6 reflects the high confidentiality, integrity, and availability impact plus changed scope; the issue is fixed in version 0.5.3, so patched installs are not exploitable.
Remote code execution in DeepChat 0.5.1 and below is possible through a cross-site scripting flaw in Mermaid diagram rendering: unauthenticated remote attackers can craft Mermaid content that bypasses the MermaidArtifact.vue sanitization regex using unquoted HTML attributes and HTML entity encoding, then reaches the Electron ipcRenderer interface to execute code on the victim's machine. Exploitation requires user interaction because the victim must open or view the malicious Mermaid content, and no vendor fix is available at time of publication; publicly available exploit code exists. The CVSS score is 9.6 with scope change, reflecting high confidentiality, integrity, and availability impact on the host once the payload executes.
Remote code execution in TUUI, the AI-QL desktop MCP client, affects every release prior to 1.3.4: the Markdown rendering component executes arbitrary JavaScript delivered inside ECharts code blocks, and the injected script pivots through the application's exposed IPC interface to spawn arbitrary system processes on the victim's machine. An unauthenticated remote attacker achieves this simply by getting the victim to open a crafted Markdown message in the client - active user interaction is mandatory, so there is no drive-by against an idle client - with the pre-patch CSP's 'unsafe-eval' allowance making the script execution trivially reliable. Risk is tempered in practice by EPSS 0.43% (roughly the 62nd percentile), the absence of any public exploit code or CISA KEV confirmation at time of analysis, and TUUI's very small user base, which makes exploitation targeted rather than opportunistic; a vendor-released fix ships in version 1.3.4.
electron-updater allows for automatic updates for Electron apps. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.
electron-builder is a solution to package and build a ready for distribution Electron, Proton Native app for macOS, Windows and Linux. Rated high severity (CVSS 7.3), this vulnerability is low attack complexity.
Electron is an open source framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Rated high severity (CVSS 7.0), this vulnerability is no authentication required. No vendor patch available.
Electron is a framework which lets you write cross-platform desktop applications using JavaScript, HTML and CSS. Rated medium severity (CVSS 6.6), this vulnerability is low attack complexity. No vendor patch available.
Electron is a framework which lets you write cross-platform desktop applications using JavaScript, HTML and CSS. Rated high severity (CVSS 8.5), this vulnerability is remotely exploitable. No vendor patch available.
Electron is a framework which lets you write cross-platform desktop applications using JavaScript, HTML and CSS. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
The Electron framework enables writing cross-platform desktop applications using JavaScript, HTML and CSS. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Electron is a framework for writing cross-platform desktop applications using JavaScript (JS), HTML, and CSS. Rated high severity (CVSS 7.2), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Electron is a framework for writing cross-platform desktop applications using JavaScript (JS), HTML, and CSS. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Rated medium severity (CVSS 5.0), this vulnerability is remotely exploitable, low attack complexity. This Exposure of Resource to Wrong Sphere vulnerability could allow attackers to access resources from an unintended security context.
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Rated high severity (CVSS 8.6), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Electron before versions 11.0.0-beta.6, 10.1.2, 9.3.1 or 8.5.2 is vulnerable to a context isolation bypass. Rated medium severity (CVSS 5.6), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.
In Electron before versions 11.0.0-beta.1, 10.0.1, 9.3.0 or 8.5.1 the `will-navigate` event that apps use to prevent navigations to unexpected destinations as per our security recommendations can be. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required.
In Electron before versions 7.2.4, 8.2.4, and 9.0.0-beta21, there is a context isolation bypass. Rated critical severity (CVSS 9.9), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
In Electron before versions 7.2.4, 8.2.4, and 9.0.0-beta21, there is a context isolation bypass. Rated critical severity (CVSS 9.0), this vulnerability is no authentication required, low attack complexity. No vendor patch available.
In Electron before versions 7.2.4, 8.2.4, and 9.0.0-beta21, arbitrary local file read is possible by defining unsafe window options on a child window opened via window.open. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
In Electron before versions 6.1.1, 7.2.4, 8.2.4, and 9.0.0-beta21, there is a context isolation bypass, meaning that code running in the main world context in the renderer can reach into the isolated. Rated medium severity (CVSS 6.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
GitHub Electron 1.7.15, 1.8.7, 2.0.7, and 3.0.0-beta.6, in certain scenarios involving IFRAME elements and "nativeWindowOpen: true" or "sandbox: true" options, is affected by a WebPreferences. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. Public exploit code available and no vendor patch available.
Electron version 1.7 up to 1.7.12; 1.8 up to 1.8.3 and 2.0.0 up to 2.0.0-beta.3 contains an improper handling of values vulnerability in Webviews that can result in remote code execution. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.
Github Electron version Electron 1.8.2-beta.4 and earlier contains a Command Injection vulnerability in Protocol Handler that can result in command execute. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This OS Command Injection vulnerability could allow attackers to execute arbitrary operating system commands on the host.
GitHub Electron before 1.6.8 allows remote command execution because of a nodeIntegration bypass vulnerability. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.
Untrusted search path vulnerability in Atom Electron before 0.33.5 allows local users to gain privileges via a Trojan horse Node.js module in a parent directory of a directory named on a require line. Rated high severity (CVSS 7.8), this vulnerability is low attack complexity.