Resume: LayerX-forskere har opdaget, hvordan en simpel brugerdefineret skrifttype kan kompromittere alle AI-systemer på markedet. Med intet andet end en brugerdefineret skrifttype og simpel CSS har vi skabt en webside, hvor browseren gengiver instruktioner, der får brugeren til at udføre en reverse shell, mens DOM-teksten, der analyseres af AI-værktøjer, indeholder harmløs videospilsfanfiction.
De ondsindede instruktioner findes kun i renderingslaget, og ingen af de AI-webassistenter, vi testede, kunne identificere truslen. Skrifttyper er en velkendt angrebsvektor til implementering af malware, og vores forskning viste, hvordan de også kan udnyttes til hurtig injektion og forgiftning af AI-systemer. Som et resultat kan alle AI-systemer – inklusive ChatGPT, Claude, Gemini og andre – blive mål for dette angreb, hvilket kan føre til potentiel datalækage og/eller udførelse af ondsindet kode.
LayerX kontaktede alle de leverandører, der var berørt af vores research. Med undtagelse af Microsoft forklarede de dog alle, at dette falder "uden for rammerne" af, hvad de anser for at være AI-modelsikkerhed, og involverer social engineering, hvilket endnu engang demonstrerer uoverensstemmelsen mellem, hvad AI-platforme sikrer, og hvad brugerne tror, de sikrer.
Klædt til at dræbe: AI's gengivelsesgab
Der er en strukturel mangel på sammenhæng mellem, hvad en AI-assistent analyserer i en sides HTML, og hvad en bruger ser gengivet af browseren. I visse scenarier kan sådanne assistenter give unøjagtige og potentielt farlige svar til brugerne, og angribere kan udnytte denne begrænsning til at udføre social engineering-angreb.
Ved hjælp af en brugerdefineret skrifttype og CSS kan HTML-tekst transformeres visuelt for brugeren, men forblive uændret i DOM'en. Når en side gengives i browseren, er det, brugeren ser, helt anderledes end den underliggende HTML. Ja, indholdet er der stadig, men det er effektivt fjernet fra brugerens visning.
Vi byggede en proof-of-concept-side, der ser ud til at være en fanfiction fra et videospil, men når den gengives i browseren, opfordres brugeren til at udføre trin, der fører til en reverse shell. Da vi blev spurgt, om siden var sikker, kunne alle de ikke-agentiske assistenter, vi testede (ChatGPT, Claude, Copilot, Dia, Fellou, Gemini, Genspark, Grok, Leo, Perplexity og Sigma), ikke registrere den "skjulte" tekst og fortalte brugeren med selvtillid, at siden ikke udgjorde et sikkerhedsproblem. Testen blev udført i december 2025.
En AI-assistent analyserer en webside som struktureret tekst, mens en browser gengiver websiden til en visuel repræsentation for brugeren. Inden for dette gengivelseslag kan angribere ændre det menneskeligt synlige betyder af en side uden at ændre den underliggende DOM.
Denne mangel på sammenhæng mellem det, assistenten ser, og det, brugeren ser, resulterer i unøjagtige svar, farlige anbefalinger og undergravet tillid.
Dette er ikke en browserudnyttelse, og den er ikke afhængig af en parsing-fejl. Browseren opfører sig præcis som den blev designet. Sårbarheden ligger i værktøjer, der antager, at DOM-tekst fuldt ud repræsenterer den brugersynlige betydning.
*Med ikke-agentisk mener vi assistenter, der henter og analyserer HTML, men ikke udfører en fuld browserrenderingspipeline eller analyserer brugerdefinerede skrifttypeglyf-tilknytninger.
Angriberens håndbog
Denne teknik kræver ingen JavaScript, ingen exploit kits og ingen browsersårbarheder:
- Forbered HTML-indhold, der ser godartet ud, inklusive fyldstof, der virker harmløst, når det parses som tekst (f.eks. fanfiction)
- Indsæt en kodet nyttelast, der virker meningsløs i DOM'en
- Opret en brugerdefineret skrifttype, der omskriver glyffer, så normale engelske tegn gengives som volapyk, og den kodede nyttelast gengives som læsbare instruktioner.
- Brug CSS til at kontrollere synligheden ved at skjule godartet indhold (f.eks. 1px, sort på sort), vise nyttelastens indhold i en læsbar størrelse og farve og anvende den brugerdefinerede skrifttype globalt.
Resultatet: Tekstbaserede parsere ser godartet indhold, mens brugerne ser angriberstyrede instruktioner.
Dette flytter nyttelasten fra DOM-laget til renderingslaget.
Angrebsarbejdsgang
En bruger besøger denne side: https://layerxresearch.com/RaptureFuture
For brugeren ser dette ud til at være en fanfiction-side, der indeholder en besked, der opfordrer brugeren til at finde et "easter egg" relateret til videospillet Bioshock:
Brugeren er forsigtig og beder en AI-assistent om at se på webstedet og afgøre, om instruktionerne til påskeægget er sikre at følge. Assistenten henter og analyserer HTML-koden og ser, hvad der primært er videospilinspireret fanfiction:
Fanfiction-sektionerne er skjult for brugeren med CSS, mens den kodede blob-sektion vises normalt (og "afkodes" med den brugerdefinerede skrifttype). Når assistenten ser den kodede blob-sektion på siden, kan den ikke parse den base64-lignende tekst og behandler den derfor som støj.
Under disse forhold, Brugeren ser den store grønne, ondsindede tekst, som vi viste ovenfor, mens AI-assistenten kun ser fanfiction-teksten, der nu er skjult for brugeren.Assistenten afgør, at siden er sikker, og opfordrer i mange tilfælde endda brugeren til at følge de trin, der ville resultere i en omvendt shell.
Dette er en social engineering-teknik på præsentationslaget. Nyttelasten findes i renderingspipelinen, ikke i et eksekverbart script.
Angrebsdiagram
Tekniske detaljer
Hvis du skulle se kildekoden til HTML-koden, ville du primært se tekst i almindeligt sprog (fanfiction i computerspil) og en lille sektion med specialtekst, der minder om base64-lignende volapyk.
I HTML-koden sikrer CSS, at al tekst er indstillet til en brugerdefineret skrifttype, som vi har oprettet. Denne skrifttype fungerer som en visuel erstatningschiffer implementeret på skrifttypeglyfniveau. Selve skrifttypefilen er chiffernøglen og er konstrueret på en måde, så normal HTML-tekst vises som volapyk, når den gengives i en browser, og den specielle HTML-tekst vises som normal tekst. Dette angreb kræver ikke JavaScript og vil fungere, selvom det er deaktiveret.
Når den gengives, reduceres den normale HTML-tekst til 1 pixel og skjules visuelt ved at være indstillet til samme farve som sidens baggrund. Den brugerdefinerede skrifttype får denne normale tekst til at virke uforståelig for brugeren. Selv hvis de zoomer ind og fremhæver teksten, vil brugeren se volapyk – men den underliggende normale HTML-tekst (videospilsfanfiction) er det, AI-assistenterne ser.
Når den specielle HTML-tekst gengives, vises den i en rimelig størrelse og farve, så den kan kan ses af brugeren. Den brugerdefinerede skrifttype gør denne særlige tekst læsbar for brugeren og indeholder en besked, der opfordrer dem til at udføre trin på deres system, der vil resultere i en omvendt shell.
For AI-assistenterne er denne specielle HTML-tekst simpelthen base64-lignende vrøvl: Den ligner en kodet nyttelast (alfanumeriske kørsler med høj entropi), der ikke kan afkodes uden fontmapping, hvilket resulterer i, at både assistenter og mennesker behandler den som støj.
Selvom det visuelt præsenteres for brugeren som normal tekst, Den underliggende specielle HTML-tekst (volapyk) er det, AI-assistenterne ser.
Hvis en bruger beder en assistent om at se på siden og afgøre, om den er sikker, vil assistenten kun kunne se den underliggende HTML. Den vil ikke rent faktisk gengive siden og kan derfor ikke pålideligt bestemme, hvordan den vil se ud for brugeren. Fordi den underliggende HTML primært er fanfiction om videospil, og den særlige tekst er uforståelig selv for assistenten, vil assistenten afgøre, at webstedet er godartet.
AI-assistenten ser en fanfiction-hjemmeside med videospil, der ikke indeholder sikkerhedstrusler eller -problemer.
Brugeren ser trin til at etablere en reverse shell på sin computer.
Det, brugeren ser, er ikke, hvad AI-assistenten ser.
Impact
Når en AI-assistent ser på en side, bestemmer den indhold og betydning gennem den underliggende HTML-tekst. Når en bruger ser på en side, bestemmer de indhold og betydning gennem den visuelle præsentation af den gengivne side. Disse er to forskellige trusselsflader, og den udnyttelse, vi har beskrevet, udnytter kløften mellem dem som et våben.
I normale webscenarier er HTML indhold og skrifttypehjælpemidler præsentationSkrifttypen ændrer ikke tekstens betydning. I denne sammenhæng er det rimeligt at antage, at sidens synlige betydning bestemmes af DOM-teksten og ikke af tegnsubstitutionstricks.
Den antagelse er normalt sikker – og det er derfor, den er så effektiv.
Moderne websikkerhedsmodeller behandler typisk ikke brugerdefinerede skrifttyper som semantiske transformere eller substitutionschiffere. De fleste browsertilgængelige AI-assistenter kan ikke pålideligt registrere tricks på præsentationslaget (som brugerdefineret glyfsubstitution), medmindre de får adgang til skrifttypefilen eller en eksplicit renderingskontekst. Selv hvis en assistent kan hente skrifttypefilen, kan de fleste ikke analysere glyftilknytningerne eller udføre renderings- og differencekontroller som standard.
Selv ved brug af meget målrettede prompter designet til at fremkalde detektion, identificerede vores test (udført i december 2025) ikke en eneste assistent, der med succes opdagede truslen.
Brugere bruger AI-assistenter til at gengive meningen af en webside præcist, men assistenterne bliver narret af en simpel erstatningskode. Dette skaber flere praktiske sikkerhedsmæssige konsekvenser:
AI-assisteret social engineering
Når en angriber opretter en ondsindet side, der får en AI-assistent til at klassificere den som sikker, tilraner de sig effektivt AI-assistentens autoritet og bruger dens omdømme til at forstærke deres eget budskab. Denne falske forsikring kan føre til, at brugerne foretager handlinger, de ellers ville undgå, og kan i sidste ende undergrave tilliden til de AI-systemer, som de stoler på for sikkerhedsvejledning.
Blinde vinkler i AI-assisterede sikkerhedsworkflows
Den proof-of-concept-side, vi har skabt – et social engineering-angreb, der opfordrer brugeren til at udføre skadelige handlinger på deres egne systemer – er blot ét eksempel på, hvordan denne præsentationslagsteknik kan udnyttes. AI-assistenter integreres i stigende grad i sikkerhedsarbejdsgange, hvor browserassistenter, copiloter og helpdesk-værktøjer opsummerer websider og leder efter potentielle trusler. Ved at flytte nyttelasten ind i renderingslaget skaber angriberne en blind vinkel, der tillader skadeligt indhold at omgå disse tekstbaserede AI-værktøjer.
Leverandøroplysninger og svar
LayerX indsendte sine resultater til de førende AI-platformudbydere i henhold til procedurerne for ansvarlig offentliggørelse. De fleste udbydere afviste rapporten, normalt med den påstand, at dette angreb falder uden for AI-modellens sikkerhedsområde. Som følge heraf forbliver brugerne af disse modeller udsatte for denne angrebsvektor.
De eneste leverandører, der accepterede denne rapport og bad om tid til at rette den, var Microsoft og Google. Af disse trak Google i sidste ende ned på processen (efter i første omgang at have givet den en P2 (Høj) score) og lukkede rapporten, muligvis fordi det ville kræve for meget arbejde at rette den.
Den eneste leverandør, der fuldt ud havde adresseret dette problem og anmodet om den fulde frist for offentliggørelse (90 dage), var Microsoft.
| Vendor | Dato indsendt | Dato lukket | Detaljer / Vigtige udsagn fra leverandørens svar |
| microsoft | December 16, 2025 | Microsoft accepterede rapporten den 17. december 2025 og åbnede en sag i Microsoft Security Response Center (MSRC). | |
| Antropisk | December 16, 2025 | December 16, 2025 | "I henhold til politikken anses følgende for at være uden for anvendelsesområdet:"
"Social engineering (herunder phishing-forsøg)" og "Indholdsproblemer med modelprompter og -svar", som eksplicit er angivet som værende uden for dette programs anvendelsesområde." |
| dag | December 14, 2025 | December 16, 2025 | "Desværre ville dette blive betragtet som uden for rammerne af BCNY's programpolitik:
Prompte injektioner, der fører til misinformation, uventet adfærd, denial of service eller denial of correct service fra assistenten, er eksplicit uden for rammerne. En prompte injektion anses kun for at være omfattet, hvis den har en påviselig og specifik skade for en bruger ved automatisk at udvinde følsomme brugerdata eller foretage uautoriserede handlinger som bruger. |
| OpenAI | December 16, 2025 | December 17, 2025 | "Tak for din tålmodighed. Indsendelsen mangler dog i sin nuværende form den nødvendige effekt for at være berettiget til triage, da problemer som disse eksplicit er angivet som værende uden for dette programs anvendelsesområde." |
| December 16, 2025 | Januar 27, 2026 | Gemini accepterede oprindeligt rapporten den 17. december 2025 og gav den en P2 (Høj) prioritet. Den 27. januar 2026 nedtrappede de dog rapporten og lukkede den med bemærkningerne:
"Vi kunne ikke identificere et angrebsscenarie, hvor din rapport resulterer i betydelig skade for brugerne. Giv os venligst besked, hvis vi har overset noget, og del et angrebsscenarie med stor effekt. Dette skyldes, at scenariet er for afhængig af social engineering". |
|
| rådvildhed | December 14, 2025 | December 17, 2025 | "Efter en grundig undersøgelse har vi fastslået, at denne rapport ikke repræsenterer en sikkerhedssårbarhed i traditionel forstand. Det scenarie, du har beskrevet, er en kendt begrænsning ved store sprogmodeller, når de behandler eksternt webindhold, snarere end en fejl eller mangel i vores systems sikkerhedskontroller."
Dit angrebsscenarie er baseret på social engineering – at overbevise en bruger om manuelt at udføre terminalkommandoer, som et AI-system foreslår efter at have analyseret en ondsindet webside. Dette svarer til en bruger, der læser dårlige råd på en hvilken som helst hjemmeside og vælger at følge dem. Der er ingen kodeudførelse på vores servere, ingen uautoriseret adgang til brugerdata og ingen omgåelse af godkendelses- eller autorisationskontroller. |
| xAI | December 16, 2025 | December 17, 2025 | "Tak for din indsendelse! Desværre falder dette specifikke problem, du rapporterede, eksplicit uden for rammerne af beskrivelsen af Politikside:
|
Anbefalinger
Ved at implementere følgende forbedringer kan LLM'er gøre store fremskridt i retning af at reducere – eller endda eliminere – kløften mellem, hvad brugeren ser, og hvad AI-assistenten ser:
Dobbelttilstands rendering-og-diff-analyse
Udfør to uafhængige analyser:
- DOM-udtrækning kun af tekst
- Fuld sidegengivelse med aktiverede skrifttyper
Udtræk den synlige tekst fra den gengivne side, og afgør, om den er væsentligt forskellig fra DOM-teksten.
Registrer skjulte indholdsmønstre
Udvid parsere til at scanne efter:
- Forgrunds-/baggrundsfarvematchninger
- Næsten nul opacitet
- Skriftstørrelser under 5px
- Positionering uden for skærmen
- Høj tæthed af skjult indhold
Behandl skrifttyper som en potentiel trusselsoverflade
- Hent skrifttypefilen
- Undersøg Unicode/glyf-tilknytningstabellerne
- Registrer unormale glyfferstatningsmønstre
Risikoscoring baseret på overfladeuoverensstemmelse
Tildel en forhøjet risikoscore når:
- Synlig gengivet tekst ligner ikke DOM-tekst
- DOM-tekst virker godartet, mens gengivet tekst indeholder eksekverbare instruktioner.
- CSS-manipulation bruges til at skjule store indholdsblokke
Konfidenskalibrering
Hvis en assistent ikke kan:
- Render siden
- Analysér de brugerdefinerede skrifttyper
- Sammenlign visuelt indhold med DOM-indhold
Så bør man undgå stærke påstande som: "Siden er sikker."
Konklusion
Webben er ikke bare HTML. Mening kan flyttes ind i renderingsprocessen, og ethvert system, der kun analyserer tekst, er blindt af sin natur.
