MCP server SVG feColorMatrix luminanceToAlpha consent security

The feColorMatrix SVG filter primitive applies a matrix transformation to RGBA channels. When type="luminanceToAlpha", it uses a fixed formula derived from the CIE luminance coefficients: output_A = 0.2126 × R + 0.7152 × G + 0.0722 × B, and sets output_R = output_G = output_B = 0. The output is a grayscale alpha map of the input's luminance. This is distinct from the general type="matrix" path — it cannot be replicated by a 5×4 matrix (because it involves the source alpha), and is processed via a separate code path in browser implementations.

SA-CSS-LTA-001: dark consent text → near-transparent (luminance-dependent)

A dark-colored consent text element (e.g., color: #333333, sRGB linearized R=0.133, G=0.133, B=0.133) has luminance = 0.2126×0.133 + 0.7152×0.133 + 0.0722×0.133 = 0.133 × (0.2126+0.7152+0.0722) = 0.133 × 1.0 = 0.133. The luminanceToAlpha transform sets output alpha to 0.133. This is 87% transparent. On a white background, dark text with 87% transparency appears as very faint pale text — contrast ratio well below WCAG 4.5:1.

For very dark text like #1a1a1a (luminance ≈ 0.016), output alpha ≈ 0.016, which is 98% transparent. The text is effectively invisible. This is why luminanceToAlpha is particularly effective against dark-text-on-light-background consent dialogs — the most common consent UI style.

<filter id="lta1">
  <feColorMatrix type="luminanceToAlpha"/>
</filter>
<!-- Input: dark text #333 (luminance=0.133) → output alpha=0.133, RGB=(0,0,0) → 87% transparent -->
<!-- getComputedStyle.color still returns "rgb(51,51,51)" unchanged -->

SA-CSS-LTA-002: feComposite operator="out" selective erasure

The luminanceToAlpha result can be used as a mask input for feComposite. With operator="out", the formula is out(A, B) = A × (1 - alpha_B). Using the luminanceToAlpha result as in2 (B), pixels where the original source had high opacity become erased: the consent text pixels (source alpha=1) produce luminance_alpha × (1-1) = 0; the background (source alpha=0 outside the element) produces 0 × anything = 0. The result is that text pixels are zeroed while background pixels (outside the element) remain at zero anyway.

This is a more targeted erasure that operates on alpha-compositing relationships rather than a simple channel replacement. It evades checks that look for all-zero output because the compositing logic is two-step (luminanceToAlpha then feComposite), and each step individually appears plausible.

<filter id="lta2">
  <feColorMatrix type="luminanceToAlpha" result="lum_alpha"/>
  <feComposite in="lum_alpha" in2="SourceGraphic" operator="out"/>
</filter>
<!-- lum_alpha: alpha = luminance, RGB = 0. feComposite out: pixels where SourceGraphic is opaque → erased -->

SA-CSS-LTA-003: white-on-dark consent themes (non-evasion case)

For a consent dialog with white text on a dark background (color: #ffffff, luminance=1.0), luminanceToAlpha sets output alpha=1.0 and RGB=(0,0,0). The result is opaque black. On a dark background, opaque black may be more visible than the white text — making the consent text appear dark gray/black rather than invisible. Luminance-based attackers must therefore select their target based on the consent text color profile. This finding exists to document the non-evasion case and prevent false interpretation of luminanceToAlpha as a universal attack. Against dark consent text it is a high-severity attack; against white consent text it may actually increase visibility.

SA-CSS-LTA-004: JS mousedown type injection (matrix → luminanceToAlpha)

The feColorMatrix initially uses type="matrix" with an identity values (5×4 matrix with 1s on the diagonal, 0s elsewhere). The identity matrix passes all channels through unchanged. The consent text renders normally. On mousedown, the script changes type to "luminanceToAlpha". For dark consent text, output alpha immediately drops to the luminance value (~0.1), making the text near-transparent. The mousedown event fires before the visual update is committed to the screen, so the user cannot see the change before their click registers.

consentElement.addEventListener("mousedown", () => {
  const fcm = document.getElementById("consentFilter")
                       .querySelector("feColorMatrix");
  fcm.setAttribute("type", "luminanceToAlpha");
  // No values attribute change needed — luminanceToAlpha uses its own fixed formula
});

Attack summary

Defences

• Flag type="luminanceToAlpha" on feColorMatrix in consent filters: There is no legitimate reason to apply luminanceToAlpha to consent text elements. Flag unconditionally and evaluate the consent text luminance to determine attack severity.
• Compute consent text luminance: Resolve the getComputedStyle.color of the consent element, convert to linear light, and apply the luminance formula. If luminance < 0.2, the attack produces near-transparent output (HIGH severity). If luminance > 0.8, the attack produces opaque black (may increase visibility on dark backgrounds — document as lower severity).
• Check feComposite chain: If luminanceToAlpha result is used as in2 for a feComposite operator="out" or operator="in", evaluate the compositing formula. These combinations can produce selective erasure that neither step flags in isolation.
• MutationObserver on feColorMatrix type: SA-CSS-LTA-004 changes only the type attribute. Add type to the MutationObserver attribute list alongside values for all feColorMatrix elements in consent ancestor filter chains. A change from any type to luminanceToAlpha is always suspicious on a consent element.

SkillAudit findings for this attack surface

← Blog  |  Security Checklist