Vulnerability-Lookup

GHSA-P458-7748-MCP3

Vulnerability from github – Published: 2026-10-21 19:57 – Updated: 2026-10-21 19:57

Summary

Vitest: Servers misapply `server.fs.deny`, serving `.env`, private keys, `.git`, and the API token file

Details

Summary

In Vitest 5, Vite's server.fs.deny is not applied as intended on Vitest's dev servers. Depending on the server, files that Vite refuses to serve by default (such as .env, private keys and certificates, .npmrc, and .git) or Vitest's own API token file (.vitest-secret-token) can be read over plain HTTP by a client that can reach the server. In Browser Mode with test.projects, a malicious website can also read .env values through the developer's browser.

This only applies when Vitest runs an HTTP server, which happens with the UI (--ui), Browser Mode, or api enabled. Plain vitest and vitest run don't listen on any port and are not affected. The fix ships in vitest, and @vitest/ui and @vitest/browser are listed because they are what enables the affected setups. Both pin vitest to the same version as a peer dependency, so upgrading either one also requires the patched vitest. Users who enable api without @vitest/ui or @vitest/browser are also affected and should upgrade vitest.

Details

Vitest 5 adds its API token file to server.fs.deny, but neither server ended up with the intended list. That's because of two Vite behaviors. Vite applies its default deny list only when server.fs.deny is unset, and it compiles the list into a matcher during config resolution, so later changes to the array have no effect.

setup	listening server	Vite's default deny list	`.vitest-secret-token`
plain `vitest` / `vitest run`	none	not reachable	not reachable
`--ui` or `api`	root	denied	served (fallback location only)
Browser Mode, single project	root (also the browser server)	denied	served (fallback location only)
Browser Mode with `test.projects`	each browser project's server	served	denied

Project servers set deny: ['.vitest-secret-token'] from a config() hook, which replaces Vite's defaults. A project server listens on a port in Browser Mode with test.projects, so in that setup a request like GET /.env?raw returns the file. A plain GET /.env is also served as text/javascript, so a malicious page can include it with <script src="http://localhost:<port>/.env">. A classic script include needs no CORS, and each dotenv line whose value is valid JavaScript (a quoted string, number, or boolean) runs as a global assignment the page can read. A syntax error anywhere in the file, such as a # comment, keeps the whole script from running. The same missing defaults also loosen Browser Mode's file-access checks for server.readFile/writeFile/removeFile, screenshots, and traces.
The root server adds the token entry after Vite has compiled the matcher, so the entry is never applied. The token file normally lives in the per-user data directory, which is outside server.fs.allow. When that directory can't be written, for example in a container whose user has no writable HOME, Vitest falls back to <workspaceRoot>/node_modules/.vitest/.vitest-secret-token, which the root server then serves. The token authenticates the UI, /__vitest_attachment__, and the API WebSocket, whose RPC can write and rerun test files when api.allowWrite/api.allowExec are enabled.

Impact

Information disclosure from the Vitest dev server, and with the token, privileged API access.

From a malicious website, in Browser Mode with test.projects: while the browser server runs, any page the developer visits can read .env values that are valid JavaScript, through a classic <script> include. This works when the file consists of KEY="value" lines. An unquoted value causes a runtime error that stops the script at that line, so only the lines before it leak. A syntax error anywhere in the file, such as a # comment line or an export prefix, prevents the script from running at all. Recent Chrome versions may ask for Local Network Access permission first. fetch and XHR reads from other websites are still blocked by Vite's default CORS policy, and Vite's Host check blocks DNS rebinding. That CORS policy does allow localhost origins, so a page served from another local dev server could read full files. The token file can't be read through a classic <script>, because a bare token isn't valid JavaScript.
With local access or developer-set network exposure (such as api.host or browser.api.host, port forwarding, or a published container port): full file contents are readable over plain HTTP, including the token file when it's in the fallback location.

