Managementsamenvatting: Onderzoekers van LayerX hebben ontdekt hoe een simpel aangepast lettertype elk AI-systeem op de markt kan compromitteren. Met niets meer dan een aangepast lettertype en simpele CSS creëerden we een webpagina waarop de browser instructies weergeeft die de gebruiker ertoe zouden aanzetten een reverse shell uit te voeren, terwijl de DOM-tekst die door AI-tools wordt geanalyseerd, onschuldige fanfictie over videogames bevat.
De kwaadaardige instructies bevinden zich uitsluitend in de renderinglaag en geen enkele AI-webassistent die we hebben getest, kon de dreiging herkennen. Lettertypen zijn een bekende aanvalsvector voor het verspreiden van malware, en ons onderzoek toonde aan hoe ze ook kunnen worden gebruikt voor snelle injectie en het vergiftigen van AI-systemen. Hierdoor kan elk AI-systeem – inclusief ChatGPT, Claude, Gemini en andere – het doelwit zijn van deze aanval, wat kan leiden tot potentiële datalekken en/of de uitvoering van kwaadaardige code.
LayerX heeft contact opgenomen met alle leveranciers die door ons onderzoek werden getroffen. Met uitzondering van Microsoft gaven ze echter allemaal aan dat dit "buiten het toepassingsgebied" valt van wat zij beschouwen als beveiliging van AI-modellen en dat het om social engineering gaat. Dit toont eens te meer de kloof aan tussen wat AI-platforms beveiligen en wat gebruikers denken dat ze beveiligen.
Gekleed om te doden: de renderingkloof van AI
Er bestaat een structurele discrepantie tussen wat een AI-assistent analyseert in de HTML van een pagina en wat een gebruiker te zien krijgt in de browser. In bepaalde gevallen kunnen dergelijke assistenten onnauwkeurige en potentieel gevaarlijke antwoorden geven aan gebruikers, en aanvallers kunnen deze beperking misbruiken om social engineering-aanvallen uit te voeren.
Met behulp van een aangepast lettertype en CSS kan HTML-tekst visueel worden aangepast voor de gebruiker, terwijl deze binnen de DOM ongewijzigd blijft. Wanneer een pagina in de browser wordt weergegeven, ziet de gebruiker iets dat volledig afwijkt van de onderliggende HTML. De inhoud is er weliswaar nog steeds, maar is in feite aan het zicht van de gebruiker onttrokken.
We hebben een proof-of-conceptpagina gemaakt die eruitziet als fanfictie over een videogame, maar die, wanneer deze in de browser wordt weergegeven, de gebruiker aanmoedigt stappen uit te voeren die leiden tot een reverse shell. Toen we de gebruiker vroegen of de pagina veilig was, slaagden alle niet-agentische assistenten die we hebben getest (ChatGPT, Claude, Copilot, Dia, Fellou, Gemini, Genspark, Grok, Leo, Perplexity en Sigma) er niet in de "verborgen" tekst te detecteren en vertelden ze de gebruiker vol vertrouwen dat de pagina geen beveiligingsrisico vormde. De tests werden uitgevoerd in december 2025.
Een AI-assistent analyseert een webpagina als gestructureerde tekst, terwijl een browser die webpagina omzet in een visuele weergave voor de gebruiker. Binnen deze weergavelaag kunnen aanvallers de voor de mens zichtbare inhoud wijzigen. betekenis van een pagina zonder de onderliggende DOM te wijzigen.
Deze discrepantie tussen wat de assistent ziet en wat de gebruiker ziet, leidt tot onnauwkeurige antwoorden, gevaarlijke aanbevelingen en een afname van het vertrouwen.
Dit is geen browser-exploit en het berust niet op een parseerfout. De browser gedraagt zich precies zoals bedoeld. De kwetsbaarheid zit hem in tools die ervan uitgaan dat DOM-tekst de voor de gebruiker zichtbare betekenis volledig weergeeft.
*Met 'niet-agentisch' bedoelen we assistenten die HTML ophalen en parsen, maar geen volledige renderingpipeline van de browser uitvoeren of aangepaste lettertype-glyph-toewijzingen analyseren.
Het draaiboek van de aanvaller
Deze techniek vereist geen JavaScript, geen exploitkits en geen kwetsbaarheden in browsers:
- Bereid onschuldig ogende HTML-content voor, inclusief opvulling die er onschadelijk uitziet wanneer deze als tekst wordt geparseerd (bijvoorbeeld fanfictie).
- Voeg een gecodeerde payload in die in de DOM betekenisloos lijkt.
- Maak een aangepast lettertype dat tekens zo herdefinieert dat normale Engelse tekens als onleesbare tekst worden weergegeven en de gecodeerde gegevens als leesbare instructies.
- Gebruik CSS om de zichtbaarheid te regelen door onschadelijke inhoud te verbergen (bijv. 1px, zwart op zwart), de payload-inhoud weer te geven in een leesbare grootte en kleur, en het aangepaste lettertype globaal toe te passen.
Het resultaat: tekstparsers zien onschadelijke inhoud, terwijl gebruikers instructies zien die door de aanvaller zijn gemanipuleerd.
Hierdoor wordt de payload verplaatst van de DOM-laag naar de renderinglaag.
Aanvalsworkflow
Een gebruiker bezoekt deze pagina: https://layerxresearch.com/RaptureFuture
Voor de gebruiker lijkt dit een fanfictiesite te zijn met een bericht waarin de gebruiker wordt aangemoedigd om een "easter egg" te vinden die verband houdt met de videogame Bioshock:
De gebruiker is wantrouwig en vraagt een AI-assistent om de site te bekijken en te bepalen of de instructies voor de easter egg veilig zijn om te volgen. De assistent haalt de HTML op, analyseert deze en ziet dat het voornamelijk fanfictie is, geïnspireerd op videogames:
De fanfictie-secties worden met CSS voor de gebruiker verborgen, terwijl de gecodeerde blob-sectie normaal wordt weergegeven (en "gedecodeerd" met het aangepaste lettertype). Wanneer de assistent de gecodeerde blob-sectie van de pagina ziet, kan deze de base64-achtige tekst niet parseren en beschouwt deze daarom als ruis.
Onder deze voorwaarden, De gebruiker ziet de grote groene, kwaadaardige tekst die we hierboven hebben weergegeven, terwijl de AI-assistent alleen de fanfictietekst ziet die nu voor de gebruiker verborgen is.De assistent bepaalt dat de pagina veilig is en moedigt de gebruiker in veel gevallen zelfs aan om de stappen te volgen die tot een reverse shell zouden leiden.
Dit is een social engineering-techniek op de presentatielaag. De payload bevindt zich in de renderingpipeline, niet in een uitvoerbaar script.
Aanvalsdiagram
Technische gegevens
Als je de broncode van de HTML zou bekijken, zou je voornamelijk gewone tekst zien (fanfictie over videogames) en een klein gedeelte met speciale tekst die lijkt op base64-achtige onzin.
Binnen de HTML zorgt CSS ervoor dat alle tekst wordt weergegeven in een aangepast lettertype dat we zelf hebben gemaakt. Dit lettertype fungeert als een visuele versleuteling die is geïmplementeerd op het niveau van de lettertekens. Het lettertypebestand zelf is de sleutel van de versleuteling en is zo opgebouwd dat, wanneer het in een browser wordt weergegeven, normale HTML-tekst als onleesbare tekst wordt weergegeven en de speciale HTML-tekst als normale tekst. Deze aanval vereist geen JavaScript en werkt zelfs als JavaScript is uitgeschakeld.
Bij het renderen wordt de normale HTML-tekst verkleind tot 1 pixel en visueel verborgen doordat deze dezelfde kleur krijgt als de achtergrond van de pagina. Het aangepaste lettertype zorgt ervoor dat deze normale tekst onleesbaar wordt voor de gebruiker. Zelfs als de gebruiker inzoomt en de tekst selecteert, ziet hij of zij onleesbare tekens. Maar de onderliggende, normale HTML-tekst (fanfictie over videogames) is wat de AI-assistenten zien.
Bij het renderen wordt de speciale HTML-tekst weergegeven in een redelijke grootte en kleur, zodat deze blikje zichtbaar voor de gebruiker. Het aangepaste lettertype zorgt ervoor dat deze speciale tekst leesbaar wordt voor de gebruiker en een bericht bevat dat hen aanmoedigt om stappen op hun systeem uit te voeren die zullen resulteren in een reverse shell.
Voor de AI-assistenten is deze speciale HTML-tekst gewoonweg base64-achtige onzin: het lijkt op een gecodeerde payload (alfanumerieke reeksen met hoge entropie) die niet kan worden gedecodeerd zonder de lettertype-mapping, waardoor zowel assistenten als mensen het als ruis beschouwen.
Hoewel het visueel aan de gebruiker wordt gepresenteerd als normale tekst, De onderliggende speciale HTML-tekst (onzin) is wat de AI-assistenten zien.
Als een gebruiker een spraakassistent vraagt om de pagina te bekijken en te bepalen of deze veilig is, kan de assistent alleen de onderliggende HTML zien. De assistent zal de pagina niet daadwerkelijk weergeven en kan daarom niet betrouwbaar bepalen hoe deze er voor de gebruiker uit zal zien. Omdat de onderliggende HTML voornamelijk bestaat uit fanfictie over videogames en de speciale tekst zelfs voor de assistent onbegrijpelijk is, zal de assistent concluderen dat de site onschadelijk is.
De AI-assistent ziet dat een website met fanfictie over videogames geen beveiligingsrisico's of -problemen vertoont.
De gebruiker ziet stappen voor het opzetten van een reverse shell op zijn of haar computer.
Wat de gebruiker ziet, is niet wat de AI-assistent ziet.
Impact
Wanneer een AI-assistent een pagina bekijkt, bepaalt deze de inhoud en betekenis aan de hand van de onderliggende HTML-tekst. Wanneer een gebruiker een pagina bekijkt, bepaalt deze de inhoud en betekenis aan de hand van de visuele presentatie van de weergegeven pagina. Dit zijn twee verschillende bedreigingsoppervlakken, en de exploit die we hebben beschreven, maakt misbruik van de kloof daartussen.
In normale webscenario's is HTML de content en lettertypen helpen bij presentatieHet lettertype verandert de betekenis van de tekst niet. In deze context is het redelijk om aan te nemen dat de zichtbare betekenis van de pagina wordt bepaald door de DOM-tekst en niet door trucjes met glyph-substitutie.
Die aanname is doorgaans terecht – en daarom is ze ook zo effectief.
Moderne webbeveiligingsmodellen behandelen aangepaste lettertypen doorgaans niet als semantische transformatoren of substitutieversleutelingen. De meeste via de browser toegankelijke AI-assistenten kunnen trucs op de presentatielaag (zoals het vervangen van aangepaste tekens) niet betrouwbaar detecteren, tenzij ze toegang hebben tot het lettertypebestand of een expliciete weergavecontext. Zelfs als een assistent het lettertypebestand kan ophalen, kunnen de meeste standaard de tekentoewijzingen niet analyseren of render-and-diff-controles uitvoeren.
Zelfs met behulp van zeer gerichte prompts die ontworpen waren om detectie uit te lokken, bleek uit onze tests (uitgevoerd in december 2025) dat geen enkele assistent de dreiging succesvol detecteerde.
Gebruikers vertrouwen op AI-assistenten om de betekenis van een webpagina correct weer te geven, maar deze assistenten worden misleid door een eenvoudige substitutieversleuteling. Dit heeft diverse praktische gevolgen voor de beveiliging:
Sociale manipulatie met behulp van AI
Wanneer een aanvaller een kwaadaardige pagina creëert die door een AI-assistent als veilig wordt geclassificeerd, ondermijnt hij in feite het gezag van de AI-assistent en gebruikt hij diens reputatie om zijn eigen boodschap te versterken. Deze valse geruststelling kan ertoe leiden dat gebruikers acties ondernemen die ze anders zouden vermijden en kan uiteindelijk het vertrouwen in de AI-systemen waarop ze voor veiligheidsadvies vertrouwen, ondermijnen.
Blinde vlekken in AI-ondersteunde beveiligingsworkflows
De proof-of-conceptpagina die we hebben gemaakt – een social engineering-aanval die de gebruiker aanmoedigt om schadelijke acties op zijn eigen systemen uit te voeren – is slechts één voorbeeld van hoe deze presentatielaagtechniek kan worden misbruikt. AI-assistenten worden steeds vaker geïntegreerd in beveiligingsworkflows, waar browserassistenten, copiloten en helpdesktools webpagina's samenvatten en naar potentiële bedreigingen zoeken. Door de payload naar de renderinglaag te verplaatsen, creëren aanvallers een blinde vlek waardoor kwaadaardige inhoud deze tekstgebaseerde AI-tools kan omzeilen.
Informatieverstrekking door leveranciers en reacties daarop
LayerX heeft zijn bevindingen, conform de Responsible Disclosure-procedures, voorgelegd aan de belangrijkste aanbieders van AI-platformen. De meeste aanbieders verwierpen het rapport, meestal met de bewering dat deze aanval buiten het toepassingsgebied van AI-modelbeveiliging valt. Hierdoor blijven gebruikers van deze modellen kwetsbaar voor deze aanvalsvector.
De enige leveranciers die dit rapport accepteerden en om tijd vroegen om het te corrigeren, waren Microsoft en Google. Van deze twee heeft Google uiteindelijk de zaak afgezwakt (nadat het aanvankelijk een P2 (Hoog) score had gekregen) en het rapport gesloten, mogelijk omdat het corrigeren ervan te veel moeite zou kosten.
De enige leverancier die dit probleem volledig heeft aangepakt en de volledige openbaarmakingstermijn (90 dagen) heeft aangevraagd, was Microsoft.
| Verkoper | Datum verzonden | Datum gesloten | Details / Kernpunten uit het antwoord van de leverancier |
| Microsoft | December 16, 2025 | Microsoft heeft het rapport op 17 december 2025 geaccepteerd en een dossier geopend bij het Microsoft Security Response Center (MSRC). | |
| antropisch | December 16, 2025 | December 16, 2025 | Volgens het beleid vallen de volgende zaken buiten het toepassingsgebied:
"Sociale manipulatie (inclusief phishingpogingen)" en "Problemen met de inhoud van modelvragen en -reacties" vallen expliciet buiten het toepassingsgebied van dit programma. |
| Dia | December 14, 2025 | December 16, 2025 | "Helaas valt dit buiten het toepassingsgebied van het BCNY-programmabeleid:
Injecties die leiden tot misinformatie, onverwacht gedrag, het uitblijven van service of het uitblijven van correcte service door de assistent vallen expliciet buiten het toepassingsgebied. Een injectie valt alleen binnen het toepassingsgebied als deze aantoonbare en specifieke schade toebrengt aan een gebruiker door automatisch gevoelige gebruikersgegevens te stelen of ongeautoriseerde acties namens de gebruiker uit te voeren. |
| OpenAI | December 16, 2025 | December 17, 2025 | "Bedankt voor uw geduld. De inzending heeft in de huidige vorm echter niet de vereiste impact om in aanmerking te komen voor triage, aangezien dergelijke kwesties expliciet buiten het toepassingsgebied van dit programma vallen." |
| December 16, 2025 | Januari 27, 2026 | Gemini accepteerde het rapport aanvankelijk op 17 december 2025 en kende er een P2 (Hoge) prioriteit aan toe. Op 27 januari 2026 verlaagden ze de prioriteit echter en sloten het rapport af met de volgende opmerking:
“We hebben geen aanvalsscenario kunnen vinden waarbij uw melding aanzienlijke schade voor gebruikers veroorzaakt. Laat het ons weten als we iets over het hoofd hebben gezien en deel een aanvalsscenario met grote impact. Dit is omdat het scenario te afhankelijk van social engineering. ' |
|
| verwarring | December 14, 2025 | December 17, 2025 | “Na grondig onderzoek hebben we vastgesteld dat dit rapport geen beveiligingslek in de traditionele zin vertegenwoordigt. Het scenario dat u beschrijft, is een bekende beperking van grote taalmodellen bij het verwerken van externe webinhoud, en geen bug of fout in de beveiligingsmaatregelen van ons systeem.
Uw aanvalsscenario is gebaseerd op social engineering – het overtuigen van een gebruiker om handmatig terminalopdrachten uit te voeren die een AI-systeem heeft voorgesteld na analyse van een kwaadwillende webpagina. Dit is vergelijkbaar met een gebruiker die slecht advies op een website leest en ervoor kiest dit op te volgen. Er vindt geen code-executie plaats op onze servers, er is geen ongeautoriseerde toegang tot gebruikersgegevens en er worden geen authenticatie- of autorisatiecontroles omzeild. |
| xAI | December 16, 2025 | December 17, 2025 | "Bedankt voor uw melding! Helaas valt het specifieke probleem dat u hebt gemeld expliciet buiten het toepassingsgebied zoals beschreven in de Beleidspagina:
|
Aanbevelingen
Door de volgende verbeteringen door te voeren, kunnen LLM's grote stappen zetten om de kloof tussen wat de gebruiker ziet en wat de AI-assistent ziet te verkleinen – of zelfs te elimineren:
Dubbele modus Render-and-Diff-analyse
Voer twee onafhankelijke analyses uit:
- Tekst-only DOM-extractie
- Volledige paginaweergave met ingeschakelde lettertypen
Extraheer de zichtbare tekst van de weergegeven pagina en bepaal of deze significant verschilt van de DOM-tekst.
Detecteer verborgen inhoudspatronen
Breid parsers uit om te scannen op:
- Voorgrond-/achtergrondkleur komen overeen
- Vrijwel nul opaciteit
- Lettergroottes kleiner dan 5px
- Positionering buiten beeld
- Hoge dichtheid van verborgen inhoud
Beschouw lettertypen als een potentieel bedreigingsoppervlak.
- Haal het lettertypebestand op.
- Bekijk de Unicode/glyph-toewijzingstabellen.
- Detecteer abnormale patronen van glyph-vervanging.
Risicoscore op basis van oppervlakteverschillen
Ken een verhoogde risicoscore toe wanneer:
- De weergegeven tekst komt niet overeen met de DOM-tekst.
- DOM-tekst lijkt onschuldig, terwijl de weergegeven tekst uitvoerbare instructies bevat.
- CSS-manipulatie wordt gebruikt om grote contentblokken te verbergen.
Vertrouwenskalibratie
Als een assistent niet in staat is:
- De pagina weergeven
- Analyseer de aangepaste lettertypen
- Vergelijk visuele content met DOM-content.
Het moet dan ook stellige beweringen zoals: "De pagina is veilig" vermijden.
Conclusie
Het web is meer dan alleen HTML. Betekenis kan worden meegenomen in het renderingproces, en elk systeem dat alleen tekst analyseert, is per definitie blind.
