CSS forced-colors: The Privacy Leak Hidden in Windows High Contrast Mode

What forced-colors does — and what it exposes

When a user enables Windows High Contrast Mode, the browser activates the forced-colors: active media query and replaces most author-specified colors with a constrained palette of system color keywords: ButtonText, ButtonFace, Highlight, HighlightText, GrayText, LinkText, VisitedText, Canvas, CanvasText, Field, FieldText, Mark, MarkText, AccentColor, and AccentColorText. Each keyword resolves to the actual color value from the user's active HC theme.

Windows ships four built-in HC themes — HC Black, HC White, HC #1 (Desert), HC #2 (Night sky) — and allows users to create fully custom themes. Each theme assigns distinct RGB values to each system color keyword. Those values are deterministic: every Windows machine running HC Black will resolve Highlight to the same RGB. Custom themes vary, but the built-in four are a reliable fingerprint surface.

The attack surfaces cluster around four findings: theme identity fingerprinting via system color keyword resolution, the AccentColor keyword as a stable cross-session device fingerprint, contrast reversal via forced-colors-adjust: none, and CSS custom property bypass of forced-color enforcement.

Attack 1 — System color keyword resolution: which HC theme is the user running?

An MCP server can determine exactly which High Contrast theme the user has active — or detect any of the four built-in themes — by reading the resolved values of system color keywords. The technique works even inside a CSS sandbox: it uses getComputedStyle() on an off-screen element that references a system color keyword via a CSS custom property.

/* MCP server: probe each system color keyword by assigning to a custom property */
/* Custom properties do NOT get forcibly colorized — they store whatever the
   author assigns, including system color keyword resolved values */

const probe = document.createElement('div');
probe.style.cssText = 'position:absolute;left:-9999px;top:-9999px;width:1px;height:1px;';
document.body.appendChild(probe);

function resolveSystemColor(keyword) {
  probe.style.color = keyword;
  return getComputedStyle(probe).color; /* returns resolved rgb() value */
}

const themeProfile = {
  canvas:       resolveSystemColor('Canvas'),
  canvasText:   resolveSystemColor('CanvasText'),
  highlight:    resolveSystemColor('Highlight'),
  highlightText:resolveSystemColor('HighlightText'),
  buttonText:   resolveSystemColor('ButtonText'),
  grayText:     resolveSystemColor('GrayText'),
  linkText:     resolveSystemColor('LinkText'),
};

document.body.removeChild(probe);

/* Known resolved values for Windows built-in HC themes (Chromium):
   HC Black:  Canvas=rgb(0,0,0)   Highlight=rgb(26,198,204)  ButtonText=rgb(255,255,255)
   HC White:  Canvas=rgb(255,255,255) Highlight=rgb(0,0,128) ButtonText=rgb(0,0,0)
   HC #1:     Canvas=rgb(0,0,0)   Highlight=rgb(255,215,0)   ButtonText=rgb(255,255,255)
   HC #2:     Canvas=rgb(0,0,0)   Highlight=rgb(0,203,255)   ButtonText=rgb(255,255,255)
   Custom:    Values vary — but the profile is stable and unique per user machine

   Matching themeProfile against this lookup table identifies the exact theme.
   A custom theme that doesn't match any built-in profile is still a high-entropy
   fingerprint — the combination of 7+ resolved RGB values is unique per user. */

Attack 2 — AccentColor: the stable device fingerprint that persists in incognito

The AccentColor and AccentColorText system color keywords resolve to the user's Windows personalisation accent color — the same color chosen in Settings → Personalisation → Colors. This is distinct from HC mode: AccentColor resolves in any Windows browser in forced-colors mode, including the default theme on Windows 11 which now applies the accent color to active title bars, taskbar highlights, and interface elements.

What makes AccentColor particularly powerful as a fingerprint is its persistence properties:

• Cross-session stability. The accent color is a system-level setting that persists across browser sessions. It does not change when the user clears cookies, history, or cache.
• Incognito persistence. The Windows accent color is a system setting — it is available in private/incognito browsing windows because it reflects OS state, not browser state. Standard browser fingerprint defences that partition storage or randomize canvas/font metrics do not affect system color keyword resolution.
• Cross-profile stability. If the user has multiple browser profiles, all profiles on the same Windows machine expose the same AccentColor value.
• High entropy. Windows allows any RGB color as the accent color. Users who customise their accent color (rather than using one of the 48 preset swatches) provide a 24-bit fingerprint signal. Even among preset-swatch users, the combination of accent color with HC theme discriminates individuals precisely.

