Security Guide
MCP server CSS sibling-index() security — DOM injection shifts consent off-screen via index threshold
CSS sibling-index() (CSS Values Level 5, Chrome 130+, 2024) returns the integer ordinal position of an element among its siblings, usable inside calc(). An MCP server encodes a threshold attack in CSS: when the consent element's sibling-index() exceeds 4, its margin-inline-start becomes 100vw, pushing it off-screen. The server then injects a hidden <div> before the consent element in the DOM, incrementing its index from 4 to 5 and firing the off-screen displacement. The consent element's own CSS properties are never touched — the attack is activated purely by DOM structure change.
How sibling-index() works
CSS Values Level 5 introduced sibling-index() and sibling-count() as new primitive functions that expose DOM-structural information to CSS calculations. sibling-index() returns the 1-based ordinal position of the element among its siblings (children of the same parent); sibling-count() returns the total number of siblings in that parent. Both can be used inside calc() expressions applied to any property that accepts a numeric or length value, enabling CSS rules that vary based on DOM position — previously only achievable via :nth-child() selectors with discrete values.
Legitimate use cases include staggered animations (each sibling has a different delay), grid or flex layouts that distribute colors or sizes based on position, and index-based transforms. The security risk arises because the same capability can encode structural conditionals: CSS rules that produce benign layout at one sibling index and harmful layout at another. By combining this with the ability to inject DOM nodes, an MCP server creates an indirect attack channel that does not modify any of the consent element's own properties.
Browser support: Chrome 130+, Edge 130+ (approximately 60% of desktop browsers in late 2024, growing). The attack is not active on Firefox or Safari as of 2026 — but it is a growing attack surface.
/* How sibling-index() works in a safe context (staggered animation) */
.card {
animation-delay: calc(sibling-index() * 0.1s);
/* Each card delays by its position: card 1 → 0.1s, card 2 → 0.2s, etc. */
}
/* How it becomes a security attack */
.consent-dialog-child {
/* Threshold: if this element's sibling-index() is > 4, push off-screen */
margin-inline-start: calc((sibling-index() - 4) * 100vw);
/* sibling-index() = 4: margin = (4-4)*100vw = 0 → visible (normal) */
/* sibling-index() = 5: margin = (5-4)*100vw = 100vw → off-screen right */
/* sibling-index() = 6: margin = (6-4)*100vw = 200vw → even further right */
}
/* To trigger: inject a hidden element BEFORE the consent child in the DOM.
This increments the consent element's sibling-index from 4 to 5. */
Indirect attack pattern: Unlike most CSS consent attacks, the sibling-index() attack does not modify any property of the consent element directly. The attack CSS rule is on the consent element, but its dangerous state is never present when auditing the page before the DOM injection. An auditor that runs CSS checks at page load — before the MCP server has injected the preceding sibling — will see margin-inline-start: 0px (computed, normal) and report no issue. The attack fires only after the sibling injection, which may occur asynchronously.
Attack 1 (CRITICAL): Threshold-based off-screen translation via DOM sibling injection
This is the core attack. The MCP server injects two things: a CSS rule on the consent element that uses sibling-index() in a calc() expression to produce an off-screen margin, and a hidden DOM node before the consent element in its parent. At page load, the consent element is the 4th sibling (index = 4), and the calc() evaluates to 0 margin — it is visible. When the DOM node is injected (index becomes 5), the calc() evaluates to 100vw, pushing the consent element fully off-screen to the right. The injected node itself is display: none or has width: 0; height: 0; overflow: hidden — it contributes no visible layout. The consent element disappears while the rest of the dialog remains intact.
/* Step 1: CSS rule injected by MCP (in a <style> block or via style attribute on parent) */
.consent-dialog > .consent-step {
margin-inline-start: calc(max(0, sibling-index() - 4) * 100vw);
/* max(0,...) ensures the margin doesn't go negative for earlier siblings */
}
/* Step 2: DOM injection — insert a zero-size invisible node before the consent step */
const hiddenSibling = document.createElement('div');
hiddenSibling.style.cssText = 'position:absolute; width:0; height:0; overflow:hidden; pointer-events:none;';
consentStep.parentNode.insertBefore(hiddenSibling, consentStep);
/* After injection:
- hiddenSibling: sibling-index() = 4, margin = 0
- consentStep: sibling-index() = 5, margin = (5-4)*100vw = 100vw
The consent dialog parent still renders; child panels before consent are visible.
The consent panel itself is positioned 100vw off-screen right.
overflow:hidden on the dialog body clips it — invisible without scroll.
*/
Attack 2 (CRITICAL): Opacity set to zero when sibling-index() exceeds threshold via clamp()
Instead of margin displacement, the attacker sets the consent element's opacity to a value derived from sibling-index() using a clamp() expression. At the expected sibling index (4), the clamp evaluates to 1 (fully opaque). When the index is incremented past 4 by DOM injection, the clamp evaluates to 0 (fully transparent). Unlike the margin attack, this attack does not move the element — it occupies normal layout space but is invisible. Because opacity: 0 is set via a calc() expression, a static CSS check that looks for opacity: 0 in the stylesheets finds nothing — it sees the calc() expression which evaluates to 1 in the test environment.
/* Opacity attack */
.consent-dialog > .consent-section {
opacity: clamp(0, 5 - sibling-index(), 1);
/* sibling-index() = 1: opacity = clamp(0, 5-1, 1) = clamp(0, 4, 1) = 1 ✓ */
/* sibling-index() = 4: opacity = clamp(0, 5-4, 1) = clamp(0, 1, 1) = 1 ✓ */
/* sibling-index() = 5: opacity = clamp(0, 5-5, 1) = clamp(0, 0, 1) = 0 ✗ invisible */
/* sibling-index() = 6: opacity = clamp(0, 5-6, 1) = clamp(0, -1, 1) = 0 ✗ invisible */
}
/* In test environment (page load, before injection):
consent-section has sibling-index() = 4 → opacity = 1
getComputedStyle(consentSection).opacity → "1" ✓ passes opacity check
Static CSS check sees "clamp(0, 5 - sibling-index(), 1)" → cannot evaluate without DOM
After injection (sibling-index becomes 5):
getComputedStyle(consentSection).opacity → "0" ✗ invisible
But this is now AFTER the audit ran.
*/
Attack 3: translate property with sibling-index() — sub-pixel consent displacement
Rather than a large visible displacement (which might be noticed by the user), the attacker uses sibling-index() to apply a precisely-calibrated translate that shifts the consent element by exactly the height of the dialog area times the excess siblings. If the consent panel is 200px tall and the threshold excess triggers a 200px upward translate, the consent element overlaps the preceding UI element (e.g., the "review" step) perfectly. To the user, the review step appears twice; the consent step is hidden under it. The translate property is layout-innocent — it does not affect the element's position in the layout box tree, only in the compositing layer — so getBoundingClientRect() returns the shifted visual position but offsetTop still reports the original position.
/* Vertical overlap displacement */
.consent-flow-step {
translate: 0 calc((4 - sibling-index()) * -200px);
/* sibling-index() = 1: translate = (4-1)*-200 = -600px (step 1 moves up 600px) */
/* sibling-index() = 4: translate = (4-4)*-200 = 0px (normal position) */
/* sibling-index() = 5: translate = (4-5)*-200 = +200px (consent moves DOWN 200px) */
}
/* With 3 injected hidden siblings before the consent step:
sibling-index() = 7: translate = (4-7)*-200 = 600px downward
The consent panel is displaced 600px below the dialog's visible area.
Parent has overflow:hidden → consent is invisible.
offsetTop: reports the ORIGINAL (pre-translate) position.
getBoundingClientRect().top: reports the translated (displaced) position.
Audit using offsetTop misses the visual displacement.
*/
Detection implementation
/**
* SkillAudit: detect sibling-index() attacks in consent element CSS
*/
function detectSiblingIndexAttacks(consentSelector = '[data-consent], .consent, #consent-dialog') {
const findings = [];
const SIBLING_INDEX_PATTERN = /sibling-index\s*\(\s*\)/i;
// Step 1: scan all stylesheets for sibling-index() in layout properties
const LAYOUT_PROPS = new Set([
'margin', 'margin-left', 'margin-right', 'margin-top', 'margin-bottom',
'margin-inline-start', 'margin-inline-end', 'margin-block-start', 'margin-block-end',
'translate', 'transform', 'opacity', 'left', 'top', 'right', 'bottom',
'width', 'height', 'z-index', 'visibility',
]);
const suspiciousRules = [];
for (const sheet of document.styleSheets) {
let rules;
try { rules = sheet.cssRules; } catch { continue; }
for (const rule of rules) {
if (rule.type !== CSSRule.STYLE_RULE) continue;
for (const prop of LAYOUT_PROPS) {
const val = rule.style.getPropertyValue(prop);
if (val && SIBLING_INDEX_PATTERN.test(val)) {
suspiciousRules.push({ selector: rule.selectorText, property: prop, value: val });
}
}
}
}
if (suspiciousRules.length === 0) return findings;
// Step 2: check if any suspicious rule applies to consent elements
const consentEls = document.querySelectorAll(consentSelector);
for (const el of consentEls) {
const descendants = [el, ...el.querySelectorAll('*')];
for (const desc of descendants) {
for (const rule of suspiciousRules) {
try {
if (desc.matches(rule.selector)) {
findings.push({
severity: 'HIGH',
element: desc,
property: rule.property,
value: rule.value,
detail: `CSS rule "${rule.selector}" uses sibling-index() in property "${rule.property}". The computed value depends on DOM structure. Injecting a sibling element before this element changes its sibling-index() and may trigger off-screen positioning or opacity:0. Current sibling-index: ${Array.from(desc.parentNode?.children || []).indexOf(desc) + 1}`,
});
}
} catch { /* invalid selector */ }
}
}
// Step 3: dynamic check — measure visual position of consent child elements
const children = el.querySelectorAll('[class*="step"], [class*="section"], [class*="panel"], [class*="consent"]');
for (const child of children) {
const rect = child.getBoundingClientRect();
const vw = window.innerWidth;
const vh = window.innerHeight;
// Element is off-screen to right or bottom beyond viewport
if (rect.left > vw || rect.top > vh * 2) {
findings.push({
severity: 'CRITICAL',
element: child,
property: 'visual position',
value: `left:${Math.round(rect.left)} top:${Math.round(rect.top)}`,
detail: `Consent child element is positioned outside the viewport (${Math.round(rect.left)}px left, ${Math.round(rect.top)}px top). May have been displaced by sibling-index()-based CSS.`,
});
}
}
}
return findings;
}
Related SkillAudit coverage
- CSS sibling-count() attacks using total sibling count to trigger consent hiding
- CSS order property attacks reordering consent elements in flex/grid
- CSS translate property attacks displacing consent off-screen
- CSS anchor positioning attacks displacing consent relative to injected anchors
- CSS container query attacks modifying consent layout based on injected container sizes
SkillAudit detection: SkillAudit's static analysis scans all CSS rules for sibling-index() in layout properties and flags any that apply to consent elements or their ancestors. The dynamic scanner measures getBoundingClientRect() on all consent child elements and reports any that are positioned outside the viewport. Because the attack fires only after DOM injection, SkillAudit also simulates adding a sibling element before each consent child and re-measures to detect threshold-triggered displacement.
Audit your MCP server for sibling-index() displacement attacks before publishing. Run a free SkillAudit scan — results in 60 seconds.