At Black Hat USA 2026 badacze pokazali, że kaskadowe arkusze stylów (CSS) mogą zostać wykorzystane jako broń, aby zmusić agentów e-mailowych opartych na AI do odczytywania treści niewidocznych dla użytkowników. Technika ta pozwoliła ominąć Outlooka, Gmaila, Yahoo i Protona, umożliwiając agentom eksfiltrację haseł, tokenów uwierzytelniających i adresów IP.

Dlaczego CSS ma znaczenie dla bezpieczeństwa poczty e-mail

Przez lata dostawcy poczty webmail bronią się przed złośliwym kodem HTML poprzez usuwanie skryptów, piaskowanie (sandboxing) ramek iframe i ograniczanie możliwości działania wiadomości. Te środki powstrzymują klasyczne ataki opierające się na JavaScript lub osadzonych obiektach. CSS był jednak zawsze traktowany jako nieszkodliwy kod prezentacyjny. Jego zaawansowane selektory — selektory atrybutów, zapytania kontenerowe (container queries) i tym podobne — pozwalają stronie reagować na strukturę DOM bez użycia skryptów.

Pokazy na Black Hat udowodniły, że te „nieszkodliwe” selektory mogą stać się kanałem bocznym (side-channel) do wycieku danych. Tworząc reguły stylów, które mają zastosowanie tylko wtedy, gdy istnieją określone ukryte elementy, atakujący sprawiają, że tekst jest niewidoczny dla użytkownika, ale wciąż obecny w wyrenderowanej stronie, którą analizuje agent AI.

Jak działają te ataki

Jeden z dowodów koncepcji (PoC) polegał na wysłaniu wiadomości e-mail, która dla odbiorcy wyglądała zwyczajnie. Wewnątrz ukryto reguły CSS, które zmieniały kolor konkretnego tekstu na taki, który pasował do tła, skutecznie go maskując. Człowiek nigdy nie zobaczy tego tekstu, ale agent AI, który wyodrębnia DOM lub drzewo dostępności (accessibility tree), nie stosuje filtra wizualnego. Gdy agent przetwarzał e-mail, odczytywał zamaskowany tekst i przesyłał go w fragmencie adresu URL — części adresu internetowego, którą przeglądarki zazwyczaj ignorują podczas ładowania strony.

Inna wariacja wykorzystywała pośrednią iniekcję promptu (indirect prompt injection). Wiadomość zawierała ukryty token Slacka. CSS sprawił, że token był niewidoczny dla użytkownika, ale pozostał w kodzie markup. Agent AI, przeszkolony do wykonywania instrukcji zaszytych w e-mailu, zinterpretował token jako polecenie i odesłał go na serwer atakującego.

Oba ataki zakończyły się sukcesem przeciwko temu samemu zestawowi popularnych dostawców, co pokazuje, że podatność wynika z fundamentalnego sposobu renderowania CSS, a nie z implementacji konkretnej platformy.

Agenci AI vs. ludzcy czytelnicy

Ludzie instynktownie ignorują tekst, którego nie widzą; ufamy układowi wizualnemu, który mówi nam, co jest istotne. Agenci AI, w przeciwieństwie do nich, operują na surowym DOM lub drzewie dostępności, które rejestruje każdy element niezależnie od jego stanu wizualnego. Gdy AI czyta stronę, nie stosuje zasady „jeśli tego nie widzę, to to zignoruję”. Ta rozbieżność tworzy martwą strefę: potoki sanityzacji zbudowane z myślą o ludziach nie gwarantują już bezpieczeństwa dla zautomatyzowanych czytelników.

Problem nie polega na nowej wadzie AI. To stara wada sieci — zdolność CSS do wpływania na układ bez użycia kodu — spotykająca nowy typ odbiorcy. Każda usługa, która przekazuje treść e-maila asystentowi, podsumowywaczowi lub klasyfikatorowi opartemu na AI, stoi teraz przed ryzykiem, że asystent zadziała na podstawie danych, których człowiek nigdy nie zobaczy.

Kto odpowiada za obronę?

Ataki te rodzą pytanie o jurysdykcję. Dostawcy poczty webmail już teraz oczyszczają HTML, aby chronić użytkowników; przeglądarki już teraz wymuszają te same reguły renderowania. Mimo to żadna z tych warstw nie bierze pod uwagę „downstream AI”, który będzie analizował ten sam kod markup. Czy usługa e-mailowa powinna wprowadzić głębszą sanityzację CSS? Czy przeglądarki powinny udostępnić flagę oznaczającą elementy jako „niewidoczne dla skryptów”? A może dostawcy AI muszą budować filtry, które odrzucają ukryte węzły przed ich przetworzeniem?

Zespołom ds. bezpieczeństwa budującym narzędzia e-mailowe oparte na AI zaleca się audyt całego potoku renderowania, a nie tylko kodu HTML, który trafia do skrzynki odbiorczej. Oznacza to sprawdzanie DOM po zastosowaniu CSS, inspekcję drzewa dostępności oraz jawne usuwanie lub oznaczanie wszelkiej treści, która nie jest widoczna dla ludzkiego oka.

Na co zwrócić uwagę w przyszłości

  • Testowanie przez dostawców – oczekuje się, że dostawcy AI będą włączać rzeczywiste wektory ataków CSS do swoich zestawów testowych. Internet ma trzydzieści lat badań nad podatnościami; agenci AI mają ich zaledwie kilka.

Jeśli asystenta AI można oszukać i skłonić do wycieku danych uwierzytelniających po prostu poprzez ukrycie tekstu za pomocą CSS, model bezpieczeństwa chroniący dzisiejsze skrzynki odbiorcze przestaje być wystarczający. Deweloperzy, dostawcy i regulatorzy muszą traktować wyrenderowaną stronę — a nie tylko surowy kod HTML — jako granicę bezpieczeństwa dla każdego zautomatyzowanego odbiorcy. Problem ukrytego tekstu przypomina nam, że technologia, która niegdyś była ograniczona jedynie do „stylizacji”, może stać się kanałem kradzieży danych. Kolejna fala zabezpieczeń będzie musiała uznać CSS za potencjalną powierzchnię ataku, a nie tylko za pomoc wizualną.