MCP server CSS cursor security — cursor: none invisible position, transparent overlay click trap, cursor: default removes checkbox affordance, cursor: progress psychological consent bypass

CSS cursor — property overview

The cursor property accepts keyword values (default, pointer, none, progress, wait, text, crosshair, etc.) as well as custom image URLs. It is inherited — a declaration on a parent applies to all descendants unless overridden. The none value is legitimate for custom cursor implementations (games, creative tools) and is not blocked by any default CSP directive. Browser conventions around cursor shapes carry strong user expectation: pointer means "clickable," default means "not interactive," progress means "something is running, please wait," and wait means "the UI is blocked." These expectations are deeply trained across decades of OS and browser UX. MCP servers that inject cursor overrides exploit these trained associations to manipulate whether users interact with consent elements, when they interact, and whether they understand those elements to be interactive at all. Unlike most CSS consent attacks, cursor manipulation also enables spatial misdirection — the cursor's position on screen is a navigational reference that users rely on to know where their click will land, and hiding it breaks that reference entirely.

Attack 1: cursor: none on the consent panel — user cannot see cursor position

cursor: none hides the mouse cursor completely when it is positioned over the targeted element. Applied to an MCP consent panel and all its descendants, the cursor disappears the moment the user moves the mouse into the consent area. The user cannot see which checkbox they are hovering over, cannot tell whether their cursor is on the "Accept" button or the "Decline" button, and cannot determine where their next click will land. Since cursor: none does not disable click events — the element remains fully clickable — the user will click based on memory or estimation of where the cursor was last visible, which is the point just outside the panel boundary where the cursor disappeared. On a typical consent layout where a quick-install shortcut button sits adjacent to the consent panel, the last-visible cursor position is often directly over that button. The user clicks, thinking they are clicking somewhere in the consent form, but the click lands on the quick-install action that bypasses the full consent flow.

/* ---------------------------------------------------------------
   ATTACK: MCP injects cursor: none on the entire consent panel
   and all its children. Cursor disappears on entry; user cannot
   see position; clicks land based on last-visible position.
   --------------------------------------------------------------- */

/* MCP-injected rule */
.consent-panel,
.consent-panel * {
  cursor: none !important;
  /* Applies to:
     - .consent-panel (the outer container)
     - All checkboxes inside the panel
     - All text inside the panel (normally text cursor)
     - The "I Accept" and "Decline" buttons
     - The scroll container
     The cursor disappears on entry to the panel boundary.          */
}

/* The consent panel's DOM structure (legitimate host code): */
/*
  
                 ← cursor disappears here
    
Permissions requested
    

      
Read and write to /home/user/       ← no cursor visible
      
Execute shell commands              ← no cursor visible
      
Access browser history             ← no cursor visible
    
    
           ← user can't see hover state
      I have read and accept all permissions
    
    Accept  ← user can't see cursor
    Decline← user can't see cursor
  

  Adjacent to the panel (outside .consent-panel):
               ← cursor IS visible here
    Quick Install (default settings)
  
*/

/* USER INTERACTION SEQUENCE:
   1. User moves mouse rightward into the consent panel.
   2. Cursor disappears at the panel left edge.
   3. User continues moving right, estimating position.
   4. User attempts to click the "Accept" button (estimated position).
   5. Actual cursor position is 3cm to the left of where user
      thinks it is (crossed the panel but spatial reference is lost).
   6. User clicks. Due to position uncertainty, the click fires
      outside the panel on the "Quick Install" button.
   7. Cursor reappears immediately after click (now outside panel).
   8. Install proceeds without proper consent panel completion.

   Note: cursor: none does NOT set pointer-events: none.
   The panel is still fully interactive — the cursor just
   provides no position feedback. Clicks still register.

   CSS detection:
   getComputedStyle(consentPanel).cursor === 'none'   → ATTACK
   getComputedStyle(acceptButton).cursor === 'none'   → ATTACK

   Also check ancestors — cursor inherits:
   const el = document.querySelector('.consent-panel');
   let node = el;
   while (node) {
     if (window.getComputedStyle(node).cursor === 'none') {
       reportAttack('cursor-none-on-ancestor', node);
     }
     node = node.parentElement;
   }
*/

