Sapphi-Red

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.

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.

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.

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.

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.

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.

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.

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.