Can a malicious website steal source code from your local dev server?

It can, if the dev server is a vulnerable version. Two 2025 advisories, one for Vite and one for webpack-dev-server, describe a website you visit being able to reach a server on your own machine and read source code. The fix is to update the tool and keep dev servers off shared networks.

Why localhost is not a wall

Developers often assume that a server bound to localhost cannot be reached by the outside world. A web browser breaks that assumption. A page from any site you open can ask your browser to send a request to localhost, and your browser will do it. Whether the page can read the answer depends on how the server handles cross origin requests and the Origin header.

The webpack-dev-server advisories

GitHub's advisories published in June 2025 describe two issues in webpack-dev-server, both affecting versions up to 5.2.0 and patched in 5.2.1.

• The first says source code may be stolen when you access a malicious website. The reason given is that a request for a classic script by a script tag is not subject to the same origin policy, so an attacker can include a script tag pointing at the dev server on localhost and run it. The attacker has to know the port and the output script path. Combined with prototype pollution, the advisory says the attacker can reach the webpack runtime variables and read module source with a string conversion.
• The second covers non-Chromium browsers, where the Origin header check behaved differently, again allowing source theft from a malicious page.

Both are rated moderate in the advisories.

The Vite advisory

The Vite advisory from January 2025, GHSA-vg6x-rcgg-rjx6, says any website could send requests to the dev server and read the responses because of permissive default CORS settings and missing Origin validation on WebSocket connections. It states this applied to people who only ran the server locally. See also Vite dev server host and allowedHosts.

What is at risk

Source code is one concern. Dev servers also serve environment values that your build inlines for the browser, internal API paths and comments. If your code embeds anything sensitive in client code, a dev server leak shows it. For what should never be in client code, see Vite env prefix: what reaches the browser.

What to do

1. Upgrade the dev server. webpack-dev-server 5.2.1 or later fixes both June 2025 advisories, and Vite has patched releases for its advisory.
2. Do not browse untrusted sites in the same browser profile you use for local development when you can avoid it. A separate profile for dev work costs nothing.
3. Keep secrets out of client code and dev proxy config in the repo.
4. Avoid binding the dev server to all network interfaces unless you need it.
5. Scan build tool dependencies. Dev tools are in your lockfile and in your advisories like any other package.
6. Treat a fix in a dev tool as worth applying even though it does not ship, since the tool runs on the machine that holds your keys.

Why dev tool advisories get ignored

A scanner often marks dev dependencies as lower priority, and many teams agree. That is reasonable for production exposure, but these two advisories affect the developer machine. The question to ask is what runs there and who can reach it, which is a different question from what runs in production.

Safeguard's dependency scanning and reachability analysis can show whether an advisory in a build tool applies to how you run it, and its free scan at gold.safeguard.sh/scan is a quick place to start.

Quick check

Sources

• GitHub Advisory: webpack-dev-server source code may be stolen (CVE-2025-30359)
• GitHub Advisory: webpack-dev-server, non-Chromium browsers
• GitHub Advisory GHSA-vg6x-rcgg-rjx6 (Vite)

Last reviewed: 19 October 2026.