Topic starter
17/08/2026 5:40 pm
TL;DR: Unosecur reports that a supply chain attack against Claude Code can silently rewrite local MCP routing to intercept OAuth bearer tokens for Jira, Confluence, GitHub and other connected platforms before they reach the intended service. The incident shows that MCP-delegated credentials behave like governed identities, not disposable configuration, and access reviews cannot see what inventory never captured.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “How MCP Traffic Hijacking Turns Claude Code Into a Credential Theft Vector”.
Key questions
Q: What breaks when MCP credentials are stored in the same file as routing and trust settings?
A: The boundary between credential custody and request routing disappears.
Q: Why do provider-side logs miss OAuth token hijacking through MCP clients?
A: Because the attacker reuses a real token through a trusted egress path, so the provider sees a valid user, valid scopes and a familiar origin.
Q: How should security teams govern OAuth tokens as non-human identities?
A: Security teams should assign ownership, expiry, and revocation rules to OAuth tokens just as they would for service accounts or API keys.
Practitioner guidance
- Govern MCP-issued tokens as NHIs Create an inventory of every Claude Code or MCP-backed OAuth credential, with an owner, scope, refresh path and revocation process.
- Separate credential storage from routing state Move token handling, trust lists and endpoint configuration out of a single writable file wherever the architecture allows.
- Validate local MCP endpoints before rotating tokens Inspect the mcpServers block and session hooks on developer machines before any credential rotation.
Bottom line: Claude Code MCP hijacking shows that delegated OAuth access can be redirected at the client layer even when provider authentication remains intact.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step breakdown of the postinstall hook and sessionStart hook sequence on the developer machine
- Detailed remediation order for removing the malicious hook, repairing the mcpServers block and rotating tokens
- Specific guidance on where to look in ~/.claude.json for trust settings, routing entries and plaintext token storage
- Discussion of how Unosecur's MCP Auth Gateway changes the enforcement point for per-agent scope
👉 Read Unosecur's analysis of the Claude Code MCP token hijack →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
17/08/2026 5:40 pm
MCP-delegated OAuth tokens are already non-human identities in practice. They persist across sessions, inherit broad grant-time permissions and sit outside the inventory logic that most IAM programmes rely on. That combination means the governance problem is not merely token hygiene; it is that the credential now behaves like an unmanaged identity with routing metadata attached. Practitioners should treat MCP-issued access as a governed identity class, not as a developer convenience setting.
A few things that frame the scale:
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should teams rotate a suspected MCP token before fixing the local configuration?
A: No. If the routing compromise is still present, rotation can deliver the new token straight back to the attacker-controlled proxy. The safer sequence is to remove the malicious hook, verify the endpoint list and trusted paths, then rotate the credential only after the path is clean.
👉 Read our full editorial: Claude Code MCP traffic hijack exposes OAuth token governance gaps