Oculo MCP Server

Electron: AppleScript injection in app.moveToApplicationsFolder on macOS

### Impact On macOS, `app.moveToApplicationsFolder()` used an AppleScript fallback path that did not properly handle certain characters in the application bundle path. Under specific conditions, a crafted launch path could lead to arbitrary AppleScript execution when the user accepted the move-to-Applications prompt. Apps are only affected if they call `app.moveToApplicationsFolder()`. Apps that do not use this API are not affected. ### Workarounds There are no app side workarounds, developers

Electron: Service worker can spoof executeJavaScript IPC replies

### Impact A service worker running in a session could spoof reply messages on the internal IPC channel used by `webContents.executeJavaScript()` and related methods, causing the main-process promise to resolve with attacker-controlled data. Apps are only affected if they have service workers registered and use the result of `webContents.executeJavaScript()` (or `webFrameMain.executeJavaScript()`) in security-sensitive decisions. ### Workarounds Do not trust the return value of `webContents.ex

Electron: Incorrect origin passed to permission request handler for iframe requests

### Impact When an iframe requests `fullscreen`, `pointerLock`, `keyboardLock`, `openExternal`, or `media` permissions, the origin passed to `session.setPermissionRequestHandler()` was the top-level page's origin rather than the requesting iframe's origin. Apps that grant permissions based on the origin parameter or `webContents.getURL()` may inadvertently grant permissions to embedded third-party content. The correct requesting URL remains available via `details.requestingUrl`. Apps that alrea

Electron: Out-of-bounds read in second-instance IPC on macOS and Linux

### Impact On macOS and Linux, apps that call `app.requestSingleInstanceLock()` were vulnerable to an out-of-bounds heap read when parsing a crafted second-instance message. Leaked memory could be delivered to the app's `second-instance` event handler. This issue is limited to processes running as the same user as the Electron app. Apps that do not call `app.requestSingleInstanceLock()` are not affected. Windows is not affected by this issue. ### Workarounds There are no app side workarounds,

Electron: nodeIntegrationInWorker not correctly scoped in shared renderer processes

### Impact The `nodeIntegrationInWorker` webPreference was not correctly scoped in all configurations. In certain process-sharing scenarios, workers spawned in frames configured with `nodeIntegrationInWorker: false` could still receive Node.js integration. Apps are only affected if they enable `nodeIntegrationInWorker`. Apps that do not use `nodeIntegrationInWorker` are not affected. ### Workarounds Avoid enabling `nodeIntegrationInWorker` in apps that also open child windows or embed content

Electron: Use-after-free in offscreen child window paint callback

### Impact Apps that use offscreen rendering and allow child windows via `window.open()` may be vulnerable to a use-after-free. If the parent offscreen `WebContents` is destroyed while a child window remains open, subsequent paint frames on the child dereference freed memory, which may lead to a crash or memory corruption. Apps are only affected if they use offscreen rendering (`webPreferences.offscreen: true`) and their `setWindowOpenHandler` permits child windows. Apps that do not use offscre

Electron: Registry key path injection in app.setAsDefaultProtocolClient on Windows

### Impact On Windows, `app.setAsDefaultProtocolClient(protocol)` did not validate the protocol name before writing to the registry. Apps that pass untrusted input as the protocol name may allow an attacker to write to arbitrary subkeys under `HKCU\Software\Classes\`, potentially hijacking existing protocol handlers. Apps are only affected if they call `app.setAsDefaultProtocolClient()` with a protocol name derived from external or untrusted input. Apps that use a hardcoded protocol name are no

Electron: Use-after-free in download save dialog callback

### Impact Apps that allow downloads and programmatically destroy sessions may be vulnerable to a use-after-free. If a session is torn down while a native save-file dialog is open for a download, dismissing the dialog dereferences freed memory, which may lead to a crash or memory corruption. Apps that do not destroy sessions at runtime, or that do not permit downloads, are not affected. ### Workarounds Avoid destroying sessions while a download save dialog may be open. Cancel pending downloads

Electron: Use-after-free in WebContents fullscreen, pointer-lock, and keyboard-lock permission callbacks

### Impact Apps that register an asynchronous `session.setPermissionRequestHandler()` may be vulnerable to a use-after-free when handling fullscreen, pointer-lock, or keyboard-lock permission requests. If the requesting frame navigates or the window closes while the permission handler is pending, invoking the stored callback dereferences freed memory, which may lead to a crash or memory corruption. Apps that do not set a permission request handler, or whose handler responds synchronously, are n

Electron: Use-after-free in PowerMonitor on Windows and macOS

