GHSA-67mh-4wv8-2f99

What it actually does

This flaw affects esbuild's development server behavior before version 0.25.0. The development server could accept cross-origin browser requests from arbitrary websites and return readable responses, effectively bypassing the browser-origin protections that developers commonly assume will prevent an unrelated website from interacting with local or internal development services. An attacker-controlled webpage visited by a developer could cause the developer's browser to send requests to the esbuild dev server and read files or responses that the dev server exposes. The impact is primarily unauthorized read/access to development-server content rather than direct code execution.

Why it matters to the business

Organizations using vulnerable esbuild versions for local or internal development workflows may expose source code, build artifacts, configuration files, or development-only application responses to a malicious website visited by a developer. While this is not known to be in the CISA KEV catalog and no mature public exploitation is indicated, the package is widely used in JavaScript build chains, so exposure can be broad across engineering teams and downstream tools. The main business risk is leakage of intellectual property, credentials accidentally present in served files, or sensitive implementation details that can support follow-on attacks.

How an attack unfolds

An attacker first hosts a malicious webpage containing JavaScript designed to probe common esbuild development-server addresses and ports, such as localhost or private-network hosts used by developers. When a developer using a vulnerable esbuild dev server visits that webpage, the developer's browser sends requests from the attacker's page to the dev server. Because the vulnerable server behavior permits these cross-origin requests and allows the response to be read, the attacker's script can retrieve content exposed by the development server and exfiltrate it back to attacker infrastructure. The attacker does not need direct network access to the development server if the victim's browser can reach it; the browser becomes the bridge between the malicious site and the local or internal development service.

How to fix it

Upgrade esbuild to version 0.25.0 or later. For npm-based projects, update direct dependencies and lockfiles so that esbuild resolves to a fixed version, then rebuild development tooling images or environments that bundle esbuild. Where esbuild is pulled transitively by frameworks, bundlers, or plugins, update the parent package if needed and verify the resolved esbuild version. As a mitigation, avoid exposing development servers beyond trusted loopback interfaces, restrict access with local firewall rules or network controls, do not run dev servers on shared or untrusted networks, and avoid serving sensitive files, secrets, or configuration through development tooling.

How to confirm the fix worked

Confirm that all affected projects resolve esbuild to 0.25.0 or later by inspecting package manifests and lockfiles and by running package-manager inventory commands such as `npm ls esbuild`, `pnpm why esbuild`, or `yarn why esbuild`. Validate development containers, CI images, and developer bootstrap scripts because they may pin older versions independently of application code. To confirm exposure is reduced, start the development server in a test environment and verify that requests from an unrelated origin cannot read responses from the esbuild server. Also verify that dev servers are bound only to intended interfaces and are not reachable from untrusted networks.

Typical attack path

1. Identify that a target population likely uses esbuild development tooling or related JavaScript build systems.
2. Host a malicious website with JavaScript that probes common esbuild dev-server origins, ports, and paths.
3. Lure a developer or user with access to a vulnerable development server to visit the malicious website.
4. Use the victim's browser to send cross-origin requests to the esbuild development server.
5. Read the returned responses from the vulnerable dev server.
6. Exfiltrate source files, build outputs, application responses, or configuration data exposed by the dev server to attacker-controlled infrastructure.
7. Use the collected information for credential discovery, intellectual-property theft, or planning additional attacks.

How to detect it

To assess possible prior exploitation, review developer workstation browser history, proxy logs, DNS logs, and endpoint telemetry for visits to suspicious or newly registered websites during periods when esbuild dev servers were running. Correlate those visits with local process telemetry showing `esbuild --serve`, framework dev servers that embed esbuild, or listening Node.js/esbuild processes. Check local firewall, EDR network connection logs, and web proxy records for browsers making requests to localhost, 127.0.0.1, private RFC1918 addresses, or common development ports followed by outbound connections to unfamiliar domains. If esbuild development-server access logs or wrapper logs are available, look for requests with unexpected `Origin` or `Referer` headers from external websites, unusual path enumeration, or high-volume reads of source, bundle, map, or configuration files. Because this issue is browser-mediated and development-server logging may be limited, absence of logs does not prove non-exploitation.

• esbuild --serve
• npm ls esbuild
• esbuild@0.24.
• esbuild@0.23.
• esbuild@0.22.
• Origin: http://
• Origin: https://
• Referer: http://
• Referer: https://
• 127.0.0.1:8000
• localhost:8000
• GET /src/
• GET /node_modules/
• GET /package.json
• GET /package-lock.json
• GET /pnpm-lock.yaml
• GET /yarn.lock
• GET /tsconfig.json
• GET /vite.config.
• GET /webpack.config.
• GET /rollup.config.
• GET /.env
• GET /*.map

What your security team should do

• Prioritize inventory of esbuild usage across repositories, developer images, build scripts, and transitive JavaScript dependencies.
• Upgrade all direct esbuild dependencies to 0.25.0 or later and refresh lockfiles to eliminate vulnerable resolved versions.
• For transitive usage, update the parent framework, bundler, or plugin until dependency resolution selects esbuild 0.25.0 or later.
• Restrict development-server access to localhost or trusted interfaces and block inbound access to dev-server ports from untrusted networks.
• Search repositories and build artifacts for secrets that may have been exposed through development servers, and rotate any credentials found in served files.
• Educate developers not to browse untrusted websites while sensitive local development services are running, especially when dev servers bind to broad interfaces.
• Add software composition analysis checks to fail builds or dependency updates that reintroduce esbuild versions earlier than 0.25.0.