UpdraftCentral: skradzione klucze podpisały prawdziwe polecenia instalacji backdoorów. Bez CVE, a „wersja naprawiona” wymagała własnej poprawki

Nie zawsze trzeba łamać zabezpieczenia wtyczki. Wystarczy przejąć klucz, którym uprawniony panel zdalnego zarządzania podpisuje polecenia. Witryna sprawdzi podpis, uzna polecenie za autentyczne i je wykona. Tak było z częścią instalacji WordPress podłączonych do UpdraftCentral Cloud w dniach 18–19 października 2026: pojawiały się na nich nowe wtyczki z backdoorem, choć kod UpdraftPlus nie został podmieniony. CVE tu nie ma i nie będzie. Jest za to wersja „naprawcza”, której mechanizm odwołania kluczy trzeba było poprawić kilka godzin później. Dla VM to przypadek, w którym numer wersji mówi bardzo mało, a o narażeniu decyduje to, czy na witrynie leży klucz.

Mechanizm: poprawny podpis, niewłaściwy nadawca

Patchstack dobrze opisuje model zaufania. Po podłączeniu witryny do UpdraftCentral na witrynie powstaje para kluczy RSA i zapisuje się klucz publiczny panelu. Od tej chwili witryna wykonuje każde polecenie podpisane kluczem prywatnym panelu, z uprawnieniami użytkownika, który utworzył połączenie. Nikt nie zatwierdza pojedynczych poleceń. Klucze prywatne paneli są przechowywane w UpdraftCentral Cloud, więc bezpieczeństwo każdej podłączonej witryny opiera się na jednym założeniu: że te klucze nie wyciekną.

Napastnik wysyłał podpisane polecenie plugin.upload_plugin i WordPress instalował dostarczoną wtyczkę zwykłym instalatorem. Według Patchstack i Nethemby pliki UpdraftPlus na zaatakowanych witrynach były identyczne z oficjalnym wydaniem, kryptografia działała prawidłowo, a ruch nie pochodził z infrastruktury producenta. Jeden z administratorów na forum WordPress.org opisał trzy witryny na jednym VPS, wszystkie z UpdraftPlus 1.26.11 i poprawnymi sumami kontrolnymi, a w logu UpdraftCentral wpis „Command received: plugin.upload_plugin”. Tego nie zatrzyma żadna łatka kodu. W tym sensie wtyczka zadziałała zgodnie z projektem.

Dlatego to nie jest zwykły finding „podatna wersja”. Bliżej mu do incydentów, w których zawodzi zaufany kanał dostawcy, jak przy AOMEI Backupper i AnyViewer albo Rank Math PRO. Tutaj zaufanym kanałem był panel zdalnego zarządzania, a nie aktualizacja.

Kto naprawdę jest narażony: klucz, nie wersja

UpdraftPlus ma ponad 4 mln aktywnych instalacji, ale to nie jest liczba ofiar. Warunkiem narażenia jest klucz UpdraftCentral zapisany na witrynie. Patchstack zwraca uwagę na dwie rzeczy, które ten warunek poszerzają:

• Klucz mógł powstać bez świadomej decyzji. Ekran łączenia witryny z kontem TeamUpdraft.com ma domyślnie zaznaczone pole „Add this website to UpdraftCentral”. Kto zostawił je zaznaczone przy logowaniu, ma klucz UpdraftCentral, nawet jeśli używa wtyczki tylko do kopii zapasowych.
• Klucze nie wygasają. Według Patchstack klucze wydane w listopadzie 2025 nadal działały w październiku 2026.

Wniosek dla inwentarza: pytanie „czy używamy UpdraftCentral?” zadane właścicielom witryn da zaniżony wynik. Lepiej sprawdzić technicznie, czy w opcjach WordPress istnieje updraft_central_localkeys. Patchstack podaje do tego polecenie WP-CLI. Usunięcie witryny z panelu UpdraftCentral nie wystarczy, bo istotny jest klucz zapisany na witrynie.

Wersje: dlaczego 1.26.12 to zły cel ticketu

Komunikat TeamUpdraft był kilka razy aktualizowany i w wersji z 20.10 nie jest spójny. W sekcji „What we have already done” mówi o 1.26.13 i 2.26.13, które rozłączają wszystkie połączenia UpdraftCentral utworzone przed 18.10, 22:00 BST. Aktualizacja z 20.10, 16:25 BST potwierdza, że to wydanie 1.26.13 / 2.26.13 z wieczoru 19.10 unieważniło stare klucze. Jednocześnie lista kroków dla użytkowników UpdraftCentral nadal mówi „Update UpdraftPlus to version 1.26.12 (free) or 2.26.12 (Premium) or later”. Changelog na WordPress.org wyjaśnia różnicę:

