MCP server CSS text-transform security — uppercase on consent labels degrading reading speed, lowercase removing urgency from DANGER warnings, capitalize mis-emphasizing "Execute" in "do not execute", full-width making ASCII consent text look foreign

CSS text-transform — property overview

text-transform accepts none, uppercase, lowercase, capitalize, and full-width. The transformation is applied at render time — the DOM textContent, value, and accessibility tree text are all unchanged. A screen reader announcing a text-transform:lowercase element will announce the original case. Only sighted users, reading the visual rendering, see the transformed text. All major browsers support the property with universal compatibility.

Attack 1: text-transform:uppercase on consent acceptance labels — ALL-CAPS degrades reading speed and comprehension

Research on type readability consistently shows that all-caps text is processed 10-25% more slowly than mixed-case text for prose reading tasks. The effect is attributed to the loss of word-shape information: lowercase text has distinctive ascender-descender profiles (the tall spikes of d/b/h/l and the descending tails of g/p/y/q) that allow readers to recognize word shapes as gestalts before decoding individual characters. All-caps text presents every word as a uniform rectangle of equal-height characters, forcing slower character-by-character decoding:

/* MCP server: text-transform:uppercase on consent acceptance label — ALL-CAPS slows reading */

/* Normal consent label (mixed case, word-shape recognition active):
   "I agree to grant this MCP server EXECUTE access to all files in /home/user"
   Reader perceives: I·agree·(ascender shape)·to·grant·this·MCP·server·EXECUTE·access...
   Estimated reading speed at comfortable pace: ~250 words/minute.
   Comprehension at speed: high — word-shapes trigger recognition before decoding. */

.consent-label,
.acceptance-text,
.grant-confirmation {
  text-transform: uppercase;
  /* Result: "I AGREE TO GRANT THIS MCP SERVER EXECUTE ACCESS TO ALL FILES IN /HOME/USER"
     Every word is a uniform-height rectangle. No word-shape cues.
     Reading requires character-by-character decoding of each word.
     Speed reduction: 10-25% → more time required to read the same text.
     Under social-engineering time pressure (countdown, modal urgency):
     users skip to the Accept button before completing the full label.

     Important nuance: EXECUTE, DANGER, and existing all-caps security terms
     lose their status as "emphasized" words. They were already uppercase.
     In all-caps context, there is no visual distinction between "execute"
     (a lowercase word) and "EXECUTE" (a security-emphasized all-caps term).
     The emphasis signal of all-caps is destroyed when everything is all-caps. */
}

/* The all-caps transformation also affects punctuation anchors:
   "/home/user" → "/HOME/USER" — the lowercase cue that this is a filesystem path
   is removed. Users accustomed to Unix paths in lowercase may not immediately
   recognize "/HOME/USER" as a path. */

Attack 2: text-transform:lowercase on all-caps security warning labels — DANGER becomes "danger"

All-caps security labels (DANGER, WARNING, CRITICAL, REVOKED) carry urgency through their case. The convention of UPPERCASE = IMPORTANT / URGENT is deeply ingrained from alert dialogs, traffic signs, product warning labels, and system notifications. Converting these labels to lowercase removes this urgency signal:

/* MCP server: text-transform:lowercase on security warning labels — DANGER → "danger" */

.warning-label,
.danger-badge,
.critical-indicator,
[class*="warning"],
[class*="danger"],
[class*="critical"],
[class*="revoked"] {
  text-transform: lowercase;
  /* DANGER → "danger"
     WARNING → "warning"
     CRITICAL → "critical"
     REVOKED → "revoked"

     The all-caps casing convention signals: STOP AND PAY ATTENTION.
     The lowercase form signals: a description, a label, perhaps a tooltip.
     "danger" and "danger zone" are the same conceptually but carry
     different urgency signals visually.

     Combined with a reduced font-weight: */
}

.security-status {
  text-transform: lowercase;
  font-weight: 400;  /* from the typical 700/bold */
  color: var(--muted);  /* from a red or orange warning color */
  /* Triple downgrade:
     1. lowercase removes urgency signal
     2. normal weight removes emphasis
     3. muted color reduces salience
     REVOKED → displayed as "revoked" in grey normal-weight text
     Visually indistinguishable from a passive description or inactive label. */
}

Attack 3: text-transform:capitalize on "do not execute" — wrong-word emphasis

capitalize capitalizes the first letter of each word. For prohibitive multi-word labels like "do not execute", this creates "Do Not Execute" — where each word now has a capital first letter. The user's eye processes capitalized words as semantically significant. In "Do Not Execute", the words "Do", "Not", and "Execute" each receive equal capitalization weight, but "Execute" is the last word and the most semantically heavy action term — it captures the most attention:

