Sapphi-Red

**Name of the Vulnerable Software and Affected Versions** webpack-dev-server versions prior to 5.2.4 **Description** Cross-origin source code exposure occurs when serving over a non-potentially trustworthy origin, such as plain HTTP. The issue arises because the previous fix relied on `Sec-Fetch-Mode` and `Sec-Fetch-Site` request headers, which browsers omit for non-trustworthy origins. This allows a malicious site to load the bundled source as a script and read it across origins. An attacker controlling a website visited by a developer can recover the application source code if the server runs over HTTP at a guessable host and port. Chromium-based browsers from Chrome 142 onward are not affected due to local network access restrictions. **Recommendations** Upgrade to version 5.2.4 or later.

**Name of the Vulnerable Software and Affected Versions** webpack-dev-server versions prior to 5.2.1 **Description** The issue allows an attacker to steal users' source code when they access a malicious website. This is possible because the request for a classic script by a script tag is not subject to the same origin policy, enabling an attacker to inject a malicious script and run it. The attacker must know the port and the output entrypoint script path. By combining this with prototype pollution, the attacker can get a reference to the webpack runtime variables. Using `Function::toString` against the values in ` webpack modules ` allows the attacker to obtain the source code. **Recommendations** For versions prior to 5.2.1, update to version 5.2.1 or later to resolve the issue. As a temporary workaround, consider restricting access to the development server to minimize the risk of exploitation. Avoid using the ` webpack modules ` variable in sensitive contexts until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** webpack-dev-server versions prior to 5.2.1 **Description** The issue allows an attacker to obtain source code via a method similar to that used to exploit a previously reported vulnerability. This is possible because webpack-dev-server always allows IP address `Origin` headers, enabling websites served on IP addresses to connect via WebSocket. The `Origin` header is checked to prevent Cross-site WebSocket hijacking. **Recommendations** For versions prior to 5.2.1, update to version 5.2.1 or later to resolve the issue. As a temporary workaround, consider restricting access to the WebSocket connection to prevent potential exploitation.

**Name of the Vulnerable Software and Affected Versions** Next.js versions 13.0.0 through 13.3.x Next.js versions 13.4 and earlier with experimental.appDir = true Next.js versions prior to 15.2.2 **Description** This issue is similar to a previously known vulnerability. When running a Next.js server locally, the WebSocket server is susceptible to Cross-site WebSocket hijacking (CSWSH) attacks. If a user visits a malicious link while the Next.js dev server is running, a bad actor may access the source code of client components. This affects applications using App Router, which was experimental in versions 13.0.0 to 13.3.x. The vulnerability allows an attacker to spy on dev activity and steal source code. **Recommendations** For Next.js versions 13.0.0 through 13.3.x, update to version 15.2.2 or later to fix the issue. For Next.js versions 13.4 and earlier with experimental.appDir = true, update to version 15.2.2 or later to fix the issue. For Next.js versions prior to 15.2.2, update to version 15.2.2 or later to fix the issue. As a temporary workaround, consider disabling the `next dev` server when not in use to minimize the risk of exploitation.

Name of the Vulnerable Software and Affected Versions: Vitest versions prior to 2.1.9 Vitest versions prior to 3.0.4 Description: The ` screenshot-error` handler on the browser mode HTTP server responds to any file on the file system. If the server is exposed on the network by `browser.api.host: true`, an attacker can send a request to that handler from remote to get the content of arbitrary files. This issue allows attackers to read arbitrary files on the system. Recommendations: For versions prior to 2.1.9, update to version 2.1.9 or later. For versions prior to 3.0.4, update to version 3.0.4 or later. As a temporary workaround, consider disabling the `browser.api.host: true` configuration to prevent exposure of the browser mode server to the network. Restrict access to the ` screenshot-error` handler to minimize the risk of exploitation. Avoid using the `file` parameter in the ` screenshot-error` handler until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Vitest versions prior to 1.6.1 Vitest versions prior to 2.1.9 Vitest versions prior to 3.0.5 **Description** The issue is related to arbitrary remote code execution when accessing a malicious website while the Vitest API server is listening, due to Cross-site WebSocket hijacking (CSWSH) attacks. The Vitest API server starts a WebSocket server when the `api` option is enabled. This server has a `saveTestFile` API that can edit a test file and a `rerun` API that can rerun the tests. An attacker can execute arbitrary code by injecting code into a test file using the `saveTestFile` API and then running that file by calling the `rerun` API. **Recommendations** For Vitest versions prior to 1.6.1, upgrade to version 1.6.1 or later. For Vitest versions prior to 2.1.9, upgrade to version 2.1.9 or later. For Vitest versions prior to 3.0.5, upgrade to version 3.0.5 or later. As a temporary workaround, consider disabling the `saveTestFile` and `rerun` APIs until a patch is available. Restrict access to the Vitest API server to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** @nuxt/rspack-builder versions 3.15.4 through 3.21.5 @nuxt/rspack-builder versions 4.0.0-alpha.1 through 4.4.5 @nuxt/webpack-builder versions 3.15.4 through 3.21.5 @nuxt/webpack-builder versions 4.0.0-alpha.1 through 4.4.5 **Description** An incomplete fix in the webpack and rspack builders allows source code to be stolen during development. This occurs if the development server is bound to a non-loopback address (for example, by using `nuxt dev --host`) and a developer visits a malicious website on the same network. The issue stems from a reliance on `Sec-Fetch-Mode` and `Sec-Fetch-Site` headers, which browsers only send for potentially trustworthy origins, allowing the check to be bypassed for non-trustworthy origins. **Recommendations** Update @nuxt/rspack-builder versions 3.15.4 through 3.21.5 to version 3.21.6. Update @nuxt/rspack-builder versions 4.0.0-alpha.1 through 4.4.5 to version 4.4.6. Update @nuxt/webpack-builder versions 3.15.4 through 3.21.5 to version 3.21.6. Update @nuxt/webpack-builder versions 4.0.0-alpha.1 through 4.4.5 to version 4.4.6. Avoid using the `nuxt dev --host` command and bind the development server to `localhost`. Switch to the Vite builder for development.

**Name of the Vulnerable Software and Affected Versions** Nuxt versions 3.0.0 through 3.15.12 Nuxt versions 3.12.2 through 3.152 **Description** Source code may be stolen during development when using the webpack or rspack builder and a victim opens a malicious website. Because the request for classic script by a script tag is not subject to the same origin policy, an attacker can inject a malicious script in their site and run the script. By using `Function::toString` against the values in `window.webpackChunknuxt app`, the attacker can get the source code. **Recommendations** For Nuxt versions 3.0.0 through 3.15.12, update to version 3.15.13 to patch the issue. For Nuxt versions 3.12.2 through 3.152, update to version 3.15.13 to patch the issue. As a temporary workaround, consider restricting access to the `window.webpackChunknuxt app` values to minimize the risk of exploitation. Avoid using the `Function::toString` method against the values in `window.webpackChunknuxt app` until the issue is resolved.