Luka w Bricksforge (CVE-2026-85097): jak sprawdzić, czy strona została przejęta, i co zrobić w 24 godziny

Autor: Grzegorz Wojterzak. Aktualizacja: 19 października 2026. Czas czytania: około 12 minut.

Bricksforge to płatny dodatek do kreatora stron Bricks Builder. Dokłada mu m.in. formularze (moduł Pro Forms) i animacje, dlatego chętnie używają go agencje. W październiku 2026 okazało się, że jeden z jego mechanizmów pozwala obcej osobie wrzucić na serwer własny program i go uruchomić. Nie trzeba do tego żadnego hasła.

Poniżej wyjaśniam, co to znaczy dla Ciebie, jak sprawdzić, czy Cię to dotyczy, i co zrobić w ciągu pierwszej doby. Ta sama procedura zadziała przy każdej innej aktywnie wykorzystywanej luce we wtyczce.

Co się stało i dlaczego to poważne

Luka dostała numer CVE-2026-85097. CVE to po prostu numer w światowym rejestrze znanych luk, dzięki któremu wszyscy mówią o tym samym błędzie. Ocena zagrożenia w skali CVSS wynosi 10,0, czyli najwyżej, jak się da. Tak ocenia się luki, których można użyć zdalnie i bez logowania.

Według analizy firmy Patchstack, która opisała pierwsze wykryte ataki, problem tkwi w obsłudze plików wysyłanych przez formularze. Wtyczka sprawdza typ pliku przy pierwszym wgraniu, ale nie sprawdza go ponownie przy wysłaniu formularza. Atakujący wgrywa więc plik, który jednocześnie jest poprawnym obrazkiem GIF i programem w PHP (taki plik nazywa się poliglotą), a potem każe wtyczce zapisać go pod nazwą zakończoną na .php. Od tej chwili wystarczy otworzyć ten plik w przeglądarce, żeby serwer wykonał kod atakującego.

W praktyce oznacza to zdalne wykonanie kodu (RCE, z ang. remote code execution), czyli sytuację, w której ktoś z zewnątrz może robić na Twoim serwerze to samo, co sama strona: czytać bazę danych z zamówieniami, dopisywać kod do plików, zakładać konta. Zwykle pierwszym krokiem jest wgranie webshella, czyli ukrytego pliku, przez który włamywacz steruje stroną także po załataniu luki.

Źródła: analiza Patchstack i wpis w bazie Wordfence. Numer najnowszej wersji zmienia się z każdym wydaniem, więc przed aktualizacją sprawdź listę zmian u producenta.

Ataki są zautomatyzowane. Boty nie wybierają ofiar, tylko odpytują tysiące stron i sprawdzają, która odpowie. To, że Twoja strona jest mała i „nikogo nie interesuje”, niczego tu nie zmienia.

Czy to dotyczy Twojej strony

Jeśli stronę robiła agencja albo freelancer, możesz nawet nie wiedzieć, że masz Bricksforge. Sprawdzenie zajmuje minutę.

1. Otwórz listę wtyczek

   Zaloguj się do panelu WordPressa i wejdź w Wtyczki (w wersji angielskiej: Plugins). Poszukaj pozycji „Bricksforge”. Pod opisem każdej wtyczki jest numer wersji.

2. Porównaj wersję

   3.1.8.9 lub niższa oznacza wersję podatną. 3.1.8.10 lub wyższa oznacza, że luka jest załatana, ale nadal musisz sprawdzić, czy ktoś nie wszedł przed aktualizacją.

3. Bez dostępu do panelu sprawdź katalog

   W menedżerze plików w panelu hostingu albo przez FTP zajrzyj do wp-content/plugins/. Katalog bricksforge oznacza, że wtyczka jest zainstalowana (aktywna lub nie). Przez SSH zrobisz to jednym poleceniem, które wypisze nazwę, stan i wersję wtyczki:

   wp plugin list --name=bricksforge --fields=name,status,version

Plan na pierwsze 24 godziny

Jeśli masz podatną wersję, działaj w tej kolejności. Pierwsze dwa kroki zajmują kilka minut i są najważniejsze.

1. Zrób kopię strony w obecnym stanie

   Pobierz pliki i bazę danych, zanim cokolwiek zmienisz. Kopia pomoże ustalić, co się stało, i pozwoli wrócić, jeśli aktualizacja coś zepsuje. Większość hostingów pozwala zrobić kopię jednym przyciskiem w panelu. Przez SSH zrobisz to tak (pierwsze polecenie pakuje pliki, drugie zapisuje bazę do pliku). Te dwa polecenia uruchamiasz w katalogu domowym konta, nad public_html; wszystkie kolejne w tym artykule uruchamiasz już w katalogu strony, czyli tam, gdzie leży wp-config.php:

   tar -czf przed-aktualizacja-$(date +%F).tar.gz public_html/
   wp db export przed-aktualizacja-$(date +%F).sql --path=public_html