Szkic, na którym oparłem ten wpis, wskazywał 1.26.12 jako wersję awaryjną. Według changelogu odwołanie kluczy w 1.26.12 zostało poprawione w 1.26.13, więc ticket zamknięty na „≥ 1.26.12” może zamknąć się na wersji, która nie zrobiła tego, co miała. Czy 1.26.12 w ogóle nie odwoływała kluczy, czy robiła to tylko częściowo, changelog nie mówi: niepotwierdzone. Bezpieczny cel to 1.26.13 / 2.26.13 albo nowsza. Ta sama zasada co przy XZ Utils: liczy się wydanie, które faktycznie realizuje poprawkę, nie pierwsze, które ją zapowiada.

Druga rzecz: producent pisze, że jeśli ktoś usunął klucz i połączył witrynę ponownie, aktualizacja nie rozłączy jej drugi raz. To rozsądne, ale oznacza, że po aktualizacji nadal mogą istnieć nowe, ważne klucze. Ich zasadność trzeba potwierdzić osobno.

Co zostaje na przejętej witrynie

Aktualizacja odcina kanał, ale nie usuwa tego, co napastnik już zainstalował. Patchstack i administratorzy na forum opisują elementy, które ułatwiają przegląd:

• Wtyczki o zmiennych nazwach. Patchstack naliczył 99 różnych nazw, przeważnie losowych. Stały był opis wtyczki: „Small maintenance toolkit: keeps option storage tidy.”. Jedna nazwa, „Site Health Cache”, powtarzała się często. Na forum opisano też warianty ukrywające się na liście wtyczek. Szukaj więc po opisie i po dacie instalacji 18–19.10, nie tylko po nazwie, i sprawdź również mu-plugins.
• Konto udające Edytora. Backdoor tworzył konto z rolą Editor i dodatkowymi uprawnieniami manage_options oraz install_plugins. Przegląd samej listy administratorów go nie wykryje, trzeba sprawdzać uprawnienia. Logowanie odbywało się przez ustawienie ciasteczka, z pominięciem formularza, więc 2FA i limity logowań nie miały znaczenia. Konto zostaje po usunięciu wtyczki.
• Opcje w bazie. Patchstack wskazuje opcję kończącą się na _sync_token, a użytkownik forum opcję <slug>_uid i konto z adresem w domenie example.
• Ślady użycia. Patchstack odróżnia instalację od użycia: wywołanie backdoora zostawia w logach dostępu parametr z 32-znakowym tokenem. Część próbek miała błąd powodujący HTTP 500 przy każdym żądaniu i to po nim pierwsze ofiary zauważyły atak. Patchstack ostrzega, żeby takiej wtyczki nie naprawiać, tylko ją usunąć.

Kolejność ma znaczenie. Patchstack radzi najpierw usunąć klucz UpdraftCentral (inaczej napastnik może dostarczyć poprawioną wersję), a podejrzaną wtyczkę dezaktywować i przenieść poza katalog WWW, zamiast odinstalowywać ją z panelu, bo procedura deinstalacji kasuje własne ślady. Jeśli konto napastnika istnieje albo w logach jest ślad użycia, witrynę trzeba traktować jako w pełni przejętą: odtworzenie z kopii sprzed ataku, porównanie plików z czystą instalacją, rotacja haseł i sesji. Producent proponuje odtworzenie z kopii sprzed 17 października.

Kopie zapasowe: osobne kryterium zamknięcia

Ten incydent dotyka narzędzia do kopii zapasowych, więc łatwo przeoczyć, że po nim kopie mogą przestać działać:

• UpdraftVault: producent rozłączył wszystkie witryny. Kopie nie trafiają do Vault, dopóki ktoś ponownie nie połączy witryny. TeamUpdraft wprost zaleca potem ręczne uruchomienie kopii, żeby to potwierdzić.
• Zewnętrzne magazyny (Google Drive, Dropbox, S3): według producenta nienaruszone, ale jeśli witryna była dostępna przez UpdraftCentral, zaleca on ponowną autoryzację magazynu i zmianę kluczy dostępu. Napastnik z dostępem do witryny mógł widzieć jej konfigurację.
• UpdraftClone: stare klucze klientów przestały działać i trzeba rozesłać nowe.

Czy ktoś pobrał kopie zapasowe z zewnętrznych magazynów, ze źródeł nie wynika: niepotwierdzone. Kopia witryny WordPress zawiera bazę z danymi użytkowników, więc to pytanie warto zadać w analizie incydentu.

Ponowne podłączenie: producent i badacze mówią co innego

Lista kroków TeamUpdraft kończy się punktem „Reconnect the site to UpdraftCentral”. Patchstack pisze odwrotnie: „Do not reconnect until the vendor explains the cause”, a jeśli zdalne zarządzanie jest potrzebne, klucz należy założyć na koncie bez install_plugins. Według Patchstack na jednej z analizowanych witryn właśnie to zatrzymało atak. Producent nie opisał publicznie, jak klucze wyciekły z UpdraftCentral Cloud. Pisze tylko o zamknięciu drogi dostępu i naprawie „underlying weakness”. Moja rekomendacja dla środowisk o podwyższonym ryzyku: decyzję o ponownym podłączeniu podejmuje właściciel ryzyka, a nie administrator witryny, i to dopiero po zakończeniu analizy. Jeśli połączenie wraca, to na koncie z minimalnymi uprawnieniami.

