136 threats tracked across 6 launch stacks — sourced from NVD, GHSA, CISA KEV, and OSV.
File Upload vulnerability in nestjs nest prior to v.11.0.16 allows a remote attacker to execute arbitrary code via the Content-Type header.
An issue discovered in Axios 0.8.1 through 1.5.1 inadvertently reveals the confidential XSRF-TOKEN stored in cookies by including it in the HTTP header X-XSRF-TOKEN for every request made to any host allowing attackers to view sensitive information.
Versions of the package @nestjs/core before 9.0.5 are vulnerable to Information Exposure via the StreamableFile pipe. Exploiting this vulnerability is possible when the client cancels a request while it is streaming a StreamableFile, the stream wrapped by the StreamableFile will be kept open.
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
axios before v0.21.2 is vulnerable to Inefficient Regular Expression Complexity.
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–29 of 29 threats