CVE-2025-50180: esm.sh CDN SSRF Vulnerability

CVE-2025-50180 Overview

CVE-2025-50180 is a Server-Side Request Forgery (SSRF) vulnerability affecting esm.sh, a no-build content delivery network (CDN) for web development. In version 136, esm.sh is vulnerable to a full-response SSRF, allowing an attacker to retrieve information from internal websites through the vulnerability. This flaw enables unauthenticated remote attackers to abuse the CDN's fetch functionality to make arbitrary requests to internal resources, potentially exposing sensitive configuration data, internal services, and cloud metadata endpoints.

Critical Impact

Full-response SSRF vulnerability allows attackers to access internal network resources and retrieve sensitive information through the esm.sh CDN infrastructure.

Affected Products

• esm.sh version 136
• esm.sh CDN infrastructure running vulnerable versions
• Self-hosted esm.sh deployments prior to version 137

Discovery Timeline

• 2026-02-25 - CVE CVE-2025-50180 published to NVD
• 2026-02-25 - Last updated in NVD database

Technical Details for CVE-2025-50180

Vulnerability Analysis

This SSRF vulnerability (CWE-918) exists in esm.sh's internal fetch functionality. The vulnerable code path allows external users to influence the destination of HTTP requests made by the server without proper validation of the target host. When the server follows HTTP redirects, it does not validate whether the redirect destination is within an allowed set of hosts, enabling attackers to redirect requests to internal network resources.

The vulnerability is particularly severe because it returns the full response content to the attacker, making it a "full-response SSRF" rather than a blind SSRF. This allows attackers to extract sensitive data from internal systems, including cloud metadata services (such as AWS EC2 metadata at 169.254.169.254), internal APIs, and configuration endpoints.

Root Cause

The root cause lies in the FetchClient implementation in internal/fetch/fetch.go. The original implementation lacked host validation when following HTTP redirects. The CheckRedirect function only checked for the maximum number of redirects (3) but did not verify whether the redirect target was an allowed external host. This oversight allowed malicious actors to craft requests that would redirect the server to internal resources.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can craft a malicious URL that, when processed by esm.sh, redirects to an internal resource. The server follows the redirect and returns the internal resource's content to the attacker.

The attack flow typically involves:

1. Attacker submits a request to esm.sh with a URL pointing to an attacker-controlled server
2. The attacker's server responds with an HTTP redirect to an internal resource (e.g., http://127.0.0.1/admin or http://169.254.169.254/latest/meta-data/)
3. esm.sh follows the redirect without validation
4. The internal resource's response is returned to the attacker

// Vulnerable code - no host validation on redirects
// Source: https://github.com/esm-dev/esm.sh/blob/f80ff8c8d58749e77fa964abde468fc61f8bd89e/internal/fetch/fetch.go#L13

// FetchClient is a custom HTTP client.
type FetchClient struct {
	*http.Client
	userAgent string
}

// NewClient creates a new FetchClient.
func NewClient(userAgent string, timeout int, reserveRedirect bool) (client *FetchClient, recycle func()) {
	client = clientPool.Get().(*FetchClient)
	client.userAgent = userAgent
	client.Timeout = time.Duration(timeout) * time.Second
	client.CheckRedirect = func(req *http.Request, via []*http.Request) error {
		if reserveRedirect && len(via) > 0 {
			return http.ErrUseLastResponse
		}
		// Missing: host validation before following redirect
		if len(via) >= 3 {
			return errors.New("stopped after 3 redirects")
		}

Source: GitHub Fetch Function Code

Detection Methods for CVE-2025-50180

Indicators of Compromise

• Unusual outbound requests from esm.sh servers to internal IP ranges (10.x.x.x, 172.16.x.x-172.31.x.x, 192.168.x.x, 127.0.0.1)
• Requests targeting cloud metadata endpoints (169.254.169.254)
• HTTP redirect chains originating from external sources and terminating at internal resources
• Increased latency or errors in fetch operations indicating redirect abuse

Detection Strategies

• Monitor server logs for requests that result in redirects to private IP address ranges or localhost
• Implement network-level detection for outbound connections from CDN infrastructure to internal networks
• Deploy web application firewall (WAF) rules to detect SSRF patterns in request URLs
• Review access logs for patterns consistent with SSRF reconnaissance (sequential scanning of internal ports/services)

Monitoring Recommendations

• Enable detailed logging for all HTTP fetch operations including redirect chains
• Set up alerts for any requests to RFC1918 private addresses or link-local addresses from the fetch subsystem
• Monitor for unusual patterns in response sizes or timing that may indicate internal resource access
• Implement egress filtering and logging at the network perimeter

How to Mitigate CVE-2025-50180

Immediate Actions Required

• Upgrade esm.sh to version 137 or later immediately
• Review server logs for evidence of exploitation prior to patching
• Audit any exposed internal services that may have been accessed through this vulnerability
• Consider rotating credentials for any services that may have been exposed

Patch Information

The vulnerability has been fixed in esm.sh version 137. The fix introduces an allowedHosts parameter to the FetchClient that validates redirect destinations against a whitelist of permitted hosts. When a redirect is received, the code now checks if the target host is in the allowed list and blocks the redirect if it's not.

The patched code adds host validation in the CheckRedirect function:

// Patched code - adds allowedHosts validation
// Source: https://github.com/esm-dev/esm.sh/commit/0593516c4cfab49ad3b4900416a8432ff2e23eb0

// FetchClient is a custom HTTP client.
type FetchClient struct {
	*http.Client
	userAgent    string
	allowedHosts map[string]struct{}
}

// NewClient creates a new FetchClient.
func NewClient(userAgent string, timeout int, reserveRedirect bool, allowedHosts map[string]struct{}) (client *FetchClient, recycle func()) {
	client = clientPool.Get().(*FetchClient)
	client.userAgent = userAgent
	client.Timeout = time.Duration(timeout) * time.Second
	client.CheckRedirect = func(req *http.Request, via []*http.Request) error {
		if reserveRedirect && len(via) > 0 {
			return http.ErrUseLastResponse
		}
		// To avoid SSRF attacks, we check if the request URL's host is in the allowed hosts list.
		if allowedHosts != nil {
			if _, ok := allowedHosts[req.URL.Host]; !ok {
				return http.ErrUseLastResponse
			}
		}
		if len(via) >= 3 {
			return errors.New("stopped after 3 redirects")
		}

Source: GitHub Commit Reference

For additional details, see the GitHub Security Advisory GHSA-3c9r-837r-qqm4 and the GitHub Release v137.

Workarounds

• If immediate upgrade is not possible, implement network-level egress filtering to block outbound connections to internal IP ranges
• Deploy a reverse proxy in front of esm.sh that validates and sanitizes incoming URLs
• Disable or restrict the fetch functionality if it is not required for your deployment
• Implement firewall rules to prevent the esm.sh server from accessing sensitive internal services

# Example iptables rules to block outbound connections to private networks
# Apply these rules to the esm.sh server

# Block connections to private IP ranges
iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -j DROP
iptables -A OUTPUT -d 127.0.0.0/8 -j DROP
iptables -A OUTPUT -d 169.254.0.0/16 -j DROP

# Log blocked attempts for monitoring
iptables -A OUTPUT -d 10.0.0.0/8 -j LOG --log-prefix "SSRF-BLOCK: "