Brevo-angreb ramte 100.000 sider — tjek din WordPress

Den 14. september 2026 blev omkring 100.000 hjemmesider i fire til fem timer omdannet til spredere af malware — uden at ejerne gjorde noget forkert, og uden at nogen af dem blev hacket. Fælles for dem var, at de havde et lille stykke JavaScript fra e-mailplatformen Brevo (tidligere Sendinblue) liggende på siden: en tilmeldingsformular, en chatwidget eller en sporingskode.

Er du blandt dem — og det er mange danske webshops, foreninger og bureauer, der bruger Brevo til nyhedsbreve — så er der en konkret ting, du skal tjekke i din WordPress. Den står længere nede.

Det er ikke den Brevo-sag, vi skrev om den 13. september

Lad os rydde forvirringen af vejen med det samme, for de to sager har samme firmanavn og syv dages afstand, og de bliver blandet sammen i flere gennemgange.

Den 13. september beskrev vi, hvordan en falsk Trezor-mail bad 347.000 modtagere om deres seed phrase. Dén sag handlede om en fejl i Brevos single sign-on, der blev offentliggjort den 10. september. Angriberen kom ind i kundekonti og sendte phishing fra kundernes egne nyhedsbrevsadresser. Angrebsvejen var indbakken.

Denne sag er en anden hændelse med en helt anden mekanisme. Her blev der ikke sendt en eneste mail, og der blev ikke logget ind på nogen kundekonto. Angrebet foregik i Cloudflares netværk, på vejen mellem Brevos servere og besøgendes browsere. Angrebsvejen var hjemmesiden.

Sikkerhedsfirmaet Sansec, der kortlagde forløbet i sin egen tekniske gennemgang, bekræfter selv, at SSO-hændelsen fra den 10. september er en separat sag. To huller, samme leverandør, to uger. Det er i sig selv en del af historien.

Sådan kom angrebet ind — uden at røre Brevos servere

Den tekniske kerne er en Cloudflare API-nøgle, der lå hardkodet i Brevos kildekode. Den var langtidsgyldig og havde fulde rettigheder til kontoen. Ifølge BleepingComputer kan nøglen have været i uvedkommende hænder allerede fra slutningen af august, uden at der skete noget synligt.

Med den nøgle kunne angriberen oprette en Cloudflare Worker — et lille program, der kører på Cloudflares kanter og kan omskrive svar, før de når frem til browseren. Og det er præcis, hvad den gjorde: den ændrede indholdet af Brevos JavaScript-filer på vej ud gennem CDN'et.

To ting gør det her ubehageligt.

For det første: Brevos egne servere blev aldrig kompromitteret. Filerne lå uændrede og rene hos Brevo. Hvis man havde tjekket dem ved kilden, havde alt set normalt ud. Det var kun kopien, der blev leveret til besøgende, der var manipuleret.

For det andet: den ondsindede Worker fjernede sikkerhedsheadere, herunder Content-Security-Policy. CSP er netop det værn, der skal forhindre en hjemmeside i at køre kode fra steder, den ikke har godkendt. Ved at stryge headeren ved kanten fjernede angriberen både låsen og alarmen i ét greb. Samme teknik kan i princippet bruges mod enhver tjeneste, der leverer scripts til tredjeparters sider.

Ramt blev brevo.com og sendinblue.com selv, login-siderne, sibforms.com — og de indlejrede komponenter på op mod 100.000 kundesider: formular-scriptet, Conversations-widgetten og SDK-loaderen.

Falsk Cloudflare-kontrol og ClickFix

For den almindelige besøgende så det hele ud som en velkendt irritation: en falsk Cloudflare-verificering — den slags "bekræft, at du er et menneske"-side, alle har klikket sig igennem hundredvis af gange.

Bagefter kom instruktionen, der er hele pointen i ClickFix-metoden: siden lægger en kommando i din udklipsholder og beder dig om at indsætte og køre den — typisk i Windows' kør-dialog eller i en terminal. Du installerer altså selv malwaren, i den tro at du løser et teknisk problem. Vi har beskrevet præcis den mekanik før, da en falsk CAPTCHA narrede brugere til selv at installere ransomware.

