MyHome Core CVE-2026-15980: krytyczne obejście logowania przez aktywację konta

CVE-2026-15980 trafiło do NVD 30 sierpnia z oceną CVSS 3.1: 9,8 (Critical). Luka dotyczy MyHome Core, komponentu komercyjnego motywu nieruchomościowego MyHome dla WordPressa, we wszystkich wersjach do 4.4.5 włącznie. W określonej konfiguracji nieuwierzytelniony napastnik może uzyskać token aktywacyjny niepotwierdzonego konta, a następnie ważne cookie logowania do tego konta — również wtedy, gdy jest to konto administratora.

Mechanizm łączy dwa błędy: brak wymaganej autoryzacji w handlerze AJAX send_link() oraz niewłaściwą walidację tokenu w activate(). Atak wymaga jednak konkretnych warunków: motyw działa w starszym trybie legacy/WPBakery, włączono rejestrację użytkowników od frontendu i potwierdzanie adresu e-mail, a konto celu nie ma jeszcze ustawionej metadanej myhome_agent_confirmed.

To rozróżnienie jest kluczowe. Rekord CVE nie mówi, że każda witryna z motywem MyHome może zostać automatycznie przejęta. Mówi, że witryna z podatną wersją i osiągalnym przepływem aktywacji może oddać sesję dowolnego niepotwierdzonego konta. Organizacje powinny więc sprawdzić zarówno wersję, jak i stan funkcji oraz kont.

Dlaczego przepływ aktywacji jest częścią uwierzytelniania

Zespoły często traktują wysłanie linku aktywacyjnego jako funkcję pomocniczą poczty. W rzeczywistości jest to element protokołu potwierdzającego kontrolę nad tożsamością. Endpoint generujący lub ponownie wysyłający token musi ustalić, kto może poprosić o operację, dla którego konta oraz czy token zostanie dostarczony wyłącznie na zweryfikowany wcześniej kanał.

Druga granica znajduje się w endpointcie konsumującym token. activate() powinno wiązać losowy, jednorazowy, wygasający sekret z konkretnym użytkownikiem i celem operacji. Powinno porównywać token w sposób odporny na wycieki czasowe, odrzucać ponowne użycie i dopiero po sukcesie zmieniać stan konta. Sam fakt, że klient dostarczył wartość przypominającą token, nie może wystarczać do wydania cookie uwierzytelniającego.

CVE pokazuje, co dzieje się, gdy oba końce procesu są zbyt ufne. Nieuwierzytelniony klient dociera do funkcji związanej z linkiem aktywacyjnym, a funkcja aktywująca nie egzekwuje poprawnie dowodu. Końcowym zasobem nie jest „status potwierdzenia e-mail”, tylko pełna sesja WordPressa z rolą już przypisaną do wybranego konta.

Warunki wykorzystania i realny blast radius

Pierwszym warunkiem jest MyHome Core w wersji 4.4.5 lub starszej. Nie wystarczy sprawdzić numeru motywu nadrzędnego w panelu. Wtyczka lub komponent core może mieć osobny cykl aktualizacji, a kopia aktywna w systemie plików może różnić się od pakietu zapisanego w repozytorium wdrożeniowym.

Drugim warunkiem jest tryb legacy/WPBakery. Instalacje korzystające z innego przepływu rejestracji mogą nie udostępniać podatnej kombinacji handlerów. Trzecim są rejestracja frontowa i potwierdzanie e-mail. Czwartym — niepotwierdzone konto celu, czyli brak myhome_agent_confirmed.

Najpoważniejszy scenariusz dotyczy administratora w stanie niepotwierdzonym. Może to być konto utworzone podczas migracji, konto zapasowe, użytkownik dodany ręcznie przed ukończeniem onboardingu albo pozostałość po testach. Po przejęciu administratora napastnik może instalować lub zmieniać wtyczki i motywy, tworzyć konta, odczytywać dane klientów, zmieniać treści i ustanawiać trwałość.

Przejęcie konta o niższej roli również jest istotne. W serwisie nieruchomościowym agent może mieć dostęp do leadów, danych kontaktowych, ofert niepublicznych, wiadomości i plików. Dalszy wpływ zależy od dodatkowych wtyczek, integracji CRM, uprawnień roli oraz tego, czy panel przechowuje sekrety usług zewnętrznych.

Co dokładnie potwierdzić dziś

Zacznij od inwentaryzacji wszystkich witryn, środowisk stagingowych, kopii demonstracyjnych i domen zapasowych. Staging bywa słabiej chroniony, ale korzysta z tej samej bazy lub poświadczeń. Ustal wersję MyHome Core z panelu, systemu plików, manifestu paczki oraz skanera integralności. Jeśli źródła się różnią, za obowiązującą uznaj wersję kodu wykonywanego przez PHP.

Sprawdź, czy WordPress zezwala na rejestrację, czy MyHome udostępnia formularz frontowy, czy wymagane jest potwierdzanie e-mail i czy aktywny jest wariant legacy/WPBakery. Następnie bez ujawniania danych w raporcie policz niepotwierdzone konta oraz ich role. Sama lista loginów i adresów e-mail powinna być traktowana jak dane wrażliwe.

Zweryfikuj ekspozycję endpointów AJAX na CDN, WAF i reverse proxy. Nie polegaj wyłącznie na tym, że ścieżka nazywa się admin-ajax.php: WordPress celowo udostępnia część akcji AJAX użytkownikom niezalogowanym. O bezpieczeństwie decyduje callback i jego kontrole, nie nazwa wspólnego endpointu.

