SVG Filter Compositing Attacks on MCP Consent: feComposite Operator, feMerge Node Ordering, and Filter Region Abuse

When we audit MCP server SVG filters for consent attacks at SkillAudit, we group attacks by what aspect of the filter system they exploit. Some attacks target individual primitive attributes — wrong blur sigma, extreme displacement scale, malicious color matrix. These are attribute-level attacks and they can in principle be caught by per-attribute rules.

But three attack families exploit a different layer: the architectural rules of how SVG filters themselves are composed and applied. These are structural attacks. They exploit the Porter-Duff compositing formula (feComposite operator), the layering order of parallel primitive outputs (feMerge node ordering), and the geometric specification of where a filter applies (filter region attributes). Together they define a set of consent evasion paths that no per-attribute rule can catch — because the attack is not in any single attribute value but in the combination, sequence, or boundary specification.

This post synthesizes the twelve SA-CSS patterns across these three families from our recent research (sessions covering SA-CSS-FCO, SA-CSS-FMO, and SA-CSS-FRG patterns). We cover each family's mathematical basis, the specific attack patterns, and then the one check that unifies detection across all three.

Family 1: feComposite operator — Porter-Duff as mask erasure

The feComposite primitive composites two images using a Porter-Duff compositing formula selected by the operator attribute. The relevant operators for consent attacks are in, out, and xor. Unlike blending modes, which mix color channels, these operators work primarily on the alpha channel using explicit geometric masking formulas.

<filter id="fco1">
  <feImage href="data:image/svg+xml,..." result="tiny_mask"
    x="0" y="0" width="1" height="1"/>
  <feComposite in="SourceGraphic" in2="tiny_mask" operator="in"/>
</filter>

Family 2: feMerge node ordering — last node always wins

feMerge composites multiple primitive outputs by alpha-compositing them in document order: each feMergeNode is rendered over all preceding nodes. This is equivalent to a sequential series of over-compositing operations. The invariant: the last feMergeNode in document order determines what covers all earlier layers. An opaque solid-color node at the end of the feMerge stack overwrites everything before it.

<filter id="fmo1">
  <feFlood flood-color="white" flood-opacity="1" result="white_layer"/>
  <feMerge>
    <feMergeNode in="SourceGraphic"/> <!-- visible layer -->
    <feMergeNode in="white_layer"/>   <!-- final node: covers everything -->
  </feMerge>
</filter>

consentEl.addEventListener("mousedown", () => {
  const feMerge = document.querySelector("#f feMerge");
  const node = document.createElementNS("http://www.w3.org/2000/svg", "feMergeNode");
  node.setAttribute("in", "white_layer");
  feMerge.appendChild(node); // appended = new top layer = white-out
});

Family 3: Filter region attributes — the zero-area transparent rule

A filter's application region is specified by the x, y, width, and height attributes of the <filter> element (defaulting to x="-10%" y="-10%" width="120%" height="120%"). The SVG specification states: if the filter region has zero area (width=0 or height=0), the filter produces fully transparent output. This is not an edge case or undefined behavior — it is an explicit, mandated specification requirement. The transparent rule applies regardless of the filter's primitive chain: even a perfectly benign identity filter produces transparent output if its region has zero area.

<filter id="frg1" width="0">
  <!-- any primitives here; they are never evaluated -->
  <feColorMatrix type="matrix" values="1 0 0 0 0  0 1 0 0 0  0 0 1 0 0  0 0 0 1 0"/>
</filter>
<!-- zero-area → transparent output; primitive chain irrelevant -->

consentEl.addEventListener("mousedown", () => {
  document.querySelector("#consentFilter")
    .setAttribute("width", "0"); // zero-area → instant transparent
});

Why these three families require a unified detection strategy

These families exploit three different architectural layers of SVG filter processing:

An attacker combining all three in a single filter — a non-zero-area region (passing FRG check), a non-out/in/xor operator (passing FCO check), and a non-final-white feMerge (passing FMO check) — while using, say, a large-scale displacement attack via feTurbulence, would evade all three per-family scanners. The only strategy that catches all of them is: simulate the filter chain output and measure its effect on the consent element's visible contrast ratio.

Interaction between families: combined attacks

The three families combine. Consider this filter that would evade per-family analysis:

<!-- Evasion of all three per-family scanners -->
<filter id="combined" x="-10%" y="-10%" width="120%" height="120%">
  <!-- FCO check: operator="over" = identity, passes -->
  <feComposite in="SourceGraphic" in2="SourceGraphic" operator="over" result="pass"/>
  <!-- feTurbulence with pre-computed seed for max-displacement at element center -->
  <feTurbulence type="turbulence" baseFrequency="0.05" numOctaves="1"
    seed="12847" result="noise"/>
  <feDisplacementMap in="pass" in2="noise" scale="400" xChannelSelector="R"/>
  <!-- FMO check: single feMergeNode, no white final node, passes -->
</filter>
<!-- All three per-family checks pass. But output: consent text displaced 200px off-element. -->

This example uses none of the three structural attack families directly — it uses a pre-computed seed displacement attack (SA-CSS-TSE-001) that evades all three structural scanners. The lesson is that output-simulation detection is not just a fallback for when per-family analysis fails; it is the only first-class check that covers the entire attack space.

MutationObserver coverage for click-time attacks

Four of the twelve patterns (SA-CSS-FCO-004, SA-CSS-FMO-004, SA-CSS-FRG-004, and similar JS-inject variants) change the filter state at mousedown. These require dynamic detection via MutationObserver:

The observer scope is: all <filter> elements that are referenced by any ancestor of any detected consent element (traversed upward from the consent element through the DOM ancestry chain). Changes to filter elements not in the ancestry chain are not relevant and should not generate alerts.

Full pattern reference table

Conclusions

The three filter compositing attack families described here are unusual in the SVG consent attack taxonomy because they exploit architectural rules rather than attribute values. feComposite operator attacks use the Porter-Duff compositing formula as a mask erasure tool. feMerge ordering attacks use the last-node-wins layering property. Filter region attacks use the SVG zero-area transparent rule. Each family is invisible to detectors focused on the other two.

The practical implication for MCP skill auditors: do not build a scanner that is a collection of per-pattern attribute checks. Build a scanner that simulates filter output on a representative consent element and measures the contrast ratio of the result. A scanner that does that one check correctly catches all twelve patterns described here, plus all attribute-level attacks (extreme blur sigma, bias=1, displacement scale=10000), without requiring explicit pattern knowledge for any of them.

SkillAudit's audit engine implements exactly this output-simulation approach as the primary consent-filter detector. Every filter applied to an ancestor of any detected consent element is simulated on a dark-text-on-white test input, and the output contrast ratio is measured. This is what a SkillAudit audit report flags under the SA-CSS category — the reported severity reflects what the filter actually does to consent visibility, not what its attributes appear to say.

← Blog  |  Security Checklist