Przejęte klucze UpdraftCentral: co sprawdzić na stronie WordPress z UpdraftPlus

Napastnik, który według producenta wtyczki miał w weekend 17–18 października 2026 dostęp do serwisu teamupdraft.com, wykorzystał wykradzione klucze UpdraftCentral Cloud do instalowania wtyczek-backdoorów i zakładania kont użytkowników na stronach WordPress z wtyczką UpdraftPlus – ostrzega CERT Polska w komunikacie 204/2026. Aktualizacja wtyczki odcina stare klucze (producent), ale według CERT Polska nie usuwa tego, co napastnik zdążył zostawić, dlatego każdą stronę trzeba sprawdzić ręcznie.

Co się stało

UpdraftPlus to wtyczka do kopii zapasowych WordPressa, według katalogu wtyczek wordpress.org aktywna na ponad 4 mln instalacji. To liczba wszystkich instalacji, a nie stron zagrożonych. Ryzyko dotyczy stron, które mają klucz UpdraftCentral, czyli połączenie z usługą zdalnego zarządzania wieloma stronami. Według analiz Patchstack i Nethemby klient UpdraftCentral jest w każdej kopii UpdraftPlus, ale pozostaje uśpiony, dopóki strona nie ma klucza. Strona z kluczem wykonuje polecenia podpisane kluczem prywatnym panelu bez potwierdzania pojedynczych operacji, więc kto ma ten klucz, może na przykład zainstalować na niej wtyczkę (Patchstack).

Patchstack podkreśla, że to nie jest luka w samym kodzie wtyczki, bo polecenia były podpisane prawdziwymi kluczami. TeamUpdraft, producent UpdraftPlus, w komunikacie o incydencie uważa, że napastnik miał dostęp do jego bazy klientów, w której były m.in. klucze połączeń UpdraftCentral. Producent twierdzi też, że wersja self-hosted UpdraftCentral (panel na własnym serwerze) nie jest dotknięta, a pliki wtyczki do pobrania nie zostały naruszone.

Pierwszą publiczną analizę kampanii opublikowała 19 października rano firma Nethemba, która w nocy z 18 na 19 października wykryła instalacje backdoorów na własnych stronach. Jeszcze 21 października Nethemba widziała kolejne próby wysyłania poleceń, już nieskuteczne, bo klucze były usunięte.

Skala ataku jest nieznana. Producent pisze, że jej zasięg nie jest znany, CERT Polska nie podaje liczby ofiar w Polsce, a Patchstack mówi ogólnie o szerokiej grupie stron i 99 różnych nazwach wtyczek-backdoorów w swojej telemetrii.

Która wersja UpdraftPlus jest bezpieczna

Zalecana jest wersja 1.26.13 (darmowa) lub 2.26.13 (Premium) albo nowsza – tak piszą CERT Polska, producent, WPSec i Nethemba. Darmowa wersja na wordpress.org ma dziś numer 1.26.14.

Na wersji 1.26.12 nie warto się zatrzymywać. Według opisu WPSEC-2026-1273 i Nethemby pierwsze awaryjne wydanie 1.26.12 / 2.26.12 przez błąd nie usuwało żadnego klucza, a producent pośrednio to przyznał w opisie zmian 1.26.13 („Properly apply the revocation in 1.26.12”). W repozytorium wtyczki na wordpress.org plik o numerze 1.26.12 został jeszcze 19 października podmieniony na poprawiony kod, więc ten sam numer może oznaczać zarówno wersję wadliwą, jak i poprawioną. Dla wersji Premium nie ma publicznej listy zmian, a daty wydań 2.26.12 i 2.26.13 znane są tylko z komunikatu producenta i od Nethemby.

Producent twierdzi, że WordPress.org rozesłał aktualizację wszystkim użytkownikom, ale nikt tego niezależnie nie potwierdził, a publiczne statystyki wordpress.org nie pokazują, ile stron ma już 1.26.13 lub nowszą. Numer wersji lepiej sprawdzić samodzielnie w kokpicie.

Wordfence w komunikacie z 19 października potwierdza, że wdrożył dla stron z Wordfence (w wersji darmowej z kilkugodzinnym opóźnieniem) awaryjną regułę zapory blokującą polecenia UpdraftCentral, ale obejmuje ona tylko wersje do 1.26.11 (darmowa) i starsze niż 2.26.12 (Premium). Nie chroni więc stron, na których działa wadliwe pierwotne wydanie 1.26.12. Zalecenia dotyczące wersji w tym komunikacie Wordfence nie zostały zaktualizowane i są nieaktualne, aktualne zalecenie to wersje podane wyżej.

