CSS @supports and @media as MCP Consent Bypass Vectors

The majority of MCP skill installations happen on desktop or laptop machines at viewport widths above 1024px. @media(min-width:1024px) { .consent { display: none; } } sets consent to hidden at exactly these widths. On mobile viewports (phones, tablets in portrait) the consent is visible — but developers are not installing skills on mobile devices. The attack achieves near-100% coverage of the actual installation population while leaving the consent visible to any audit or test run at a constrained viewport.

/* Attack: hide consent on desktop — where MCP installs happen */
@media (min-width: 1024px) {
  .consent-required {
    display: none;
  }
}
/* Mobile and tablet portrait: consent visible
   Desktop (≥1024px): consent hidden
   MCP install context: always desktop
   Static audit at fixed 1280px: fires immediately
   Static audit at 375px (mobile test): consent visible — PASS */

See the full reference: @media consent bypass security — all five media query attack patterns.

The hover:hover media feature matches devices where the primary input mechanism can hover over elements without activating them — mice and trackpads, not touchscreens. The entire population of developers installing MCP skills uses a hover-capable device. @media(hover:hover) { .consent { opacity: 0; } } hides consent on every developer machine while leaving it visible on phones and tablets. Any audit run on a mobile emulation profile or a touch-first test environment will report the consent as visible.

/* Attack: hide consent on hover-capable devices (all developer workstations) */
@media (hover: hover) {
  .consent-text {
    opacity: 0;
    pointer-events: none;
  }
}
/* Touch devices (phones, tablets): opacity 1 — consent visible
   Hover devices (mice, trackpads): opacity 0 — consent hidden
   All MCP install contexts: hover:hover
   Audit on mobile emulator: PASS
   Audit in headless Chromium (desktop mode): opacity:0 — FAIL */

The single-condition attacks above each have a gap: consent is visible at the excluded viewport range. The combination technique closes this gap. MQ-001 hides consent at viewports ≥1024px via display:none. MQ-003 adds a second rule hiding consent at viewports ≤1023px via color:transparent. Together they cover every possible viewport: consent is hidden everywhere. An audit that checks visibility at a single viewport width will always pick one side of the boundary and miss the other condition.

/* Attack combination: cross-device blackout */
@media (min-width: 1024px) {
  .consent-required {
    display: none;     /* Desktop: removed from layout */
  }
}
@media (max-width: 1023px) {
  .consent-required {
    color: transparent; /* Mobile: text invisible but in DOM */
    user-select: none;  /* Cannot copy-paste to check */
  }
}
/* Any single viewport: catches only one rule
   Full audit at both 375px and 1280px: both rules fire
   Overlap at exactly 1024px: MQ-001 fires; below 1024px: MQ-003 fires
   No viewport where consent is unaffected */

The color-gamut:p3 media feature matches displays capable of rendering colors in the DCI-P3 color space — effectively all modern MacBooks with Retina displays and most high-end developer monitors produced after 2018. Setting consent text to a high-lightness oklch(97% 0 0) or a narrow-range rgb(250,250,250) on a white background creates invisible text specifically on developer displays. On a standard sRGB monitor (Linux VM, budget laptop, older machine), the consent is rendered in the sRGB context and the exact color computation differs enough to remain barely readable. The attack reliably targets the hardware most commonly used for MCP skill installation.

/* Attack: near-white text on P3-capable developer displays */
@media (color-gamut: p3) {
  .consent-text {
    color: oklch(97% 0 0);            /* very high lightness, no chroma */
  }
  .consent-wrapper {
    background-color: oklch(99% 0 0); /* near-white background */
  }
  /* Luminance contrast: L97 vs L99 → ~1.04:1 — invisible on P3 display */
  /* On sRGB display: colors clamp differently — slight contrast remains */
}

Dark mode is the default system setting for a majority of developers — surveys consistently show developer dark-mode adoption above 70%. The prefers-color-scheme:dark media feature matches this system setting. The consent text color is left unchanged at a dark neutral — #1a1a1a or rgb(20,20,20) — which is visible on the light-mode background. Inside the dark-mode media block, the consent container background is promoted to near-black (#0d0d0d), creating effectively zero contrast. The consent text exists in the DOM, has a non-transparent color, and its computed style has a positive luminance — but placed on a background of equal luminance it is invisible. Contrast-checking tools that only check computed color without computing the background color miss this attack entirely.

/* Attack: dark background promotion creates zero contrast in dark mode */
.consent-text {
  color: #1a1a1a;  /* Dark text: visible on light background */
}

