Sequelize information disclosure vulnerability
Due to improper input filtering in the sequelize js library, can malicious queries lead to sensitive information disclosure.
136 threats tracked across 6 launch stacks — sourced from NVD, GHSA, CISA KEV, and OSV.
Due to improper input filtering in the sequelize js library, can malicious queries lead to sensitive information disclosure.
Impact Providing an invalid value to the where option of a query caused Sequelize to ignore that option instead of throwing an error. A finder call like the following did not throw an error: ``ts User.findAll({ where: new Date(), }); ` As this option is typically used with plain javascript objects, be aware that this only happens at the top level of this option. Patches This issue has been patched in sequelize@6.28.1` &
Impact Sequelize 6.28.2 and prior has a dangerous feature where using parentheses in the attribute option would make Sequelize use the string as-is in the SQL ``ts User.findAll({ attributes: [ ['count(id)', 'count'] ] }); ` Produced `sql SELECT count(id) AS "count" FROM "users" ` Patches This feature was deprecated in Sequelize 5, and using it prints a deprecation warning. This issue has been patched in [@sequelize/core@7.0.0.alpha-20`](https://github.com/sequelize
Mongoose is a MongoDB object modeling tool designed to work in an asynchronous environment. Affected versions of this package are vulnerable to Prototype Pollution. The Schema.path() function is vulnerable to prototype pollution when setting the schema object. This vulnerability allows modification of the Object prototype and could be manipulated into a Denial of Service (DoS) attack.
Description Mongoose is a MongoDB object modeling tool designed to work in an asynchronous environment. Affected versions of this package are vulnerable to Prototype Pollution. The Schema.path() function is vulnerable to prototype pollution when setting the schema object. This vulnerability allows modification of the Object prototype and could be manipulated into a Denial of Service (DoS) attack. Proof of Concept ```js // poc.js const mongoose = require('mongoose'); const schema =
Overview Versions <=8.5.1 of jsonwebtoken library can be misconfigured so that passing a poorly implemented key retrieval function (referring to the secretOrPublicKey argument from the readme link) will result in incorrect verification of tokens. There is a possibility of using a different algorithm and key combination in verification than the one that was used to sign the tokens. Specifically, tokens signed with an asymmetric public key could be verified with a symmetric HS256 algorithm. This can lead to successful validation of forged tokens. Am I affected? You will be affected if your application is supporting usage of both symmetric key and asymmetric key in jwt.verify() implementation with the same key retrieval function. How do I fix it? Update to version 9.0.0. Will the fix impact my users? There is no impact for end users
Overview In versions <=8.5.1 of jsonwebtoken library, lack of algorithm definition and a falsy secret or key in the jwt.verify() function can lead to signature validation bypass due to defaulting to the none algorithm for signature verification. Am I affected? You will be affected if all the following are true in the jwt.verify() function: a token with no signature is received no algorithms are specified a falsy (e.g. null, false, undefined) secret or key is passed How do I fix it? Update to version 9.0.0 which removes the default support for the none algorithm in the jwt.verify() method. Will the fix impact my users? There will be no impact, if you update to version 9.0.0 and you don’t need to allow for the none algorithm. If you need 'none' algorithm, you have to explicitly specify that in jwt.verify() options.
Overview Versions <=8.5.1 of jsonwebtoken library could be misconfigured so that legacy, insecure key types are used for signature verification. For example, DSA keys could be used with the RS256 algorithm. Am I affected? You are affected if you are using an algorithm and a key type other than the combinations mentioned below | Key type | algorithm | |----------|------------------------------------------| | ec | ES256, ES384, ES512
lodash versions prior to 4.17.21 are vulnerable to Command Injection via the template function.
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): ``js 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); ``
Showing 21–30 of 30 threats