Multer vulnerable to Denial of Service from maliciously crafted requests
Impact
A vulnerability in Multer versions >=1.4.4-lts.1 allows an attacker to trigger a Denial of Service (DoS) by sending a malformed multi-part upload request. This request causes an unhandled exception, leading to a crash of the process.
Patches
Users should upgrade to 2.0.0
Workarounds
None
References
https://github.com/expressjs/multer/issues/1176
https://github.com/expressjs/multer/commit/2c8505f207d923dd8de13a9f93a4563e59933665
Multer vulnerable to Denial of Service via memory leaks from unclosed streams
Impact
Multer <2.0.0 is vulnerable to a resource exhaustion and memory leak issue due to improper stream handling. When the HTTP request stream emits an error, the internal busboy stream is not closed, violating Node.js stream safety guidance.
This leads to unclosed streams accumulating over time, consuming memory and file descriptors. Under sustained or repeated failure conditions, this can result in denial of service, requiring manual server restarts to recover. All users of Multer han
FastAPI Guard Auth Bypass via X-Forwarded-For
Attacker manipulates X-Forwarded-For header to bypass IP-based access controls. Fixed in fastapi-guard 2.0.0.
FastAPI unauthenticated RCE via code eval endpoint (Langflow)
FastAPI app executed arbitrary Python via /api/v1/validate/code without authentication. Actively exploited in wild.
Authorization Bypass in Next.js Middleware
Impact
It is possible to bypass authorization checks within a Next.js application, if the authorization check occurs in middleware.
Patches
For Next.js 15.x, this issue is fixed in 15.2.3
For Next.js 14.x, this issue is fixed in 14.2.25
For Next.js 13.x, this issue is fixed in 13.5.9
For Next.js 12.x, this issue is fixed in 12.3.5
For Next.js 11.x, consult the below workaround.
_Note: Next.js deployments hosted on Vercel are automatically protected against this vulnerability.
Nuxt allows DOS via cache poisoning with payload rendering response
Summary
By sending a crafted HTTP request to a server behind an CDN, it is possible in some circumstances to poison the CDN cache and highly impacts the availability of a site.
It is possible to craft a request, such as https://mysite.com/?/_payload.json which will be rendered as JSON. If the CDN in front of a Nuxt site ignores the query string when determining whether to cache a route, then this JSON response could be served to future visitors to the site.
Impact
An attacker can p
axios Requests Vulnerable To Possible SSRF and Credential Leakage via Absolute URL
Summary
A previously reported issue in axios demonstrated that using protocol-relative URLs could lead to SSRF (Server-Side Request Forgery). Reference: axios/axios#6463
A similar problem that occurs when passing absolute URLs rather than protocol-relative URLs to axios has been identified. Even if baseURL is set, axios sends the request to the specified absolute URL, potentially causing SSRF and credential leakage. This issue impacts both server-side and client-side usage of axios.
##
Mongoose search injection vulnerability
Mongoose versions prior to 8.9.5, 7.8.4, and 6.13.6 are vulnerable to improper use of the $where operator. This vulnerability arises from the ability of the $where clause to execute arbitrary JavaScript code in MongoDB queries, potentially leading to code injection attacks and unauthorized access or manipulation of database data.
NOTE: this issue exists because of an incomplete fix for CVE-2024-53900.
Mongoose search injection vulnerability
Mongoose versions prior to 8.8.3, 7.8.3, 6.13.5, and 5.13.23 are vulnerable to improper use of the $where operator. This vulnerability arises from the ability of the $where clause to execute arbitrary JavaScript code in MongoDB queries, potentially leading to code injection attacks and unauthorized access or manipulation of database data.
Next.js authorization bypass vulnerability
Impact
If a Next.js application is performing authorization in middleware based on pathname, it was possible for this authorization to be bypassed.
Patches
This issue was patched in Next.js 14.2.15 and later.
If your Next.js application is hosted on Vercel, this vulnerability has been automatically mitigated, regardless of Next.js version.
Workarounds
There are no official workarounds for this vulnerability.
Credits
We'd like to thank tyage (GMO
Next.js Cache Poisoning
Impact
By sending a crafted HTTP request, it is possible to poison the cache of a non-dynamic server-side rendered route in the pages router (this does not affect the app router). When this crafted request is sent it could coerce Next.js to cache a route that is meant to not be cached and send a Cache-Control: s-maxage=1, stale-while-revalidate header which some upstream CDNs may cache as well.
To be potentially affected all of the following must apply:
Next.js between 13.5.1 and 14
Next.js Server-Side Request Forgery in Server Actions
Impact
A Server-Side Request Forgery (SSRF) vulnerability was identified in Next.js Server Actions by security researchers at Assetnote. If the Host header is modified, and the below conditions are also met, an attacker may be able to make requests that appear to be originating from the Next.js application server itself.
Prerequisites
Next.js (<14.1.1) is running in a self-hosted manner.
The Next.js application makes use of Server Actions.
The Server Action performs a redire
Mongoose Prototype Pollution vulnerability
Prototype Pollution in GitHub repository automattic/mongoose prior to 7.3.3, 6.11.3, and 5.13.20.
Sequelize vulnerable to SQL Injection via replacements
Impact
The SQL injection exploit is related to replacements. Here is such an example:
In the following query, some parameters are passed through replacements, and some are passed directly through the where option.
``typescript
User.findAll({
where: or(
literal('soundex("firstName") = soundex(:firstName)'),
{ lastName: lastName },
),
replacements: { firstName },
})
``
This is a very legitimate use case, but this query was vulnerable to SQL injection due to how Sequelize
Unsafe fall-through in getWhereConditions
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` &
Sequelize - Default support for “raw attributes” when using parentheses
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
automattic/mongoose vulnerable to Prototype pollution via Schema.path
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.
Mongoose Vulnerable to Prototype Pollution in Schema Object
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 =
jsonwebtoken unrestricted key type could lead to legacy keys usage
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
node-fetch forwards secure headers to untrusted sites
node-fetch forwards secure headers such as authorization, www-authenticate, cookie, & cookie2 when redirecting to a untrusted site.
