Discovery runs before trust exists. That is what makes this a structural bug rather than a careless one. An OAuth client has to ask a server where its endpoints live before any token exists and before any issuer has been verified, so the only authority behind that first request is the network position of the process making it. The guard this SDK does have was applied to the part of the flow where credentials are submitted [7]. By then the requests have already gone out.
The chain is short enough to read in one sitting: `auth()` calls `discoverOAuthProtectedResourceMetadata()`, which calls `discoverMetadataWithFallback()`, which calls `tryMetadataDiscovery()`, which calls `fetch()` [4]. Four call boundaries, none of them validating [13]. The check that exists elsewhere is `assertSafeOAuthEndpoint()`, which delegates to `validateDownloadUrl()` [2]. That name is the interesting part: a URL guard written for downloads and later borrowed for OAuth endpoints. Borrowed validation gets applied where it was pasted, not where the data flows, which is the researcher's stated reason for reviewing this class of tooling in the first place [15].
On evidence strength, be precise about what was shown. A mock server on localhost received the SDK's standard OAuth discovery requests, headers and all, after the SDK was pointed at it through its public API [6]. That demonstrates request delivery to `127.0.0.1`. The writeup's other targets, the AWS metadata service at `169.254.169.254`, Redis on 6379, Elasticsearch on 9200 [8], and the credential-theft outcome it describes for instances with an attached IAM role [9], are consequences argued from that primitive rather than captured artifacts [14]. For instance metadata to become stolen credentials, the response body or an error carrying it has to be observable by whoever chose the URL, and that step is not in the writeup [14]. Blind SSRF is still a forged request originating inside your network; the distinction only changes which severity you file it under.
Three things have to hold for the finding to transfer to your deployment. The `serverUrl` has to be influenced by data you do not control, which the writeup notes can be a config file, a database row, or a user-supplied value [12]. The process has to sit somewhere with internal services worth reaching [9]. And nothing between the process and those services can be filtering egress. If your MCP client only ever dials a hardcoded host through a proxy that resolves and allowlists, this is a library defect and not your incident.
The awkward part is that the writeup does not name the SDK, describing it only as a fairly popular AI SDK for MCP authentication [11], so there is no version to diff and no advisory to read. The portable check is a shape rather than a version number: a public API that accepts a URL, a `fetch()` reachable from it, and a guard applied at some of the call sites downstream. The attacker in this model needs no credentials and no privileges [10], which means the interesting question about any agent framework you run is not whether it validates URLs, but whether it validates them at every point where a remote name turns into a socket.
