Vergiftete Schriftart: Wie einfache Schriftartdarstellung jeden KI-Assistenten vergiftet – und nur Microsoft sich darum kümmert

Zusammenfassung: Die Forscher von LayerX haben herausgefunden, wie eine einfache, benutzerdefinierte Schriftart jedes KI-System auf dem Markt kompromittieren kann. Mit nichts weiter als einer benutzerdefinierten Schriftart und einfachem CSS erstellten wir eine Webseite, auf der der Browser Anweisungen rendert, die den Benutzer zur Ausführung einer Reverse Shell verleiten, während der von KI-Tools analysierte DOM-Text harmlose Videospiel-Fanfiction enthält. 

Die schädlichen Anweisungen befinden sich ausschließlich in der Rendering-Schicht, und kein von uns getesteter KI-Webassistent konnte die Bedrohung erkennen. Schriftarten sind ein bekannter Einfallstor für Schadsoftware, und unsere Forschung hat gezeigt, wie sie auch für die schnelle Einschleusung und Manipulation von KI-Systemen missbraucht werden können. Daher kann jedes KI-System – einschließlich ChatGPT, Claude, Gemini und anderer – Ziel dieses Angriffs werden, was zu potenziellen Datenlecks und/oder der Ausführung von Schadcode führen kann.

LayerX kontaktierte alle von unserer Studie betroffenen Anbieter. Mit Ausnahme von Microsoft erklärten jedoch alle, dass dies nicht in ihren Zuständigkeitsbereich der KI-Modellsicherheit falle und Social Engineering betreffe. Dies verdeutlicht einmal mehr die Diskrepanz zwischen dem, was KI-Plattformen tatsächlich schützen, und dem, was Nutzer davon halten. 

Dressed to Kill: Die Rendering-Lücke der KI

Es besteht eine strukturelle Diskrepanz zwischen dem, was ein KI-Assistent im HTML-Code einer Webseite analysiert, und dem, was der Browser dem Nutzer anzeigt. In bestimmten Fällen können solche Assistenten Nutzern ungenaue und potenziell gefährliche Antworten geben, und Angreifer können diese Einschränkung für Social-Engineering-Angriffe ausnutzen.

Mithilfe einer benutzerdefinierten Schriftart und CSS lässt sich HTML-Text für den Benutzer visuell verändern, bleibt aber im DOM unverändert. Beim Rendern einer Seite im Browser sieht der Benutzer etwas völlig anderes als den zugrunde liegenden HTML-Code. Der Inhalt ist zwar noch vorhanden, wird aber für den Benutzer ausgeblendet.

Wir haben eine Proof-of-Concept-Seite entwickelt, die wie eine Fanfiction zu einem Videospiel aussieht, aber im Browser den Nutzer zu Schritten animiert, die zu einer Reverse Shell führen. Auf die Frage, ob die Seite sicher sei, erkannten alle getesteten nicht-agentenbasierten Assistenten (ChatGPT, Claude, Copilot, Dia, Fellou, Gemini, Genspark, Grok, Leo, Perplexity und Sigma) den „versteckten“ Text nicht und versicherten dem Nutzer fälschlicherweise, die Seite stelle kein Sicherheitsrisiko dar. Die Tests wurden im Dezember 2025 durchgeführt.

Ein KI-Assistent analysiert eine Webseite als strukturierten Text, während ein Browser diese Webseite für den Benutzer visuell darstellt. Innerhalb dieser Darstellungsebene können Angreifer die für Menschen sichtbare Darstellung verändern. Bedeutung einer Seite, ohne das zugrunde liegende DOM zu verändern.

Diese Diskrepanz zwischen der Sicht des Assistenten und der Sicht des Benutzers führt zu ungenauen Antworten, gefährlichen Empfehlungen und einem schwindenden Vertrauen.

Dies ist kein Browser-Exploit und beruht auch nicht auf einem Parsing-Fehler. Der Browser verhält sich exakt wie vorgesehen. Die Schwachstelle liegt in Tools, die davon ausgehen, dass DOM-Text die für den Benutzer sichtbare Bedeutung vollständig wiedergibt.

*Unter nicht-agentisch verstehen wir Assistenten, die HTML abrufen und analysieren, aber keine vollständige Browser-Rendering-Pipeline ausführen oder benutzerdefinierte Glyphenzuordnungen analysieren.

