Brevo: cum a ajuns un script terț pe 100.000 de site-uri

Ce s-a întâmplat, în ordinea în care s-a întâmplat

Cheia API Cloudflare a fost folosită prima dată abuziv la sfârșitul lunii august 2026. Pe 14 septembrie, atacatorii au folosit-o pentru a desfășura un Cloudflare Worker care injecta cod în brevo.com, în sibforms.com și în fișierele JavaScript pe care clienții le încarcă în paginile lor.

Sansec a măsurat fereastra exact: Brevo a servit malware între 16:05:18 și 20:12:53 UTC pe 14 septembrie. Cronologia proprie a Brevo indică intervalul 16:07–20:30 UTC. Cele două nu coincid perfect, ceea ce este normal când o parte măsoară din exterior, iar cealaltă din propriile sisteme; ambele descriu aproximativ aceleași patru ore și jumătate.

Fișierele afectate includ cdn.brevo.com/js/sdk-loader.js și cdn.brevo.com/js/brevo-conversations.js, iar codul injectat era adus de pe subdomenii cdn ale sendibt1.com. Le enumerăm ca să poți căuta în propriul markup și în propriile loguri, nu ca indicatori de blocat: subdomeniile malițioase au încetat să rezolve pe 15 septembrie, conform Sansec.

Brevo a revocat cheia compromisă și credențialele create cu ea, a scos credențiala din codul sursă, a șters numele de gazdă controlate de atacatori și și-a golit cache-urile de edge. Ultimul pas contează mai mult decât pare: un fișier malițios rămas în cache la marginea rețelei supraviețuiește corecturii de la origine.

• ▸Sansec — analiza atacului supply chain prin Brevo
• ▸BleepingComputer — declarația Brevo și cronologia
• ▸SecurityWeek — relatare independentă

Două comportamente, în funcție de cine deschidea pagina

Scriptul injectat se ramifica în funcție de vizitator. Pentru un vizitator obișnuit afișa un ecran fals de tip „Cloudflare, verify you are human”, care îi cerea să lipească și să ruleze o comandă pe propriul calculator. Este tehnica cunoscută drept ClickFix: nu exploatează browserul, ci convinge omul să execute singur comanda.

Pentru un vizitator autentificat ca administrator într-un site WordPress care încorpora widgetul, scriptul încerca altceva: să instaleze și să ruleze un plugin. Conform relatărilor, pluginul se numea „Web Media Optimizer”, încerca să descarce o ușă din spate de pe domenii externe, se ascundea din lista de pluginuri, crea acces persistent și conținea o cheie de autentificare codificată care ocolea verificarea parolei.

Această a doua ramură este cea care lasă urme durabile. Un vizitator păcălit de ClickFix are o problemă pe stația lui. Un administrator care era logat în momentul vizitei poate avea o problemă în site, care rămâne și după ce scripturile Brevo au redevenit curate.

Ce nu s-a confirmat: Brevo a recunoscut atacul, dar nu a raportat compromiteri reușite ale endpointurilor, iar Sansec a precizat că nu a putut recupera arhiva malware. Nu există un număr public de site-uri în care pluginul chiar a fost instalat.

• ▸Sansec — comportamentul codului injectat
• ▸BleepingComputer — detaliile pluginului WordPress

De ce nu l-ar fi văzut scannerul tău

Atacul a trăit la marginea rețelei, într-un Worker Cloudflare care rescria răspunsuri. Nu a existat un fișier modificat pe serverul tău, nici o dependență nouă în build-ul tău, nici o versiune schimbată în lockfile. Dacă instrumentarea ta se uită la integritatea fișierelor de pe origine sau la modificări în depozitul de cod, nu avea unde să vadă nimic.

Nici verificarea manuală nu ar fi ajutat prea mult: fereastra a fost de circa patru ore, iar conținutul servit depindea de cine deschidea pagina. Un administrator care a testat site-ul la ora nepotrivită ar fi văzut o pagină perfect normală.

Ce ar fi ajutat sunt controale pe care le decizi înainte. Subresource Integrity leagă un fișier extern de un hash cunoscut, dar nu se potrivește cu un script pe care furnizorul îl actualizează frecvent, pentru că orice actualizare legitimă ar rupe pagina. O politică de securitate a conținutului nu ar fi oprit un script servit de pe exact domeniul pe care l-ai permis, dar ar fi putut opri încărcarea ulterioară de pe domenii neașteptate, dacă lista ta de surse permise era strictă. Merită spus onest: niciunul dintre aceste controale nu este o garanție, iar costul lor operațional este real.