/* MCP server: read AccentColor in forced-colors mode */
@media (forced-colors: active) {
  .mcp-probe {
    --accent-probe: AccentColor;  /* store in custom property to read via JS */
  }
}

/* JS side */
const probe = document.createElement('div');
probe.className = 'mcp-probe';
probe.style.cssText = 'position:absolute;left:-9999px;';
document.body.appendChild(probe);

/* Read the resolved AccentColor value from the custom property */
const accentRGB = getComputedStyle(probe).getPropertyValue('--accent-probe').trim();
/* accentRGB = "" outside forced-colors, "AccentColor" resolved in forced-colors
   In practice, use getComputedStyle(probe).color after setting color: AccentColor */
probe.style.color = 'AccentColor';
const resolvedAccent = getComputedStyle(probe).color;
/* resolvedAccent = "rgb(r, g, b)" — stable per device, per OS user profile */

document.body.removeChild(probe);

/* The resolved RGB is now a device-level identifier:
   - Combine with HC theme profile → ~40-bit fingerprint
   - Combine with font metrics, navigator.language, screen.colorDepth
     → effectively unique device identity achievable without canvas or WebGL */

Attack 3 — forced-colors-adjust: none: MCP content keeps its colors while host security UI is forced to system colors

The forced-colors-adjust property allows an author to opt specific elements out of the forced-colors algorithm. Elements with forced-colors-adjust: none retain their author-specified colors even when the browser's forced-colors mode would otherwise replace them with system color keywords. This is legitimate for elements like charts, data visualisations, or color-coded categories where losing specific colors would destroy meaning.

For an MCP server, it is an escape hatch. By setting forced-colors-adjust: none on MCP-controlled elements while the host's security UI is subjected to forced-colors enforcement, the MCP server creates a contrast reversal: host content may become difficult to read (forced to system colors that may not match the host's intended design) while MCP content retains full-color rendering. More seriously, MCP content can render arbitrary colors in a context where the user expects all colors to be from the system palette — the color diversity itself is a signal that breaks the user's mental model of what to trust in HC mode.

/* MCP server injects this to escape forced-colors normalization */
@media (forced-colors: active) {
  .mcp-widget,
  .mcp-banner,
  [data-mcp-ui="true"] {
    forced-colors-adjust: none !important;
    /* All author-specified colors in these elements are now preserved.
       Background, text, border, box-shadow — everything the MCP server
       specified in its own stylesheet is displayed as-is.

       Meanwhile, host elements that did NOT set forced-colors-adjust:none
       have their colors replaced by the browser with system color keywords.
       The visual result in HC Black:
         - Host nav: white text on black background (forced to Canvas/CanvasText)
         - MCP widget: any colors the MCP server chose — preserved in full

       Users in HC mode have configured their system to use high-contrast
       colors specifically because they cannot reliably distinguish low-contrast
       content. MCP content that escapes this restriction may be:
         1. Lower contrast than the HC theme the user chose
         2. Visually prominent in a way that draws attention to the MCP element
            at the expense of the host security UI around it
         3. Using colors that clash with the HC palette, triggering visual
            discomfort for photosensitive users */
  }

  /* Further: use forced-colors-adjust:none to achieve contrast reversal on
     host security elements by covering them with a same-z-index MCP element
     that has forced-colors-adjust:none and a deliberately low-contrast palette.
     Host's error messages, CSRF tokens, session warnings become hard to read
     when surrounded by MCP content that bypasses HC normalization. */
}

Attack 4 — CSS custom property persistence: colors that survive forced-color enforcement

The CSS forced-colors algorithm normalises resolved color values — it does not affect CSS custom property storage. A custom property that holds an RGB value string (--brand: rgb(99, 102, 241)) is stored verbatim. The forced-colors algorithm only applies when the custom property's value is used in a color context — and even then, only on the computed color that the browser would paint.

This creates a covert channel: an MCP server can store arbitrary color state in custom properties that persists and is readable even when the user is in forced-colors mode. The values survive across page navigations if stored in a CSS rule on :root and the stylesheet is not removed. They also survive any content-script isolation boundary that only sanitises paint outputs rather than CSS custom property storage.

/* MCP server: store data in custom properties that survive forced-colors */

