Luka w All-in-One WP Migration: 3 miliony stron wciąż bez łatki
Luka w All-in-One WP Migration: ponad 3 miliony stron wciąż bez łatki
Pod koniec sierpnia firma Wordfence ujawniła krytyczną lukę w All-in-One WP Migration and Backup — jednej z najpopularniejszych wtyczek do migracji i backupu WordPressa, zainstalowanej na ponad 5 milionach stron. Deweloper, ServMask, wypuścił poprawkę (wersja 7.110) 20 sierpnia. Problem w tym, że według danych z 3 września zaktualizowało się zaledwie około 35% instalacji — czyli ponad 3 miliony stron wciąż działają na podatnej wersji.
Luka (CVE-2026-19949) to tzw. second-order SQL injection — nie działa od razu, tylko czeka. Atakujący, bez logowania się do panelu, wysyła spreparowany trackback do publicznego wpisu. Dane trafiają do bazy i leżą tam nieszkodliwie, dopóki administrator nie wykona eksportu, a potem importu archiwum wtyczką — czyli standardowej operacji migracji albo backupu. Dopiero wtedy błąd w parsowaniu escapowanych cudzysłowów i ukośników podczas odtwarzania archiwum pozwala wstrzyknąć zapytanie SQL. Za jego pomocą atakujący może wyciągnąć tajny klucz importu wtyczki (ai1wm_secret_key), a następnie użyć go do zaimportowania własnego archiwum .wpress ze złośliwym kodem — co w praktyce daje pełne przejęcie strony.
To odróżnia tę lukę od typowych podatności „kliknij i już" — wymaga, żeby ktoś normalnie korzystał z wtyczki do tego, do czego jest zrobiona. Ale właśnie dlatego jest groźna: administrator migrujący albo backupujący stronę nie ma powodu podejrzewać, że rutynowa operacja może być momentem ataku. Do sieci trafił już działający kod proof-of-concept, więc ryzyko automatycznych, masowych prób wykorzystania rośnie z każdym dniem zwłoki w aktualizacji.
Jeśli używasz All-in-One WP Migration and Backup, sprawdź numer wersji w panelu wtyczek — podatne są wszystkie wydania do 7.109 włącznie. Aktualizacja do 7.110 lub nowszej usuwa problem. Warto też przejrzeć komentarze i trackbacki oczekujące na moderację pod kątem podejrzanych, nienaturalnych wpisów sprzed łatki — to typowy ślad przygotowania ataku tego typu. Jeśli nie korzystasz z trackbacków, ich wyłączenie w ustawieniach dyskusji zamyka ten wektor wejścia niezależnie od wersji wtyczki.
Szerzej to kolejny przykład tego, że bezpieczeństwo WordPressa nie kończy się na aktualizacji rdzenia — dobrze skonfigurowane zaplecze serwera nie zastąpi pilnowania aktualizacji wtyczek zainstalowanych w panelu WordPressa. W naszych testach hostingów codziennie sprawdzamy m.in. stan zaplecza serwera (cache, bazę danych, wydajność pod obciążeniem) — metodologię opisujemy na /jak-testujemy, a wyniki są widoczne w rankingu. Żaden hosting nie zaktualizuje jednak za administratora wtyczki zainstalowanej w panelu WordPressa — to wciąż zostaje po stronie właściciela strony.