Co powinien zrobić VE

1. Inwentarz: lista witryn z UpdraftPlus i, osobno, lista witryn z kluczem UpdraftCentral (opcja updraft_central_localkeys), sprawdzona technicznie, nie ankietą. W rejestrze oznacz źródło połączenia: Cloud czy self-hosted.
2. Odcięcie: usunięcie starych kluczy na każdej witrynie, logując się bezpośrednio do WordPressa, a nie przez UpdraftCentral. Do tego zmiana hasła konta TeamUpdraft i reset 2FA.
3. Wersja: UpdraftPlus ≥ 1.26.13 / 2.26.13, potwierdzona inwentarzem. Witryny poniżej 1.26.5 mają dodatkowo CVE-2026-10795.
4. Trwałość napastnika: przegląd wtyczek i mu-plugins z 18–19.10, kont z nietypowymi uprawnieniami (nie tylko administratorów), opcji w bazie i logów dostępu. Wynik zapisany przy każdej witrynie: „brak śladów”, „zainstalowano, nieużyte” albo „użyte, IR”.
5. Kopie zapasowe: ponowne połączenie Vault lub autoryzacja magazynu i ręczny test wykonania kopii. Zadanie VE zamyka się dopiero, gdy kopia się wykonała, a nie gdy zmieniono ustawienia.

Zadanie powiązałbym z incydentem i z właścicielem procesu odtwarzania danych, a w rejestrze dostawców dopisałbym pytanie do TeamUpdraft o przyczynę i zakres wycieku. Ten sam schemat, „załatane nie znaczy wyczyszczone”, opisywałem przy BeyondTrust Remote Support.

Powiązane na blogu

• AOMEI Backupper i AnyViewer — złośliwy kanał aktualizacji bez CVE i bez wersji do łatania
• Rank Math PRO CVE-2026-111862 — okno pobrania zamiast wersji
• BeyondTrust Remote Support CVE-2026-102764 — kiedy patch nie zamyka incydentu
• WordPress CVE-2026-87902 — kiedy czas do exploita jest krótszy niż SLA
• XZ Utils 5.8.4 — liczy się wydanie, które faktycznie realizuje poprawkę

Źródła

• TeamUpdraft — „TeamUpdraft security incident: What customers need to know” (19.10.2026, ostatnia aktualizacja 20.10.2026 16:25 BST) — teamupdraft.com
• Patchstack — „Stolen UpdraftCentral Keys Are Backdooring WordPress Sites” (Dave Jong, 19.10.2026; mechanizm, wskaźniki, zalecenia, oś czasu; analiza oparta na ustaleniach Nethemby) — patchstack.com
• WordPress.org — UpdraftPlus, changelog 1.26.12 i 1.26.13 (19.10.2026) — wordpress.org
• WordPress.org Support — zgłoszenie „Security vulnerability affecting UpdraftPlus 1.26.11” (przykłady administratorów, nie miara skali) — wordpress.org
• NVD — CVE-2026-10795 (UpdraftPlus ≤ 1.26.4, Wordfence, CVSS 3.1 8.1) — nvd.nist.gov
• CISA Known Exploited Vulnerabilities Catalog (wersja 2026.10.21, brak wpisów UpdraftPlus) — cisa.gov

Nota redakcyjna: wpis powstał na podstawie szkicu VMRT Radar z 20 października 2026 i został zweryfikowany ze źródłami pierwotnymi 20 października 2026 (ok. 19:00 CEST), a katalog CISA KEV sprawdziłem ponownie 22 października 2026 (wersja 2026.10.21, bez wpisów dla tego tematu). Źródła: komunikat TeamUpdraft w wersji z aktualizacją z 20.10.2026 16:25 BST, changelog UpdraftPlus z WordPress.org (1.26.12 i 1.26.13 z 19.10.2026), artykuł Patchstack z 19.10.2026, zgłoszenie na forum WordPress.org, rekord NVD API 2.0 dla CVE-2026-10795 oraz katalog CISA KEV w wersji 2026.10.21. Względem szkicu poprawiłem wersję docelową (1.26.13 / 2.26.13 zamiast 1.26.12, bo 1.26.13 poprawia odwołanie kluczy z 1.26.12) i opis konta napastnika (udaje Edytora, a nie administratora). Oryginalnej analizy Nethemby nie czytałem bezpośrednio, korzystam z jej streszczenia u Patchstack. Nie potwierdziłem: jak klucze wyciekły z UpdraftCentral Cloud, ilu witryn dotyczy atak, w jakiej strefie czasowej są godziny z telemetrii Patchstack, czy 1.26.12 w ogóle nie odwoływała kluczy, czy tylko częściowo, ani czy pobrano kopie zapasowe z zewnętrznych magazynów. Pięć kryteriów zamknięcia i rekomendacja dotycząca ponownego podłączenia to ocena autora, nie zalecenie producenta.