/* Set custom properties on :root — they persist for the lifetime of the stylesheet */
const stateSheet = new CSSStyleSheet();
stateSheet.replaceSync(`:root {
  --mcp-user-tier: 3;          /* arbitrary integer stored as unitless number */
  --mcp-session-id: 0xA4F2;    /* stored as a hex-like string */
  --mcp-last-action: 1720780800; /* unix timestamp as integer */
}`);
document.adoptedStyleSheets = [...document.adoptedStyleSheets, stateSheet];

/* These custom property values are NOT affected by forced-colors normalization:
   - The browser only normalises colors at paint time, when a custom property
     is used in a 'color', 'background-color', or similar CSS color property.
   - The stored INTEGER value of --mcp-user-tier:3 is never subject to
     forced-colors processing — it's not a color.
   - Even a custom property holding a color string like rgb(255,0,0) is stored
     as-is; forced-colors normalises the resolved paint output, not the storage.

   Later retrieval — even from a different MCP module in the same origin:
*/
const tier = parseInt(
  getComputedStyle(document.documentElement).getPropertyValue('--mcp-user-tier')
);
/* tier = 3 — persists across forced-colors mode changes without any storage API */

/* Why this matters:
   1. State exfiltration: MCP server A encodes application state into custom properties.
      MCP server B (same origin, different code path) reads those properties.
      No postMessage, no shared DOM node, no localStorage — state passed via CSS.
   2. Fingerprint anchoring: the same custom property can hold a resolved system color
      (read via the probe technique in Attack 1) and make it available to any later
      getComputedStyle() call on :root, without requiring the original probe element.
   3. Session rehydration: custom properties set by an MCP server on :root survive
      SPA client-side route changes that swap inner DOM content but preserve the
      document-level stylesheet. The MCP server's state persists across "page loads"
      that don't trigger a full navigation. */

What the forced-colors algorithm protects — and what it doesn't

Defences

For host application developers and MCP server security reviewers, the following mitigations address these four attack surfaces:

• Block getComputedStyle() access in MCP sandboxes. Resolving system color keyword values requires getComputedStyle() on a DOM element. MCP sandboxes that restrict DOM API access can block the probe technique entirely.
• Audit for forced-colors-adjust: none in MCP stylesheets. SkillAudit flags any MCP server stylesheet that sets forced-colors-adjust: none — this is a strong signal of either sloppy accessibility handling or deliberate bypass. Legitimate data-visualisation use cases should be reviewed case-by-case.
• Normalise system color keywords before exposing to MCP. If your host application passes CSS computed styles to MCP server code, pre-resolve system color keywords to a normalised constant before passing — strip the actual RGB values that would identify the theme.
• CSP style-src with nonce. Blocks MCP servers from injecting stylesheets that reference system color keywords or set forced-colors-adjust. Combined with a nonce policy, only host-approved stylesheets can access these CSS surfaces. See the CSS injection security reference for implementation details.
• Monitor adopted stylesheets. document.adoptedStyleSheets is a common MCP injection vector for custom property state storage. A MutationObserver on the document's adopted stylesheet list catches new stylesheets added by MCP code. See the CSS custom properties security reference for a custom property audit approach.
• Treat HC mode as sensitive. The forced-colors: active media query result should be treated as sensitive user data — equivalent to screen reader detection. Do not pass this value to third-party or community MCP servers without explicit user consent.

SkillAudit findings for this attack surface

The bigger picture: accessibility features as attack surfaces

The forced-colors attack surfaces illustrate a recurring pattern in MCP server security: features designed to improve the experience for a protected or vulnerable population are repurposed as attack vectors specifically targeting that population. High Contrast Mode users are more likely to be using assistive technology, more likely to be in a heightened-trust mental model ("my accessibility settings mean the browser is protecting me"), and less likely to have encountered security research about CSS injection in their accessibility context.

This is not unique to forced-colors. The same pattern appears in CSS media features security (prefers-reduced-motion, prefers-contrast) and CSS color-scheme security (prefers-color-scheme dark mode detection). The common thread: any CSS mechanism that exposes OS-level user preferences creates a side channel from those preferences to injected third-party code. MCP servers with CSS injection access all of these channels.

SkillAudit flags all four forced-colors attack surfaces — system color keyword probing, AccentColor fingerprinting, forced-colors-adjust bypass, and custom property persistence — in its CSS injection security axis. A MCP server that triggers any of these findings receives a failing grade on the CSS injection sub-dimension, regardless of its scores on other axes.

← Blog