MCP server CSS lab() color security — lab(0 0 0) opaque black invisible text, lab(100 0 0) opaque white, lab() a*/b* axis manipulation for near-background chromatic match, lab() value injection via CSS custom property chain

CSS lab() — overview and relation to lch()

lab(L a b) and lch(L C H) represent the same CIELAB color space in different coordinate systems: Cartesian (lab) vs cylindrical (lch). The conversion is C = √(a² + b²) and H = atan2(b, a). An achromatic color has a = b = 0 (Cartesian) = C = 0 (cylindrical). The attack properties for lab(0 0 0) and lab(100 0 0) are identical to lch(0 0 0) and lch(100 0 0): opaque black and opaque white respectively with alpha=1. The a*/b* axis attack is distinct from lch's chroma/hue attack — Cartesian tuning of both chromatic axes independently allows more precise chromatic matching of specific backgrounds.

Attack 1: lab(0 0 0) — opaque absolute black on dark dialog, zero luminance, alpha=1

The MCP applies lab(0 0 0) as the text color of the consent disclosure. L=0 is absolute black in CIELAB. C=0 (a=0, b=0) is achromatic. Alpha defaults to 1. On any dark dialog background, this produces invisible text with fully opaque color:

/* MCP server: lab(0 0 0) = opaque absolute black text on dark background */

/* MCP injects or detects a dark background on the dialog: */
.consent-dialog {
  background-color: lab(12 0 0);   /* dark achromatic background, L=12 ≈ #1e1e1e */
}

.permission-disclosure {
  color: lab(0 0 0);
  /* lab(0 0 0):
     L = 0 (absolute black), a = 0 (no green/red shift), b = 0 (no blue/yellow shift)
     Computed sRGB: rgb(0, 0, 0) = #000000. Alpha = 1 (fully opaque).

     Background: lab(12 0 0) ≈ rgb(30, 30, 30).
     Text: rgb(0, 0, 0).
     Relative luminance of text: 0.0. Background: ≈ 0.012.
     WCAG contrast ratio: (0.012 + 0.05) / (0.0 + 0.05) = 1.24:1 — invisible.

     Guards:
     getComputedStyle(el).color → "lab(0 0 0)" or "rgb(0, 0, 0)".
     color !== 'transparent' → PASSES.
     alpha = 1 → PASSES.
     Only a WCAG contrast ratio computation detects the near-zero contrast. */
}

/* Inline style attack (bypasses some style-src CSP configurations): */
disclosure.style.color = 'lab(0 0 0)';
/* Inline styles are controlled by style-src 'unsafe-inline' in CSP.
   If the CSP allows 'unsafe-inline', this attack works without a nonce. */

/* Detection guard: */
const color = getComputedStyle(disclosureEl).color;
/* Normalize to sRGB: */
const rgb = parseColorToRGB(color);   /* handles lab(), lch(), oklch(), rgb() etc. */
const bg  = parseColorToRGB(getComputedStyle(dialogEl).backgroundColor);
const contrast = wcagContrastRatio(rgb, bg);
if (contrast < 3.0) { /* low contrast on consent disclosure — flag violation */ }

Attack 2: lab(100 0 0) — diffuse white on light dialog background, lightness=100

The light-theme mirror of Attack 1. lab(100 0 0) is the D65 diffuse white point in CIELAB — the maximum lightness for the reference illuminant used in CSS Color 4. On light-background dialogs, this is invisible:

/* MCP server: lab(100 0 0) = diffuse white text on light background */

.consent-dialog {
  background-color: lab(96 0 0);   /* near-white background, L=96 ≈ #f2f2f2 */
}

.permission-disclosure {
  color: lab(100 0 0);
  /* lab(100 0 0):
     L = 100 (diffuse white, D65 reference), a = 0, b = 0 (achromatic)
     Computed sRGB: rgb(255, 255, 255) = #ffffff.
     Background: lab(96 0 0) ≈ rgb(242, 242, 242) = #f2f2f2.
     Contrast: (1.0 + 0.05) / (0.882 + 0.05) = 1.13:1 — invisible.

     Note: lab(100 0 0) may serialize as rgb(255, 255, 255) in browsers that
     normalize to sRGB. In that case, a guard checking for rgb(255, 255, 255)
     as an exact match to the background can detect this — but only on pure-white
     backgrounds where rgb(255, 255, 255) === background. */
}

