CVE-2026-27730
SSRF Vulnerability in esm.sh Fetch Route Allows Internal Access
Publication date: 2026-02-25
Last updated on: 2026-02-27
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| esm | esm.sh | to 137 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-918 | The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-27730 is a Server-Side Request Forgery (SSRF) vulnerability in the esm.sh service, specifically in its `/http(s)` fetch route.
The vulnerability exists because esm.sh tries to block requests to localhost or internal network targets by checking the hostname strings, but this validation is insufficient and can be bypassed using DNS alias domains that resolve to internal IP addresses.
For example, a DNS alias like `127.0.0.1.nip.io` resolves to `127.0.0.1` but does not match the blocked hostname patterns, allowing an attacker to make esm.sh fetch internal localhost services.
This means an external attacker can trick esm.sh into accessing internal services that are not meant to be publicly accessible.
How can this vulnerability impact me? :
[{'type': 'paragraph', 'content': "This vulnerability allows attackers to access internal HTTP services that are not intended for public exposure by exploiting esm.sh's insufficient hostname validation."}, {'type': 'list_item', 'content': 'Attackers can discover and probe internal services through the esm.sh server.'}, {'type': 'list_item', 'content': 'Sensitive internal endpoints, such as metadata or administrative APIs, may be exposed depending on the deployment environment.'}, {'type': 'list_item', 'content': 'The exploit is limited to fetching resources with certain file extensions (e.g., .js, .ts, .mjs, .jsx, .tsx, .vue, .svelte, .md, .css), but some servers may allow bypassing these restrictions.'}, {'type': 'paragraph', 'content': 'Overall, this can lead to significant confidentiality breaches without requiring any privileges or user interaction.'}] [1]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': "Detection of this SSRF vulnerability involves identifying requests to the esm.sh service's `/http(s)` fetch route that attempt to access internal or localhost services using DNS alias domains that resolve to internal IPs."}, {'type': 'paragraph', 'content': 'You can monitor network traffic or server logs for requests matching the pattern `https://esm.sh/http://<dns-alias>:<port>/...` where the hostname is a DNS alias resolving to internal IP addresses such as `127.0.0.1.nip.io`.'}, {'type': 'paragraph', 'content': 'Suggested commands to detect such activity include:'}, {'type': 'list_item', 'content': 'Using tcpdump or Wireshark to capture HTTP requests to esm.sh and filter for suspicious hostnames:'}, {'type': 'list_item', 'content': "tcpdump -i <interface> -A 'tcp port 443 and (((ip dst <esm.sh IP>) and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420)))'"}, {'type': 'list_item', 'content': 'Grep or search server access logs for requests containing suspicious DNS alias domains resolving to internal IPs, e.g.:'}, {'type': 'list_item', 'content': "grep -E '127\\.0\\.0\\.1\\.nip\\.io|localhost|192\\.168\\.' /var/log/esmsh_access.log"}, {'type': 'list_item', 'content': 'Use DNS resolution commands to verify if suspicious hostnames resolve to internal IPs:'}, {'type': 'list_item', 'content': 'dig 127.0.0.1.nip.io'}, {'type': 'list_item', 'content': 'nslookup 127.0.0.1.nip.io'}] [1]
What immediate steps should I take to mitigate this vulnerability?
As of the time of publication, no patched versions of esm.sh exist to fix this SSRF vulnerability.
Immediate mitigation steps include:
- Restrict access to the esm.sh service to trusted users or networks to reduce exposure.
- Implement network-level controls such as firewall rules to block outbound requests from esm.sh servers to internal IP ranges (e.g., 127.0.0.1, 192.168.x.x).
- Monitor and log requests to the `/http(s)` fetch route for suspicious activity and block or alert on requests using DNS aliases resolving to internal IPs.
- Consider disabling or limiting the use of the vulnerable fetch route until a proper fix or patch is available.
Long-term mitigation requires proper validation of resolved IP addresses rather than relying on hostname string checks to block internal or localhost targets.