CVE-2025-59146: New API Gateway SSRF Vulnerability

CVE-2025-59146 Overview

CVE-2025-59146 is an authenticated Server-Side Request Forgery (SSRF) vulnerability in New API, a large language model (LLM) gateway and AI asset management system. The flaw affects all versions prior to 0.9.0.5. An application endpoint accepts a user-supplied URL and fetches its content without validating the destination. Any authenticated user can exploit the issue, and because user registration is often enabled by default, the attack surface includes self-registered accounts. The vulnerability is categorized under CWE-918: Server-Side Request Forgery.

Critical Impact

Authenticated attackers can coerce the New API server into issuing arbitrary HTTP requests to internal services, cloud metadata endpoints, or external systems, enabling internal network reconnaissance and exposure of sensitive infrastructure data.

Affected Products

• QuantumNous New API versions prior to 0.9.0.5
• Self-hosted New API LLM gateway deployments
• New API instances with default user registration enabled

Discovery Timeline

• 2025-10-09 - CVE-2025-59146 published to the National Vulnerability Database
• 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-59146

Vulnerability Analysis

New API exposes a feature that allows authenticated users to submit a URL for server-side retrieval. The endpoint was originally intended for image processing, but the URL handler did not enforce a content-type or destination restriction. The server fetches whatever URL the user supplies, including links pointing at internal RFC1918 ranges, loopback interfaces, link-local addresses, and cloud instance metadata services.

The vulnerability falls under [CWE-918] and is triggered with a single authenticated HTTP request. Because the server processes the response on behalf of the attacker, the issue can be used to probe internal services, fingerprint listening ports, or retrieve credentials from metadata endpoints such as 169.254.169.254 in cloud environments.

Root Cause

The download handler in service/download.go accepted user-controlled URLs and forwarded them to the HTTP fetch routine without consulting an allow-list or blocking private address space. There was no helper to classify an IP address as private, link-local, or loopback prior to the patch. The fix introduces a new common/ip.go module that detects private ranges and a configurable FetchSetting policy that validates each outbound request.

Attack Vector

The attack requires only network access to the New API web interface and a valid low-privilege account. The attacker submits a crafted URL to the vulnerable endpoint. The server resolves the host and issues an outbound request from its own network position, returning the response content or error to the attacker.

// Security patch in common/ip.go - introduces private IP detection
package common

import "net"

func IsPrivateIP(ip net.IP) bool {
	if ip.IsLoopback() || ip.IsLinkLocalUnicast() || ip.IsLinkLocalMulticast() {
		return true
	}

	private := []net.IPNet{
		{IP: net.IPv4(10, 0, 0, 0), Mask: net.CIDRMask(8, 32)},
		{IP: net.IPv4(172, 16, 0, 0), Mask: net.CIDRMask(12, 32)},
		{IP: net.IPv4(192, 168, 0, 0), Mask: net.CIDRMask(16, 32)},
	}

	for _, privateNet := range private {
		if privateNet.Contains(ip) {
			return true
		}
	}
	return false
}

Source: GitHub Commit ef634160

The corresponding fix in service/download.go validates the URL against the new fetch policy before issuing the request:

// SSRF protection: validate the request URL
fetchSetting := system_setting.GetFetchSetting()
if err := common.ValidateURLWithFetchSetting(req.URL, fetchSetting.EnableSSRFProtection, fetchSetting.AllowPrivateIp, fetchSetting.DomainFilterMode, fetchSetting.IpFilterMode, fetchSetting.DomainList, fetchSetting.IpList, fetchSetting.AllowedPorts, fetchSetting.ApplyIPFilterForDomain); err != nil {
	return nil, fmt.Errorf("request reject: %v", err)
}

Source: GitHub Commit ef634160

Detection Methods for CVE-2025-59146

Indicators of Compromise

• Outbound HTTP requests from the New API server process to RFC1918 addresses, 127.0.0.0/8, or 169.254.169.254 that did not originate from normal LLM provider traffic.
• New user registrations followed shortly by image upload or URL submission API calls.
• Application logs showing the download or image-fetch endpoint receiving non-image URLs or non-HTTPS schemes.
• Unexpected DNS queries from the New API host resolving internal hostnames or cloud metadata domains.

Detection Strategies

• Inspect web access logs for repeated POST requests to URL-submission endpoints with varying url parameters targeting internal CIDR ranges.
• Correlate authenticated session identifiers with outbound socket connections initiated by the New API process to spot single users driving anomalous fetch behavior.
• Alert on any egress traffic from the New API container or host destined for 169.254.169.254, metadata.google.internal, or internal management subnets.

Monitoring Recommendations

• Capture and retain New API application logs, HTTP egress logs, and DNS query logs in a central analytics platform for retrospective hunting.
• Baseline the legitimate set of upstream LLM provider domains the gateway contacts and alert on deviations.
• Monitor user registration rates and flag bursts that precede URL-fetch API usage.

How to Mitigate CVE-2025-59146

Immediate Actions Required

• Upgrade New API to version 0.9.0.5 or later, which ships SSRF protection enabled by default.
• Disable open user registration on internet-exposed deployments until upgrade completes.
• Rotate any cloud instance credentials or API keys reachable from the New API host if exploitation cannot be ruled out.
• Restrict administrative access to the New API console to trusted networks.

Patch Information

The maintainers fixed the issue in commit ef634160, released in version 0.9.0.5. The patch introduces a user-configurable SSRF protection module, enabled by default, that gives administrators granular control over outbound requests. Configurable settings include EnableSSRFProtection, AllowPrivateIp, domain and IP allow/deny lists, and an AllowedPorts policy. Full details are published in GitHub Security Advisory GHSA-xxv6-m6fx-vfhh.

Workarounds

• Enable the New API image processing worker (new-api-worker) to isolate URL fetching into a constrained execution context.
• Apply egress firewall rules on the New API host or container that deny outbound traffic to RFC1918 ranges, loopback, link-local addresses, and cloud metadata IPs.
• Place the New API service behind an outbound proxy that enforces a strict allow-list of upstream LLM provider domains.

# Example iptables egress restrictions for the New API host
iptables -A OUTPUT -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -d 127.0.0.0/8 -j REJECT