Your MCP Server Shouldn’t Decide Where Your Credentials Go

On October 6, a security flaw was found in the official MCP TypeScript SDK. In short: an MCP server could trick your AI agent into sending its login secrets to the wrong place.

What happened, in plain terms

AI agents use MCP servers as tools. Some of those servers need a login. To log in, the agent asks the server one question: "Who handles your logins?" The server replies with the address of a login service, and the agent sends its credentials there.

The flaw: the agent believed whatever the server said. A malicious or hacked server could reply with the address of a login service the attacker controls. The agent would then send its secrets straight to the attacker.

Think of a valet who asks a restaurant where to leave your car keys. The restaurant says "with my cousin round the back," and the valet just does it.

The details:

• Bug: CVE-2026–104850, rated High (CVSS 7.5)
• Affected: MCP TypeScript SDK 1.12.0 up to 1.31.0, and 2.x before 2.2.0
• What can leak: refresh tokens, client secrets and signed JWT assertions
• Who is at risk: apps that use the SDK as an MCP client with OAuth login, and might connect to an MCP server they don't fully trust
• Fix: upgrade to @modelcontextprotocol/sdk 1.31.0 or @modelcontextprotocol/client 2.2.0

Why it matters: it's a login bug, not an AI bug

This has nothing to do with AI being tricked by clever prompts. It is an old, well-known security rule being broken: never let the party asking for your password tell you where to send it.

Websites learned this years ago with single sign-on. Your app decides which login provider it trusts, in its own settings. It never takes that answer from someone else. AI agents are now learning the same lesson.

The risk is bigger with agents because one agent can hold several logins and connect to dozens of MCP servers. Every untrusted server it talks to is a chance for someone to grab those logins.

It keeps happening

This is not the first bug of this kind. In the last few weeks, several MCP tools made the same mistake of trusting the other side without checking.

The bigger picture is no better. A July study of 414 public MCP servers (Exposed by Design) found that 380 of them, about 92%, had no login protection at all. Most of the problems found were basic web security mistakes, not anything specific to AI.

What to do

Today

• Find your MCP clients. List every AI agent, app, IDE plugin or script that uses the MCP SDK and logs in to MCP servers.
• Upgrade. Move to @modelcontextprotocol/sdk 1.31.0 or @modelcontextprotocol/client 2.2.0. If you use the Python SDK, upgrade that too.
• Change exposed secrets. If an older version ever connected to an MCP server you don't control, assume its secrets leaked. Create new client secrets, revoke refresh tokens and replace signing keys.

This week

• Lock the login provider. Set the trusted login service (the "issuer") in your agent's own settings. Reject any MCP server that points somewhere else. For machine-to-machine logins, the upgrade alone may not protect you until you do this.
• Block, don't guess. If a server doesn't say clearly who handles its logins, don't connect.
• Approve MCP servers like any other vendor. Keep an allowlist. New servers need a review, an owner and logging.

Ongoing

• One secret per job. Give each agent separate credentials for each login service and purpose, so one leak doesn't unlock everything.
• Keep secrets short-lived. Prefer tokens that expire quickly over long-lived secrets in config files.
• Give agents their own identity. Manage each agent like a user or service account, with its own access rules (see below).

The bigger lesson: agents need their own identity

Today, most agents run on borrowed secrets: a password or token sitting in a config file. Whoever tricks the agent into handing them over gets access.

The better approach is to treat each agent like an employee account: its own identity, its own permissions and its own access rules, managed in your identity system.

This is already happening. Microsoft now gives every new Copilot Studio agent its own Entra Agent ID, and since July 2026 offers Conditional Access and ID Protection for agents.

Bottom line: upgrading fixes this bug. Giving agents real identities fixes the whole category.