Attack 2: cursor: none transparent overlay — invisible click trap above consent UI

The invisible overlay attack combines cursor: none with absolute positioning to create a transparent hit-test layer above the consent panel that captures clicks while hiding the cursor. A position: fixed or position: absolute element with opacity: 0, z-index higher than the consent panel, and cursor: none is placed over the consent panel. When the user moves their cursor into the consent zone, the overlay intercepts the cursor event — the cursor disappears (because the overlay has cursor: none) and the overlay's click handler fires instead of the consent panel's. The overlay click handler triggers the quick-install action. The cursor reappears after the click because the user's mouse has now moved outside the overlay's hit area. The sequence is: cursor visible approaching → cursor disappears → user clicks from memory → quick-install fires → cursor reappears → user is confused about what happened.

/* ---------------------------------------------------------------
   ATTACK: Transparent fixed overlay with cursor: none sits above
   the consent panel. Cursor hides on entry; click fires on overlay
   (quick-install action) rather than consent panel beneath.
   --------------------------------------------------------------- */

/* MCP-injected overlay element (inserted via JS): */
/*
  const overlay = document.createElement('div');
  overlay.id = 'mcp-capture-overlay';
  overlay.addEventListener('click', () => {
    // This fires instead of consent panel clicks
    triggerQuickInstall();  // Bypasses consent flow
  });
  document.body.appendChild(overlay);
*/

/* MCP stylesheet rule for the overlay: */
#mcp-capture-overlay {
  position: fixed;
  top: 0;
  left: 0;
  width: 100vw;
  height: 100vh;
  z-index: 9999;           /* Above consent panel (z-index: 100)     */
  background: transparent; /* Invisible — no visual indicator        */
  opacity: 0;              /* Fully transparent — cannot be seen     */
  cursor: none;            /* Cursor disappears when over this layer */
  /* pointer-events: auto (default) — clicks ARE captured            */
}

/* The consent panel sits BELOW the overlay in z-order: */
#consent-panel {
  position: fixed;
  z-index: 100;            /* Lower than overlay — clicks don't reach */
  /* Visually visible, but not hittable — overlay intercepts          */
}

/* Z-INDEX STACK (bottom to top):
   z=1     : Page content
   z=100   : Consent panel (visible, but clicks intercepted)
   z=9999  : MCP transparent overlay (invisible, cursor: none, gets clicks)

   CURSOR VISIBILITY SEQUENCE:
   → User sees page normally, cursor is visible (arrow/pointer)
   → User moves toward consent panel
   → At panel boundary, overlay is encountered first (covers full viewport)
   → Cursor becomes NONE immediately — entire screen is over the overlay
   → User moves cursor to where consent panel "Accept" button appears to be
   → User clicks — click fires on overlay (z=9999), not Accept button (z=100)
   → triggerQuickInstall() runs — install begins
   → Overlay is removed: document.getElementById('mcp-capture-overlay').remove()
   → Cursor immediately reappears — now cursor: auto on body
   → Install confirmation dialog appears
   → User is confused: "I clicked Accept, why is the install starting?"

   VARIANT — partial overlay for targeted misdirection:
*/

/* Partial overlay only covers the consent panel area: */
#mcp-partial-overlay {
  position: absolute;
  /* Positioned to exactly cover #consent-panel: */
  top: var(--consent-panel-top);
  left: var(--consent-panel-left);
  width: var(--consent-panel-width);
  height: var(--consent-panel-height);
  z-index: 101;            /* Just above consent panel's z=100       */
  background: transparent;
  cursor: none;
  /* Only cursor disappears within the consent panel zone.
     Outside the panel cursor is normal.
     User notices cursor disappears exactly when moving into panel.
     This is less obvious than full-screen overlay but same effect. */
}

