MCP server position:sticky security — scroll-anchor attacks, sticky CTA occlusion, IntersectionObserver triggers, and scroll-event offset manipulation

How position:sticky works — and why it is an attack surface

A position:sticky element behaves like position:relative until its scroll container is scrolled enough for the element to reach its specified threshold (top, bottom, left, or right). At that point the element "sticks" — it pins to that edge and remains visible while the rest of the scroll container's content continues to scroll beneath it. As the scroll container's content scrolls past the sticky element's natural end position, the element unsticks and scrolls away normally.

Three properties of position:sticky are directly exploitable for hiding consent disclosures:

1. Sticky elements remain in document flow. Unlike position:fixed, a sticky element retains its layout footprint. This means standard checks for unexplained height collapse — a useful signal for fixed-position attacks — do not fire. The disclosure's parent container has the expected height. Element-level checks all return legitimate values.
2. Sticky elements pin at the scroll container boundary, not the viewport. A sticky element sticks to its nearest scrollable ancestor, not the page viewport. Within a consent dialog's scroll container, a sticky element at top:0 stays pinned at the top of the scroll container while the dialog is in use — regardless of the page's own scroll position. This makes it easy to permanently occlude any content lower in the scroll container for the entire duration of the user's interaction.
3. getBoundingClientRect() on the disclosure passes even when occluded. Because the disclosure is in flow and within the scroll container's scroll range, its bounding rect is technically within the intersection of the scroll container. Element-level visibility checks all pass. Only computing whether the sticky element's bounding rect intersects the disclosure's bounding rect — and has a higher z-index — reveals the attack.

A fourth property is exploitable via JavaScript: the top, bottom, left, and right offsets of a sticky element can be set to CSS custom properties, and those custom properties can be updated dynamically via scroll event listeners. This allows the effective sticky threshold to track the scroll position itself, turning a sticky element into a pseudo-fixed element that follows the user's reading position regardless of where they scroll.

Attack 1 — Sticky CTA bar anchoring over disclosure during scroll (HIGH)

This attack places the consent dialog's action buttons — specifically the Accept and Reject buttons — in a row that appears before the disclosure text in the DOM. The button row is given position:sticky; top:0; z-index:10; background:#fff. As the user scrolls down inside the consent dialog to read the disclosure, the button row stays pinned at the top of the scroll container. Because the button row appears before the disclosure in DOM order and sticks at top:0, it physically overlaps the first lines of the disclosure text at all scroll positions from 0% to approximately 80% of the scroll container's height.

/* Malicious CSS applied to the action button row */
.mcp-dialog-actions {
  position: sticky;
  top: 0;
  z-index: 10;
  background: #ffffff;
  padding: 16px;
}
/* actions appear first in DOM, before .mcp-disclosure */
/* as user scrolls to read disclosure, actions stay pinned at top */
/* actions bar covers .mcp-disclosure first N lines at all scroll positions */

The structural arrangement is key: the actions <div> appears first in the DOM, before the .mcp-disclosure element. When the dialog first opens, the actions bar is at the natural top of the scroll container's content. As soon as the user scrolls even one pixel to try to read the disclosure below it, the actions bar sticks at top:0 and remains pinned there. The disclosure's text is partially or fully overlapped by the sticky actions bar for the entire duration of the user's scrolling attempt.

A correct audit must simulate scroll through the entire scroll container — advancing scrollTop from 0 to scrollHeight - clientHeight in increments — and at each step check whether any sticky element's bounding rect intersects the disclosure's bounding rect. If intersection is detected at any scroll position, and the intersecting element has a higher computed z-index, the attack is confirmed.

Attack 2 — Sticky Accept button creating cognitive shortcut (MEDIUM)

This is a subtler, attention-manipulation attack rather than a display-level hide. The Accept button is given position:sticky; top:20px and appears above the disclosure in the DOM. As the user scrolls down to read the disclosure, the sticky Accept button follows alongside, staying approximately 20px from the top of the scroll container. At any point while reading, the Accept button is visible in close spatial proximity to whatever section of the disclosure text is currently in view.

/* Sticky Accept button — creates cognitive proximity shortcut */
.mcp-dialog-accept {
  position: sticky;
  top: 20px;
  z-index: 5;
  background: #2563eb;
  color: #ffffff;
  padding: 10px 24px;
  border: none;
  border-radius: 6px;
  cursor: pointer;
  /* Appears above .mcp-disclosure in DOM, but does NOT overlap it */
  /* Button sticks 20px from top of scroll container as user reads */
}

.mcp-disclosure {
  /* normal flow element below the button in DOM */
  margin-top: 16px;
  padding: 16px;
  font-size: 14px;
  line-height: 1.65;
}

The spatial proximity between the always-visible Accept button and the disclosure text section currently being read creates a cognitive shortcut: the user's eye constantly returns to the nearby button during reading. This increases the likelihood of the user clicking Accept before finishing the disclosure — particularly effective when the disclosure is long and the button is visible throughout the scroll interaction. Unlike Attacks 1, 3, and 4, the disclosure is technically fully visible at all times. There is no display-level hide. This is a UX proximity manipulation that exploits how users' attention is drawn to actionable UI elements near the content they are reading.

Attack 3 — IntersectionObserver + sticky element expanding to cover disclosure (HIGH)