Only the machine running Vitest is exposed, while it runs one of the setups above. Applications built or deployed from the project aren't affected.

The fix is in vitest <PATCHED>. Vitest 4 and earlier are unaffected. They don't persist an API token, and they don't override server.fs.deny.

Workaround

Set server.fs.deny explicitly in the root Vitest config, including Vite's default list for your Vite version and the token file. For Vite 8.3:

export default defineConfig({
  server: {
    fs: {
      deny: [
        '.env',
        '.env.*',
        '*.{crt,pem,key,p12,pfx,cer,der}',
        '.npmrc',
        '.yarnrc.yml',
        '**/.git/**',
        '.vitest-secret-token',
      ],
    },
  },
})

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@vitest/ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0-beta.6"
            },
            {
              "fixed": "5.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@vitest/browser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0-beta.6"
            },
            {
              "fixed": "5.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "vite-plus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0-rc.0"
            },
            {
              "fixed": "1.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-112948"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-552"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-21T19:57:00Z",
    "nvd_published_at": "2026-10-20T16:17:05Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nIn Vitest 5, Vite\u0027s `server.fs.deny` is not applied as intended on Vitest\u0027s dev servers. Depending on the server, files that Vite refuses to serve by default (such as `.env`, private keys and certificates, `.npmrc`, and `.git`) or Vitest\u0027s own API token file (`.vitest-secret-token`) can be read over plain HTTP by a client that can reach the server. In Browser Mode with `test.projects`, a malicious website can also read `.env` values through the developer\u0027s browser.\n\nThis only applies when Vitest runs an HTTP server, which happens with the UI (`--ui`), Browser Mode, or `api` enabled. Plain `vitest` and `vitest run` don\u0027t listen on any port and are not affected. The fix ships in `vitest`, and `@vitest/ui` and `@vitest/browser` are listed because they are what enables the affected setups. Both pin `vitest` to the same version as a peer dependency, so upgrading either one also requires the patched `vitest`. Users who enable `api` without `@vitest/ui` or `@vitest/browser` are also affected and should upgrade `vitest`.\n\n### Details\n\nVitest 5 adds its API token file to `server.fs.deny`, but neither server ended up with the intended list. That\u0027s because of two Vite behaviors. Vite applies its default deny list only when `server.fs.deny` is unset, and it compiles the list into a matcher during config resolution, so later changes to the array have no effect.\n\n| setup                              | listening server                | Vite\u0027s default deny list | `.vitest-secret-token`              |\n| ---------------------------------- | ------------------------------- | ------------------------ | ----------------------------------- |\n| plain `vitest` / `vitest run`      | none                            | not reachable            | not reachable                       |\n| `--ui` or `api`                    | root                            | denied                   | **served** (fallback location only) |\n| Browser Mode, single project       | root (also the browser server)  | denied                   | **served** (fallback location only) |\n| Browser Mode with `test.projects`  | each browser project\u0027s server   | **served**               | denied                              |\n\n- **Project servers** set `deny: [\u0027.vitest-secret-token\u0027]` from a `config()` hook, which replaces Vite\u0027s defaults. A project server listens on a port in Browser Mode with `test.projects`, so in that setup a request like `GET /.env?raw` returns the file. A plain `GET /.env` is also served as `text/javascript`, so a malicious page can include it with `\u003cscript src=\"http://localhost:\u003cport\u003e/.env\"\u003e`. A classic script include needs no CORS, and each dotenv line whose value is valid JavaScript (a quoted string, number, or boolean) runs as a global assignment the page can read. A syntax error anywhere in the file, such as a `#` comment, keeps the whole script from running. The same missing defaults also loosen Browser Mode\u0027s file-access checks for `server.readFile`/`writeFile`/`removeFile`, screenshots, and traces.\n- **The root server** adds the token entry after Vite has compiled the matcher, so the entry is never applied. The token file normally lives in the per-user data directory, which is outside `server.fs.allow`. When that directory can\u0027t be written, for example in a container whose user has no writable `HOME`, Vitest falls back to `\u003cworkspaceRoot\u003e/node_modules/.vitest/.vitest-secret-token`, which the root server then serves. The token authenticates the UI, `/__vitest_attachment__`, and the API WebSocket, whose RPC can write and rerun test files when `api.allowWrite`/`api.allowExec` are enabled.\n\n### Impact\n\nInformation disclosure from the Vitest dev server, and with the token, privileged API access.\n\n- **From a malicious website**, in Browser Mode with `test.projects`: while the browser server runs, any page the developer visits can read `.env` values that are valid JavaScript, through a classic `\u003cscript\u003e` include. This works when the file consists of `KEY=\"value\"` lines. An unquoted value causes a runtime error that stops the script at that line, so only the lines before it leak. A syntax error anywhere in the file, such as a `#` comment line or an `export` prefix, prevents the script from running at all. Recent Chrome versions may ask for Local Network Access permission first. `fetch` and XHR reads from other websites are still blocked by Vite\u0027s default CORS policy, and Vite\u0027s `Host` check blocks DNS rebinding. That CORS policy does allow localhost origins, so a page served from another local dev server could read full files. The token file can\u0027t be read through a classic `\u003cscript\u003e`, because a bare token isn\u0027t valid JavaScript.\n- **With local access or developer-set network exposure** (such as `api.host` or `browser.api.host`, port forwarding, or a published container port): full file contents are readable over plain HTTP, including the token file when it\u0027s in the fallback location.\n\nOnly the machine running Vitest is exposed, while it runs one of the setups above. Applications built or deployed from the project aren\u0027t affected.\n\nThe fix is in `vitest` `\u003cPATCHED\u003e`. Vitest 4 and earlier are unaffected. They don\u0027t persist an API token, and they don\u0027t override `server.fs.deny`.\n\n### Workaround\n\nSet `server.fs.deny` explicitly in the root Vitest config, including Vite\u0027s default list for your Vite version and the token file. For Vite 8.3:\n\n```ts\nexport default defineConfig({\n  server: {\n    fs: {\n      deny: [\n        \u0027.env\u0027,\n        \u0027.env.*\u0027,\n        \u0027*.{crt,pem,key,p12,pfx,cer,der}\u0027,\n        \u0027.npmrc\u0027,\n        \u0027.yarnrc.yml\u0027,\n        \u0027**/.git/**\u0027,\n        \u0027.vitest-secret-token\u0027,\n      ],\n    },\n  },\n})\n```",
  "id": "GHSA-p458-7748-mcp3",
  "modified": "2026-10-21T19:57:00Z",
  "published": "2026-10-21T19:57:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vitest-dev/vitest/security/advisories/GHSA-p458-7748-mcp3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-112948"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vitest-dev/vitest/pull/11578"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vitest-dev/vitest/commit/28dc1edfb6ba5a181fe208576989063795aeadb3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vitest-dev/vitest"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vitest-dev/vitest/releases/tag/v5.0.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vitest: Servers misapply `server.fs.deny`, serving `.env`, private keys, `.git`, and the API token file"
}

