All the vulnerabilities related to the version 1.12.1 of the package
Inefficient Regular Expression Complexity in nth-check
There is a Regular Expression Denial of Service (ReDoS) vulnerability in nth-check that causes a denial of service when parsing crafted invalid CSS nth-checks.
The ReDoS vulnerabilities of the regex are mainly due to the sub-pattern \s*(?:([+-]?)\s*(\d+))? with quantified overlapping adjacency and can be exploited with the following code.
Proof of Concept
// PoC.js
var nthCheck = require("nth-check")
for(var i = 1; i <= 50000; i++) {
var time = Date.now();
var attack_str = '2n' + ' '.repeat(i*10000)+"!";
try {
nthCheck.parse(attack_str)
}
catch(err) {
var time_cost = Date.now() - time;
console.log("attack_str.length: " + attack_str.length + ": " + time_cost+" ms")
}
}
The Output
attack_str.length: 10003: 174 ms
attack_str.length: 20003: 1427 ms
attack_str.length: 30003: 2602 ms
attack_str.length: 40003: 4378 ms
attack_str.length: 50003: 7473 ms
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.
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.
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.
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.
Prototype Pollution in node-forge
The package node-forge before 0.10.0 is vulnerable to Prototype Pollution via the util.setPath function. Note: version 0.10.0 is a breaking change removing the vulnerable functions.
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:
Prototype Pollution in node-forge util.setPath API
forge.util.setPath had a potential prototype pollution issue if called with untrusted keys. This API was not used by forge itself.
The forge.util.setPath API and related functions were removed in 0.10.0.
Don't call forge.util.setPath directly or indirectly with untrusted keys.
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:
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.
Cross-Site Scripting in serialize-to-js
Versions of serialize-to-js prior to 3.0.1 are vulnerable to Cross-Site Scripting (XSS). The package fails to sanitize serialized regular expressions. This vulnerability does not affect Node.js applications.
Upgrade to version 3.0.1 or later.
Denial of Service in serialize-to-js
Versions of serialize-to-js prior to 2.0.0 are vulnerable to Denial of Service. User input is not properly validated, allowing attackers to provide inputs that lead the execution to loop indefinitely.
Upgrade to version 2.0.0 or later.
Sandbox Breakout / Arbitrary Code Execution in safer-eval
All versions of safer-eval are vulnerable to Sandbox Escape leading to Remote Code Execution. It is possible to escape the sandbox by forcing exceptions recursively in the evaluated code. This may allow attacker to execute arbitrary code in the system.
The package is not suited to receive arbitrary user input. Consider using an alternative package.
Sandbox Breakout / Arbitrary Code Execution in safer-eval
All versions of safer-eval are vulnerable to Sandbox Escape leading to Remote Code Execution. The package fails to restrict access to the main context and is not suited to process arbitrary user input. This may allow attackers to execute arbitrary code in the system.
The package is not meant to receive user input. Consider using an alternative package until a fix is made available.
Terser insecure use of regular expressions leads to ReDoS
The package terser before 4.8.1, from 5.0.0 and before 5.14.2 are vulnerable to Regular Expression Denial of Service (ReDoS) due to insecure usage of regular expressions.