Das Angreifer-Spielbuch

Diese Technik benötigt weder JavaScript noch Exploit-Kits und nutzt keine Browser-Schwachstellen aus:

1. Bereiten Sie harmlos aussehenden HTML-Inhalt vor, einschließlich Füllinhalt, der beim Parsen als Text unschädlich erscheint (z. B. Fanfiction).
2. Füge eine kodierte Nutzlast ein, die im DOM bedeutungslos erscheint.
3. Erstellen Sie eine benutzerdefinierte Schriftart, die Glyphen so umordnet, dass normale englische Zeichen als Kauderwelsch und die kodierte Nutzlast als lesbare Anweisungen dargestellt werden.
4. Verwenden Sie CSS, um die Sichtbarkeit zu steuern, indem Sie harmlose Inhalte ausblenden (z. B. 1px, schwarz auf schwarz), den Nutzdateninhalt in einer lesbaren Größe und Farbe anzeigen und die benutzerdefinierte Schriftart global anwenden.

Das Ergebnis: Textbasierte Parser sehen harmlose Inhalte, während Benutzer vom Angreifer kontrollierte Anweisungen sehen.

Dadurch wird die Nutzlast von der DOM-Ebene in die Rendering-Ebene verschoben.

Angriffsablauf

Ein Benutzer besucht diese Seite: https://layerxresearch.com/RaptureFuture

Für den Nutzer erscheint dies wie eine Fanfiction-Seite mit einer Nachricht, die den Nutzer dazu auffordert, ein „Easter Egg“ im Zusammenhang mit dem Videospiel Bioshock zu finden:

Der Nutzer ist misstrauisch und bittet einen KI-Assistenten, die Website zu überprüfen und festzustellen, ob die Anweisungen für das Easter Egg sicher sind. Der Assistent ruft den HTML-Code ab, analysiert ihn und sieht, dass es sich hauptsächlich um von Videospielen inspirierte Fanfiction handelt:

Die Fanfiction-Abschnitte werden per CSS ausgeblendet, während der kodierte Textabschnitt normal angezeigt (und mit der benutzerdefinierten Schriftart „dekodiert“) wird. Wenn der Assistent den kodierten Textabschnitt der Seite sieht, kann er den base64-ähnlichen Text nicht parsen und behandelt ihn daher als Rauschen.

Unter diesen Umständen, Der Benutzer sieht den großen grünen, schädlichen Text, den wir oben angezeigt haben, während der KI-Assistent nur den Fanfiction-Text sieht, der dem Benutzer nun verborgen ist.Der Assistent stellt fest, dass die Seite sicher ist, und ermutigt den Benutzer in vielen Fällen sogar dazu, die Schritte zu befolgen, die zu einer Reverse Shell führen würden.

Dies ist eine Social-Engineering-Technik auf der Präsentationsebene. Die Schadsoftware befindet sich in der Rendering-Pipeline, nicht im ausführbaren Skript.

Angriffsdiagramm

Technische Details

Wenn Sie sich den Quelltext des HTML-Codes ansehen würden, fänden Sie hauptsächlich einfachen Text (Videospiel-Fanfiction) und einen kleinen Abschnitt mit speziellem Text, der einer Art Base64-kodiertem Kauderwelsch ähnelt.

Innerhalb des HTML-Codes sorgt CSS dafür, dass der gesamte Text in einer von uns erstellten benutzerdefinierten Schriftart dargestellt wird. Diese Schriftart fungiert als visuelle Substitutionschiffre, die auf Glyphenebene implementiert ist. Die Schriftartdatei selbst ist der Verschlüsselungsschlüssel und so aufgebaut, dass normaler HTML-Text im Browser als unverständlicher Text und der spezielle HTML-Text als normaler Text angezeigt wird. Dieser Angriff benötigt kein JavaScript und funktioniert auch, wenn es deaktiviert ist.

Beim Rendern wird der normale HTML-Text auf 1 Pixel verkleinert und durch die Verwendung der gleichen Farbe wie der Seitenhintergrund optisch ausgeblendet. Die benutzerdefinierte Schriftart führt dazu, dass dieser normale Text für den Benutzer unleserlich erscheint. Selbst wenn er hineinzoomt und den Text markiert, sieht er nur Kauderwelsch. Aber der zugrunde liegende normale HTML-Text (Videospiel-Fanfiction) ist das, was die KI-Assistenten sehen.

