All the vulnerabilities related to the version 1.1.0 of the package
Denial of Service in js-yaml
Versions of js-yaml prior to 3.13.0 are vulnerable to Denial of Service. By parsing a carefully-crafted YAML file, the node process stalls and may exhaust system resources leading to a Denial of Service.
Upgrade to version 3.13.0.
Code Injection in js-yaml
Versions of js-yaml prior to 3.13.1 are vulnerable to Code Injection. The load() function may execute arbitrary code injected through a malicious YAML file. Objects that have toString as key, JavaScript code as value and are used as explicit mapping keys allow attackers to execute the supplied code through the load() function. The safeLoad() function is unaffected.
An example payload is
{ toString: !<tag:yaml.org,2002:js/function> 'function (){return Date.now()}' } : 1
which returns the object
{
"1553107949161": 1
}
Upgrade to version 3.13.1.
js-yaml has prototype pollution in merge (<<)
In js-yaml 4.1.0, 4.0.0, and 3.14.1 and below, it's possible for an attacker to modify the prototype of the result of a parsed yaml document via prototype pollution (__proto__). All users who parse untrusted yaml documents may be impacted.
Problem is patched in js-yaml 4.1.1 and 3.14.2.
You can protect against this kind of attack on the server by using node --disable-proto=delete or deno (in Deno, pollution protection is on by default).
https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html
Prototype Pollution in minimist
Affected versions of minimist are vulnerable to prototype pollution. Arguments are not properly sanitized, allowing an attacker to modify the prototype of Object, causing the addition or modification of an existing property that will exist on all objects.
Parsing the argument --__proto__.y=Polluted adds a y property with value Polluted to all objects. The argument --__proto__=Polluted raises and uncaught error and crashes the application.
This is exploitable if attackers have control over the arguments being passed to minimist.
Upgrade to versions 0.2.1, 1.2.3 or later.
Prototype Pollution in minimist
Minimist prior to 1.2.6 and 0.2.4 is vulnerable to Prototype Pollution via file index.js, function setKey() (lines 69-95).
Server-Side Request Forgery in Request
The request package through 2.88.2 for Node.js and the @cypress/request package prior to 3.0.0 allow a bypass of SSRF mitigations via an attacker-controller server that does a cross-protocol redirect (HTTP to HTTPS, or HTTPS to HTTP).
NOTE: The request package is no longer supported by the maintainer.
Uncontrolled Resource Consumption in Hawk
Hawk is an HTTP authentication scheme providing mechanisms for making authenticated HTTP requests with partial cryptographic verification of the request and response, covering the HTTP method, request URI, host, and optionally the request payload. Hawk used a regular expression to parse Host HTTP header (Hawk.utils.parseHost()), which was subject to regular expression DoS attack - meaning each added character in the attacker's input increases the computation time exponentially. parseHost() was patched in 9.0.1 to use built-in URL class to parse hostname instead.Hawk.authenticate() accepts options argument. If that contains host and port, those would be used instead of a call to utils.parseHost().
hoek subject to prototype pollution via the clone function.
hoek versions prior to 8.5.1, and 9.x prior to 9.0.3 are vulnerable to prototype pollution in the clone function. If an object with the proto key is passed to clone() the key is converted to a prototype. This issue has been patched in version 9.0.3, and backported to 8.5.1.
Prototype Pollution in hoek
Versions of hoek prior to 4.2.1 and 5.0.3 are vulnerable to prototype pollution.
The merge function, and the applyToDefaults and applyToDefaultsWithShallow functions which leverage merge behind the scenes, are vulnerable to a prototype pollution attack when provided an unvalidated payload created from a JSON string containing the __proto__ property.
This can be demonstrated like so:
var Hoek = require('hoek');
var malicious_payload = '{"__proto__":{"oops":"It works !"}}';
var a = {};
console.log("Before : " + a.oops);
Hoek.merge({}, JSON.parse(malicious_payload));
console.log("After : " + a.oops);
This type of attack can be used to overwrite existing properties causing a potential denial of service.
Update to version 4.2.1, 5.0.3 or later.
form-data uses unsafe random function in form-data for choosing boundary
form-data uses Math.random() to select a boundary value for multipart form-encoded data. This can lead to a security issue if an attacker:
Because the values of Math.random() are pseudo-random and predictable (see: https://blog.securityevaluators.com/hacking-the-javascript-lottery-80cc437e3b7f), an attacker who can observe a few sequential values can determine the state of the PRNG and predict future values, includes those used to generate form-data's boundary value. The allows the attacker to craft a value that contains a boundary value, allowing them to inject additional parameters into the request.
This is largely the same vulnerability as was recently found in undici by parrot409 -- I'm not affiliated with that researcher but want to give credit where credit is due! My PoC is largely based on their work.
The culprit is this line here: https://github.com/form-data/form-data/blob/426ba9ac440f95d1998dac9a5cd8d738043b048f/lib/form_data.js#L347
An attacker who is able to predict the output of Math.random() can predict this boundary value, and craft a payload that contains the boundary value, followed by another, fully attacker-controlled field. This is roughly equivalent to any sort of improper escaping vulnerability, with the caveat that the attacker must find a way to observe other Math.random() values generated by the application to solve for the state of the PRNG. However, Math.random() is used in all sorts of places that might be visible to an attacker (including by form-data itself, if the attacker can arrange for the vulnerable application to make a request to an attacker-controlled server using form-data, such as a user-controlled webhook -- the attacker could observe the boundary values from those requests to observe the Math.random() outputs). A common example would be a x-request-id header added by the server. These sorts of headers are often used for distributed tracing, to correlate errors across the frontend and backend. Math.random() is a fine place to get these sorts of IDs (in fact, opentelemetry uses Math.random for this purpose)
PoC here: https://github.com/benweissmann/CVE-2025-7783-poc
Instructions are in that repo. It's based on the PoC from https://hackerone.com/reports/2913312 but simplified somewhat; the vulnerable application has a more direct side-channel from which to observe Math.random() values (a separate endpoint that happens to include a randomly-generated request ID).
For an application to be vulnerable, it must:
form-data to send data including user-controlled data to some other system. The attacker must be able to do something malicious by adding extra parameters (that were not intended to be user-controlled) to this request. Depending on the target system's handling of repeated parameters, the attacker might be able to overwrite values in addition to appending values (some multipart form handlers deal with repeats by overwriting values instead of representing them as an array)If an application is vulnerable, this allows an attacker to make arbitrary requests to internal systems.
tough-cookie Prototype Pollution vulnerability
Versions of the package tough-cookie before 4.1.3 are vulnerable to Prototype Pollution due to improper handling of Cookies when using CookieJar in rejectPublicSuffixes=false mode. This issue arises from the manner in which the objects are initialized.
Memory Exposure in tunnel-agent
Versions of tunnel-agent before 0.6.0 are vulnerable to memory exposure.
This is exploitable if user supplied input is provided to the auth value and is a number.
Proof-of-concept:
require('request')({
method: 'GET',
uri: 'http://www.example.com',
tunnel: true,
proxy:{
protocol: 'http:',
host:'127.0.0.1',
port:8080,
auth:USERSUPPLIEDINPUT // number
}
});
Update to version 0.6.0 or later.
Renderers can obtain access to random bluetooth device without permission in Electron
This vulnerability allows renderers to obtain access to a random bluetooth device via the web bluetooth API if the app has not configured a custom select-bluetooth-device event handler. The device that is accessed is random and the attacker would have no way of selecting a specific device.
All current stable versions of Electron are affected.
This has been patched and the following Electron versions contain the fix:
17.0.0-alpha.616.0.615.3.514.2.413.6.6Adding this code to your app can workaround the issue.
app.on('web-contents-created', (event, webContents) => {
webContents.on('select-bluetooth-device', (event, devices, callback) => {
// Prevent default behavior
event.preventDefault();
// Cancel the request
callback('');
});
});
For more information If you have any questions or comments about this advisory, email us at security@electronjs.org.
Chromium Remote Code Execution in electron
Affected versions of ElectronJS are susceptible to a remote code execution vulnerability that occurs when an affected application access remote content, even if the sandbox option is enabled.
Update to electron version 1.7.8 or later.
Electron vulnerable to Heap Buffer Overflow in NativeImage
The nativeImage.createFromPath() and nativeImage.createFromBuffer() functions call a function downstream that is vulnerable to a heap buffer overflow. An Electron program that uses either of the affected functions is vulnerable to a buffer overflow if an attacker is in control of the image's height, width, and contents.
There are no app-side workarounds for this issue. You must update your Electron version to be protected.
v28.3.2v29.3.3v30.0.3If you have any questions or comments about this advisory, email us at security@electronjs.org.
Context isolation bypass via Promise in Electron
Apps using contextIsolation are affected.
This is a context isolation bypass, meaning that code running in the main world context in the renderer can reach into the isolated Electron context and perform privileged actions.
There are no app-side workarounds, you must update your Electron version to be protected.
9.0.0-beta.218.2.47.2.46.1.11If you have any questions or comments about this advisory:
AutoUpdater module fails to validate certain nested components of the bundle
This vulnerability allows attackers who have control over a given apps update server / update storage to serve maliciously crafted update packages that pass the code signing validation check but contain malicious code in some components.
Please note that this kind of attack would require significant privileges in your own auto updating infrastructure and the ease of that attack entirely depends on your infrastructure security.
This has been patched and the following Electron versions contain the fix:
18.0.0-beta.617.2.016.2.015.5.0There are no workarounds for this issue, please update to a patched version of Electron.
If you have any questions or comments about this advisory, email us at security@electronjs.org
Electron vulnerable to remote command execution
Electron before 1.6.8 allows remote command execution because of a nodeIntegration bypass vulnerability. This also affects all applications that bundle Electron code equivalent to 1.6.8 or earlier. Bypassing the Same Origin Policy (SOP) is a precondition; however, recent Electron versions do not have strict SOP enforcement. Combining an SOP bypass with a privileged URL internally used by Electron, it was possible to execute native Node.js primitives in order to run OS commands on the user's host. Specifically, a chrome-devtools://devtools/bundled/inspector.html window could be used to eval a Node.js child_process.execFile API call.
ASAR Integrity bypass via filetype confusion in electron
This only impacts apps that have the embeddedAsarIntegrityValidation and onlyLoadAppFromAsar fuses enabled. Apps without these fuses enabled are not impacted. This issue is specific to macOS as these fuses are only currently supported on macOS.
Specifically this issue can only be exploited if your app is launched from a filesystem the attacker has write access too. i.e. the ability to edit files inside the resources folder in your app installation on Windows which these fuses are supposed to protect against.
There are no app side workarounds, you must update to a patched version of Electron.
27.0.0-alpha.726.2.125.8.124.8.322.3.24If you have any questions or comments about this advisory, email us at security@electronjs.org
Electron vulnerable to out-of-package code execution when launched with arbitrary cwd
Apps that are launched as command line executables are impacted. E.g. if your app exposes itself in the path as myapp --help
Specifically this issue can only be exploited if the following conditions are met:
This makes the risk quite low, in fact normally issues of this kind are considered outside of our threat model as similar to Chromium we exclude Physically Local Attacks but given the ability for this issue to bypass certain protections like ASAR Integrity it is being treated with higher importance. Please bear this in mind when reporting similar issues in the future.
There are no app side workarounds, you must update to a patched version of Electron.
26.0.0-beta.1325.5.024.7.123.3.1322.3.19If you have any questions or comments about this advisory, email us at security@electronjs.org
Arbitrary file read via window-open IPC in Electron
The vulnerability allows arbitrary local file read by defining unsafe window options on a child window opened via window.open.
Ensure you are calling event.preventDefault() on all new-window events where the url or options is not something you expect.
9.0.0-beta.218.2.47.2.4If you have any questions or comments about this advisory:
Electron protocol handler browser vulnerable to Command Injection
Github Electron version Electron 1.8.2-beta.4 and earlier contains a Command Injection vulnerability in Protocol Handler that can result in command execute. This attack appear to be exploitable via the victim opening an electron protocol handler in their browser. This vulnerability appears to have been fixed in Electron 1.8.2-beta.5. This issue is due to an incomplete fix for CVE-2018-1000006, specifically the black list used was not case insensitive allowing an attacker to potentially bypass it.
High severity vulnerability that affects electron
Untrusted search path vulnerability in Atom Electron before 0.33.5 allows local users to gain privileges via a Trojan horse Node.js module in a parent directory of a directory named on a require line.
Context isolation bypass via contextBridge in Electron
Apps using both contextIsolation and contextBridge are affected.
This is a context isolation bypass, meaning that code running in the main world context in the renderer can reach into the isolated Electron context and perform privileged actions.
There are no app-side workarounds, you must update your Electron version to be protected.
9.0.0-beta.218.2.47.2.4If you have any questions or comments about this advisory:
IPC messages delivered to the wrong frame in Electron
IPC messages sent from the main process to a subframe in the renderer process, through webContents.sendToFrame, event.reply or when using the remote module, can in some cases be delivered to the wrong frame.
If your app does ANY of the following, then it is impacted by this issue:
remotewebContents.sendToFrameevent.reply in an IPC message handlerThis has been fixed in the following versions:
There are no workarounds for this issue.
If you have any questions or comments about this advisory, email us at security@electronjs.org.
Context isolation bypass via leaked cross-context objects in Electron
Apps using contextIsolation are affected.
This is a context isolation bypass, meaning that code running in the main world context in the renderer can reach into the isolated Electron context and perform privileged actions.
There are no app-side workarounds, you must update your Electron version to be protected.
9.0.0-beta.218.2.47.2.49.0.0-beta.*If you have any questions or comments about this advisory:
Electron's sandboxed renderers can obtain thumbnails of arbitrary files through the nativeImage API
This vulnerability allows a sandboxed renderer to request a "thumbnail" image of an arbitrary file on the user's system. The thumbnail can potentially include significant parts of the original file, including textual data in many cases.
All current stable versions of Electron are affected.
This was fixed with #30728, and the following Electron versions contain the fix:
If your app enables contextIsolation, this vulnerability is significantly more difficult for an attacker to exploit.
Further, if your app does not depend on the createThumbnailFromPath API, then you can simply disable the functionality. In the main process, before the 'ready' event:
delete require('electron').nativeImage.createThumbnailFromPath
If you have any questions or comments about this advisory, email us at security@electronjs.org.
Compromised child renderer processes could obtain IPC access without nodeIntegrationInSubFrames being enabled
This vulnerability allows a renderer with JS execution to obtain access to a new renderer process with nodeIntegrationInSubFrames enabled which in turn allows effective access to ipcRenderer.
Please note the misleadingly named nodeIntegrationInSubFrames option does not implicitly grant Node.js access rather it depends on the existing sandbox setting. If your application is sandboxed then nodeIntegrationInSubFrames just gives access to the sandboxed renderer APIs (which includes ipcRenderer).
If your application then additionally exposes IPC messages without IPC senderFrame validation that perform privileged actions or return confidential data this access to ipcRenderer can in turn compromise your application / user even with the sandbox enabled.
This has been patched and the following Electron versions contain the fix:
18.0.0-beta.617.2.016.2.615.5.5Ensure that all IPC message handlers appropriately validate senderFrame as per our security tutorial here.
If you have any questions or comments about this advisory, email us at security@electronjs.org.
Exfiltration of hashed SMB credentials on Windows via file:// redirect
When following a redirect, Electron delays a check for redirecting to file:// URLs from other schemes. The contents of the file is not available to the renderer following the redirect, but if the redirect target is a SMB URL such as file://some.website.com/, then in some cases, Windows will connect to that server and attempt NTLM authentication, which can include sending hashed credentials.
This issue has been fixed in all current stable versions of Electron. Specifically, these versions contain the fixes:
We recommend all apps upgrade to the latest stable version of Electron.
If upgrading isn't possible, this issue can be addressed without upgrading by preventing redirects to file:// URLs in the WebContents.on('will-redirect') event, for all WebContents:
app.on('web-contents-created', (e, webContents) => {
webContents.on('will-redirect', (e, url) => {
if (/^file:/.test(url)) e.preventDefault()
})
})
If you have any questions or comments about this advisory, email us at security@electronjs.org.
Thanks to user @coolcoolnoworries for reporting this issue.
Electron context isolation bypass via nested unserializable return value
Apps using contextIsolation and contextBridge are affected.
This is a context isolation bypass, meaning that code running in the main world context in the renderer can reach into the isolated Electron context and perform privileged actions.
This issue is exploitable under either of two conditions:
contextBridge can return an object or array that contains a JS object which cannot be serialized, for instance, a canvas rendering context. This would normally result in an exception being thrown Error: object could not be cloned.contextBridge has a return value that throws a user-generated exception while being sent over the bridge, for instance a dynamic getter property on an object that throws an error when being computed.The app side workaround is to ensure that such a case is not possible. Ensure all values returned from a function exposed over the context bridge are supported and that any objects returned from functions do not have dynamic getters that can throw exceptions.
Auditing your exposed API is likely to be quite difficult so we strongly recommend you update to a patched version of Electron.
25.0.0-alpha.224.0.123.2.322.3.6If you have any questions or comments about this advisory, email us at security@electronjs.org
Electron affected by libvpx's heap buffer overflow in vp8 encoding
Heap buffer overflow in vp8 encoding in libvpx in Google Chrome prior to 117.0.5938.132 and libvpx 1.13.1 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
Electron has ASAR Integrity Bypass via resource modification
This only impacts apps that have the embeddedAsarIntegrityValidation and onlyLoadAppFromAsar fuses enabled. Apps without these fuses enabled are not impacted.
Specifically this issue can only be exploited if your app is launched from a filesystem the attacker has write access too. i.e. the ability to edit files inside the resources folder in your app installation on Windows which these fuses are supposed to protect against.
There are no app side workarounds, you must update to a patched version of Electron.
38.0.0-beta.637.3.136.8.135.7.5If you have any questions or comments about this advisory, email us at security@electronjs.org