2. Zaktualizuj Bricksforge albo go wyłącz

   Bricksforge kupuje się u producenta, a nie w katalogu wordpress.org, więc aktualizacja zwykle wymaga aktywnego klucza licencyjnego wpisanego w ustawieniach wtyczki. Jeśli przycisk aktualizacji jest dostępny w Wtyczkach, użyj go. Jeśli licencja wygasła, a wykonawca nie odbiera telefonu, dezaktywuj wtyczkę. Część elementów strony (np. formularze) może przestać działać. To mniejsze zło niż otwarte drzwi.

   # wyłącza wtyczkę bez usuwania jej plików i ustawień
   wp plugin deactivate bricksforge

3. Zablokuj wykonywanie PHP w katalogu uploads

   W tym ataku złośliwy plik ląduje w katalogu na przesłane pliki. Jeśli serwer nie wykonuje tam PHP, wgrany plik pozostaje martwy. Na serwerze Apache utwórz w wp-content/uploads plik .htaccess z poniższą treścią (możesz to zrobić w menedżerze plików hostingu). Reguła odmawia dostępu do plików z rozszerzeniami PHP, także pisanymi wielkimi literami:

   <FilesMatch "(?i)\.(php\d?|phtml|phar|pht)$">
     Require all denied
   </FilesMatch>

   Na serwerze Nginx taka reguła trafia do konfiguracji serwera, więc poproś o nią hosting. Ta blokada to pas bezpieczeństwa, a nie zamiennik aktualizacji.

4. Poszukaj plików PHP w katalogu uploads

   W wp-content/uploads powinny być zdjęcia, PDF-y i podobne pliki. Plik PHP to prawie zawsze ślad włamania. Najpierw zajrzyj do katalogu wp-content/uploads/bricksforge/tmp/, bo tam według Patchstack trafiają pliki z tego ataku. Patchstack widział też pliki o nazwach login_admin_….php w katalogu z bieżącym miesiącem, np. wp-content/uploads/2026/10/. Potem przeszukaj cały katalog. Polecenie poniżej szuka plików z rozszerzeniem zaczynającym się od „ph” (łapie też .phtml, .php5 i .PHP) i wypisuje ich daty:

   find wp-content/uploads -type f -iname "*.ph*" -printf "%TY-%Tm-%Td %TH:%TM  %p\n"

   Tak wygląda wynik na naszej testowej instalacji, na której podłożyłem przykładowy plik:

   2026-10-08 03:12  wp-content/uploads/bricksforge/tmp/f3a9c1.php

   Data tuż po pierwszych wykrytych atakach i losowa nazwa to typowy obraz. Plik zaczyna się od nagłówka obrazka GIF, a dopiero po nim jest kod PHP. Dlatego program file uznaje go za obrazek:

   $ head -c 60 wp-content/uploads/bricksforge/tmp/f3a9c1.php
   GIF89a<?php /* plik testowy */ ?>
   
   $ file wp-content/uploads/bricksforge/tmp/f3a9c1.php
   wp-content/uploads/bricksforge/tmp/f3a9c1.php: GIF image data, version 89a, 16188 x 26736

   Prawdziwy plik atakującego ma w tym miejscu działający kod, a nie komentarz. Kod PHP może się też ukrywać w plikach z rozszerzeniem obrazka. To polecenie wypisze każdy plik w uploads, który zawiera znacznik otwierający PHP:

   grep -rlE "<\?php|<\?=" wp-content/uploads

   Bez terminala: otwórz menedżer plików w panelu hostingu, wejdź do wp-content/uploads i użyj wyszukiwarki plików, jeśli panel ją ma (szukaj „.php”). Wtyczka bezpieczeństwa ze skanerem plików też zgłosi pliki PHP w uploads. Nie usuwaj znalezisk od razu: zanotuj nazwę, datę i rozmiar, a plik pobierz do kopii jako dowód.

5. Sprawdź listę administratorów

   Po wejściu na serwer atakujący zwykle zakłada sobie konto administratora, żeby mieć drugie wejście. W panelu wejdź w Użytkownicy i kliknij filtr Administrator. Każde konto, którego nie znasz, jest podejrzane, szczególnie z nazwą udającą wsparcie techniczne i adresem e-mail spoza Twojej firmy.

   # lista administratorów z datą założenia konta
   wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

6. Zajrzyj do wtyczek Must-Use

   Wtyczki Must-Use to pliki w katalogu wp-content/mu-plugins, które WordPress uruchamia zawsze, bez aktywowania. Nie widać ich na zwykłej liście wtyczek i nie da się ich wyłączyć z panelu, dlatego włamywacze chętnie zostawiają w nich tylne furtki. W Wtyczkach kliknij zakładkę Wymuszane (w wersji angielskiej Must-Use; pojawia się tylko wtedy, gdy taki plik istnieje). Hostingi i wtyczki cache też tu coś zapisują, więc sprawdź pochodzenie każdego pliku.

   wp plugin list --status=must-use
   ls -la wp-content/mu-plugins

