A server-side MCP client validates discovery URLs before it fetches them. It parses the URL, resolves the host, compares the address against a private-range list and only then calls fetch. Code review passes it, and so does a unit test that feeds it http://169.254.169.254/. Then a server answers its authorization-server metadata request with a 302 to the cloud metadata address, and the client follows it:
client=naive\nmetadata IP, octal refused: blocked: 169.254.169.254 is private (0 ms)\n302 to http://169.254.169.254 200 66 bytes (2 ms)\n dial 203.0.113.10:443\n dial 169.254.169.254:80\n METADATA STUB served /latest/meta-data/iam/security-credentials/\nrebinding name (public, then metadata) 200 66 bytes (2 ms)\n dial 169.254.169.254:443\n METADATA STUB served /okThose lines are an excerpt from the lab behind this article. The check was correct and the client was still exploitable: it ran on the first URL and the first DNS answer, and the request used neither. Part 3 tested the protected resource metadata a server publishes; this part tests the client that reads it, and any MCP server whose tools fetch a URL. Part 5 covered what a model can be talked into. This attacker needs no model, only an HTTP server.
\n\n@modelcontextprotocol/client 2.4.0 (published 2026-10-23); undici 8.12.3, imported explicitly because the lab's Node.js 26.0.0 (macOS arm64) bundles 8.0.2. Node.js 26.12.1, the newest release that day, was not used. The Client ID Metadata Document draft is at -02 (2026-07-06); MCP still links -00. The lab replaces DNS with a lookup table and the network with a dial table that maps each fake address to a stub on 127.0.0.1, and 203.0.113.0/24 plays the public internet.The MCP security best-practices page lists three places a malicious server can plant a URL during discovery: the resource_metadata parameter of the WWW-Authenticate header, the authorization_servers entries in the protected resource metadata, and the token_endpoint, authorization_endpoint and other URLs in the authorization server metadata. The 2026-07-28 discovery rules multiply them: up to two well-known locations for the resource metadata, then three metadata locations for an issuer with a path. One authorization server can mean five GET requests before any user interaction, plus a POST to a token endpoint the attacker also named.
| Fetch | Who picks the URL | What a test should feed it |
|---|---|---|
| Protected resource metadata | The MCP server, through resource_metadata | Private, link-local and encoded addresses; http:; a 302 |
| Authorization server metadata | The MCP server, through authorization_servers | An issuer whose well-known URL redirects, or whose name resolves privately |
| Token and registration endpoints | The authorization server's metadata | Internal hosts, because a POST there can change state |
| Client ID Metadata Document | The client, fetched by the authorization server | The same rows, run against your authorization server |
| A tool that takes a URL | The model, steered by whatever it read | The same rows, through the tool's handler |
The 2026-07-28 revision added a rule that looks as if it helps: the client MUST reject authorization server metadata whose issuer is not identical to the issuer used to build the URL, per RFC 8414 section 3.3. The 2025-11-25 text had no such requirement. It decides whether the client may use a response, and by then the request has gone out and done whatever it does.
In @modelcontextprotocol/client 2.4.0, discovery requests go through fetchWithinOrigin, which sends redirect: 'manual' and follows a redirect only when it stays on the same origin and keeps the method, up to five hops. That is the transports' default redirectPolicy: 'same-origin'. Set 'follow' and redirects are left to the fetch implementation, which follows them to any origin.
The client does not look at addresses. auth.ts at v2.4.0 has no range check, and the resource_metadata value is fetched as parsed, http: included. The one scheme check guards the token endpoint, with a loopback exemption; the registration endpoint gets a POST without one. The lab passed a recording fetch to the discovery functions, so nothing touched a network:
-- resource_metadata pointing at the metadata address\nresult: ZodError [\nfetch manual http://169.254.169.254/latest/meta-data/\n-- AS metadata that redirects cross-origin, then same-origin\nfetch manual https://auth.example.test/.well-known/oauth-authorization-server\nfetch manual https://auth.example.test/.well-known/openid-configuration\nfetch manual https://auth.example.test/oidc.json\nresult: issuer https://auth.example.testThe first request went out; only its response failed schema validation. In the second case the cross-origin 302 was not followed, the client moved to the next well-known location, and a same-origin redirect there was followed. The SDK closes cross-origin hops and leaves the first hop of every fetch to you. The seam is the fetch option of StreamableHTTPClientTransport, which it also hands to its OAuth requests, and the fetchFn parameter of the discovery functions. A guarded fetch goes there, in the shape of fetch itself: it must accept the request's RequestInit, so methods, headers and bodies survive, and return a Response. The safeFetch below returns { status, body } to keep the matrix readable; return the final Response from its loop and forward init on each hop before you pass it to the transport.
The best-practices page warns against hand-written IP validation, because of octal, hex and IPv4-mapped IPv6 forms. The lab ran twelve spellings of the metadata address through a hand-written splitter (split on dots, Number() each part) and through net.BlockList, first on the raw host and then on the hostname that new URL() produced:
raw host URL hostname hand(raw) hand(parsed) BlockList\n169.254.169.254 -> 169.254.169.254 BLOCK BLOCK BLOCK\n2852039166 -> 169.254.169.254 not an IP, allow BLOCK BLOCK\n0xa9.0xfe.0xa9.0xfe -> 169.254.169.254 BLOCK BLOCK BLOCK\n0251.0376.0251.0376 -> 169.254.169.254 allow BLOCK BLOCK\n169.254.43518 -> 169.254.169.254 not an IP, allow BLOCK BLOCK\n%31%36%39.254.169.254 -> 169.254.169.254 not an IP, allow BLOCK BLOCK\n169.254.169.254. -> 169.254.169.254 not an IP, allow BLOCK BLOCK\n[::ffff:169.254.169.254] -> [::ffff:a9fe:a9fe] not an IP, allow not an IP, allow BLOCK\n[::ffff:a9fe:a9fe] -> [::ffff:a9fe:a9fe] not an IP, allow not an IP, allow BLOCK\n[64:ff9b::a9fe:a9fe] -> [64:ff9b::a9fe:a9fe] not an IP, allow not an IP, allow allow\n0 -> 0.0.0.0 not an IP, allow allow allow\n①②⑦.0.0.1 -> 127.0.0.1 not an IP, allow BLOCK BLOCKThe WHATWG parser behind new URL() rewrites decimal, octal, hex, short-form, percent-encoded, trailing-dot and circled-digit hosts into dotted decimal, so a check on url.hostname sees what the socket will see. The octal row is the dangerous one: Number('0251') is 251, so the splitter reads a public address where the parser reads 169.254.169.254. BlockList matches an IPv4 rule against the IPv4-mapped form, which the Node.js documentation shows for single addresses and the lab confirmed for subnets. The NAT64 and 0 rows pass even a correct parser, because the list is missing ranges.
The best-practices page names 10/8, 172.16/12, 192.168/16, 127/8, 169.254/16, ::1, fc00::/7 and fe80::/10. RFC 9728 section 7.7 only says clients should block \"internal IP address ranges\". The IANA special-purpose registries list more blocks that are not globally reachable, and some matter for a fetcher:
net.connect to 0.0.0.0 reached a listener bound to 127.0.0.1: connect host=0.0.0.0 remote=127.0.0.1. A loopback check that only knows 127/8 lets it through.64:ff9b::a9fe:a9fe spells 169.254.169.254. RFC 6052 section 3.1 tells translators to drop packets combining this prefix with a non-global IPv4 address, so whether it reaches anything depends on someone else's translator. Checking it costs one function.The CIMD draft has already moved this way. Revision -00, which MCP links, says authorization servers SHOULD avoid fetching private or loopback addresses. Revision -02 says they MUST NOT fetch a Client ID Metadata Document URL, or any URL inside one, that resolves to a special-use address as defined in RFC 6890, which is the registry above. It also says the server MUST NOT follow redirects when fetching the document. The lab's policy is built from the registry:
\n\n// policy.mjs: which destination addresses a discovery or tool fetch may reach.\nimport net from 'node:net';\n\n// IANA special-purpose registries (checked 2026-10-26): blocks not marked\n// globally reachable, plus multicast, broadcast and 6to4.\nconst V4 = [\n ['0.0.0.0', 8], ['10.0.0.0', 8], ['100.64.0.0', 10], ['127.0.0.0', 8],\n ['169.254.0.0', 16], ['172.16.0.0', 12], ['192.0.0.0', 24], ['192.0.2.0', 24],\n ['192.88.99.0', 24], ['192.168.0.0', 16], ['198.18.0.0', 15],\n ['198.51.100.0', 24], ['203.0.113.0', 24], ['224.0.0.0', 4], ['240.0.0.0', 4],\n];\nconst V6 = [\n ['::', 128], ['::1', 128], ['64:ff9b:1::', 48], ['100::', 64], ['2001::', 23],\n ['2001:db8::', 32], ['2002::', 16], ['3fff::', 20], ['5f00::', 16],\n ['fc00::', 7], ['fe80::', 10], ['ff00::', 8],\n];\n\nexport function buildPolicy({ exempt = [] } = {}) {\n const deny = new net.BlockList();\n for (const [a, p] of V4) deny.addSubnet(a, p, 'ipv4'); // also matches ::ffff:a.b.c.d\n for (const [a, p] of V6) deny.addSubnet(a, p, 'ipv6');\n const allow = new net.BlockList(); // explicit opt-outs only\n for (const [a, p, t] of exempt) allow.addSubnet(a, p, t);\n\n return function verdict(address) {\n const family = net.isIP(address);\n if (family === 0) return 'not an IP address';\n const type = family === 6 ? 'ipv6' : 'ipv4';\n if (allow.check(address, type)) return null;\n if (deny.check(address, type)) return `${address} is in a special-purpose range`;\n const v4 = family === 6 ? nat64Embedded(address) : null; // 64:ff9b::/96 carries an IPv4 address\n if (v4 && deny.check(v4, 'ipv4')) return `${address} embeds ${v4}`;\n return null; // null means allowed\n };\n}\n// nat64Embedded() expands the address and reads the last 32 bits as IPv4.The exempt list is the explicit opt-out the best-practices page asks for in development. The lab exempts 203.0.113.0/24 to stand in for public hosts; a development build might exempt 127.0.0.1/32, from configuration production never loads. CIMD -02 forbids the loopback exception in production outright.
If your client only talks to a known set of authorization servers, use an allowlist of issuers instead; the OWASP SSRF cheat sheet treats deny lists as a last resort. A client that connects to whatever server a user pastes in is OWASP's second case, where destinations are unknown in advance and a deny list on resolved addresses is the practical control.
\n\nHere is the client from the opening. Its list is the one from the best-practices page. Its resolve and dial layer are the lab's fake network, which tries each address in turn the way Node.js does with autoSelectFamily:
// Wrong: check the name once, then hand the URL to fetch.\nreturn async function naiveFetch(input) {\n const url = new URL(input);\n const host = url.hostname.replace(/^\\[|\\]$/g, '');\n const [first] = net.isIP(host) ? [host] : await resolve(host); // time of check\n const reason = verdict(first);\n if (reason) throw new Error(`blocked: ${reason}`);\n const res = await fetch(url, { dispatcher: agent }); // time of use; redirects followed\n return { status: res.status, body: await res.text() };\n};Its three failures have three causes. fetch follows redirects, so the check never sees hop two. fetch resolves the name again, so check and connection can get different answers: DNS rebinding. And the check reads only the first address while the connection falls back to the next. None is a bug in the list. The OWASP cheat sheet states the fix: validate the resolved addresses, connect only to them while keeping the original hostname for the Host header, SNI and certificate verification, and apply the policy to retries and fallback connections too.
In undici that place is the connect option of a dispatcher. undici calls it for every new connection with the hostname, port and protocol, and expects a connected socket back:
// safe.mjs: resolve once, validate every address, connect to a validated\n// address, and handle each redirect hop as a new request.\nconst agent = new Agent({\n connect(opts, cb) {\n const host = opts.hostname.replace(/^\\[|\\]$/g, '');\n (net.isIP(host) ? Promise.resolve([host]) : resolve(host)).then((addrs) => {\n for (const a of addrs) {\n const reason = verdict(a);\n if (reason) throw new PolicyError(a === host ? reason : `${host} -> ${reason}`);\n }\n dial(addrs[0], opts, cb); // the address that was checked, nothing else\n }).catch(cb);\n },\n});In production, resolve is dns.promises.lookup(host, { all: true }) mapped to addresses, and dial calls a connector from undici's buildConnector() with hostname set to the checked IP and servername set to the original name, so TLS still verifies the certificate against the name. On loopback, that connector with a test CA connected for servername=public.example.test and failed with ERR_TLS_CERT_ALTNAME_INVALID for any other name. Never put an IP in servername for a plain http: target: undici 8.12.3's connector then connects to servername instead of hostname, with no lookup to pin it. A probe with hostname=127.0.0.2 and servername=127.0.0.1 printed connected to 127.0.0.1, the address nobody checked. In the lab, dial maps the address to a loopback stub with the same certificate check. Refusing a whole answer when any address is bad is a choice: a name that resolves to public and private addresses at once is misconfigured or hostile, and you want to know either way.
The tempting shortcut is the lookup option that net.connect accepts. The lab shows its two traps:
autoSelectFamily default: true\nconnect host=stub.example.test remote=127.0.0.1 lookup calls=[{\"hostname\":\"stub.example.test\",\"all\":true}]\nconnect host=127.0.0.1 remote=127.0.0.1 lookup calls=[]\nconnect host=0.0.0.0 remote=127.0.0.1 lookup calls=[]With autoSelectFamily on, the default, the lookup gets all: true and the socket tries every address returned, so a lookup that checks only the first is the naive client again. And an IP-literal host never calls the lookup, so a lookup-only policy never sees 0.0.0.0 or an octal metadata URL. A connector that checks literals itself has neither gap.
Redirects are the second half. With redirect: 'manual', Node's fetch hands back the real 3xx and its Location; the lab's probe printed status=302 type=basic location=http://169.254.169.254/latest/meta-data/. So each hop can be a new request:
return async function safeFetch(input, { maxHops = 3, deadlineMs = 2000, maxBytes = 5 * 1024 } = {}) {\n const signal = AbortSignal.timeout(deadlineMs); // one deadline for every hop and the body\n let url = new URL(input);\n for (let hop = 0; ; hop++) {\n try { checkUrl(url); } catch (e) { trace(`hop ${hop} ${url.href} refused: ${e.message}`); throw e; }\n let res;\n try {\n res = await fetch(url, { dispatcher: agent, redirect: 'manual', signal });\n } catch (e) {\n const cause = e.cause instanceof PolicyError ? e.cause : e;\n trace(`hop ${hop} ${url.href} refused: ${cause.message}`);\n throw cause;\n }\n const location = res.headers.get('location');\n if (res.status >= 300 && res.status < 400 && location) {\n await res.body?.cancel();\n const next = new URL(location, url);\n trace(`hop ${hop} ${url.href} ${res.status} -> ${next.href}`);\n if (hop === maxHops) throw new PolicyError(`more than ${maxHops} redirects`);\n url = next;\n continue;\n }\n trace(`hop ${hop} ${url.href} ${res.status}`);\n return { status: res.status, body: await readCapped(res, maxBytes) };\n }\n};\n\nfunction checkUrl(url) {\n if (url.protocol !== 'https:') throw new PolicyError(`scheme ${url.protocol} not allowed`);\n if (url.username || url.password) throw new PolicyError('credentials in URL');\n}\n\nasync function readCapped(res, maxBytes) {\n const declared = Number(res.headers.get('content-length') ?? 0);\n if (declared > maxBytes) { await res.body?.cancel(); throw new PolicyError(`content-length ${declared} > ${maxBytes}`); }\n const chunks = []; let total = 0;\n for await (const chunk of res.body) {\n total += chunk.length;\n if (total > maxBytes) throw new PolicyError(`body exceeded ${maxBytes} bytes`);\n chunks.push(chunk);\n }\n return Buffer.concat(chunks).toString('utf8');\n}checkUrl enforces HTTPS, which the best-practices page says clients SHOULD require for OAuth-related URLs. The address check stays in the connector, the only code that knows which address is about to be used. Discovery can refuse cross-origin redirects outright, as the SDK does; the loop follows them through the checks because a tool fetching user-supplied pages usually has to.
Each row is one URL, an expected outcome and a fresh resolver, so the rebinding name always answers public first. Run the rows against the naive client too: a row it also passes tests nothing. The safe client, with its hop trace:
\n\nclient=safe\npublic metadata document 200 40 bytes (11 ms)\nmetadata IP, octal refused: 169.254.169.254 is in a special-purpose range (1 ms)\nmetadata IP, IPv4-mapped IPv6 refused: ::ffff:a9fe:a9fe is in a special-purpose range (1 ms)\nmetadata IP via NAT64 prefix refused: 64:ff9b::a9fe:a9fe embeds 169.254.169.254 (0 ms)\n\"this network\" 0.0.0.0 refused: 0.0.0.0 is in a special-purpose range (1 ms)\n302 to http://169.254.169.254 refused: scheme http: not allowed (5 ms)\n dial 203.0.113.10:443\n hop 0 https://public.example.test/discover 302 -> http://169.254.169.254/latest/meta-data/iam/security-credentials/\n hop 1 http://169.254.169.254/latest/meta-data/iam/security-credentials/ refused: scheme http: not allowed\n302 to https name -> 169.254.169.254 refused: meta.example.test -> 169.254.169.254 is in a special-purpose range (3 ms)\n dial 203.0.113.10:443\n hop 0 https://public.example.test/discover-https 302 -> https://meta.example.test/latest/meta-data/iam/security-credentials/\n hop 1 https://meta.example.test/latest/meta-data/iam/security-credentials/ refused: meta.example.test -> 169.254.169.254 is in a special-purpose range\nrebinding name (public, then metadata) 200 40 bytes (2 ms)\n dial 203.0.113.10:443\ndead public address, then 10.0.0.5 refused: mixed.example.test -> 10.0.0.5 is in a special-purpose range (1 ms)\n10 MB response refused: body exceeded 5120 bytes (9 ms)\ndrip-fed body, 4.5 s refused: The operation was aborted due to timeout (2004 ms)Trace lines for single-hop rows are left out of both runs. The naive client on the rows not shown at the top:
\n\nclient=naive\nmetadata IP via NAT64 prefix refused: lab network: no route to [64:ff9b::a9fe:a9fe]:443 (1 ms)\n dial [64:ff9b::a9fe:a9fe]:443\n\"this network\" 0.0.0.0 refused: lab network: no route to 0.0.0.0:443 (1 ms)\n dial 0.0.0.0:443\ndead public address, then 10.0.0.5 200 14 bytes (1 ms)\n dial 203.0.113.99:443\n dial 10.0.0.5:443\n INTERNAL STUB served /ok\n10 MB response 200 10485760 bytes (21 ms)\ndrip-fed body, 4.5 s 200 17 bytes (4518 ms)The two redirect rows fail at different layers, which is why both exist: the http: hop stops at checkUrl, and the HTTPS hop to a name resolving to the metadata address stops in the connector, before any socket opens. Against the naive client, the NAT64 and 0.0.0.0 rows reached the dial layer, a \"no route\" error in the lab and whatever answers there on a real host.
The drip row is a trap in undici's own options. bodyTimeout measures the time between body chunks, per the dispatcher documentation, so one byte every 300 ms never trips the naive client's 1,000 ms setting, and it waited out the whole drip. One AbortSignal.timeout across every hop and the body bounds the fetch. For size, CIMD -02 recommends reading at most 5 kilobytes of a client metadata document. Authorization server metadata has no such figure, so measure the documents your deployment fetches and cap above them.
A refusal should leave a hop trace and a policy reason behind, and no response body. A metadata service's answer never belongs in a log, an error message or a model's context.
\n\nThe same client belongs under any MCP tool that takes a URL. An authorization server that fetches Client ID Metadata Documents, which the 2026-07-28 best-practices page added as its own SSRF case, needs the same connector with a stricter profile: CIMD -02 says it MUST NOT follow redirects, so call safeFetch with maxHops: 0 and treat any 3xx as a refusal. In a tool, what the model sees and what you log should differ:
async function fetchPage({ url }) {\n try {\n const { status, body } = await safeFetch(url);\n return { content: [{ type: 'text', text: `HTTP ${status}\\n${body}` }] };\n } catch (e) {\n const reason = e instanceof PolicyError ? 'destination not allowed' : 'fetch failed';\n console.error(JSON.stringify({ tool: 'fetch_page', url, refused: e.message, hops: audit.splice(0) }));\n return { isError: true, content: [{ type: 'text', text: `Could not fetch ${url}: ${reason}.` }] };\n }\n}{\"tool\":\"fetch_page\",\"url\":\"https://public.example.test/discover-https\",\"refused\":\"meta.example.test -> 169.254.169.254 is in a special-purpose range\",\"hops\":[\"hop 0 https://public.example.test/discover-https 302 -> https://meta.example.test/latest/meta-data/iam/security-credentials/\",\"hop 1 https://meta.example.test/latest/meta-data/iam/security-credentials/ refused: meta.example.test -> 169.254.169.254 is in a special-purpose range\"]}\n{\"isError\":true,\"content\":[{\"type\":\"text\",\"text\":\"Could not fetch https://public.example.test/discover-https: destination not allowed.\"}]}The model learns that the fetch was refused, not which internal address the name resolved to. The best-practices page counts error messages that reveal internal topology among the risks, and a model can repeat them to whoever planted the URL. Nor does the model decide whether a destination is safe: it can ask for a URL, and the connector answers the same way whatever it says.
\n\nOwning the connector means owning what the platform used to handle: lookup errors, IPv6 preference, connect timeouts. Pinning one address gives up fallback across a host's other addresses, which is the part the wrong version showed to be dangerous. Pooling is unaffected, since undici calls the connector only for new connections.
\n\nThe guard sees only direct connections. Behind an HTTP egress proxy the client resolves nothing and connects only to the proxy, so the proxy must enforce the policy. The best-practices page suggests one, such as Smokescreen, for server-side clients; that makes it a second place to run the matrix. The lab cannot exercise a network-specific NAT64 prefix, and its rebinding row tests one property, one resolution per connection, not a real DNS server with a zero TTL. Write both down as known gaps.
\n\nList every place your MCP client or server fetches a URL it did not write: discovery, token and registration requests, tools, webhooks. Stand up a stub HTTPS server with a test CA and a resolver table, and write six rows: an octal metadata IP, an IPv4-mapped one, 0.0.0.0, a 302 to http://169.254.169.254, an HTTPS redirect to a name that resolves there, and a name that answers public then private. Run them against the client you have before changing it, then put a guarded fetch in the transport's fetch option and run them again. Keep both runs, each refusal with its hop trace and policy reason, and a check that no response body reached a log line. When you add 301, 303, 307 and 308 rows, the HTTP status reference helps; the SDK's origin check follows a non-GET request only on 307 and 308.
Yes. The OWASP cheat sheet calls IMDSv2 defence in depth that mitigates some SSRF cases, not a fix. The same client can also reach databases, admin panels and internal APIs that ask for no token at all, and the MCP best-practices page points out that a POST to a planted token endpoint can change state on an internal service.
\n\nThe best-practices MUST covers clients deployed to a server. A laptop client can still be pointed at the user's router or a service on localhost, so keep the HTTPS rule and loopback refusal, with a development opt-out. A stdio server never runs OAuth discovery, but its tools can still fetch URLs.
Its dns-rebinding-protection scenario, covered in part 2, tests a different defence: a local server rejecting a foreign Host or Origin header. A search of both published packages on 2026-10-26, 0.1.16 and 0.2.0-alpha.12, finds no scenario that mentions SSRF or the 169.254 range, so the rows here are your own tests.
resource_metadata-then-well-known order, the three and two metadata locations, and the MUST to reject metadata whose issuer is not identical.BlockList matching IPv4 rules against IPv4-mapped addresses, the lookup option, and autoSelectFamily passing all: true and trying every address.connect option, buildConnector, and the per-connection options a connector receives.bodyTimeout measuring the time between body chunks.fetchWithinOrigin: manual redirects, same-origin and same-method hops only, five at most.resource_metadata as given, the fetchFn parameter, and the HTTPS check limited to token endpoints.hostname and a different servername connecting to servername through a pinned lookup.