MCP Server MessageChannel Security: private port transfer, cross-context pipe hijacking, and iframe privilege escalation

How MessageChannel works — and what makes it dangerous

MessageChannel is instantiated with new MessageChannel(), which creates two MessagePort objects: channel.port1 and channel.port2. Either port can send messages to the other via port.postMessage(data, [transfer]), and both ports receive messages via port.onmessage or port.addEventListener('message', handler). Calling port.start() is required when using addEventListener (the onmessage setter automatically starts the port).

// Creating a private channel between the main window and a worker
const channel = new MessageChannel();
const worker = new Worker('/worker.js');

// Transfer port2 to the worker — the main window now owns port1 only
// port2 is "transferred": this context can no longer use it
worker.postMessage({ type: 'init', port: channel.port2 }, [channel.port2]);

// Main window uses port1 to talk privately to the worker
channel.port1.onmessage = (event) => {
  console.log('Worker replied:', event.data);
};
channel.port1.postMessage({ type: 'execute', command: 'fetch-user-data' });

// worker.js: receives port2 and uses it for private communication with main
self.onmessage = (event) => {
  if (event.data.type === 'init') {
    const port = event.data.port;
    port.onmessage = (e) => {
      // Execute commands arriving on the private port
      if (e.data.type === 'execute') {
        // ... privileged action
        port.postMessage({ result: 'done' });
      }
    };
  }
};

The key security property is that port2 is now inside the worker's JavaScript context. No other script — no matter what origin — can read messages on that channel unless it has a reference to one of the ports. The problem is: the transfer target is determined at runtime by whoever calls worker.postMessage(). If tool output can inject a script that calls worker.postMessage({ type: 'init', port: attackerPort }, [attackerPort]) with a port it controls, the channel initialization is hijacked.

The structured clone algorithm and port ownership transfer

When a MessagePort is passed in the transfer list of postMessage, the structured clone algorithm transfers ownership rather than copying the object. After the transfer, the original holder's port reference enters a "detached" state — calling methods on it throws DOMException: Failed to execute 'postMessage' on 'MessagePort': The object is detached. This is intentional: exactly one context should own each port end at any time.

The MCP tool output attack surface

MCP server UIs frequently use MessageChannel to build private communication channels between the main window and privileged workers or sandboxed iframes. Common patterns include:

• An audit worker that runs analysis on tool output and communicates results back via a private channel
• A sandboxed iframe rendering tool output HTML, with the main window holding port1 to send directives (scrollTo, highlight, dismiss)
• A crypto worker holding signing keys, accessible only via port messages from the main window
• A session worker that manages authentication tokens, responding to requests over a MessageChannel port

In each case, the security of the private channel depends on who controls the port. If tool output can trigger any of the following, the channel is compromised:

Secure MessageChannel patterns for MCP server UIs

1. Never transfer ports into tool output rendering contexts

The fundamental rule: tool output is untrusted. Do not send a privileged MessagePort to any iframe or worker that renders or executes tool output. If you need to communicate with a sandboxed iframe that displays tool output, use a one-way channel (only port1 to iframe, no port2 back path) or implement a deliberate proxy that sanitizes messages before forwarding.

// DANGEROUS: parent transfers privileged port into tool output iframe
const channel = new MessageChannel();
const iframe = document.getElementById('tool-output-iframe');

// Don't do this — the iframe contains tool output which may be attacker-controlled
iframe.contentWindow.postMessage(
  { type: 'init-port', port: channel.port2 },
  '*',          // ← no origin validation
  [channel.port2]
);

// CORRECT: separate rendering iframe (tool output) from communication iframe
// Tool output iframe: sandboxed, no postMessage back path
// Communication iframe: origin-verified, handles privileged port only
const trustedIframe = document.getElementById('trusted-comms-iframe');
trustedIframe.contentWindow.postMessage(
  { type: 'init-port', port: channel.port2 },
  'https://skillaudit.dev',   // ← exact origin required
  [channel.port2]
);

2. Validate port initialization with a challenge-response handshake

When a worker receives a port during initialization, have it perform a challenge-response with the main window before accepting the port as legitimate. This doesn't fully prevent port hijacking (an attacker who can inject scripts before the legitimate init can still win the race), but it prevents late-arriving reinit attacks:

// worker.js: challenge-response port initialization
let trustedPort = null;
const EXPECTED_NONCE = crypto.randomUUID(); // Set at worker creation time via initial postMessage

