GHSA-gv7w-rqvm-qjhr

What it actually does

The advisory describes a cryptographic/integrity weakness in the esbuild npm distribution when used through the Deno module path: binary downloads could be influenced by the NPM_CONFIG_REGISTRY setting without sufficient integrity verification. If an attacker can cause a build, install, or Deno execution environment to use a malicious npm registry, esbuild may retrieve and execute an attacker-controlled native binary instead of the legitimate esbuild binary, resulting in remote code execution in the context of the invoking user or build process. The advisory is marked withdrawn, so exploitation details and affectedness should be treated with caution, but upgrading to the fixed release remains the safest posture.

Why it matters to the business

Successful exploitation could compromise developer workstations, CI/CD runners, build systems, or release pipelines that execute esbuild, allowing theft of source code, credentials, signing keys, package tokens, or insertion of malicious code into downstream software artifacts. Because esbuild is widely used in JavaScript and TypeScript build chains, exposure can extend beyond runtime applications into software supply-chain integrity. The advisory is not in CISA KEV, is not known to be used in ransomware campaigns, and has no stated public exploit maturity, but build-system compromise can have high operational impact even without widespread exploitation.

How an attack unfolds

An attacker first gains a way to influence the npm registry used by a Deno/esbuild invocation, commonly through environment variable injection, poisoned CI configuration, compromised developer shell configuration, malicious documentation, or a dependency/build script that sets NPM_CONFIG_REGISTRY. The attacker then operates or points to a malicious npm-compatible registry that serves a counterfeit esbuild package or platform-specific esbuild binary. When the victim runs a Deno workflow that imports or installs esbuild, the module resolves the binary from the attacker-controlled registry. Because the described flaw involves missing or insufficient binary integrity verification, the malicious binary may be accepted and executed. The payload then runs with the permissions of the build or developer process, enabling credential theft, source modification, persistence in build scripts, or further lateral movement. Because this advisory was withdrawn, teams should validate whether their actual Deno/esbuild usage path is affected before assuming compromise, while still treating unexpected registry configuration as suspicious.

How to fix it

Upgrade esbuild to version 0.28.1 or later wherever esbuild is declared directly or resolved transitively. Regenerate lockfiles after upgrading and ensure CI/CD uses the updated lockfile. Pin package registries to approved sources and prevent untrusted jobs, scripts, or pull requests from overriding NPM_CONFIG_REGISTRY, npm_config_registry, .npmrc registry entries, or equivalent package-manager registry settings. Where possible, enforce package integrity through lockfiles, checksums, provenance controls, and artifact allowlisting. Restrict network egress from build systems so they can only reach approved package registries. Run builds with least privilege and avoid exposing long-lived credentials to build jobs that install dependencies or execute third-party tooling. Because the advisory is withdrawn, also review upstream esbuild release notes and advisory history to confirm whether the specific usage pattern is applicable in your environment.

How to confirm the fix worked

Confirm that all direct and transitive esbuild versions resolve to 0.28.1 or later using package-manager inventory, lockfile review, and software composition analysis. Check package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, deno.lock, and generated dependency manifests for older esbuild versions. Validate that build and Deno execution environments do not set NPM_CONFIG_REGISTRY or npm_config_registry to unapproved domains. Inspect .npmrc files at repository, user, and global levels for unauthorized registry entries. Run a clean build in a controlled environment and verify that all package and binary downloads come only from approved registries. Confirm network egress policies block access to arbitrary npm-compatible registries from CI/CD runners and build hosts.

Typical attack path

1. Identify a project, developer workflow, or CI/CD job that uses esbuild through the affected Deno/npm path.
2. Influence npm registry resolution by setting or injecting NPM_CONFIG_REGISTRY or npm_config_registry to an attacker-controlled registry.
3. Host a malicious npm-compatible registry or package endpoint serving a counterfeit esbuild binary or package artifact.
4. Trigger an install, build, test, or Deno execution step that causes esbuild to download or resolve its native binary.
5. Have the malicious binary execute under the developer or build-runner account.
6. Steal credentials, source code, package tokens, cloud secrets, or signing material, or modify build outputs for downstream compromise.

How to detect it

Review CI/CD logs, build logs, package-manager logs, Deno cache activity, proxy logs, DNS logs, EDR telemetry, and shell/process environment captures for evidence that esbuild was installed or executed while npm registry settings pointed to an unapproved domain. Focus on builds or developer sessions where NPM_CONFIG_REGISTRY or npm_config_registry was set, .npmrc was modified, or network traffic showed esbuild-related downloads from nonstandard registries. Look for unexpected child processes spawned by esbuild, post-install scripts, Deno, npm, pnpm, yarn, or node during dependency installation. Examine downloaded esbuild binaries for unexpected hashes, unsigned or unknown provenance, unusual file modification times, or binaries sourced from unapproved hosts. Investigate any subsequent access to secrets, package publishing, source-code changes, release artifacts, or outbound network connections immediately after suspicious esbuild installation or execution.

• NPM_CONFIG_REGISTRY=
• npm_config_registry=
• registry=
• .npmrc
• node_modules/esbuild/bin/esbuild
• node_modules/@esbuild/
• deno.lock
• package-lock.json
• pnpm-lock.yaml
• yarn.lock
• esbuild@0.
• npm install esbuild
• pnpm add esbuild
• yarn add esbuild
• deno add npm:esbuild
• deno run
• npm_config_registry=http://
• NPM_CONFIG_REGISTRY=http://

What your security team should do

• Prioritize upgrading esbuild to 0.28.1 or later across source repositories, build images, developer containers, and CI/CD templates.
• Search CI/CD definitions, build scripts, Dockerfiles, shell profiles, and repository configuration for NPM_CONFIG_REGISTRY, npm_config_registry, and unauthorized .npmrc registry overrides.
• Restrict build-system egress to approved package registries and artifact mirrors only.
• Audit recent builds that used esbuild with nonstandard registry configuration, especially builds that had access to package publishing tokens, cloud credentials, signing keys, or production deployment credentials.
• Rotate exposed or potentially exposed secrets if suspicious registry use or unexpected esbuild binary downloads are found.
• Add CI policy checks that fail builds when registry settings are changed to unapproved locations.
• Because the advisory is withdrawn and no public exploit maturity is reported, treat this as a supply-chain hardening priority rather than evidence of active exploitation unless local indicators are present.