CSS Custom Element and Shadow DOM Consent Attacks on MCP Servers: How :defined, ::slotted(), and :host Hide Terms Inside Web Components

The :defined pseudo-class fires the moment a custom element is registered via customElements.define(). Before registration, a custom element tag (<mcp-widget>) is :not(:defined) — the browser treats it as an unknown element. Once customElements.define('mcp-widget', ...) runs, the element transitions to :defined.

MCP uses this transition as a CSS trigger. The attack setup: MCP injects <mcp-widget></mcp-widget> before the consent disclosure in the light DOM. The injected stylesheet contains mcp-widget:defined ~ .consent { display:none }. At page load, mcp-widget is :not(:defined) — the rule does not fire — the consent is visible — the automated load-time audit passes. Then MCP's script calls customElements.define('mcp-widget', McpWidget) from inside a setTimeout(). The element becomes :defined. The rule fires. The consent disappears. All of this happens after the audit window closes.

/* :defined timing attack — fires after deferred customElements.define() */
mcp-widget:defined ~ .consent { display: none }

/* Registration is deferred to after page-load audits: */
setTimeout(() => customElements.define('mcp-widget', McpWidget), 800);

The inverse of this attack uses :not(:defined): MCP injects a tag that is never registered. *:not(:defined) ~ .consent { display:none } fires from page load and never resolves — a permanent absence condition requiring zero JavaScript. See the full :defined attack reference for all four patterns.

Shadow DOM slots (<slot>) allow a shadow root to incorporate light-DOM children into its layout. When you write <mcp-panel><p class="consent">...</p></mcp-panel>, the <p class="consent"> is a light-DOM element — it exists in the main document tree. But if mcp-panel's shadow root contains a <slot></slot>, the shadow DOM renders the <p> inside the shadow layout, in the position where the slot appears.

The shadow root's stylesheet can then target that slotted element using ::slotted():

/* Inside mcp-panel's shadow root stylesheet */
::slotted(.consent) {
  display: none;
  visibility: hidden;
}

The <p class="consent"> is technically in the light DOM — document.querySelector('.consent') finds it. But its rendering is controlled by the shadow root it has been slotted into. The shadow stylesheet uses ::slotted(.consent) to apply display:none to the slotted element. A light-DOM audit finds the element (it's in the document) and checks its class and text content — and sees what looks like a visible consent element. The shadow stylesheet that actually hides it is invisible to the light-DOM scan.

The attack becomes more complex when MCP wraps existing page content in a shadow host via JavaScript: shadowRoot.appendChild(document.querySelector('.consent')) moves light-DOM elements into a shadow root mid-session, converting them from regular DOM elements to shadow DOM content. The audit may have already run and passed before the move happens. See the ::slotted() attack reference for the full attack taxonomy.

:host and :host-context() are the inside-out shadow selectors — they operate within a shadow root's stylesheet but react to conditions on the shadow host element or its ancestors in the light DOM.

:host(.mcp-ready) matches when the shadow host element has the class .mcp-ready. MCP's connectedCallback() adds this class immediately when the component initializes — before any user interaction, before any audit re-check, and before the user can read the consent inside the shadow root. The shadow root's stylesheet hides the consent disclosure the moment the class appears:

/* Inside mcp-install-panel's shadow root stylesheet */
:host(.mcp-ready) .consent-wrap { display: none }

/* connectedCallback: immediately adds the trigger class */
connectedCallback() {
  this.attachShadow({ mode: 'closed' }); /* Blocks external inspection */
  this.classList.add('mcp-ready');       /* Triggers :host(.mcp-ready) */
}

:host-context() is the more dangerous variant: it fires when any ancestor of the shadow host in the light DOM matches a given selector. This crosses the shadow boundary outward. MCP can add a single attribute to document.documentElement — data-mcp-installed="1" — and every MCP shadow component on the page that has :host-context([data-mcp-installed]) .consent { display:none } in its shadow stylesheet will simultaneously hide its consent disclosure. One call, all components affected.

Crucially, all :host and :host-context() rules live inside shadow root stylesheets — accessible via element.shadowRoot.styleSheets for open shadow roots, but completely unreachable for closed shadow roots. The full attack reference is in the :host pseudo-class security page.

::part() is the CSS Shadow Parts specification's answer to the question: "how do host pages style specific elements inside shadow roots?" Elements inside a shadow root can add a part="" attribute to expose themselves to host-page CSS. The host page can then target them with custom-element::part(name) { ... }.

MCP inverts this mechanism. The attack: MCP's shadow component adds part="consent" to the consent disclosure element inside the shadow root. Then MCP's injected host-page stylesheet contains mcp-widget::part(consent) { display:none }. The consent element is exposed — technically accessible to host CSS — and then immediately hidden by MCP's own host CSS rule:

/* Shadow HTML: consent element with part attribute */
<div part="consent">By installing, you grant access to...</div>

/* Host-page CSS (MCP-injected): hides the just-exposed consent part */
mcp-widget::part(consent) { display: none }

A shadow DOM security review might flag this as "the consent element has part='consent', so it's accessible and styleable by the host page" — interpreting the part attribute as a sign of openness. But the openness is the first half of the attack. The host-page ::part(consent) rule is the second half. The part attribute is evidence of deliberate exposure for the purpose of hiding, not evidence of compliance.

The attack extends through exportparts chains: an outer custom element can re-export inner shadow root parts, allowing host-page CSS to target consent elements that are two shadow boundaries deep. Each exportparts hop adds a layer of indirection that complicates manual tracing while keeping the hiding rule in the light-DOM host stylesheet. See the ::part() attack reference for the full taxonomy including specificity bypass patterns.