Notifications
Clear all
Topic starter
15/08/2026 6:13 pm
TL;DR: Common MCP clients can be driven into remote code execution, local file execution, or account takeover through unsafe authorization handling, insecure browser-launch flows, and unsanitized URL schemes across desktop and browser-based implementations, according to Obsidian Security. The finding matters because AI agent access now depends on client-side trust assumptions that traditional OAuth and app security controls were not built to enforce.
NHIMG editorial — based on content published by Obsidian Security: From well-known to Well-Pwned: Common Vulnerabilities in AI Agents
Questions worth separating out
Q: How should security teams enforce per-client authorization in MCP environments?
A: Security teams should bind each request to a specific client identity, approved scope, and approved operation on the server side.
Q: Why do MCP servers create new identity risk for AI-native development?
A: MCP servers create risk because they extend delegated access from the model into repositories, data, and workflow tools.
Q: What breaks when URL schemes are not restricted in agent clients?
A: Untrusted schemes can move a workflow from normal login into command injection, local file execution, XSS, or token theft.
Practitioner guidance
- Restrict authorization endpoints to approved schemes Allow only http and https for MCP authorization discovery, and reject javascript:, file:, smb:, and any other non-web schemes before the client renders or opens them.
- Remove unsafe browser-launch helpers from the trust path Avoid third-party open handlers that do not guarantee safe encoding, and do not pass raw metadata into shell-based browser launch logic.
- Treat MCP clients as privileged identity endpoints Review desktop, CLI, and browser-based clients as access-enforcing software that can expose credentials, session tokens, and local execution paths.
What's in the full article
Obsidian Security's full research covers the operational detail this post intentionally leaves for the source:
- Step-by-step proof-of-concept behaviour for the affected MCP clients across desktop and browser-based implementations.
- The exact metadata discovery sequence that turns authorization server lookup into a local trust decision.
- Technical examples of command injection, local file execution, XSS, and chained RCE paths.
- The coordinated disclosure timeline and the CVE references assigned to the affected client flaws.
👉 Read Obsidian Security's analysis of common MCP client vulnerabilities →
MCP authorization flaws in AI agents: are your client controls ready?
Explore further
15/08/2026 6:20 pm
Client-side MCP authorization has created a new identity control plane problem. The article shows that the decision boundary now sits inside the client, where metadata discovery, browser launch logic, and OS helpers all influence access. That means identity teams can no longer treat agent authorization as a pure server-side concern. Practitioners need to recognise the client as part of the access enforcement surface.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
A question worth separating out:
Q: Who is accountable when an MCP client exposes tokens or executes hostile input?
A: Accountability sits across the application team, the identity team, and the platform owner because the failure spans protocol handling, endpoint policy, and local runtime behaviour. NIST zero trust and application security controls both apply, but neither replaces the need for client-side authorization governance.
👉 Read our full editorial: Client-side MCP authorization flaws expose AI agent attack paths
