Security research · CSS attacks · Pseudo-class state

CSS Pseudo-Class Attacks on MCP Consent: State-Triggered Consent Hiding

Most CSS consent-hiding attacks fail a simple test: load the page, query getComputedStyle on the consent element, and check whether it is visible. But a class of attacks based on CSS pseudo-classes defeats this check entirely — because the hiding rule is only active during specific user interactions. :autofill fires when a browser fills credentials. :placeholder-shown fires when a field is empty. :focus-within fires for the entire duration of form interaction. :target fires when a URL hash matches an element's ID. Each creates a consent suppression window that does not exist at page load, does not exist in a static audit snapshot, and does not exist after the user leaves the form — it exists only in the exact moments when users are most likely to submit without reading.

Why state-triggered attacks evade static analysis

Standard CSS security audits operate on two levels: stylesheet scanning and computed-style inspection. Stylesheet scanning reads document.styleSheets and flags rules that apply hiding properties — display:none, visibility:hidden, opacity:0 — to consent-adjacent selectors. Computed-style inspection calls getComputedStyle(consentEl) and verifies the element is visually present. Both approaches share a fatal assumption: the page is in a stable state when the audit runs.

Pseudo-class rules break this assumption. A rule like input:autofill ~ .consent-disclosure { display: none } is present in the stylesheet at all times — but its computed effect on .consent-disclosure depends entirely on whether the adjacent input is currently in the :autofill state. At page load, before any browser autofill has occurred, the rule is inert. The computed style of .consent-disclosure is display: block. A static audit reports: no issue. The attack is invisible until the exact moment a returning user's password manager fires.

This is not a subtle difference. It means every automated consent audit that runs a single snapshot check — including most commercial CMP auditors and browser extension-based checks — will report a clean result for all four attack patterns in this post, even when those patterns are actively suppressing consent for real users.

/* MCP server injected stylesheet */
input:autofill ~ .consent-disclosure {
  display: none;
}

/* Also catches webkit-prefixed autofill (older browsers, some password managers) */
input:-webkit-autofill ~ .consent-disclosure {
  display: none;
}

/* HTML structure the attacker relies on:
   <form class="login-form">
     <input type="email" name="email" autocomplete="username">
     <input type="password" name="password" autocomplete="current-password">
     <div class="consent-disclosure">
       By signing in you confirm you have read our updated data processing
       terms including Article 6(1)(b) lawful basis and US data transfers.
     </div>
     <button type="submit">Sign in</button>
   </form>

   State transitions:
   - Page load: no :autofill → .consent-disclosure { display: block } ← audit sees this
   - Password manager fires: input:autofill → .consent-disclosure { display: none } ← attack active
   - User clicks "Sign in": form submits → consent never visible to returning user
   - New audit snapshot: no :autofill → .consent-disclosure { display: block } ← clean again */

/* Consent is hidden from the moment the page loads until the user types */
input:placeholder-shown ~ .consent-section {
  display: none;
}

/* State machine:
   Page load → field is empty → :placeholder-shown active → consent hidden
   User clicks field → still empty → still hidden
   User types first character → :placeholder-shown deactivates
   → .consent-section { display: block } reappears
   But the user is now mid-typing and the appearing consent is treated as UI noise.
   Most users continue typing and submit — consent was hidden at the critical read-time. */

/* Consent shown at page load (appears legitimate during static audit).
   Hidden the moment the user starts typing — the moment they are most committed. */
input:not(:placeholder-shown) ~ .consent-section {
  display: none;
}

/* State machine:
   Page load → field empty → :not(:placeholder-shown) inactive → consent visible ← audit snapshot
   User types first character → :not(:placeholder-shown) activates → consent hidden
   User completes form and submits → consent hidden for entire form-filling session.

   This attack is particularly deceptive: consent is visible in a static audit
   because the :not(:placeholder-shown) rule is only active after user interaction.
   The consent passes every pre-interaction check and fails every real-user flow. */

/* Hides consent for the entire form-filling session */
form:focus-within ~ .consent-disclosure {
  display: none;
}

/* Timeline for a typical sign-up flow:
   T=0s: Page loads. Form has no focused descendant.
         form:focus-within is inactive. Consent visible. ← static audit snapshot
   T=2s: User clicks "Email" field. form:focus-within activates.
         .consent-disclosure { display: none } ← attack window opens
   T=8s: User types email address.    Still focus-within. Still hidden.
   T=10s: User tabs to "Password" field.  Focus changes, still within form. Still hidden.
   T=15s: User clicks "Create Account".
         Browser fires click on submit button (still inside form).
         Form submission triggered. Focus-within still active at moment of submit.
         ← consent hidden during entire deliberate form completion period
   T=15.1s: Navigation begins. Consent moot.

   Total time consent was visible in this session: 0–2 seconds (before first click).
   Total time user was actively considering the form: 13 seconds.
   Consent visible during active consideration: 0 seconds. */

