CVE-2026-19374

The CVSS 7.3 score for this SSRF in the customAxios proxy endpoint is misleading—not because the math is wrong, but because it treats this as a typical input validation flaw when the vulnerability is actually a structural authorization failure in a component whose core purpose is making arbitrary outbound requests. The key distinction: in most SSRF cases, you're exploiting unintended behavior—a file upload that can be tricked into fetching URLs, an image processor that follows redirects. Here, the customAxios function in app/api/proxy/route.ts IS a dedicated proxy. Making outbound HTTP requests is the feature, not an accident. That means the missing remediation isn't input sanitization—it's access control. The authorization boundary must exist somewhere: IP allowlisting on the proxy itself, destination restrictions (blocking internal ranges, metadata endpoints), or authentication middleware. If your proxy accepts requests from unauthenticated internet traffic and forwards them anywhere, you don't have an SSRF vulnerability—you have an intentionally open relay that was shipped without the authorization layer its design demands. The rolling-release model compounds the problem significantly. There's no patch to apply and no version boundary to check. You cannot enumerate whether your instance is vulnerable because there's no fixed version where the flaw was introduced and later fixed. This transforms what would normally be a point-in-time vulnerability into a persistent configuration requirement. Egress filtering, IP allowlisting, and destination restrictions aren't compensating controls you're deploying temporarily while waiting for a fix—they're permanent operational constraints you must implement, maintain, and audit indefinitely. The CVE creates an illusion of a remediation path toward 'patched' when the actual path is toward 'adequately compensating-controlled,' and defenders must internalize that distinction immediately. Your immediate actions: audit whether app/api/proxy/route.ts is exposed to unauthenticated traffic, implement destination deny-lists blocking 169.254.169.254, 127.0.0.1, and RFC 1918 ranges, and apply authentication or IP restriction at the API gateway level if the proxy is intended for internal use only. This is not a vulnerability you will eventually patch and forget—you are building permanent infrastructure to govern an intentionally open channel.

Reviewed through automated stages and approved by a human before publication.