Overlayet blev også vist til folk, der klikkede på afmeldingslinks i kampagnemails sendt via Brevo. Har du klikket "afmeld" i et nyhedsbrev den 14. september og derefter fået en Cloudflare-lignende side, der bad dig kopiere og køre noget: kør en virusscanning af maskinen nu.

"Web Media Optimizer": bagdøren til WordPress

Den anden nyttelast var målrettet noget helt specifikt: en besøgende, der var logget ind som administrator på sin egen WordPress-side.

Var du det, forsøgte scriptet at installere et plugin ved navn "Web Media Optimizer". Navnet er valgt til at gå ubemærket hen — det lyder som et hvilket som helst billedoptimeringsplugin. Pluginnet kan skjule sig selv fra plugin-oversigten i WordPress-administrationen og give angriberen vedvarende adgang som administrator.

Det betyder, at en ejer, der loggede ind for at se, hvorfor siden opførte sig mærkeligt, kan have fået bagdøren installeret ved netop det besøg. Og at bagdøren stadig kan sidde der i dag, selvom angrebet for længst er stoppet.

Tjekliste: sådan undersøger du din egen side

Tidsvinduet er snævert og velafgrænset. Sansec måler, at malwaren blev serveret mellem 16:05 og 20:12 UTC den 14. september — altså godt fire timer; enkelte gennemgange angiver op til 5,5 timer. Alt, hvad du skal lede efter, ligger på den ene dag.

1. Gennemgå dine plugins for installations- eller aktiveringsdato 14. september. Leder du efter et navn, er det Web Media Optimizer — men gå ikke ud fra, at navnet er det samme hos alle.
2. Sammenlign mappen wp-content/plugins på serveren med listen i WordPress-administrationen. Er der en mappe, der ikke optræder i oversigten, er det et alvorligt fund. Det er hele pointen i et plugin, der skjuler sig.
3. Søg i serverens adgangslog efter to anmodninger fra den 14. september: en POST til /wp-admin/update.php?action=upload-plugin og kort efter en GET til /wp-admin/plugins.php?action=activate. Kommer de fra en tid, hvor du ved, du ikke selv installerede noget, er sagen klar.
4. Skift adgangskoder på alle administratorkonti, og log alle sessioner ud.
5. Gennemgå brugerlisten for administratorkonti, du ikke selv har oprettet.

Fandt du noget, skal siden behandles som kompromitteret: gendan fra en sikkerhedskopi fra før den 14. september, eller få en professionel til at rense den. Et plugin, der kan skjule sig, kan også have lagt kode andre steder.

Samme fremgangsmåde gælder i øvrigt bredt. Vi har set den igen og igen i år — fra angrebene mod Elementor Pro og Super Forms til det kritiske WP2Shell-hul. WordPress-sider falder sjældent på selve WordPress. De falder på det, der er sat ind i dem.

Konklusion

Brevo har fjernet den hardkodede nøgle fra sin kildekode og er skiftet til kortlivede tokens med begrænsede rettigheder. Cloudflare-Workeren er slettet, de ondsindede værtsnavne holdt op med at svare den 15. september, og indholdet ved kilden er rent.

Men det ændrer ikke ved, at en enkelt glemt nøgle i en kildekodefil gjorde 100.000 uafhængige hjemmesider til malwaredistributører i løbet af en eftermiddag — og at ingen af sideejerne kunne have gjort noget for at forhindre det. Det er forsyningskædeangrebets kerneproblem: din sikkerhed er ikke bedre end sikkerheden hos den mindst omhyggelige leverandør, hvis script du har limet ind i sidefoden.

Det eneste, du kan gøre nu, er det, du selv har kontrol over: tjek dine plugins, tjek din log fra den 14. september, og skift dine administratoradgangskoder. Og overvej, hvor mange tredjepartsscripts der egentlig behøver at ligge på din side.