Super Productivity is an advanced todo list app with integrated timeboxing and time tracking capabilities. Prior to 18.13.0, the EXEC IPC handler in electron/ipc-handlers/exec.ts accepts a command string from the renderer through the IPC.EXEC channel and executes it with childprocess.exec(). The electron/preload.ts bridge exposes window.ea.exec() to renderer code, including community plugins executed with new Function(), without requiring nodeExecution permission. A confirmation dialog protects only the first execution, its persistence checkbox is selected by default, and approved commands are stored in the ALLOWEDCOMMANDS value in simpleSettings for silent later execution with the desktop account's privileges. This issue is fixed in version 18.13.0.

Impact On macOS, the check Electron uses to confirm it was launched by a same-signed parent process could be bypassed by a local process. Apps that enable the fuse-based hardening restricting ELECTRONRUNASNODE and NODEOPTIONS to same-signed parents rely on this check; a local attacker could bypass it and run their own code inside the signed app, inheriting its TCC permissions and keychain access.

Apps are only affected if they enable those macOS fuse-based restrictions. Apps that do not enable them are not affected.

Workarounds There are no app side workarounds, you must update to a patched version of Electron.

Fixed Versions 42.0.0-beta.3 41.2.1 40.9.0 39.8.8

For more information If you have any questions or comments about this advisory, email us at security@electronjs.org

Impact The DevTools "reveal in file manager" action could launch the target file rather than reveal it. An attacker with a separate means of running script inside the DevTools frontend (such as a malicious DevTools extension) could use this to execute native code outside the sandbox.

Apps are only affected if DevTools is opened for windows exposed to untrusted content or untrusted DevTools extensions. Apps that do not open DevTools in that context are not affected.

Workarounds Do not open DevTools for windows that load untrusted content, and do not load untrusted DevTools extensions.

Fixed Versions 42.0.0-beta.3 41.2.1 40.9.2 39.8.9

For more information If you have any questions or comments about this advisory, email Electron at security@electronjs.org

Summary

