Bricksforge CVE-2026-85097: luka jest atakowana, zaktualizuj Pro Forms

#Czy moja strona z Bricksforge jest podatna na CVE-2026-85097

Podatna jest każda instalacja Bricksforge w wersji 3.1.8.9 lub starszej. Tak podaje rekord CVE w NVD i wpis w bazie Wordfence. Atak nie wymaga logowania ani kliknięcia przez kogokolwiek z Twojej strony.

Pole uploadu w formularzu nie jest warunkiem. W changelogu producenta przy wersji 4.0.1 stoi wprost, że problem dotyczy każdej strony z aktywnym Pro Forms, także takiej, której formularze nie mają pól do wgrywania plików. Jeśli więc myślisz “u nas jest tylko formularz kontaktowy”, to nie zwalnia Cię z aktualizacji.

Ocena powagi różni się w zależności od źródła. Patchstack daje 10.0 i oznacza lukę jako znaną z wykorzystania (KEV). Wordfence i NVD podają 9.8 z wektorem CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Praktyczna różnica jest żadna: atak przez sieć, bez uprawnień, z pełnym wpływem na poufność, integralność i dostępność.

Bricksforge to wtyczka komercyjna. API katalogu WordPress.org zwraca dla niej “Plugin not found”. To ma znaczenie przy dwóch krokach niżej: aktualizacja przychodzi z licencji producenta, a nie z repozytorium, i wp plugin verify-checksums nie ma z czym porównać plików.

#Jak działa luka w formularzach Bricksforge Pro Forms

Opis w rekordzie CVE i analiza Patchstack składają się na trzy kroki:

1. Atakujący pobiera ważny nonce z akcji AJAX bricksforge_regenerate_nonce, która jest dostępna bez logowania.
2. Wgrywa plik, który jest jednocześnie poprawnym GIF-em i kodem PHP (tzw. poliglota). Sprawdzenie typu MIME przy pierwszym uploadzie przechodzi, bo plik naprawdę wygląda jak obraz. Trafia do katalogu tymczasowego.
3. Wysyła formularz z parametrem temporaryFileUploads, w którym ścieżka po stronie serwera wskazuje na zweryfikowany GIF, a pole url kończy się na .php. Wtyczka ufa metadanym przysłanym przez klienta i zapisuje treść pod adresem PHP.

Patchstack wskazuje dwa punkty wejścia: POST /wp-json/bricksforge/v1/form_submit oraz /wp-admin/admin-ajax.php z akcją bricksforge_form_submit. Kod, którego to dotyczy, siedzi w includes/elements/pro-forms/actions/init.php i base.php. Według rekordu CVE producent dostał zgłoszenie 3 września 2026, a ujawnienie nastąpiło 7 października. Znalazca to d.v4n_s3c.

#Jak sprawdzić wersję Bricksforge w wp-admin i przez WP-CLI

W kokpicie: Wtyczki, Zainstalowane wtyczki, wiersz Bricksforge, numer wersji pod opisem. Jeśli licencja wygasła, panel może nie pokazać dostępnej aktualizacji, choć ona istnieje. Brak powiadomienia nie oznacza, że jesteś na bieżącej wersji.

Przez SSH, na jednej stronie:

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

Na serwerze z wieloma instalacjami pętla po katalogach daje szybki spis:

for d in /var/www/*/public_html; do
  printf '%s ' "$d"
  wp --path="$d" plugin get bricksforge --field=version 2>/dev/null || echo "brak"
done

Ścieżki dopasuj do swojego hostingu. Na koncie współdzielonym zwykle jest to jeden katalog public_html albo domains/<domena>/public_html. Wynik 3.1.8.9 lub niższy oznacza: aktualizacja i kontrola z sekcji niżej.

#Do jakiej wersji zaktualizować Bricksforge: 3.1.8.10 czy 4.0.1

Źródła nie są tu spójne i warto to wiedzieć, zanim klikniesz “Aktualizuj”.

• Patchstack i Wordfence podają 3.1.8.10 jako wersję z poprawką.
• Changelog producenta na dzień 10 października 2026 nie ma wpisu 3.1.8.10. Pokazuje 3.1.8.9 (28 sierpnia), 4.0.0 (17 września) i 4.0.1 (8 października) z wpisem “Security fix for the Pro Forms file upload”.

Wniosek praktyczny: po aktualizacji wersja musi wynosić 3.1.8.10 albo 4.0.1 lub więcej. Jeśli stoisz na 4.0.0, przejdź na 4.0.1. Żadne z cytowanych źródeł nie mówi wprost, czy 4.0.0 jest podatne, ale producent wydał poprawkę uploadu właśnie w 4.0.1, więc nie ma powodu tam zostawać.

wp plugin update bricksforge
wp plugin get bricksforge --field=version

Jeśli WP-CLI nie widzi aktualizacji, pobierz paczkę z konta klienta u producenta i zainstaluj ją z pliku: wp plugin install /tmp/bricksforge.zip --force. Skok na 4.x to nowa wersja główna, więc na stronie z rozbudowanymi formularzami przejdź ją najpierw na stagingu, ale nie odkładaj tego na przyszły tydzień.

Jeśli nie możesz zaktualizować od razu, wyłącz wtyczkę (wp plugin deactivate bricksforge) albo zablokuj oba endpointy w WAF. Patchstack wdrożył dla swoich klientów regułę RapidMitigate dla tego CVE. Sam Patchstack traktuje ją jako rozwiązanie tymczasowe, nie zamiennik aktualizacji.

#Co sprawdzić, jeśli strona działała na Bricksforge 3.1.8.9 lub starszym

Aktualizacja zamyka drzwi. Nie usuwa tego, kto mógł już wejść. Data 7 października to pierwsza obserwacja w telemetrii Patchstack, a nie dowód, że nikt nie próbował wcześniej, więc przy kontroli przyjmij szersze okno, np. od 3 września, gdy producent dostał zgłoszenie.

#Nowe konta administratorów

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Porównaj z listą osób, które znasz. Konto założone w ostatnich tygodniach, z adresem w obcej domenie albo z loginem typu wp-support, to sygnał do pełnej analizy. Sprawdź też hasła aplikacji: wp user application-password list <ID> dla każdego administratora.

#Pliki PHP w katalogu uploads

W wp-content/uploads nie powinno być żadnego wykonywalnego PHP. Patchstack znajdował pliki o nazwach login_admin_*.php w /wp-content/uploads/bricksforge/tmp/ i /wp-content/uploads/2026/10/.

find wp-content/uploads -type f \( -iname '*.php*' -o -iname '*.phtml' -o -iname '*.phar' \) -ls
find wp-content/uploads -type f -name 'login_admin_*' -ls
ls -la wp-content/uploads/bricksforge/tmp/

Wzorzec *.php* łapie też .php5 i .PHP z inną wielkością liter. Patchstack opisuje warianty rozszerzeń, zmiany wielkości liter i kodowania w ładunkach, więc nie ograniczaj się do dokładnego .php. Zajrzyj również po pliki .htaccess w uploads, bo mogą przestawić obsługę innych rozszerzeń na PHP.

#Zmienione pliki rdzenia, motywów i wtyczek

wp core verify-checksums
find wp-content -type f -name '*.php' -newermt '2026-09-03' ! -path '*/cache/*' -ls

Rdzeń sprawdzisz sumami kontrolnymi. Bricksforge i Bricks nie są w katalogu WordPress.org, więc dla nich pobierz czystą paczkę od producenta i porównaj diff -r z katalogiem na serwerze. Szczególnie zajrzyj do wp-content/mu-plugins, bo kod tam ładuje się zawsze i nie widać go na liście wtyczek, oraz do wp-config.php.

#Zaplanowane zadania

wp cron event list --fields=hook,next_run_relative,recurrence
crontab -l

Obce hooki w WP-Cron albo wpis w crontabie użytkownika, który pobiera coś z zewnętrznego adresu, to typowy sposób na powrót po usunięciu webshella.

#Logi serwera

Szukaj żądań do endpointów z raportu Patchstack:

grep -E 'bricksforge/v1/form_submit|bricksforge_regenerate_nonce|bricksforge_form_submit' access.log*
zgrep -E 'bricksforge/v1/form_submit' access.log*.gz
grep -E '^(177\.75\.57\.20|23\.97\.62\.146|84\.247\.60\.125|38\.154\.185\.97|150\.109\.16\.166|153\.75\.90\.146) ' access.log*
grep -E 'GET /wp-content/uploads/.*\.php' access.log*

Sześć adresów to najaktywniejsze z 63 unikalnych IP, które Patchstack policzył w kampanii. Pamiętaj o ograniczeniu: zwykły log dostępu zapisuje tylko adres URL, a nazwa akcji AJAX często idzie w treści POST. Żądanie do admin-ajax.php może więc nie mieć w logu słowa “bricksforge”. Wtedy koreluj po IP i czasie, a najmocniejszy sygnał to udane GET do pliku .php w uploads z kodem 200.

#Kiedy przywracać stronę WordPress z kopii zapasowej

Gdy znajdziesz choć jeden plik PHP w uploads, którego nie umiesz wytłumaczyć, albo nieznane konto administratora, uznaj stronę za przejętą. Kod uruchomiony na serwerze miał dostęp do bazy, plików i wp-config.php. Ręczne usunięcie jednego pliku nie daje pewności, że to był jedyny.

Kolejność, która działa:

1. Zrób kopię obecnego stanu (pliki i baza) jako materiał dowodowy, zanim cokolwiek skasujesz.
2. Odtwórz pliki z kopii sprzed pierwszego podejrzanego wpisu w logach. Jeśli logi nie sięgają tak daleko, wybierz kopię sprzed 3 września i dopisz treść z późniejszego okresu ręcznie.
3. Zanim strona wróci do sieci, zaktualizuj Bricksforge do 3.1.8.10 albo 4.0.1. Przywrócona kopia ma starą, podatną wersję.
4. Zmień hasła do bazy, SFTP, wszystkich kont administratorów, wygeneruj nowe klucze w wp-config.php (wp config shuffle-salts) i unieważnij hasła aplikacji.

Formularze Pro Forms zwykle zbierają imiona, adresy e-mail i treść wiadomości. Jeśli atakujący miał dostęp do bazy, może to być naruszenie ochrony danych osobowych w rozumieniu art. 33 RODO, które zgłasza się do UODO w ciągu 72 godzin od jego stwierdzenia, chyba że jest mało prawdopodobne, by powodowało ryzyko dla osób, których dane dotyczą. Udokumentuj ustalenia, nawet jeśli finalnie zgłoszenie nie będzie potrzebne.

Jeśli kontrola nic nie wykazała, przywracanie nie jest potrzebne. Zostaw sobie zapis, co i kiedy sprawdziłeś.

#Czwarta luka w Bricksforge w 2026 roku

Lista w bazie Wordfence pokazuje wcześniejsze wpisy z tego samego roku: CVE-2026-14956 (do 3.1.8.6, eskalacja uprawnień bez logowania przez Pro Forms, 9.8), CVE-2026-18030 (do 3.1.8.7, eskalacja uprawnień bez logowania przez reset hasła, 9.8) i CVE-2026-84814 (do 3.1.8.8, eskalacja z roli subskrybenta, 6.3). Trzy z czterech dotyczą formularzy albo logiki logowania.

To nie powód, żeby w panice wyrzucać wtyczkę. To powód, żeby Bricksforge na stronach klientów był pozycją, którą ktoś sprawdza co tydzień, a nie raz na kwartał.

#Jak umowa serwisowa wyłapuje taką lukę

Luka z exploitem bez logowania daje kilka dni, a czasem godzin. Umowa na utrzymanie strony WordPress powinna pokrywać trzy rzeczy, które w tym przypadku decydują o wyniku:

• spis wtyczek i wersji dla każdej strony, także komercyjnych spoza WordPress.org, bo dla nich nie zadziała automatyczne powiadomienie z repozytorium,
• subskrypcję źródeł o podatnościach (Patchstack, Wordfence, NVD) dopasowaną do tego spisu, żeby alert o Bricksforge trafił do osoby, która wie, że go używasz,
• logi dostępu przechowywane dłużej niż kilka dni, bo bez nich pytanie “czy ktoś wszedł przed aktualizacją” nie ma odpowiedzi.

Jeśli nie wiesz, czy Twoja strona przeszła ten tydzień czysto, audyt bezpieczeństwa WordPress obejmuje dokładnie kroki z tej listy: uploads, konta, cron, sumy kontrolne i logi.

Ostatnia aktualizacja 10 października 2026. Źródła: artykuł i wpis w bazie Patchstack (7 i 8 października 2026), rekord Wordfence Intelligence, rekord CVE-2026-85097 w NVD, changelog Bricksforge, art. 33 RODO.