/* CSS rule — inert at page load, active after MCP JS fires */
#consent-disclosure:target {
  display: none;
}

/* MCP server JavaScript (injected via tool call or skill execution) */
// Fired after detecting that the user has started filling the form:
document.addEventListener('input', function onFirstInput(e) {
  if (e.target.form) {
    // User is actively filling a form — trigger the :target rule
    history.replaceState(null, '', '#consent-disclosure');
    // location.hash is now '#consent-disclosure'
    // #consent-disclosure:target now matches the consent element
    // display: none activates
    document.removeEventListener('input', onFirstInput);
  }
}, { once: false });

/* The attack requires JavaScript — CSS alone cannot set location.hash.
   But MCP servers frequently inject JavaScript alongside injected CSS.
   The JS is the trigger; the CSS is the hiding mechanism.

   From an audit perspective: the CSS rule is syntactically present and
   detectable via stylesheet scanning. But at audit time (no hash in URL),
   the rule is inert and getComputedStyle reports display:block. ← false negative */

Runtime state-machine auditor

Because all four pseudo-class attacks only activate under specific interaction conditions, the only reliable detection approach is a runtime auditor that explicitly simulates or monitors each interaction state and re-checks consent visibility after each state transition. The following auditor uses requestAnimationFrame-based re-checks and programmatic state simulation to cover all four attack vectors.

/**
 * SkillAudit CSS pseudo-class consent state-machine auditor
 *
 * Detects: :autofill, :placeholder-shown, :focus-within, :target attacks
 * against MCP server consent disclosures.
 *
 * Run this in browser DevTools or inject it as an early <script> tag.
 * Returns a Promise that resolves to an array of findings.
 */
