Summary
An Electron <webview> guest could enable Node.js integration in its Web Workers even when the unsandboxed embedder had disabled Node.js integration. Untrusted guest content may therefore create a Node-enabled worker with more privileges than the host application intended, particularly when the <webview> tag is enabled and the embedder is unsandboxed.
Affected context
The issue can arise in Electron applications that enable the <webview> tag and load guest content in an unsandboxed embedder. It depends on a mismatch between the privileges granted by the embedder and the capabilities available to guest-created Web Workers. Applications that do not enable <webview>, or that keep the embedder sandboxed, have a substantially different exposure profile.
Exploit preconditions
- Attack surface: Electron
<webview>guest content and its Web Workers - Required access: Ability to cause or control content loaded in an affected guest
- Trigger point: Creation or initialization of a Web Worker by the guest
- Relevant configuration: The
<webview>tag is enabled and the embedder is unsandboxed - Why exploitation is possible: Guest-controlled worker configuration can obtain Node.js integration despite the embedder having disabled that capability
Why this happens
The underlying flaw is an inconsistent enforcement of privilege boundaries between an Electron embedder, its <webview> guest, and guest-created Web Workers. A worker capability was made available based on guest-controlled behavior even though the embedder had not granted Node.js integration. This maps primarily to CWE-269: Improper Privilege Management, with CWE-1188: Insecure Default Initialization of Resource, because initialization behavior did not reliably preserve the intended security configuration.
Potential impact
- Untrusted guest content may gain Node.js capabilities that the embedder intended to deny
- Attackers could access privileged runtime functionality from a Web Worker
- Application confidentiality and integrity could be reduced
- Additional compromise may be possible depending on exposed Node.js APIs and application permissions
- The affected desktop application's local user context could be placed at greater risk
General mitigation guidance
Mitigation generally focuses on preserving privilege decisions across all guest and worker creation paths.
Common defensive patterns include:
- Keeping the Electron embedder sandboxed where application architecture permits
- Avoiding the
<webview>tag when a more isolated or narrowly scoped content model is sufficient - Treating guest content and worker scripts as untrusted by default
- Ensuring Node.js integration and related privileged capabilities remain disabled for untrusted content
- Enforcing consistent privilege inheritance between embedders, guests, frames, and workers
- Applying least privilege to exposed preload APIs and limiting filesystem, process, and IPC access
- Restricting guest navigation and content origins through explicit allowlists
- Testing security settings across worker creation, reload, navigation, and other lifecycle transitions
How teams detect issues like this
Organizations can look for this class of issue through:
- Static and configuration analysis of Electron applications that enable
<webview>or unsandboxed renderers - Code review checks for Node.js integration, worker creation, preload exposure, and guest navigation settings
- Tests that verify denied capabilities remain denied in Web Workers and nested guest contexts
- Runtime telemetry for unexpected worker access to Node.js, privileged IPC channels, filesystem APIs, or process APIs
- Policy enforcement requiring sandboxing and explicit origin controls for untrusted embedded content
- Automated security review tools that flag privilege-boundary inconsistencies and unsafe Electron configuration patterns
