Summary

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 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

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 accessible

The issue involves a security vulnerability in Vite where the server options can be bypassed using a double forward slash (//). This vulnerability poses a potential security risk as it can allow unauthorized access to sensitive directories and files.

Steps to Fix. Update Vite: Ensure that you are using the latest version of Vite. Security issues like this are often fixed in newer releases.\n2. Secure the server configuration: In your vite.config.js file, review and update the server configuration options to restrict access to unauthorized requests or directories.

Impact

Only users explicitly exposing the Vite dev server to the network (using --host or the server.host config option) are affected and only files in the immediate Vite project root folder could be exposed.\n\n### Patches\nFixed in vite@4.3.9, vite@4.2.3, vite@4.1.5, vite@4.0.5 and in the latest minors of the previous two majors, vite@3.2.7 and vite@2.9.16.

Details

Vite serves the application with under the root-path of the project while running on the dev mode. By default, Vite uses the server option fs.deny to protect sensitive files. But using a simple double forward-slash, we can bypass this restriction. \n\n### PoC\n1. Create a new latest project of Vite using any package manager. (here I'm using react and vue templates and pnpm for testing)\n2. Serve the application on dev mode using pnpm run dev.\n3. Directly access the file via url using double forward-slash (//) (e.g: //.env, //.env.local)\n4. The server option fs.deny was successfully bypassed.

Proof Images: \n