async function auditPseudoClassConsentAttacks() {
  const CONSENT_SELECTORS = [
    '.consent-disclosure', '.consent-section', '.consent-panel',
    '.consent-body', '#consent-disclosure', '#consent-panel',
    '[class*="consent"]', '[class*="disclosure"]', '[data-consent]',
  ];

  const findings = [];

  function getConsentEls() {
    const seen = new Set();
    const els = [];
    for (const sel of CONSENT_SELECTORS) {
      try {
        document.querySelectorAll(sel).forEach(el => {
          if (!seen.has(el)) { seen.add(el); els.push(el); }
        });
      } catch {}
    }
    return els;
  }

  function isHidden(el) {
    const cs = getComputedStyle(el);
    if (cs.display === 'none') return { hidden: true, reason: 'display:none' };
    if (cs.visibility === 'hidden') return { hidden: true, reason: 'visibility:hidden' };
    if (parseFloat(cs.opacity) < 0.05) return { hidden: true, reason: 'opacity:0' };
    const rect = el.getBoundingClientRect();
    if (rect.width === 0 || rect.height === 0) return { hidden: true, reason: 'zero dimensions' };
    // Color-vs-background camouflage check
    const color = cs.color;
    const bg = cs.backgroundColor;
    if (color === bg && color !== 'rgba(0, 0, 0, 0)') return { hidden: true, reason: 'color matches background' };
    return { hidden: false };
  }

  function rAFCheck(el, label) {
    return new Promise(resolve => {
      requestAnimationFrame(() => {
        requestAnimationFrame(() => {
          // Two rAF frames to allow CSS transitions and browser state updates to settle
          const result = isHidden(el);
          if (result.hidden) {
            findings.push({
              severity: 'CRITICAL',
              rule: label,
              element: el,
              reason: result.reason,
              message: `Consent element hidden during ${label} state: ${result.reason}`,
            });
          }
          resolve(result);
        });
      });
    });
  }

  // ── STATE 1: Baseline (no interaction) ──────────────────────────────────────
  const consentEls = getConsentEls();
  if (consentEls.length === 0) {
    findings.push({ severity: 'HIGH', rule: 'BASELINE', message: 'No consent elements found matching known selectors' });
    return findings;
  }

  for (const el of consentEls) {
    await rAFCheck(el, 'BASELINE (no interaction)');
  }

  // ── STATE 2: :focus-within simulation ──────────────────────────────────────
  // Find form inputs, focus each, re-check consent visibility
  const formInputs = document.querySelectorAll('form input:not([type=hidden]), form textarea, form select');
  if (formInputs.length > 0) {
    const firstInput = formInputs[0];
    firstInput.focus();
    for (const el of consentEls) {
      const result = await rAFCheck(el, ':focus-within (form field focused)');
      if (result.hidden) {
        // Annotate with which rule is likely responsible
        findings[findings.length - 1].suspectedRule = 'form:focus-within ~ .consent-disclosure { display: none }';
      }
    }
    firstInput.blur();
    // Brief settle after blur
    await new Promise(r => requestAnimationFrame(() => requestAnimationFrame(r)));
  }

  // ── STATE 3: :placeholder-shown and :not(:placeholder-shown) simulation ────
  const textInputs = Array.from(document.querySelectorAll('input[placeholder], textarea[placeholder]'));
  for (const input of textInputs) {
    // State A: placeholder shown (field empty — default state, but verify)
    input.value = '';
    input.dispatchEvent(new Event('input', { bubbles: true }));
    for (const el of consentEls) {
      const result = await rAFCheck(el, ':placeholder-shown (field empty)');
      if (result.hidden) {
        findings[findings.length - 1].suspectedRule =
          'input:placeholder-shown ~ .consent-section { display: none }';
      }
    }

    // State B: placeholder hidden (field has value — :not(:placeholder-shown) active)
    const originalValue = input.value;
    input.value = 'a'; // single character — minimum to deactivate :placeholder-shown
    input.dispatchEvent(new Event('input', { bubbles: true }));
    await new Promise(r => requestAnimationFrame(() => requestAnimationFrame(r)));
    for (const el of consentEls) {
      const result = await rAFCheck(el, ':not(:placeholder-shown) (field has value)');
      if (result.hidden) {
        findings[findings.length - 1].suspectedRule =
          'input:not(:placeholder-shown) ~ .consent-section { display: none }';
      }
    }
    // Restore
    input.value = originalValue;
    input.dispatchEvent(new Event('input', { bubbles: true }));
  }

  // ── STATE 4: :target simulation ─────────────────────────────────────────────
  // Test each consent element's ID as a potential :target
  const consentIdsToTest = [
    'consent-disclosure', 'consent-panel', 'consent-section',
    'consent-body', 'disclosure',
    ...consentEls.map(el => el.id).filter(Boolean),
  ];

  const originalHash = location.hash;
  for (const id of new Set(consentIdsToTest)) {
    history.replaceState(null, '', '#' + id);
    await new Promise(r => requestAnimationFrame(() => requestAnimationFrame(r)));
    for (const el of consentEls) {
      const result = await rAFCheck(el, `:target (#${id})`);
      if (result.hidden) {
        findings[findings.length - 1].suspectedRule =
          `#${id}:target { display: none }`;
      }
    }
  }
  // Restore original hash
  history.replaceState(null, '', originalHash || location.pathname);

  // ── STATE 5: :autofill simulation (stylesheet-scan fallback) ────────────────
  // We cannot programmatically trigger :autofill — it's browser-controlled.
  // Fall back to stylesheet scanning for autofill-related rules.
  const autofillPatterns = [
    /:-webkit-autofill\s*[~+>]/,
    /:autofill\s*[~+>]/,
  ];
  const hidingValues = ['none', 'hidden', '0'];

  for (const sheet of document.styleSheets) {
    try {
      for (const rule of sheet.cssRules) {
        if (!(rule instanceof CSSStyleRule)) continue;
        const sel = rule.selectorText || '';
        const isAutofillRule = autofillPatterns.some(p => p.test(sel));
        if (!isAutofillRule) continue;

        const display = rule.style.display;
        const visibility = rule.style.visibility;
        const opacity = rule.style.opacity;

        const isHidingRule = hidingValues.includes(display) ||
          hidingValues.includes(visibility) ||
          (opacity !== '' && parseFloat(opacity) < 0.05);

        if (isHidingRule) {
          findings.push({
            severity: 'CRITICAL',
            rule: 'SA-CSS-AUTOFILL-001',
            suspectedRule: sel + ' { ' + rule.style.cssText + ' }',
            message: ':autofill sibling-combinator hiding rule detected in stylesheet (cannot simulate state — verify manually with a password manager)',
          });
        }
      }
    } catch (e) { /* cross-origin sheet */ }
  }

  // ── Summary ─────────────────────────────────────────────────────────────────
  console.group('[SkillAudit] CSS Pseudo-class Consent Audit');
  console.log('Consent elements scanned:', consentEls.length);
  console.log('Total findings:', findings.length);
  const crits = findings.filter(f => f.severity === 'CRITICAL');
  const highs = findings.filter(f => f.severity === 'HIGH');
  if (crits.length) console.error('CRITICAL findings:', crits);
  if (highs.length) console.warn('HIGH findings:', highs);
  if (!findings.length) console.log('No pseudo-class consent suppression attacks detected.');
  console.groupEnd();

  return findings;
}

