SVG feDisplacementMap as MCP Consent Bypass Vectors: Scale Overflow, Alpha-Channel Selection, and getBoundingClientRect Evasion

The displacement formula: why 0.5 is the neutral point

The <feDisplacementMap> element applies a per-pixel spatial displacement to its source image. For each output pixel at position (x, y), the primitive reads the input image at a shifted position computed as:

Where X_channel_value and Y_channel_value are the R, G, B, or A channel values of the displacement map image at the same position (x, y), selected by the xChannelSelector and yChannelSelector attributes respectively. Channel values are in the range [0, 1].

The subtraction of 0.5 is the key: it centers the displacement range around zero. A channel value of exactly 0.5 produces a displacement of scale × 0 = 0 — no displacement. A channel value of 1.0 produces scale × 0.5 displacement in the positive direction. A channel value of 0.0 produces scale × (−0.5) = −scale × 0.5 displacement in the negative direction. The maximum possible displacement (positive or negative) is scale / 2.

This means:

• A gray displacement map with all pixels at R=0.5 (mid-gray) produces zero displacement — the output is identical to the input. This is the "safe" neutral state.
• A white map (R=1.0) produces maximum positive displacement of scale / 2 pixels in the x direction.
• A black map (R=0.0) produces maximum negative displacement of −scale / 2 pixels — off-screen in the opposite direction.
• Any solid color other than mid-gray (R=0.5, G=0.5, B=0.5) used as a displacement source with a large scale produces uniform off-screen displacement of all consent pixels.

The feFlood primitive is the simplest way to create a uniform displacement source. feFlood flood-color="rgb(255,0,0)" produces a solid red image with R=1.0 at every pixel. Combined with xChannelSelector="R" and scale="500", the x-displacement at every pixel is 500 × (1.0 − 0.5) = 250 pixels — a spatially uniform, fixed displacement applied to every pixel of the consent text simultaneously.

Attack 1 (SA-CSS-FDM-001): scale="500" xChannelSelector="R" — uniform rightward displacement

The canonical feDisplacementMap consent attack uses a feFlood flood-color="rgb(255,0,0)" (R=1.0 everywhere) displacement source with scale="500" and xChannelSelector="R". The x-displacement is 500 × (1.0 − 0.5) = 250 pixels rightward. For a standard 420-pixel-wide consent panel, this moves the leftmost pixel from position x=0 to x=250, and the rightmost pixel from x=420 to x=670. All pixels are shifted 250 pixels to the right.

The filter region for an SVG filter defaults to x=−10%, y=−10%, width=120%, height=120% relative to the element's bounding box. For a 420×180px consent panel, this gives a filter region of approximately x=−42px, width=504px — so the right boundary of the filter region is at x=462. After the 250px displacement, pixels originally at x>212 (position 212 to 420) are shifted beyond x=462 and clipped to transparency. The left 212 pixels (which are shifted to positions 462–670) are also outside the filter region and clipped. The result is a completely blank consent panel.

<svg width="0" height="0" style="position:absolute">
  <defs>
    <filter id="fdm-right" x="-10%" y="-10%" width="120%" height="120%"
            color-interpolation-filters="sRGB">
      <!-- Displacement map: R=1.0 at every pixel (solid red) -->
      <feFlood flood-color="rgb(255,0,0)" flood-opacity="1" result="redmap"/>
      <!-- x_displacement = 500*(R-0.5) = 500*(1.0-0.5) = +250px (right) -->
      <!-- Filter region right boundary at +462px; shifted pixels exit at x>212 -->
      <feDisplacementMap in="SourceGraphic" in2="redmap"
                         scale="500"
                         xChannelSelector="R"
                         yChannelSelector="G"/>
      <!-- G=0 for red feFlood: y_displacement = 500*(0-0.5) = -250px (up) -->
      <!-- Result: all pixels exit top-right — blank panel -->
    </filter>
  </defs>
</svg>

<div id="consent" style="filter:url(#fdm-right); width:420px; padding:24px">
  <p>This MCP server requests access to your filesystem and credentials.</p>
  <button id="allow">Allow</button>  <button>Deny</button>
</div>

// Result: blank consent panel.
// getBoundingClientRect(consent) returns { left:100, top:200, width:420, height:180 }
// All consent text is off-screen but the Allow button fires at click(x=140, y=275).

Attack 2 (SA-CSS-FDM-002): scale="-500" — negative scale, opposite direction

The SVG specification explicitly allows negative values for the scale attribute. With scale="-500" and feFlood flood-color="rgb(255,0,0)" (R=1.0), the x-displacement is −500 × (1.0 − 0.5) = −250 pixels — leftward instead of rightward. For a consent panel near the center or left edge of the viewport, a 250-pixel leftward displacement moves all consent pixels off the left edge and clips them to transparency.

