文章总结： 本文揭示Vite开发服务器因配置不当暴露公网导致严重安全风险。核心漏洞CVE-2026-29321允许通过/@fs/路由读取任意文件。攻击者可获取数据库密码、云密钥等敏感信息，进而横向渗透内网。文章通过实战案例展示攻击链，并给出升级Vite、限制网络访问、使用VPN等防御建议。强调开发环境暴露已成为堪比弱口令的基础设施安全问题。 综合评分： 87 文章分类： 渗透测试,漏洞分析,红队,内网渗透,安全建设

你的 Vite 还在公网裸奔？我靠一个开发服务器打穿了整条内网

原创

逍遥 逍遥

昆仑AI安全实验室

2026年8月10日 02:07 广东

在小说阅读器读本章

去阅读

上周做一个金融客户的红队项目，他们的主站防护滴水不漏。我转身拿 FOFA 搜了一把资产，发现了一个暴露在公网的 5173 端口，访问后页面赫然显示着 Vite 的开发调试界面。我熟练地在 URL 后拼接了 /@fs/etc/passwd，服务器直接把系统用户列表吐了出来。三个小时后，我拿着从 .env 里翻出的生产环境数据库密码，大摇大摆地走进了他们的内网核心区。

这已经不是某个漏洞的问题，而是一种正在被大量忽视的开发环境暴露风险。2026 年，超过 30 万台 Vite 开发服务器在公网裸奔，这扇门比任何 0day 都更容易敲开。

一、为什么开发服务器会跑到公网上去？

Vite、Webpack Dev Server 这类工具，设计初衷是给本地开发用的，默认只监听 127.0.0.1。但为了在手机上调试，开发者经常会加上 --host 0.0.0.0，或者配置 server.host = '0.0.0.0'，让服务器监听所有网络接口。当开发者的机器同时连着公司内网和互联网时，这个端口就可能被公网访问到。

更常见的是 Docker 部署。很多团队把 npm run dev 写进 Dockerfile，容器启动后直接暴露 5173 端口。再加上 Kubernetes 的 NodePort 或 LoadBalancer，开发服务器就堂而皇之地出现在了公网上，没有认证，没有加密，没有访问控制。

二、Vite 不止是静态文件服务器，它是一台文件读取器

2026 年 5 月，一个编号 CVE-2026-29321 的漏洞被公开：Vite 开发服务器的 /@fs/ 路由允许读取服务器上的任意文件。攻击者只需构造 URL：

/@fs/etc/passwd/@fs/proc/self/environ/@fs/app/.env

就能读取系统文件、环境变量、项目配置。这个漏洞覆盖面极广，从 Vite 2.0 到 6.2.3 之前的版本全部受影响。虽然修复版本 6.2.3 已经发布，但存量暴露的服务器中，绝大多数运行的是老旧版本。

这个漏洞根因在于，/@fs/ 本意是让开发者在浏览器中查看项目依赖的源码，却对路径没有任何限制。当服务器暴露在公网时，这就成了一个免费的文件下载站。

三、实战：从开发服务器到内网漫游

信息收集

1. 使用测绘引擎搜索暴露的 Vite 服务器。FOFA 语法：

header="vite" || title="Vite"

或者搜索特征端口：

port="5173" && protocol="http"

1. 针对目标公司，先用其域名反查 SSL 证书、WHOIS 等关联出 IP 段，再扫描常用开发端口。

漏洞利用

假设目标暴露了 http://x.x.x.x:5173。

1. 尝试读取基础文件：

/@fs/etc/passwd/@fs/proc/self/environ

1. 成功返回内容，确认漏洞存在。
2. 寻找项目根目录。通常 Vite 运行在项目根目录，所以 /@fs/app/.env 大概率命中。也可以根据返回的错误信息推断绝对路径。
3. 读取 .env 文件：

/@fs/app/.env

返回了数据库连接字符串、Redis 密码、AWS AccessKey、JWT 密钥等。

4.读取其他敏感文件：

/@fs/app/config/production.json/@fs/root/.ssh/id_rsa/@fs/var/run/docker.sock

内网横向

拿到凭证后：

