BEZPIECZEŃSTWO WORDPRESS 11 min czytania

Atak na Brevo: jak cudzy skrypt zaatakował odwiedzających firmowe strony?

Skradziony klucz API Cloudflare pozwolił podmienić skrypty Brevo osadzone na stronach klientów. Sprawdź, co zweryfikować i jak zapanować nad obcym kodem.

Strona firmowa może mieć aktualny WordPress, silne hasła, kopię zapasową i poprawnie skonfigurowany hosting, a mimo to zaatakować własnych odwiedzających. Wystarczy, że ładuje skrypt dostarczany przez zewnętrzną usługę — formularz newslettera, okienko czatu, analitykę albo piksel reklamowy.

14 września 2026 roku dokładnie to się wydarzyło. Przez kilka godzin skrypty platformy mailingowej Brevo, osadzone na tysiącach witryn, serwowały odwiedzającym fałszywy komunikat weryfikacyjny i instrukcję uruchomienia polecenia w systemie Windows. Pliki na serwerach tych firm pozostały nienaruszone.

Co dokładnie wydarzyło się w ataku na Brevo?

Brevo, znane wcześniej jako Sendinblue, to platforma do e-mail marketingu i obsługi klienta. Firmy korzystają z niej przy newsletterach, formularzach zapisu i okienkach czatu. Żeby te elementy działały na stronie, wkleja się do jej kodu fragment dostarczony przez usługodawcę: skrypt formularza, widżet konwersacji albo tak zwany loader SDK.

Zgodnie z raportem opublikowanym przez Brevo atakujący zdobyli klucz API do Cloudflare należący do firmy. Był to klucz długoterminowy, z pełnymi uprawnieniami do konta, zaszyty bezpośrednio w kodzie źródłowym aplikacji. Firma przyznaje, że klucz mógł znajdować się w rękach napastników już pod koniec sierpnia, choć nie znaleziono śladów wcześniejszej aktywności.

Mając ten klucz, atakujący nie musieli włamywać się na serwery Brevo. Utworzyli własny komponent w infrastrukturze Cloudflare — Cloudflare Worker — który modyfikował odpowiedzi w drodze do przeglądarki użytkownika, już po opuszczeniu serwerów źródłowych.

Podmienione zostały między innymi skrypt formularzy Brevo, widżet Conversations oraz loader SDK, czyli dokładnie te elementy, które klienci osadzają na własnych stronach. Firma Sansec, która jako pierwsza opisała incydent, szacuje zasięg na blisko sto tysięcy witryn.

Element	Ustalenie
Data incydentu	14 września 2026
Okno ekspozycji	16:07–20:30 UTC według Brevo, 16:05–20:13 UTC według Sansec
Wektor	Skradziony długoterminowy klucz API Cloudflare z pełnymi uprawnieniami
Mechanizm	Cloudflare Worker modyfikujący odpowiedzi na brzegu sieci
Dotknięte zasoby	Skrypt formularzy, widżet Conversations, loader SDK, wybrane domeny Brevo
Nienaruszone	Aplikacja app.brevo.com, API, infrastruktura wysyłki poczty, dane kont klientów
Zakończenie	Złośliwe subdomeny przestały odpowiadać 15 września, pliki Brevo są czyste

Łańcuch ataku: od skradzionego klucza API Cloudflare do odwiedzającego Twoją stronę

Rozbieżność w oknie ekspozycji wynika z różnych metod pomiaru i nie zmienia obrazu sytuacji. Ma jednak znaczenie, jeśli analizujesz własne logi serwera.

Dlaczego standardowe zabezpieczenia tego nie wykryły?

To najważniejszy techniczny szczegół całej sprawy.

Typowa ochrona strony sprawdza, czy pliki na serwerze się nie zmieniły: porównuje sumy kontrolne, szuka nieznanego kodu, weryfikuje integralność. W tym ataku wszystkie te kontrole raportowały stan prawidłowy — ponieważ pliki źródłowe faktycznie były nietknięte. Modyfikacja następowała dopiero w drodze do przeglądarki.

Dodatkowo złośliwy komponent usuwał nagłówek Content-Security-Policy, czyli mechanizm informujący przeglądarkę, skąd wolno ładować skrypty. Bez niego przeglądarka wykonywała wszystko, co jej podano.

Efekt był następujący:

firewall aplikacyjny nie miał czego zablokować, bo ruch pochodził z zaufanej domeny dostawcy;
skaner plików nie miał czego znaleźć, bo na serwerze nic się nie zmieniło;
właściciel strony nie miał żadnego sygnału, że coś jest nie tak.

To dobra ilustracja różnicy między atakiem na stronę a atakiem na łańcuch dostaw. W pierwszym przypadku napastnik uderza bezpośrednio w Twoją infrastrukturę. W drugim kompromituje zaufany element znajdujący się wcześniej w łańcuchu — a Twoja strona jedynie posłusznie dostarcza jego kod odwiedzającym. Szerzej opisujemy ten mechanizm w artykule o bezpieczeństwie wtyczek WordPress i ryzyku supply chain.

Czym jest ClickFix i dlaczego działa nawet na ostrożnych pracowników?

Osobom wchodzącym na dotknięte strony wyświetlała się fałszywa strona weryfikacji Cloudflare, a po niej instrukcja: skopiuj poniższe polecenie i wklej je w systemie Windows, żeby rozwiązać problem.

Ta technika nazywa się ClickFix i jest dziś jednym z najskuteczniejszych sposobów dystrybucji złośliwego oprogramowania. Działa, ponieważ omija wszystko, czego uczymy pracowników na szkoleniach:

nie ma podejrzanego załącznika, bo nie ma maila;
nie ma linku do dziwnej domeny, bo użytkownik jest na stronie, którą zna;
nie ma pliku do pobrania, który zatrzyma antywirus;
polecenie uruchamia sam użytkownik, więc dla systemu wygląda to jak świadoma decyzja właściciela sprzętu.

Zasada, którą warto przekazać zespołowi, jest krótka i nie wymaga wiedzy technicznej:

Żadna prawdziwa strona internetowa nigdy nie prosi o wklejenie polecenia do systemu Windows. Ani Cloudflare, ani Google, ani bank, ani dostawca poczty. Jedyną poprawną reakcją jest zamknięcie karty.

Fałszywe okno weryfikacji ClickFix obok poprawnej reakcji zespołu

Co groziło stronom na WordPressie?

Dla witryn opartych na WordPressie przygotowano osobny scenariusz i to on wymaga najpilniejszej weryfikacji.

Złośliwy skrypt sprawdzał, czy odwiedzający jest w danym momencie zalogowany jako administrator. Jeśli tak, próbował w tle zainstalować wtyczkę pobieraną z serwera atakujących. Według analizy BleepingComputer dodatek podszywa się pod narzędzie do optymalizacji mediów i nosi nazwę Web Media Optimizer.

Po instalacji wtyczka:

ukrywa się przed listą wtyczek w panelu, więc administrator jej nie widzi;
kopiuje się do katalogu dodatków typu must-use, dzięki czemu przetrwa dezaktywację;
cyklicznie odpytuje serwer sterujący o adres skryptu, który następnie wstrzykuje odwiedzającym stronę;
przechowuje zapasowy adres, aby działać nawet po zniknięciu serwera sterującego;
zawiera zaszyty klucz pozwalający wygenerować sesję administratora bez znajomości hasła.

Ostatni punkt ma praktyczną konsekwencję: sama zmiana hasła nie zamyka tej furtki. Najpierw trzeba usunąć wtyczkę.

Zagrożenie dotyczy wąskiej grupy przypadków — konto administratora musiało mieć aktywną sesję i w tym samym czasie odwiedzić stronę z podmienionym skryptem. W małej firmie, gdzie panel strony bywa otwarty w tle przez cały dzień roboczy, nie jest to scenariusz egzotyczny.

Co sprawdzić dzisiaj?

Jeżeli Twoja strona korzysta z formularzy, widżetu czatu lub SDK Brevo — albo po prostu nie masz pewności — przejdź przez poniższe kroki. Zajmie to kilkanaście minut.

Krok	Działanie	Gdzie sprawdzić
1	Poszukaj wtyczek zainstalowanych lub aktywowanych 14 września, ze szczególną uwagą na dodatki o nazwach sugerujących optymalizację mediów.	Panel WordPress → Wtyczki, a następnie katalogi `wp-content/plugins` i `wp-content/mu-plugins` przez FTP lub menedżer plików hostingu.
2	Ustal, kto z zespołu miał 14 września aktywną sesję administratora i odwiedzał wtedy strony firmowe.	Rozmowa z osobami mającymi uprawnienia administratora.
3	Sprawdź listę kont administratorów pod kątem nowych oraz zbędnych wpisów.	Panel WordPress → Użytkownicy.
4	Po usunięciu podejrzanych dodatków zmień hasła administratorów i wyloguj wszystkie sesje.	Panel WordPress, menedżer haseł firmy.
5	Zapytaj zespół wprost, czy ktokolwiek wklejał polecenie z komunikatu o weryfikacji połączenia.	Rozmowa z zespołem, bez oceniania.

Kolejność ma znaczenie. Zmiana hasła przed usunięciem wtyczki niczego nie rozwiązuje, bo dodatek potrafi zalogować się bez hasła.

Jeżeli ktokolwiek uruchomił polecenie z komunikatu ClickFix, potraktuj ten komputer jako zainfekowany: odłącz go od sieci, zmień hasła do firmowej poczty i systemów z innego urządzenia, a sprzęt przekaż do sprawdzenia. Jeśli w firmie działa uwierzytelnianie dwuskładnikowe, przejęte hasło nie wystarczy atakującemu — dlatego warto je wdrożyć zawczasu, zgodnie z zasadami opisanymi w poradniku o wdrożeniu MFA w firmie.

Czy to był odosobniony incydent?

Nie. Cztery dni wcześniej, 10 września, Brevo opisało osobny incydent związany z logowaniem jednokrotnym, w wyniku którego atakujący przejęli konta klientów platformy i z tych kont rozsyłali phishing do ich odbiorców.

Jedną z ofiar był producent portfeli kryptowalutowych Trezor, który 11 września poinformował, że fałszywe wiadomości trafiły do 347 tysięcy adresów, a co najmniej 2 500 kont użytkowników zostało przejętych.

Czy oba zdarzenia są ze sobą powiązane, nie wiadomo — Brevo nie odpowiedziało na to pytanie zadane przez dziennikarzy. Nie należy więc zakładać, że to jedna operacja. Warto natomiast zauważyć, co oba incydenty mają wspólnego z perspektywy klienta: w żadnym z nich firma korzystająca z platformy nie popełniła błędu, a mimo to jej odbiorcy zostali zaatakowani w jej imieniu.

Ile obcego kodu działa na Twojej stronie?

Rozmowy o bezpieczeństwie strony firmowej zwykle krążą wokół tego, co znajduje się na serwerze: wersja WordPressa, aktualność wtyczek, siła hasła, kopia zapasowa. To wszystko pozostaje ważne.

Tymczasem przeciętna strona firmowa ładuje dziś od kilku do kilkunastu skryptów z serwerów, nad którymi nikt w firmie nie ma kontroli:

narzędzie do mailingu i formularze zapisu;
okienko czatu lub system zgłoszeń;
analityka i menedżer tagów;
piksele reklamowe i narzędzia remarketingowe;
mapy, systemy rezerwacji i kalendarze;
widżety opinii, ocen i mediów społecznościowych;
banner zgód na pliki cookie;
biblioteki graficzne i fonty ładowane z zewnętrznych CDN.

Każdy z nich został tam kiedyś wklejony w dobrej wierze, zwykle przez inną osobę i często lata temu. I każdy z nich ma w przeglądarce Twojego klienta dokładnie takie same uprawnienia jak Twój własny kod.

To nie oznacza, że trzeba je wszystkie usunąć. Oznacza, że warto wiedzieć, ile ich jest i skąd pochodzą — bo w dniu, w którym któryś z dostawców zostanie zaatakowany, pytanie „czy to nas dotyczy?” powinno mieć odpowiedź w pięć minut, a nie po tygodniu szukania.

Jak zinwentaryzować skrypty firm trzecich?

Zacznij od listy technicznej, a następnie dodaj kontekst biznesowy. Najprostszy sposób bez narzędzi deweloperskich: otwórz stronę w przeglądarce, naciśnij F12, przejdź na zakładkę Sieć (Network) i odśwież stronę z filtrem na pliki JS. Zobaczysz każdą domenę, z której ładuje się kod.

Dobra inwentaryzacja powinna zawierać:

Pole	Pytanie kontrolne
Narzędzie	Jaka usługa dostarcza ten skrypt?
Domena	Z jakiego adresu ładuje się kod?
Funkcja biznesowa	Co przestanie działać po jego usunięciu?
Właściciel	Kto w firmie odpowiada za to narzędzie i jego konto?
Kto dodał	Zespół wewnętrzny, agencja, freelancer czy dostawca hostingu?
Zakres danych	Czy narzędzie widzi dane z formularzy, koszyka lub płatności?
Kanał kontaktu	Gdzie sprawdzimy status i komunikaty o incydentach dostawcy?
Decyzja	Zostawić, zastąpić, ograniczyć czy usunąć?

Większość firm odkrywa przy takim spisie dwa lub trzy skrypty po narzędziach, z których nikt już nie korzysta: porzucony czat, analityka zastąpiona inną, piksel po kampanii sprzed dwóch lat. Te można po prostu skasować i jest to najtańsze zabezpieczenie, jakie da się dziś wdrożyć.

Jak ograniczyć ryzyko skryptów zewnętrznych?

Pełne wyeliminowanie tego ryzyka nie jest możliwe, dopóki strona korzysta z kodu firm trzecich. Można je jednak istotnie zmniejszyć.

Zredukuj liczbę dostawców. Każde narzędzie mniej to jeden potencjalny incydent mniej. Zacznij od skryptów bez przypisanego właściciela i bez funkcji biznesowej.

Ustaw Content-Security-Policy na własnej stronie. Nagłówek określa, z jakich domen przeglądarka może ładować skrypty. Ogranicza to zasięg ataku, ale ma istotne zastrzeżenie: nie pomoże, gdy złośliwy kod pochodzi z domeny, którą i tak masz na liście zaufanych — czyli dokładnie w scenariuszu Brevo.

Rozważ Subresource Integrity dla skryptów o stałych wersjach. Mechanizm SRI każe przeglądarce porównać skrót pliku z oczekiwaną wartością i odmówić wykonania zmodyfikowanego kodu. Blokuje podmianę taką jak w tym ataku, ale działa wyłącznie tam, gdzie plik ma niezmienną wersję. Loadery SaaS aktualizowane przez dostawcę bez zapowiedzi zwykle się do tego nie nadają.

Ogranicz czas pracy na koncie administratora. Panel strony otwarty w tle przez osiem godzin to warunek, który umożliwił instalację złośliwej wtyczki. Do codziennej pracy redakcyjnej wystarczy konto o niższych uprawnieniach.

Śledź kanały statusu swoich dostawców. Brevo opublikowało raport po incydencie na własnej stronie statusu. Subskrypcja takich kanałów dla trzech–czterech kluczowych narzędzi kosztuje kilka minut, a daje informację, zanim temat trafi do mediów.

Zachowaj możliwość odtworzenia strony. Kopia zapasowa przechowywana poza serwerem strony oraz przetestowany proces odtwarzania pozostają ostatnią linią obrony, także wtedy, gdy atak przyszedł kanałem, którego nie kontrolujesz. Podstawy opisujemy w poradniku jak zabezpieczyć firmę przed cyberatakami.

Checklista: obcy kod na stronie firmowej

Reakcja na ten konkretny incydent

Sprawdziliśmy listę wtyczek i katalogi plugins oraz mu-plugins pod kątem zmian z 14 września.
Ustaliliśmy, kto miał wtedy aktywną sesję administratora.
Zweryfikowaliśmy listę kont administratorów i usunęliśmy zbędne.
Zmieniliśmy hasła administratorów po usunięciu podejrzanych dodatków.
Zapytaliśmy zespół o komunikat proszący o wklejenie polecenia do systemu.

Inwentaryzacja

Mamy spis wszystkich zewnętrznych skryptów ładowanych przez stronę.
Każdy skrypt ma przypisaną funkcję biznesową i właściciela w firmie.
Wiemy, które narzędzia mają dostęp do danych z formularzy, koszyka lub płatności.
Spis obejmuje wszystkie strony i sklepy firmy, nie tylko witrynę główną.

Ograniczanie ryzyka

Usunęliśmy skrypty po narzędziach, z których już nie korzystamy.
Strona wysyła nagłówek Content-Security-Policy z listą dozwolonych domen.
Do codziennej pracy redakcyjnej używamy kont bez uprawnień administratora.
Konta administratorów są chronione uwierzytelnianiem dwuskładnikowym.

Monitoring i reakcja

Śledzimy kanały statusu kluczowych dostawców.
Rejestrujemy instalacje, aktywacje i usunięcia wtyczek oraz zmiany kont administratorów.
Kopie zapasowe są przechowywane poza serwerem strony i regularnie testowane.
Zespół wie, że żadna strona nie prosi o wklejanie poleceń do systemu.

Najważniejszy wniosek

Bezpieczeństwo strony firmowej nie kończy się na tym, co znajduje się na Twoim serwerze. Typowa witryna jest dziś złożeniem kodu wielu dostawców, dostarczanego przez sieci, których nie kontrolujesz, i aktualizowanego bez Twojej wiedzy.

W ataku na Brevo żadna z dotkniętych firm nie zrobiła nic złego. Różnica między nimi polegała na czymś innym: jedne wiedziały, jaki obcy kod działa na ich stronie, a drugie musiały się tego dopiero dowiedzieć — już po fakcie.

Jeżeli nie masz aktualnej listy zewnętrznych skryptów i narzędzi osadzonych na swojej stronie, umów bezpłatną 20-minutową diagnozę. Przejdziemy przez sposób pracy firmy i wskażemy trzy najważniejsze ryzyka dla kont, danych i strony — w jasnej kolejności działań, bez dostępu do Twoich systemów.