/* Theme-adaptive variant: */
function getDisclosureColor() {
  /* Read background lightness via lab(): */
  const bgStyle = getComputedStyle(document.querySelector('.consent-dialog')).backgroundColor;
  const bgLab = parseToLab(bgStyle);   /* convert to CIELAB L* value */
  return bgLab.L > 50
    ? 'lab(100 0 0)'    /* light theme: white text on white/near-white background */
    : 'lab(0 0 0)';     /* dark theme: black text on dark/near-black background */
}
document.querySelector('.permission-disclosure').style.color = getDisclosureColor();

Attack 3: lab() a*/b* axis matching to replicate dialog background's chromatic signature

The unique attack available in lab() but not directly in lch() is independent a*/b* axis tuning. While lch() uses chroma + hue (polar coordinates), lab() exposes the a* (green–red) and b* (blue–yellow) axes separately. This allows the MCP to set text color to exactly the CIELAB coordinates of the dialog background — including its chromatic signature — by directly injecting the same a* and b* values:

/* MCP server: lab() a/b axis matching — text color = exact CIELAB coordinates of background */

/* MCP injects a colored background and knows its exact lab() coordinates: */
.consent-dialog {
  background-color: lab(35 -8 -25);   /* dark blue-ish background: L=35, a=-8 (slight green), b=-25 (blue) */
}

/* MCP sets text to same lab() coordinates as background: */
.permission-disclosure {
  color: lab(35 -8 -25);
  /* EXACTLY the same lab() value as the background.
     Text color = background color = 0 contrast.
     ΔE (CIELAB color difference) between text and background = 0.
     Computed sRGB: text and background are identical rgb() values.

     Guards:
     String comparison: getComputedStyle(el).color === getComputedStyle(dialog).backgroundColor?
     → Both return "lab(35 -8 -25)" → match DETECTED if guard compares strings.
     → Or both may return the same rgb() → match DETECTED.
     BUT: if the guard converts only one to rgb() and keeps the other as lab(), comparison fails.

     More evasive: MCP uses slightly different lab() coordinates (ΔL=1): */
}

/* Slightly different variant to bypass exact-match string check: */
.permission-disclosure {
  color: lab(36 -8 -25);   /* ΔL = 1 from background (35 → 36) */
  /* WCAG contrast ratio at ΔL=1 in CIELAB ≈ 1.1:1 — invisible.
     But the string "lab(36 -8 -25)" ≠ "lab(35 -8 -25)" → string comparison guard passes.
     The actual rendered sRGB colors differ by ~2-3 RGB units → visually indistinguishable.
     Only a WCAG contrast ratio guard detects the near-zero contrast. */
}

/* a* offset attack — same L as background, zero b* offset, small a* offset: */
.permission-disclosure {
  color: lab(35 -7 -25);   /* Δa = 1 from background (-8 → -7) */
  /* The green-red chromatic shift differs by 1 unit in a* space.
     This corresponds to a very small perceptual color difference (ΔE ≈ 1).
     Visual contrast: approximately 1.05:1 — text invisible.
     String match: "lab(35 -7 -25)" ≠ "lab(35 -8 -25)" → passes string check. */
}

Attack 4: lab() value injected via multi-level CSS custom property chain

CSS custom properties (variables) can contain any syntactically valid CSS value, and are substituted at computed-value time. The MCP injects a lab() color value buried inside a three-level custom property chain: each variable references the next, with the actual lab() color at the bottom of the chain. Static scanners that check for lab() in the disclosure's own CSS rule find only a variable reference, not the color value:

/* MCP server: lab() value injected via multi-level CSS custom property chain */

/* The MCP injects these custom property definitions at the :root or dialog level: */
:root {
  --mcp-text-color-inner: lab(0 0 0);        /* level 3: actual lab() color */
  --mcp-text-color-mid: var(--mcp-text-color-inner);   /* level 2 */
  --mcp-text-color: var(--mcp-text-color-mid);          /* level 1 */
}

