Jsdom version 6.2.0 and 6.1.0 are both JavaScript implementations of the DOM and HTML standards, designed for server-side use cases like testing, web scraping, and manipulating HTML content in a Node.js environment. A quick look reveals most of the core dependencies remain identical between the two versions, including crucial libraries like acorn, cssom, parse5, and request. This suggests that the fundamental HTML parsing and DOM construction mechanisms are largely unchanged. Similarly, development dependencies providing tools for testing, code style checking, and building browser bundles stay consistent. This probably means the core testing and development workflows remain stable.
The most significant difference between these two releases lies in their release dates. Version 6.2.0 was published on August 25, 2015, approximately two weeks after version 6.1.0, released on August 11, 2015. While the absence of specific changelog data prevents a complete understanding of the precise bug fixes or minor feature enhancements included in 6.2.0, the updated release date suggests it incorporates stability improvements or resolves critical issues identified in the earlier 6.1.0 version.
For developers choosing between these versions, opting for the newer 6.2.0 is generally advisable. It is likely to offer a more refined and robust experience due to its later release date, incorporating necessary fixes. The shared dependencies between the two versions imply a similar API and overall functionality, so upgrading should be seamless. Always prioritize using the latest point release within a major version to benefit from the latest bug fixes and optimizations.
All the vulnerabilities related to the version 6.2.0 of the package
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.
ReDoS via long string of semicolons in tough-cookie
Affected versions of tough-cookie may be vulnerable to regular expression denial of service when long strings of semicolons exist in the Set-Cookie header.
Update to version 2.3.0 or later.
Regular Expression Denial of Service in tough-cookie
Affected versions of tough-cookie are susceptible to a regular expression denial of service.
The amplification on this vulnerability is relatively low - it takes around 2 seconds for the engine to execute on a malicious input which is 50,000 characters in length.
If node was compiled using the -DHTTP_MAX_HEADER_SIZE however, the impact of the vulnerability can be significant, as the primary limitation for the vulnerability is the default max HTTP header length in node.
Update to version 2.3.3 or later.
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.