Next.js Content Injection Vulnerability for Image Optimization
A vulnerability in Next.js Image Optimization has been fixed in v15.4.5 and v14.2.31. The issue allowed attacker-controlled external image sources to trigger file downloads with arbitrary content and filenames under specific configurations. This behavior could be abused for phishing or malicious file delivery.
All users relying on images.domains or images.remotePatterns are encouraged to upgrade and verify that external image sources are strictly validated.
More details at Vercel Changelog
Lodash has Prototype Pollution Vulnerability in `_.unset` and `_.omit` functions
Impact
Lodash versions 4.0.0 through 4.17.22 are vulnerable to prototype pollution in the _.unset and _.omit functions. An attacker can pass crafted paths which cause Lodash to delete methods from global prototypes.
The issue permits deletion of properties but does not allow overwriting their original behavior.
Patches
This issue is patched on 4.17.23.
Next.js Allows a Denial of Service (DoS) with Server Actions
Impact
A Denial of Service (DoS) attack allows attackers to construct requests that leaves requests to Server Actions hanging until the hosting provider cancels the function execution.
_Note: Next.js server is idle during that time and only keeps the connection open. CPU and memory footprint are low during that time._
Deployments without any protection against long running Server Action invocations are especially vulnerable. Hosting providers like Vercel or Netlify set a default maximum duration on function execution to reduce the risk of excessive billing.
This is the same issue as if the incoming HTTP request has an invalid Content-Length header or never closes. If the host has no other mitigations to those then this vulnerability is novel.
This vulnerability affects only Next.js deployments using Server Actions.
Patches
This vulnerability was resolved in Next.js 14.2.21, 15.1.2, and 13.5.8. We recommend that users upgrade to a safe version.
Workarounds
There are no official workarounds for this vulnerability.
Credits
Thanks to the PackDraw team for responsibly disclosing this vulnerability.
Denial of Service condition in Next.js image optimization
Impact
The image optimization feature of Next.js contained a vulnerability which allowed for a potential Denial of Service (DoS) condition which could lead to excessive CPU consumption.
Not affected:
The next.config.js file is configured with images.unoptimized set to true or images.loader set to a non-default value.
The Next.js application is hosted on Vercel.
Patches
This issue was fully patched in Next.js 14.2.7. We recommend that users upgrade to at least this version.
Workarounds
Ensure that the next.config.js file has either images.unoptimized, images.loader or images.loaderFile assigned.
Credits
Brandon Dahler (brandondahler), AWS
Dimitrios Vlastaras
nuxt vulnerable to Cross-site Scripting in navigateTo if used after SSR
Summary
The navigateTo function attempts to blockthe javascript: protocol, but does not correctly use API's provided by unjs/ufo. This library also contains parsing discrepancies.
Details
The function first tests to see if the specified URL has a protocol. This uses the unjs/ufo package for URL parsing. This function works effectively, and returns true for a javascript: protocol.
After this, the URL is parsed using the parseURL function. This function will refuse to parse poorly formatted URLs. Parsing javascript:alert(1) returns null/"" for all values.
Next, the protocol of the URL is then checked using the isScriptProtocol function. This function simply checks the input against a list of protocols, and does not perform any parsing.
The combination of refusing to parse poorly formatted URLs, and not performing additional parsing means that script checks fail as no protocol can be found. Even if a protocol was identified, whitespace is not stripped in the parseURL implementation, bypassing the isScriptProtocol checks.
Certain special protocols are identified at the top of parseURL. Inserting a newline or tab into this sequence will block the special protocol check, and bypass the latter checks.
PoC
POC - https://stackblitz.com/edit/nuxt-xss-navigateto?file=app.vue
Attempt payload X, then attempt payload Y.
Impact
XSS, access to cookies, make requests on user's behalf.
Recommendations
As always with these bugs, the URL constructor provided by the browser is always the safest method of parsing a URL.
Given the cross-platform requirements of nuxt/ufo a more appropriate solution is to make parsing consistent between functions, and to adapt parsing to be more consistent with the WHATWG URL specification.
Note
I've reported this vulnerability here as it is unclear if this is a bug in ufo or a misuse of the ufo library.
This ONLY has impact after SSR has occurred, the javascript: protocol within a location header does not trigger XSS.
nest allows a remote attacker to execute arbitrary code via the Content-Type header
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.
Express.js Open Redirect in malformed URLs
Impact
Versions of Express.js prior to 4.19.2 and pre-release alpha and beta versions before 5.0.0-beta.3 are affected by an open redirect vulnerability using malformed URLs.
When a user of Express performs a redirect using a user-provided URL Express performs an encode using encodeurl on the contents before passing it to the location header. This can cause malformed URLs to be evaluated in unexpected ways by common redirect allow list implementations in Express applications, leading to an Open Redirect via bypass of a properly implemented allow list.
The main method impacted is res.location() but this is also called from within res.redirect().
Patches
https://github.com/expressjs/express/commit/0867302ddbde0e9463d0564fea5861feb708c2dd
https://github.com/expressjs/express/commit/0b746953c4bd8e377123527db11f9cd866e39f94
An initial fix went out with express@4.19.0, we then patched a feature regression in 4.19.1 and added improved handling for the bypass in 4.19.2.
Workarounds
The fix for this involves pre-parsing the url string with either require('node:url').parse or new URL. These are steps you can take on your own before passing the user input string to res.location or res.redirect.
Resources
https://github.com/expressjs/express/pull/5539
https://github.com/koajs/koa/issues/1800
https://expressjs.com/en/4x/api.html#res.location
Axios Cross-Site Request Forgery Vulnerability
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.
@nestjs/core vulnerable to Information Exposure via StreamableFile pipe
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.
Sequelize information disclosure vulnerability
Due to improper input filtering in the sequelize js library, can malicious queries lead to sensitive information disclosure.
jsonwebtoken's insecure implementation of key retrieval function could lead to Forgeable Public/Private Tokens from RSA to HMAC
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
jsonwebtoken vulnerable to signature validation bypass due to insecure default algorithm in jwt.verify()
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.
Regular Expression Denial of Service (ReDoS) in lodash
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);
``
