Critical SSRF Vulnerability in Popular HTTP Helper Exposes Internal Networks

A widely used HTTP client helper library contains a critical security flaw, exposing applications to Server-Side Request Forgery (SSRF) attacks. The `Http` helper's `send()` method passes user-supplied URLs directly to the underlying `fetch()` function without any validation, creating a direct pipeline for attackers to probe internal networks and services. This absence of basic safeguards turns a common utility into a potential backdoor.

The vulnerability, located in the `packages/helpers/src/Http.ts` file, lacks fundamental SSRF protections. There is no blocklist for private IP ranges like 127.0.0.0/8 or 10.0.0.0/8, no protocol restriction to only HTTP/HTTPS, no DNS rebinding protection, and no limits on redirect following. Any application feature that passes user-controlled URLs to `Http.get()`—such as webhook handlers, URL previews, avatar fetching, or RSS importers—becomes an attack vector. This allows malicious actors to scan internal networks, access sensitive cloud metadata endpoints (like 169.254.169.254), and even read local files via the `file://` protocol.

The flaw represents a medium-severity risk, aligning with SSRF's status as a top-10 OWASP vulnerability class. The proposed fix involves implementing an optional SSRF guard that performs DNS resolution to check IPs against private ranges, restricts protocols, and limits redirects. Until patched, any service using this helper for processing external URLs faces significant exposure to internal infrastructure reconnaissance and data exfiltration.