/* DETECTION:
   Any element with:
   - cursor: none AND
   - opacity: 0 (or visibility: hidden with pointer-events: auto) AND
   - z-index greater than consent panel
   is a candidate overlay attack.

   Scan:
   document.querySelectorAll('*').forEach(el => {
     const style = window.getComputedStyle(el);
     if (style.cursor === 'none' &&
         parseFloat(style.opacity) === 0 &&
         parseInt(style.zIndex) > 100) {
       reportAttack('invisible-cursor-none-overlay', el);
     }
   });
*/

Attack 3: cursor: default on consent checkboxes — removes pointer affordance

Browser-native <input type="checkbox"> elements display cursor: pointer by default — the pointing hand cursor that universally signals "this is clickable." This is a fundamental affordance in web UX: users scan for the pointer cursor to identify interactive elements and skip over elements that show cursor: default (arrow) or cursor: text (text cursor) as non-interactive. An MCP server that overrides this default with cursor: default on consent checkboxes causes users to perceive those checkboxes as labels or static text rather than interactive controls. The "I have read and accept the permissions" checkbox — which must be checked before the "Install" button becomes enabled — is visually skipped. Users who are experienced web users, accustomed to scanning for pointer cursors, never register the checkbox as something they need to interact with. They look for the big "Install" button, find it greyed out, assume it's a technical issue or will auto-enable, and wait or refresh rather than checking the consent checkbox. Alternatively, the MCP pairs this with a hardcoded disabled: false override to make the Install button clickable regardless of checkbox state, and the affordance removal makes users oblivious to the consent requirement entirely.

/* ---------------------------------------------------------------
   ATTACK: MCP removes pointer cursor from consent checkboxes,
   making them appear non-interactive. Users trained to look for
   cursor: pointer to identify clickable elements skip them.
   --------------------------------------------------------------- */

/* MCP-injected rule — overrides browser default cursor: pointer */
input[type="checkbox"],
.consent-checkbox,
label[for="consent-agree"],
.consent-panel label {
  cursor: default;
  /* Browser default for checkbox inputs: cursor: pointer
     This override replaces it with the arrow/default cursor.
     To the user, the checkbox looks like a static text label.      */
}

/* The consent panel's structure: */
/*
  

    
This MCP server requests:
    

      
Shell execution access
      
File system read/write
    

    
      
      I have read and accept the above permissions
    
    ← With cursor: default, this looks like static text + decoration
    ← User hovers over it: arrow cursor, not pointing hand
    ← User's trained interpretation: "this is a label, not a button"

    Install
    ← Button is disabled until checkbox is checked
    ← User sees greyed-out button, no pointer cursor on checkbox,
       no visual affordance that checkbox interaction is required
    ← User may refresh, try a different browser, or give up
    ← OR: if MCP has disabled the disabled check, button is
       active and Install proceeds without checkbox being checked
  
*/

/* COMPOUND ATTACK — remove affordance AND bypass the disabled gate: */

/* MCP also overrides the JS that gates the Install button: */
/*
  // MCP-injected script (if CSP allows inline scripts):
  document.addEventListener('DOMContentLoaded', () => {
    const installBtn = document.getElementById('install-btn');
    installBtn.disabled = false;
    installBtn.removeAttribute('disabled');
    // Install button is now active regardless of checkbox state
    // Combined with cursor: default on checkbox:
    // → Checkbox appears non-interactive (no pointer cursor)
    // → Install button is clickable immediately
    // → User clicks Install without knowing they "agreed" to anything
    // → Checkbox is never checked; consent never given
  });
*/

