CodeVetter · Repo Unpack · Risk map
vitejs/vite
Vite's security model rests on four independent guards — the `server.fs` allow/deny list, WebSocket token authentication, host validation, and CORS origin restriction — and a bypass in any one of them exposes the developer's filesystem or dev server to a hostile web page. The code shows scar tissue from past CVEs: Windows 8.3 short-name detection, NTFS ADS colon rejection, `#`-in-URL rejection, and trailing-slash normalisation are all defensive patches with explanatory comments. Beyond security, the main structural risks are the very large monolithic modules (`css.ts` at 3685 lines, `config.ts` at 2961), the two-implementation split between classic dev and `bundledDev`, and a large surface of deprecated-but-live compatibility shims.
- `isFileLoadingAllowed` is the single chokepoint for filesystem access and carries three separate bypass mitigations: Windows 8.3 short-name paths (`PROGRA~1`, matched by `windowsShortNameSegmentRE`) are rejected outright, any `:` outside a drive letter is rejected as a possible NTFS alternate data stream, and trailing slashes are stripped before the deny check because `fs.readFile('/foo.png/')` resolves to `/foo.png`.
- `server.fs.deny` defaults to only six patterns — `.env`, `.env.*`, `*.{crt,pem,key,p12,pfx,cer,der}`, `.npmrc`, `.yarnrc.yml`, `**/.git/**` — so any other secret-bearing file inside an allowed root (e.g. `credentials.json`, `.aws/`, `id_rsa` without extension) is servable when `fs.strict` passes.
- `config.safeModulePaths` is an escape hatch checked *before* the `fs.allow` list in `isFileLoadingAllowed`, and it is populated at runtime by `DevEnvironment._registerInputsAsSafeModules()` — meaning build inputs silently widen the serving allow-list.
- `rejectInvalidRequestMiddleware` exists specifically because Node accepts `#` in request targets while the `server.fs.deny` checks assume it is absent — a 400 is returned for any URL containing `#`, and this middleware is the first in the chain.
- WebSocket auth uses a per-process 72-bit token compared with `crypto.timingSafeEqual`, but the token travels as a URL query parameter (`?token=...`), which the comment acknowledges may land in server/middleware logs.
- `config.legacy.skipWebSocketTokenCheck` is a live opt-out that disables token validation entirely inside `shouldHandle`, re-opening cross-site WebSocket hijacking for anyone who sets it.
- Host validation is skipped whenever `server.https` is configured (`if (allowedHosts !== true && !serverConfig.https)`), on the reasoning that HTTPS is not DNS-rebinding-vulnerable — so a misissued or self-signed HTTPS dev setup loses that guard.
- The WS upgrade path allows *any* non-browser client without a token: `shouldHandle` returns `true` when `req.headers.origin` is absent, with an inline comment justifying it for backward compat — meaning any local process that can open a socket can join the HMR channel.
- Shell-out surface exists in the dev server itself: `server/index.ts` imports `execSync` from `node:child_process`, and `openBrowser.ts` spawns a browser process honouring the `BROWSER`/`BROWSER_ARGS` environment variables which `loadEnv` will populate from a project's `.env` file.
- Config loading executes arbitrary project code by design through three paths (`bundleAndLoadConfigFile`, `runnerImportConfigFile`, `nativeImportConfigFile`), and `bundleConfigFile`/`loadConfigFromBundledFile` evaluate the bundled result — so opening an untrusted repo and running `vite` is code execution.
- Blast-radius hotspots by size: `plugins/css.ts` (3685 lines), `config.ts` (2961), `utils.ts` (2022), `build.ts` (1986), `plugins/html.ts` (1753), `server/index.ts` (1496), `server/pluginContainer.ts` (1332) — none of which has a same-named unit spec except `config.spec.ts`, `build.spec.ts` and `html.spec.ts`.
- The dev server now has two divergent implementations gated on one boolean: `config.experimental.bundledDev` swaps the entire serving strategy, skips `cachedTransformMiddleware`, skips `buildStart` at init, and short-circuits `handleHMRUpdate` with a `// TODO: support handleHotUpdate / hotUpdate` early return — so plugin HMR hooks silently do nothing in that mode.
- A large deprecated-but-live compatibility layer runs on every access: `server.hot`, `server.pluginContainer`, `server.moduleGraph`, `server.transformRequest`, `server.warmupRequest`, `server.ssrLoadModule`, `server.ssrFixStacktrace`, `server.ssrRewriteStacktrace` and `server.reloadModule` all route through `warnFutureDeprecation` and a `ModuleGraph` bridging facade.
- `vite optimize` is documented-dead in its own help string ('deprecated, the pre-bundle process runs automatically and does not need to be called') yet still resolves a full config and invokes `optimizeDeps(config, options.force, true)`.
- The preview server reuses `hostValidationMiddleware(allowedHosts, true)` and `sirv(distDir, ...)` but has a much shorter middleware chain than the dev server and no `fs.allow` equivalent, since it serves a fixed `distDir` root.
- `server.proxy`'s `rewriteWsOrigin` deliberately rewrites the browser-supplied `Origin` header on WebSocket upgrades, with an inline warning path when headers are already sent — a knob that defeats the target server's own origin checks if enabled carelessly.