chore(deps): update dependency vite to v8.0.16 [security]#337
chore(deps): update dependency vite to v8.0.16 [security]#337renovate[bot] wants to merge 1 commit into
Conversation
|
📝 WalkthroughWalkthroughThe ChangesVite Dependency Update
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~1 minute Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
View your CI Pipeline Execution ↗ for commit 6e83811 ☁️ Nx Cloud last updated this comment at |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@examples/lit/simple/package.json`:
- Line 16: The package.json file in examples/lit/simple has been updated to
specify Vite version `^8.0.0`, but the pnpm-lock.yaml file has not been
regenerated to reflect this change, causing a manifest/lockfile mismatch that
prevents installations with frozen lockfile mode. To fix this, regenerate the
lockfile by running `pnpm install` (without the `--frozen-lockfile` flag) at the
repository root to update pnpm-lock.yaml with the resolved Vite 8.0.x version
for the examples/lit/simple package.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: dc7cfd57-7189-44f7-8bd1-91e39359b868
📒 Files selected for processing (1)
examples/lit/simple/package.json
| }, | ||
| "devDependencies": { | ||
| "vite": "^7.2.2" | ||
| "vite": "^8.0.0" |
There was a problem hiding this comment.
Critical: pnpm-lock.yaml not updated to match the Vite version bump.
The package.json specifier has been updated to ^8.0.0, but the pnpm-lock.yaml file still pins the example to vite@^7.2.2 (resolved to 7.3.2). This creates a manifest/lockfile mismatch that blocks all pnpm install --frozen-lockfile operations—as confirmed by 6 failed CI/CD pipelines and the autofix.ci run.
Result: The security update has zero practical effect. The dependency will not resolve to Vite 8 until the lockfile is regenerated, leaving CVE-2026-53571 and CVE-2026-53632 unpatched.
Action required: Regenerate the lockfile by running pnpm install (without --frozen-lockfile) at the repository root to update pnpm-lock.yaml with the new Vite 8.0.x resolution for the examples/lit/simple importer.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@examples/lit/simple/package.json` at line 16, The package.json file in
examples/lit/simple has been updated to specify Vite version `^8.0.0`, but the
pnpm-lock.yaml file has not been regenerated to reflect this change, causing a
manifest/lockfile mismatch that prevents installations with frozen lockfile
mode. To fix this, regenerate the lockfile by running `pnpm install` (without
the `--frozen-lockfile` flag) at the repository root to update pnpm-lock.yaml
with the resolved Vite 8.0.x version for the examples/lit/simple package.
This PR contains the following updates:
8.0.13→8.0.16^7.2.2→^8.0.0vite:
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)
v8.0.16Compare Source
Bug Fixes
v8.0.15Compare Source
Features
Bug Fixes
Miscellaneous Chores
Code Refactoring
collectAllModulesfunction (#22562) (6978a9c)v8.0.14Compare Source
Features
Bug Fixes
Miscellaneous Chores
Code Refactoring
Tests
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, 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.