• 用数据库密码连接 MySQL/PostgreSQL，导出用户数据。
• 用 Redis 密码通过 SSRF 或写定时任务反弹 Shell。
• 用 AWS 密钥接管 S3 存储桶。
• 用 SSH 私钥直接登录跳板机。

在某次实战中，我通过一个暴露的 Vite 服务器读取了项目源码，发现代码里硬编码了公司的 VPN 配置和预共享密钥。我直接用这些连接了内网 VPN，然后扫描到了内网的 Jenkins 和 GitLab，进一步扩大了战果。

四、真实案例：某 SaaS 平台的“Vite 门”事件

2026 年 7 月，我在一次授权渗透测试中，发现了某 SaaS 平台的开发环境端口暴露。该平台使用微服务架构，其中一个子服务是前端开发用的 Vite 开发服务器，通过 Docker 部署在公网，端口 5173 开放。

通过 /@fs/ 漏洞，我读取了：

• 项目的 package.json，确认了技术栈和依赖版本。
• .env.production，包含了生产环境的 MongoDB 连接字符串、阿里云 OSS 的 AK/SK。
• config/keys.js，存放着 JWT 签名密钥。

利用 MongoDB 连接字符串，我直接连上生产数据库，导出了 200 万用户数据，包括手机号、身份证号、订单记录。利用 AK/SK 登录阿里云控制台，发现 OSS 桶里存储了用户的身份证照片和合同文件。

攻击链仅用时 15 分钟，全程未触发任何告警。事后客户 CTO 感叹：“我们以为开发环境只是临时用用，没人会注意到。”

五、不止 Vite：Webpack、Create React App 同样中招

类似的问题也存在于 Webpack Dev Server、Create React App、Vue CLI 等开发工具中。它们同样默认监听 127.0.0.1，但开发者为了方便常常改为 0.0.0.0。虽然不一定都有任意文件读取漏洞，但暴露的开发服务器本身就可能泄露前端代码、API 接口、版本信息等，为攻击者打开大门。

例如，Webpack Dev Server 的 /__webpack_hmr 端点可以泄露模块热更新的信息；一些配置错误的 Source Map 可以还原原始源码，暴露内部逻辑。

六、防御：把开发环境关进笼子

1. 不要将开发服务器暴露到公网。即使需要移动端调试，也应使用 VPN、SSH 隧道或内网穿透工具（如 ngrok）进行，而非直接监听 0.0.0.0。
2. 升级 Vite：确认 Vite 版本 ≥ 6.2.3，或应用了修复补丁。在 vite.config.js 中配置：

server: {  fs: { strict: true, allow: ['./'] },  host: '127.0.0.1'  // 或 'localhost'}

1. 网络安全组限制：在防火墙或安全组中，明确禁止公网访问开发端口（5173、3000、8080 等），只允许内网特定 IP 或 VPN 网段访问。
2. Docker 安全：Dockerfile 中避免直接 EXPOSE 开发端口，使用反向代理，且容器内不应存放敏感环境变量（.env）。
3. 定期测绘自查：用 FOFA、Shodan 等平台搜索自己公司的域名和 IP 段，及时发现暴露的开发服务。
4. 不要在开发环境中使用真实数据。生产数据库凭据、云服务密钥等绝不应出现在开发配置文件中。

七、结语

2026 年，开发环境的暴露已经成为一个堪比弱口令的基础设施安全问题。Vite 的 /@fs/ 漏洞只是导火索，真正可怕的是开发者对“本地环境”的盲目信任。在微服务、DevOps 和远程办公的推动下，开发边界早已模糊，公网和内网的界线只在一次配置疏忽之间。

下次你做渗透测试或安全巡检，别忘了扫一扫 5173、3000、8080 这些熟悉的端口。说不定，一个正在裸奔的开发服务器，就是你通往内网的第一张门票。

严正声明 本文所述技术仅用于合法授权的安全测试，所有案例均已脱敏。未经授权利用漏洞入侵他人系统属于违法行为，与作者无关。请遵守法律法规，共同维护网络安全。

免责声明：

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

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

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

本文转载自：昆仑AI安全实验室 逍遥 逍遥《你的 Vite 还在公网裸奔？我靠一个开发服务器打穿了整条内网》