The New MCP Specification: What Security Teams Must Prepare For
The upcoming MCP 2026-07-28 specification fundamentally reshapes the protocol's security model by moving to a stateless architecture, eliminating protocol-managed sessions, and mandating OAuth 2.1 with PKCE. While this removes historical attack vectors like session hijacking and unsolicited server prompts, it introduces new risks: client-controlled state objects and tracking IDs enable cross-agent workflow hijacking, the _meta object allows metadata-based privilege escalation, new HTTP headers create desync and data leakage opportunities, MCP Apps bring stored XSS into AI interfaces, and asynchronous tasks introduce resource exhaustion DoS vectors. Security responsibility now rests squarely on MCP server developers and platform operators to implement cryptographic state verification, input validation, output encoding, and resource quotas.
Detection / Hunteropenrouter
What Happened
A widely used protocol called MCP (Model Context Protocol), which connects AI tools to external systems, is getting a major update on July 28, 2026. The update makes the protocol better suited for large organizations by removing some old security problems — like session hijacking and weak passwords — and requiring stronger authentication. However, the changes also create new security risks that developers must handle themselves. For example, because the protocol no longer remembers who users are between requests, it hands out tracking identifiers that attackers could guess or tamper with to access other people's data. The update also introduces interactive visual panels inside AI apps that could be abused to inject malicious code (similar to how websites can be hacked), and a new feature for long-running background tasks could be exploited to overwhelm servers. Organizations using or planning to use MCP should ensure their developers treat all client-provided data as untrusted, enforce strict validation, and implement resource limits to prevent abuse.
Key Takeaways
- MCP specification transitions to a stateless, enterprise-grade architecture on July 28, 2026, shifting security boundary responsibility from the protocol to individual developers.
- Legacy risks eliminated include protocol-level session hijacking (Mcp-Session-Id), unsolicited server prompts via SSE, and weak authentication — replaced by mandatory OAuth 2.1 with PKCE.
- New attack surfaces include cross-agent workflow hijacking via predictable tracking IDs or tampered state objects, _meta object metadata manipulation for privilege escalation, and HTTP header confusion/desync attacks between HTTP and JSON-RPC layers.
- MCP Apps introduce stored XSS risk inside AI interfaces (e.g., Claude Desktop); sandboxed iframes mitigate full takeover but phishing and data exfiltration from visible panels remain possible.
- Asynchronous long-running tasks create a cheap-to-create, expensive-to-process DoS vector where attackers spawn resource-intensive operations and immediately disconnect.
Affected Systems
- MCP servers implementing the 2026-07-28 specification
- MCP clients and AI applications using MCP (e.g., Claude Desktop)
- Cloud-native MCP enterprise deployments
- Intermediaries, proxies, and gateways routing MCP traffic
Attack Chain
The article describes a protocol-level architectural shift rather than a specific attack campaign. In the new stateless MCP architecture, an attacker could exploit multiple vectors: (1) guess or tamper with client-provided tracking IDs and state objects to hijack another user's workflow or access cross-tenant data, (2) inject malicious key-value pairs into the _meta object to escalate privileges or bypass authorization, (3) send conflicting values between HTTP headers and JSON-RPC body to desynchronize proxies and bypass security controls, (4) store malicious JavaScript via MCP tools that executes when another user or AI agent views the content in an MCP App panel, enabling phishing and data exfiltration, or (5) spawn numerous expensive asynchronous tasks and immediately disconnect, exhausting server resources.
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
No detection rules, queries, or signatures are provided in the article. The content is an architectural analysis and advisory piece with no actionable detection logic.
Detection Engineering Assessment
EDR Visibility: Low — The threats described are protocol-level and application-layer issues within MCP implementations. EDR agents would not natively inspect MCP message payloads, _meta objects, or HTTP header-to-JSON-RPC body consistency. Visibility would depend on custom application logging or API gateway inspection. Network Visibility: Medium — Network-level inspection of MCP HTTP headers (Mcp-Method, Mcp-Name) and JSON-RPC body consistency could detect desync attempts and header-based data leakage. However, distinguishing legitimate from malicious _meta metadata or tracking ID tampering requires application context not available at the network layer. Detection Difficulty: Hard — Detecting these threats requires deep inspection of MCP-specific protocol semantics, including validating state object integrity, comparing HTTP header values against JSON-RPC body fields, monitoring _meta object contents for authorization claims, and correlating async task creation with resource consumption. No off-the-shelf detection content exists for these protocol-specific behaviors.
Required Log Sources
- MCP server application logs with request/response payloads
- API gateway or reverse proxy logs capturing HTTP headers and JSON-RPC bodies
- OAuth 2.1 authorization server token issuance and validation logs
- Web application firewall (WAF) logs for MCP endpoints
- Server-side resource utilization metrics for async task monitoring
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for MCP requests where the Mcp-Method or Mcp-Name HTTP header values conflict with the corresponding method or name fields in the JSON-RPC request body, which could indicate protocol desync attempts (T1190). | API gateway or reverse proxy logs capturing both HTTP headers and request body content for MCP endpoints. | Initial Access / Defense Evasion | Medium — legitimate proxies or SDKs may rewrite headers in ways that create transient mismatches; correlation with downstream anomalous behavior would reduce false positives. |
| Consider hunting for MCP requests containing _meta objects with authorization-related keys such as 'tenant', 'authenticated', 'role', or 'admin' that originate from client-side input, which could indicate privilege escalation attempts (T1548). | MCP server application logs capturing full request payloads including _meta object contents. | Privilege Escalation | Low to Medium — legitimate clients may include routing metadata, but authorization-claim keys from clients are inherently suspicious. |
| Consider hunting for rapid creation of multiple asynchronous MCP tasks from a single client or IP address followed by immediate disconnection, which could indicate resource exhaustion DoS attempts (T1499.002). | MCP server task creation logs and server-side resource utilization metrics (CPU, memory, database connections). | Impact | Medium — legitimate batch processing or automated workflows may create many tasks; correlation with resource exhaustion thresholds would improve accuracy. |
| Consider hunting for MCP tool responses containing HTML or JavaScript content that is rendered in MCP App panels, which could indicate stored XSS injection (T1059.007). | MCP server response payloads and client-side rendering logs from AI applications supporting MCP Apps. | Execution / Collection | Medium — some MCP tools may legitimately return HTML content; focus on script tags, event handlers, and external resource references. |
| Consider hunting for MCP requests where tracking IDs or state objects are reused across different authenticated users or tenants, which could indicate cross-agent workflow hijacking (T1078). | MCP server application logs correlating tracking IDs and state objects with authenticated user/tenant context. | Credential Access / Lateral Movement | Low — tracking ID reuse across distinct users is inherently anomalous and should not occur in properly implemented systems. |
Control Gaps
- Standard WAF rules would not detect _meta object metadata manipulation because the malicious content is within a legitimate JSON field.
- Network-level IDS/IPS would not detect tracking ID guessing or state object tampering without application-layer correlation.
- Traditional XSS detection in WAFs may not cover MCP App rendering contexts inside AI application interfaces.
- Rate limiting on task creation endpoints may not account for the asymmetric cost of async task processing versus request creation.
- OAuth token validation alone would not prevent attacks where the client supplies authorization claims via _meta metadata.
Key Behavioral Indicators
- Mismatches between Mcp-Method/Mcp-Name HTTP headers and JSON-RPC body method/name fields
- Presence of authorization-related keys (tenant, authenticated, role, admin) in client-supplied _meta objects
- High volume of async task creation requests from a single source followed by connection termination
- MCP tool responses containing inline JavaScript or external script references rendered in MCP App iframes
- Tracking IDs or state objects appearing in requests from different authenticated users or tenants
False Positive Assessment
- Medium — Several of the described attack patterns (header mismatches, _meta metadata with routing keys, high async task volume) could have legitimate explanations in properly functioning MCP implementations. Detection would require application-layer context and correlation to distinguish malicious activity from normal protocol usage.
Recommendations
Immediate Mitigation
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider auditing any existing MCP server implementations for proper validation of client-provided tracking IDs and state objects, ensuring cryptographic integrity verification (e.g., signed state tokens) is in place.
- If your organization operates MCP servers, consider evaluating whether _meta object contents are validated against an allowlist and whether authorization decisions are made solely from server-side OAuth token claims, not client-supplied metadata.
- If applicable to your environment, consider inspecting MCP API gateway or proxy configurations for header-to-body consistency validation on Mcp-Method and Mcp-Name fields to detect desync attempts.
Infrastructure Hardening
- Consider implementing strict resource quotas and per-client rate limits on asynchronous task creation endpoints to mitigate the DoS vector described.
- Evaluate whether your API gateway or WAF can inspect and block sensitive data (API keys, tokens, PII) from being mapped into HTTP headers via the x-mcp-header directive.
- If deploying MCP servers, consider enforcing server-side state object signing (e.g., HMAC or JWT) to prevent client tampering with tracking IDs and state.
- Consider implementing output encoding and CSP headers for MCP App rendering contexts to mitigate stored XSS impact.
User Protection
- If your organization uses AI applications with MCP Apps (e.g., Claude Desktop), consider evaluating whether sandboxed iframe isolation is properly enforced for interactive panels.
- Consider educating users who interact with MCP-powered AI interfaces about the risk of deceptive content or phishing prompts displayed within trusted AI application panels.
Security Awareness
- Consider incorporating MCP protocol security awareness into existing developer training programs, emphasizing that client-provided state, metadata, and headers must be treated as untrusted input.
- If your development teams build MCP servers, consider rolling out guidance on implementing cryptographic state verification, OAuth 2.1 with PKCE, and output encoding for MCP Apps into existing secure coding standards.
MITRE ATT&CK Mapping
- T1059.007 - Command and Scripting Interpreter: JavaScript
- T1190 - Exploit Public-Facing Application
- T1499.002 - Endpoint Denial of Service: Service Exhaustion Flood
- T1078 - Valid Accounts
- T1548 - Privilege Escalation
