Find, fix and prevent vulnerabilities in your code.
critical severity
- Vulnerable module: next
- Introduced through: next@14.2.13
Detailed paths
-
Introduced through: screamer@SVendittelli/screamer#7301303c451e8d567b853f184a3f26fdba2b7489 › next@14.2.13Remediation: Upgrade to next@14.2.25.
Overview
next is a react framework.
Affected versions of this package are vulnerable to Improper Authorization due to the improper handling of the x-middleware-subrequest header. An attacker can bypass authorization checks by sending crafted requests containing this specific header.
Workaround
This can be mitigated by preventing external user requests which contain the x-middleware-subrequest header from reaching your Next.js application.
Remediation
Upgrade next to version 12.3.5, 13.5.9, 14.2.25, 15.2.3, 15.3.0-canary.12 or higher.
References
high severity
new
- Vulnerable module: validator
- Introduced through: validator@13.12.0
Detailed paths
-
Introduced through: screamer@SVendittelli/screamer#7301303c451e8d567b853f184a3f26fdba2b7489 › validator@13.12.0Remediation: Upgrade to validator@13.15.22.
Overview
validator is a library of string validators and sanitizers.
Affected versions of this package are vulnerable to Incomplete Filtering of One or More Instances of Special Elements in the isLength() function that does not take into account Unicode variation selectors (\uFE0F, \uFE0E) appearing in a sequence which lead to improper string length calculation. This can lead to an application using isLength for input validation accepting strings significantly longer than intended, resulting in issues like data truncation in databases, buffer overflows in other system components, or denial-of-service.
PoC
Input;
const validator = require('validator');
console.log(`Is "test" (String.length: ${'test'.length}) length less than or equal to 3? ${validator.isLength('test', { max: 3 })}`);
console.log(`Is "test" (String.length: ${'test'.length}) length less than or equal to 4? ${validator.isLength('test', { max: 4 })}`);
console.log(`Is "test\uFE0F\uFE0F\uFE0F\uFE0F" (String.length: ${'test\uFE0F\uFE0F\uFE0F\uFE0F'.length}) length less than or equal to 4? ${validator.isLength('test\uFE0F\uFE0F\uFE0F', { max: 4 })}`);
Output:
Is "test" (String.length: 4) length less than or equal to 3? false
Is "test" (String.length: 4) length less than or equal to 4? true
Is "test️️️️" (String.length: 8) length less than or equal to 4? true
Remediation
Upgrade validator to version 13.15.22 or higher.
References
high severity
- Vulnerable module: next
- Introduced through: next@14.2.13
Detailed paths
-
Introduced through: screamer@SVendittelli/screamer#7301303c451e8d567b853f184a3f26fdba2b7489 › next@14.2.13Remediation: Upgrade to next@14.2.32.
Overview
next is a react framework.
Affected versions of this package are vulnerable to Server-side Request Forgery (SSRF) via the resolve-routes. An attacker can access internal resources and potentially exfiltrate sensitive information by crafting requests containing user-controlled headers (e.g.,
Location) that are forwarded or interpreted without validation.
Note: This is only exploitable if custom middleware logic is implemented in a self-hosted deployment. The project maintainers recommend using the documented NextResponse.next({request}) to explicitly pass the request object.
Remediation
Upgrade next to version 14.2.32, 15.4.2-canary.43, 15.4.7 or higher.
References
high severity
- Vulnerable module: next
- Introduced through: next@14.2.13
Detailed paths
-
Introduced through: screamer@SVendittelli/screamer#7301303c451e8d567b853f184a3f26fdba2b7489 › next@14.2.13Remediation: Upgrade to next@14.2.15.
Overview
next is a react framework.
Affected versions of this package are vulnerable to Missing Authorization when using pathname-based checks in middleware for authorization decisions. If i18n configuration is not configured, an attacker can get unintended access to pages one level under the application's root directory.
e.g. https://example.com/foo is accessible. https://example.com/ and https://example.com/foo/bar are not.
Note:
Only self-hosted applications are vulnerable. The vulnerability has been fixed by Vercel on the server side.
Remediation
Upgrade next to version 13.5.8, 14.2.15, 15.0.0-canary.177 or higher.
References
medium severity
new
- Vulnerable module: js-yaml
- Introduced through: swagger-ui-react@5.17.14
Detailed paths
-
Introduced through: screamer@SVendittelli/screamer#7301303c451e8d567b853f184a3f26fdba2b7489 › swagger-ui-react@5.17.14 › js-yaml@4.1.0Remediation: Upgrade to swagger-ui-react@5.30.3.
Overview
js-yaml is a human-friendly data serialization language.
Affected versions of this package are vulnerable to Prototype Pollution via the merge function. An attacker can alter object prototypes by supplying specially crafted YAML documents containing __proto__ properties. This can lead to unexpected behavior or security issues in applications that process untrusted YAML input.
Workaround
This vulnerability can be mitigated by running the server with node --disable-proto=delete or by using Deno, which has pollution protection enabled by default.
Details
Prototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as __proto__, constructor and prototype. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the Object.prototype are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.
There are two main ways in which the pollution of prototypes occurs:
Unsafe
Objectrecursive mergeProperty definition by path
Unsafe Object recursive merge
The logic of a vulnerable recursive merge function follows the following high-level model:
merge (target, source)
foreach property of source
if property exists and is an object on both the target and the source
merge(target[property], source[property])
else
target[property] = source[property]
When the source object contains a property named __proto__ defined with Object.defineProperty() , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of Object and the source of Object as defined by the attacker. Properties are then copied on the Object prototype.
Clone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: merge({},source).
lodash and Hoek are examples of libraries susceptible to recursive merge attacks.
Property definition by path
There are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: theFunction(object, path, value)
If the attacker can control the value of “path”, they can set this value to __proto__.myValue. myValue is then assigned to the prototype of the class of the object.
Types of attacks
There are a few methods by which Prototype Pollution can be manipulated:
| Type | Origin | Short description |
|---|---|---|
| Denial of service (DoS) | Client | This is the most likely attack. DoS occurs when Object holds generic functions that are implicitly called for various operations (for example, toString and valueOf). The attacker pollutes Object.prototype.someattr and alters its state to an unexpected value such as Int or Object. In this case, the code fails and is likely to cause a denial of service. For example: if an attacker pollutes Object.prototype.toString by defining it as an integer, if the codebase at any point was reliant on someobject.toString() it would fail. |
| Remote Code Execution | Client | Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation. For example: eval(someobject.someattr). In this case, if the attacker pollutes Object.prototype.someattr they are likely to be able to leverage this in order to execute code. |
| Property Injection | Client | The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens. For example: if a codebase checks privileges for someuser.isAdmin, then when the attacker pollutes Object.prototype.isAdmin and sets it to equal true, they can then achieve admin privileges. |
Affected environments
The following environments are susceptible to a Prototype Pollution attack:
Application server
Web server
Web browser
How to prevent
Freeze the prototype— use
Object.freeze (Object.prototype).Require schema validation of JSON input.
Avoid using unsafe recursive merge functions.
Consider using objects without prototypes (for example,
Object.create(null)), breaking the prototype chain and preventing pollution.As a best practice use
Mapinstead ofObject.
For more information on this vulnerability type:
Arteau, Oliver. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018
Remediation
Upgrade js-yaml to version 3.14.2, 4.1.1 or higher.
References
medium severity
- Vulnerable module: next
- Introduced through: next@14.2.13
Detailed paths
-
Introduced through: screamer@SVendittelli/screamer#7301303c451e8d567b853f184a3f26fdba2b7489 › next@14.2.13Remediation: Upgrade to next@14.2.21.
Overview
next is a react framework.
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling through the Server Actions process. An attacker can cause the server to hang by constructing requests that leave Server-Actions requests pending until the hosting provider terminates the function execution.
Note:
This is only exploitable if there are no protections against long-running Server Action invocations.
Remediation
Upgrade next to version 13.5.8, 14.2.21, 15.1.2 or higher.
References
medium severity
- Vulnerable module: nodemailer
- Introduced through: supertokens-node@20.1.2
Detailed paths
-
Introduced through: screamer@SVendittelli/screamer#7301303c451e8d567b853f184a3f26fdba2b7489 › supertokens-node@20.1.2 › nodemailer@6.10.1
Overview
nodemailer is an Easy as cake e-mail sending from your Node.js applications
Affected versions of this package are vulnerable to Interpretation Conflict due to improper handling of quoted local-parts containing @. An attacker can cause emails to be sent to unintended external recipients or bypass domain-based access controls by crafting specially formatted email addresses with quoted local-parts containing the @ character.
Remediation
Upgrade nodemailer to version 7.0.7 or higher.
References
medium severity
- Vulnerable module: cookie
- Introduced through: supertokens-node@20.1.2
Detailed paths
-
Introduced through: screamer@SVendittelli/screamer#7301303c451e8d567b853f184a3f26fdba2b7489 › supertokens-node@20.1.2 › cookie@0.4.0Remediation: Upgrade to supertokens-node@21.0.0.
Overview
Affected versions of this package are vulnerable to Cross-site Scripting (XSS) via the cookie name, path, or domain, which can be used to set unexpected values to other cookie fields.
Workaround
Users who are not able to upgrade to the fixed version should avoid passing untrusted or arbitrary values for the cookie fields and ensure they are set by the application instead of user input.
Details
Cross-site scripting (or XSS) is a code vulnerability that occurs when an attacker “injects” a malicious script into an otherwise trusted website. The injected script gets downloaded and executed by the end user’s browser when the user interacts with the compromised website.
This is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.
Injecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.
Escaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, < can be coded as < and > can be coded as > in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses < and > as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.
The most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware.
Types of attacks
There are a few methods by which XSS can be manipulated:
| Type | Origin | Description |
|---|---|---|
| Stored | Server | The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link. |
| Reflected | Server | The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser. |
| DOM-based | Client | The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data. |
| Mutated | The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters. |
Affected environments
The following environments are susceptible to an XSS attack:
- Web servers
- Application servers
- Web application environments
How to prevent
This section describes the top best practices designed to specifically protect your code:
- Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches.
- Convert special characters such as
?,&,/,<,>and spaces to their respective HTML or URL encoded equivalents. - Give users the option to disable client-side scripts.
- Redirect invalid requests.
- Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.
- Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.
- Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.
Remediation
Upgrade cookie to version 0.7.0 or higher.
References
medium severity
- Vulnerable module: next
- Introduced through: next@14.2.13
Detailed paths
-
Introduced through: screamer@SVendittelli/screamer#7301303c451e8d567b853f184a3f26fdba2b7489 › next@14.2.13Remediation: Upgrade to next@14.2.24.
Overview
next is a react framework.
Affected versions of this package are vulnerable to Race Condition in the Pages Router. An attacker can cause the server to serve incorrect pageProps data instead of the expected HTML content by exploiting a race condition between two requests, one containing the ?__nextDataRequest=1 query parameter and another with the x-now-route-matches header.
Notes:
This is only exploitable if the CDN provider caches a
200 OKresponse even in the absence of explicitcache-controlheaders, enabling a poisoned response to persist and be served to subsequent users;No backend access or privileged escalation is possible through this vulnerability;
Applications hosted on Vercel's platform are not affected by this issue, as the platform does not cache responses based solely on
200 OKstatus without explicitcache-controlheaders.This is a bypass of the fix for CVE-2024-46982
Workaround
This can be mitigated by stripping the x-now-route-matches header from all incoming requests at your CDN and setting cache-control: no-store for all responses under risk.
Remediation
Upgrade next to version 14.2.24, 15.1.6 or higher.
References
medium severity
- Vulnerable module: next
- Introduced through: next@14.2.13
Detailed paths
-
Introduced through: screamer@SVendittelli/screamer#7301303c451e8d567b853f184a3f26fdba2b7489 › next@14.2.13Remediation: Upgrade to next@14.2.31.
Overview
next is a react framework.
Affected versions of this package are vulnerable to Use of Cache Containing Sensitive Information in the image optimization process, when responses from API routes vary based on request headers such as Cookie or Authorization. An attacker can gain unauthorized access to sensitive image data by exploiting cache key confusion, causing responses intended for authenticated users to be served to unauthorized users.
Note: Exploitation requires a prior authorized request to populate the cache.
Remediation
Upgrade next to version 14.2.31, 15.4.2-canary.19, 15.4.5 or higher.
References
medium severity
- Vulnerable module: inflight
- Introduced through: next-swagger-doc@0.4.0
Detailed paths
-
Introduced through: screamer@SVendittelli/screamer#7301303c451e8d567b853f184a3f26fdba2b7489 › next-swagger-doc@0.4.0 › swagger-jsdoc@6.2.8 › glob@7.1.6 › inflight@1.0.6
Overview
Affected versions of this package are vulnerable to Missing Release of Resource after Effective Lifetime via the makeres function due to improperly deleting keys from the reqs object after execution of callbacks. This behavior causes the keys to remain in the reqs object, which leads to resource exhaustion.
Exploiting this vulnerability results in crashing the node process or in the application crash.
Note: This library is not maintained, and currently, there is no fix for this issue. To overcome this vulnerability, several dependent packages have eliminated the use of this library.
To trigger the memory leak, an attacker would need to have the ability to execute or influence the asynchronous operations that use the inflight module within the application. This typically requires access to the internal workings of the server or application, which is not commonly exposed to remote users. Therefore, “Attack vector” is marked as “Local”.
PoC
const inflight = require('inflight');
function testInflight() {
let i = 0;
function scheduleNext() {
let key = `key-${i++}`;
const callback = () => {
};
for (let j = 0; j < 1000000; j++) {
inflight(key, callback);
}
setImmediate(scheduleNext);
}
if (i % 100 === 0) {
console.log(process.memoryUsage());
}
scheduleNext();
}
testInflight();
Remediation
There is no fixed version for inflight.
References
medium severity
- Vulnerable module: validator
- Introduced through: validator@13.12.0
Detailed paths
-
Introduced through: screamer@SVendittelli/screamer#7301303c451e8d567b853f184a3f26fdba2b7489 › validator@13.12.0Remediation: Upgrade to validator@13.15.20.
Overview
validator is a library of string validators and sanitizers.
Affected versions of this package are vulnerable to Improper Validation of Specified Type of Input in the isURL() function which does not take into account : as the delimiter in browsers. An attackers can bypass protocol and domain validation by crafting URLs that exploit the discrepancy in protocol parsing that can lead to Cross-Site Scripting and Open Redirect attacks.
Remediation
Upgrade validator to version 13.15.20 or higher.
References
medium severity
- Module: @vercel/analytics
- Introduced through: @vercel/analytics@1.3.1
Detailed paths
-
Introduced through: screamer@SVendittelli/screamer#7301303c451e8d567b853f184a3f26fdba2b7489 › @vercel/analytics@1.3.1
MPL-2.0 license
low severity
- Vulnerable module: next
- Introduced through: next@14.2.13
Detailed paths
-
Introduced through: screamer@SVendittelli/screamer#7301303c451e8d567b853f184a3f26fdba2b7489 › next@14.2.13Remediation: Upgrade to next@14.2.30.
Overview
next is a react framework.
Affected versions of this package are vulnerable to Missing Origin Validation in WebSockets when running next dev and the project uses the App Router. An attacker can access the source code of client components by exploiting the Cross-site WebSocket hijacking (CSWSH) attack when a user visits a malicious link while having the server running locally.
Workarounds
Avoid browsing untrusted websites while running the local development server.
Implement local firewall or proxy rules to block unauthorized WebSocket access to localhost.
Remediation
Upgrade next to version 14.2.30, 15.2.2 or higher.
References
low severity
- Vulnerable module: next
- Introduced through: next@14.2.13
Detailed paths
-
Introduced through: screamer@SVendittelli/screamer#7301303c451e8d567b853f184a3f26fdba2b7489 › next@14.2.13Remediation: Upgrade to next@14.2.31.
Overview
next is a react framework.
Affected versions of this package are vulnerable to Missing Source Correlation of Multiple Independent Data in image-optimizer. An attacker can cause arbitrary files to be downloaded with attacker-controlled content and filenames by supplying malicious external image sources.
Note: This is only exploitable if the application is configured to allow external image sources via the images.domains or images.remotePatterns configuration.
Remediation
Upgrade next to version 14.2.31, 15.4.2-canary.19, 15.4.5 or higher.
References
low severity
- Vulnerable module: prismjs
- Introduced through: swagger-ui-react@5.17.14
Detailed paths
-
Introduced through: screamer@SVendittelli/screamer#7301303c451e8d567b853f184a3f26fdba2b7489 › swagger-ui-react@5.17.14 › react-syntax-highlighter@15.6.6 › refractor@3.6.0 › prismjs@1.27.0
Overview
prismjs is a lightweight, robust, elegant syntax highlighting library.
Affected versions of this package are vulnerable to Arbitrary Code Injection via the document.currentScript lookup process. An attacker can manipulate the web page content and execute unintended actions by injecting HTML elements that overshadow legitimate DOM elements.
Note:
This is only exploitable if the application accepts untrusted input containing HTML but not direct JavaScript.
Remediation
Upgrade prismjs to version 1.30.0 or higher.
References
low severity
- Vulnerable module: dompurify
- Introduced through: swagger-ui-react@5.17.14
Detailed paths
-
Introduced through: screamer@SVendittelli/screamer#7301303c451e8d567b853f184a3f26fdba2b7489 › swagger-ui-react@5.17.14 › dompurify@3.1.4Remediation: Upgrade to swagger-ui-react@5.19.0.
Overview
dompurify is a DOM-only XSS sanitizer for HTML, MathML and SVG.
Affected versions of this package are vulnerable to Cross-site Scripting (XSS) due to incorrect handling of template literals in regular expressions. An attacker can manipulate the output of the script by injecting malicious payloads that bypass the dompurify sanitization.
PoC
DOMPurify.sanitize(
`<math><foo-test><mi><li><table><foo-test><li></li></foo-test><a>
<style>
<! \${
</style>
}
<foo-b id="><img src onerror='alert(1)'>">hmm...</foo-b>
</a></table></li></mi></foo-test></math>
`,
{
SAFE_FOR_TEMPLATES: true,
CUSTOM_ELEMENT_HANDLING: {
tagNameCheck: /^foo-/,
},
}
);
Details
Cross-site scripting (or XSS) is a code vulnerability that occurs when an attacker “injects” a malicious script into an otherwise trusted website. The injected script gets downloaded and executed by the end user’s browser when the user interacts with the compromised website.
This is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.
Injecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.
Escaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, < can be coded as < and > can be coded as > in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses < and > as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.
The most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware.
Types of attacks
There are a few methods by which XSS can be manipulated:
| Type | Origin | Description |
|---|---|---|
| Stored | Server | The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link. |
| Reflected | Server | The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser. |
| DOM-based | Client | The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data. |
| Mutated | The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters. |
Affected environments
The following environments are susceptible to an XSS attack:
- Web servers
- Application servers
- Web application environments
How to prevent
This section describes the top best practices designed to specifically protect your code:
- Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches.
- Convert special characters such as
?,&,/,<,>and spaces to their respective HTML or URL encoded equivalents. - Give users the option to disable client-side scripts.
- Redirect invalid requests.
- Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.
- Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.
- Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.
Remediation
Upgrade dompurify to version 3.2.4 or higher.