At Black Hat USA 2026 lieten onderzoekers zien dat Cascading Style Sheets (CSS) kunnen worden ingezet als wapen om AI-gestuurde e-mailagenten inhoud te laten lezen die onzichtbaar is voor menselijke gebruikers. De techniek omzeilde Outlook, Gmail, Yahoo en Proton, waardoor de agenten wachtwoorden, authenticatietokens en IP-adressen konden exfiltreren.

Waarom CSS belangrijk is voor e-mailbeveiliging

Al jaren verdedigen webmailproviders zich tegen kwaadaardige HTML door scripts te verwijderen, iframes te sandboxen en de mogelijkheden van een bericht te beperken. Deze maatregelen stoppen klassieke aanvallen die vertrouwen op JavaScript of ingebedde objecten. CSS wordt echter altijd als onschuldige presentatiecode beschouwd. De geavanceerde selectors — zoals attribuutselectors, container queries en dergelijke — laten een pagina reageren op de DOM-structuur zonder dat daar scripting voor nodig is.

De Black Hat-demo's bewezen dat deze "onschuldige" selectors een zijkanaal voor datalekken kunnen worden. Door stijlgeregels te maken die alleen van toepassing zijn wanneer bepaalde verborgen elementen aanwezig zijn, maken aanvallers tekst onzichtbaar voor de gebruiker, maar blijft deze wel aanwezig in de gerenderde pagina die een AI-agent analyseert.

Hoe de aanvallen werken

Een proof-of-concept verstuurde een e-mail die er voor de ontvanger gewoon uitzag. Verborgen in de e-mail zaten CSS-regels die de kleur van specifieke tekst aanpasten aan de achtergrond, waardoor de tekst effectief werd gecamoufleerd. Een mens ziet de tekst nooit, maar een AI-agent die de DOM of de toegankelijkheidsboom (accessibility tree) extraheert, past het visuele filter niet toe. Toen de agent de e-mail verwerkte, las hij de gecamoufleerde tekst en verzond deze via een URL-fragment — een deel van een webadres dat browsers normaal gesproken negeren bij het laden van een pagina.

Een andere variant maakte gebruik van indirecte prompt injection. De e-mail bevatte een verborgen Slack-token. De CSS maakte het token onzichtbaar voor de gebruiker, maar hield het wel in de markup. De AI-agent, getraind om instructies in de e-mail op te volgen, interpreteerde het token als een commando en stuurde het terug naar de server van de aanvaller.

Beide aanvallen slaagden bij dezelfde reeks populaire providers, wat aantoont dat de kwetsbaarheid voortkomt uit de fundamentele manier waarop CSS wordt gerenderd, en niet uit de implementatie van een enkel platform.

AI-agenten versus menselijke lezers

Mensen negeren instinctief tekst die ze niet kunnen zien; we vertrouwen op de visuele lay-out om ons te vertellen wat belangrijk is. AI-agenten werken daarentegen op de ruwe DOM of een toegankelijkheidsboom die elk element registreert, ongeacht de visuele staat. Wanneer een AI een pagina leest, past deze de regel "als ik het niet kan zien, negeer ik het" niet toe. Die discrepantie creëert een blinde vlek: sanitization-pipelines die zijn gebouwd voor menselijke consumptie, garanderen niet langer veiligheid voor geautomatiseerde lezers.

Het probleem is geen nieuwe AI-fout. Het is een oude webfout — het vermogen van CSS om de lay-out te beïnvloeden zonder code — die een nieuw type consument ontmoet. Elke dienst die e-mailinhoud overdraagt aan een AI-gestuurde assistent, samenvatter of classifier, loopt nu het risico dat de assistent handelt op basis van gegevens die een mens nooit ziet.

Wie is verantwoordelijk voor de verdediging?

De aanvallen roepen een vraag op over de taakverdeling. Webmailproviders verwijderen al HTML om menselijke gebruikers te beschermen; browsers handhaven al dezelfde regels voor het renderen. Toch houdt geen van deze lagen rekening met een downstream AI die dezelfde markup analyseert. Moet de e-maildienst diepere CSS-sanitization toevoegen? Moeten browsers een vlag introduceren die elementen markeert als "onzichtbaar voor scripts"? Of moeten AI-leveranciers filters bouwen die verborgen nodes verwijderen voordat ze worden verwerkt?

Securityteams die AI-gestuurde e-mailtools bouwen, krijgen het advies om de volledige rendering-pipeline te auditen, en niet alleen de HTML die de inbox bereikt. Dat betekent het controleren van de DOM nadat de CSS is toegepast, het inspecteren van de toegankelijkheidsboom en het expliciet verwijderen of markeren van alle inhoud die niet zichtbaar is voor het menselijk oog.

Waar u op moet letten

  • Testen door leveranciers – Van AI-leveranciers wordt verwacht dat ze real-world CSS-aanvalvectoren opnemen in hun testsuites. Het web heeft dertig jaar aan onderzoek naar kwetsbaarheden; AI-agenten hebben er slechts enkele.

Als een AI-assistent kan worden misleid om inloggegevens te lekken door simpelweg tekst met CSS te verbergen, dan is het beveiligingsmodel dat de huidige inboxen beschermt niet langer voldoende. Ontwikkelaars, providers en toezichthouders moeten de gerenderde pagina — en niet alleen de ruwe HTML — beschouwen als de beveiligingsgrens voor elke geautomatiseerde consument. Het probleem met verborgen tekst herinnert ons eraan dat een technologie die ooit werd weggezet als "alleen styling", een kanaal voor datadiefstal kan worden. De volgende golf van verdedigingsmechanismen zal CSS moeten herkennen als een potentieel aanvalsoppervlak, en niet alleen als een visueel hulpmiddel.