CVE-2026-112948 (GCVE-0-2026-112948)

Vulnerability from cvelistv5 – Published: 2026-10-20 15:15 – Updated: 2026-10-20 16:16

Title

Vitest: Servers misapply `server.fs.deny`, serving `.env`, private keys, `.git`, and the API token file

Summary

Vitest is a testing framework powered by Vite. From 5.0.0-beta.6 until 5.0.5, Vitest dev servers can misapply server.fs.deny because project servers replace Vite's defaults and the root server adds .vitest-secret-token after Vite compiles its matcher. An attacker who can reach an affected UI, Browser Mode, or API server can read denied project files or the fallback API token at node_modules/.vitest/.vitest-secret-token, and Browser Mode with test.projects can expose JavaScript-compatible .env values through a malicious website. This issue is fixed in version 5.0.5.

Severity

6.5 (Medium)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-10-20 16:16 UTC

CWE

CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
CWE-552 - Files or Directories Accessible to External Parties

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 7797 records in the last 180 days details

References

4 references

URL	Tags
https://github.com/vitest-dev/vitest/security/adv…	x_refsource_CONFIRM
https://github.com/vitest-dev/vitest/pull/11578	x_refsource_MISC
https://github.com/vitest-dev/vitest/commit/28dc1…	x_refsource_MISC
https://github.com/vitest-dev/vitest/releases/tag…	x_refsource_MISC