In electron-builder's builder-util-runtime package, the HTTP redirect handler (HttpExecutor.prepareRedirectUrlOptions) only stripped a credential header whose key string matched exactly lowercase "authorization". Other credential-bearing headers — most notably PRIVATE-TOKEN (used by GitLab's personal access token flow) and mixed-case Authorization (used by GitLab's Bearer/OAuth flow) — were not stripped and could be forwarded to an attacker-controlled cross-origin redirect destination.

---

Details

Root cause

HttpExecutor.prepareRedirectUrlOptions (introduced in builder-util-runtime via PR #9211, first released in v26.0.20) performed its cross-origin credential strip with a single case-sensitive property check:

typescript // vulnerable code (electron-builder v26.0.20 – v26.14.x) [via builder-util-runtime <9.7.0] if (headers?.authorization) { if (HttpExecutor.isCrossOriginRedirect(originalUrl, parsedRedirectUrl)) { delete headers.authorization // only removes the exact key "authorization" } }

JavaScript object property access is case-sensitive. The guard headers?.authorization evaluates to undefined (falsy) when the key is "Authorization", "AUTHORIZATION", or any other casing, so the branch is never entered and no header is deleted for those cases.

Affected updater flows

The clearest reproduced path is the private GitLab updater flow.

packages/electron-updater/src/providers/GitLabProvider.ts sets one of two credential headers depending on the token type:

typescript // GitLabProvider.setAuthHeaderForToken (affected versions) if (token.startsWith("Bearer")) { headers.authorization = token // Bearer / OAuth token → key is lowercase } else { headers["PRIVATE-TOKEN"] = token // personal access token → key is "PRIVATE-TOKEN" }

During a private release update check, the updater requests a release asset through GitLab's directasseturl. GitLab commonly redirects asset downloads to an external object-storage origin (e.g., S3, GCS). Because the redirect crosses origins:

1. A personal access token in PRIVATE-TOKEN is never inspected by the vulnerable strip guard — it is forwarded intact. 2. A Bearer token set as headers.authorization (lowercase) is stripped correctly. 3. A Bearer token set as headers.Authorization (capital A) or any other mixed-case variant bypasses the guard and is forwarded intact.

GitLab is the concrete reproduced case; any other provider or custom updater configuration that places credentials in a non-lowercase-authorization header is equally affected.

Before v26.0.20

Versions prior to v26.0.20 did not contain prepareRedirectUrlOptions at all. All credential headers were forwarded unchanged on every redirect, regardless of origin. This represents a broader, pre-existing version of the same class of vulnerability.

---

Proof of concept (reproduction shape)

1. Configure the updater with an authenticated GitLab provider, supplying a personal access token (non-Bearer). The provider will set PRIVATE-TOKEN: <token> on requests. 2. Trigger an update check. The updater fetches release metadata and then requests a release asset URL. 3. The trusted GitLab origin returns a 3xx cross-origin redirect (e.g., to S3 object storage). 4. HttpExecutor.prepareRedirectUrlOptions is called. The guard headers?.authorization is falsy (the key is "PRIVATE-TOKEN"). No header is deleted. 5. The request to the redirect destination is issued with PRIVATE-TOKEN: <token> present in the headers.

Observed result: The personal access token is forwarded to the redirect destination. An attacker who controls or can observe the redirect destination receives the token.

---

Impact

This is a credential disclosure vulnerability. An automatic update check can leak:

- GitLab personal access tokens (PRIVATE-TOKEN) - Bearer/OAuth tokens sent under a mixed-case Authorization key - Any other credential header not named exactly "authorization" in lowercase

Disclosure of a GitLab PAT grants the attacker whatever repository and API permissions the token carries, enabling unauthorized access to private source code, packages, or release artifacts.

---

Patches

Fixed in electron-builder v26.15.0 [included via v9.7.0 builder-util-runtime] via PR #9834 (commit 22a7532bd).

The incomplete property-access guard was replaced with a separator-agnostic, case-insensitive lookup against a registry of known sensitive header names:

typescript // fixed code (v9.7.0+) const normalizeName = (name: string): string => name.toLowerCase().replace(/[-]/g, "")

const SENSITIVEREDIRECTHEADERS = new Set([ "authorization", "proxyauthorization", "privatetoken", "xapikey", "xauthtoken", "xaccesstoken", "xgitlabtoken", "cookie", "xcsrftoken", ])

// In prepareRedirectUrlOptions, on cross-origin redirect: for (const key of Object.keys(headers)) { if (SENSITIVEREDIRECTHEADERS.has(normalizeName(key))) { delete (headers as Record<string, unknown>)[key] } }

normalizeName converts to lowercase and strips - and separators, so PRIVATE-TOKEN, Private-Token, Authorization, AUTHORIZATION, X-Api-Key, etc. are all matched. The fix also exports addSensitiveRedirectHeader() to allow custom publishers to register additional headers.

Upgrade path: Update builder-util-runtime to >= 9.7.0.

---

Workarounds

There is no configuration-level workaround that prevents header forwarding in affected versions. The only mitigation short of upgrading is to avoid authenticated GitLab updater flows on versions < 9.7.0.

If operating in a network environment where you control all possible redirect destinations, you may be able to prevent the token from reaching an attacker-controlled host through network-layer controls, but this is not a reliable mitigation.

End of life: 3/2/2027, Latest version: 44.4.3

Summary

AppImage targets built by app-builder-lib could use an empty path component when setting the LDLIBRARYPATH environment variable at runtime. This causes the current working directory to be added to the dynamic linker search path, which may allow an attacker to execute arbitrary code by placing a malicious shared library in the directory from which the AppImage is launched.

This vulnerability is the same class as CVE-2024-41817.

Details

The vulnerability existed in two independent code paths within app-builder-lib (toolset 1.0.0) and through upstream dependency app-builder-bin (toolset 0.0.0).

Path 1 — Modern static runtime (AppRun generated by TypeScript)

The AppRun script generated by app-builder-lib contained this line:

bash export LDLIBRARYPATH="${APPDIR}/usr/lib:${LDLIBRARYPATH}"

When LDLIBRARYPATH is not set in the environment at launch time, this evaluates to:

/path/to/app.AppDir/usr/lib:

The trailing : is treated by the dynamic linker as an empty path component, which resolves to the current working directory. If an attacker can place a malicious shared library (e.g., libfoo.so) in the directory from which the AppImage is executed, that library will be loaded in place of the legitimate one, resulting in arbitrary code execution.

The same issue affected PATH, XDGDATADIRS, and GSETTINGSSCHEMADIR in the same script.

bash export LDLIBRARYPATH="${APPDIR}/usr/lib${LDLIBRARYPATH:+:${LDLIBRARYPATH}}"

Path 2 — Legacy FUSE2 toolset (app-builder-bin)

AppImage targets built using the legacy FUSE2 toolset (toolsets.appimage = "0.0.0") delegated AppRun script generation to the app-builder-bin Go binary, which contained the same vulnerable template:

https://github.com/develar/app-builder/blob/7004925f95d8f034fc88d7e782c9aa7583debb8e/pkg/package-format/appimage/templates/AppRun.sh#L27

Impact

An attacker with the ability to write files to the directory from which a vulnerable AppImage is executed can cause arbitrary shared libraries to be loaded into the application process, resulting in arbitrary code execution with the privileges of the user running the AppImage.

Affected Versions

This was fully resolved in app-builder-lib@26.15.0 (commit 01b8ba979, PR #9829) when app-builder-bin was removed from the dependency tree entirely and all AppImage construction was migrated to the TypeScript implementation.

Workarounds

Set LDLIBRARYPATH to a non-empty value before launching the AppImage, so that the concatenation does not produce an empty path component. Alternatively, avoid running AppImage files from world-writable directories such as /tmp.

End of life: 1/5/2027, Latest version: 43.7.3

End of life: 10/20/2026, Latest version: 42.11.6

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 38.8.6, 39.8.0, 40.7.0, and 41.0.0-beta.8, 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 not affected. This issue has been patched in versions 38.8.6, 39.8.0, 40.7.0, and 41.0.0-beta.8.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 38.8.6, 39.8.0, 40.7.0, and 41.0.0-beta.8, 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 webPreferences object are not affected. This issue has been patched in versions 38.8.6, 39.8.0, 40.7.0, and 41.0.0-beta.8.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. From versions 39.0.0-alpha.1 to before 39.8.0, 40.0.0-alpha.1 to before 40.7.0, and 41.0.0-alpha.1 to before 41.0.0-beta.8, apps that pass VideoFrame objects (from the WebCodecs API) across the contextBridge are vulnerable to a context isolation bypass. An attacker who can execute JavaScript in the main world (for example, via XSS) can use a bridged VideoFrame to gain access to the isolated world, including any Node.js APIs exposed to the preload script. Apps are only affected if a preload script returns, resolves, or passes a VideoFrame object to the main world via contextBridge.exposeInMainWorld(). Apps that do not bridge VideoFrame objects are not affected. This issue has been patched in versions 39.8.0, 40.7.0, and 41.0.0-beta.8.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 39.8.1, 40.7.0, and 41.0.0, 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 offscreen rendering, or that deny child windows, are not affected. This issue has been patched in versions 39.8.1, 40.7.0, and 41.0.0.

End of life: 8/25/2026, Latest version: 41.10.7

End of life: 6/30/2026, Latest version: 40.10.6

Impact Windows-Only: The NSIS installer makes a system call to open cmd.exe via NSExec in the .nsh installer script. NSExec by default searches the current directory of where the installer is located before searching PATH. This means that if an attacker can place a malicious executable file named cmd.exe in the same folder as the installer, the installer will run the malicious file.

Patches Fixed in https://github.com/electron-userland/electron-builder/pull/8059

Workarounds None, it executes at the installer-level before the app is present on the system, so there's no way to check if it exists in a current installer.

References https://cwe.mitre.org/data/definitions/426.html https://cwe.mitre.org/data/definitions/427

End of life: 5/5/2026, Latest version: 39.8.10

Electron Capture facilitates video playback for screen-sharing and capture. In versions 2.19.1 and below, the elecap app on macOS allows local unprivileged users to bypass macOS TCC privacy protections by enabling ELECTRONRUNASNODE. This environment variable allows arbitrary Node.js code to be executed via the -e flag, which runs inside the main Electron context, inheriting any previously granted TCC entitlements (such as access to Documents, Downloads, etc.). This issue is fixed in version 2.20.0.

End of life: 3/10/2026, Latest version: 38.8.6

End of life: 1/13/2026, Latest version: 37.10.3

End of life: 10/28/2025, Latest version: 36.9.5

End of life: 9/2/2025, Latest version: 35.7.5

End of life: 6/24/2025, Latest version: 34.5.8

End of life: 4/29/2025, Latest version: 33.4.11

End of life: 4/29/2025, Latest version: 33.4.11

End of life: 1/14/2025, Latest version: 31.7.7

End of life: 1/14/2025, Latest version: 31.7.7

End of life: 3/4/2025, Latest version: 32.3.3

End of life: 3/4/2025, Latest version: 32.3.3

End of life: 10/15/2024, Latest version: 30.5.1