CVE-2026-70610: Context Isolation Bypass via Prototype Pollution in Electron contextBridge

Electron applications use Context Isolation as a primary security control to isolate privileged script execution environments from untrusted web contents. The contextBridge module serves as the primary secure channel that facilitates structured data transfer across this context boundary. Under normal operating conditions, this bridge creates proxies or clean copies of objects to prevent the renderer from accessing internal Node.js execution properties.\n\nThis vulnerability, tracked as CVE-2026-70610, is a prototype pollution flaw residing within this boundary-crossing serialization mechanism. If a preload script accepts custom object parameters from the untrusted main world, an attacker can manipulate the property transfer sequence to alter the prototype of objects created in the privileged script context.\n\nBy manipulating the prototype of these cloned structures, an attacker can bypass the context isolation boundary entirely. Under specific application-level configurations, this can lead to arbitrary code execution or privileges escalation within the context of the running desktop application.

The core of the issue lies in the C++ layer of Electron's renderer API, specifically within the CreateProxyForAPI function in shell/renderer/api/electron_api_context_bridge.cc. This function executes the serialization and deserialization of objects that traverse the bridge between isolated V8 contexts.\n\nTo copy an object across the boundary, the previous implementation traversed the source object properties and wrote them to a newly created target object using the standard v8::Object::Set function. In V8, invoking Set triggers standard ECMAScript [[Set]] semantics, which aligns with standard property assignment.\n\nBecause the target proxy object is initially empty, it inherits properties from Object.prototype, including the default proto accessor. When the parser attempts to copy a property named proto, the engine traverses the prototype chain, detects the accessor setter on Object.prototype, and executes it. This dynamic modification redirects the internal [[Prototype]] link of the target object to an attacker-controlled reference, establishing a prototype pollution state in the privileged context.

To resolve the vulnerability, the Electron development team updated the property assignment mechanism to bypass prototype setters. The following code block illustrates the exact modifications made in the C++ backend:\n\ncpp\n// Before Patch\n// proxy.Set(key, passed_value.ToLocalChecked());\n\n// After Patch\nv8::Local<v8::Value> proxied_value = passed_value.ToLocalChecked();\nif (key->IsName()) {\n // Bypasses prototype setter by defining property directly\n std::ignore = proxy.GetHandle()->CreateDataProperty(\n destination_context, key.As<v8::Name>(), proxied_value);\n} else {\n // Handles numeric keys directly\n std::ignore = proxy.GetHandle()->CreateDataProperty(\n destination_context, key.As<v8::Uint32>()->Value(),\n proxied_value);\n}\n\n\nBy swapping v8::Object::Set with v8::Object::CreateDataProperty, the engine transitions from [[Set]] semantics to [[DefineOwnProperty]] semantics. This prevents the V8 engine from traversing the prototype chain and invoking the inherited proto setter on Object.prototype.\n\nThe patch is highly complete because it restricts the assignment to the object's own direct properties. No variant attacks targeting alternative setter-based properties can trigger prototype mutations on the newly allocated proxy object, as the property definition operations are strictly non-recursive and localized.

Exploitation requires the application's preload script to expose an API through contextBridge that accepts object-type arguments from the untrusted renderer process. The attacker must execute JavaScript in the renderer context, which can occur via a Cross-Site Scripting vulnerability or by loading untrusted remote content.\n\nThe attacker defines an object with a custom proto property configured via Object.defineProperty to ensure it is enumerable. When passed through the bridge, the serialization logic copies this descriptor, invoking the setter on the destination side.\n\nOnce the prototype chain of the object in the privileged context is polluted, any subsequent property lookup on that object will fall back to the attacker-defined prototype. If the preload script relies on dynamic configurations, helper methods, or optional callbacks, the attacker can redirect control flow or execute malicious scripts inside the node context.\n\nmermaid\ngraph LR\n Renderer["Renderer (Untrusted)"] -- "Sends payload with custom __proto__" --> Bridge["contextBridge (C++ Binding)"]\n Bridge -- "Invokes standard [[Set]]" --> V8Engine["V8 Engine (Privileged Context)"]\n V8Engine -- "Triggers prototype setter" --> PollutedObject["Polluted Object in Preload"]\n PollutedObject -- "Unsafe Property Access" --> RCE["Execution / Privilege Escalation"]\n

The security implications of CVE-2026-70610 are severe for applications that expose flexible, object-based APIs to untrusted content. Although the CVSS score is rated as 5.4 due to the high attack complexity, the actual operational impact can reach arbitrary code execution on the underlying host operating system.\n\nBecause the preload script has access to Node.js APIs or high-privilege IPC channels, polluting objects within its context allows an attacker to manipulate parameters passed to functions like child_process.exec or fs.writeFile.\n\nThe vulnerability represents a direct breach of the primary security boundary in Electron. Since the scope is 'Changed', the vulnerability actively bridges the gap between sandboxed web content and the node execution environment, rendering standard sandbox protections ineffective if the API surface is poorly designed.

Immediate remediation requires upgrading the Electron dependency to a patched version. Developers must verify that their applications utilize Electron versions 39.8.9, 40.9.2, 41.2.2, or 42.0.0-beta.4 depending on their current release line.\n\nFor legacy applications where runtime upgrades are blocked by compatibility constraints, developers should implement application-level filtering. Preload APIs must be modified to accept flat structures or primitive values rather than raw nested objects.\n\nAdditionally, all preload scripts should adopt defensive coding practices. Rather than performing direct property lookups on client-controlled objects, developers should utilize Object.prototype.hasOwnProperty.call() or sanitize objects by recreating them with a null prototype before executing downstream logic.