GHSA-g7r4-m6w7-qqqr

What it actually does

The flaw is a Windows-specific path traversal/arbitrary file read issue in the esbuild development server. When the vulnerable dev server is exposed, a crafted HTTP request can cause esbuild to resolve a requested path outside the intended served directory and return local files readable by the esbuild process. The impact is limited to file disclosure; there is no direct code execution or privilege escalation described. Exposure is typically constrained to systems that run esbuild’s development server, especially if it is bound to a network-accessible interface rather than localhost.

Why it matters to the business

An attacker who can reach a vulnerable esbuild development server on Windows may be able to read sensitive local files, such as source code, configuration files, environment files, credentials, tokens, or other developer workstation data. The CVSS score is low and this is not listed in CISA KEV, with no known mature public exploitation in the provided data, but it can still create meaningful risk if development servers are exposed beyond trusted local access. Because esbuild is widely used in JavaScript build and development workflows, organizations should treat this as a supply-chain hygiene issue and update affected tooling promptly.

How an attack unfolds

An attacker first identifies an esbuild development server running on Windows and confirms that it is reachable over HTTP. They then send specially crafted requests that manipulate path resolution so the server interprets the requested file path as being outside the configured served directory. If the vulnerable esbuild version is in use and the target file is readable by the esbuild process, the server returns the file contents in the HTTP response. The attacker may repeat the process to enumerate likely sensitive files, focusing on project configuration, secrets files, user profile files, package manager credentials, and Windows system files useful for confirming file disclosure. Successful exploitation generally requires network access to the dev server and depends on how the dev server is launched and what local files the process can read.

How to fix it

Upgrade esbuild to a fixed version. For npm-based installations, update esbuild to version 0.28.1 or later. Regenerate lockfiles as needed and ensure transitive or vendored copies are also updated. If immediate upgrade is not possible, do not expose the esbuild development server to untrusted networks; bind it to localhost only, restrict access with host firewall rules or VPN controls, and avoid running it with access to sensitive directories or secrets. Development servers should not be used as production-facing services.

How to confirm the fix worked

Confirm package resolution shows esbuild 0.28.1 or later across package manifests and lockfiles, including transitive dependency trees. For npm projects, use commands such as `npm ls esbuild`, `npm audit`, or software composition analysis tooling to verify the installed version. Validate that any running esbuild development server is either upgraded or restricted to localhost/trusted interfaces. On Windows hosts, confirm the process is not serving from directories containing secrets and that firewall rules prevent access from untrusted networks. Where safe and authorized, perform a controlled negative test to ensure traversal-style requests cannot retrieve files outside the configured served directory.

Typical attack path

1. Scan for HTTP services that appear to be esbuild development servers or JavaScript development tooling endpoints.
2. Confirm the server is running on Windows or behaves like a vulnerable Windows-hosted esbuild dev server.
3. Send path traversal-style HTTP requests designed to escape the configured served directory.
4. Request benign known files first to confirm arbitrary file read behavior.
5. Attempt to retrieve higher-value files such as project configuration, environment files, package manager credentials, source files, or user profile artifacts.
6. Use any disclosed secrets or internal information to support follow-on access against repositories, package registries, cloud services, or internal applications.

How to detect it

Review HTTP access logs, terminal output, reverse proxy logs, endpoint telemetry, and network captures for requests to esbuild development servers containing path traversal patterns, encoded dot-dot sequences, Windows drive-letter paths, or attempts to retrieve common sensitive files. Focus on Windows hosts running esbuild before upgrade to 0.28.1. Useful log sources include web/proxy logs in front of development servers, EDR network connection telemetry for `esbuild.exe` or `node.exe`, command-line process telemetry showing esbuild dev server startup, and developer workstation logs where available. Look for repeated 200 responses to unusual paths, requests for files outside the expected served directory, and access from non-local or unexpected source IPs. If exploitation is suspected, preserve logs, identify which files may have been returned, and rotate any secrets that may have been present in readable project or user-profile files.

• ../
• ..\\
• ..%2f
• ..%5c
• %2e%2e%2f
• %2e%2e%5c
• %252e%252e%252f
• %252e%252e%255c
• C:%5c
• C:/Windows/win.ini
• C:\\Windows\\win.ini
• /Windows/win.ini
• /.env
• /package.json
• /package-lock.json
• /yarn.lock
• /pnpm-lock.yaml
• /.npmrc
• /.git/config
• id_rsa
• esbuild.exe
• node.exe

What your security team should do

• Prioritize upgrading all npm esbuild installations to 0.28.1 or later, especially on Windows developer workstations, CI runners, and shared development servers.
• Inventory running development servers and ensure esbuild dev servers are not exposed to the internet or broad internal networks.
• Search package lockfiles and dependency inventories for vulnerable esbuild versions below 0.28.1.
• Review logs from exposed or shared Windows development hosts for traversal-style HTTP requests and suspicious file read attempts.
• If suspicious access is found, rotate potentially exposed secrets such as npm tokens, Git credentials, cloud credentials, API keys, and application environment secrets.
• Add policy controls to prevent development servers from binding to public interfaces by default.
• Treat this as lower urgency than active KEV or ransomware-exploited vulnerabilities, but remediate promptly because developer tooling can expose high-value credentials and source code.