GHSA-8MC6-XJPR-H98X: Root-cause SSRF Mitigation in fetchPeerConnectInfo

Vulnerability

GHSA-8MC6-XJPR-H98X describes a server-side request forgery condition in Ech0's connect flow. The vulnerable path allowed an authorized user to supply a peer URL that was later fetched by the server, enabling requests to internal network services and cloud metadata endpoints. The commit diff in the patch commit shows the original implementation issuing a request directly from a constructed URL without visible destination validation.

resp, err := httpUtil.SendRequest(url, "GET", struct {
		Header  string
		Content string
	}{

This is a classic SSRF pattern: application-controlled outbound HTTP based on attacker-influenced input, with no demonstrated restriction on scheme, host, IP range, or metadata endpoints. The advisory summary also indicates impact against internal networks and cloud environment configuration services, which is consistent with unrestricted server-side fetch behavior.

Patch

The patch introduces two defensive changes in internal/service/connect/connect.go, as shown in the commit. First, it validates the peer URL before persistence using ValidatePublicHTTPURL. Second, it replaces the generic outbound request helper with SendSafeRequest, with comments stating that it blocks private-network, loopback, and cloud metadata destinations and uses a secure dialer to mitigate DNS rebinding.

// SSRF 防护：拒绝指向私网/回环/云元数据等地址的对端 URL。
// 运行时 fetchPeerConnectInfo 也会再次校验，这里在入库前就拦截，避免恶意记录污染存储。
if err := httpUtil.ValidatePublicHTTPURL(connected.ConnectURL + "/api/connect"); err != nil {
	return errors.New(commonModel.INVALID_CONNECTION_URL)
}

// 使用 SendSafeRequest 进行 SSRF 防护：拒绝指向私网/回环/云元数据等地址的对端 URL，
// 并通过 SecureDialContext 防御 DNS rebinding。
resp, err := httpUtil.SendSafeRequest(url, "GET", httpUtil.Header{

From the patch summary alone, the intended security model is improved in two places: input acceptance and request execution. That is the correct architectural direction for SSRF remediation because it reduces both stored malicious configuration and runtime bypass opportunities.

Review

Pros

• The patch moves from unrestricted outbound fetches to an explicitly hardened request path, which is the right control point for SSRF.
• Validation is applied before storing the peer URL, reducing persistence of attacker-controlled endpoints and limiting later abuse from poisoned records.
• The runtime request path is also hardened, which is important because storage-time validation alone is insufficient if records can be modified elsewhere or if canonicalization differs at execution time.
• The patch comments explicitly mention blocking private, loopback, and cloud metadata targets and defending against DNS rebinding, which addresses common SSRF bypass classes called out by the advisory context.
• The change appears localized and low-risk from a functional perspective: it preserves the connect workflow while tightening destination policy.

Cons

• The provided diff does not include the implementations of ValidatePublicHTTPURL, SendSafeRequest, or SecureDialContext, so the review cannot verify exact handling of edge cases such as IPv6 literals, mixed-encoding hosts, redirects, alternate schemes, or resolver behavior.
• The snippet shows validation against connected.ConnectURL + "/api/connect"; correctness depends on robust URL parsing and normalization rather than string concatenation semantics.
• The patch summary does not show whether redirects are disabled or revalidated per hop. If redirects are followed without equivalent checks, SSRF may still be reachable indirectly.
• The review material does not show whether all outbound call sites that consume peer URLs were migrated to the safe helper. If other paths still use generic request functions, residual SSRF exposure may remain outside this specific flow.
• The advisory states authorized users can trigger the issue; the patch mitigates destination abuse but does not change the privilege model or add audit controls for suspicious outbound connection attempts.

Verdict

Root-cause.

Based on the available diff and advisory data from the GitHub Security Advisory and the referenced commit, this patch appears to address the underlying trust-boundary problem rather than merely filtering one obvious payload. It adds destination validation before persistence and enforces a hardened transport path at request time, which is the correct layered design for SSRF. The remaining uncertainty is implementation quality in the helper functions, not the remediation strategy itself. If those helpers correctly canonicalize hosts, reject non-public destinations after DNS resolution, and prevent unsafe redirects, the fix should materially close the reported SSRF vector.