// Execute:
auditPseudoClassConsentAttacks().then(findings => {
  if (findings.some(f => f.severity === 'CRITICAL')) {
    console.error('[SkillAudit] CRITICAL: pseudo-class consent attack confirmed. Block form submission.');
  }
});

The auditor runs five distinct state checks in sequence. States 2 through 4 use programmatic DOM manipulation to simulate the interaction conditions that activate each pseudo-class. State 5 falls back to stylesheet scanning for :autofill, which cannot be programmatically simulated. The requestAnimationFrame double-frame delay between state transitions allows the browser's style recalculation to settle before checking computed visibility, preventing false negatives from CSS transition timing.

Mitigations and SkillAudit detection rules

The four pseudo-class attacks share a common structural pattern: a state-conditional pseudo-class selector on a form input, combined with a sibling or descendant combinator, targeting a consent element. Mitigations should address both the CSS structural pattern and the consent element's resilience to state-triggered hiding.

CSS structural mitigations

/* Safe: consent disclosure is not a sibling of form inputs.
   Pseudo-class sibling combinators on inputs cannot reach it. */
<div class="page-layout">
  <form id="signup-form">
    <input type="email" placeholder="Email">
    <input type="password" placeholder="Password">
    <button type="submit">Create account</button>
  </form>
  <div class="consent-disclosure" aria-live="polite">
    <!-- Consent is outside the form, cannot be reached by
         input:autofill ~, input:placeholder-shown ~,
         or form:focus-within ~ combinators -->
    By clicking "Create account" you agree to our data processing terms.
  </div>
</div>

/* Additionally: use CSS containment on the consent element */
.consent-disclosure {
  contain: strict; /* Prevents layout effects from ancestors affecting this element */
  display: block !important; /* !important is insufficient alone but raises the specificity bar */
}

/* Option A: consent element has no ID, preventing :target matching */
<div class="consent-disclosure">...</div> <!-- no id attribute -->

/* Option B: consent element exists in Shadow DOM, insulating it from document :target rules */
class ConsentDisclosure extends HTMLElement {
  constructor() {
    super();
    const shadow = this.attachShadow({ mode: 'open' });
    shadow.innerHTML = `
      <style>
        :host { display: block; }
        /* Rules here cannot be overridden by document-level CSS */
        .inner { display: block !important; visibility: visible !important; opacity: 1 !important; }
      </style>
      <div class="inner"><slot></slot></div>
    `;
  }
}
customElements.define('consent-disclosure', ConsentDisclosure);

/* Option C: monitor hash changes and verify consent visibility after each change */
window.addEventListener('hashchange', () => {
  requestAnimationFrame(() => {
    const consent = document.querySelector('.consent-disclosure');
    if (consent && getComputedStyle(consent).display === 'none') {
      consent.style.setProperty('display', 'block', 'important');
      console.error('[SkillAudit] :target attack detected and neutralized');
    }
  });
});

SkillAudit rule coverage

Related findings

Each of the four pseudo-classes in this post has a dedicated SEO reference page with the complete four-attack breakdown, individual detection code per rule, severity rationale, and browser support matrix:

• MCP server CSS :autofill pseudo-class security — SA-CSS-AUTOFILL-001 through -004: returning-user credential window attacks, sibling combinators, overlay injection, webkit-autofill cross-browser coverage
• MCP server CSS :placeholder-shown pseudo-class security — SA-CSS-PLACEHOLDER-001 through -004: empty-field hiding, typing-triggered hiding, single-keystroke window, consent-substitute injection
• MCP server CSS :focus-within pseudo-class security — SA-CSS-FOCUS-WITHIN-001 through -004: full-session suppression, ancestor-container variant, overlay injection, color camouflage
• MCP server CSS :target pseudo-class security — SA-CSS-TARGET-001 through -004: JS-triggered hash targeting, parent container variant, overlay injection, bait-and-switch consent substitution

For the broader context of CSS injection in MCP servers, see the SkillAudit blog post on CSS pseudo-element consent attacks (::first-line, ::first-letter, ::placeholder) and CSS @property registered custom property attacks (initial-value priority, inherits:false isolation, type constraint violations).

← All posts