https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 23:32:45 +0000 https://vulnerability.circl.lu/vuln/ghsa-p63j-vcc4-9vmv <p><strong>Affected:</strong> npm: @vitest/browser</p> <p>## Summary</p> <p>Browser Mode exposes a set of built-in &#34;commands&#34; that run on the Node.js side of the test runner and can touch the local filesystem (taking screenshots, managing Playwright traces, uploading files for `&lt;input type=&#34;file&#34;&gt;`, comparing screenshots).</p> <p>Several of these commands accept a file path from the browser and act on it without checking the `allowWrite` permission gate and without confining the path to the project directory. A client that can reach the Browser Mode API can therefore read, create, overwrite, or delete files anywhere the Vitest process can access, even when `allowWrite` is `false`.</p> <p>This matters most when the Browser Mode API is exposed to the network (for example `test.api.host` is set, or the dev server is reachable from another machine or origin). In that configuration `allowWrite` defaults to `false` precisely to block file access, and these commands bypass that protection. On a default localhost-only setup with trusted test code, there is no untrusted party in a position to exploit it. The gap still matters wherever you rely on `allowWrite: false` to contain untrusted test code, because these commands ignore that flag.</p> <p>## Affected commands and impact</p> <p>| Command | Operation | Impact | |---|---|---| | `upload` (Playwright + WebdriverIO) | Read | Arbitrary local file read; contents are loaded into the page and readable by test code. Highest-impact case. | | `takeScreenshot` (Playwright + WebdriverIO) | Write | Writes a PNG to an arbitrary pa…</p> <p><strong>Affected:</strong> npm: @vitest/browser</p> <p>## Summary</p> <p>Browser Mode exposes a set of built-in &#34;commands&#34; that run on the Node.js side of the test runner and can touch the local filesystem (taking screenshots, managing Playwright traces, uploading files for `&lt;input type=&#34;file&#34;&gt;`, comparing screenshots).</p> <p>Several of these commands accept a file path from the browser and act on it without checking the `allowWrite` permission gate and without confining the path to the project directory. A client that can reach the Browser Mode API can therefore read, create, overwrite, or delete files anywhere the Vitest process can access, even when `allowWrite` is `false`.</p> <p>This matters most when the Browser Mode API is exposed to the network (for example `test.api.host` is set, or the dev server is reachable from another machine or origin). In that configuration `allowWrite` defaults to `false` precisely to block file access, and these commands bypass that protection. On a default localhost-only setup with trusted test code, there is no untrusted party in a position to exploit it. The gap still matters wherever you rely on `allowWrite: false` to contain untrusted test code, because these commands ignore that flag.</p> <p>## Affected commands and impact</p> <p>| Command | Operation | Impact | |---|---|---| | `upload` (Playwright + WebdriverIO) | Read | Arbitrary local file read; contents are loaded into the page and readable by test code. Highest-impact case. | | `takeScreenshot` (Playwright + WebdriverIO) | Write | Writes a PNG to an arbitrary pa…</p> https://vulnerability.circl.lu/vuln/ghsa-p63j-vcc4-9vmv