Old Vulnerabilities are New Again! (MCP Part 2)
By Caber Team
VentureBeat recently said MCP stacks have a 92% exploit probability. Every wave of connectivity promises stronger security — and yet, the same vulnerabilities keep returning. APIs, OAuth, and now MCP all claim to close the gaps that came before them. But progress in design doesn't equal progress in outcome. The data shows that most breaches arise not from missing controls, but from controls that couldn't keep up. MCP is repeating the same pattern — just at machine speed.
The Promise of Progress
Every new technology begins with the same optimism: This time, we've learned our lesson.
In 2010, the API economy embraced OAuth 2.0 to solve access delegation. In 2025, the MCP ecosystem announced OAuth 2.1, PKCE, and tool provenance as its answer. Both were right in theory — and wrong in practice.
| Generation | Innovation | Intended Fix | Real-World Outcome |
|---|---|---|---|
| APIs (2010s) | OAuth 2.0, Scopes | Limit access per app/user | 80% of apps used global service accounts |
| Cloud APIs (2020s) | Fine-grained tokens, API gateways | Centralized enforcement | Token proliferation, gateway bypass |
| MCP (2025) | OAuth 2.1, PKCE, tool filtering | Context-aware delegation | 70% unauthenticated or weakly scoped servers |
The pattern isn't technical failure — it's structural. When ecosystems expand faster than the rules that govern them, even the most elegant controls degrade into suggestions. You must be able to identify resources to control them, but determining what rules and policies those controls enforce isn't a technology issue.
Familiar Vulnerabilities, Faster Timeline
MCP's most common vulnerabilities are almost identical to those that plagued early APIs:
| Vulnerability | APIs (2010s) | MCP (2025) | Cause |
|---|---|---|---|
| Command Injection | #1 in OWASP API Top 10 | 43% of MCP servers vulnerable (Equixly 2025) | Input not validated in dynamic calls |
| SSRF / Fetch Abuse | Common API gateway exploit | 33% allow unrestricted fetch (Docker Security) | Missing network filters |
| Broken Auth | ~40% of APIs (Akamai 2020) | 60% lack full auth (Astrix Labs) | Optional enforcement |
| Security Misconfiguration | Persistent Top 10 | Default debug endpoints in MCP servers | Developer speed bias |
The difference is compression. What took five years to become critical in APIs took five months in MCP.
This acceleration isn't just about faster development cycles. It's about the fundamental mismatch between how quickly systems evolve and how slowly security practices propagate through an ecosystem. Patches and security vendor solutions for vulnerabilities take time.
The Retrofitting Illusion
CISO teams often assume they can harden systems after adoption. History says otherwise.
| Security Stage | Typical Timing | Success Rate |
|---|---|---|
| Preventive design | Pre-deployment | High |
| Mid-cycle retrofit | After first exploits | Moderate |
| Late-stage remediation | After proliferation | Low (<25%) |
API programs tried to retrofit fine-grained access controls years after release — and triggered massive breakage. OAuth 2.0 introduced scoped tokens, but tightening them disabled legitimate clients. Most teams reverted to coarse global credentials.
MCP's upcoming security layers — ETDI (cryptographic tool identity), token delegation (preserving user context through agent chains), and per-user credential translation — face the same adoption gravity. Once thousands of agents and tools depend on permissive defaults, enforcing precision feels riskier than leaving it weak.
Why Retrofitting Fails Structurally
The research on MCP security efforts reveals why retrofits consistently fail:
- Backward compatibility always wins. Enterprises will not break production workloads for new controls.
- Complex systems resist uniform enforcement. Agents, servers, and tools evolve asynchronously.
- Governance cycles move slower than code cycles. Standards take quarters; MCP updates propagate hourly.
- Security upgrades create support crises. Each fix surfaces as a new outage before it becomes a feature.
Even when the OAuth 2.1 specification was updated to include stronger authentication flows, adoption data shows that most servers either don't implement them or make them optional. The security improvements exist on paper but not in practice.
The uncomfortable truth: retrofits don't fail because they're wrong — they fail because they're late and often too complex.
Quantifying Recurrence
Despite a decade of progress, vulnerability recurrence rates in distributed ecosystems remain nearly constant:
| Year / Ecosystem | Avg. critical vulnerabilities per 1,000 services | Source |
|---|---|---|
| APIs (2014) | 58 | Akamai State of the Internet |
| APIs (2023) | 31 | Salt Security Report |
| MCP (2025) | 47 | Equixly + Docker composite scans |
Even with tighter standards and more vendors, the rate of serious flaws per deployment has not improved meaningfully. What changed is time to exposure — now measured in weeks instead of years.
What This Means for Governance
Governance models built for stable infrastructure can't handle dynamic proliferation. Security frameworks like NIST, OWASP, and ISO all assume an observable steady state — an assumption that collapses under continuous recomposition.
The data tells a single story: growth neutralizes control faster than control can mature. When system evolution outpaces policy publication, enforcement devolves into theater.
MCP isn't a failure of innovation — it's proof that innovation alone cannot produce governance. Security must exist independently of protocol design.
Breaking the Retrofit Loop
The alternative to retrofitting is continuous observation from day one. Rather than trying to add security after the fact, organizations need visibility infrastructure that evolves alongside the system it protects.
This approach requires a fundamental shift:
| Phase | Traditional Security Mindset | Observation-First Approach |
|---|---|---|
| 1. Design | Add new auth flows | Observe real data paths first |
| 2. Deploy | Apply generic policies | Infer behavior from actual usage |
| 3. Enforce | Restrict access post-failure | Simulate impact before rollout |
| 4. Sustain | React to incidents | Adapt policies in real time |
Emerging security platforms are building this capability. Instead of assuming what data flows should look like, they observe what actually happens and derive policy from behavior.
For example, systems that build deterministic lineage graphs — tracking every data movement from source through transformation to destination — can identify policy violations without requiring upfront configuration. When a new MCP server starts moving sensitive data inappropriately, the system detects the anomaly based on relationship patterns rather than predefined rules.
Companies like Caber Systems are pioneering this visibility-first approach, treating observation as the control plane rather than enforcement. The philosophy is simple: you can't retrofit what you never saw in the first place.
The Token Delegation Problem
One specific example illustrates why retrofits fail: the token delegation challenge.
APIs have had OAuth delegation for over a decade, yet research shows it's rarely implemented correctly. The same issues exist for MCP:
- Agent → tool call is two hops: The MCP client calls the MCP server; then the MCP server may call tools/APIs. Ensuring the second hop carries the user context and doesn't revert to a blanket service credential is nontrivial.
- No built-in user identity: Many MCP servers treat the "client" or "agent" as a trustful actor without tying operations to a user identity.
- Granularity vs usability: Too fine-grained scoping becomes complex to configure and manage in dynamic agent settings.
Token delegation proposals exist for MCP, just as they existed for APIs. But the same structural forces that prevented API adoption — backward compatibility, operational friction, debugging complexity — are already visible in MCP deployments.
Closing Thought
APIs proved that strong standards can't save systems that evolve faster than they're governed. MCP is proving it faster.
The solution isn't more specification — it's comprehension. Organizations need visibility infrastructure that doesn't depend on perfect protocol design or universal adoption of security features.
Security has always been about control; AI-driven systems demand understanding first. And understanding begins with seeing what's actually happening, not what you hoped would happen.
Next in the series: Part 3 — The Wrong Target: Authorizing Resources When Data Is What Matters
We'll explore why traditional resource-based authorization — controlling access to endpoints and servers — fails in AI ecosystems where data itself is the atomic unit of action. The shift from "who can access this API" to "should this data move" changes everything.