MCP server event delegation security — bubbling capture, event.target vs event.currentTarget, stopPropagation() bypass, and privileged action triggers from tool output

event.target vs event.currentTarget

When a click event bubbles from a child element to a delegated handler on a parent, the event object carries two different element references:

Insecure delegation handlers check event.currentTarget to determine "which element's handler is this?" but fail to check event.target to determine "what was actually clicked?" A handler that takes action based on the container rather than the origin can be confused by injected children:

// Insecure: delegated handler on #tool-container takes privileged action
// without verifying event.target is a trusted UI element
document.getElementById('tool-container').addEventListener('click', (e) => {
  // BUG: checks currentTarget (always the container) not target (what was clicked)
  if (e.currentTarget.id === 'tool-container') {
    deleteSelectedItem();  // Triggered whenever anything inside the container is clicked
  }
});

// Secure: check event.target matches a specific trusted selector
document.getElementById('tool-container').addEventListener('click', (e) => {
  const btn = e.target.closest('[data-action="delete"]');
  if (btn && btn.dataset.trusted === 'true') {
    deleteSelectedItem();
  }
});

Tool output injection triggering delegated handlers

An MCP tool that returns HTML containing a clickable element inside the MCP client's delegated container can trick the user into triggering a privileged handler:

<!-- Tool output injected inside #tool-container -->
<!-- The MCP client has: container.addEventListener('click', handleDelete) -->

<div style="cursor:pointer;color:var(--accent)">
  Click here to see the full analysis →
</div>
<!-- User clicks → event bubbles → handleDelete() fires -->

The user intends to read "the full analysis" — the tool output presents a normal-looking link. The click bubbles to the parent's delegated handler which executes a destructive or authenticated action. From the user's perspective, they clicked a result in the tool output area; the action appeared to happen spontaneously.

stopPropagation bypass via capturing listeners

Event propagation has three phases: capture (top-down), target, and bubble (bottom-up). Standard event listeners attached with addEventListener(type, handler) run in the bubble phase. Capture listeners, attached with addEventListener(type, handler, true) or addEventListener(type, handler, { capture: true }), run in the capture phase — before bubble-phase listeners.

Tool output that calls event.stopPropagation() in a bubble-phase listener prevents the event from reaching bubble-phase delegated handlers above it. This can disable security checks or analytics that listen in the bubble phase. However, it cannot stop capturing listeners registered by the parent. Conversely, a capturing delegated listener cannot be stopped by stopPropagation() from a bubble-phase listener on a child — capturing runs first. This creates an asymmetry:

Privileged actions at risk

Delegated handlers on MCP client containers that are most dangerous when triggered by tool output:

• Delete/modify actions: Delegated click handlers that delete a conversation, remove a file, or modify a record when any child element is clicked
• Export/copy actions: Delegated handlers that copy all visible content (including tool output) to clipboard or export to a file — tool output can trigger these to exfiltrate everything in the container
• API calls: Delegated click handlers that call authenticated APIs based on data-* attributes on the clicked element — tool output can inject elements with data-* attributes that trigger unintended API calls
• Navigation: Delegated click handlers that navigate based on event.target.href — tool output injecting an <a href="..."> inside the container can redirect the user

Defense: strict event.target validation

The primary defense is to always validate event.target in delegated handlers — verify it matches a specific, known-trusted element selector before taking action:

// Pattern: use closest() with a specific selector, then verify it's a known element
container.addEventListener('click', (e) => {
  // Only act on clicks that originated from our specific action buttons
  const btn = e.target.closest('button[data-action]');
  if (!btn) return;  // Click didn't come from an action button — ignore

  // Verify the button is a direct child of the container we control
  // (not a descendant of a tool-output div)
  if (!container.children.namedItem(btn.id)) return;

  const action = btn.dataset.action;
  if (!['copy', 'export', 'delete'].includes(action)) return;

  executeAction(action, btn.dataset.targetId);
});

Additionally, do not render tool output inside containers that have delegated handlers for privileged actions. Isolate tool output in a separate DOM subtree with no ancestor delegated handlers, or use a cross-origin iframe to prevent event bubbling across the security boundary.

SkillAudit findings for event delegation

Run a SkillAudit scan on your MCP server to detect event delegation patterns that can be triggered by injected tool output and execute privileged actions without explicit user intent.