GitGuardian recently published some findings[1] on MCP server vulnerabilities. They found a path traversal vulnerability in a major MCP hosting provider that compromised over 3,000 servers and exposed API keys from thousands of clients. The fix right now is looking like manual testing, responsible disclosure, and hoping developers catch up on their reading.
I’ve been thinking about this type of vulnerability for a few months, ever since my NIST AI RMF article series and particularly with respect to MCP. But the broader issue is that every AI integration creates security debt we have few ways to track.
The Real Problem Isn’t the Vulnerability
The GitGuardian researchers showed that a single path traversal bug exposed sensitive files and API keys, the kind of foothold that could escalate into command execution or cloud resource access in less secure setups. It’s a pattern that rhymes with classic privilege escalation stuff, with prompt engineering instead of hacking a web form.
This was the result of a specific hunt through GitHub, testing individual servers, and building custom tooling to probe for issues. The approach works for research and bug hunts, but that’s hard to operationalize.
Most organizations running MCP servers right now are running one, maybe two. The other end of the scale, which is all too common especially in “move fast and break things” environments, is having no idea how many they’re running. (I’ve been talking to firms, and the non-hyperbolic answer from a lot of startups to large orgs with innovative teams tends to be that nobody actually knows-knows.)
You can’t secure what you can’t see. And right now, AI integrations are invisible to most security tooling.
Why?
MCP servers get deployed once, and updates are limited to maintenance. Just like in other permissions-optional environments, a developer may need filesystem access to make an integration work, grants broad permissions, moves on. That server then runs for months, makes it through a scrappy pilot, and nobody revisits those permissions because the integration works and there’s likely little to no monitoring. One or more humans saw that, and didn’t flag it for review.
Configuration drift is bad enough with traditional infrastructure. With AI integrations it’s worse because the attack surface is fundamentally different. Traditional vulnerabilities target developers and system admins - people with technical access. AI integrations expose that same functionality to operators, business users, anyone with access to the conversational interface. You’re not looking for SQL injection patterns or XSS vulnerabilities anymore, but for prompts that abuse legitimate functionality from a much broader user base.
The GitGuardian team demonstrated this beautifully. Their exploits weren’t breaking anything, they were just politely asking for things the servers were configured to provide. And, oh yeah, local dev environments aren’t exempt.
The Supply Chain Amplification
The Smithery.ai vulnerability illustrates something worse than individual misconfigurations. One path traversal bug in the hosting provider compromised over 3,000 downstream MCP servers. The researchers demonstrated actual credential theft by capturing network traffic and extracting API keys sent by clients to compromised servers. A single vulnerability in centralized infrastructure exposed secrets from thousands of clients accessing hundreds of services.
This is the inventory problem manifesting as supply chain risk. Organizations using hosted MCP servers had no visibility into the hosting provider’s security posture, and they couldn’t assess the risk because they couldn’t see the infrastructure. And when Smithery got compromised, thousands of downstream servers became untrusted simultaneously.
What Actually Needs to Exist
Security and development teams need three things that don’t really exist yet.
Automatic discovery. You cannot rely on developers to register their MCP servers in some central inventory system. That will never happen consistently. Something needs to find servers wherever they’re running (local environments, containers, cloud instances, hosted providers) and catalog what tools they expose and what resources they can access.
Contextual risk scoring. A server with filesystem access isn’t automatically high-risk. A server with filesystem access running in production with database credentials in environment variables is different. Risk assessment needs to understand relationships between capabilities, instead of just flagging individual features. It also needs to assess whether you’re using a centralized hosting provider and what your exposure looks like if that provider gets compromised.
Continuous monitoring. A server that started with read-only file access last month can easily have somebody add write permissions this week. Or a new tool got deployed that exposes shell access. Or your hosting provider introduced a configuration bug that creates path traversal vulnerabilities. You find out when it gets exploited, or you find out because monitoring catches the configuration change.
The research specifically mentions ToolVault as a potential solution for validating tools. That helps with new deployments, but ToolVault doesn’t address existing infrastructure and it doesn’t solve the threat detection problem, just validation at deployment time. This isn’t a critique of ToolVault itself but of the category of solutions that includes it. Still, you need an inventory before you can fix anything.
MCP adoption is accelerating
MCP launched in November 2024. Nearly a year later, estimates suggest well over ten thousand MCP servers are running across development environments, with new deployments accelerating quickly. GitGuardian just demonstrated how a single vulnerability in centralized infrastructure can compromise thousands of those servers simultaneously. The timeline is worrisome, too - we went from protocol launch to significant attack surface faster than security tooling could catch up. This isn’t theoretical risk we can address in next quarter’s roadmap, as these servers are running right now.
Every integration creates potential exposure, and most organizations are flying blind. The vulnerable servers GitGuardian found weren’t malicious deployments, just normal development workflows that nobody secured because nobody knew (or at least acted like) they needed securing.
Security teams need to know what’s running before researchers (or worse) find it. The right tooling doesn’t stop developers from misconfiguring servers, but it surfaces those misconfigurations immediately, scores them by risk, and gives teams actionable data instead of hoping someone notices during the next pen test.
We don’t know what the right solution looks like yet, but we know it’s not manual testing and staying current on blog posts. The MCP security problem isn’t theoretical, so now we need to figure out how to secure these integrations at scale.
Finally, full disclosure on why I care at all: I’ve been working on a community-driven AI threat intelligence solution. It’s not a crowded space just yet, so I think there’s a significant opportunity in both aggregating threats and building tools that fill the above gaps.
Working on something in this space? If you’re dealing with IT or AI posture issues, let’s talk.
References:[1] GitGuardian Security Research Team. “Breaking MCP: Server Hosting Security Analysis” https://blog.gitguardian.com/breaking-mcp-server-hosting/