CVE-2026-112946: Vite: Files outside `server.fs.allow` could be served when project paths match system paths on non-Windows machine

Published Oct 20, 2026
·
Updated

Summary

The content of files outside server.fs setting can be returned to the browser if the project imports a file path concatenated with the root. For example, if the project references <path-to-project-root>/etc/hosts, the content of /etc/hosts was possible to be returned.

The content of files outside the server.fs.allow option can be returned to the browser when a project imports a file whose root-relative path matches an absolute path on the host. For example, referencing <project-root>/etc/hosts could make Vite return the host's /etc/hosts file.

Impact

Only apps that meet all of the following conditions are affected:

- explicitly expose the Vite dev server to the network (using --host or the server.host option) - contain an imported file whose root-relative browser URL is also the absolute path of a readable file on the host - The sensitive file is not matched by server.fs.deny - the dev server is not running on Windows

Details

When Vite analyzes an in-root import, it rewrites the resolved module ID to a browser URL such as /etc/hostname. In affected versions, Vite converts that URL with fsPathFromUrl and adds the result to safeModulePaths. Because fsPathFromUrl ensures a leading slash without resolving the URL against the project root, the project URL /etc/hostname is recorded as if it were the absolute filesystem path /etc/hostname.

For a later request to /@fs/etc/hostname, the raw-filesystem middleware interprets /etc/hostname as an absolute path. The access check applies server.fs.deny, then accepts paths present in safeModulePaths before checking server.fs.allow. As a result, the request can return the host file instead of the project file that originally populated safeModulePaths.

PoC The following example requires Linux with a readable /etc/hostname: bash $ mkdir vite-safe-module-path-poc $ cd vite-safe-module-path-poc $ npm init -y $ npm install vite@8.3.1 $ mkdir -p etc $ echo 'PROJECT-DECOY\n' > etc/hostname $ echo 'import "./etc/hostname"\n' > main.js $ npx vite --host 127.0.0.1

In another terminal: bash $ curl -o /dev/null -s -w '%{httpcode}\n' http://127.0.0.1:5173/main.js 200 $ curl -sS -o response -w '%{httpcode}\n' http://127.0.0.1:5173/@fs/etc/hostname 200 $ cmp -s response /etc/hostname && echo 'response matches host file' response matches host file

Other sources

Vite is a frontend tooling framework for JavaScript. Prior to 6.4.4, 7.3.7, 8.1.6, 8.2.4, and 8.3.3, import analysis can record a root-relative browser URL in safeModulePaths instead of the cleaned resolved module identifier. On a network-accessible, non-Windows development server, an imported project file whose URL matches an absolute host path can authorize a later raw-filesystem request for that host file, provided server.fs.deny does not block it. The request can disclose the matching file outside the project root, but it does not allow arbitrary path traversal because the host path must correspond to a project-relative URL authorized by the application graph. This issue is fixed in versions 6.4.4, 7.3.7, 8.1.6, 8.2.4, and 8.3.3.

— NVD

Affected Software

14 affected componentsFixes available
Vite Vite<6.4.4, <7.3.7, <8.1.6, <8.2.4, <8.3.3
npm/vite-plus<=1.0.0
1.1.0
npm/vite<=6.4.3
6.4.4
npm/vite>=7.0.0<=7.3.6
7.3.7
npm/vite>=8.0.0<=8.1.5
8.1.6
npm/vite>=8.2.0<=8.2.3
8.2.4
npm/vite>=8.3.0<=8.3.2
8.3.3
ubuntu/vite*
ubuntu/vite*
ubuntu/vite*
ubuntu/vite*
ubuntu/vite*
ubuntu/vite*
ubuntu/vite*

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/vite-plus to a version that resolves this vulnerability.

    Fixed in 1.1.0
  2. Upgrade

    Upgrade npm/vite to a version that resolves this vulnerability.

    Fixed in 6.4.4
  3. Upgrade

    Upgrade npm/vite to a version that resolves this vulnerability.

    Fixed in 7.3.7
  4. Upgrade

    Upgrade npm/vite to a version that resolves this vulnerability.

    Fixed in 8.1.6
  5. Upgrade

    Upgrade npm/vite to a version that resolves this vulnerability.

    Fixed in 8.2.4
  6. Upgrade

    Upgrade npm/vite to a version that resolves this vulnerability.

    Fixed in 8.3.3
  7. Upgrade

    Upgrade vite to a version that resolves this vulnerability.

    Fixed in 6.4.4
  8. Upgrade

    Upgrade vite to a version that resolves this vulnerability.

    Fixed in 7.3.7
  9. Upgrade

    Upgrade vite to a version that resolves this vulnerability.

    Fixed in 8.1.6
  10. Upgrade

    Upgrade vite to a version that resolves this vulnerability.

    Fixed in 8.2.4
  11. Upgrade

    Upgrade vite to a version that resolves this vulnerability.

    Fixed in 8.3.3

Event History

Oct 20, 2026
CVE Published
via MITRE·03:03 PM
Data Sourced
via MITRE·03:03 PM
DescriptionWeakness
Data Sourced
via OSV·03:03 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·04:17 PM
DescriptionSeverityWeakness
Oct 21, 2026
Advisory Published
via GitHub·04:47 PM
Data Sourced
via GitHub·04:47 PM
DescriptionWeaknessAffected Software
Oct 28, 2026
Data Sourced
via OSV·05:50 PM
Affected Software

Frequently Asked Questions

1

Which deployments are exposed?

Exposure requires a network-accessible Vite development server running on a non-Windows host. The issue affects versions before 6.4.4, 7.3.7, 8.1.6, 8.2.4, or 8.3.3, depending on the release line.

2

What must an attacker be able to do to disclose a file?

An imported project file must have a root-relative browser URL that matches an absolute path on the host. The attacker can then request that matching host file as a raw filesystem path, unless server.fs.deny blocks it.

3

Does this permit arbitrary filesystem traversal?

No. The disclosed host path must correspond to a project-relative URL that was authorized by the application's import graph; arbitrary path traversal is not possible through this issue.

4

What can be done if an upgrade cannot be applied immediately?

Do not expose the development server to the network, and ensure server.fs.deny blocks sensitive files. These measures address the stated network-accessibility and deny-list conditions for exploitation.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203