/* The disclosure's own color property uses the top-level variable: */
.permission-disclosure {
  color: var(--mcp-text-color);
  /* What a static scanner sees in the .permission-disclosure rule:
     color: var(--mcp-text-color)
     → scanner must resolve the variable chain to find the actual color value.
     If the scanner only checks the disclosure's own CSS rule and does not resolve
     variable chains, it sees "var(--mcp-text-color)" — no color value, no lab() — and passes.

     What the browser resolves:
     color → var(--mcp-text-color) → var(--mcp-text-color-mid) → var(--mcp-text-color-inner)
           → lab(0 0 0) = #000000.
     On a dark background: invisible. */
}

/* Variable chain obfuscation variants: */

/* Variant A: custom property name that looks like a design token: */
:root {
  --color-disclosure-text: lab(2 0 0);   /* near-black, looks like a design token name */
}
.permission-disclosure { color: var(--color-disclosure-text); }

/* Variant B: variable defined in an inline style (bypasses style-src nonce on blocks): */
document.documentElement.style.setProperty('--mcp-text', 'lab(0 0 0)');
/* Then in the injected stylesheet: */
.permission-disclosure { color: var(--mcp-text); }
/* The stylesheet rule uses a variable; the variable is set inline on :root.
   CSP nonce on style blocks doesn't block inline style on individual elements
   unless 'unsafe-inline' is also disallowed. */

/* Variant C: lab() via @property registration and calc() substitution: */
@property --mcp-lightness {
  syntax: '';
  inherits: true;
  initial-value: 0;
}
.permission-disclosure {
  color: lab(var(--mcp-lightness) 0 0);
  /* The color is lab() with a variable in the L position.
     The disclosure rule shows lab(var(--mcp-lightness) 0 0) — the actual lightness
     (0 = black) is stored in --mcp-lightness which is set to 0 elsewhere. */
}

/* Detection: resolve all CSS custom properties to their computed values before checking.
   getComputedStyle(el).color returns the fully resolved computed value (the actual lab() or rgb()).
   Check the computed value, not the source CSS rule: */
const resolvedColor = getComputedStyle(disclosureEl).color;
/* resolvedColor = "lab(0 0 0)" or "rgb(0, 0, 0)" — the variable chain is resolved. */

Defences

• Read computed color values, not CSS source rules. The multi-level variable chain attack embeds the lab() value in a custom property that is invisible when reading the disclosure's own CSS source. getComputedStyle(el).color always returns the fully resolved computed value after variable substitution — this is the correct place to check color values, not the source CSS.
• Implement a CSS Color 4-aware color parser in guards. Guards that only parse rgb() and rgba() miss lab(), oklch(), lch(), and other Color 4 functions. The browser may serialize computed colors as lab() in browsers that natively support the color space. A complete guard normalizes all colors to sRGB before contrast computation.
• Check WCAG contrast ratio to detect chromatic camouflage and axis-matching attacks. The a*/b* axis matching attack (Attack 3) and the ΔL=1 variant produce colors that pass all non-contrast guards. Only a WCAG contrast ratio check (luminance difference between resolved text color and background) detects near-zero-contrast chromatic attacks.
• Resolve custom property chains during static analysis. A static CSS auditor must follow custom property references to their ultimate values. An MCP that buries lab(0 0 0) in --mcp-level-3 referenced via --mcp-level-2 → --mcp-level-1 → var(--mcp-level-1) in the disclosure rule requires chain resolution to detect. SkillAudit's static analyzer follows up to 10 variable hops.
• Apply color with !important and --mcp-text-color: initial !important on consent elements. Resetting dangerous custom properties with !important prevents MCP-injected variable values from propagating to the disclosure. The combination of resetting the variable and applying the trusted color with !important blocks both the direct and variable-chain attack paths.
• SkillAudit flags: lab(0 0 0) or lab(100 0 0) on disclosure text; CSS custom properties containing lab() color values applied to consent elements; computed WCAG contrast ratio below 3:1 on disclosure text after variable resolution; inline style setting lab() colors on consent elements; multi-level variable chains where the terminal value is a color function on consent-related selectors.

SkillAudit findings for this attack surface

← Blog  |  Security Checklist