Beim Rendern wird der spezielle HTML-Text in einer angemessenen Größe und Farbe angezeigt, so dass er können. Der spezielle Text wird vom Benutzer sichtbar gemacht. Die benutzerdefinierte Schriftart sorgt dafür, dass dieser spezielle Text für den Benutzer lesbar wird und eine Nachricht enthält, die ihn dazu auffordert, Schritte auf seinem System auszuführen, die zu einer Reverse-Shell führen.

Für die KI-Assistenten ist dieser spezielle HTML-Text einfach nur base64-ähnlicher Kauderwelsch: Er ähnelt einer kodierten Nutzlast (alphanumerische Sequenzen mit hoher Entropie), die ohne die Schriftartzuordnung nicht dekodiert werden kann, was dazu führt, dass sowohl Assistenten als auch Menschen ihn als Rauschen behandeln.

Obwohl es dem Benutzer visuell als normaler Text präsentiert wird, Der zugrundeliegende spezielle HTML-Text (Kauderwelsch) ist das, was die KI-Assistenten sehen.

Wenn ein Nutzer einen Assistenten bittet, eine Seite zu prüfen und deren Sicherheit zu beurteilen, kann der Assistent lediglich den zugrundeliegenden HTML-Code einsehen. Er rendert die Seite nicht und kann daher nicht zuverlässig feststellen, wie sie für den Nutzer aussieht. Da der zugrundeliegende HTML-Code hauptsächlich aus Fanfiction zu Videospielen besteht und der spezielle Text selbst für den Assistenten unverständlich ist, stuft dieser die Seite als harmlos ein.

Der KI-Assistent erkennt eine Videospiel-Fanfiction-Seite, die keine Sicherheitsbedrohungen oder -bedenken aufweist.

Der Benutzer sieht die Schritte zum Einrichten einer Reverse-Shell auf seinem Computer.

Was der Benutzer sieht, ist nicht das, was der KI-Assistent sieht.

Auswirkungen

Wenn ein KI-Assistent eine Seite analysiert, ermittelt er Inhalt und Bedeutung anhand des zugrundeliegenden HTML-Textes. Betrachtet ein Nutzer eine Seite hingegen, erschließt er Inhalt und Bedeutung anhand der visuellen Darstellung der gerenderten Seite. Dies sind zwei unterschiedliche Angriffsflächen, und die von uns beschriebene Sicherheitslücke nutzt diese gezielt aus.

In normalen Web-Szenarien ist HTML das Inhalt und Schriftarten helfen dabei presentationDie Schriftart ändert nichts an der Bedeutung des Textes. In diesem Kontext ist es gerechtfertigt anzunehmen, dass die sichtbare Bedeutung der Seite durch den DOM-Text und nicht durch Glyphenersetzungstricks bestimmt wird.

Diese Annahme ist in der Regel richtig – und deshalb ist sie so effektiv.

Moderne Web-Sicherheitsmodelle behandeln benutzerdefinierte Schriftarten üblicherweise nicht als semantische Transformatoren oder Substitutionschiffren. Die meisten browserbasierten KI-Assistenten können Tricks auf der Darstellungsschicht (wie die benutzerdefinierte Glyphenersetzung) nicht zuverlässig erkennen, solange sie keinen Zugriff auf die Schriftartdatei oder einen expliziten Rendering-Kontext haben. Selbst wenn ein Assistent die Schriftartdatei abrufen kann, können die meisten standardmäßig weder die Glyphenzuordnungen analysieren noch Render- und Differenzvergleiche durchführen.

Selbst mit hochgradig zielgerichteten Aufforderungen, die auf eine Erkennung abzielen, konnte in unseren Tests (durchgeführt im Dezember 2025) kein einziger Assistent identifiziert werden, der die Bedrohung erfolgreich erkannte.

Nutzer verlassen sich darauf, dass KI-Assistenten den Inhalt einer Webseite korrekt wiedergeben, doch die Assistenten lassen sich durch eine einfache Substitutionschiffre austricksen. Dies hat mehrere praktische Sicherheitsrisiken zur Folge:

KI-gestütztes Social Engineering

