Electron App RCE in Bug Bounty: Practical Hunting Paths

Electron App RCE in Bug Bounty: Practical Hunting Paths

Electron packs Chromium and Node into one desktop app. Misconfiguration turns a renderer XSS into host code execution. That jump is why programs pay well for Electron findings—and why you must test carefully on a disposable profile.

Baseline security settings

Unpack the app ascope allows (ASAR extract, installed resources tree). Search for BrowserWindow construction and webPreferences:

• nodeIntegration: true with contextIsolation: false is the historical jackpot
• contextIsolation: true with a fat preload that still bridges dangerous APIs
• sandbox: false where sandbox should be on
• webSecurity: false disabling same-origin checks
• Custom protocol handlers that map to local files

Also note Electron version. Old runtimes carry known Chromium CVEs; programs vary on whether outdated Electron alone is enough—prefer a chain to attacker-controlled code. Grep for enableRemoteModule leftovers and for <webview> tags with missing webpreferences restrictions.

From renderer to Node

If you find XSS in a renderer (often via displayed markdown, OAuth errors, or local HTML loaded from user content), check what the preload exposes on window. A single window.api.run(cmd) is enough. Call it with a harmless canary like writing a file under the user temp directory or opening calc only if the program permits that style of proof—many prefer a touch file.

IPC is the other highway. Trace ipcRenderer.invoke channels. If the main process takes a path or URL from the renderer and passes it to shell.openExternal, fs, or child_process without allowlists, you can escalate from UI control to RCE.

Open redirects into openExternal remain a favorite: help center links, SSO callbacks, or electron-open style routes. Prove with a custom URL scheme handler you register in the test OS user, or with a benign https URL that shows the call happened—then explain the scheme abuse.

Local content and loadURL

Loading file:// content or remote HTTPS with node hooks is risky. Try navigation to attacker-controlled HTML when the app accepts deep links. Deep link parsers that concatenate into HTML or into shell commands deserve the same attention as web open redirects. Autoupdate feeds are another angle when in scope: a poisoned update manifest is rare in bounty, but a client that trusts HTTP metadata is worth a sentence in recon notes.

Report hygiene

Capture app version, OS, and exact IPC channel names. Prefer a file-write canary over destructive payloads. If nodeIntegration is on for a login window, say so plainly—triage understands that sentence.

Fixes track Electron's security tutorial: enable context isolation, sandbox renderers, lock down preload bridges, allowlist openExternal, and keep Electron updated. Your job is to show one controlled path from untrusted input to main-process code. Stop there and write it clearly.

If the app embeds a remote web UI inside Electron, treat that origin like any other XSS target—but remember the preload bridge may still be listening after navigation.

For multi-window apps, confirm whether a less-trusted window can invoke IPC meant only for the main UI. Window-to-window trust bugs are easy to miss when you only test the login screen.