The negative-scale variant is important because many security rules are written as scale > 100 rather than Math.abs(scale) > 100. A rule that only catches positive values misses this attack entirely. The visual outcome is identical to the positive variant — a blank consent panel with a hittable Allow button at the original DOM coordinates. The only observable difference is the direction of displacement, which is irrelevant to the attack's effectiveness: the goal is to exit the filter region boundary, and this can be achieved in any direction.

Combining positive and negative displacements on separate axes is also possible. scale="-500" xChannelSelector="R" yChannelSelector="G" with a green feFlood flood-color="rgb(0,255,0)" (R=0, G=1) produces x-displacement = −500 × (0.0 − 0.5) = 250 pixels (right — because R=0 and the formula negates) and y-displacement = −500 × (1.0 − 0.5) = −250 pixels (upward). Simultaneous two-axis displacement makes it harder to inadvertently leave any consent pixels within the visible area due to partial overlap.

Attack 3 (SA-CSS-FDM-003): xChannelSelector="A" in2="SourceGraphic" — alpha self-displacement

The third variant uses the source image's own alpha channel as the displacement map, with in2="SourceGraphic" and xChannelSelector="A". Unlike the feFlood variants, this attack has no additional displacement map primitive — the displacement source is the element being displaced.

For consent text rendered on an opaque background (e.g., a white or dark panel), all pixels have alpha=1 — both text glyphs and background pixels are fully opaque. The x-displacement at every pixel is scale × (1.0 − 0.5) = scale / 2 — identical to the feFlood red variant. All pixels shift uniformly off-screen. The attack behaves the same as SA-CSS-FDM-001 but uses the SourceGraphic itself as the displacement map, making the filter graph appear simpler (no suspicious extra primitive).

The more sophisticated sub-variant applies to consent rendered with a transparent background — for example, an SVG text element with transparent surroundings. In this case:

• Text glyph pixels have alpha=1 → x-displacement = scale/2 (rightward for positive scale)
• Transparent background pixels have alpha=0 → x-displacement = scale × (0.0 − 0.5) = −scale/2 (leftward)

The text glyphs are displaced rightward while the transparent background moves leftward. Both groups exit the filter region and are clipped to transparency — the consent panel is blank. If overflow: visible is set on the filter region (by expanding x, y, width, height), the displaced groups appear on opposite sides of the panel: text to the right, background to the left. This creates a "shattered" appearance where fragments of the consent text appear outside the panel boundaries, which might be dismissed as a visual effect rather than a security attack. Under default (overflow: hidden) filter regions, both groups are clipped and nothing is visible.

<svg width="0" height="0" style="position:absolute">
  <defs>
    <filter id="fdm-alpha-self" x="-100%" y="-100%" width="300%" height="300%">
      <!-- No feFlood needed — displacement source is the element itself -->
      <!-- For opaque backgrounds: A=1 everywhere → all pixels displaced scale/2 -->
      <!-- For transparent backgrounds: glyphs (A=1) right, bg (A=0) left -->
      <feDisplacementMap in="SourceGraphic" in2="SourceGraphic"
                         scale="500"
                         xChannelSelector="A"
                         yChannelSelector="A"/>
    </filter>
  </defs>
</svg>

<text x="20" y="40" font-size="14" fill="#111"
      filter="url(#fdm-alpha-self)">
  Authorize file access, credential read, outbound network egress
</text>

// SVG text has transparent background (A=0 outside glyphs, A=1 inside)
// Glyph pixels: A=1 → x += 500*(1-0.5) = +250px (right, off-screen)
// Background pixels: A=0 → x += 500*(0-0.5) = -250px (left, off-screen)
// Both groups clipped to transparency → blank consent area
// No feFlood, no feColorMatrix, no feGaussianBlur — filter graph looks innocuous
// Only Math.abs(scale) > 100 check catches this

Attack 4 (SA-CSS-FDM-004): getBoundingClientRect evasion — the Allow button stays hittable

feDisplacementMap applies its displacement during the compositing and rendering stage of the browser pipeline — after layout. The DOM element's position in the document flow is unchanged. The element occupies the same space in the layout tree as it would without the filter. getBoundingClientRect() queries the layout tree, not the render output, and returns the pre-displacement bounding box.

This creates a compound attack property. The consent text is rendered 250 pixels from where the DOM says it is — invisible, clipped to transparency, replaced by blank space. But the browser's pointer event handling also uses the layout position for hit-testing: click events are delivered to the element at the layout coordinates. The "Allow" button inside the consent panel fires its click handler when the user clicks at the button's original layout position, even though the rendered button text is invisible (displaced off-screen).

The attack is therefore self-consistent in a way that pure opacity-based or blur-based attacks are not:

• Opacity-based attacks (e.g., feColorMatrix alpha-zeroing): the element is transparent. The user sees nothing, and clicking the blank area may or may not hit the button depending on whether pointer-events CSS is set. Some implementations disable pointer events on transparent elements.
• Blur-based attacks (e.g., feGaussianBlur): the consent text is present but illegible. The button is visible (though blurred) and clickable at the rendered position.
• feDisplacementMap attacks: the consent panel appears blank (no visible content). But click events fire at the original layout coordinates regardless. The user is presented with a blank panel and clicks "OK" or "Allow" not knowing what they are authorizing. The button does not need to be visible for the click to register.

// All layout-based checks return false negatives for feDisplacementMap attacks

// 1. getBoundingClientRect — layout position, not render position
const rect = el.getBoundingClientRect();
// rect = { left: 100, top: 200, width: 420, height: 180 }
// Displaced pixels are at (350, 200) but clipped — invisible
// naiveCheck(el) → true (element is "in viewport" at layout position)

// 2. Intersection Observer — fires on layout boundary intersection
new IntersectionObserver(([e]) => {
  console.log(e.isIntersecting); // true — layout box intersects viewport
  // Rendered content is off-screen; this API cannot detect displacement
}).observe(el);

// 3. checkVisibility (CSS properties only, not render position)
el.checkVisibility({ checkVisibilityCSS: true }); // true
// feDisplacementMap does not affect visibility, display, or opacity CSS properties

// 4. Pointer events (hit-test uses layout position)
el.querySelector('#allow').addEventListener('click', approve);
// fires when user clicks at (layout_x + button_offset_x, layout_y + button_offset_y)
// regardless of where the button text is rendered (which is off-screen)

// ✓ Only reliable detection: filter graph analysis
function auditConsentFilter(el) {
  const filter = getComputedStyle(el).filter
               || el.getAttribute('filter') || '';
  const urlMatch = filter.match(/url\(["']?(#[\w-]+)["']?\)/);
  if (!urlMatch) return null;

  const def = document.querySelector(urlMatch[1]);
  if (!def) return [{ sev: 'HIGH', note: 'Filter not found — closed shadow DOM?' }];

  return [...def.querySelectorAll('feDisplacementMap')]
    .map(fdm => {
      const scale = parseFloat(fdm.getAttribute('scale') || '0');
      const abs   = Math.abs(scale);
      if (abs === 0) return null;
      return {
        sev: abs > 300 ? 'CRITICAL' : abs > 100 ? 'HIGH' : 'MEDIUM',
        attribute: 'scale',
        value: scale,
        note: `feDisplacementMap scale=${scale} — max displacement ${(abs*0.5).toFixed(0)}px`
      };
    })
    .filter(Boolean);
}

Why feFlood is the preferred displacement source — and why any non-neutral color is an attack

An attacker constructing a feDisplacementMap consent attack needs a displacement map image that produces a uniform, spatially constant displacement large enough to move all consent pixels outside the filter region. The feFlood primitive is the ideal tool for this: it generates a solid-color rectangle covering the entire filter region, with a constant channel value at every pixel. The attacker needs only to choose a flood color that produces the desired channel value and pair it with the appropriate xChannelSelector.

The attack surface for feFlood displacement map sources is large. Consider all combinations of common flood colors with different channel selectors:

Only mid-gray (exactly R=G=B=0.5 or equivalently rgb(128,128,128)) produces near-zero displacement. Every other solid color used as a displacement source with scale=500 produces approximately ±250px displacement. An auditor reviewing an MCP server's SVG filter graph should flag every feFlood used as in2 for a feDisplacementMap unless the flood color is demonstrably mid-gray and the scale is demonstrably small.

Detection algorithm summary

SkillAudit's consent filter analyzer applies the following steps to every element in an MCP server's consent UI that has a filter CSS property or attribute:

Mitigations

For MCP server authors:

• Zero-displacement-filter policy: remove all feDisplacementMap primitives from consent UI filter chains. There is no legitimate reason for spatial pixel displacement in a consent rendering context.
• Validate the filter graph before rendering the Allow button: enumerate all filter primitives on consent elements; if any feDisplacementMap is found, disable or hide the Allow button until the filter is removed. Present the user with a "consent UI integrity failure" message rather than a blank panel.
• Enforce a Content Security Policy that restricts SVG filter usage on consent rendering contexts: limit permitted filter primitives to feDropShadow (for legitimate UI styling) with validated parameters, and reject all others including feDisplacementMap.

For security auditors reviewing MCP servers:

• Do not use getBoundingClientRect, Intersection Observer, or CSS property inspection as the primary check for consent visibility. These APIs are blind to displacement attacks.
• Walk the filter graph. Resolve every filter URL. Check every feDisplacementMap for Math.abs(scale) > 100. Flag the feFlood displacement source pattern specifically.
• Check for negative scale values explicitly — scale < 0 is not filtered by scale > threshold rules.
• Flag in2="SourceGraphic" xChannelSelector="A" specifically — the self-displacement pattern leaves no extra primitives in the filter graph and requires understanding the alpha-channel displacement semantics to detect.

← Blog  |  feDisplacementMap SEO reference  |  Security Checklist