All-in-One WP Migration 7.110: luka CVE-2026-19949

Kopia zapasowa, która uruchamia atak

Wyobraź sobie sklep WooCommerce przenoszony między serwerami za pomocą All-in-One WP Migration. Ktoś bez konta zostawia dwa trackbacki pod publicznym wpisem, a strona nie pokazuje żadnego niepokojącego efektu. Dopiero późniejszy eksport i odtworzenie archiwum sprawiają, że zapisane dane stają się aktywnym poleceniem SQL.

Tak działa luka CVE-2026-19949. Pozwala ona przejść od anonimowego trackbacka do ujawnienia tajnego klucza importu, a następnie do wgrania dowolnego archiwum. Poprawka trafiła do wersji 7.110 już 20 sierpnia 2026 roku, lecz na początku września korzystała z niej tylko około jedna trzecia instalacji.

Co dokładnie naprawia wersja 7.110

Luka jest nieuwierzytelnionym wstrzyknięciem SQL drugiego rzędu, uruchamianym podczas odtwarzania archiwum. W przeciwieństwie do zwykłego ataku złośliwa treść nie wykonuje się w chwili wysłania. Najpierw zostaje zapisana w bazie i czeka, aż inny mechanizm odczyta ją oraz wykorzysta przy budowaniu zapytania.

Słabym punktem była funkcja odpowiedzialna za podmienianie wartości tabel podczas importu. Mechanizm musiał rozpoznawać granice tekstu ujętego w apostrofy, lecz przy parzystej liczbie ukośników błędnie oceniał, gdzie kończy się ciąg znaków. Wersja 7.110 poprawia zarówno rozpoznawanie tych granic, jak i sposób budowania zapytań.

• Podatne są wszystkie wydania do wersji 7.109 włącznie.
• NVD ocenia lukę na 8,8 punktu w skali CVSS i klasyfikuje ją jako CWE-89.
• Zgłoszenie trafiło do programu Wordfence Bug Bounty 14 sierpnia.
• Producent został powiadomiony 15 sierpnia, a poprawkę wydał 20 sierpnia.

Dlaczego dane zamieniają się w polecenie SQL

Atakujący wykorzystuje sposób zapisu komentarzy i późniejszego tworzenia archiwum. W nazwie bloga umieszcza ciąg zakończony ukośnikiem, a w adresie URL fragment polecenia SQL. WordPress zapisuje te wartości w tabeli komentarzy, nie usuwając ukośników.

Podczas eksportu do formatu .wpress końcowy ukośnik zostaje podwojony. To przesuwa granicę tekstu rozpoznawaną przez podatny mechanizm. Dane, które miały pozostać zwykłym ciągiem znaków, przy odtwarzaniu wypadają poza apostrofy i są interpretowane jako część zapytania do bazy.

To właśnie opóźnienie jest kluczowe. Zapisany trackback może przez wiele dni wyglądać jak zwykły spam. Samo wyłączenie wtyczki również nie usuwa ryzyka, jeśli dane już znalazły się w bazie. Po ponownym włączeniu i imporcie archiwum podatny kod znów może je przetworzyć.

Od dwóch trackbacków do przejęcia strony

Pełny mechanizm składa się z kilku kroków, które oglądane osobno nie muszą wzbudzić alarmu:

1. Atakujący wysyła dwa trackbacki do publicznego wpisu z włączoną obsługą pingów.
2. WordPress zapisuje przygotowane wartości w tabeli komentarzy bez potrzeby logowania.
3. Administrator wykonuje rutynowy eksport i import archiwum .wpress, na przykład podczas przenosin na serwer testowy.
4. Pierwszy ładunek przeciąża jeden krok importu, wymuszając przerwanie i zatwierdzenie transakcji.
5. Na granicy kroków wtyczka odświeża tajny klucz ai1wm_secret_key, a drugi ładunek odczytuje go i zapisuje w zatwierdzonym komentarzu.
6. Atakujący pobiera komentarz przez publiczny interfejs REST i wykorzystuje klucz do uruchomienia importu.

Przygotowane archiwum może zawierać wtyczkę typu must-use umieszczaną bezpośrednio w katalogu wp-content/mu-plugins. WordPress ładuje taki plik automatycznie przy każdym żądaniu, przed zwykłymi wtyczkami i bez ręcznej aktywacji. Nie można wyłączyć go w panelu — konieczne jest usunięcie pliku z serwera.

Ile instalacji pozostało bez poprawki

All-in-One WP Migration ma ponad 5 milionów aktywnych instalacji i 185 milionów pobrań. Według zestawienia BleepingComputer z 2 września na wersję 7.110 przeszło około 35 procent użytkowników. Oznaczało to, że około 65 procent, czyli blisko 3,25 miliona stron, nadal działało na podatnym wydaniu.

Oceny ryzyka różniły się między źródłami. Patchstack oznaczył priorytet jako średni mimo wysokiego wyniku CVSS, a wskaźnik EPSS wynosił 0,54 procent. Taka statystyka nie oznacza jednak braku realnych prób. Publicznie dostępny był już opis działania oraz uzbrojony wariant ataku.

Dlaczego zapora aplikacyjna może nie wystarczyć

Zapora aplikacyjna analizuje pojedyncze żądanie HTTP w chwili jego nadejścia. Trackback zawierający ukośnik i adres URL nie musi zawierać rozpoznawalnych poleceń charakterystycznych dla klasycznego wstrzyknięcia SQL, dlatego może wyglądać jak zwykły spam.

