Yes. A client identity document proves control of a domain, but it cannot prove which local process is listening on a localhost redirect address. An attacker's app can present a legitimate client's identity, bind a local port and receive the authorization code when the user approves. Warnings and visible redirect details are the main defense.
How the attack works
Native MCP clients often use a redirect address on localhost. When clients identify themselves with a Client ID Metadata Document, the authorization server fetches a document from the client's URL. That proves the document owner controls the domain.
The MCP security guidance lays out the steps. The attacker supplies the real client's metadata URL as the client ID, binds any localhost port, and gives that address as the redirect. The user sees the legitimate client's name on the consent screen, approves, and the code lands with the attacker.
Why it is hard to spot
The consent page looks right. The client name is real and the domain is real. The only wrong thing is which process is on the other end of the localhost port, which a web page cannot verify.
Mitigations
The spec points to its authorization security considerations for countermeasures expected of authorization servers.
| Control | Where | Effect |
|---|---|---|
| Extra warning for localhost only redirects | Authorization server | Prompts the user to think |
| Show the redirect hostname clearly | Authorization server | Makes the target visible |
| Domain trust policies for client identities | Authorization server | Limits who can claim a name |
The guidance also describes trust policies, such as allowlists of trusted domains for protected servers, reputation checks and showing client hostnames prominently.
What you can do
- When you see a consent screen, read the redirect address as well as the client name.
- Be wary of approving a client you did not just launch.
- Prefer clients that use a registered, non localhost redirect where they can.
- If you run an authorization server, add the warnings and trust policy above.
- Keep scopes minimal so a stolen code gives little.
- Watch for sign in prompts you did not start.
The boundary to remember
A domain proves who published a client, not which copy of it is running. For high value access, add a second factor such as a device bound credential or an approval on another device.
Safeguard includes agent identity and policies, gates and guardrails, plus a free scan at https://gold.safeguard.sh/scan.
Quick check
Does PKCE stop this?
It limits what a stolen code can do without the verifier, but an attacker that started the flow holds the verifier. Warnings and trust policy matter more here.
Is this only a problem for desktop clients?
It is mainly native and local clients that use localhost redirects. Hosted clients with fixed, registered redirects face a different risk profile.
Sources
Last reviewed: 19 October 2026.