Impacted products

4 products

Vendor	Product	Version
vitest-dev	vitest	Affected: >= 5.0.0-beta.6, < 5.0.5
@vitest	browser	Affected: >= 5.0.0-beta.6, < 5.0.5
@vitest	ui	Affected: >= 5.0.0-beta.6, < 5.0.5
vitejs	vite-plus	Affected: >= 1.0.0-rc.0, < 1.3.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-112948",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-20T16:16:51.150771Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-20T16:16:59.623Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "vitest",
          "vendor": "vitest-dev",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 5.0.0-beta.6, \u003c 5.0.5"
            }
          ]
        },
        {
          "product": "browser",
          "vendor": "@vitest",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 5.0.0-beta.6, \u003c 5.0.5"
            }
          ]
        },
        {
          "product": "ui",
          "vendor": "@vitest",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 5.0.0-beta.6, \u003c 5.0.5"
            }
          ]
        },
        {
          "product": "vite-plus",
          "vendor": "vitejs",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 1.0.0-rc.0, \u003c 1.3.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Vitest is a testing framework powered by Vite. From 5.0.0-beta.6 until 5.0.5, Vitest dev servers can misapply server.fs.deny because project servers replace Vite\u0027s defaults and the root server adds .vitest-secret-token after Vite compiles its matcher. An attacker who can reach an affected UI, Browser Mode, or API server can read denied project files or the fallback API token at node_modules/.vitest/.vitest-secret-token, and Browser Mode with test.projects can expose JavaScript-compatible .env values through a malicious website. This issue is fixed in version 5.0.5."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-200",
              "description": "CWE-200: Exposure of Sensitive Information to an Unauthorized Actor",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-552",
              "description": "CWE-552: Files or Directories Accessible to External Parties",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-20T15:15:01.927Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/vitest-dev/vitest/security/advisories/GHSA-p458-7748-mcp3",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/vitest-dev/vitest/security/advisories/GHSA-p458-7748-mcp3"
        },
        {
          "name": "https://github.com/vitest-dev/vitest/pull/11578",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/vitest-dev/vitest/pull/11578"
        },
        {
          "name": "https://github.com/vitest-dev/vitest/commit/28dc1edfb6ba5a181fe208576989063795aeadb3",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/vitest-dev/vitest/commit/28dc1edfb6ba5a181fe208576989063795aeadb3"
        },
        {
          "name": "https://github.com/vitest-dev/vitest/releases/tag/v5.0.5",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/vitest-dev/vitest/releases/tag/v5.0.5"
        }
      ],
      "source": {
        "advisory": "GHSA-p458-7748-mcp3",
        "discovery": "UNKNOWN"
      },
      "title": "Vitest: Servers misapply `server.fs.deny`, serving `.env`, private keys, `.git`, and the API token file"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-112948",
    "datePublished": "2026-10-20T15:15:01.927Z",
    "dateReserved": "2026-10-19T21:30:47.245Z",
    "dateUpdated": "2026-10-20T16:16:59.623Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

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

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
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.

Action not permitted

GHSA-P458-7748-MCP3

Summary

Details

Impact

Workaround

CVE-2026-112948 (GCVE-0-2026-112948)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour