文章总结： CVE-2026-29321是Vite开发服务器中/@fs/路径的任意文件读取漏洞，攻击者无需认证即可读取服务器敏感文件如/etc/passwd或.env配置文件。漏洞影响Vite2.0至6.2.3版本，CVSS评分9.1，全球数千万前端项目面临风险。修复方案包括升级至Vite6.2.3以上版本、配置访问白名单、避免使用–host0.0.0.0暴露服务。 综合评分： 92 文章分类： 漏洞分析,WEB安全,安全建设,漏洞预警,应用安全

一个斜杠，读穿整台服务器： Vite 任意文件读取漏洞（CVE-2026-29321）的完全拆解

原创

逍遥 逍遥

昆仑AI安全实验室

2026年5月30日 00:26 广东

在小说阅读器读本章

去阅读

昨天下午，我在测绘平台搜了一组暴露在公网的 Vite 开发服务器，挑了其中一台没有鉴权、没有任何访问控制的，在浏览器里敲了一行：https://target.com/@fs/etc/passwd。

三秒钟后，服务器上所有用户的列表原封不动地返回到我屏幕上。接着我读了 .env，读到了数据库密码和云服务密钥。从发现目标到完全接管它的云存储，前后不超过五分钟。

这就是 CVE-2026-29321，一个允许攻击者通过特殊构造的路径读取服务器上任意文件的漏洞。CVSS 评分 9.1，影响全球数千万前端开发者。更致命的是：漏洞的利用不需要任何前置条件，不需要认证，不需要交互，PoC 已在全网公开，攻击门槛低到了纯手工就能完成的程度。

本文把漏洞原理、利用方式、真实案例和修复方案全部拆开，不写概念，只写干货。

一、漏洞到底是什么

Vite 是一个下一代前端构建工具，在开发阶段提供了一个内置的 Web 服务器。为了方便开发者在调试时查看项目依赖的源码，Vite 在 URL 路径里设计了一个特殊的约定：/@fs/ 前缀。

这个约定的本意是让浏览器能够访问到 node_modules 里的文件。/@fs/ 后面的路径会被 Vite 直接映射到服务器的文件系统上。比如你在开发 Vue 项目，浏览器请求 /@fs/Users/zhangsan/project/src/App.vue，Vite 就会把本地 src/App.vue 文件的内容返回给浏览器。

问题出在它没有限制能读什么。

Vite 的开发服务器默认只对本地 localhost 开放，但这个默认行为在大量实际部署中被覆盖了。很多开发者为了方便移动端调试、或者因为使用了 --host 0.0.0.0、Docker 容器端口映射、云开发环境等，直接将开发服务器暴露在了公网上。

一旦暴露，攻击者只需要把 @fs 后面的路径改成任何想读的文件——/etc/passwd、/root/.ssh/id_rsa、/proc/self/environ、你项目根目录下的 .env——服务器就会乖乖地把文件内容送回来。

这不是“可能存在的漏洞”，这是设计上的功能被滥用。而漏洞编号 CVE-2026-29321 对应的修复，就是给这个 /@fs/ 路径加上访问白名单。

二、影响范围有多大

Vite 的全球装机量极其庞大。根据 npm 下载统计，Vite 每周下载量长期维持在千万级别，几乎所有 Vue、React、Svelte 的现代前端项目都在使用 Vite 或类 Vite 的开发服务器。

受影响版本覆盖了从 Vite 2.0 到 6.2.3 之前的全部版本。直到 6.2.3 版本，Vite 才默认限制了 /@fs/ 的访问范围，只允许访问 Vite 项目根目录和 node_modules 目录。

但问题是，已暴露在公网的存量服务器里，有多少已经打了补丁？目前在 Shodan、FOFA、Hunter 等测绘平台上，能直接搜到数十万台暴露了 Vite 开发服务器的资产。其中相当大一部分运行着老旧版本。

即使服务器本身没有公网 IP，在很多云开发环境或微服务架构中，Vite 开发服务器也经常被绑定在 0.0.0.0 上，内网其他主机可以直接访问。攻击者通过 SSRF 或简单的内网横向移动，就能利用这个漏洞读取内网服务器的任意文件。

三、实战攻击过程

真正危险的不是直接读 /etc/passwd，而是用这个漏洞作为跳板，横向攻击开发者的整个云环境。以下是一次真实授权测试的全过程。

第一步：测绘暴露资产

FOFA 的语法非常简单：

