Researchers from LayerX have presented a new prompt injection technique that targets browser-integrated AI assistants by abusing custom fonts. The method allows attackers to hide a malicious command in plain sight on a web page so that the human user sees the real, dangerous instruction, while the AI assistant only processes a harmless decoy. The attack exploits the gap between what an AI reads in the HTML DOM and what a browser actually renders on the screen.
How the custom font prompt injection attack works
The core of the attack is a combination of custom fonts and glyph substitution. In the HTML, the malicious command is stored as a meaningless-looking string: a sequence of characters that appears as random noise when viewed directly from the DOM. However, a specially crafted font redefines the mapping between character codes and visible symbols, so that the browser renders this “garbage” as a fully legible command for the user.
At the same time, the page contains a benign version of the command text. Through CSS, this safe text is effectively hidden from human eyes — for example, by setting the font size to an extremely small value, matching the text color to the background, or using near-zero opacity. To the AI assistant, which reads the DOM and associated styles but not the final bitmap output, this innocuous text remains visible, while the actual malicious instruction is effectively masked.
Why AI assistants see one thing and users see another
Most modern browser-based AI assistants operate on a structured representation of the page: the HTML, DOM tree, and CSS rules. They typically do not analyze the final, visually rendered page the way a human user does. This means the model “reads” the content before the browser applies font substitutions, advanced CSS effects, and other rendering-time transformations.
According to LayerX, this creates a perception mismatch: the AI assistant processes a safe description while the user is presented with a harmful command. If the victim then asks the assistant to “check whether the command on this page is safe,” the system only evaluates the visible-to-DOM, non-malicious text and confidently reports that the command appears safe.
Proof-of-concept: from game easter egg to reverse shell
To demonstrate real-world impact, LayerX built a proof-of-concept web page that advertises a “hidden easter egg” for the video game Bioshock. The page instructs users to run what looks like an innocuous terminal command to unlock special content. In reality, the rendered command launches a reverse shell, giving an attacker inbound remote access to the victim’s machine once the command is executed.
LayerX reports that, as of December 2025, popular AI assistants including ChatGPT, Claude, Copilot, Gemini, Leo, Grok, Perplexity and others only saw the harmless DOM text and therefore recommended the command as safe. This demonstrates that even security-aware users who rely on AI assistants for validation can be misled when the assistant’s view of the page differs from what the user actually sees.
Vendor reactions and disclosure handling
The researchers notified major AI platform vendors about the issue on 16 December 2025. Many providers classified the report as out of scope, arguing that the scenario primarily involves social engineering: the attacker still needs to persuade the user to copy and manually execute the command.
Microsoft was reportedly the only vendor to fully treat the issue as a security case, opening it in the Microsoft Security Response Center (MSRC) and deploying mitigations that close this attack vector. Google initially assigned a high priority to the finding, but later downgraded it and closed the case, concluding that the vulnerability did not pose sufficient real-world risk to warrant changes at that time.
Security implications and defense strategies for AI assistants
The technique described by LayerX extends the known class of prompt injection and data supply chain attacks against AI models. It underlines that inspecting HTML and the DOM alone is insufficient for systems that automatically analyze web content. Fonts, CSS, and other intermediate rendering layers effectively become part of the attack surface when AI assistants are used to interpret or validate page content.
For technical mitigations, LayerX recommends that AI assistant vendors cross-check the DOM against the fully rendered page. In practice, this may require leveraging a real rendering engine, extracting text after font substitutions, and comparing pre- and post-render strings. Additional safeguards include detecting suspicious CSS patterns such as text that matches the background color, abnormally small font sizes, near-zero opacity, and aggressive use of custom fonts for large text blocks.
These recommendations are consistent with broader industry guidance. The NIST AI Risk Management Framework and the OWASP Top 10 for Large Language Model Applications both highlight prompt injection and untrusted input handling as critical risks. Similarly, incident data from reports such as the Verizon Data Breach Investigations Report (DBIR) repeatedly show that the human factor and over-trust in “smart assistants” are central elements in many successful attacks.
Organizations should complement technical defenses with policy and awareness measures. Internal rules should discourage employees from blindly running commands sourced from web pages or AI-generated explanations, especially in administrative shells, CI/CD pipelines, or cloud consoles. Training should reinforce that AI security advice is an aid, not an oracle, and that commands from unverified sources remain risky even when an assistant labels them as safe.
The emergence of custom font–based prompt injection illustrates that AI assistants must be secured as rigorously as browsers, email clients, and other user-facing applications. Developers integrating AI with web content should reassess their architectures, incorporate visual rendering checks, and treat fonts and CSS as genuine attack vectors. Adopting these practices early will significantly reduce the likelihood that the next seemingly harmless “easter egg” page silently turns into a dangerous reverse shell for unsuspecting users.
