<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-27T01:05:07.445873+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-112948</id>
    <title>fkie_cve-2026-112948</title>
    <updated>2026-10-27T01:05:07.466995+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-112948"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-p458-7748-mcp3</id>
    <title>GHSA-p458-7748-mcp3 — Vitest: Servers misapply `server.fs.deny`, serving `.env`, private keys, `.git`, and the API token file</title>
    <updated>2026-10-27T01:05:07.467084+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> npm: @vitest/ui, npm: @vitest/browser, npm: vite-plus</p>
<p>### Summary</p>
<p>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.</p>
<p>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`.</p>
<p>### Details</p>
<p>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.</p>
<p>| setup                              | listening server                | Vite's default deny list | `.vitest-secre…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-p458-7748-mcp3"/>
  </entry>
</feed>