### Impact Apps that use the `powerMonitor` module may be vulnerable to a use-after-free. After the native `PowerMonitor` object is garbage-collected, the associated OS-level resources (a message window on Windows, a shutdown handler on macOS) retain dangling references. A subsequent session-change event (Windows) or system shutdown (macOS) dereferences freed memory, which may lead to a crash or memory corruption. All apps that access `powerMonitor` events (`suspend`, `resume`, `lock-screen`, e

Electron: Renderer command-line switch injection via undocumented commandLineSwitches webPreference

### Impact An undocumented `commandLineSwitches` webPreference allowed arbitrary switches to be appended to the renderer process command line. Apps that construct `webPreferences` by spreading untrusted configuration objects may inadvertently allow an attacker to inject switches that disable renderer sandboxing or web security controls. Apps are only affected if they construct `webPreferences` from external or untrusted input without an allowlist. Apps that use a fixed, hardcoded `webPreference

Electron: Unquoted executable path in app.setLoginItemSettings on Windows

### Impact On Windows, `app.setLoginItemSettings({openAtLogin: true})` wrote the executable path to the `Run` registry key without quoting. If the app is installed to a path containing spaces, an attacker with write access to an ancestor directory may be able to cause a different executable to run at login instead of the intended app. On a default Windows install, standard system directories are protected against writes by standard users, so exploitation typically requires a non-standard instal

Electron: HTTP Response Header Injection in custom protocol handlers and webRequest

### Impact Apps that register custom protocol handlers via `protocol.handle()` / `protocol.registerSchemesAsPrivileged()` or modify response headers via `webRequest.onHeadersReceived` may be vulnerable to HTTP response header injection if attacker-controlled input is reflected into a response header name or value. An attacker who can influence a header value may be able to inject additional response headers, affecting cookies, content security policy, or cross-origin access controls. Apps that

Electron: USB device selection not validated against filtered device list

### Impact The `select-usb-device` event callback did not validate the chosen device ID against the filtered list that was presented to the handler. An app whose handler could be influenced to select a device ID outside the filtered set would grant access to a device that did not match the renderer's requested `filters` or was listed in `exclusionFilters`. The WebUSB security blocklist remained enforced regardless, so security-sensitive devices on the blocklist were not affected. The practical

Electron has ASAR Integrity Bypass via resource modification

### Impact This only impacts apps that have the `embeddedAsarIntegrityValidation` and `onlyLoadAppFromAsar` [fuses](https://www.electronjs.org/docs/latest/tutorial/fuses) enabled. Apps without these fuses enabled are not impacted. Specifically this issue can only be exploited if your app is launched from a filesystem the attacker has write access too. i.e. the ability to edit files inside the `resources` folder in your app installation on Windows which these fuses are supposed to protect agai

Electron vulnerable to Heap Buffer Overflow in NativeImage

### Impact The `nativeImage.createFromPath()` and `nativeImage.createFromBuffer()` functions call a function downstream that is vulnerable to a heap buffer overflow. An Electron program that uses either of the affected functions is vulnerable to a buffer overflow if an attacker is in control of the image's height, width, and contents. ### Workaround There are no app-side workarounds for this issue. You must update your Electron version to be protected. ### Patches - `v28.3.2` - `v29.3.3` - `v

electron ASAR Integrity bypass by just modifying the content

electron's ASAR Integrity can be bypass by modifying the content. ### Impact This only impacts apps that have the `embeddedAsarIntegrityValidation` and `onlyLoadAppFromAsar` [fuses](https://www.electronjs.org/docs/latest/tutorial/fuses) enabled. Apps without these fuses enabled are not impacted. This issue is specific to Windows, apps using these fuses on macOS are unimpacted. Specifically this issue can only be exploited if your app is launched from a filesystem the attacker has write access

ASAR Integrity bypass via filetype confusion in electron

### Impact This only impacts apps that have the `embeddedAsarIntegrityValidation` and `onlyLoadAppFromAsar` [fuses](https://www.electronjs.org/docs/latest/tutorial/fuses) enabled. Apps without these fuses enabled are not impacted. This issue is specific to macOS as these fuses are only currently supported on macOS. Specifically this issue can only be exploited if your app is launched from a filesystem the attacker has write access too. i.e. the ability to edit files inside the `resources` fo

Electron affected by libvpx's heap buffer overflow in vp8 encoding

Heap buffer overflow in vp8 encoding in libvpx in Google Chrome prior to 117.0.5938.132 and libvpx 1.13.1 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

libwebp: OOB write in BuildHuffmanTable

Heap buffer overflow in libwebp allow a remote attacker to perform an out of bounds memory write via a crafted HTML page.

Electron vulnerable to out-of-package code execution when launched with arbitrary cwd

### Impact Apps that are launched as command line executables are impacted. E.g. if your app exposes itself in the path as `myapp --help` Specifically this issue can only be exploited if the following conditions are met: * Your app is launched with an attacker-controlled working directory * The attacker has the ability to write files to that working directory This makes the risk quite low, in fact normally issues of this kind are considered outside of our threat model as similar to Chromium w