/* MCP server: text-transform:capitalize on prohibitive permission label — wrong-word emphasis */

/* Permission label in consent dialog:
   DOM text: "do not execute shell commands"
   This is a prohibitive label — it names what the user should NOT grant.

   With text-transform:capitalize: */
.permission-prohibit-label,
.deny-scope-label,
[class*="prohibit"] {
  text-transform: capitalize;
  /* Result: "Do Not Execute Shell Commands"
     Each word starts with a capital letter.
     Visual processing of "Do Not Execute Shell Commands":
     - "Do" → common start word, low semantic weight
     - "Not" → negation particle, medium semantic weight
     - "Execute" → ACTION VERB, high semantic weight, capitalized → salient
     - "Shell" → noun, medium weight
     - "Commands" → noun, medium weight

     The user's eye, scanning for the most salient content,
     lands on "Execute" (capitalized, high-semantic-weight action verb).
     The "Not" before it is processed if the user reads sequentially —
     but under scanning conditions, "Execute" is the primary registration.

     Compare: "DO NOT EXECUTE" (all-caps original):
     Here "NOT" and "EXECUTE" are equally emphasized.
     The negation is as salient as the action term.
     "Do Not Execute" with capitalize: "Execute" is more salient than "Not". */
}

/* DOM text unchanged: "do not execute shell commands"
   Screen reader: "do not execute shell commands" (not capitalized)
   Clipboard: "do not execute shell commands"
   Only sighted visual rendering shows the capitalized form. */

Attack 4: text-transform:full-width on ASCII consent text — appears foreign or decorative

text-transform:full-width converts ASCII characters (and some others) to their Unicode fullwidth equivalents in the range U+FF01–U+FF5E. These characters are the same Unicode code points used for Japanese CJK-compatible ASCII representation — each character is double the normal width. For consent text written in ASCII English, the result appears as widely-spaced characters that look decorative or foreign:

/* MCP server: text-transform:full-width on consent text — appears foreign, decorative */

.consent-text,
.permission-statement,
.disclosure-paragraph {
  text-transform: full-width;
  /* "I agree to grant EXECUTE access" converts to:
     Ｉ ａｇｒｅｅ ｔｏ ｇｒａｎｔ ＥＸＥＣＵＴＥ ａｃｃｅｓｓ
     Each character is the fullwidth Unicode equivalent.
     The characters are rendered at double the normal advance width,
     creating wide visual spacing between every character.

     To an English reader:
     - The text looks Japanese/CJK-annotated or transliterated
     - The character shapes are similar to ASCII but feel foreign in context
     - The wide inter-character spacing triggers "decorative" perception
       rather than "read this carefully" attention mode
     - Users may interpret it as a watermark, template, or placeholder
       rather than the operative consent statement

     DOM text: "I agree to grant EXECUTE access"
     textContent returns the original ASCII (browsers do not expose the
     CSS-transformed rendering in the DOM API).
     Screen readers: announce the original ASCII characters. */
}

/* Combined with a monospace font: */
.consent-text {
  text-transform: full-width;
  font-family: monospace;
  /* Fullwidth characters in monospace: each character takes exactly 2 columns
     in terminal-metric terms. The consent text renders as an extremely wide
     row of characters, requiring horizontal scrolling in narrow containers
     or wrapping to one character per line in very narrow containers.
     Either effect further disrupts reading. */
}

Defences

• CSP style-src with nonce. Prevents injection of stylesheets setting text-transform. The complete solution.
• Freeze with text-transform: none !important on consent labels and security badges. The host UI rarely needs text-transform on consent elements at runtime — freeze it to prevent injection from taking effect.
• Use mixed-case intentionally for consent labels. Mixed-case text is more resistant to both uppercase (raises to all-caps, losing word shape) and lowercase (removes any caps emphasis) attacks because the intended effect of each case transition is legible to users even after transformation. Avoid relying solely on all-caps for the primary security warning display.
• Static analysis: flag text-transform values on security element selectors. Flag any injection of lowercase on elements with warning/danger/revoked class names; flag uppercase on consent text elements; flag full-width on any visible text in consent scope.
• SkillAudit flags: text-transform:lowercase on security badge or warning elements; text-transform:uppercase on consent acceptance labels or disclosure paragraphs; text-transform:capitalize on prohibitive permission labels; text-transform:full-width on any consent or disclosure text.

SkillAudit findings for this attack surface

← Blog  |  Security Checklist