Two weeks ago, Wiz Research published a bombshell: they scanned cloud environments and found MCP (Model Context Protocol) servers in 80% of them.
The numbers from their research:
- 1 in 6 cloud environments expose at least one MCP server to the internet
- ~70% of exposed servers return their full tool catalog to anonymous callers
- ~42% return real data when a tool is called
- ~10% expose a sensitive backend, including cloud metadata credentials via SSRF
Most of these servers are running pre-authentication MCP. In production. In Fortune 500 companies.
The Verification Badge Problem
If you think we only use verified MCP servers from the official registry, a separate study published in GB Hackers should change your mind.
Researchers analyzed 9,695 MCP servers across GitHub, Glama, Lobehub, and PulseMCP:
| Category | Count |
|---|---|
| Arbitrary file access | 880 |
| Command injection flaws | 476 |
| SSRF vulnerabilities | 422 |
| SQL injection issues | 211 |
| No authentication | 2,054 |
Total: 4,982 distinct security issues across 5,832 servers.
The researchers noted that popularity, repository activity, and verification badges do not reliably reflect security posture.
A popular MCP server with 200K+ downloads still handed attackers full account takeover. Pluto Security found CVSS 9.8 and 9.6 vulnerabilities in gitlab-mcp, the most popular community GitLab MCP server. No credentials to guess. No user interaction needed.
The New MCP Spec Makes It Your Problem
On July 28, 2026, the MCP specification moved to a stateless architecture under the Linux Foundation Agentic AI Foundation. The biggest change since the protocol was created.
Session hijacking is gone. Legacy auth is gone (OAuth 2.1 is mandatory). Unsolicited server prompts are gone.
But the trade-off: security responsibility shifts to the developers and operators implementing MCP servers.
The spec tells you to verify state object integrity but does not tell you how. It tells you to validate _meta fields but does not provide the validation. This is exactly where runtime verification becomes non-optional.
What Runtime Verification Checks
Static analysis scans your code before deployment. Runtime verification watches what actually happens when your MCP server processes real requests in production.
Configuration drift: Your MCP server was secure at deployment. Three config changes later, a tool can read /proc/self/environ. Static analysis will not catch that.
Supply chain updates: A dependency update changes a default. Now a header redirects credential-bearing requests to any host. You would not know until someone exploits it.
Composability gaps: Each tool is individually safe. But chained together, they create a path from read file to exfiltrate SSH key. Only runtime verification sees the full trajectory.
A proper runtime verification framework validates across 6 dimensions:
- Structure: Does the tool request match its declared schema?
- Schema: Are field types, ranges, and constraints respected?
- Latency: Is response time consistent or is something intercepting?
- Cost: Is the model called more times than expected?
- Identity: Is the caller who they claim to be?
- Integrity: Is the output what the tool actually produced?
The Conformance Check Specification (CCS) (DOI: 10.5281/zenodo.21603250) defines this 6-dimensional verification model. Palo Alto Networks AI Research Lab referenced it in their contribution to Microsoft Semantic Kernel (PR #14199). Overhead: P50 under 10 microseconds.
What You Can Do Today
1. Inventory your MCP exposure. Check if MCP endpoints are reachable without authentication from your network.
2. Check protocol version. If your servers still negotiate 2024-11-05, they are pre-authentication. Update immediately.
3. Verify, do not trust. Badges and popularity metrics are not security controls. Run an actual security scan.
4. Add runtime verification. For production MCP servers, validate every tool call across all 6 dimensions. Log everything. Alert on anomalies.
The Uncomfortable Truth
MCP is in your infrastructure. The protocol just had its biggest security overhaul, which means the security bar moved from the protocol handles it to your implementation handles it.
The question is not whether you need runtime verification. It is whether you will do it before or after your MCP server ends up in the next Wiz research report.
Sources:
- Wiz Research (July 28, 2026)
- GB Hackers (July 7, 2026)
- Pluto Security (July 6, 2026)
- CCS Specification DOI: 10.5281/zenodo.21603250
Top comments (1)
The inventory step is load-bearing, and I’d separate four states that security dashboards often collapse: an MCP package exists, a server process is running, an endpoint is reachable, and an unauthenticated caller can invoke a meaningful capability. Those imply very different remediation urgency.
For each endpoint, the inventory should preserve evidence: owner, environment, network path, negotiated protocol version, auth result, server/image digest, tool-catalog digest, effective downstream identity, and whether a harmless canary call actually crossed the boundary. Re-run it across identities and regions; a 401 from the scanner’s subnet does not prove the production path is protected.
Runtime verification also needs an enforcement contract. “Log and alert” can be too late for a write or exfiltration call. Classify controls as observe, block, require approval, or quarantine; define fail-open/fail-closed behavior; and test detection-to-block latency, revocation propagation, tool-catalog drift, chained-tool attacks, and verifier outage.
That turns a percentage headline into an actionable asset register—and makes “verified” a reproducible state with evidence and expiry, not another badge.