Electron context isolation bypass via nested unserializable return value

### Impact Apps using `contextIsolation` and `contextBridge` are affected. This is a context isolation bypass, meaning that code running in the main world context in the renderer can reach into the isolated Electron context and perform privileged actions. ### Workarounds This issue is exploitable under either of two conditions: * If an API exposed to the main world via `contextBridge` can return an object or array that contains a JS object which cannot be serialized, for instance, a canvas ren

Electron's Content-Secrity-Policy disabling eval not applied consistently in renderers with sandbox disabled

### Impact A Content-Security-Policy that disables eval, specifically setting a `script-src` directive and _not_ providing `unsafe-eval` in that directive, is not respected in renderers that have sandbox and contextIsolation disabled. i.e. `sandbox: false` and `contextIsolation: false` in the `webPreferences` object. This resulted in incorrectly allowing usage of methods like `eval()` and `new Function`, which can result in an expanded attack surface. ### Patches This issue only ever affected

Heap buffer overflow in GPU

Heap buffer overflow in GPU in Google Chrome prior to 107.0.5304.121 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)

Exfiltration of hashed SMB credentials on Windows via file:// redirect

### Impact When following a redirect, Electron delays a check for redirecting to file:// URLs from other schemes. The contents of the file is not available to the renderer following the redirect, but if the redirect target is a SMB URL such as `file://some.website.com/`, then in some cases, Windows will connect to that server and attempt NTLM authentication, which can include sending hashed credentials. ### Patches This issue has been fixed in all current stable versions of Electron. Specifical

AutoUpdater module fails to validate certain nested components of the bundle

### Impact This vulnerability allows attackers who have control over a given apps update server / update storage to serve maliciously crafted update packages that pass the code signing validation check but contain malicious code in some components. Please note that this kind of attack would require **significant** privileges in your own auto updating infrastructure and the ease of that attack entirely depends on your infrastructure security. ### Patches This has been patched and the following

Compromised child renderer processes could obtain IPC access without nodeIntegrationInSubFrames being enabled

### Impact This vulnerability allows a renderer with JS execution to obtain access to a new renderer process with `nodeIntegrationInSubFrames` enabled which in turn allows effective access to `ipcRenderer`. Please note the misleadingly named `nodeIntegrationInSubFrames` option does not implicitly grant Node.js access rather it depends on the existing `sandbox` setting. If your application is sandboxed then `nodeIntegrationInSubFrames` just gives access to the sandboxed renderer APIs (which inc

Electron vulnerable to remote command execution

Electron before 1.6.8 allows remote command execution because of a `nodeIntegration` bypass vulnerability. This also affects all applications that bundle Electron code equivalent to 1.6.8 or earlier. Bypassing the Same Origin Policy (SOP) is a precondition; however, recent Electron versions do not have strict SOP enforcement. Combining an SOP bypass with a privileged URL internally used by Electron, it was possible to execute native Node.js primitives in order to run OS commands on the user's ho

Electron vulnerable to URL spoofing via PDFium

Electron version 1.7.0 - 1.7.5 is vulnerable to a URL Spoofing problem when opening PDFs in PDFium resulting loading arbitrary PDFs that a hacker can control.

Renderers can obtain access to random bluetooth device without permission in Electron

### Impact This vulnerability allows renderers to obtain access to a random bluetooth device via the [web bluetooth API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API) if the app has not configured a custom `select-bluetooth-device` event handler. The device that is accessed is random and the attacker would have no way of selecting a specific device. All current stable versions of Electron are affected. ### Patches This has been patched and the following Electron versions

Electron's sandboxed renderers can obtain thumbnails of arbitrary files through the nativeImage API

### Impact This vulnerability allows a sandboxed renderer to request a "thumbnail" image of an arbitrary file on the user's system. The thumbnail can potentially include significant parts of the original file, including textual data in many cases. All current stable versions of Electron are affected. ### Patches This was fixed with #30728, and the following Electron versions contain the fix: - 15.0.0-alpha.10 - 14.0.0 - 13.3.0 - 12.1.0 - 11.5.0 ### Workarounds If your app enables `contextIso

IPC messages delivered to the wrong frame in Electron

### Impact IPC messages sent from the main process to a subframe in the renderer process, through `webContents.sendToFrame`, `event.reply` or when using the `remote` module, can in some cases be delivered to the wrong frame. If your app does ANY of the following, then it is impacted by this issue: - Uses `remote` - Calls `webContents.sendToFrame` - Calls `event.reply` in an IPC message handler ### Patches This has been fixed in the following versions: - 9.4.0 - 10.2.0 - 11.1.0 - 12.0.0-beta.9

Context isolation bypass in Electron

