CSS-ul din e-mail îți fură parola: cercetarea de la Black Hat
Gareth Heyes de la PortSwigger a prezentat la Black Hat USA 2026 o cercetare care arată că doar CSS-ul dintr-un e-mail — fără JavaScript — poate ieși din limitele mesajului și manipula interfața clientului de webmail. Au fost demonstrate lanțuri împotriva Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail și AOL Mail.
Rezultatul nu e o defigurare cosmetică. Sunt lanțuri demonstrate care fură parole tastate, preiau conturi terțe și scot tokenuri afară.
De ce CSS-ul e o suprafață de atac
Fiecare client de webmail permite un anumit CSS în e-mailuri, pentru că altfel newsletterele ar arăta ca niște documente text din 1995. Sanitizarea se concentrează în mod tradițional pe JavaScript și pe etichetele periculoase.
Premisa implicită e că stilul e inofensiv: cel mai rău, un e-mail urât. Cercetarea demontează exact această premisă.
CSS-ul modern poate selecta elemente pe baza stării lor, poate declanșa cereri de rețea prin imagini de fundal și poate ascunde sau dezvălui conținut condiționat. Cu suficientă atenție, aceste trei capacități combinate produc un keylogger — fără o linie de JavaScript.
Lanțurile demonstrate, pe furnizori
Fiecare lanț depinde de combinația dintre client și browser. Nu e o singură vulnerabilitate, ci aceeași idee aplicată la implementări diferite — motiv pentru care a funcționat aproape peste tot.
- ▸Outlook cu Firefox: label-jacking și transformarea atributelor personalizate produc un ecran fals de autentificare Microsoft care capturează parola tastată
- ▸Yahoo și AOL: o cursă la lipire exploatează intervalul scurt în care CSS-ul e reținut înainte de sanitizare, expunând un token de conectare prin e-mail suficient pentru preluarea contului
- ▸Gmail: o ocolire prin image-set(), combinată cu injecție indirectă de prompt, exfiltrează un token Slack atunci când un asistent AI citește e-mailul prin conectorul Gmail
- ▸Fastmail: pseudo-elemente CSS și jocuri de opacitate ascund instrucțiuni de ochiul uman, dar le lasă lizibile pentru un browser cu AI
Tehnica centrală: label-jacking
În HTML, un element de tip etichetă poate fi legat de un control aflat în altă parte a paginii. Dacă utilizatorul dă click pe etichetă, click-ul ajunge la acel control.
Atacul folosește această legătură pentru a redirecționa click-uri către elemente ale interfeței clientului de e-mail, aflate în afara mesajului. Utilizatorul crede că apasă un buton din e-mail; în realitate acționează ceva din aplicație.
Aceeași familie de trucuri permite deghizarea unui element de selecție ca un câmp de parolă. Nimic din ce vede utilizatorul nu contrazice așteptarea, pentru că tot ce vede el este stilul, iar stilul e sub controlul atacatorului.
Partea nouă: asistenții AI care îți citesc e-mailul
Cea mai interesantă schimbare față de atacurile clasice pe e-mail e că victima nu mai trebuie să fie neapărat un om.
CSS-ul poate ascunde text de ochiul uman păstrându-l în document — opacitate zero, poziționare în afara ecranului, pseudo-elemente. Un om nu vede nimic. Un model care primește conținutul paginii îl citește integral, inclusiv instrucțiunile plantate acolo pentru el.
Asta transformă o cutie poștală într-un canal de intrare pentru injecție indirectă de prompt. Dacă asistentul are și acces la alte unelte — un conector către spațiul de lucru, un token de integrare — instrucțiunea plantată poate cere exfiltrarea lor.
Din perspectiva apărării, aici se schimbă modelul de amenințare: nu mai e suficient ca interfața să fie sigură pentru utilizatorul uman.
Ce s-a reparat și ce nu
Fastmail a rezolvat două erori de mutație CSS. Ocolirea prin proxy la Proton Mail nu a mai funcționat la retestare.
La momentul publicării cercetării, pe 6 august 2026, label-jacking-ul pe Outlook și ocolirea prin image-set() la Gmail încă funcționau.
Nu au fost alocate numere CVE pentru aceste probleme. Sunt defecte în servicii găzduite, reparabile de furnizor fără ca tu să instalezi ceva — ceea ce e o veste bună pentru remediere, dar înseamnă și că nu apar în niciun flux de vulnerabilități pe care l-ai putea urmări.
Ce poți face, realist
- ▸Nu poți repara clientul de webmail al furnizorului — dar poți alege unde citești e-mailul: clienții desktop nativi nu au aceeași suprafață de atac ca interfața web
- ▸Tratează orice ecran de autentificare care apare după un click într-un e-mail ca fiind fals, indiferent cât de corect arată; deschide aplicația separat, dintr-un semn de carte
- ▸Redu dependența de parole cu chei FIDO2 sau passkeys; pentru ca o parolă capturată să nu rămână o cale de acces, elimină fallback-ul pe parolă sau impune MFA rezistent la phishing
- ▸Inventariază ce asistenți AI au acces la cutiile poștale ale organizației și cu ce alte unelte sunt conectați — acolo e lanțul care doare
- ▸Revizuiește tokenurile de integrare accesibile din contextul acelor asistenți; aplică principiul privilegiului minim, nu al comodității
- ▸Instruiește echipa că un e-mail poate conține instrucțiuni invizibile adresate uneltelor, nu oamenilor
Ce nu e confirmat
Nu există dovezi publice că aceste tehnici ar fi fost folosite în atacuri reale. Sunt lanțuri demonstrate de un cercetător, cu dovezi de concept, nu campanii observate.
Nu s-a publicat un număr de utilizatori expuși și nici o cronologie a corectărilor din partea furnizorilor care nu au reparat încă.
Distincția merită păstrată: „funcționează într-o demonstrație" nu e același lucru cu „se exploatează acum". Dar pentru tehnici publicate, cu dovezi de concept disponibile, distanța dintre cele două a fost istoric scurtă.
Urmărește ce rulezi, nu doar ce citești
Pentru vulnerabilitățile din software-ul tău, MONITOR AWARELY agregă NVD, CISA KEV, EUVD și GitHub și te alertează pe versiunile din inventarul tău de active.