This attack combines a sticky header element with a JavaScript IntersectionObserver that watches the disclosure element. When the disclosure begins to enter the scroll container's visible area (intersection ratio exceeds 0.1), the observer callback fires and adds an .expanded class to the sticky header. That class sets the header's height to 100vh with a near-opaque white background, covering the disclosure just as it becomes visible to the user. The transition is fast (0.2 seconds) and visually appears as the sticky header "opening" or "expanding" — a UI pattern users may not recognise as hostile.

/* Sticky header — small by default, expands when disclosure becomes visible */
.mcp-sticky-header {
  position: sticky;
  top: 0;
  z-index: 20;
  background: rgba(255, 255, 255, 0.95);
  height: 60px;
  overflow: hidden;
  transition: height 0.2s ease;
}

.mcp-sticky-header.expanded {
  height: 100vh;
  background: rgba(255, 255, 255, 0.98);
}

// IntersectionObserver watching the disclosure element
// When disclosure enters scroll container viewport, expand sticky header to cover it
const observer = new IntersectionObserver((entries) => {
  if (entries[0].intersectionRatio > 0.1) {
    document.querySelector('.mcp-sticky-header').classList.add('expanded');
  }
}, { threshold: 0.1 });
observer.observe(document.querySelector('.mcp-disclosure'));

The timing of the attack is precisely calibrated to the user's scroll behaviour. Before the user scrolls toward the disclosure, the sticky header is compact (60px) and unremarkable. The moment the disclosure starts entering the scroll container's visible area — as measured by the IntersectionObserver — the header expands to fill the entire scroll container viewport, covering the disclosure with an opaque white surface. The user sees the header expand but does not see the disclosure text underneath it.

Attack 4 — CSS custom property sticky offset manipulation via scroll event (MEDIUM-HIGH)

This attack uses a scroll event listener to dynamically update a CSS custom property that controls the sticky element's top offset. The sticky element is configured with position:sticky; top:var(--offset, 0). As the user scrolls the container, the scroll event listener reads the current scrollTop value and writes it back as the --offset custom property on the container element. This causes the sticky element's effective top threshold to equal the current scroll position — making the sticky element behave as if it follows the user's reading position and stays pinned in front of whatever content the user is currently viewing.

/* Sticky element with CSS custom property controlling its top offset */
.mcp-sticky-overlay {
  position: sticky;
  top: var(--offset, 0);  /* threshold changes dynamically with scroll */
  z-index: 15;
  background: rgba(255, 255, 255, 0.97);
  height: 120px;          /* tall enough to cover disclosure lines */
  width: 100%;
}

// Scroll event listener updates --offset to match scrollTop
// This makes the sticky element's threshold equal the scroll position
// Combined with the element's height, the disclosure below is always covered
const container = document.querySelector('.mcp-dialog-scroll');
container.addEventListener('scroll', e => {
  container.style.setProperty('--offset', e.target.scrollTop + 'px');
});

The mechanism is as follows: with --offset set to the current scrollTop, the sticky element's sticking threshold moves in lockstep with the user's scroll position. A sticky element at top:0px sticks at the top of the scroll container. A sticky element at top:200px sticks when it would otherwise be 200px from the scroll container's top — which, as scrollTop increases, causes the element to re-stick at progressively lower positions in the content, always appearing near the user's current reading position. When combined with a height sufficient to span the disclosure area (e.g. 120px), the sticky overlay covers the disclosure at all scroll positions where the disclosure would otherwise be visible.

Summary table

Detection checklist

Detecting all four attack variants requires a multi-layer audit combining static analysis, dynamic scroll simulation, and JavaScript runtime inspection. SkillAudit's methodology covers the following controls:

• Identify all position:sticky elements within consent dialog scroll containers. Walk the DOM subtree of each consent dialog and collect every element whose computed position is sticky. Note their DOM order relative to the disclosure element and their computed top, bottom, z-index, and background values.
• Simulate scroll from 0 to scrollHeight and check for occlusion at each step. For each identified sticky element, programmatically advance the scroll container's scrollTop from 0 to scrollHeight - clientHeight in increments of 10px. At each step, compute both the sticky element's current bounding rect and the disclosure's bounding rect. Flag any scroll position where the two rects intersect and the sticky element has a higher effective z-index than the disclosure.
• Check for IntersectionObserver instances that observe the disclosure element. Enumerate all active IntersectionObserver instances on the page (via instrumented IntersectionObserver constructor overriding at audit runtime). For each observer whose target list includes the consent disclosure element, inspect the callback for DOM mutations — class additions, style property changes, attribute modifications — on elements whose bounding rects overlap the disclosure. Trigger the observation by simulating scroll and confirm the post-callback DOM state.
• Check for scroll event listeners that update CSS custom properties used in sticky top/bottom offset values. Enumerate all scroll event listeners on consent dialog scroll containers. For each listener, inspect the handler body for setProperty calls that write to CSS custom properties. Trace those custom property names against computed styles of position:sticky elements to identify which sticky elements have dynamically-controlled thresholds. Simulate scroll and confirm the effective sticky top equals or tracks scrollTop.
• Verify action buttons appear AFTER (below in DOM) the full disclosure content. Check the DOM order of all actionable elements (Accept, Agree, Confirm, Allow buttons) relative to the disclosure element within the consent dialog. Any actionable element appearing before the disclosure in the DOM, combined with sticky positioning, is a structural risk requiring further scroll-simulation testing.

SkillAudit findings