@media (prefers-color-scheme: dark) {
  .consent-container {
    background-color: #0d0d0d;  /* Near-black: matches text color */
    /* getComputedStyle(consentEl).color === "rgb(26,26,26)" — non-transparent */
    /* getComputedStyle(consentEl).backgroundColor === "rgb(13,13,13)" */
    /* Contrast ratio: ~1.04:1 — invisible */
  }
}
/* Light mode: dark text on white background — ~17:1 contrast — visible */
/* Dark mode: dark text on near-black — ~1.04:1 — invisible          */

CSS Grid Layout is supported by 97.8% of all browsers globally (2026 data) and by every browser version released since 2017. @supports (display: grid) is therefore not a meaningful conditional — it evaluates to true in essentially every browser any user will encounter. Wrapping a consent display:none inside this block looks like a legitimate feature check in the stylesheet while providing no practical conditionality. Static CSS analysis tools that parse stylesheets but skip @supports blocks as "conditional/dead code" will never evaluate the enclosed rule. The attack achieves universal coverage without triggering the obvious pattern of an unconditional display:none on the consent element.

/* Attack: grid-support wraps unconditional consent hiding */
@supports (display: grid) {
  .consent-required {
    display: none;
  }
}
/* CSS.supports('display','grid') === true in Chrome, Firefox, Safari, Edge
   IE11 only exception — not an MCP installation platform
   Audit tool that skips @supports blocks: PASS (sees no unconditional display:none)
   Audit tool that evaluates CSS.supports(): detects display:none under active rule */

See the full reference: @supports consent bypass security — all four feature-query attack patterns.

The oklch() color function is supported in Chrome 111+, Firefox 113+, and Safari 15.4+ — the complete set of modern developer browsers. Combined with the @supports check, it limits the near-white attack to modern browsers (which is the entire MCP installation population) while remaining syntactically invisible to auditors that don't support oklch parsing. The near-white value oklch(98% 0 0) on a white background produces a contrast ratio of approximately 1.03:1 — visually invisible. Unlike color:transparent (which getComputedStyle returns as rgba(0,0,0,0) and is trivially flagged), an oklch near-white computes to rgb(249,249,249) in the browser — a non-zero, non-transparent color value that bypasses simple color-equality checks.

/* Attack: oklch near-white in modern browsers — bypasses transparent check */
@supports (color: oklch(0 0 0)) {
  .consent-text {
    color: oklch(98% 0 0);             /* L=98% — near-white */
    background-color: oklch(99.5% 0 0); /* L=99.5% — near-white background */
  }
}
/* getComputedStyle().color: "rgb(249,249,249)" — NOT "rgba(0,0,0,0)"
   Simple audit check (color === transparent): PASS
   Contrast ratio L98 vs L99.5: ~1.03:1
   Contrast-ratio check (< 4.5:1): FAIL — correctly flagged */

The :has() pseudo-class is supported in Chrome 105+, Firefox 121+, and Safari 15.4+. The @supports selector(:has(input:checked)) block limits the rule to these modern browsers. Inside, a rule fires when a sibling or ancestor checkbox is checked: .consent-wrapper:has(input[type="checkbox"]:checked) .consent-text { opacity: 0; }. The consent text is fully readable while the user reads it. The checkbox labeled "I have read and agree to the above terms" is visible. The user checks the box. At that instant — the moment of commitment — the consent text disappears. It is unreadable at exactly the point in the flow where it should be most verifiable.

This pattern is uniquely insidious because it passes static audits completely: consent is present in the DOM, visible at page load, not hidden by any unconditional rule. A page scanner that checks visibility at load time reports no issue. The attack only triggers through user interaction, at a behavioral level. Only a behavioral auditor — one that simulates the checkbox check and re-evaluates consent visibility after the state change — catches it.

/* Attack: consent disappears at the moment of agreement */
@supports selector(:has(input:checked)) {
  .consent-wrapper:has(input[type="checkbox"]:checked) .consent-text {
    opacity: 0;
    transition: opacity 0s;  /* Instant — no visible fade */
    pointer-events: none;    /* Cannot re-select text to copy */
    user-select: none;
  }
}
/* At load: consent fully visible — static audit: PASS
   After checkbox check: consent opacity:0 — invisible
   DOM: text node still present (innerText returns content)
   Behavioral audit: check → re-evaluate opacity → FAIL */

/* Detection: MutationObserver + checkbox change listener */
function auditPostCheckboxVisibility(consentEl, form) {
  const checkboxes = form.querySelectorAll('input[type="checkbox"]');
  checkboxes.forEach(cb => {
    cb.addEventListener('change', () => {
      const op = parseFloat(getComputedStyle(consentEl).opacity);
      if (op < 0.5) {
        reportFinding('SA-CSS-SUP-004',
          'Consent became invisible after checkbox state change');
      }
    });
  });
}