Jsdom version 0.5.3 marks a minor update to the popular JavaScript implementation of the W3C DOM, building upon the foundation laid by version 0.5.2. Developers leveraging jsdom for server-side DOM manipulation or testing purposes will find the changes subtle yet potentially impactful. The key difference lies in the request dependency, where version 0.5.3 pins the library to 2.14 while the previous version 0.5.2 used 2.x. This could indicate a fix addressing compatibility issues or bugs introduced in later 2.x versions of the request library.
For those utilizing jsdom to fetch external resources, this change in the request dependency is particularly noteworthy. It's crucial to assess whether the restricted version introduces any limitations or necessitates adjustments in how external content is handled.
Both versions maintain similar core functionalities, including CSSOM support, CSS styling capabilities, and DOM querying through nwmatcher. The htmlparser dependency remains consistent, ensuring consistent HTML parsing behavior. The development dependencies, crucial for contributing to jsdom or running tests, are also unchanged. Overall, the move from version 0.5.2 to 0.5.3 suggests a focused effort to stabilize dependencies and potentially address specific issues related to web requests. Understanding the nuances is really important for a developer that wants to keep its application healthy and up to date.
All the vulnerabilities related to the version 0.5.3 of the package
Remote Memory Exposure in request
Affected versions of request
will disclose local system memory to remote systems in certain circumstances. When a multipart request is made, and the type of body
is number
, then a buffer of that size will be allocated and sent to the remote server as the body.
var request = require('request');
var http = require('http');
var serveFunction = function (req, res){
req.on('data', function (data) {
console.log(data)
});
res.end();
};
var server = http.createServer(serveFunction);
server.listen(8000);
request({
method: "POST",
uri: 'http://localhost:8000',
multipart: [{body:500}]
},function(err,res,body){});
Update to version 2.68.0 or later
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.
mime Regular Expression Denial of Service when MIME lookup performed on untrusted user input
Affected versions of mime
are vulnerable to regular expression denial of service when a mime lookup is performed on untrusted user input.
Update to version 2.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.