Wprowadzenie do problemu / definicja
Badacze bezpieczeństwa opisali nową technikę ataku, która wykorzystuje niestandardowe czcionki i reguły CSS do rozdzielenia tego, co widzi użytkownik w przeglądarce, od tego, co analizuje asystent AI. W praktyce oznacza to, iż strona może wyglądać dla człowieka jak zestaw czytelnych instrukcji, podczas gdy narzędzie AI oceniające bezpieczeństwo widzi w kodzie HTML jedynie nieszkodliwą treść.
To istotny problem dla rosnącej klasy rozwiązań opartych na AI, które analizują strony internetowe bez pełnego renderowania ich warstwy wizualnej. jeżeli system interpretuje wyłącznie DOM lub tekst źródłowy, może przeoczyć manipulację ukrytą w sposobie prezentacji treści.
W skrócie
Opisana metoda polega na ukryciu faktycznego przekazu w warstwie renderowania przeglądarki. Atakujący przygotowuje stronę zawierającą pozornie bezpieczny tekst w HTML, a następnie wykorzystuje własną mapę glifów w czcionce, aby przekształcić inny ciąg znaków w czytelne dla użytkownika polecenie.
Dodatkowo CSS służy do ukrycia nieszkodliwej treści i wyeksponowania złośliwego komunikatu. W efekcie asystent AI może błędnie uznać stronę za bezpieczną i potwierdzić użytkownikowi, iż pokazane instrukcje nie stanowią zagrożenia.
Kontekst / historia
Problem został nagłośniony w marcu 2026 roku przez badaczy zajmujących się bezpieczeństwem przeglądarek i narzędzi AI. Według opisu testy przeprowadzono wcześniej, w grudniu 2025 roku, na wielu popularnych asystentach internetowych.
Scenariusz ataku nie opiera się na exploicie przeglądarki ani błędzie parsera HTML. Wykorzystuje natomiast fundamentalną różnicę między analizą tekstowej struktury dokumentu a końcowym obrazem renderowanym użytkownikowi.
To istotny kontekst, ponieważ wiele współczesnych copilotów, rozszerzeń przeglądarkowych i asystentów bezpieczeństwa działa na poziomie pobierania i interpretacji DOM lub tekstu strony. o ile narzędzie nie analizuje również czcionek, stylów oraz faktycznego wyniku renderowania, może nie wykryć manipulacji semantycznej wykonanej wyłącznie w warstwie prezentacji.
Analiza techniczna
Sedno techniki polega na użyciu niestandardowej czcionki jako swoistego szyfru podstawieniowego. W standardowym modelu bezpieczeństwa font odpowiada za wygląd tekstu, ale nie za jego znaczenie. W tym przypadku znaczenie zostaje jednak przeniesione właśnie do mapowania glifów.
Przebieg ataku można uprościć do kilku kroków:
- Napastnik tworzy stronę z pozornie nieszkodliwą treścią w HTML, na przykład opisem gry, tekstem fanowskim lub neutralnym komentarzem.
- Do dokumentu dodawany jest drugi ciąg znaków, który dla parsera wygląda jak losowy lub zakodowany tekst.
- Ładowana jest niestandardowa czcionka, w której glify są zmapowane tak, aby bełkotliwy ciąg znaków wyświetlał się użytkownikowi jako czytelne, konkretne polecenie.
- Reguły CSS ukrywają neutralną treść, na przykład przez minimalny rozmiar czcionki, zerową widoczność albo zlanie koloru tekstu z tłem.
- Widoczny dla użytkownika pozostaje tylko komunikat o charakterze instrukcji operacyjnej, na przykład zachęta do uruchomienia polecenia w terminalu.
Kluczowe jest to, iż wiele narzędzi AI analizuje stronę jako tekst strukturalny i nie uruchamia pełnego pipeline’u renderowania. Odczytują więc treść DOM, ale nie weryfikują, jak czcionka i style zmieniają odbiór treści na ekranie. W takim modelu złośliwy przekaz istnieje wyłącznie w warstwie wizualnej, a nie w prostym odczycie HTML.
Badacze wskazali również, iż technika nie wymaga JavaScript, exploit kitów ani podatności w silniku przeglądarki. To zwiększa jej praktyczność, ponieważ wiele klasycznych mechanizmów detekcji skupia się na skryptach, aktywnej zawartości lub podejrzanych żądaniach sieciowych, a nie na semantyce renderowanej przez fonty i CSS.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem jest możliwość przejęcia zaufania użytkownika do asystenta AI. o ile użytkownik poprosi narzędzie o ocenę bezpieczeństwa instrukcji widocznych na stronie, a system odpowie, iż są one nieszkodliwe, AI staje się nieświadomym wzmacniaczem inżynierii społecznej.
Ryzyko obejmuje kilka obszarów:
- Fałszywe zapewnienie o bezpieczeństwie i błędne uspokojenie użytkownika.
- Nakłonienie do wykonania niebezpiecznych komend, w tym poleceń prowadzących do uruchomienia reverse shella.
- Luki w procesach SOC i helpdesk, jeżeli zespoły korzystają z AI do oceny artefaktów webowych.
- Nową powierzchnię ataku dla rozwiązań AI security, obejmującą fonty i warstwę prezentacji.
- Erozję zaufania do narzędzi AI, które nie rozpoznają różnicy między HTML a finalnym obrazem strony.
Z perspektywy operacyjnej jest to atak z pogranicza social engineeringu i obejścia mechanizmów AI-assisted browsing. Nie daje automatycznej kompromitacji systemu, ale może skutecznie doprowadzić użytkownika do samodzielnego wykonania szkodliwej akcji.
Rekomendacje
Organizacje korzystające z asystentów AI do oceny stron internetowych powinny założyć, iż analiza samego DOM nie jest wystarczająca. W praktyce warto wdrożyć wielowarstwowe podejście obejmujące kontrolę renderowania, analizę stylów oraz procedury operacyjne ograniczające ryzyko błędnej interpretacji.
- Nie traktować odpowiedzi AI jako ostatecznej decyzji bezpieczeństwa.
- Wdrożyć zasadę, aby nie uruchamiać poleceń z internetu bez niezależnej weryfikacji.
- Rozszerzyć analizę o renderowanie wizualne i porównanie DOM z faktycznym widokiem strony.
- Monitorować użycie niestandardowych fontów oraz podejrzanych reguł CSS, takich jak bardzo małe czcionki, niska przezroczystość czy kolor tekstu zbliżony do tła.
- Dodać detekcję semantycznych rozbieżności między treścią źródłową a renderem, na przykład przez OCR zrzutów ekranu lub render-and-diff.
- Prowadzić szkolenia użytkowników i administratorów z zakresu ograniczeń narzędzi AI.
- Stosować zasadę least privilege oraz środowiska testowe lub sandboxy do weryfikacji ryzykownych instrukcji.
Podsumowanie
Nowa technika ukrywania poleceń dzięki renderowania czcionek pokazuje, iż bezpieczeństwo systemów AI zależy nie tylko od jakości modelu, ale również od tego, jaką warstwę danych narzędzie rzeczywiście analizuje. jeżeli asystent widzi wyłącznie HTML, a użytkownik widzi wynik przekształcony przez CSS i niestandardowe glify, powstaje groźna luka semantyczna.
To praktyczny przykład, iż warstwa prezentacji może stać się pełnoprawnym wektorem ataku na procesy oparte na AI. Dla zespołów bezpieczeństwa oznacza to konieczność rozszerzenia detekcji poza sam DOM i ostrożniejszego traktowania rekomendacji generowanych przez asystentów internetowych.
