When OAuth Becomes a Weapon: Lessons from CVE-2025-6514

In late 2025, security researchers disclosed CVE-2025-6514—a critical vulnerability in mcp-remote that affected 558,846 downloads (HackerNoon). The issue allowed arbitrary OS command execution when connecting to untrusted MCP servers (JFrog advisory). mcp-remote is used by LLM hosts such as Claude Desktop, Cursor, and Windsurf (JFrog blog).

The attack vector exploited a pattern OAuth introduced: dynamic discovery of authorization endpoints (JFrog blog).

The bug itself was client-side—mcp-remote failed to sanitize URLs before opening them (JFrog advisory). But the architectural assumption that enabled the attack is OAuth’s: clients should ask servers where to authenticate. That assumption, designed for a world of known identity providers, becomes dangerous when applied to autonomous agents connecting to arbitrary MCP servers.

What Happened

The Model Context Protocol (MCP) has become the standard for connecting AI agents to external tools and services. When an MCP client connects to a remote server, it needs to authenticate. In mcp-remote, that flow asks the server for OAuth metadata (including an authorization_endpoint) and then opens the returned URL for the user to authenticate (JFrog blog). The flow looks like:

1. Client asks the MCP server: “Where should I authenticate?”
2. Server responds with OAuth metadata, including an authorization_endpoint
3. Client opens a browser to that endpoint
4. User logs in, client receives tokens

The vulnerability exploited step 2. A malicious MCP server could return a crafted authorization_endpoint URL that, instead of opening a login page, triggered OS command execution when mcp-remote attempted to open it (JFrog blog; JFrog advisory).

The Deeper Problem

The CVE has been patched (fix commit). But the architectural assumption that enabled it remains embedded in how we’re building agent authorization: agents must trust external services to tell them how to authenticate.

This is OAuth’s fundamental model. It assumes:

• A trusted identity provider exists
• The client can discover and verify that provider
• Token exchange happens over secure, authenticated channels
• The human user validates the authentication flow

None of these assumptions hold for autonomous agents operating at scale.

When Agent A needs to delegate authority to Agent B to call a third-party API, who is the identity provider? When that delegation happens asynchronously—maybe hours later, maybe through a message queue—how does the OAuth flow complete? When an agent orchestrator spawns hundreds of sub-agents, each needing scoped access to different resources, how many OAuth flows is that?

The answer the industry has settled on is: store the credentials, pass them around, hope nothing goes wrong.

CVE-2025-6514 shows what “goes wrong” looks like.

The Trust Inversion

OAuth was designed for a world where:

• Humans authenticate to services
• Services are few and well-known
• Sessions are synchronous and short-lived
• The user is present to validate trust decisions

AI agents invert every one of these assumptions:

• Agents authenticate on behalf of humans (or other agents)
• Services are numerous, dynamic, and potentially untrusted
• Operations are asynchronous and long-running
• No human is present to click “Allow”

The MCP vulnerability occurred precisely at this inversion point. The protocol asked: “Server, tell me where to authenticate.” The server answered with an attack payload. The client, following OAuth’s discovery model, obeyed.

The implication is uncomfortable: every OAuth integration in an agent system is a potential attack vector. Not because OAuth is broken, but because its trust assumptions don’t match agent reality.

A Different Model: Capability-Based Delegation

What if agents didn’t need to ask external services how to authenticate? What if authorization wasn’t about acquiring tokens from trusted third parties, but about presenting cryptographically-verifiable capabilities that carry their own proof of validity?

This is the capability-based security model, and it’s designed exactly for distributed, asynchronous, multi-party systems—which is what AI agent architectures actually are.

In a capability system:

Credentials stay at the boundary. A gateway service holds the actual API keys, OAuth tokens, and secrets. Agents never see them.

Agents hold capabilities, not credentials. When a user authorizes an agent to “read my calendar,” the agent receives a capability token that grants exactly that permission—cryptographically signed, time-bounded, and unforgeable.

Delegation is structural, not implicit. When Agent A needs Agent B to perform a subtask, A issues an attenuated capability—mathematically guaranteed to grant equal or lesser permissions than A holds. No OAuth flow. No trusting B to tell A where to authenticate.

Verification doesn’t require dynamic discovery. A capability token is cryptographically signed against a trust plane the verifier already knows. There’s no “ask the server where to authenticate” step. No metadata endpoint to poison. The attack surface that enabled CVE-2025-6514 simply doesn’t exist.

The CVE-2025-6514 attack becomes impossible—not because we added input validation, but because the attack surface doesn’t exist. There’s no OAuth flow to hijack.

What This Means for Agent Builders

If you’re building AI agents today, you’re probably using one of three patterns:

1. Environment variables / hardcoded keys

The agent has the actual credentials. Fast to implement, impossible to scope, nightmare to rotate, and a single prompt injection away from exfiltration.

2. Secret managers (Vault, AWS Secrets Manager)

Better storage, same problem. The agent still retrieves and holds the credential. You’ve secured the vault but handed the key to an entity that processes untrusted input.

3. OAuth / OIDC flows

The “proper” solution—and the pattern that enabled this RCE vulnerability. Works for human-interactive flows, breaks at async boundaries, and creates the trust inversion that CVE-2025-6514 exploited.

None of these were designed for autonomous agents delegating to other autonomous agents across trust boundaries.

Capability-based delegation is. It’s not a new idea—the theory dates to the 1970s, battle-tested in systems like seL4 and KeyKOS. What’s new is applying it to the specific problem of AI agent authorization.

The Path Forward

The MCP community is actively working on authorization improvements. The June 2025 spec update discusses OAuth resource servers and related auth guidance, and the November 2025 revision adds client registration improvements. Separately, RFC 9728 introduced protected resource metadata for OAuth ecosystems (RFC 9728). These are steps in the right direction.

But they’re still building on OAuth’s discovery model. They’re still assuming agents can safely discover, connect to, and trust external authorization infrastructure—now with better metadata validation, but the same fundamental trust assumption.

The next vulnerability won’t be the same as CVE-2025-6514. But it will exploit the same structural assumption: that identity-based authorization, designed for humans clicking through browser flows, can secure autonomous agents operating at machine speed across organizational boundaries.

Capability-based delegation offers a different foundation. One where:

• Trust is cryptographic, not discovered
• Delegation is attenuated, not all-or-nothing
• Verification is local, not dependent on external services
• The attack surface shrinks instead of grows

We’re building this infrastructure at Amla Labs. If you’re deploying agents with real credentials and want to stop worrying about the next discovery-based vulnerability, get in touch.

For the technical foundation, see Proof of Continuity. For why identity alone doesn’t solve delegation, see The Missing Layer.