7. Przejrzyj logi serwera

   Logi dostępu (access log) to zapis każdego żądania do strony. Pobierzesz je z panelu hostingu albo poprosisz o nie obsługę. Szukaj odwołań do adresów używanych w ataku, od 7 października 2026. Polecenie poniżej przeszukuje bieżący log i spakowane starsze logi:

   zgrep -E "bricksforge/v1/form_submit|bricksforge_form_submit|bricksforge_regenerate_nonce" access.log*

   Samo trafienie oznacza próbę ataku, nie udany atak. Ważniejsze jest, czy później ktoś otwierał pliki PHP w katalogu uploads, bo to oznacza uruchamianie wgranego kodu:

   zgrep -iE "/wp-content/uploads/.*\.ph(p[0-9]?|tml|ar|t)" access.log*

   Uwaga na jedną pułapkę: log zapisuje adres, ale nie treść formularza. Żądanie do admin-ajax.php zobaczysz w logu, ale nazwę akcji tylko wtedy, gdy była w adresie. Brak trafień nie jest więc dowodem, że ataku nie było.

8. Sprawdź pliki zmienione od 7 października

   Włamywacz rzadko poprzestaje na jednym pliku. To polecenie wypisze pliki PHP zmienione od dnia pierwszych ataków, posortowane po dacie:

   find . -type f -name "*.php" -newermt "2026-10-07" -printf "%TY-%Tm-%Td %TH:%TM  %p\n" | sort

   Pliki z Twoich aktualizacji też tu będą. Szukaj tych, których nie potrafisz wyjaśnić: zmian w wp-config.php, index.php, functions.php motywu, nowych katalogów w wp-content/plugins. Pliki rdzenia porównasz z oryginałem poleceniem wp core verify-checksums. Wtyczek płatnych, takich jak Bricksforge, w ten sposób nie sprawdzisz, bo WordPress.org nie zna ich sum kontrolnych.

Dlaczego sama aktualizacja nie wystarczy

Aktualizacja usuwa błąd w kodzie wtyczki. Nie usuwa niczego, co atakujący zdążył dopisać do serwera. Jeśli boty trafiły na Twoją stronę między 7 października a dniem aktualizacji, mogły zostawić trzy rodzaje śladów:

• Webshell w katalogu uploads albo w podkatalogu wtyczki. Działa niezależnie od tego, czy luka jest załatana.
• Konto administratora, które pozwala wrócić przez normalny ekran logowania.
• Kod w innych plikach lub w bazie danych: przekierowania, spam w Google, a czasem skrypt pokazujący odwiedzającym fałszywą weryfikację. Taki atak opisuję w artykule Fałszywa CAPTCHA na mojej stronie.

Jeśli czytasz to przy innej luce

Za kilka miesięcy podobny komunikat pojawi się przy innej wtyczce. Procedura jest ta sama, zmieniają się tylko szczegóły.

Pełną listę sygnałów, po których rozpoznasz przejętą stronę, znajdziesz w artykule Jak sprawdzić, czy strona została zhakowana.

Jak się zabezpieczyć na przyszłość

Od ogłoszenia luki do pierwszych ataków mijają dziś godziny, nie tygodnie. Ręczne aktualizacje „raz w miesiącu” przestają wystarczać.

• Automatyczne aktualizacje wtyczek. Włączysz je na liście wtyczek, w kolumnie automatycznych aktualizacji. Przy wtyczkach płatnych działają tylko z aktywną licencją, więc pilnuj jej odnawiania albo zrezygnuj z dodatku. Od WordPressa 6.6 nieudana automatyczna aktualizacja wtyczki, która powoduje błąd krytyczny, jest cofana automatycznie.
• Mniej wtyczek. Usuń te, których nie używasz, także nieaktywne.
• Zapora aplikacyjna (WAF). Filtr ruchu przed WordPressem, który potrafi blokować znane ataki, zanim zdążysz zaktualizować wtyczkę. Oferują ją niektóre wtyczki bezpieczeństwa, usługi CDN i część hostingów.
• Blokada PHP w uploads na stałe, jak w kroku 3.
• Monitoring zmian plików. Alarm, gdy na serwerze pojawi się nowy plik PHP, skraca czas od włamania do reakcji z tygodni do godzin.
• Wyłączona edycja plików w panelu. Linia define('DISALLOW_FILE_EDIT', true); w wp-config.php odbiera edytor kodu każdemu, kto przejmie konto administratora. Opis tej i innych zasad jest w dokumentacji Hardening WordPress.

Kiedy nie robić tego samemu

Aktualizację wtyczki i sprawdzenie listy administratorów zrobi każdy właściciel strony. Przegląd logów i czyszczenie po włamaniu wymagają już wprawy. Oddaj to specjaliście, gdy:

• znalazłeś plik PHP w uploads, obce konto albo nieznaną wtyczkę Must-Use,
• strona to sklep z danymi klientów i nie wiesz, czy atakujący miał do nich dostęp,
• nie masz dostępu do licencji Bricksforge ani kontaktu z wykonawcą strony,
• hosting zablokował konto albo przysłał ostrzeżenie o złośliwych plikach (zobacz co zrobić, gdy hosting zablokował stronę).

Koszty takich prac opisuję w artykule Ile kosztuje usunięcie wirusa ze strony.

Najczęstsze pytania