Złośliwa treść jest przy zapisie zabezpieczana i dopiero podczas późniejszego odtwarzania bazy odzyskuje formę, która zmienia znaczenie zapytania. Ten etap zachodzi wewnątrz aplikacji, poza pierwotnym ruchem HTTP. Z tego powodu jednorazowa analiza żądania może nie połączyć dostarczenia danych z ich wykonaniem wiele dni później.

Co oznaczał harmonogram Wordfence 1 września

Harmonogram Wordfence dobrze pokazuje różnicę między dodatkową osłoną a właściwą naprawą. Zgłoszenie i walidacja nastąpiły 14–15 sierpnia, reguła dla klientów Premium, Care i Response pojawiła się 16 sierpnia, a ServMask wydał wersję 7.110 cztery dni później.

Reguła dla bezpłatnej wersji Wordfence miała zostać udostępniona dopiero 15 września. Oznacza to, że 1 września 2026 roku użytkownicy Wordfence Free nie mieli jeszcze tej dedykowanej osłony. Zapora pozostaje dodatkową warstwą, ale jedyną pełną poprawką podatnego mechanizmu jest aktualizacja All-in-One WP Migration do wersji 7.110 lub nowszej.

Aktualizacja, trackbacki i porządek w plikach

Pierwszym krokiem jest aktualizacja do wersji 7.110 lub nowszej. Następnie warto usunąć nieużywane wtyczki i motywy, ponieważ sama dezaktywacja pozostawia ich pliki na serwerze. Jeżeli trackbacki i pingbacki nie są potrzebne, należy wyłączyć je w ustawieniach dyskusji oraz zablokować dostęp do punktu obsługującego trackbacki na poziomie serwera.

Trzeba również sprawdzić katalog wp-content/mu-plugins. WordPress automatycznie ładuje pliki PHP położone bezpośrednio w tym katalogu, nie pokazuje dla nich standardowych powiadomień o aktualizacji i nie oferuje zwykłego wyłącznika. Podejrzane są zwłaszcza nieznane pliki oraz nowe pliki PHP w katalogu wgrywanych materiałów.

• Ustaw edycję plików w panelu WordPress jako niedostępną.
• Stosuj uprawnienia 755 dla katalogów i 644 dla zwykłych plików oraz 400 lub 440 dla pliku konfiguracyjnego, jeśli środowisko na to pozwala.
• Wymagaj silnych haseł i drugiego składnika logowania od administratorów oraz kierowników sklepu.
• Przechowuj kopie poza serwerem i regularnie sprawdzaj możliwość ich odtworzenia.
• Monitoruj importy, nieudane logowania oraz zmiany integralności plików.

Dodatkowa ochrona sklepu WooCommerce

Przejęcie strony z WooCommerce oznacza ryzyko ingerencji w koszyk, płatności, konta klientów i dane zamówień. Dlatego poza usunięciem bezpośredniej podatności trzeba sprawdzić klucze interfejsu REST, zwłaszcza gdy sklep korzystał z integracji magazynowych lub rozwiązania bezgłowego. Nieużywane klucze należy unieważnić, a aktywne wymienić po potwierdzonym incydencie.

Warto obserwować skoki nieudanych zamówień, ograniczać tempo wywołań procesu składania zamówienia i stosować tokenizację płatności. Każda ochrona przed botami musi być jednak sprawdzona pod kątem zgodności z blokowym procesem zamówienia, płatnościami ekspresowymi i używanymi bramkami, aby zabezpieczenie nie zablokowało prawdziwych klientów.

Audyt strony działającej wcześniej na podatnej wersji

Jeśli witryna przed aktualizacją działała na wersji 7.109 lub starszej, sam montaż poprawki nie kończy pracy. W komentarzach należy wyszukać nietypowe ukośniki, cudzysłowy oraz ciąg ai1wm_secret_key. Pojawienie się tajnego klucza w treści komentarza oznacza, że złośliwy ładunek już się wykonał.

Audyt powinien objąć logi żądań wysyłanych do obsługi trackbacków i importu, tabelę ustawień, katalog wtyczek must-use, listę administratorów, nieznane archiwa .wpress oraz nowe pliki PHP w katalogu wgrywanych materiałów. Trzeba uwzględnić okres sprzed publicznego ujawnienia, ponieważ dostarczenie danych i ich wykonanie mogły być rozdzielone w czasie.

Po potwierdzonym wycieku należy potraktować zdarzenie jak naruszenie bezpieczeństwa: wymienić sekret wtyczki, klucze zabezpieczające WordPressa, hasła, sesje i klucze integracji. Bezpieczniejsza jest odbudowa z czystego źródła niż samo nadpisanie podejrzanych plików. Przez kolejne 30 dni warto monitorować logi oraz integralność plików.

Zostawić wtyczkę czy ją usunąć

All-in-One WP Migration można zostawić, jeśli regularnie służy do przenoszenia stron i format .wpress jest elementem ustalonego procesu. Warunkiem jest wersja 7.110 lub nowsza, wyłączone niepotrzebne trackbacki oraz uporządkowany katalog wtyczek must-use.

Jeśli migracje zdarzają się rzadko, rozsądniej ograniczyć wtyczkę do środowiska testowego, a na produkcji polegać na kopiach serwerowych i kontrolowanym repozytorium plików. Wtyczka migracyjna ma szeroki dostęp do bazy, więc błąd w odtwarzaniu danych może oznaczać przejęcie całej strony.

Aktualizacja zamyka podatny mechanizm, ale nie usuwa śladów wcześniejszego ataku. Dlatego poprawka jest początkiem działań, a nie ich końcem. O bezpieczeństwie decydują również kontrola komentarzy, przegląd mu-plugins, zamknięcie trackbacków i rzeczywiste monitorowanie importów.