Version Details and Security Vulnerabilities

The package underscore from 1.13.0-0 and before 1.13.0-2, from 1.3.2 and before 1.12.1 are vulnerable to Arbitrary Code Execution via the template function, particularly when a variable property is passed as an argument as it is not sanitized.

Versions of underscore.string prior to 3.3.5 are vulnerable to Regular Expression Denial of Service (ReDoS).

The function unescapeHTML is vulnerable to ReDoS due to an overly-broad regex. The slowdown is approximately 2s for 50,000 characters but grows exponentially with larger inputs.

Recommendation

Upgrade to version 3.3.5 or higher.

Affected versions of minimatch are vulnerable to regular expression denial of service attacks when user input is passed into the pattern argument of minimatch(path, pattern).

Proof of Concept

var minimatch = require(“minimatch”);

// utility function for generating long strings
var genstr = function (len, chr) {
  var result = “”;
  for (i=0; i<=len; i++) {
    result = result + chr;
  }
  return result;
}

var exploit = “[!” + genstr(1000000, “\\”) + “A”;

// minimatch exploit.
console.log(“starting minimatch”);
minimatch(“foo”, exploit);
console.log(“finishing minimatch”);

Recommendation

Update to version 3.0.2 or later.

A vulnerability was found in the minimatch package. This flaw allows a Regular Expression Denial of Service (ReDoS) when calling the braceExpand function with specific arguments, resulting in a Denial of Service.

Versions of uglify-js prior to 2.4.24 are affected by a vulnerability which may cause crafted JavaScript to have altered functionality after minification.

Recommendation

Upgrade UglifyJS to version >= 2.4.24.

Versions of uglify-js prior to 2.6.0 are affected by a regular expression denial of service vulnerability when malicious inputs are passed into the parse() method.

Proof of Concept

var u = require('uglify-js');
var genstr = function (len, chr) {
    var result = "";
    for (i=0; i<=len; i++) {
        result = result + chr;
    }

    return result;
}

u.parse("var a = " + genstr(process.argv[2], "1") + ".1ee7;");

Results

$ time node test.js 10000
real	0m1.091s
user	0m1.047s
sys	0m0.039s

$ time node test.js 80000
real	0m6.486s
user	0m6.229s
sys	0m0.094s

Recommendation

Update to version 2.6.0 or later.

Versions 0.3.0 and earlier of marked are affected by two cross-site scripting vulnerabilities, even when sanitize: true is set.

The attack vectors for this vulnerability are GFM Codeblocks and JavaScript URLs.

Recommendation

Upgrade to version 0.3.1 or later.

Versions 0.3.2 and earlier of marked are affected by a cross-site scripting vulnerability even when sanitize:true is set.

Proof of Concept ( IE10 Compatibility Mode Only )

[xss link](vbscript:alert(1))

will get a link

<a href="vbscript:alert(1)">xss link</a>

Recommendation

Update to version 0.3.3 or later.

Versions 0.3.3 and earlier of marked are affected by a regular expression denial of service ( ReDoS ) vulnerability when passed inputs that reach the em inline rule.

Recommendation

Update to version 0.3.4 or later.

Affected versions of marked are susceptible to a cross-site scripting vulnerability in link components when sanitize:true is configured.

Proof of Concept

This flaw exists because link URIs containing HTML entities get processed in an abnormal manner. Any HTML Entities get parsed on a best-effort basis and included in the resulting link, while if that parsing fails that character is omitted.

For example:

A link URI such as

javascript&#x58document;alert(1)

Renders a valid link that when clicked will execute alert(1).

Recommendation

Update to version 0.3.6 or later.

marked version 0.3.6 and earlier is vulnerable to an XSS attack in the data: URI parser.

Affected versions of marked are vulnerable to a regular expression denial of service.

The amplification in this vulnerability is significant, with 1,000 characters resulting in the event loop being blocked for around 6 seconds.

Recommendation

Update to version 0.3.9 or later.

Marked prior to version 0.3.17 is vulnerable to a Regular Expression Denial of Service (ReDoS) attack due to catastrophic backtracking in several regular expressions used for parsing HTML tags and markdown links. An attacker can exploit this vulnerability by providing specially crafted markdown input, such as deeply nested or repetitively structured brackets or tag attributes, which cause the parser to hang and lead to a Denial of Service.

Impact

What kind of vulnerability is it?

Denial of service.

The regular expression inline.reflinkSearch may cause catastrophic backtracking against some strings. PoC is the following.

import * as marked from 'marked';

console.log(marked.parse(`[x]: x

\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](`));

Who is impacted?

Anyone who runs untrusted markdown through marked and does not use a worker with a time limit.

Patches

Has the problem been patched?

Yes

What versions should users upgrade to?

4.0.10

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

Do not run untrusted markdown through marked or run marked on a worker thread and set a reasonable time limit to prevent draining resources.

References

Are there any links users can visit to find out more?

• https://marked.js.org/using_advanced#workers
• https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS

For more information

If you have any questions or comments about this advisory:

• Open an issue in marked

Impact

What kind of vulnerability is it?

Denial of service.

The regular expression block.def may cause catastrophic backtracking against some strings. PoC is the following.

import * as marked from "marked";

marked.parse(`[x]:${' '.repeat(1500)}x ${' '.repeat(1500)} x`);

Who is impacted?

Anyone who runs untrusted markdown through marked and does not use a worker with a time limit.

Patches

Has the problem been patched?

Yes

What versions should users upgrade to?

4.0.10

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

Do not run untrusted markdown through marked or run marked on a worker thread and set a reasonable time limit to prevent draining resources.

References

Are there any links users can visit to find out more?

• https://marked.js.org/using_advanced#workers
• https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS

For more information

If you have any questions or comments about this advisory:

• Open an issue in marked

Versions of lodash before 4.17.12 are vulnerable to Prototype Pollution. The function defaultsDeep allows a malicious user to modify the prototype of Object via {constructor: {prototype: {...}}} causing the addition or modification of an existing property that will exist on all objects.

Recommendation

Update to version 4.17.12 or later.

Versions of lodash before 4.17.5 are vulnerable to prototype pollution.

The vulnerable functions are 'defaultsDeep', 'merge', and 'mergeWith' which allow a malicious user to modify the prototype of Object via __proto__ causing the addition or modification of an existing property that will exist on all objects.

Recommendation

Update to version 4.17.5 or later.

Versions of lodash before 4.17.11 are vulnerable to prototype pollution.

The vulnerable functions are 'defaultsDeep', 'merge', and 'mergeWith' which allow a malicious user to modify the prototype of Object via {constructor: {prototype: {...}}} causing the addition or modification of an existing property that will exist on all objects.

Recommendation

Update to version 4.17.11 or later.

lodash prior to 4.7.11 is affected by: CWE-400: Uncontrolled Resource Consumption. The impact is: Denial of service. The component is: Date handler. The attack vector is: Attacker provides very long strings, which the library attempts to match using a regular expression. The fixed version is: 4.7.11.

All versions of package lodash prior to 4.17.21 are vulnerable to Regular Expression Denial of Service (ReDoS) via the toNumber, trim and trimEnd functions.

Steps to reproduce (provided by reporter Liyuan Chen):

var lo = require('lodash');

function build_blank(n) {
    var ret = "1"
    for (var i = 0; i < n; i++) {
        ret += " "
    }
    return ret + "1";
}
var s = build_blank(50000) var time0 = Date.now();
lo.trim(s) 
var time_cost0 = Date.now() - time0;
console.log("time_cost0: " + time_cost0);
var time1 = Date.now();
lo.toNumber(s) var time_cost1 = Date.now() - time1;
console.log("time_cost1: " + time_cost1);
var time2 = Date.now();
lo.trimEnd(s);
var time_cost2 = Date.now() - time2;
console.log("time_cost2: " + time_cost2);

lodash versions prior to 4.17.21 are vulnerable to Command Injection via the template function.

Impact

Affected versions of this package are vulnerable to Prototype Pollution. A malicious HTML code block can be crafted that will result in prototype pollution of the base object's prototype during highlighting. If you allow users to insert custom HTML code blocks into your page/app via parsing Markdown code blocks (or similar) and do not filter the language names the user can provide you may be vulnerable.

The pollution should just be harmless data but this can cause problems for applications not expecting these properties to exist and can result in strange behavior or application crashes, i.e. a potential DOS vector.

If your website or application does not render user provided data it should be unaffected.

Patches

Versions 9.18.2 and 10.1.2 and newer include fixes for this vulnerability. If you are using version 7 or 8 you are encouraged to upgrade to a newer release.

Workarounds

Patch your library

Manually patch your library to create null objects for both languages and aliases:

const HLJS = function(hljs) {
  // ...
  var languages = Object.create(null);
  var aliases = Object.create(null);

Filter out bad data from end users:

Filter the language names that users are allowed to inject into your HTML to guarantee they are valid.

References

• What is Prototype Pollution?
• https://github.com/highlightjs/highlight.js/pull/2636

For more information

If you have any questions or comments about this advisory:

• Please file an issue against highlight.js

Affected versions of mime are vulnerable to regular expression denial of service when a mime lookup is performed on untrusted user input.

Recommendation

Update to version 2.0.3 or later.

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.

Summary

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:

1. can observe other values produced by Math.random in the target application, and
2. can control one field of a request made using form-data

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.

Details

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

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).

Impact

For an application to be vulnerable, it must:

• Use 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)
• Reveal values of Math.random(). It's easiest if the attacker can observe multiple sequential values, but more complex math could recover the PRNG state to some degree of confidence with non-sequential values.

If an application is vulnerable, this allows an attacker to make arbitrary requests to internal systems.

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.