app="Vite" && country="CN" && proto

col="http"

搜索结果里，大量项目正在使用 Vite 进行开发调试。

第二步：基础探测

挑了一个没有鉴权的目标，先访问 /@fs/etc/passwd，返回 200。确认漏洞存在。接着测试能不能读到项目源码：/@fs/app/src/main.js。整个项目的入口文件、API 接口地址、用到的第三方库版本全部暴露。

第三步：读取配置文件

大多数前端项目的根目录下都有一个 .env 文件，存放着开发环境的数据库密码、Redis 密码、云存储的 AccessKey 和 SecretKey。依次尝试：

/@fs/app/.env /@fs/app/.env.local /@fs/app/.env.development /@fs/etc/environment /@fs/proc/self/environ

/@fs/app/.env.local 直接返回了阿里云 OSS 的 AccessKeyId 和 AccessKeySecret。

第四步：接管云资源

用拿到的 AK/SK 配置 OSS Browser，可以看到该开发者所有的存储桶。其中一个是生产环境的图片存储，里面存放着数十万用户的身份证照片和合同扫描件。

整个过程没有用任何漏洞扫描器，没有构造任何复杂 payload，全手动操作。从打开浏览器到看到身份证照片，不到十分钟。

📌 类似的事件真实发生过。某知名 WebSocket 在线协作平台白板项目的开发者，在调试时将 Vite 开发服务器暴露到了内网。有攻击者通过读取项目的 .env 文件拿到了 MongoDB 的连接字符串，进一步拖走了整个数据库。

四、为什么这个漏洞这么容易利用

根源在于开发者对“开发服务器”的认知偏差。

很多人认为 npm run dev 打开的只是一个本地调试工具，没有人会闲着没事扫自己的开发机。他们不理解一旦绑在 0.0.0.0 上，这台机器就成了一个对全世界开放的 Web 服务器。开发服务器通常没有接入生产环境的 WAF、没有日志监控、没有异常流量告警。

攻击者在读取文件时，请求看起来就像开发者在调试自己的代码。开发服务器返回的数据本身不包含任何恶意特征——只是纯文本，传统的安全网关根本不会拦截。

五、修复方案

Vite 官方在 6.2.3 版本修复了该漏洞，核心改动是默认限制 /@fs/ 只能访问 Vite 项目根目录及 node_modules。同时新增了一个配置项 server.fs.deny，开发者可以手动添加禁止访问的路径。

必须立刻做的事：

• 将所有 Vite 升级到 6.2.3 及以上版本，或者升级到对应的 5.4.16、4.5.10 等修复版本。
• 如果暂时无法升级，在 vite.config.js 里添加如下配置，将 /@fs/ 的访问限制到项目目录内：

export default defineConfig({   server: {     fs: {       strict: true,       allow: ['./']     }   } })

• 绝对不要使用 --host 0.0.0.0

  将开发服务器暴露到公网。如果确有移动端调试需求，使用内网 IP 并通过 VPN 或 SSH 隧道访问。

• 检查 .env 等敏感文件是否被提交到 Git 仓库、是否在 Docker 镜像中残留，涉及生产环境的密钥不得出现在开发配置中。

• 用测绘平台排查自己公司名下是否有暴露在公网的 Vite 开发服务器，发现一台关闭一台。

六、写在最后

这个漏洞的本质，不是 Vite 写错了某一行代码，而是“便利性”和“安全性”的一次经典冲突。/@fs 的原始设计是为了方便开发者调试，但当便利性变成默认暴露的攻击面时，代价就是数十万台服务器的任意文件可读。

更值得警惕的是开发环境的安全盲区。越来越多的攻击者发现，开发机、测试服务器、CI/CD 管道是进入生产环境的最短路径。因为开发者在测试环境里放了太多真实数据：数据库连接串、云服务密钥、内部文档、甚至直接克隆了生产数据库。

⚠️ 如果你或你的团队正在用 Vite 做开发，打开终端看一下你现在的 npm run dev 命令里有没有 --host。如果有，立刻关掉，然后升级 Vite。读这篇文章花掉的时间里，已经又有一批暴露的开发服务器被扫描了。

📢 本文为安全技术研究分享，旨在提升防御意识。请勿用于非法用途。 转载需注明出处，保持文章完整性。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：昆仑AI安全实验室 逍遥 逍遥《一个斜杠，读穿整台服务器： Vite 任意文件读取漏洞（CVE-2026-29321）的完全拆解》