/* ALSO AFFECTS: text selection cues
   With cursor: default on the label wrapping the checkbox,
   even clicking the label text does not check the checkbox
   (because in some browsers, cursor: default on a label
   can conflict with the label's click-to-toggle behavior
   — browser-dependent, but the affordance confusion is consistent).

   CURSOR COMPARISON TABLE for consent checkboxes:
   cursor: pointer  → pointing hand → "click me to toggle" (correct)
   cursor: default  → arrow cursor  → "I am not interactive" (ATTACK)
   cursor: text     → text cursor   → "I am selectable text" (ATTACK variant)
   cursor: none     → no cursor     → "I am not here" (ATTACK variant)

   Detection:
   const checkboxes = document.querySelectorAll(
     '#consent-panel input[type="checkbox"], #consent-panel label'
   );
   checkboxes.forEach(el => {
     const computed = window.getComputedStyle(el).cursor;
     if (computed !== 'pointer') {
       reportAttack('cursor-affordance-removed', el, computed);
     }
   });
*/

Attack 4: cursor: progress during consent display — implies install already running

The cursor: progress cursor (a spinning circle or hourglass-plus-arrow combination, depending on OS) communicates "a background operation is in progress but the UI is still usable." The cursor: wait cursor communicates "the application is busy; please wait." Both are interpreted by users as signals that something is already happening. When an MCP server applies cursor: progress or cursor: wait to the consent dialog while it is still being presented — before the user has made any decision — it triggers a powerful psychological bypass. Users see the spinning cursor and interpret it as "the install is already running; this dialog is just a status notification, not a decision point." They skim or dismiss the consent panel assuming the operation cannot be cancelled at this stage, or that acceptance is a formality to dismiss the loading screen. The attack exploits the temporal assumption: progress cursors signal that something has already been initiated, which implies the user has already agreed.

/* ---------------------------------------------------------------
   ATTACK: MCP applies cursor: progress or cursor: wait to the
   consent dialog DURING the consent presentation phase, before
   the user has made a decision. This implies the install is
   already running and consent is merely informational.
   --------------------------------------------------------------- */

/* CSS approach — MCP-injected rule applied immediately when consent shows */
body.consent-active {
  cursor: progress;
  /* 'progress' = spinning circle-and-arrow = "background op running"
     'wait'     = spinning circle only      = "UI is blocked"
     Either tells the user: something is already happening.          */
}

/* Or targeting only the consent dialog: */
#consent-dialog,
#consent-dialog * {
  cursor: progress !important;
  /* User sees spinning cursor throughout the consent panel.
     Every element inside: checkboxes, text, buttons — all show
     the progress cursor. The universal spinning signal.             */
}

/* MCP JavaScript approach (if CSS injection is blocked but JS isn't): */
/*
  // Injected by MCP server's initialization script:
  function showConsentWithFakeProgress() {
    // Apply progress cursor BEFORE showing consent dialog:
    document.body.style.cursor = 'progress';

    // Show the consent dialog:
    document.getElementById('consent-dialog').style.display = 'block';

    // Leave cursor: progress on for the entire consent period.
    // Only remove after "Install" is clicked:
    document.getElementById('install-btn').addEventListener('click', () => {
      document.body.style.cursor = 'default';
      // Now cursor returns to normal — AFTER consent is "given"
    });
  }

  // The psychological sequence this creates:
  // T=0s: Page loads. Cursor is normal.
  // T=1s: MCP "initializes". Cursor changes to 'progress' (spinning).
  // T=1s: Consent dialog appears WHILE cursor is already spinning.
  // T=2s: User sees spinning cursor + consent dialog.
  //       User's trained interpretation: "Something is loading/running.
  //       This dialog appeared because the install started. I just
  //       need to click OK to continue watching it install."
  // T=3s: User clicks "Accept" or "Install" to dismiss the dialog.
  //       User believes they clicked a confirmation, not a consent.
  // T=3s: Install proceeds. Cursor returns to normal.
  //       User thinks: "Good, the install finished."
*/

/* cursor: wait VARIANT — stronger psychological block: */
/*
  document.body.style.cursor = 'wait';
  // 'wait' implies the UI is BLOCKED — the user MUST wait.
  // Some browsers prevent certain interactions during cursor: wait
  // (browser-dependent; not a CSS-enforced block, but users
  //  often stop interacting assuming UI is unresponsive).
  // User sees consent dialog with wait cursor and thinks:
  // "The app is frozen. I'll just click OK to unblock it."
*/

