Is vite-plugin-static-copy Safe? Understanding CVE-2025-57753 and Path Traversal

vite-plugin-static-copy is safe to use once you are on a patched version, but affected releases carried a directory traversal vulnerability (CVE-2025-57753) that could expose arbitrary files during development. The plugin copies static assets into your Vite build output and serves them in dev, and the flaw lived in how it resolved requested file paths from the dev server.

If you use vite static copy in your frontend build, this is worth a few minutes to check. The good news is that the fix is a straightforward version bump, and the vulnerable path is only reachable under a specific and avoidable configuration.

What the Plugin Does

vite-plugin-static-copy solves a common problem: copying files that are not part of the module graph into your output directory. Fonts, favicons, robots.txt, downloadable PDFs, and vendored assets that you do not want Vite to hash and transform all fit here. You configure it with source globs and destination paths:

import { viteStaticCopy } from 'vite-plugin-static-copy'

export default defineConfig({
  plugins: [
    viteStaticCopy({
      targets: [
        { src: 'assets/fonts/*', dest: 'fonts' },
        { src: 'legal/*.pdf', dest: 'docs' },
      ],
    }),
  ],
})

During vite dev, the plugin also serves those copied assets so the dev experience matches production. That serving path is where the vulnerability lived.

CVE-2025-57753: Directory Traversal via viaLocal

The vulnerability is tracked as CVE-2025-57753. Affected versions of vite-plugin-static-copy are vulnerable to directory traversal through the viaLocal function, which handled serving files in the dev server. By sending crafted HTTP requests containing path traversal sequences, an attacker could read files outside the intended asset directory, effectively reaching arbitrary files the dev server process could access.

Directory traversal (also called path traversal) is a classic class of bug: user-controlled input is used to build a filesystem path without properly canonicalizing and validating it, so sequences that walk up the directory tree escape the intended root. It maps to CWE-22.

The important qualifier is the exploitation condition. This is only exploitable if the Vite dev server is explicitly exposed to the network, meaning you started it with the --host flag or set server.host in your config. A dev server bound only to localhost is not reachable by a remote attacker, which limits the blast radius considerably. But teams that expose the dev server for testing on other devices, or run it inside a container with a published port, were genuinely at risk.

Affected Versions and the Fix

Upgrade vite-plugin-static-copy to version 2.3.2, 3.1.2, or higher to pick up the fix. The maintainers backported the patch across release lines so you do not have to jump a major version if you are pinned to the 2.x series.

Check what you have and update:

# See the installed version
npm ls vite-plugin-static-copy

# Update to a patched release
npm install vite-plugin-static-copy@^3.1.2
# or, if you are on the 2.x line
npm install vite-plugin-static-copy@^2.3.2

After updating, verify your lockfile resolved to a patched version rather than a cached older one, and rebuild.

Reducing Exposure Beyond the Patch

Patching closes this specific issue, but the underlying lesson is about how you run the dev server. A few habits reduce your exposure to this whole category of dev-time flaw:

• Do not expose the Vite dev server to untrusted networks. Bind to localhost by default and only use --host when you genuinely need cross-device access, on a trusted network.
• If you must expose it, put it behind a reverse proxy or restrict access by IP rather than opening the raw dev port.
• Treat the dev server as a development-only tool. It is not hardened for production serving, and CVE-2025-57753 is a reminder of why.
• Keep build-time dependencies in your vulnerability tracking, not just runtime dependencies. Dev and build tooling can carry serious flaws too.

That last point is easy to overlook. Many teams scan production dependencies but ignore devDependencies, where build plugins live. An SCA tool such as Safeguard can flag a vulnerable build plugin in your lockfile and tell you which patched version to move to, regardless of whether it is a runtime or development dependency.

Keeping Vite Tooling Current

The broader Vite ecosystem has seen a handful of path-traversal issues in the dev server and related plugins, which is not unusual for tools that serve files from disk. The maintainers respond quickly, so the most effective defense is simply staying current. Automate dependency updates with a tool that opens pull requests for patched versions, and gate merges on a passing build so upgrades do not silently break things. For a wider view of managing npm supply chain risk, our security academy covers dependency hygiene end to end.

FAQ

Which versions of vite-plugin-static-copy are affected by CVE-2025-57753?

The directory traversal affects releases prior to the fixed versions. Upgrade to 2.3.2, 3.1.2, or higher to remediate.

Is CVE-2025-57753 exploitable in production?

The vulnerable serving path is in the Vite dev server, which is a development tool. It becomes remotely exploitable only when the dev server is exposed to the network via --host or server.host. Production builds do not run this code.

Do I need to change my config after upgrading?

No configuration change is required. The fix is in the plugin's path-handling code, so a version bump is sufficient. Just confirm your lockfile resolved to a patched version.

Should I scan devDependencies for vulnerabilities?

Yes. Build plugins and other development dependencies can carry serious flaws, as this case shows. Include devDependencies in your software composition analysis rather than scanning only runtime packages.