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
the sensitive file exists in the allowed directories specified by server.fs.allow
the sensitive file is denied with a pattern that matches a file by server.fs.deny
Details
On the Vite dev server, files that should be blocked by server.fs.deny (e.g., .env, *.crt) can be retrieved with HTTP 200 responses when query parameters such as ?raw, ?import&raw, or ?import&url&inline are appended.
PoC
Start the dev server: pnpm exec vite root --host 127.0.0.1 --port 5175 --strictPort
Confirm that server.fs.deny is enforced (expect 403): curl -i http://127.0.0.1:5175/src/.env | head -n 20
Confirm that the same files can be retrieved with query parameters (expect 200):
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
Arbitrary files on the server (development machine, CI environment, container, etc.) can be exposed.
Details
If it is possible to connect to the Vite dev server’s WebSocket without an Origin header, an attacker can invoke fetchModule via the custom WebSocket event vite:invoke and combine file://... with ?raw (or ?inline) to retrieve the contents of arbitrary files on the server as a JavaScript string (e.g., export default "...").
The access control enforced in the HTTP request path (such as server.fs.allow) is not applied to this WebSocket-based execution path.
PoC
Start the dev server on the target
Example (used during validation with this repository):
pnpm -C playground/alias exec vite --host 0.0.0.0 --port 5173
Confirm that access is blocked via the HTTP path (example: arbitrary file)
Confirm that the same file can be retrieved via the WebSocket path
By connecting to the HMR WebSocket without an Origin header and sending a vite:invoke request that calls fetchModule with a file://... URL and ?raw, the file contents are returned as a JavaScript module.
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.
Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.
♻ Renovate will retry this branch, including artifacts, only when one of the following happens:
any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually
The artifact failure details are included below:
File name: pnpm-lock.yaml
Scope: all 9 workspace projects
? Verifying lockfile against supply-chain policies (1394 entries)...
Progress: resolved 1, reused 0, downloaded 0, added 0
Progress: resolved 54, reused 0, downloaded 0, added 0
✗ Lockfile failed supply-chain policy check (1394 entries in 9.5s)
[ERR_PNPM_TRUST_DOWNGRADE] 5 lockfile entries failed verification:
chokidar@4.0.3 High-risk trust downgrade for "chokidar@4.0.3" (possible package takeover)
semver@5.7.2 High-risk trust downgrade for "semver@5.7.2" (possible package takeover)
semver@6.3.1 High-risk trust downgrade for "semver@6.3.1" (possible package takeover)
undici-types@6.21.0 High-risk trust downgrade for "undici-types@6.21.0" (possible package takeover)
vite@5.4.21 High-risk trust downgrade for "vite@5.4.21" (possible package takeover)
The lockfile contains entries that the active policies reject. This can mean the lockfile is stale, or that someone committed a lockfile that bypassed the policy locally — inspect recent changes to pnpm-lock.yaml before trusting it. If the changes look expected, run "pnpm clean --lockfile" and then "pnpm install" to rebuild from a fresh resolution. Alternatively, relax the policy that flagged them.
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
renovateBot
changed the title
chore(deps): update pnpm.catalog.default vite [security]
chore(deps): update pnpm.catalog.default vite to v7.3.2 [security]
May 29, 2026
renovateBot
changed the title
chore(deps): update pnpm.catalog.default vite to v7.3.2 [security]
chore(deps): update pnpm.catalog.default vite [security]
Jun 1, 2026
renovateBot
changed the title
chore(deps): update pnpm.catalog.default vite [security]
chore(deps): update pnpm.catalog.default vite to v7.3.2 [security]
Jun 2, 2026
renovateBot
changed the title
chore(deps): update pnpm.catalog.default vite to v7.3.2 [security]
chore(deps): update pnpm.catalog.default vite [security]
Jun 11, 2026
renovateBot
changed the title
chore(deps): update pnpm.catalog.default vite [security]
chore(deps): update pnpm.catalog.default vite to v7.3.2 [security]
Jun 12, 2026
renovateBot
changed the title
chore(deps): update pnpm.catalog.default vite to v7.3.2 [security]
chore(deps): update pnpm.catalog.default vite [security]
Jun 18, 2026
renovateBot
changed the title
chore(deps): update pnpm.catalog.default vite [security]
chore(deps): update pnpm.catalog.default vite to v7.3.5 [security]
Jun 19, 2026
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
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.
This PR contains the following updates:
7.3.1→7.3.5>=7.3.1→>=7.3.5Vite:
server.fs.denybypassed with queriesCVE-2026-39364 / GHSA-v2wj-q39q-566r
More information
Details
Summary
The contents of files that are specified by
server.fs.denycan be returned to the browser.Impact
Only apps that match the following conditions are affected:
--hostorserver.hostconfig option)server.fs.allowserver.fs.denyDetails
On the Vite dev server, files that should be blocked by
server.fs.deny(e.g.,.env,*.crt) can be retrieved with HTTP 200 responses when query parameters such as?raw,?import&raw, or?import&url&inlineare appended.PoC
pnpm exec vite root --host 127.0.0.1 --port 5175 --strictPortserver.fs.denyis enforced (expect 403):curl -i http://127.0.0.1:5175/src/.env | head -n 20Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/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).
Vite Vulnerable to Arbitrary File Read via Vite Dev Server WebSocket
CVE-2026-39363 / GHSA-p9ff-h696-f583
More information
Details
Summary
server.fscheck was not enforced to thefetchModulemethod that is exposed in Vite dev server's WebSocket.Impact
Only apps that match the following conditions are affected:
--hostorserver.hostconfig option)server.ws: falseArbitrary files on the server (development machine, CI environment, container, etc.) can be exposed.
Details
If it is possible to connect to the Vite dev server’s WebSocket without an
Originheader, an attacker can invokefetchModulevia the custom WebSocket eventvite:invokeand combinefile://...with?raw(or?inline) to retrieve the contents of arbitrary files on the server as a JavaScript string (e.g.,export default "...").The access control enforced in the HTTP request path (such as
server.fs.allow) is not applied to this WebSocket-based execution path.PoC
Start the dev server on the target
Example (used during validation with this repository):
pnpm -C playground/alias exec vite --host 0.0.0.0 --port 5173Confirm that access is blocked via the HTTP path (example: arbitrary file)
curl -i 'http://localhost:5173/@​fs/etc/passwd?raw'Result:

403 Restricted(outside the allow list)Confirm that the same file can be retrieved via the WebSocket path
By connecting to the HMR WebSocket without an
Originheader and sending avite:invokerequest that callsfetchModulewith afile://...URL and?raw, the file contents are returned as a JavaScript module.Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/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:
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:H/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: 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).
Release Notes
vitejs/vite (vite)
v7.3.5Compare Source
Please refer to CHANGELOG.md for details.
v7.3.3Compare Source
Please refer to CHANGELOG.md for details.
v7.3.2Compare Source
Please refer to CHANGELOG.md for details.
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR was generated by Mend Renovate. View the repository job log.