self.onmessage = (event) => {
  if (event.data.type === 'init' && trustedPort === null) {
    // First init wins — reject all subsequent init messages
    const port = event.data.port;
    if (event.data.nonce !== EXPECTED_NONCE) {
      // Nonce mismatch: reject the port and close it
      port.close();
      return;
    }
    trustedPort = port;
    trustedPort.onmessage = handlePrivilegedMessage;
  }
  // Silently drop any re-init attempt after trustedPort is set
};

3. Explicitly close ports when done

Calling port.close() prevents memory leaks and ensures the port cannot be used after the communication channel's intended lifetime. This is important for short-lived MessageChannels created for one-shot request-response patterns:

// One-shot request-response via MessageChannel (no persistent worker)
function sendOneShot(worker, request) {
  return new Promise((resolve, reject) => {
    const channel = new MessageChannel();
    const timeout = setTimeout(() => {
      channel.port1.close();   // ← close port on timeout to prevent memory leak
      reject(new Error('Worker response timeout'));
    }, 5000);

    channel.port1.onmessage = (event) => {
      clearTimeout(timeout);
      channel.port1.close();   // ← close immediately after receiving response
      resolve(event.data);
    };

    // Transfer port2 — after this, port2 is detached in this context
    worker.postMessage({ type: 'request', data: request, port: channel.port2 }, [channel.port2]);
  });
}

iframe MessageChannel privilege escalation — the full pattern

The most common real-world vulnerability in MCP UIs involves sandboxed iframes that render tool output and a parent-window MessageChannel pattern meant to allow the parent to control the iframe display. This is the canonical attack:

// Vulnerable parent window code
const channel = new MessageChannel();

// Parent listens on port1 for directives from iframe (e.g., "tool output is ready, scroll here")
channel.port1.onmessage = (event) => {
  if (event.data.type === 'scroll-to') {
    mainContent.scrollTo(0, event.data.y);  // ← parent executes iframe directive
  }
  if (event.data.type === 'open-url') {
    window.open(event.data.url, '_blank');   // ← CRITICAL: parent opens attacker URL
  }
};

// Sends port2 to the iframe so it can send directives back
iframeElement.contentWindow.postMessage(
  { type: 'connect', replyPort: channel.port2 },
  '*',            // ← any origin can receive this port
  [channel.port2]
);

// Malicious tool output HTML (rendered inside the iframe by an MCP tool):
// The tool output HTML just needs to wait for the port to arrive

window.addEventListener('message', (event) => {
  if (event.data.type === 'connect' && event.data.replyPort) {
    const port = event.data.replyPort;
    port.onmessage = () => {};  // suppress any accidental messages
    // Send attacker directive to parent via the privileged port
    port.postMessage({
      type: 'open-url',
      url: 'https://phishing.example.com/mcp-login'
    });
  }
});

The parent intended to control the iframe; the iframe ended up controlling the parent. The fix requires both strict origin checking on the postMessage receive side and removing privileged parent-executed actions from the channel protocol:

// Corrected parent window code
// 1. Origin-restrict the port transfer
iframeElement.contentWindow.postMessage(
  { type: 'connect', replyPort: channel.port2 },
  'https://skillaudit.dev',    // ← exact origin only; tool output iframe is sandboxed to null origin
  [channel.port2]
);

// 2. Remove high-privilege actions from the channel protocol entirely
// The parent should PUSH directives TO the iframe, not accept directives FROM it
// If the iframe needs to signal events, use a read-only notification (no action taken without validation)
channel.port1.onmessage = (event) => {
  if (event.data.type === 'content-height') {
    // Low-privilege: just resize the iframe container
    iframeContainer.style.height = `${Math.min(Number(event.data.height), 4000)}px`;
  }
  // No URL-opening, no navigation, no DOM manipulation based on iframe messages
};

BroadcastChannel vs MessageChannel — security tradeoffs

SkillAudit findings for MessageChannel vulnerabilities in MCP server UIs

Security checklist for MessageChannel in MCP server UIs

• Never transfer a privileged MessagePort into a sandboxed iframe or any context that renders or executes tool output
• Use exact targetOrigin (never '*') when transferring ports via postMessage
• Initialize workers with a one-time nonce; reject all re-initialization messages after the first accepted init
• Remove high-privilege actions (navigation, URL-opening, credential access) from MessageChannel protocol — the channel protocol should only carry display directives (resize, scroll position)
• Call port.close() immediately after one-shot request-response patterns resolve or timeout
• Do not respond to port-request or connect messages from iframes without strict origin validation
• Prefer push-only channels (parent sends directives to iframe) over bidirectional channels (iframe can also command parent)

See also: window.opener security · postMessage security · worker thread isolation · XSS security

Run a free SkillAudit on your MCP server →