Wenn ein Angreifer eine schädliche Webseite erstellt, die von einem KI-Assistenten als sicher eingestuft wird, missbraucht er dessen Autorität und nutzt dessen Reputation, um seine eigene Botschaft zu verstärken. Diese falsche Sicherheit kann Nutzer zu Handlungen verleiten, die sie sonst vermeiden würden, und letztendlich das Vertrauen in die KI-Systeme untergraben, auf die sie sich bei Sicherheitsfragen verlassen.

Blinde Flecken in KI-gestützten Sicherheitsworkflows

Die von uns erstellte Proof-of-Concept-Seite – ein Social-Engineering-Angriff, der den Nutzer zu schädlichen Aktionen auf seinen eigenen Systemen verleiten soll – ist nur ein Beispiel dafür, wie diese Technik auf der Präsentationsschicht ausgenutzt werden kann. KI-Assistenten werden zunehmend in Sicherheitsworkflows integriert, wo Browser-Assistenten, Copiloten und Helpdesk-Tools Webseiten zusammenfassen und nach potenziellen Bedrohungen suchen. Indem Angreifer die Schadsoftware in die Rendering-Schicht verlagern, schaffen sie eine Schwachstelle, die es schädlichen Inhalten ermöglicht, diese textbasierten KI-Tools zu umgehen.

Offenlegung und Antworten der Anbieter

LayerX übermittelte seine Ergebnisse gemäß den Richtlinien für verantwortungsvolle Offenlegung an die führenden Anbieter von KI-Plattformen. Die meisten Anbieter wiesen den Bericht zurück, in der Regel mit der Begründung, dieser Angriff falle nicht in den Bereich der Sicherheit von KI-Modellen. Daher bleiben die Nutzer dieser Modelle weiterhin diesem Angriffsvektor ausgesetzt.

Die einzigen Anbieter, die diesen Bericht akzeptierten und um Zeit zur Behebung baten, waren Microsoft und Google. Google gab schließlich nach (nachdem der Bericht zunächst mit P2 (Hoch) bewertet worden war) nach und schloss ihn, möglicherweise weil die Behebung zu viel Aufwand erfordert hätte.

Der einzige Anbieter, der dieses Problem vollständig angegangen ist und die volle Offenlegungsfrist (90 Tage) beantragt hat, war Microsoft.

Empfehlungen

Durch die Umsetzung der folgenden Verbesserungen können LLMs große Fortschritte bei der Verringerung – oder sogar Beseitigung – der Diskrepanz zwischen dem, was der Benutzer sieht, und dem, was der KI-Assistent sieht, erzielen:

Dual-Mode-Render-and-Diff-Analyse

Führen Sie zwei unabhängige Analysen durch:

• DOM-Extraktion (nur Text)
• Vollständige Seitendarstellung mit aktivierten Schriftarten

Extrahieren Sie den sichtbaren Text aus der gerenderten Seite und prüfen Sie, ob er sich signifikant vom DOM-Text unterscheidet.

Versteckte Inhaltsmuster erkennen

Erweitern Sie die Parser, um Folgendes zu scannen:

• Vorder-/Hintergrundfarbenübereinstimmung
• Nahezu keine Opazität
• Schriftgrößen unter 5px
• Positionierung außerhalb des Bildschirms
• Hohe Dichte an verborgenem Inhalt

Behandeln Sie Schriftarten als potenzielle Bedrohungsfläche

• Die Schriftartdatei abrufen
• Überprüfen Sie die Unicode/Glyphen-Zuordnungstabellen.
• Anomale Glyphenersetzungsmuster erkennen

Risikobewertung basierend auf Oberflächenabweichungen

Weisen Sie eine erhöhte Risikobewertung zu, wenn:

• Der sichtbare gerenderte Text ähnelt nicht dem DOM-Text.
• Der DOM-Text erscheint harmlos, während der gerenderte Text ausführbare Anweisungen enthält.
• Mithilfe von CSS-Manipulationen lassen sich große Inhaltsblöcke ausblenden.

Vertrauenskalibrierung

Wenn ein Assistent nicht in der Lage ist:

• Seite rendern
• Analysieren Sie die benutzerdefinierten Schriftarten
• Vergleich von visuellem und DOM-Inhalt

Dann sollte man starke Aussagen wie „Die Seite ist sicher“ vermeiden.

Fazit

Das Web besteht nicht nur aus HTML. Bedeutung kann in die Rendering-Pipeline verlagert werden, und jedes System, das nur Text analysiert, ist von Grund auf blind.

• Teilen auf: