Ataki na Magento i WordPressa uderzają masowo

Dwie fale ataków na popularne systemy

W świecie cyberbezpieczeństwa ostatnie dni przyniosły dwie głośne kampanie wymierzone w szeroko używane platformy internetowe. Z jednej strony atakujący wykorzystują niezałataną lukę zero-day w Magento Open Source i Adobe Commerce, aby podsuwać sklepom internetowym trwały backdoor. Z drugiej — masowo skanują i atakują witryny WordPress oparte na wtyczkach Super Forms i Elementor Pro, gdzie liczba prób wykorzystania podatności liczona jest już w setkach tysięcy.

Choć dotyczą różnych ekosystemów, oba incydenty pokazują ten sam problem: gdy popularne oprogramowanie trafia na celownik, czas reakcji ma kluczowe znaczenie.

Magento i Adobe Commerce bez łatki

Pierwszy z opisywanych problemów dotyczy nowej, jeszcze niezałatanej podatności w Magento Open Source oraz Adobe Commerce. Luka pozwala wykonać kod na serwerze sklepu bez logowania, co w praktyce otwiera drogę do przejęcia hostingu sklepu i instalacji trwałego backdoora.

Badacze, którzy wykryli problem, nazwali go StyleSmuggler. Według ich ustaleń ataki rozpoczęły się 4 września, a publiczne ostrzeżenie pojawiło się, zanim Adobe opublikowało poprawkę, identyfikator CVE czy obejście problemu. W chwili opisywania incydentu nie było też oficjalnego biuletynu bezpieczeństwa z poprawką.

Istotne jest to, że podatność dotykała aktualnych wydań Magento, w tym 2.4.9, a badacze potwierdzili pełny łańcuch ataku na czystych instalacjach 2.4.7, 2.4.8 i 2.4.9. Jeden z pierwszych zaatakowanych sklepów działał na 2.4.6-p15 z zainstalowanymi lipcowymi i sierpniowymi poprawkami bezpieczeństwa z 2026 roku.

Jak działa atak

Mechanizm ataku składa się z dwóch etapów. Najpierw napastnik wstrzykuje PHP do pliku, który Magento samo zapisuje — na przykład podczas generowania raportu błędu. Następnie doprowadza do wykonania tego pliku przez uruchomienie standardowego mechanizmu wiadomości o nieudanej transakcji płatniczej.

To ważne: kod uruchamia się w trakcie renderowania wiadomości, więc ofiara nie musi nawet otworzyć e-maila. Nawet jeśli sama dostawa wiadomości się nie powiedzie, exploit nadal może zadziałać.

Efekt końcowy to uruchomienie kodu na serwerze i instalacja backdoora, który ma przetrwać ponowne uruchomienia i utrzymywać dostęp do sklepu.

Co zostawia po sobie malware

Wskaźniki kompromitacji wskazują na dość charakterystyczny zestaw śladów. Zainfekowany proces potrafi podszyć się pod nazwę przypominającą wątek jądra Linuksa — [kworker/u:8:0] — choć w rzeczywistości działa jako proces zwykłego użytkownika, a nie roota.

Plik binarny jest umieszczany poza web rootem, w katalogu użytkownika sklepu, między innymi pod ścieżką:

• ~/.local/share/.gvfsd/gvfsd-user

W innych wariantach pojawiają się także pliki pomocnicze i locki w katalogach ~/.local/share/.gvfsd/, /tmp/ oraz wpis cron uruchamiający implant co 5 minut.

Badacze opisali też, że próbka była statycznie linkowanym programem Rust dla architektur x86-64 i arm64. Na jednym z zaatakowanych sklepów plik na dysku różnił się od wersji działającej w pamięci, co dodatkowo utrudniało analizę.

Ślady ataku w logach i e-mailach

Jednym z najbardziej praktycznych sygnałów ostrzegawczych okazały się wiadomości o nieudanych transakcjach płatniczych. W jednym przypadku sklep sam wysłał właścicielowi e-mail z uszkodzonym szablonem — z surowymi znacznikami typu {{var ...}}, adresem na domenie .invalid i zerową kwotą. Taki komunikat wygląda jak błędne zamówienie, ale w rzeczywistości może być efektem ubocznym próby exploitacji.

W logach warto sprawdzać zarówno var/report/, jak i var/log/system.log, bo atak nie zawsze zostawia ślady w jednym, domyślnie monitorowanym miejscu. Pojawia się też charakterystyczny wzorzec nagłówka X-TRACE- z ośmioma lub dziesięcioma znakami szesnastkowymi, choć forma tego znacznika może się zmieniać.

Uderzenie było szybkie i skoordynowane

Zebrane dane pokazują, że kampania nie ograniczała się do jednego źródła. W atakach na Magento zidentyfikowano wiele adresów IP, a nie tylko pojedynczy serwer kontrolujący całą operację. Część ruchu pochodziła z infrastruktury hostingowej, a część z puli proxy mieszkaniowych.

W praktyce oznacza to, że blokada jednego adresu nie wystarczyła. Ruch był rozproszony i uporczywy, a liczba źródeł rosła wraz z rozwojem kampanii.

Co mogą zrobić administratorzy

Na moment publikacji nie było oficjalnej łatki do wdrożenia. Zamiast tego zalecano działania tymczasowe i obronne:

• czasowe wyłączenie GraphQL tam, gdzie to możliwe,
• szukanie podejrzanych wpisów w var/report/ i var/log/system.log,
• sprawdzanie procesów podszywających się pod kworker/u:8:0,
• weryfikację plików w katalogach domowych użytkowników sklepu i w /tmp/,
• rotację haseł Magento oraz kluczy i sekretów z app/etc/env.php.

Wśród dodatkowych środków wymieniano też:

• ustawienie proc_open w disable_functions,
• montowanie /tmp, /var/tmp i /dev/shm z opcją noexec,
• ostrożność przy uruchamianiu composer install, bo może nadpisać ślady incydentu.

WordPress też pod ostrzałem

Drugi opisany incydent dotyczy środowiska WordPress. Badacze odnotowali już ponad 440 tysięcy prób wykorzystania dwóch krytycznych luk w popularnych wtyczkach:

• CVE-2026-14894 w Super Forms – Drag & Drop Form Builder,
• CVE-2026-32475 w Elementor Pro.

Obie podatności prowadzą do nieautoryzowanego uploadu plików, w tym plików PHP, a więc w konsekwencji do remote code execution.

W przypadku Super Forms atakujący wysyłają żądanie POST do admin-ajax.php, używając endpointu super_submit_form, i wgrywają payload PHP udający obrazek GIF. W przypadku Elementor Pro obejście polega na przesłaniu pola uploadu jako tablicy: pierwszy element jest pusty, a drugi zawiera plik PHP z rozszerzeniem .php. To wystarcza, by mechanizm walidacji został oszukany.

Skala ataków rośnie

Z danych telemetrycznych wynika, że:

• ataki na Super Forms rozpoczęły się 14 lipca 2026 roku,
• szczyt aktywności przypadł na 18 sierpnia 2026 roku, gdy liczba prób przekroczyła 40 tysięcy w ciągu jednego dnia,
• ataki na Elementor Pro zaczęły się 19 sierpnia 2026 roku.

Lista źródeł ruchu jest długa i obejmuje wiele różnych adresów IP, co sugeruje szeroką kampanię rozproszoną między wieloma infrastrukturami.

Co powinny zrobić organizacje

W przypadku WordPressa sprawa jest prostsza niż przy luce zero-day w Magento: dostępne są poprawione wersje wtyczek. Administratorzy powinni więc natychmiast:

• zaktualizować Super Forms do wersji 6.3.314,
• zaktualizować Elementor Pro do wersji 4.2.2,
• przejrzeć witryny pod kątem nieoczekiwanych plików .php,
• sprawdzić, czy w katalogach uploadu nie pojawiły się nowe skrypty,
• przeanalizować logi pod kątem prób uploadu i wywołań admin-ajax.php.

Wspólny mianownik: czas reakcji

Oba przypadki pokazują, że w cyberbezpieczeństwie e-commerce i CMS-ów najważniejsze są trzy rzeczy: szybkie łatanie, monitoring logów i umiejętność wyłapania subtelnych oznak kompromitacji. W Magento problem jest dodatkowo trudny, bo przez pewien czas nie było gotowej poprawki, a atak wykorzystywał standardowe mechanizmy platformy.

To właśnie takie scenariusze — ciche, szybkie i prowadzące do trwałego przejęcia serwera — są dziś najgroźniejsze dla sklepów internetowych i witryn opartych na popularnych wtyczkach.