Aktualizacja i działania tymczasowe

Priorytetem jest zainstalowanie wersji dostawcy, która jawnie usuwa CVE-2026-15980. W chwili przygotowania wpisu rekord CVE potwierdza zakres do 4.4.5, ale nie wskazuje wprost numeru wydania naprawczego. Nie zakładaj więc, że dowolny pakiet z wyższym numerem automatycznie zawiera poprawkę. Sprawdź changelog, advisory dostawcy lub informację w kanale wsparcia, wykonaj kopię i przetestuj przepływ rejestracji po wdrożeniu.

Do czasu potwierdzonej aktualizacji wyłącz rejestrację od frontendu i potwierdzanie przez podatny mechanizm, jeżeli biznes może czasowo pracować bez tej funkcji. Rozważ dezaktywację MyHome Core na publicznej witrynie lub przejście z trybu legacy, ale najpierw sprawdź wpływ na treść. Usuń lub wyłącz niepotwierdzone konta administracyjne, których organizacja nie potrzebuje.

WAF może tymczasowo ograniczyć nieuwierzytelnione wywołania konkretnej akcji związanej z send_link, lecz regułę trzeba przetestować z prawidłowym onboardingiem. Blokada wspólnego admin-ajax.php może uszkodzić inne funkcje i nie jest rozsądnym rozwiązaniem. Rate limiting zmniejsza automatyzację, ale nie naprawia błędu logicznego, jeśli pojedynczy poprawnie zbudowany przepływ wystarcza.

Retest bez ryzyka dla użytkowników

Po aktualizacji utwórz wyłącznie dedykowane konto testowe o minimalnej roli. Sprawdź, że prośba o token nie może wskazać innego użytkownika, token trafia na właściwy kanał, jest losowy i wygasa, a jego użycie po raz drugi kończy się odmową. Próba aktywacji z wartością zmienioną o jeden znak również musi zostać odrzucona bez wydania cookie.

Potwierdź, że sesja po prawidłowej aktywacji należy do dokładnie tego konta i ma oczekiwaną rolę. Nie testuj na prawdziwym administratorze ani kliencie. Test powinien również objąć wyłączoną rejestrację, brak potwierdzenia e-mail, tryb spoza legacy i bezpośrednie wywołanie endpointu bez wymaganych parametrów.

Detekcja i reakcja na możliwe przejęcie

Przejrzyj żądania AJAX związane z wysyłaniem linku i aktywacją, zwłaszcza serie dla różnych identyfikatorów kont, odpowiedzi zakończone natychmiastowym utworzeniem sesji i żądania z adresów, które nie uczestniczyły wcześniej w rejestracji. Koreluj je z wysłanymi wiadomościami e-mail, logami dostawcy poczty i zdarzeniami logowania.

Szukaj sesji utworzonych dla niepotwierdzonego wcześniej użytkownika bez odpowiadającego kliknięcia z dostarczonego linku. Dla administratorów sprawdź instalacje wtyczek, zmiany plików, nowe konta, modyfikacje ról, edycje opcji, tworzenie application passwords i nietypowe eksporty. Pliki PHP zmienione po podejrzanym logowaniu mogą oznaczać trwałość wykraczającą poza cookie.

Jeżeli nie można wykluczyć przejęcia konta uprzywilejowanego, unieważnij wszystkie sesje WordPressa, zresetuj hasła i application passwords, obróć salts oraz sekrety dostępne w panelu, a pliki porównaj z zaufanymi paczkami. Sprawdź bazę pod kątem nowych administratorów, zaplanowanych zadań i zmienionych opcji. Sama aktualizacja wtyczki nie usuwa backdoora pozostawionego wcześniej.

Lekcja projektowa dla WordPressa i innych systemów

Token aktywacyjny, reset hasła, magic link i kod zaproszenia są poświadczeniami. Każdy powinien mieć wysoką entropię, krótki czas życia, pojedyncze użycie, powiązanie z użytkownikiem i celem oraz pełny audyt. Endpoint generujący token nie może pozwalać anonimowemu klientowi wybierać dowolnego celu bez dodatkowego dowodu.

Cookie powinno być wydawane dopiero po atomowym przejściu ze stanu „oczekuje” do „potwierdzony”. Rozproszenie tej decyzji między kilka callbacków zwiększa ryzyko race condition i niespójnych kontroli. Testy bezpieczeństwa muszą objąć cały graf stanów konta, a nie tylko formularz logowania.

Fakty źródłowe i wnioski Breachroad

Opis dwóch wadliwych funkcji, warunki konfiguracji, zakres wersji i CVSS pochodzą z rekordu CVE przygotowanego przez Wordfence jako CNA oraz z NVD. Scenariusze blast radius, telemetria, retest i działania reagowania są wnioskami Breachroad. Źródła nie informują o potwierdzonym aktywnym wykorzystywaniu CVE-2026-15980.

Źródła

Przepływy aktywacji są częścią granicy uwierzytelniania i warto uwzględniać je w szkoleniu deweloperów oraz administratorów. Breachroad prowadzi szkolenia z cyberbezpieczeństwa i pomaga weryfikować podobne scenariusze podczas testów penetracyjnych aplikacji webowych i API.