Wersja 1.26.13 usuwa klucze UpdraftCentral Cloud utworzone przed 18 października, godz. 14:07 czasu polskiego (12:07 UTC) – wynika to z kodu wtyczki i od 22 października także z komunikatu producenta. Kluczy utworzonych później ani kluczy do wersji self-hosted nie rusza. Nethemba twierdzi, że zagrożone mogą być również klucze utworzone 18 października między 12:07 a 21:00 UTC (do 23:00 czasu polskiego). Producent tego nie potwierdził i nie wyjaśnił, dlaczego zmieniał tę granicę w swoim komunikacie. Producent, Patchstack i Nethemba i tak zalecają ręczne usunięcie klucza na każdej stronie, więc w praktyce najbezpieczniej usunąć wszystkie klucze UpdraftCentral, niezależnie od daty ich utworzenia.

Checklista dla właściciela strony

Polskie nazwy menu pochodzą z oficjalnego tłumaczenia wtyczki i WordPressa, w nawiasie podana jest wersja angielska.

1. Sprawdzić, czy strona ma klucz UpdraftCentral

Klucz można mieć bez świadomej decyzji. Według Patchstack i Nethemby pole „Dodaj tę stronę do UpdraftCentral…” przy logowaniu do konta teamupdraft.com we wtyczce było domyślnie zaznaczone, co potwierdza kod wtyczki. W darmowej wersji 1.26.14 nie jest już zaznaczone domyślnie.

Klucze są w menu Ustawienia → Kopia UpdraftPlus → karta „Narzędzia zaawansowane” → „UpdraftCentral” → „Zarządzaj istniejącymi kluczami” (Settings → UpdraftPlus Backups → Advanced Tools → UpdraftCentral → Manage existing keys). Producent apeluje do użytkowników Premium, żeby sprawdzili strony, nawet jeśli nigdy nie korzystali z UpdraftCentral. Według producenta użytkownicy darmowej wersji bez konta teamupdraft.com nie muszą nic robić.

2. Zaktualizować UpdraftPlus

Do wersji 1.26.13 (darmowa) lub 2.26.13 (Premium) albo nowszej. Producent zaleca logowanie się bezpośrednio do kokpitu strony, a nie przez panel UpdraftCentral.

3. Usunąć ręcznie wszystkie klucze UpdraftCentral

Przy każdym kluczu jest przycisk „Usuwanie…” (Delete…). Samo usunięcie strony z panelu UpdraftCentral nie wystarczy (CERT Polska), bo według Patchstack i Nethemby liczy się klucz zapisany na stronie. Według Patchstack i Nethemby kopie zapasowe działają dalej, przestaje działać tylko zdalne zarządzanie. Osoby korzystające z wiersza poleceń mogą sprawdzić i usunąć klucze poleceniami wp option get updraft_central_localkeys i wp option delete updraft_central_localkeys (Patchstack, Nethemba).

Nethemba radzi dodatkowo usunąć klucze Migratora (karta „Przenieś / Klonuj”), jeśli strona nie jest akurat przenoszona. Zaznacza przy tym, że nie widziała ich nadużycia.

4. Przejrzeć listę użytkowników

W menu Użytkownicy → Wszyscy użytkownicy trzeba szukać nie tylko obcych administratorów. Według Patchstack i Nethemby backdoor zakładał konto z rolą Redaktor (Editor), z dodatkowymi uprawnieniami manage_options i install_plugins, a producent też pisze o nieoczekiwanych kontach z rolą „editor”. Panel pokazuje rolę, ale nie dodatkowe uprawnienia – do ich sprawdzenia potrzebny jest wiersz poleceń albo pomoc firmy hostingowej.

Sygnały ostrzegawcze to nazwa wyświetlana „Site Tools”, adresy e-mail w domenie @example.org lub @example.com oraz loginy w stylu data-ops43 czy media-staff96 (Patchstack, Nethemba). CERT Polska podaje też loginy media.ops12, page_ops41 i content.desk38, ale nie wskazuje ich źródła i nie potwierdzili ich inni badacze. Wszystkie nazwy są przykładowe, napastnik je zmienia (Nethemba). Według Nethemby adresy @example.com bywają też fałszywym alarmem, bo boty zakładają takie konta klientów w sklepach internetowych.

Brak nowego konta niczego nie przesądza. Nethemba opisuje odmianę backdoora, która loguje napastnika jako istniejącego administratora i nie zostawia śladu w bazie.

5. Przejrzeć wtyczki, także te ukryte

W menu Wtyczki → Zainstalowane wtyczki warto sprawdzić również zakładkę „Wymuszane” (Must-Use). Podejrzane są nieznane wtyczki, na przykład o nazwie „Site Health Cache” lub z opisem „Small maintenance toolkit: keeps option storage tidy.” (Patchstack, Nethemba). Część backdoorów ukrywa się z listy w kokpicie, dlatego CERT i Nethemba zalecają sprawdzenie plików na serwerze. Komenda podana przez CERT przeszukuje tylko katalog wtyczek, więc lepiej przeszukać cały katalog wp-content/, np. grep -rl "Small maintenance toolkit" /ścieżka/wp-content/.

