Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/esm-dev/esm.sh < 0.0.0-20250616164159-0593516c4cfa
Fixed in
0.0.0-20250616164159-0593516c4cfa· Vendor fix available
Issue
A Local File Inclusion (LFI) vulnerability exists in the esbuild plugin's handling of the browser field in package.json. An attacker can publish an npm package that causes the server to read and return arbitrary files from the host filesystem during the build process. Details The vulnerable code is in the OnResolve callback of the esbuild plugin: https://github.com/esm-dev/esm.sh/blob/main/server/build.go The plugin validates that resolved file paths stay within the package working directory. However, after this check, the browser field from package.json remaps the module path to an attacker-controlled value containing ../ sequences. No validation is performed after the remapping. File contents appear in both the bundled JS output and the source map sourcesContent array. Readable files are constrained by esbuild's loader selection based on file extension: .json files must be valid JSON, .txt/.html/.md are read as raw text, files without a recognized extension must be…
Recommended action: Upgrade to 0.0.0-20250616164159-0593516c4cfa (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/esm-dev/esm.sh < 0.0.0-20260508100112-1960055e1d53
Fixed in
0.0.0-20260508100112-1960055e1d53· Vendor fix available
Issue
Impact - Arbitrary File Write – An attacker can cause the server to write data to any file path it has write permission for. - Privilege Escalation / RCE – By overwriting critical binaries or scripts, the attacker can execute arbitrary code with the server’s privileges. Exploit The legacy router first retrieves a response from legacyServer, parses the incoming request path, and ultimately writes the data to storage via buildStorage.Put (see <https://github.com/esm-dev/esm.sh/blob/4312ae93e518121e764a18bb521af12e490ef137/server/legacyrouter.go#L291). For a URL such as: the router concatenates the path components without sanitizing them, producing a storage key like: When this key is used, the underlying file system resolves the relative segments and writes the file to /tmp/pwned. Thus an attacker can craft a request that writes data to arbitrary locations on the server. Details 1. URL Construction A crafted request is sent to the server: 2. Proxy to Legacy Server The request is…
Recommended action: Upgrade to 0.0.0-20260508100112-1960055e1d53 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/esm-dev/esm.sh < 0.0.0-20250616164159-0593516c4cfa
Fixed in
0.0.0-20250616164159-0593516c4cfa· Vendor fix available
Issue
An SSRF vulnerability (CWE-918) exists in esm.sh’s /http(s) fetch route. The service tries to block localhost/internal targets, but the validation is based on hostname string checks and can be bypassed using DNS alias domains (for example, 127.0.0.1.nip.io resolving to 127.0.0.1). This allows an external requester to make the esm.sh server fetch internal localhost services. Severity: High (depending on deployment network exposure). Details The vulnerable flow starts at the route handling user-controlled remote URLs: - server/router.go:532 - Accepts paths beginning with /http:// or /https://. The internal-target block is string-based: - server/router.go:545 Localhost detection itself is limited to hostname patterns: - server/utils.go:72 - isLocalhost(...) checks values like localhost, 127.0.0.1, and 192.168.. - It does not validate the resolved destination IP after DNS resolution. Fetch proceeds with host-string allowlisting: - server/router.go:595-596 -…
Recommended action: Upgrade to 0.0.0-20250616164159-0593516c4cfa (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/esm-dev/esm.sh < 0.0.0-20250616164159-0593516c4cfa
Fixed in
0.0.0-20250616164159-0593516c4cfa· Vendor fix available
Issue
esh.sh is vulnerable to a full-response SSRF, allowing an attacker to retrieve information from internal websites through the vulnerability. Details Vulnerable code location: https://github.com/esm-dev/esm.sh/blob/f80ff8c8d58749e77fa964abde468fc61f8bd89e/server/router.go#L511 If the internal address has a suffix listed below, the attacker can obtain content from the specified internal address. eg: https://esm.sh/https://local.site/test.md A 302 redirect can be used to bypass the suffix restriction. eg: https://esm.sh/https://attacker.site/test.md https://attacker.site/test.md 302 redirect to http://169.254.169.254/v1.json PoC Use Flask to start a server that returns a 302 redirect. Let esh.sh visit this site. https://esm.sh/https://attacker.site/test.md Attacker can obtain data from http://169.254.169.254/v1.json. Decode the data (redacted) . Impact An attacker can exploit the vulnerability to access internal sites, and in a cloud environment, can retrieve access keys (AK)…
Recommended action: Upgrade to 0.0.0-20250616164159-0593516c4cfa (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/esm-dev/esm.sh < 0.0.0-20251118065157-87d2f6497574
Fixed in
0.0.0-20251118065157-87d2f6497574· Vendor fix available
Issue
The esm.sh CDN service contains a Template Literal Injection vulnerability (CWE-94) in its CSS-to-JavaScript module conversion feature. When a CSS file is requested with the ?module query parameter, esm.sh converts it to a JavaScript module by embedding the CSS content directly into a template literal without proper sanitization. An attacker can inject malicious JavaScript code using ${...} expressions within CSS files, which will execute when the module is imported by victim applications. This enables Cross-Site Scripting (XSS) in browsers and Remote Code Execution (RCE) in Electron applications. Root Cause: The CSS module conversion logic (router.go:1112-1119) performs incomplete sanitization - it only checks for backticks (\) but fails to escape template literal expressions (${...}), allowing arbitrary JavaScript execution when the CSS content is inserted into a template literal string. Details File: server/router.go Lines: 1112-1119 When CSS does not contain backticks,…
Recommended action: Upgrade to 0.0.0-20251118065157-87d2f6497574 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/esm-dev/esm.sh < 0.0.0-20251117232647-9d77b88c3207
Fixed in
0.0.0-20251117232647-9d77b88c3207· Vendor fix available
Issue
The esm.sh CDN service is vulnerable to a Path Traversal (CWE-22) vulnerability during NPM package tarball extraction. An attacker can craft a malicious NPM package containing specially crafted file paths (e.g., package/../../tmp/evil.js). When esm.sh downloads and extracts this package, files may be written to arbitrary locations on the server, escaping the intended extraction directory. Uploading files containing ../ in the path is not allowed on official registries (npm, GitHub), but the X-Npmrc header allows specifying any arbitrary registry. By setting the registry to an attacker-controlled server via the X-Npmrc header, this vulnerability can be triggered. Details file: server/npmrc.go line: 552-567 The code uses path.Join(pkgDir, name), which normalizes the path and allows sequences like ../../ to escape the intended package directory. PoC Test On - esm.sh Official Docker Image (latest version) - python 3.11 - flask (for attacker registry server) Step 1. Create…
Recommended action: Upgrade to 0.0.0-20251117232647-9d77b88c3207 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.