ESB-2018.1469 - [Win][UNIX/Linux] Electron: Execute arbitrary code/commands - Remote with user interaction 2018-05-14

Printable version
PGP/GPG verifiable version

Hash: SHA256

             AUSCERT External Security Bulletin Redistribution

                 Security vulnerability found in Electron
                                14 May 2018


        AusCERT Security Bulletin Summary

Product:           Electron
Publisher:         Electron
Operating System:  Windows
                   UNIX variants (UNIX, Linux, OSX)
Impact/Access:     Execute Arbitrary Code/Commands -- Remote with User Interaction
Resolution:        Patch/Upgrade
CVE Names:         CVE-2018-1000136  

Original Bulletin:

Comment: AusCERT notes that not all applications built with vulnerable versions
         of Electron are affected. For instance, the Slack application is

- --------------------------BEGIN INCLUDED TEXT--------------------

CVE-2018-1000136 - Electron nodeIntegration Bypass
Posted By Brendan Scarvell
A few weeks ago, I came across a vulnerability that affected all current ver=
sions of Electron at the time (< 1.7.13, < 1.8.4, and < 2.0.0-beta.3). The v=
ulnerability allowed nodeIntegration to be re-enabled, leading to the potent=
ial for remote code execution. If you're unfamiliar with Electron, it is a p=
opular framework that allows you to create cross-platform desktop applicatio=
ns using HTML, CSS, and JavaScript. Some popular applications such as Slack,=
 Discord, Signal, Atom, Visual Studio Code, and Github Desktop are all built=
 using the Electron framework. You can find a list of applications built wit=
h Electron here.

Electron applications are essentially web apps, which means they're suscepti=
ble to cross-site scripting attacks through failure to correctly sanitize us=
er-supplied input. A default Electron application includes access to not onl=
y its own APIs, but also includes access to all of Node.js' built in modules=
. This makes XSS particularly dangerous, as an attacker's payload can allow d=
o some nasty things such as require in the child_process module and execute s=
ystem commands on the client-side. Atom had an XSS vulnerability not too lon=
g ago which did exactly that. You can remove access to Node.js by passing no=
deIntegration: false into your application's webPreferences.

There's also a WebView tag feature which allows you to embed content, such a=
s web pages, into your Electron application and run it as a separate process=
. When using a WebView tag you are also able to pass in a number of attribut=
es, including nodeIntegration. WebView containers do not have nodeIntegratio=
n enabled by default. The documentation states that if the webviewTag option=
 is not explicitly declared in your webPreferences, it will inherit the same=
 permissions of whatever the value of nodeIntegration is set to.

By default, Electron also uses its own custom function which c=
reates a new instance of a BrowserWindow. The child window will inherit all o=
f the parent window's options (which includes its webPreferences) by default=
. The custom function does allow you to override some of the i=
nherited options by passing in a featuresargument:

if (!usesNativeWindowOpen) {
    // Make the browser window or guest view emit "new-window" event. =3D function (url, frameName, features) {
      if (url !=3D null && url !=3D=3D '') {
        url =3D resolveURL(url)
      const guestId =3D ipcRenderer.sendSync('ELECTRON_GUEST_WINDOW_MANAGER_=
WINDOW_OPEN', url, toString(frameName), toString(features))
      if (guestId !=3D null) {
        return getOrCreateProxy(ipcRenderer, guestId)
      } else {
        return null

  if (openerId !=3D null) {
    window.opener =3D getOrCreateProxy(ipcRenderer, openerId)
When Electron's custom function is called, it emits an ELECTRON_=
DOW_OPENevent handler then parses the features provided, adding them as opti=
ons to the newly created window and then emits an ELECTRON_GUEST_WINDOW_MANA=
GER_INTERNAL_WINDOW_OPENevent. To prevent child windows from being able to d=
o nasty things like re-enabling nodeIntegration when the parent window has i=
t explicitly disabled, guest-window-manager.js contains a hardcoded list of w=
ebPreferences options and their restrictive values:

// Security options that child windows will always inherit from parent windo=
const inheritedWebPreferences =3D new Map([
 ['contextIsolation', true],
 ['javascript', false],
 ['nativeWindowOpen', true],
 ['nodeIntegration', false],
 ['sandbox', true],
 ['webviewTag', false]
lls the mergeBrowserWindowOptionsfunction which ensures that the restricted a=
ttributes of the parent window's webPreferences are applied to the child win=

  const mergeBrowserWindowOptions =3D function (embedder, options) {


    // Inherit certain option values from parent window
    for (const [name, value] of inheritedWebPreferences) {
      if (embedder.getWebPreferences()[name] =3D=3D=3D value) {
        options.webPreferences[name] =3D value

    // Sets correct openerId here to give correct options to 'new-window' ev=
ent handler
    options.webPreferences.openerId =3D

    return options
And here is where the vulnerability lays. The mergeBrowserWindowOptions func=
tion didn't take into account what the default values of these restricted at=
tributes should be if they were undefined. In other words, if webviewTag: fa=
lsewasn't explicitly declared in your application's webPreferences (and was t=
herefore being inferred by explicitly setting nodeIntegration: false), when m=
ergeBrowserWindowOptions went to check the webviewTag, it would then come ba=
ck undefined thus making the above if statement return false and not apply t=
he parent's webviewTag preference. This allowed to pass the webv=
iewTag option as an additional feature, re-enabling nodeIntegration and allo=
wing the potential for remote code execution.

The following proof-of-concept shows how an XSS payload can re-enable nodeIn=
tegration during run time and allow execution of system commands:

var x =3D'data://yoloswag','','webviewTag=3Dyes,show=3Dno');
  "var webview =3D new WebView;"+
  "webview.setAttribute('webpreferences', 'webSecurity=3Dno, nodeIntegration=
  "webview.src =3D `data:text/html;base64,PHNjcmlwdD5yZXF1aXJlKCdjaGlsZF9wcm=
If you find an Electron application with the nodeIntegration option disabled=
 and it contains either an XSS vulnerability through poor sanitization of us=
er input or a vulnerability in another dependency of the application, the ab=
ove proof-of-concept can allow for remote code execution provided that the a=
pplication is using a vulnerable version of Electron (version < 1.7.13, < 1.=
8.4, or < 2.0.0-beta.3) , and hasn't manually opted into one of the followin=

Declared webviewTag: false in its webPreferences.
Enabled the nativeWindowOption option in its webPreferences.
Intercepting new-window events and overriding event.newGuest without using t=
he supplied options tag.
We'd also like to thank the Electron team for being extremely responsive and=
 for quickly providing a patch to the public.

This vulnerability was assigned the CVE identifier CVE-2018-1000136.

- --------------------------END INCLUDED TEXT--------------------

You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to
and we will forward your request to the appropriate person.

NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members.  As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.

NOTE: This is only the original release of the security bulletin.  It may
not be updated when updates to the original are made.  If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above.  If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:

Australian Computer Emergency Response Team
The University of Queensland
Qld 4072

Internet Email:
Facsimile:      (07) 3365 7031
Telephone:      (07) 3365 4417 (International: +61 7 3365 4417)
                AusCERT personnel answer during Queensland business hours
                which are GMT+10:00 (AEST).
                On call after hours for member emergencies only.


« Back to bulletins