Concluzia practică este mai puțin tehnică: fiecare script terț pe care îl încarci este cod care rulează în browserul vizitatorului tău, cu drepturile paginii tale, la discreția altcuiva. Acesta este un activ, nu o linie de configurare de marketing.

• ▸Sansec — atacul a fost servit prin infrastructura de livrare

Ce verifici acum, dacă folosești sau ai folosit Brevo

• ▸Caută în markup-ul site-urilor tale numele fișierelor afectate, sdk-loader.js și brevo-conversations.js de pe cdn.brevo.com, plus orice widget de formular sau de conversații. Include site-urile de campanie și microsite-urile pe care nimeni nu le mai revizuiește.
• ▸Pentru site-urile WordPress, caută în loguri încărcări sau activări de pluginuri din 14 septembrie 2026 și verifică lista de pluginuri instalate, inclusiv pe disc, nu doar în interfață: pluginul raportat se ascundea din listare.
• ▸Verifică dacă vreun administrator a fost autentificat și a deschis o pagină a site-ului în fereastra raportată. Dacă da, tratează contul și site-ul ca pe o ipoteză de investigat, nu ca pe un caz închis.
• ▸Rotește parolele de administrator și, dacă ai indicii de instalare, tratează situația ca incident, nu ca pe o curățare de fișiere.
• ▸Pentru utilizatorii care au văzut ecranul fals de verificare și au rulat comanda, recomandarea Sansec este o scanare antivirus urgentă pe stația respectivă. Aceștia nu sunt neapărat angajații tăi, ci vizitatorii site-ului tău.
• ▸Reține retenția logurilor disponibilă. Fereastra este 14 septembrie, iar dacă logurile tale de acces se păstrează șapte zile, capacitatea ta de a răspunde la întrebare dispare rapid. Notează explicit cât ai putut căuta.

Cauza rădăcină nu este Brevo

Elementul care a făcut posibil acest atac este descris chiar de Brevo: o cheie API cu permisiuni complete pe cont, de lungă durată, scrisă direct în codul sursă. Fiecare dintre cei trei termeni contează separat. Permisiuni complete înseamnă că a permis crearea de Workers și de înregistrări DNS, adică lucruri care nu au legătură cu funcția aplicației. De lungă durată înseamnă că nu expira. În codul sursă înseamnă că oricine a avut acces la cod a avut acces la ea, iar rotația nu era o operațiune de rutină, ci o schimbare de cod.

Este exact combinația pe care majoritatea organizațiilor o are undeva. Întrebarea utilă după această știre nu este dacă folosești Brevo, ci câte chei cu permisiuni largi și fără expirare există în depozitele tale, cine le-ar observa dacă ar fi folosite din altă parte și cât ar dura o rotație dacă ar trebui făcută azi.

Merită menționat separat, ca să nu se amestece: pe 10 septembrie Brevo a comunicat un incident diferit, legat de modul de gestionare a SSO prin SAML, prin care au fost accesate 138 de conturi, s-au trimis phishinguri din șase conturi și s-au exportat contacte din 43. Trezor, al cărui cont a fost printre cele atinse, a raportat pe 11 septembrie că phishingul a ajuns la 347.000 de adrese de email de utilizatori și că cel puțin 2.500 au fost compromise. Acele cifre aparțin incidentului SSO, nu injectării de scripturi din 14 septembrie.

• ▸BleepingComputer — cheia API hardcodată, în declarația Brevo
• ▸SecurityWeek — incidentul SSO din 10 septembrie, separat

Dovada minimă pentru închidere

Awarely Monitor ajută la urmărirea expunerilor, a responsabililor, a excepțiilor și a dovezilor deciziilor până la închidere. Nu scanează site-urile tale după scripturi terțe, nu inspectează pagini, nu detectează cod injectat și nu gestionează chei API. Inventarul scripturilor, verificarea logurilor și rotația secretelor rămân în uneltele tale web, în procesul de dezvoltare și în controalele furnizorilor.

• ▸Inventarul scripturilor terțe încărcate de fiecare site public al organizației, cu furnizorul, scopul, responsabilul intern și data ultimei revizuiri.
• ▸Rezultatul căutării pentru componentele Brevo, pe toate site-urile, inclusiv cele de campanie și cele uitate.
• ▸Domeniul căutării în loguri, retenția disponibilă, fereastra acoperită și rezultatul, cu limitele explicite ale investigației.
• ▸Pentru site-urile WordPress: lista pluginurilor verificată pe disc, nu doar în interfață, și decizia luată pentru fiecare anomalie.
• ▸Deciziile de rotație: parole de administrator, chei API către furnizori, cu cine și când.
• ▸Inventarul propriilor chei API cu permisiuni largi sau fără expirare, cu planul de rotație și responsabilul, ca rezultat direct al acestui incident.