6. Sprawdzić dzienniki

We wtyczce jest „Wyświetl ostatnie zdarzenia dziennika UpdraftCentral” (View recent UpdraftCentral log events). Sygnałem ostrzegawczym jest wpis „Command received: plugin.upload_plugin” (CERT), a według Patchstack i Nethemby także „plugin.delete_plugin”. Nethemba zaznacza, że dziennik przechowuje tylko 50 ostatnich zdarzeń.

W logach serwera warto szukać adresów IP 43.250.53.42 i 2a09:bac5:4e21:2e3c::49b:9 (CERT, Patchstack, Nethemba) oraz zapytań z nagłówkiem User-Agent zawierającym class-udrpc.php bez numeru wersji i adresu – prawdziwy panel też wysyła tę nazwę, ale z wersją i adresem (Patchstack, Nethemba). Patchstack zaznacza, że napastnik zmieniał adresy, więc blokowanie IP nie jest zabezpieczeniem. Niespodziewane błędy 500 albo e-mail od WordPressa o błędzie nieznanej wtyczki to również sygnał do sprawdzenia strony (błędy 500: CERT; e-mail o błędzie wtyczki: Patchstack, Nethemba).

7. Po znalezieniu backdoora

Według Patchstack i Nethemby kolejność ma znaczenie. Najpierw trzeba usunąć klucz UpdraftCentral, bo inaczej napastnik może wgrać nową wtyczkę. Podejrzanej wtyczki nie należy naprawiać, bo naprawa ją uruchamia. Lepiej ją dezaktywować i przenieść poza katalog strony, zamiast odinstalowywać z kokpitu, bo deinstalacja zaciera ślady. Na koniec trzeba usunąć konto napastnika i zapisaną w bazie opcję kończącą się na _sync_token.

8. Przy potwierdzonym włamaniu

CERT Polska i producent zalecają przywrócenie strony z kopii zapasowej sprzed 17 października, zmianę haseł wszystkich administratorów oraz sprawdzenie plików i uprawnień. Patchstack radzi dodatkowo porównać pliki z czystą instalacją, zakończyć wszystkie aktywne sesje i włączyć logowanie dwuskładnikowe. Według Patchstack i Nethemby samo 2FA nie chroniło przed tym backdoorem, bo logował on napastnika z pominięciem formularza logowania.

9. Konto teamupdraft.com i zdalne magazyny kopii

Producent twierdzi, że napastnik miał prawdopodobnie dostęp do bazy klientów, w tym imion, adresów e-mail, adresów rozliczeniowych, historii zamówień, hashy haseł i ustawień 2FA. Danych kart płatniczych firma według własnych słów nie przechowuje. Producent zaleca zmianę hasła do konta (adres strony trzeba wpisać ręcznie, nie klikać linku z maila), zmianę tego hasła wszędzie tam, gdzie było użyte, oraz zresetowanie 2FA w „My Account”. Ostrzega też przed mailami podszywającymi się pod firmę i zaznacza, że nigdy nie prosi o hasła ani klucze.

Jeśli strona mogła być dostępna przez UpdraftCentral, producent zaleca ponowną autoryzację zdalnego magazynu kopii (Google Drive, Dropbox, S3) i zmianę kluczy dostępu, ponowne połączenie UpdraftVault z nowym hasłem oraz nowe klucze UpdraftClone.

10. Ponowne połączenie z UpdraftCentral

Tu zalecenia się rozchodzą. Producent każe na końcu ponownie połączyć stronę, a Patchstack radzi wstrzymać się, dopóki producent nie wyjaśni przyczyny włamania, i tworzyć klucz na koncie bez uprawnienia install_plugins. Kto nie potrzebuje zdalnego zarządzania, może po prostu nie łączyć strony. Przy logowaniu do konta teamupdraft.com we wtyczce warto sprawdzić, czy pole „Dodaj tę stronę do UpdraftCentral…” jest odznaczone.

CERT Polska zaznacza, że brak widocznych śladów nie gwarantuje, że strona nie została zaatakowana.

Czego nie wiadomo

Nie wiadomo, ile stron miało klucz UpdraftCentral Cloud, ile z nich zaatakowano ani ile jest w Polsce. Producent nie wyjaśnił, czym był „compromised key”, przez który napastnik dostał się do jego serwisu, ani jaką słabość naprawił. Nie wiadomo też, czy klucze utworzone 18 października po 12:07 UTC mogły trafić do napastnika, czy WordPress.org faktycznie zaktualizował wtyczkę na wszystkich stronach, skąd CERT ma podane loginy kont oraz czy wykradzione hashe haseł i sekrety 2FA zostały już użyte.