Security & Governance

MCP Security Hardening Checklist: 1,467 Exposed Servers and the Controls That Close Them

By IdeaBosqueLast updated: July 26, 2026

Trend Micro scanned the internet and found 1,467 MCP servers sitting open — no authentication, no encryption, reachable by anyone. Practical DevSecOps found that 82% of 2,614 surveyed servers are vulnerable to path traversal. HashiCorp patched CVE-2026-16496 — the first CVSS 10.0 in the MCP ecosystem — a session-hijacking authorization bypass in Terraform MCP Server's stateful transport mode. A protocol designed to connect AI agents to enterprise systems shipped without a production-security baseline, and the deployment patterns prove it: most teams exposed MCP to the internet before they hardened it. This checklist is the baseline that should have come first — 12 controls across transport, authentication, tool registration, runtime, and audit, each verifiable in under five minutes before an MCP server touches production traffic.

Key takeaways

1,467 MCP servers are publicly accessible with zero authentication or encryption — Trend Micro's corrected scan, July 2026. 1,227 of them run the deprecated SSE transport that the 2026-07-28 spec retires on a 12-month deprecation clock.
82% of 2,614 surveyed MCP servers are vulnerable to path traversal, and only 8.5% use OAuth — Practical DevSecOps MCP Security Statistics 2026 Report. The attack classes are widespread in deployed servers, not theoretical.
3 CVEs landed in the official MCP Python SDK in July 2026, and CVE-2026-16496 (CVSS 10.0) hit Terraform MCP Server on August 5 — the Python SDK CVEs are CVE-2026-59950 (DNS rebinding), CVE-2026-52869 (unverified sessions), CVE-2026-52870 (open task handlers). CVE-2026-16496 is the first maximum-severity MCP CVE — a session-hijacking authorization bypass in the stateful transport mode that the stateless protocol core is designed to eliminate.
78.3% attack success rate when 5 MCP servers connect to 1 agent — Palo Alto Networks Unit 42. Five servers is a typical deployment, not a large one. OX Security identified an architectural RCE affecting 150M+ downloads, and the Cloud Security Alliance classified MCP security as a systemic design-flaw problem.
The MCP 2026-07-28 specification ships as final on July 28, 2026 — all four Tier 1 SDKs (TypeScript, Python, Go, C#) speak the new stateless core, with a 12-month deprecation policy for SSE transport. The migration and the hardening are the same work.

Update — 2026-08-06

HashiCorp patched CVE-2026-16496 (CVSS 10.0) in Terraform MCP Server — the first maximum-severity CVE in the MCP ecosystem. The NVD entry confirms the vulnerability: the terraform-mcp-server before version 1.1.0 is vulnerable to an authorization bypass in the streamable-HTTP stateful transport mode. A user who obtains another user's MCP session ID can have their tool calls executed using that user's Terraform credentials — a session-hijacking vector. Fixed in terraform-mcp-server 1.1.0. (The Hacker News, SentinelOne vulnerability database)

HashiCorp also patched two related vulnerabilities in the same release: CVE-2026-16498 (tenant isolation break in Terraform MCP Server) and CVE-2026-14869 (SSRF flaw in Terraform MCP Server). The three CVEs together mean a single compromised session ID can cross tenant boundaries and reach internal network resources.

This CVE is the first production evidence that the stateful transport mode is a security liability, not just an operational complexity. The MCP 2026-07-28 specification moved to a stateless protocol core precisely to eliminate session-state attack surfaces — the initialize/initialized handshake and Mcp-Session-Id header are removed, and stateful workflows use explicit handles instead of server-side sessions. The Terraform MCP Server CVE validates that design decision: the attack vector (session-ID theft leading to credential reuse) exists only because the server holds a session state that an attacker can steal and reuse. A stateless server has no session to steal. Control 1 (SSE to Streamable HTTP migration) and the stateless protocol core are the controls that close this vulnerability class — not a patch, an architecture.

A production MCP deployment that passes this checklist's 12 controls is not invulnerable — no system is — but it is no longer in the population that Trend Micro found, that Practical DevSecOps scanned, or that the July CVE wave caught. The checklist maps each control to the OWASP MCP Top 10 category it addresses, the CVE or exposure it prevents, and the verification step an operator can run in under five minutes. The Microsoft Agent Governance Toolkit — the first hyperscaler-shipped open-source governance runtime with 10/10 OWASP MCP Top 10 coverage — is the reference implementation. This article is the operational complement: a scannable hardening review for a Head of Engineering or platform lead preparing to expose an MCP server to production traffic.

Update — 2026-08-07: Black Hat 2026 MCP server discovery products — Cyera, SailPoint, Check Point

The full Black Hat 2026 product inventory (crn.com, August 4, 2026) adds three products that directly address Control 12 (shadow server detection) and the MCP server discoverability and governance dimension of this checklist.

Cyera Agent Guardian — shadow MCP server discovery. Cyera launched Agent Guardian to discover shadow MCP servers and unsanctioned AI agents across the enterprise. For Control 12 (shadow server detection), Cyera is the productized version of the inventory-and-drift-monitoring pattern: instead of manually maintaining an MCP server inventory and checking it against a registry, Cyera automatically discovers MCP servers in production — including ones that were never registered. The 1,467 exposed servers Trend Micro found are the internet-facing population; Cyera addresses the internal population — MCP servers running inside the corporate network that no one knows about. A pre-deployment review should now ask: does a discovery tool like Cyera find MCP servers that are not in the official inventory?
SailPoint Identity Security — MCP server identity governance. SailPoint extended its Identity Security platform to cover MCP server identities alongside human and agent identities. For Control 4 (agent identity separation), SailPoint adds MCP servers as a managed identity type — each MCP server has a lifecycle (provisioning, attestation, revocation) managed by the same identity governance infrastructure that handles human identities. An MCP server that loses its attestation is automatically flagged, and its access can be revoked through the identity governance workflow. A pre-deployment review should now ask: are MCP server identities managed in an identity governance platform, or are they ad hoc credentials?
Check Point AI Network Firewall — MCP communications monitoring. Check Point launched an AI Network Firewall that monitors MCP traffic — the communication between agents and MCP servers — for policy violations and data exfiltration. For Control 9 (context boundary), Check Point adds network-layer enforcement: a tool server that attempts to exfiltrate data through its MCP responses is caught at the firewall, not only by the agent's context-scoping logic. The MCP communication channel is now monitorable at the network layer, which closes the gap between application-layer context scoping (Control 9) and the actual traffic that flows between agents and servers. A pre-deployment review should now ask: is the MCP communication channel monitored at the network layer?

The MCP security product category now has dedicated vendors for shadow server discovery (Cyera), identity governance (SailPoint), and network-layer monitoring (Check Point) — three surfaces this checklist's 12 controls address but that previously required custom builds. The 1,467 exposed servers and the 82% path-traversal exposure are the population this checklist closes; the Black Hat 2026 product wave gives operators vendor tools to close them at scale.

The attack surface, in numbers

The OWASP MCP Top 10 (Beta Release v0.1, Phase 3 of 5) catalogs 10 named risk categories across the MCP-enabled system lifecycle. The numbers behind them are what turn "governance is good practice" into "governance is a production gate":

1,467 exposed servers — Trend Micro's corrected scan found 1,467 publicly accessible MCP servers with no authentication or encryption, up from an initial count of 492. 1,227 run the deprecated SSE transport. At least three expose patient medical records via a progress_note tool. The execute_sql tool appears on 70 hosts.
82% path-traversal exposure — Practical DevSecOps measured 82% path-traversal vulnerability and 8.5% OAuth adoption across 2,614 surveyed servers. 97M+ monthly MCP downloads means the exposure scales with adoption.
CVSS 10.0 — the first maximum-severity MCP CVE — CVE-2026-16496 in HashiCorp's Terraform MCP Server, patched August 5, 2026. A user who steals another user's MCP session ID executes tool calls with that user's Terraform credentials. The vulnerability affects only the stateful streamable-HTTP transport mode — the attack surface the stateless protocol core eliminates. HashiCorp also patched CVE-2026-16498 (tenant isolation break) and CVE-2026-14869 (SSRF) in the same release. (The Hacker News)
150M+ downloads affected by architectural RCE — OX Security framed the STDIO command injection root cause as an architectural-level flaw, not isolated CVEs. The Cloud Security Alliance classified it as a systemic design-flaw problem in AI agent infrastructure.
3 SDK CVEs in July 2026 — CVE-2026-59950 (missing Host/Origin validation, DNS rebinding/CSRF), CVE-2026-52869 (unverified session requests), CVE-2026-52870 (open task handlers). The official Python SDK — the reference implementation every Python MCP server inherits from — shipped the same class of flaw as the community servers it underpins.
3 new attack surfaces in the final spec — backslash.security identified three new attack surfaces introduced by the stateless redesign in the 2026-07-28 specification. New capabilities create new entry points that the security community is still mapping.

The cataam.com analysis frames the state of MCP security precisely: "MCP security is roughly where web security sat fifteen years ago — the attacks are old, only the target is new." The hardening checklist below is the set of controls that moved web security from 82% path-traversal exposure to a baseline where production systems are expected to pass. The same controls apply here.

The 12 hardening controls

The checklist organizes around five layers that map to the OWASP MCP Top 10 and the MCP 2026-07-28 specification changes:

Layer 1 — Transport and network

Control 1: SSE to Streamable HTTP migration. The MCP 2026-07-28 specification ships as final on July 28, 2026, with a 12-month deprecation policy for the HTTP+SSE transport. All four Tier 1 SDKs (TypeScript, Python, Go, C#) speak the new stateless core as of publication day, with migration notes for the breaking parts. The 1,227 deprecated-SSE servers in Trend Micro's scan are the population most affected — they run a transport the spec is retiring. The stateless protocol core eliminates server-side session state, which eliminates the session-hijacking attack class: CVE-2026-16496 (CVSS 10.0, the first maximum-severity MCP CVE, patched in Terraform MCP Server on August 5, 2026) is the concrete proof — a user who steals another user's MCP session ID executes tool calls with that user's credentials. The vulnerability exists only in the stateful streamable-HTTP transport mode. A stateless server has no session to steal. Verification: check the server's transport configuration. If it serves SSE or uses stateful streamable-HTTP with Mcp-Session-Id, it is on the deprecation clock and carries the session-hijacking attack surface. Migrate to stateless Streamable HTTP before the 12-month window closes.

Control 2: Network isolation and origin validation. CVE-2026-59950 — confirmed in the National Vulnerability Database — is a missing Host/Origin validation flaw in the official MCP Python SDK. A web page the victim visits can drive their local MCP server via DNS rebinding and CSRF. The browser becomes the attacker's proxy into a loopback server the operator believed was private. Verification: confirm the server validates Host and Origin headers on every request. If the server is internet-facing, confirm it sits behind a network boundary that prevents direct access from untrusted origins. A server that should never have been reachable from the public internet must not be accessible from the public internet.

Layer 2 — Authentication and identity

Control 3: OAuth 2.1 + OIDC enforcement. The 2026-07-28 spec makes OAuth 2.1 plus OpenID Connect mandatory — a shift from the prior "bring your own token" approach. WorkOS's authentication migration guide details the requirements: RFC 8707 (Resource Indicators) to prevent token replay across servers, Client ID Metadata Documents replacing Dynamic Client Registration, issuer verification (RFC 9207). The Practical DevSecOps finding — only 8.5% of surveyed servers use OAuth — is the baseline this control lifts. Verification: check the server's authentication configuration. If it accepts unauthenticated requests or uses static API keys without OAuth, it fails. Confirm the server implements RFC 8707 resource indicators.

Control 4: Agent identity separation. NIST's AI Agent Standards Initiative (February 2026) proposes treating agents as distinct non-human identities with their own lifecycle: provisioning, attestation, revocation. Most deployments authenticate the human user and pass that identity to the agent. When the agent takes an action, the audit log says the human did it. Verification: confirm each agent has its own credential (OAuth token, SPIFFE SVID) distinct from the human operator's. Revoking the agent's identity should stop all agent calls without affecting the human's access.

Layer 3 — Tool registration and supply chain

Control 5: Tool poisoning scan. OWASP MCP03 names tool poisoning as a top-10 risk: rug pulls (trusted tools updated to malicious versions), schema poisoning (interface definitions corrupted to mislead the model), tool shadowing (fake tools intercepting calls meant for real ones). The Microsoft Agent Governance Toolkit's McpSecurityScanner detects tool poisoning, typosquatting, and hidden instructions — a demo tool named read_flie (typosquatting read_file) with injection in its description scored 85/100 risk. Verification: inspect the tool registration process. If tools are registered without a security scan, it fails. The scan must cover prompt injection patterns in descriptions, typosquatting against known tool names, and hidden system directives.

Control 6: Signed provenance and dependency monitoring. OWASP MCP04 covers supply chain attacks and dependency tampering. The Postmark MCP backdoor — the first malicious MCP server caught in the wild — was a legitimate-looking npm package that silently intercepted emails and exfiltrated them. It passed registry review. UpGuard's research found one in 15 MCP servers is a lookalike designed to impersonate a legitimate service. Verification: confirm every MCP server in the deployment has a signed provenance record and an AIBOM (AI Bill of Materials) inventory. Confirm dependency monitoring is active and alerts on new CVEs in the dependency tree.

Control 7: STDIO hardening. OX Security's disclosure identified an architectural RCE in STDIO configurations affecting 150M+ downloads. The root cause: shell: true in the TypeScript SDK enabled command injection via configuration strings. The Cloud Security Alliance classified this as a systemic design-flaw problem. Verification: if the server uses STDIO transport, confirm shell: false or equivalent hardening is set. Confirm command allowlists check arguments, not just binary names — the Upsonic and Flowise bypasses (CVE-2026-30625, CVE-2026-40933) showed that npx -c <malicious-command> passes through an allowlist that checks only the binary.

Layer 4 — Runtime and execution

Control 8: Rate limiting. Each tool declares its own rate limit in the registration call. The backbone enforces limits per-agent, per-tool, and per-window. When a limit is hit, the agent receives a 429 response with a Retry-After header. A compromised agent cannot exhaust upstream API quotas because the rate limit is enforced at the module boundary. Verification: confirm every registered tool has a rate limit. Confirm the limit is enforced at the module boundary, not at the upstream API. A tool without a rate limit is a tool a compromised agent can call without bound.

Control 9: Context boundary. OWASP MCP10 names context injection and over-sharing as a top-10 risk. An agent with broad context access leaks information across tenants, sessions, or users — a particularly acute concern for B2B deployments where the same agent serves multiple customers with different data-access rights. Verification: confirm each tool receives only the context it needs for its specific operation. Confirm the context window is scoped per-tool, not shared globally across all tools. A tool that receives the full session context when it needs only a single field is a data-leak surface.

Control 10: Kill-switch per module. Each MCP module must be independently disableable without touching the orchestration backbone. The kill switch is a configuration change, not a code deployment. When a vulnerability is disclosed — as the July CVE wave disclosed 3 SDK CVEs and 7+ server CVEs in a fortnight — the operator's first question is: can I disable this module without taking down the agent? In a governed deployment, the answer is yes. Verification: confirm each module can be disabled via a feature flag or configuration change. Confirm the disable path has been tested — not just configured. A kill switch that has never been exercised is a kill switch that will fail when it is needed.

Layer 5 — Audit and telemetry

Control 11: Per-call audit logging. OWASP MCP08 names lack of audit and telemetry as a top-10 risk. Without logs of tool invocations and context changes, token theft and injection remain invisible. Every tool call must log timestamp, agent ID, tool name, input hash (not raw input — PII boundary), output status, duration, and upstream system. Logs are structured JSON shipped to the observability pipeline. Verification: confirm every tool call produces a structured log entry. Confirm the log includes the input hash, not the raw input. Confirm the log is immutable — an attacker who compromises the server cannot rewrite the audit trail.

Control 12: Shadow server detection. OWASP MCP09 covers shadow MCP servers — unapproved or unsupervised deployments invisible to governance. UpGuard found one in 15 MCP servers is a lookalike. An engineer who installs the wrong mcp-server-postgress (note the typo) gets a package that silently exfiltrates SSH keys and .env files. Verification: confirm there is an inventory of every MCP server in the deployment. Confirm the inventory is checked against a registry of known-good packages. Confirm drift monitoring alerts when a new server appears that was not in the inventory.

How the frameworks map to the checklist

Control	OWASP MCP	Spec 2026-07-28	Microsoft AGT	NIST	CSA
1. SSE migration	—	12-month deprecation	—	—	—
2. Network isolation	MCP07	Origin validation	—	—	—
3. OAuth 2.1 + OIDC	MCP07	Mandatory auth	—	OAuth 2.0	—
4. Agent identity	MCP07	—	AgentMesh Identity	SPIFFE/SPIRE	—
5. Tool poisoning scan	MCP03	—	MCP Security Gateway	—	—
6. Signed provenance	MCP04	—	—	—	—
7. STDIO hardening	MCP05	—	—	—	Systemic design flaw
8. Rate limiting	—	—	Policy Engine	—	—
9. Context boundary	MCP10	—	Response sanitizer	—	—
10. Kill-switch per module	—	—	Hypervisor kill switch	—	—
11. Per-call audit logging	MCP08	—	Audit + metrics	—	—
12. Shadow server detection	MCP09	—	—	—	—

No single framework covers all 12 controls. The checklist is the intersection of OWASP, the spec, Microsoft, NIST, and CSA — each contributing the controls the others lack. The Microsoft Agent Governance Toolkit covers 10/10 OWASP MCP Top 10 categories (7/10 fully, 3/10 partial with roadmap) and is the first hyperscaler-shipped open-source runtime with explicit OWASP mappings — 68 tests in the Agent OS Policy Engine, 127 tests in the MCP Security Gateway, 80 tests in the Agent Hypervisor Execution Control including the kill switch.

Scoring the checklist

A production-ready MCP server passes all 12 controls. A partially-ready server passes 8–11. A server that passes fewer than 8 should not be exposed to production traffic without a documented remediation plan and a target date for each failed control.

Score	Status	Action
12/12	Production-ready	Deploy with monitoring
8–11/12	Partially ready	Deploy with documented exceptions and remediation timeline
<8/12	Not ready	Do not deploy. Remediate failed controls first

The most common failure pattern is passing controls 1–4 (transport, authentication, identity) while failing controls 5–12 (supply chain, runtime, audit). The first four are architectural and get attention in design reviews. The last eight are operational and get missed until an incident or an audit surfaces them. The July 2026 CVE wave — 3 SDK CVEs and 7+ server CVEs in a fortnight — is what happens when the operational controls are absent. The August 5 Terraform MCP Server CVSS 10.0 (CVE-2026-16496) is what happens when the transport control is absent: the stateful session is the attack surface, and a stolen session ID becomes a credential-reuse vector.

Update — 2026-08-08: Skill/Plugin Security Scanning — the vendor-side supply-chain control

Anthropic shipped Skill/Plugin Security Scanning on August 6, 2026 — the first model-vendor-side supply-chain mitigation for third-party tool servers. The scanning inspects third-party Claude Code uploads (skills and plugins) for malicious content before they reach the marketplace. This directly addresses Control 5 (Tool poisoning scan) from the vendor side: Control 5 governs the scanning you do on your own tool definitions; Skill/Plugin Scanning governs what the model vendor does on its marketplace before the tool reaches you.

The "9 of 11 MCP marketplaces accepted poisoned PoC submissions" finding — the supply-chain gap this checklist's Control 5 (tool poisoning scan) and Control 6 (signed provenance) address — now has a vendor-side mitigation. The implication for the 12-control checklist: Control 5 has a new dimension. A tool sourced from a marketplace that performs vendor-side scanning (like Claude Code with Skill/Plugin Scanning) arrives with a vendor-attested safety baseline. A tool sourced from a marketplace that does not scan arrives without that baseline — and Control 5's scanning must compensate by treating every unscanned tool as higher risk.

The 88% production-failure framework (digitalapplied.com, August 6, 2026) quantifies the cost: security blockers account for 14% of AI agent project failures. Vendor-side supply-chain scanning reduces the probability that a malicious tool reaches the agent — but only for marketplaces that implement it. For the broader MCP ecosystem, the 12-control checklist remains the production-security baseline, and Control 5 remains the control that catches what the marketplace did not.

Update — 2026-08-20: Spring AI MCP SSRF CVE-2026-45609 — new MCP CVE class in the Java/Spring ecosystem

SentinelOne disclosed CVE-2026-45609 — an unauthenticated SSRF vulnerability in the Spring AI mcp-security framework. This is the first MCP CVE in the Java/Spring ecosystem and the first to exploit framework-level server-side request handling rather than the transport layer or SDK. The vulnerability allows an attacker to make the MCP server send requests to arbitrary endpoints without authentication.

For the 12-control checklist, this CVE adds a new verification dimension to Control 1 (transport authentication) and Control 5 (tool poisoning defense): Java/Spring teams deploying MCP servers must verify that the framework's request handling is authenticated and that SSRF protections (allowlist-based egress filtering, internal-network access restrictions) are in place. The framework-managed MCP server is not exempt from the authentication control just because the framework handles setup — the framework's request handling is itself an attack surface. The SSRF vector means a compromised MCP server can reach internal network resources that the application-layer controls do not protect. See the MCP Paradox article for the frictionless-to-fragile mapping of this CVE class and the MCP Module Code Standard for the Java/Spring deployment baseline.

Update — 2026-08-18: OWASP GenAI MCP Server Security Baseline, MCP Project Sandboxing Baseline, MCP Ruby SDK and file server bugs — three new standards and new CVE classes

Three developments in the August 16-18 window add two new MCP security standards and new CVE classes to the hardening checklist's evidence base: a development-controls baseline from OWASP GenAI, a deployment-controls baseline from the MCP Project's own spec authors, and two new vulnerability classes in the MCP Ruby SDK and a file server component.

OWASP GenAI MCP Server Security Baseline (August 18) — development controls. OWASP GenAI published a practical guide for secure MCP server development covering authentication, authorization, session isolation, input validation, and hardened deployment. This is distinct from the OWASP MCP Top 10 (which catalogues risks) and the MCP Project's sandboxing baseline (deployment controls, below). The three together form a layered MCP security framework: OWASP MCP Top 10 (risk catalogue, Beta v0.1), OWASP GenAI MCP Server Security Baseline (development controls), MCP Project Sandboxing Baseline (deployment controls). For this checklist, the OWASP GenAI baseline is the development-time reference standard against which audit readiness will be measured. Controls 1-12 in this checklist map to the OWASP GenAI baseline's development controls — the baseline is the standard, this checklist is the operational verification. A pre-deployment review should now ask: does the MCP server's development process follow the OWASP GenAI MCP Server Security Baseline, or was it built without a reference standard?
MCP Project Sandboxing Baseline (August 16) — deployment controls from the spec authors. The Model Context Protocol project published formal security best practices requiring sandboxing or containerization for spawned processes and restricting file system access for MCP servers. This is the protocol's own security baseline — the most authoritative MCP-server-hardening guidance available, coming from the spec authors. Combined with the DeepSeek Harness sandboxing pattern (Landlock/Seatbelt/Windows ACL, documented in the Aug 17 update), the production pattern is now: sandbox every spawned process, restrict file system access, treat all custom and third-party MCP components as untrusted. For this checklist, the MCP Project sandboxing baseline is the reference for Control 8 (runtime sandboxing) — the spec authors are now saying what this checklist recommended. A pre-deployment review should now ask: does the MCP server sandbox spawned processes per the MCP Project's own baseline, or does it run without OS-level containment?
MCP Ruby SDK and file server bugs (August 16) — new CVE classes. Security researchers at Mallory.ai documented a denial-of-service vulnerability in the MCP Ruby SDK and a file-disclosure flaw in an MCP server component caused by insufficient path validation. The Ruby SDK DoS (resource exhaustion) and file-server directory traversal are new attack classes not previously in the CVE timeline. The MCP CVE catalogue now spans Python, TypeScript, Java, Ruby, and C# SDKs, plus application-layer MCP servers. For this checklist, the Ruby SDK DoS extends Control 5 (rate limiting) to resource-exhaustion attack classes, and the file-server directory traversal extends Control 3 (tool registration input validation) to path-validation attack classes. The "treat all MCP components as untrusted" guidance directly validates this checklist's defensive posture — every custom and third-party MCP component is a potential attack surface, regardless of the SDK language. See the MCP Module Code Standard for the CoSAI token-exchange standard as the authorization pattern for MCP-mediated agent-to-tool handoffs.

The three new standards/baselines do not replace the 12 controls — they provide the reference frameworks against which the controls are verified. The layered MCP security framework is now: OWASP MCP Top 10 (what the risks are), OWASP GenAI MCP Server Security Baseline (how to develop securely), MCP Project Sandboxing Baseline (how to deploy securely), and this checklist (how to verify before production). The CVE catalogue spanning five SDK languages confirms that the attack surface is protocol-wide, not implementation-specific.

Update — 2026-08-17: CVE-2026-75011 NetForensicMCP and the Forcepoint data-exposure control dimension

Two developments extend this checklist: a new STDIO command injection CVE and a new control dimension — data exposure — that Forcepoint reframed as a first-class MCP security concern.

CVE-2026-75011 — NetForensicMCP 2.1.0 command injection. kylecui's NetForensicMCP 2.1.0 contains a command injection vulnerability in the execAsync function of index.js — medium severity, remotely exploitable, exploit published. The root cause is the same STDIO command injection class as CISA KEV CVE-2026-42271 (LiteLLM) and the OX Security Family 1 (9 CVEs). Closed by Control 1 (tool registration — sanitize all inputs to subprocess execution) and Control 7 (STDIO hardening — no user-controlled input in command strings). The CVE adds to the growing STDIO command injection inventory and reinforces that Control 7 is not a theoretical defense — it is the control that closes an actively exploited vulnerability class.
Forcepoint data-exposure reframing — a new control dimension. Forcepoint published "MCP Security Overlooks the Data Your AI Agents Can Reach" (August 10, 2026). Core thesis: "authentication fixes the door, not the data." The Postmark MCP backdoor (already cited in this article's supply-chain section) is recontextualized as a data-exposure incident: the postmark-mcp package quietly added a hidden recipient to every email an AI agent sent — no crash, no alert, just a slow silent leak. The MCP server is a pivot point for data exfiltration, and the current 12-control checklist addresses code vulnerabilities and authentication but does not explicitly address data-scoped enforcement. Four governance questions from Forcepoint that extend the checklist:
- Does the agent hold direct credentials, or brokered ones? Direct credentials give the agent full access to the upstream system's data surface. Brokered credentials (the agent authenticates through a proxy that scopes the token to specific fields or actions) limit the blast radius of a compromised server. This extends Control 4 (authentication) from "is the agent authenticated?" to "what is the credential's data scope?"
- Is enforcement scoped to the field, or the application? Application-level enforcement ("the agent can access the CRM") is too coarse — a compromised MCP server can exfiltrate any field the application exposes. Field-level enforcement ("the agent can read customer name and order status, not payment details") limits data exposure to the minimum required for the task. This extends Control 10 (context boundary) from the tool surface to the data surface.
- Are high-risk actions gated by a human? The kill-switch pattern (Control 11) already gates tool execution. The data-exposure dimension adds: actions that access sensitive data fields (PII, financial, health) should require human approval regardless of whether the tool itself is high-risk. The gate is on the data, not just the tool.
- Is there a full attribution trail? Control 12 (audit logging) already requires per-tool-call logging. The data-exposure dimension extends the audit trail to include: agent identity, triggering user, data fields accessed, and action taken — not just tool name and input hash. The attribution trail is the artifact that surfaces a slow silent leak like the Postmark backdoor pattern.

The Forcepoint data-exposure dimension does not replace the existing 12 controls — it extends them from the code and authentication surface to the data surface. The pattern is the same as the CISA KEV designation: each new MCP security development validates a control and adds a dimension. See the MCP Paradox article for the frictionless-to-fragile mapping of the data-exposure dimension and the governance checklist for the four governance questions as pre-deployment review items.

Update — 2026-08-09: CISA KEV CVE-2026-42271 — the first MCP-adjacent CVE with a federal remediation mandate

CISA added CVE-2026-42271 (BerriAI LiteLLM, CVSS 8.7) to its Known Exploited Vulnerabilities catalog — the first MCP-adjacent CVE to receive the KEV designation. The vulnerability stems from two MCP server testing endpoints in LiteLLM versions 1.74.2 through 1.83.6 that allowed authenticated users to supply custom server configurations including commands and environment variables, executed as subprocesses without role-based access controls — the same STDIO command injection root cause documented in the OX Security advisory. Fixed in LiteLLM 1.83.7.

For the 12-control checklist, the KEV designation is a control-justifying CVE. The testing-endpoint command injection is closed by Control 1 (tool registration — the testing endpoint must not accept arbitrary server configurations from non-admin users) and Control 4 (authentication — subprocess execution must require role-based authorization). The KEV mandate means these controls are no longer best practices; for federal agencies and their contractors, they are compliance requirements with a remediation deadline. The broader implication: every MCP-adjacent proxy that passes user-controlled server configurations to subprocesses without role-based access controls carries the same vulnerability class — the KEV designation is the federal signal that this class is being actively exploited, not just theoretically present. See the MCP Paradox article for the frictionless-to-fragile mapping and the Kill Switch by Design article for how the KEV designation elevates the kill-switch supply-chain threat.

Update — 2026-08-23: MCP New Roadmap — agent identity and progressive discovery as checklist extensions

On August 22, 2026, the MCP maintainers published a new roadmap defining five priority areas for the next specification cycle. Two of them extend the 12-control checklist:

Agent identity and enterprise-ready security — the roadmap recognizes that "more and more of the callers are agents running as cloud workloads with their own identity, acting on behalf of a user who isn't present, or delegating narrower authority to sub-agents." The path forward includes DPoP (RFC 9449) to bind OAuth tokens to a client-held key, Workload Identity Federation via the IETF WIMSE working group, and the Enterprise-Managed Authorization (EMA) extension for central assignment and revocation. For the checklist, this extends Control 4 (authentication): the OAuth 2.1 baseline should be augmented with DPoP binding for agent callers, and the token-exchange pattern (task-scoped tokens at every trust boundary) should be verified before production. The CoSAI token-exchange standard (published August 18) establishes token exchange as a foundational control for agentic workflows — every register_tools() entry point should accept a task-scoped token, not a persistent credential.
Progressive tool discovery — the roadmap addresses the "hundred tools" problem where tool selection degrades as the list grows. The 2026-07-28 spec provides server/discover RPC and tools/list with ttlMs and cacheScope cache hints. For the checklist, this is a Control 5 (tool poisoning scan) and Control 8 (context boundary) extension: a server with 50+ tools should expose a discover_tools entry point that returns a focused subset, rather than dumping all tool schemas into the model's context window. Progressive discovery keeps the context window lean and reduces the attack surface the model can invoke at any given step.

See the MCP Tutorial for a hands-on production walkthrough covering agent identity setup, DPoP binding, and progressive discovery implementation.

Update — 2026-08-27: Microsoft six-risk-area framework + RufRoot CVE-2026-59726 — vendor framework and the most severe MCP CVE

Microsoft "State of MCP Security in 2026" (June 26, newly surfaced). Microsoft Security Blog — six risk areas: (1) prompt injection and tool poisoning, (2) authorization and the confused deputy (OAuth 2.1 + PKCE + audience-bound tokens), (3) over-broad access and credential aggregation, (4) supply chain and rug pulls, (5) shadow MCP, (6) command injection and sandbox escape. Azure controls: API Management for token validation, Entra Agent ID for agent identity governance, API Center for server inventory, OWASP MCP Top 10 mapped to Azure controls. For the 12-control hardening checklist, the Microsoft framework is the first major-vendor validation of the controls this checklist operationalizes. The "shadow MCP" framing (visibility into all MCP servers, including ones deployed without central IT approval) is a new control dimension — add a runtime gateway that surfaces unregistered shadow servers. The "rug pull" pattern (server behaves during review, changes after approval) is a new supply-chain control — pin tool definitions and alert on drift. The OAuth 2.1 + PKCE + audience-bound tokens guidance is the authorization model the checklist's authentication controls should reference.
RufRoot CVE-2026-59726 (CVSS 10.0). Noma Labs: 233 tools exposed over HTTP with zero authentication, full 8-step compromise chain (recon, RCE, API key theft, agent weaponization, AI memory poisoning, conversation theft, persistent backdoor, cleanup). Six additional disclosures: GitLost, ContextCrush, GrafanaGhost, Gemini Enterprise prompt injection, Salesforce Agentforce, DockerDash. For the 12-control checklist, RufRoot validates every transport and authentication control: the 233 unauthenticated tools are the exposure that the SSE migration + OAuth 2.1 controls close. The agent weaponization step (tools co-opted to attack infrastructure) is the consequence that the tool-poisoning scan control prevents. The persistent backdoor step is the consequence that the audit logging control detects. Noma-Kiro partnership (August 26): AI security as native layer inside agent runtimes — the runtime-layer enforcement pattern.

Update — 2026-09-08: CISA KEV CVE-2026-59822 — Streamable HTTP authentication bypass (deadline Sep 16)

CISA added CVE-2026-59822 (BerriAI LiteLLM, CVSS 8.8) to its Known Exploited Vulnerabilities catalog on September 2, 2026, with a federal remediation deadline of September 16 — the second MCP-adjacent KEV designation after CVE-2026-42271. The vulnerability is a Streamable HTTP authentication bypass in LiteLLM versions prior to 1.84.0: a faulty OAuth2 passthrough fallback replaces failed LiteLLM key validation with an empty UserAPIKeyAuth() object instead of terminating the request, allowing unauthenticated access to any tool the proxy exposes. This is a different root cause from CVE-2026-42271 (testing-endpoint STDIO command injection) — CVE-2026-59822 is an authentication bypass in the Streamable HTTP transport itself.

For the 12-control checklist, CVE-2026-59822 is a Control 4 (authentication) failure with a new dimension: passthrough authentication patterns must fail closed, not open. An empty auth object is not a valid identity; the request must terminate, not proceed. The verification step for Control 4 should now include: confirm that OAuth2 passthrough fallbacks reject requests when upstream validation fails, rather than substituting an empty or default auth object. Every MCP proxy that delegates authentication to an upstream provider via OAuth2 passthrough carries this vulnerability class — the KEV designation means it is being actively exploited, not just theoretically present. See the MCP Paradox article for the frictionless-to-fragile mapping.