MCP server SVG feComposite arithmetic k-value consent security

The feComposite SVG filter primitive composites two images. When operator="arithmetic", it applies the formula out = k1×in1×in2 + k2×in1 + k3×in2 + k4 per-pixel (SVG §15.8). The formula is a bilinear polynomial in in1 and in2 controlled by four scalar coefficients. Several configurations produce constant output independent of the source image: any setting where the in1 and in2 terms cancel out or are zeroed leaves only the constant term k4. This is the fundamental mechanism behind two of the four SA-CSS-KAR attack patterns.

SA-CSS-KAR-001: k1=k2=k3=0, k4=1 (constant white-out)

With all input-dependent coefficients zero and k4=1, every output pixel is clamped to 1. The consent element is completely white. No in2 primitive is required — the k3 term is zero so in2 is multiplied out. The filter can be written with a single feComposite primitive applied directly to SourceGraphic.

This is the most structurally minimal consent erasure possible: one filter element, one feComposite, four numeric attributes, no additional feFlood or chaining primitives. Static analysis tools that count filter complexity or require multiple primitives for flagging will miss it entirely.

<filter id="kar1">
  <feComposite in="SourceGraphic" operator="arithmetic"
               k1="0" k2="0" k3="0" k4="1"/>
</filter>
<!-- out = 0×in1×in2 + 0×in1 + 0×in2 + 1 = 1; constant white-out -->

SA-CSS-KAR-002: k1=k2=k3=0, k4=-1 (dark-out via clamp)

Setting k4=-1 (or any negative value) with all other coefficients zero produces a computed output of -1 per pixel. Per SVG spec §15.4, filter outputs are clamped to [0, 1]. The clamped result is 0. All RGB channels become 0 (black) — dark-out. Applied to an element with a dark UI theme, the consent text is invisible against the background.

If the filter chain applies the same constant-output feComposite to the alpha channel (or if premultiplied alpha processing causes the alpha to also be zeroed), the element becomes transparent rather than black. The exact behavior depends on the SVG filter color-interpolation-filters setting (linearRGB vs sRGB) and whether the renderer applies premultiplied alpha during compositing.

<filter id="kar2">
  <feComposite in="SourceGraphic" operator="arithmetic"
               k1="0" k2="0" k3="0" k4="-1"/>
</filter>
<!-- out = -1; clamped to 0 → dark-out; on dark-themed clients: text invisible -->

SA-CSS-KAR-003: k1=100, white feFlood in2, k2=k3=k4=0 (amplify+clamp white-out)

This variant uses the product term: out = k1 × in1 × in2 with a solid white feFlood as in2 (all channels = 1). The formula becomes out = 100 × in1 × 1 = 100 × in1. For any pixel where in1 > 0.01 — that is, any pixel with any non-trivial brightness — the output exceeds 1 and is clamped to 1. The result is that all non-black pixels become white. Anti-aliased text edges (which are always at intermediate luminance values) are reliably wiped. The consent element collapses to a pure white rectangle.

This attack is structurally different from SA-CSS-KAR-001: it uses a two-primitive chain (feFlood + feComposite) and the k1 product term rather than the constant k4 term, making it harder to detect with simple attribute-value checks. The apparent innocuousness of large numeric k1 values (they could legitimately be used for brightness amplification effects) provides additional evasion.

<filter id="kar3">
  <feFlood flood-color="white" flood-opacity="1" result="white_in2"/>
  <feComposite in="SourceGraphic" in2="white_in2" operator="arithmetic"
               k1="100" k2="0" k3="0" k4="0"/>
</filter>
<!-- out = 100 × in1 × 1; any in1 > 0.01 → clamped to 1; all anti-aliased pixels → white -->

SA-CSS-KAR-004: JS mousedown changes k4 0 → 1 (click-time white-out injection)

The feComposite begins in identity configuration: k2=1, k1=k3=k4=0. The formula out = in1 passes SourceGraphic unchanged. The consent text is fully visible. On mousedown, the script sets k2="0" and k4="1", switching from identity to constant white-out. The transition is instantaneous — the mousedown event fires before the click completes.

consentElement.addEventListener("mousedown", () => {
  const fc = document.getElementById("consentFilter")
              .querySelector("feComposite[operator='arithmetic']");
  fc.setAttribute("k2", "0"); // remove identity pass-through
  fc.setAttribute("k4", "1"); // inject constant white-out
});

Attack summary

Defences

• Check for constant output from arithmetic operator: For each feComposite operator="arithmetic" in a consent ancestor filter, if k1=k2=k3=0, compute output = k4. If k4 > 0.95: white-out; if k4 ≤ 0: dark-out. Flag either.
• Check for extreme k1 with saturated in2: If k1 > 10 and in2 is a feFlood with luminance > 0.9, compute the effective in1 threshold at which clamping occurs: threshold = 1 / k1. If threshold < 0.1 (meaning 90%+ of pixels are white-out targets), flag as white-out by amplification.
• Evaluate identity configurations for JS override risk: A k2=1, k1=k3=k4=0 configuration (identity) in a consent ancestor filter with any attached JavaScript should be flagged as a potential JS-override target. Recommend MutationObserver deployment.
• MutationObserver on all k-value attributes: Monitor k1, k2, k3, and k4 on feComposite operator="arithmetic" elements within consent ancestor filters.

SkillAudit findings for this attack surface

← Blog  |  Security Checklist