# vitest@5.0.3 security report (npm)

- Verdict: **Needs review** (risk level: medium)
- Scanned: 2026-10-06T14:25:30.000Z
- Files reviewed: 62
- Findings: 1 high, 18 medium, 35 low severity findings
- Report: https://security.togoder.click/npm/vitest
- Source: Togoder Security (https://security.togoder.click), AI source-code review

## Summary

Togoder Security scanned the npm package vitest@5.0.3 on Oct 6, 2026. An AI review of 62 source files produced 1 high, 18 medium, 35 low severity findings. The overall verdict is medium: the findings flag risky but common patterns (dynamic code, unsafe defaults, broad file or network access) rather than confirmed malware.

## Findings

### [high] Potential for code injection

Finding ID: `NPS-DFAD18D7CB40`

File: `dist/module-evaluator.js`

The module constructs code strings and executes them with vm.runInThisContext. The code string includes user-supplied module code and argument names/values. If an attacker can inject malicious code into the module code or argument values, it could lead to arbitrary code execution.

### [medium] Dynamic code execution

Finding ID: `NPS-9EBC4121E70B`

File: `dist/chunks/base.DhkQeZwd.js:153`

Uses runInThisContext from node:vm to execute serialized `defines` configuration directly in the current context. While intended for loading build-time defines in Vitest, this pattern is inherently risky as it executes arbitrary strings from user configuration.

### [medium] Dynamic import with computed module specifier

Finding ID: `NPS-2DE5F26FF717`

File: `dist/chunks/coverage._yXj5zeb.js:20`

The code performs dynamic imports using a value derived from options.customProviderModule (loader.import(options.customProviderModule)) and a built-in module name constructed from the provider string. While this is typical for a test coverage tool, it allows loading arbitrary modules based on configuration, which could be abused if an attacker controls the configuration. This is a low-to-medium risk pattern since it is a legitimate feature but introduces a dynamic code loading surface.

### [medium] Global namespace pollution

Finding ID: `NPS-0946A79A91C0`

File: `dist/chunks/globals.9QtHn8Sr.js:19`

The code assigns properties to globalThis from the imported index module for each API name in globalApis. This modifies the global scope of any application that imports this file, which can cause unexpected side effects, conflicts, or security issues if the assigned values are not carefully controlled. While likely intended for testing frameworks like Vitest, it represents a risky side effect at import time.

### [medium] Dynamic code execution via module runner

Finding ID: `NPS-F3368816E17E`

File: `dist/chunks/init.D0qF-GGk.js:21`

The ModuleRunner from vite/module-runner is used to execute fetched module code. fetchModule retrieves code via RPC and it is evaluated. This is core Vitest functionality (test execution) but represents dynamic code evaluation from external sources.

### [medium] Dynamic module loading with computed input

Finding ID: `NPS-A6157EF268B6`

File: `dist/chunks/init.D0qF-GGk.js:68`

The loadEnvironment and loadNativeEnvironment functions dynamically import modules based on environment name derived from configuration. import.meta.resolve(`vitest-environment-${name}`) and loader.import(packageId) are used with user-controlled environment names, which could load arbitrary modules if an attacker controls the environment configuration.

### [medium] Debugging/inspector session initiation

Finding ID: `NPS-E0D3D3EE0E1D`

File: `dist/chunks/inspector.CvyFGlXm.js:10`

The code opens an inspector session and connects to it, enabling debugging. If an attacker can control the configuration (port, host), they could potentially expose a debugging interface to the network. The inspector.open() call uses config.inspector.port and config.inspector.host, which could be set to expose the inspector on all interfaces.

### [medium] Dynamic import with computed input

Finding ID: `NPS-36F6D2E47B4A`

File: `dist/chunks/nativeModuleRunner.jwZPY3dg.js:1490`

The NativeModuleRunner.import() method dynamically imports a module resolved from arbitrary moduleId input at runtime. While this is typical for Vite/Vitest module runners, it allows importing any module on the filesystem, which could be abused if the moduleId is attacker-controlled.

### [medium] Dynamic imports with external input

Finding ID: `NPS-67A1359B1EF1`

File: `dist/chunks/setup-common.BglbuAHD.js`

loadDiffConfig and loadSnapshotSerializers dynamically import paths taken from configuration (config.diff and config.snapshotSerializers). If an attacker can control the config, they may load arbitrary modules, potentially executing malicious code.

### [medium] Dynamic global pollution

Finding ID: `NPS-C82E95B04401`

File: `dist/chunks/setup-common.BglbuAHD.js:12`

setupDefines iterates over config.defines and assigns arbitrary keys directly onto globalThis. If config is influenced by untrusted input, this could overwrite global objects (e.g. globalThis.fetch, globalThis.process) and enable runtime tampering.

### [medium] Dynamic code execution

Finding ID: `NPS-F2994C111432`

File: `dist/chunks/vm.vTyZj_02.js`

Heavy use of vm.Script, vm.SourceTextModule, vm.SyntheticModule, runInContext, and WebAssembly compilation. Unlike eval/Function, this is the intended architecture of Vitest's VM test pool, but it still executes untrusted code in a sandboxed context and warrants scrutiny.

### [medium] Network module loading

Finding ID: `NPS-EFD4C0087212`

File: `dist/chunks/vm.vTyZj_02.js`

createNetworkModule fetches remote modules via fetch() for http/https URLs, with an IP-based restriction allowing only localhost/::1 and 127.0.0.0/8. This enables remote code loading when --experimental-network-imports is enabled.

### [medium] File system access

Finding ID: `NPS-80026DAB198B`

File: `dist/chunks/vm.vTyZj_02.js`

FileMap reads arbitrary files via fs.readFile/readBuffer/readFileSync and caches contents. This is required for module loading but means the executor can read any path it is pointed at, including outside the package.

### [medium] Dynamic require resolution

Finding ID: `NPS-B6C1E2874508`

File: `dist/chunks/vm.vTyZj_02.js`

CommonjsExecutor.createRequire resolves and loads arbitrary specifiers, including native .node bindings and builtins, from module-supplied identifiers. Standard for a CJS runtime but a significant trust boundary.

### [medium] Dynamic code execution

Finding ID: `NPS-D30CB5762D6E`

File: `dist/module-evaluator.js`

The module uses vm.runInThisContext and vm.Script to compile and execute dynamically constructed code. The wrappedCode string is built by concatenating module code with a function wrapper, and then executed. This is core to Vitest's module evaluator, but if an attacker can influence the module code or options, it could lead to arbitrary code execution.

### [medium] Environment variable access

Finding ID: `NPS-F733F94DE461`

File: `dist/module-evaluator.js`

createImportMetaEnvProxy returns a Proxy around process.env, allowing access to and modification of environment variables. This could be used to harvest credentials if the module is executed in a context where sensitive environment variables are present.

### [medium] Dynamic module loading

Finding ID: `NPS-BDDD7EF209B2`

File: `dist/module-evaluator.js`

The module uses createRequire to create a require function that can load arbitrary modules based on the current module's URL. This could be exploited to load malicious modules if an attacker can control the module's URL or the imported IDs.

### [medium] Dynamic import with computed path

Finding ID: `NPS-8055E805BEBE`

File: `dist/traces.js:30`

The constructor dynamically imports a module using `options.sdkPath` which is an externally controllable value. This allows loading arbitrary code from an arbitrary path when the class is instantiated with a malicious `sdkPath`, potentially leading to code execution if an attacker can influence the options object (e.g., through configuration injection).

### [medium] Monkey-patching global process.emit

Finding ID: `NPS-D7B39CB3B673`

File: `suppress-warnings.cjs:14`

The code overrides the global process.emit function, which is a core Node.js EventEmitter method. While the current implementation only filters specific warning messages, this technique alters runtime behavior globally and could mask important warnings or be repurposed by malicious actors to hide other activities.

### [low] import-time exception

Finding ID: `NPS-ED0AC9A337D9`

File: `browser/context.js:9`

The module throws an error at import time to enforce that it is only imported within Vitest's Browser Mode. This is intentional, expected behavior for this Vitest virtual module shim, not malicious. No data exfiltration, credential harvesting, obfuscation, dynamic execution, network requests, file system manipulation, or process spawning is present.

### [low] Module system extension manipulation

Finding ID: `NPS-86A5C351858A`

File: `dist/chunks/base.DhkQeZwd.js:27`

Overrides createRequire's _require.extensions for .css, .scss, .sass, .less files and all KNOWN_ASSET_TYPES, altering Node.js module resolution behavior. This is a legitimate Vitest feature for handling Vite-specific assets, but modifying require.extensions is a deprecated and potentially risky mechanism.

### [low] Dynamic imports with computed paths

Finding ID: `NPS-72C5BE47E62C`

File: `dist/chunks/base.DhkQeZwd.js:47`

Multiple dynamic imports of internal chunk files (e.g., './console.RBA5x-0t.js', './nativeModuleMocker.CXSh3m91.js', './nativeModuleRunner.jwZPY3dg.js', './native.CBlba4VV.js') using relative paths. These are standard lazy-loading patterns within the package bundle, but dynamic module loading is a general code smell to monitor.

### [low] process.exit override

Finding ID: `NPS-F3256FF469C8`

File: `dist/chunks/base.DhkQeZwd.js:128`

Replaces process.exit with a function that throws an Error instead of terminating the process. While this is an intentional testing safeguard in Vitest to catch unexpected exit calls, overriding a core process API could have unintended side effects in some environments.

### [low] Dynamic import of built-in coverage provider

Finding ID: `NPS-4B1B46F8D8AA`

File: `dist/chunks/coverage._yXj5zeb.js:17`

The code imports @vitest/coverage-v8 or @vitest/coverage-istanbul (or their /browser variants) dynamically. These are expected dependencies for Vitest coverage, but the use of /* @vite-ignore */ suggests the import is intentionally hidden from static analysis, which could be a minor red flag in a malicious context. Here it appears to be a legitimate bundler directive.

### [low] File system manipulation outside package scope

Finding ID: `NPS-AD1E6476C056`

File: `dist/chunks/creator.203NYCo3.js:156`

The code writes files to the current working directory (process.cwd()) including creating a 'vitest-example' folder, generating config files like 'vitest.config.ts', and modifying 'package.json'. While this is expected behavior for a scaffolding/setup tool (this is Vitest's browser testing setup wizard), it does modify files outside the package's own scope.

### [low] Package installation

Finding ID: `NPS-B3862329A736`

File: `dist/chunks/creator.203NYCo3.js:371`

The code dynamically installs packages (vitest browser providers, framework plugins) using installPackage with the detected package manager. This is expected for a setup wizard but represents dynamic dependency installation.

### [low] Reading package.json and dependencies

Finding ID: `NPS-7BEC2B5F00B6`

File: `dist/chunks/creator.203NYCo3.js:386`

The code reads the local package.json to detect existing dependencies and infer defaults. This is standard practice for scaffolding tools and stays within the project directory.

### [low] Spawning processes or shell commands

Finding ID: `NPS-62DD55B8B0B7`

File: `dist/chunks/creator.203NYCo3.js:509`

The code uses 'tinyexec' (x) to spawn external commands, specifically running package manager commands (npx/yarn/pnpm/bunx) to install Playwright browsers via 'playwright install --with-deps'. This is legitimate behavior for a test setup tool, but it does execute external processes based on detected package manager.

### [low] Dynamic import with computed path

Finding ID: `NPS-C157B9752B13`

File: `dist/chunks/doctor.CpHPRoza.js:168`

The code uses `import.meta.resolve('happy-dom')` and dynamic `await import('./cli-api.C4x4GGip.js')`. The dynamic import of cli-api is via a static relative path, and resolve of happy-dom is a peer dependency check. No external input controls module resolution, but dynamic imports should be reviewed.

### [low] Temporary file creation outside package scope

Finding ID: `NPS-C6E05A779531`

File: `dist/chunks/doctor.CpHPRoza.js:199`

The module creates a temp directory via `mkdtempSync(join(tmpdir(), 'vitest-doctor-'))` and writes a runner script into it. The temp dir is cleaned up on exit. This is standard temporary file usage, but it writes executable JavaScript outside the package's own directory.

### [low] Process spawning and dynamic code generation

Finding ID: `NPS-F069F413F0D5`

File: `dist/chunks/doctor.CpHPRoza.js:218`

The module spawns a child Node.js process using `spawn(process.execPath, [runnerPath, payload])` to run a dynamically generated runner script. The runner contents are created by `createRunnerScript()` and written to a temp directory. This is a legitimate benchmarking/doctor workflow for Vitest, but spawning processes and generating executable scripts at runtime is a sensitive pattern that warrants review.

### [low] Environment variable propagation to child processes

Finding ID: `NPS-0A42AF98E00E`

File: `dist/chunks/doctor.CpHPRoza.js:228`

Child processes inherit `process.env` via `env: { ...process.env, NO_COLOR: '1' }`. This passes all environment variables (including any credentials present in the environment) to spawned processes. While standard for spawning test runners, it is a broad environment propagation.

### [low] Process Spawning

Finding ID: `NPS-0B31618B1C92`

File: `dist/chunks/index.DXQx-kDM.js`

The code uses `x` from `tinyexec` to spawn package manager commands (npm, yarn, pnpm, etc.) for installing/uninstalling packages. This is expected functionality for a package manager detection and installation utility, not malicious. Commands are constructed from predefined agent names and user-supplied package names, with no shell injection vectors.

### [low] File System Access

Finding ID: `NPS-B14264E912C9`

File: `dist/chunks/index.DXQx-kDM.js`

Reads package.json files and checks for lockfiles to detect package managers. This is normal operation for the stated purpose of the package and stays within project directories.

### [low] File system read outside package scope

Finding ID: `NPS-A05C545A6CDD`

File: `dist/chunks/init.D0qF-GGk.js:28`

readFileSync(result.tmp, 'utf-8') reads files from temporary paths provided by the RPC transport. While this is part of Vitest's normal module loading mechanism, it reads arbitrary files from disk based on external RPC responses.

### [low] Process signal/error handlers

Finding ID: `NPS-C75511839DFE`

File: `dist/chunks/init.D0qF-GGk.js:106`

listenForErrors registers process-level handlers for uncaughtException and unhandledRejection. This is standard error handling but intercepts process-level errors.

### [low] Environment variable manipulation

Finding ID: `NPS-647C0B62A321`

File: `dist/chunks/init.D0qF-GGk.js:233`

createImportMetaEnvProxy creates a Proxy over process.env that allows reading and writing environment variables. process.env.VITEST_POOL_ID, VITEST_WORKER_ID are set from message context. This is expected behavior for a test runner but provides a mechanism to modify environment variables.

### [low] Module loading with computed input

Finding ID: `NPS-F23895D18ED6`

File: `dist/chunks/inspector.CvyFGlXm.js:7`

The code uses createRequire to load the 'node:inspector' module dynamically. While this is a legitimate Node.js API for loading built-in modules, it represents dynamic module loading that could be abused if the input were controllable. In this case, the module name is hardcoded, so it's not directly exploitable.

### [low] Breakpoint setting via inspector

Finding ID: `NPS-D386C9D45298`

File: `dist/chunks/inspector.CvyFGlXm.js:16`

The code sets a breakpoint in the first test file using the inspector session. While this is intended for debugging test files, if the file path is controllable, it could potentially be used to inject or manipulate debugging behavior. However, this is a legitimate debugging feature.

### [low] Inspector cleanup logic

Finding ID: `NPS-E156F0BD9D97`

File: `dist/chunks/inspector.CvyFGlXm.js:22`

The cleanup function closes the inspector and disconnects the session based on configuration. This is standard cleanup behavior and not inherently malicious.

### [low] Dynamic code execution / module loading

Finding ID: `NPS-897063050A2B`

File: `dist/chunks/native.CBlba4VV.js:22`

Uses Node.js module.registerHooks and module.register APIs to intercept module resolution and loading. This is a legitimate testing framework feature (Vitest) for module mocking and in-source testing, not obfuscated or malicious dynamic execution.

### [low] Worker thread communication

Finding ID: `NPS-826884D48686`

File: `dist/chunks/native.CBlba4VV.js:66`

Establishes a MessageChannel for RPC with the main worker process to track module graph entries. This is standard inter-process communication for a test runner, not exfiltration.

### [low] Code transformation at import time

Finding ID: `NPS-8CA21EF24A1F`

File: `dist/chunks/native.CBlba4VV.js:124`

Performs AST-based code transformations (hoistMocks, replaceInSourceMarker) on loaded modules to support mocking and in-source testing. This is expected behavior for a test runner and operates only on modules within the project scope.

### [low] File system access outside package scope

Finding ID: `NPS-F8C5B05A9E76`

File: `dist/chunks/nativeModuleRunner.jwZPY3dg.js`

The code performs extensive filesystem reads and path resolution (readFileSync, statSync, realpathSync) on paths derived from package.json resolution logic, walking up parent directories via './node_modules/' and '../package.json'. This is standard Node module resolution but accesses files beyond the package's own directory.

### [low] Module resolution using external input

Finding ID: `NPS-B3E18900850C`

File: `dist/chunks/nativeModuleRunner.jwZPY3dg.js:1390`

resolveModule/resolveSync resolves module names using createRequire and custom resolver logic based on user/options input, potentially resolving arbitrary packages from paths specified in options.paths.

### [low] Global object mutation

Finding ID: `NPS-7428D6D26063`

File: `dist/chunks/nativeModuleRunner.jwZPY3dg.js:1483`

The constructor conditionally defines a writable global property '__vitest_mocker__' on globalThis via Object.defineProperty when a mocker is provided. This is intentional for Vitest integration but mutates the global namespace.

### [low] Import-time global state mutation

Finding ID: `NPS-ADEF52791BEC`

File: `dist/chunks/setup-common.BglbuAHD.js:5`

setupCommonEnv is called and mutates global state (globalSetup, setSafeTimers, registerApiGlobally, globalThis assignments). This top-level side effect can affect the entire runtime and, combined with globals registration, exposes APIs globally unless explicitly intended.

### [low] Environment variable access

Finding ID: `NPS-3D973E3BC3A8`

File: `dist/chunks/vm.vTyZj_02.js`

Reads process.env.NODE_OPTIONS and process.execArgv to determine CJS resolution conditions and network-import support. Legitimate Node runtime behavior, but NODE_OPTIONS parsing could theoretically be influenced by an attacker-controlled environment.

### [low] V8 flag manipulation

Finding ID: `NPS-8D8E410CE90B`

File: `dist/chunks/vm.vTyZj_02.js`

Calls v8.setFlagsFromString('--no-compilation-cache') to reduce memory retention. Modifying V8 flags at runtime can affect the entire isolate, though this call is benign and clearly documented.

### [low] Top-level code execution

Finding ID: `NPS-2B8B6F12C18B`

File: `dist/nodejs-worker-loader.js:7`

The file executes top-level code on import, including regex generation and initialization of constants. This is typical for loader hooks but still represents import-time execution.

### [low] Dynamic module loading with computed input

Finding ID: `NPS-619C4ED6E361`

File: `dist/nodejs-worker-loader.js:10`

The resolve hook manipulates module specifiers based on patterns like '%3Fvitest=' and '?mock=actual', dynamically rewriting import URLs. While this appears to be part of Vitest's mocking system, the dynamic rewriting of module URLs based on string manipulation could potentially be abused if input is not properly validated.

### [low] Inter-process communication

Finding ID: `NPS-13F537A76815`

File: `dist/nodejs-worker-loader.js:35`

The code uses port.postMessage to send module resolution data back to the parent process. This is expected behavior for a worker loader but involves IPC communication.

### [low] Import-time side effects

Finding ID: `NPS-4BE21E81FD2D`

File: `dist/traces.js:7`

The file initializes a class with top-level property initializers that call `createNoopSpan()` and `createNoopContext()`, and records a start time with `performance.now()`. While this is not inherently malicious, the class is designed to be imported and instantiated, and the dynamic import of OpenTelemetry and custom SDK occurs when an instance is created with `enabled: true`. This could lead to unexpected network or file system activity depending on the imported SDK.

### [low] Suppression of runtime warnings

Finding ID: `NPS-2489BA7C9962`

File: `suppress-warnings.cjs:15`

The code suppresses specific experimental feature warnings by intercepting the 'warning' event. Although the warnings themselves are benign, deliberately silencing them may reduce visibility into potential issues and is often seen in malicious packages attempting to avoid detection.

## Files reviewed

- `dist/chunks/base.DhkQeZwd.js` (medium): This appears to be a legitimate, minified/bundled Vitest internal chunk file containing test-runner runtime logic; no clear malicious patterns were found, though it does use dynamic code execution and module system manipulation in ways typical of the Vitest framework.
- `dist/chunks/coverage._yXj5zeb.js` (medium): The code is part of Vitest's coverage provider resolution and contains only expected dynamic module loading for coverage providers; no clear malicious patterns were found, but dynamic imports based on configuration warrant low-to-medium caution.
- `dist/chunks/creator.203NYCo3.js` (medium): This is a legitimate Vitest browser testing setup wizard that scaffolds config files and installs packages; it contains no data exfiltration, credential harvesting, obfuscation, or backdoor patterns, though it does perform expected file writes and package installations.
- `dist/chunks/doctor.CpHPRoza.js` (medium): The code appears to be a legitimate Vitest 'doctor' performance benchmarking module that spawns child processes and creates temporary runner scripts; no clear malicious patterns such as data exfiltration, credential harvesting, or backdoors were detected, though process spawning and env propagation warrant caution.
- `dist/chunks/globals.9QtHn8Sr.js` (medium): No malicious patterns detected, but the code performs global namespace pollution on import, which could be exploited if the imported module is compromised.
- `dist/chunks/init.D0qF-GGk.js` (medium): This is legitimate Vitest worker initialization code with expected test-runner behaviors (dynamic module loading, RPC-based code fetching, env manipulation) but no clear malicious patterns such as exfiltration, credential theft, or backdoors.
- `dist/chunks/inspector.CvyFGlXm.js` (medium): The code appears to be a legitimate debugging utility for enabling the Node.js inspector in worker threads or child processes, with no clear malicious patterns, though it does expose debugging interfaces based on configuration.
- `dist/chunks/nativeModuleRunner.jwZPY3dg.js` (medium): This appears to be a legitimate Vite/Vitest native module runner implementing Node ESM resolution; no exfiltration, credential harvesting, obfuscation, shell execution, or backdoor patterns were detected, though it does perform dynamic imports and broad filesystem resolution typical of such tooling.
- `dist/chunks/setup-common.BglbuAHD.js` (medium): The module is mostly a test-framework setup helper, but it mutates globalThis from configuration, performs dynamic imports based on config-controlled paths, and registers globals at runtime, which could be abused if configuration is attacker-influenced.
- `dist/chunks/vm.vTyZj_02.js` (medium): Vitest's VM test-pool runtime with intentional sandboxed code execution, dynamic module loading, and runtime V8/env manipulation — no evidence of data exfiltration, credential harvesting, or backdoor behavior, but the aggressive sandbox/runtime capabilities make it a sensitive component.
- `dist/module-evaluator.js` (medium): The code is part of Vitest's module evaluator and uses dynamic code execution and environment variable access, which are legitimate for its purpose but could be risky if input is not properly sanitized.
- `dist/nodejs-worker-loader.js` (medium): This appears to be a legitimate Vitest node worker loader with expected dynamic module resolution behavior, though it does perform import-time execution and IPC communication.
- `dist/traces.js` (medium): The code contains a dynamic import of a user-controlled path which could load arbitrary code, but no other malicious patterns such as data exfiltration, credential harvesting, or backdoor installation were detected.
- `suppress-warnings.cjs` (medium): The file monkey-patches process.emit to suppress specific Node.js warnings, which is a code smell but not overtly malicious; however, such global interception could be abused and warrants caution.
- `browser/context.js` (safe): No malicious patterns detected; the top-level throw is an intentional guard for Vitest's browser module rather than a security concern.
- `dist/browser.js` (safe): No malicious patterns detected in the provided re-export barrel file; it only re-exports symbols from internal chunks and defines a harmless internal Set.
- `dist/chunks/cac.DfDGTQ9W.js` (safe): This is a legitimately bundled build artifact of Vitest's CLI (dist/chunks/cac.DfDGTQ9W.js) containing the CAC argument parser, Vitest CLI option definitions, and shell tab-completion generators; no malicious patterns such as data exfiltration, credential harvesting, obfuscated payloads, or backdoor code were detected.
- `dist/chunks/cli-api.C4x4GGip.js` (safe): No malicious patterns detected; the code is a legitimate part of the Vitest testing framework's CLI API.
- `dist/chunks/console.RBA5x-0t.js` (safe): No malicious patterns detected; the code is a legitimate Vitest custom console implementation with no exfiltration, credential harvesting, obfuscation, or process spawning.
- `dist/chunks/constants.-juJ8b_4.js` (safe): No malicious patterns detected
- `dist/chunks/coverage.S6Dao4g-.js` (safe): No malicious patterns detected; the code only provides standard coverage lifecycle helpers that delegate to a resolved provider module.
- `dist/chunks/defaults.D2ip7f-X.js` (safe): No malicious patterns detected; the code contains standard Vitest configuration defaults and benign environment checks.
- `dist/chunks/display.CXBnkt9a.js` (safe): No malicious patterns detected; the code is a standard object serialization/formatting utility with no network, filesystem, process, or dynamic execution behavior.
- `dist/chunks/env.DzFJjrmK.js` (safe): No malicious patterns detected; the code only performs innocuous environment detection for CI, TTY, and platform flags.
- `dist/chunks/index.DXQx-kDM.js` (safe): The code is a legitimate package manager detection and installation utility with no malicious patterns such as exfiltration, credential harvesting, obfuscation, or backdoors.
- `dist/chunks/index.DmDMHCg8.js` (safe): No malicious patterns detected; the code implements a legitimate bi-directional RPC (birpc) library with standard ID generation and message handling.
- `dist/chunks/index.cx-_w29y.js` (safe): No malicious patterns detected; the code is a pretty-format library implementation for object serialization and React/DOM introspection with no exfiltration, credential harvesting, dynamic execution, or network/process activity.
- `dist/chunks/index.ggMXe2IF.js` (safe): No malicious patterns detected; the code is a legitimate Vitest testing utility for async leak detection and test runner resolution.
- `dist/chunks/index.k8L_ZRzq.js` (safe): The analyzed file is a legitimate Vitest environment and module-runner implementation containing expected dynamic imports, VM contexts, and test-mocking logic, with no evidence of malicious data exfiltration, credential harvesting, obfuscation, backdoors, or process spawning.
- `dist/chunks/init-forks.hzLs7kMZ.js` (safe): This file is part of Vitest's worker initialization logic and contains no malicious patterns; it only handles inter-process communication and process event listeners.
- `dist/chunks/init-threads.COb0VD5D.js` (safe): This worker thread initialization module contains no malicious patterns; it simply sets up message passing for a test runner framework.
- `dist/chunks/modules.BJuCwlRJ.js` (safe): No malicious patterns detected
- `dist/chunks/native.CBlba4VV.js` (safe): This is a legitimate Vitest internal module loader hook implementation with no malicious patterns; all dynamic module loading and code transformation is scoped to test execution and project files.
- `dist/chunks/nativeModuleMocker.CXSh3m91.js` (safe): No malicious patterns detected; the code is a legitimate Vitest module mocking utility with no data exfiltration, credential harvesting, obfuscation, or unauthorized process/file system access.
- `dist/chunks/node.BzimPqT5.js` (safe): No malicious patterns detected; the code is a legitimate Vitest snapshot environment implementation with standard filesystem operations scoped to snapshot files.
- `dist/chunks/offset.Dy-5Fdfn.js` (safe): No malicious patterns detected
- `dist/chunks/pathe.M-eThtNZ.CknpM8Or.js` (safe): No malicious patterns detected; the code consists of path utility functions and constants commonly used in build tooling.
- `dist/chunks/plugins.D2ut1V9b.js` (safe): No malicious patterns detected; the code is a benign serialization plugin for Vitest mock functions.
- `dist/chunks/resolver.fbW9AUvG.js` (safe): The code only implements package scope type resolution by reading package.json files, with no network, credential, or process-spawning behavior.
- `dist/chunks/rpc.BTmCtPly.js` (safe): No malicious patterns detected; the code is legitimate Vitest internal RPC and module evaluation logic without exfiltration, obfuscation, or unauthorized system access.
- `dist/chunks/source-map.DUxvo12T.js` (safe): No malicious patterns detected; this is a legitimate source-map/trace-mapping utility bundle from Vitest with no data exfiltration, dynamic execution, or install-time hooks.
- `dist/chunks/spy.DgMTfhrK.js` (safe): This is a legitimate Vitest mocking library chunk implementing spy/mock functionality with no malicious patterns such as data exfiltration, credential harvesting, obfuscation, or unauthorized network/file/process operations.
- `dist/chunks/tinyrainbow.Ht9iggcq.js` (safe): No malicious patterns detected; the code is a standard ANSI color styling library (tinyrainbow) with only environment variable reads for color support detection and no network, filesystem, or process execution behavior.
- `dist/chunks/utils.DYj33du9.js` (safe): No malicious patterns detected; code is standard Vitest worker state management and module resetting logic.
- `dist/chunks/utils.RcGwuOc_.js` (safe): This file is a benign utility module for formatting test runner output, with no network, filesystem, process, or dynamic code execution activity.
- `dist/cli.js` (safe): No malicious patterns detected
- `dist/config.cjs` (safe): No malicious patterns detected; the file contains standard Vitest configuration defaults and helper exports with no data exfiltration, credential harvesting, obfuscation, or process spawning.
- `dist/config.js` (safe): No malicious patterns detected
- `dist/index.js` (safe): The file is a standard Vitest package entry point with only static re-exports and no suspicious or malicious patterns.
- `dist/node.js` (safe): No malicious patterns detected
- `dist/path.js` (safe): No malicious patterns detected; the code only resolves directory paths using Node.js built-in modules and runs no external commands or network operations.
- `dist/runtime.js` (safe): No malicious patterns detected
- `dist/spy.js` (safe): The file is a simple re-export statement from a local chunk, containing no executable code or malicious patterns.
- `dist/task-utils.js` (safe): No malicious patterns detected; this is legitimate Vitest test utility code for task/suite traversal and filtering.
- `dist/worker.js` (safe): This file only contains ECMAScript module re-exports and imports of built-in Node.js modules and internal Vitest chunks, with no dynamic code execution, network calls, filesystem access, or other malicious patterns.
- `dist/workers/forks.js` (safe): No malicious patterns detected; the file is a standard Vitest worker fork bootstrap that imports internal chunks and initializes test workers.
- `dist/workers/runVmTests.js` (safe): No malicious patterns detected
- `dist/workers/threads.js` (safe): No malicious patterns detected; the file is a benign Vitest worker entry point that imports testing utilities and initializes worker execution.
- `dist/workers/vmForks.js` (safe): The file is a standard Vitest worker entry point that imports internal chunks and calls workerInit, with no malicious patterns detected.
- `dist/workers/vmThreads.js` (safe): The file is a legitimate Vitest worker entry point that imports internal modules and initializes VM test workers without any malicious patterns.
- `index.cjs` (safe): No malicious patterns detected
- `vitest.mjs` (safe): No malicious patterns detected

AI analysis is guidance, not a guarantee. Methodology: https://security.togoder.click/methodology