Sqlite3 version 5.0.0 introduces several notable changes compared to the previous stable version 4.2.0, impacting developers utilizing the popular asynchronous SQLite3 bindings for Node.js. The most significant shift is the replacement of the 'nan' dependency with 'node-addon-api'. This transition signals a move towards a more modern and stable API for creating Node.js addons, potentially improving compatibility and reducing maintenance overhead. Furthermore, version 5.0.0 explicitly declares dependencies on both 'node-pre-gyp' and 'node-gyp', whereas version 4.2.0 only specified 'node-pre-gyp'. Node-gyp is also added as a peer dependency and optional dependency. The inclusion suggests a potentially revised build process or expanded support for different build environments.
Developers should be aware that the underlying mechanism for building and distributing pre-compiled binaries might have changed.
Both versions maintain the same core description, license (BSD-3-Clause), repository, and author information, indicating a continued commitment to the project's stability and open-source nature. The development dependencies remain consistent, leveraging tools like @mapbox/cloudfriend, aws-sdk, eslint, and mocha for cloud deployment, AWS integration, linting, and testing. Finally version 5.0.0 saw a reduction to a fileCount of 32 versus 42 of the previous version, and a slightly different unpackedSize. Overall, the upgrade to version 5.0.0 necessitates careful consideration, particularly regarding potential build-time changes and the shift to 'node-addon-api'.
All the vulnerabilities related to the version 5.0.0 of the package
Denial-of-Service when binding invalid parameters in sqlite3
Affected versions of sqlite3 will experience a fatal error when supplying a specific object in the parameter array. This error causes the application to crash and could not be caught. Users of sqlite3 v5.0.0, v5.0.1 and v5.0.2 are affected by this. This issue is fixed in v5.0.3. All users are recommended to upgrade to v5.0.3 or later. Ensure there is sufficient sanitization in the parent application to protect against invalid values being supplied to binding parameters as a workaround.
sqlite vulnerable to code execution due to Object coercion
Due to the underlying implementation of .ToString(), it's possible to execute arbitrary JavaScript, or to achieve a denial-of-service, if a binding parameter is a crafted Object.
Users of sqlite3 v5.0.0 - v5.1.4 are affected by this.
Fixed in v5.1.5. All users are recommended to upgrade to v5.1.5 or later.
If you have any questions or comments about this advisory:
Credits: Dave McDaniel of Cisco Talos
Denial of service while parsing a tar file due to lack of folders count validation
During some analysis today on npm's node-tar package I came across the folder creation process, Basicly if you provide node-tar with a path like this ./a/b/c/foo.txt it would create every folder and sub-folder here a, b and c until it reaches the last folder to create foo.txt, In-this case I noticed that there's no validation at all on the amount of folders being created, that said we're actually able to CPU and memory consume the system running node-tar and even crash the nodejs client within few seconds of running it using a path with too many sub-folders inside
You can reproduce this issue by downloading the tar file I provided in the resources and using node-tar to extract it, you should get the same behavior as the video
Here's a video show-casing the exploit:
Denial of service by crashing the nodejs client when attempting to parse a tar archive, make it run out of heap memory and consuming server CPU and memory resources
This report was originally reported to GitHub bug bounty program, they asked me to report it to you a month ago
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.