### Impact Apps using both `contextIsolation` and `sandbox: true` are affected. Apps using both `contextIsolation` and `nativeWindowOpen: true` are affected. This is a context isolation bypass, meaning that code running in the main world context in the renderer can reach into the isolated Electron context and perform privileged actions. ### Workarounds There are no app-side workarounds, you must update your Electron version to be protected. ### Fixed Versions * `11.0.0-beta.6` * `10.1.2` * `9

Unpreventable top-level navigation

### Impact The `will-navigate` event that apps use to prevent navigations to unexpected destinations [as per our security recommendations](https://www.electronjs.org/docs/tutorial/security) can be bypassed when a sub-frame performs a top-frame navigation across sites. ### Patches * `11.0.0-beta.1` * `10.0.1` * `9.3.0` * `8.5.1` ### Workarounds Sandbox all your iframes using the [`sandbox` attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox). This will pre

Arbitrary file read via window-open IPC in Electron

### Impact The vulnerability allows arbitrary local file read by defining unsafe window options on a child window opened via window.open. ### Workarounds Ensure you are calling `event.preventDefault()` on all [`new-window`](https://electronjs.org/docs/api/web-contents#event-new-window) events where the `url` or `options` is not something you expect. ### Fixed Versions * `9.0.0-beta.21` * `8.2.4` * `7.2.4` ### For more information If you have any questions or comments about this advisory: * Em

Context isolation bypass via contextBridge in Electron

### Impact Apps using both `contextIsolation` and `contextBridge` are affected. This is a context isolation bypass, meaning that code running in the main world context in the renderer can reach into the isolated Electron context and perform privileged actions. ### Workarounds There are no app-side workarounds, you must update your Electron version to be protected. ### Fixed Versions * `9.0.0-beta.21` * `8.2.4` * `7.2.4` ### For more information If you have any questions or comments about thi

Context isolation bypass via leaked cross-context objects in Electron

### Impact Apps using `contextIsolation` are affected. This is a context isolation bypass, meaning that code running in the main world context in the renderer can reach into the isolated Electron context and perform privileged actions. ### Workarounds There are no app-side workarounds, you must update your Electron version to be protected. ### Fixed Versions * `9.0.0-beta.21` * `8.2.4` * `7.2.4` ### Non-Impacted Versions * `9.0.0-beta.*` ### For more information If you have any questions or

Context isolation bypass via Promise in Electron

### Impact Apps using `contextIsolation` are affected. This is a context isolation bypass, meaning that code running in the main world context in the renderer can reach into the isolated Electron context and perform privileged actions. ### Workarounds There are no app-side workarounds, you must update your Electron version to be protected. ### Fixed Versions * `9.0.0-beta.21` * `8.2.4` * `7.2.4` * `6.1.11` ### For more information If you have any questions or comments about this advisory: *

Electron webPreferences vulnerability can be used to perform remote code execution

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 vulnerability that can be leveraged to perform remote code execution. More information to determine if you are impacted can be found on the [electron blog](https://electronjs.org/blog/web-preferences-fix). ## Recommendation Upgrade Electron to >=3.0.0-beta.7, >=2.0.8, >=1.8.8, or >=1.7.16.

Chromium Remote Code Execution in electron

Affected versions of `ElectronJS` are susceptible to a remote code execution vulnerability that occurs when an affected application access remote content, even if the [sandbox option](https://electron.atom.io/docs/api/sandbox-option) is enabled. ## Recommendation Update to electron version 1.7.8 or later.

Electron protocol handler browser vulnerable to Command Injection

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. This attack appear to be exploitable via the victim opening an electron protocol handler in their browser. This vulnerability appears to have been fixed in Electron 1.8.2-beta.5. This issue is due to an incomplete fix for CVE-2018-1000006, specifically the black list used was not case insensitive allowing an attacker to potentially bypass it

Electron Vulnerable to Code Execution by Re-Enabling Node.js Integration

A vulnerability has been discovered which allows Node.js integration to be re-enabled in some Electron applications that disable it. For the application to be impacted by this vulnerability it must meet all of these conditions - Runs on Electron 1.7, 1.8, or a 2.0.0-beta - Allows execution of arbitrary remote code - Disables Node.js integration - Does not explicitly declare webviewTag: false in its webPreferences - Does not enable the nativeWindowOption option - Does not intercept new-window e

Remote Code Execution in electron

Affected versions of `electron` may be susceptible to a remote code execution flaw when certain conditions are met: 1. The electron application is running on Windows. 2. The electron application registers as the default handler for a protocol, such as `nodeapp://`. This vulnerability is caused by a failure to sanitize additional arguments to chromium in the command line handler for Electron. MacOS and Linux are not vulnerable. ## Recommendation Update electron to a version that is not vulne

High severity vulnerability that affects electron

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.