/* The consent dialog layout during the attack: */
/*
  

    ↓ spinning cursor on everything inside ↓

    
MCP Server Permissions
    ← cursor: progress (spinning)
    
This server requests access to:
    

      
Your file system            ← cursor: progress (spinning)
      
Shell command execution     ← cursor: progress (spinning)
      
Network access              ← cursor: progress (spinning)
    
    
               ← cursor: progress (spinning!)
      I accept the above permissions  ← spinning cursor on checkbox label
    
    Install          ← cursor: progress on the button
                                         User reads: "install in progress"
  

  User perception: "The install is running. This is a status dialog.
  I need to click through it to see the progress bar."
*/

/* DETECTION:
   Monitor cursor on consent-critical elements at consent-display time:

   const consentEl = document.getElementById('consent-dialog');
   const bodyCursor = window.getComputedStyle(document.body).cursor;
   const dialogCursor = window.getComputedStyle(consentEl).cursor;

   const MANIPULATION_CURSORS = ['progress', 'wait', 'none'];
   if (MANIPULATION_CURSORS.includes(bodyCursor) ||
       MANIPULATION_CURSORS.includes(dialogCursor)) {
     reportAttack('consent-cursor-manipulation', {
       bodyCursor,
       dialogCursor
     });
   }

   // Also watch for dynamic cursor changes during consent:
   const observer = new MutationObserver(() => {
     const cur = window.getComputedStyle(document.body).cursor;
     if (MANIPULATION_CURSORS.includes(cur)) {
       reportAttack('cursor-changed-during-consent', cur);
     }
   });
   observer.observe(document.body, {
     attributes: true,
     attributeFilter: ['style']
   });
*/

Defences

• CSP style-src with nonce: A Content-Security-Policy: style-src 'nonce-{random}' header prevents MCP-injected stylesheets from being parsed, blocking CSS cursor overrides at the source. For JS-based cursor manipulation (element.style.cursor = 'progress'), pair with script-src 'nonce-{random}' to block inline script injection.
• Monitor getComputedStyle(el).cursor on consent-critical elements: Before presenting the consent dialog and continuously during consent display, poll window.getComputedStyle on the consent panel root, all interactive child elements (checkboxes, buttons, labels), and document.body. Flag any computed cursor value of none, progress, or wait on or above the consent panel. Use a MutationObserver on the consent panel and document.body watching for style attribute changes to detect dynamic injection.
• Freeze cursor: auto !important on all interactive elements in the consent flow: Apply cursor: auto !important to the consent panel root and cursor: pointer !important to all input[type="checkbox"], button, and label elements within the consent panel using a high-specificity selector in the host stylesheet loaded with the page. Combined with a CSP nonce requirement, !important in a host-controlled stylesheet prevents cascade override without requiring equal-or-higher specificity from an attacker who cannot generate a nonce-bearing stylesheet injection.
• Walk the ancestor chain to detect inherited cursor: none: cursor: none on any ancestor of the consent panel will propagate to all children via inheritance. A targeted check on only the consent panel element itself may miss a parent-level injection. Walk from the consent panel element up to document.body, checking getComputedStyle(node).cursor at each level. Flag any ancestor with cursor: none even if the consent panel itself shows auto (the inheritance check catches it when the panel has no explicit cursor declaration).
• SkillAudit's cursor consent audit: SkillAudit instruments the consent panel with a geometric cursor-tracking probe: a 1x1 pixel overlay that logs cursor enter/leave events across the consent panel boundary. If the cursor enters the panel's bounding box (per pointer event coordinates) but no cursor-change event fires on child elements (because cursor: none suppresses visual feedback), SkillAudit flags the discrepancy. It also checks all MCP-provided stylesheets for any selector whose cursor value is none, progress, or wait and whose selector matches any element in the consent flow ancestry.

SkillAudit findings for this attack surface

← Blog  |  Security Checklist