WooCommerce 11.2.2 – klienci nie mogą się zalogować po zmianie kluczy bezpieczeństwa WordPressa

WooCommerce 11.2.2 – klienci nie mogą się zalogować po zmianie kluczy bezpieczeństwa WordPressa

W WooCommerce 11.2.2 wykryto poważny błąd związany z obsługą sesji klientów po zmianie kluczy bezpieczeństwa WordPressa. W określonych warunkach użytkownik nie może zalogować się do swojego konta, mimo że wpisuje prawidłową nazwę użytkownika i hasło. Formularz logowania jedynie odświeża stronę, pole hasła zostaje wyczyszczone, a klient nadal pozostaje wylogowany.

Problem został szczegółowo zgłoszony 7 listopada 2026 roku w oficjalnym repozytorium WooCommerce na GitHubie pod numerem #70762. Autor odtworzył błąd na czystej instalacji WordPressa z aktywną wyłącznie wtyczką WooCommerce 11.2.2 oraz standardowym motywem Twenty Twenty-Five.

Przyczyną jest nieprawidłowa obsługa ciasteczek sesyjnych WooCommerce po zmianie kluczy bezpieczeństwa i wartości salts. Wcześniej utworzone ciasteczko przestaje przechodzić weryfikację integralności, ale WooCommerce nie usuwa go prawidłowo z przeglądarki ani z bieżącego żądania.

W rezultacie system generuje zmieniające się identyfikatory sesji, przez co token zabezpieczający formularz logowania nie przechodzi weryfikacji. Użytkownik nie otrzymuje przy tym żadnego komunikatu wyjaśniającego przyczynę problemu.

Jest to szczególnie istotne dla właścicieli sklepów WooCommerce, ponieważ problem może pojawić się po operacjach bezpieczeństwa wykonywanych przez administratora, dostawcę hostingu lub narzędzie zarządzające instalacją WordPressa.

Jak objawia się błąd logowania WooCommerce?

Najbardziej charakterystycznym objawem jest brak jakiegokolwiek komunikatu o błędzie.

Klient otwiera stronę Moje konto, wpisuje prawidłowy login i hasło, a następnie wybiera przycisk logowania.

Zamiast przekierowania do panelu klienta następuje zwykłe przeładowanie strony.

W zgłoszonym przypadku zaobserwowano następujące zachowanie:

• Klient wpisuje prawidłowe dane logowania.
• Po kliknięciu przycisku strona Moje konto zostaje odświeżona.
• Wpisana nazwa użytkownika pozostaje w formularzu.
• Pole hasła zostaje wyczyszczone.
• Użytkownik nadal pozostaje wylogowany.
• Nie pojawia się informacja o błędnym haśle ani nieprawidłowej sesji.
• W konsoli przeglądarki nie występuje charakterystyczny błąd JavaScript.
• Logi serwera mogą nie zawierać żadnego komunikatu wyjaśniającego nieudaną próbę.

Problem powtarza się przy kolejnych próbach. Nawet wielokrotne wpisywanie prawidłowego hasła nie przywraca dostępu do konta.

Dlaczego WooCommerce nie zgłasza błędnego hasła?

W analizowanym scenariuszu hasło w ogóle nie jest sprawdzane.

WooCommerce odrzuca formularz wcześniej, podczas weryfikacji tokenu bezpieczeństwa nonce.

Jeżeli token nie przejdzie weryfikacji, standardowy mechanizm logowania nie wywołuje funkcji odpowiedzialnej za uwierzytelnienie użytkownika.

W konsekwencji nie dochodzi do typowego błędu logowania, który WordPress mógłby zarejestrować jako nieprawidłowe hasło.

To również wyjaśnia, dlaczego resetowanie hasła nie musi rozwiązywać problemu. Przyczyną nie są dane uwierzytelniające klienta, lecz niespójny stan sesji.

Co wywołuje błąd? Zmiana kluczy AUTH_KEY i wartości salts

WordPress wykorzystuje specjalne klucze bezpieczeństwa i wartości salts, między innymi do zabezpieczania mechanizmów uwierzytelniania oraz weryfikacji podpisanych danych.

W konfiguracji WordPressa występują między innymi następujące stałe:

AUTH_KEY
SECURE_AUTH_KEY
LOGGED_IN_KEY
NONCE_KEY
AUTH_SALT
SECURE_AUTH_SALT
LOGGED_IN_SALT
NONCE_SALT

Ich wartości są zazwyczaj przechowywane w pliku wp-config.php, chociaż w niektórych środowiskach mogą być dostarczane przez konfigurację serwera.

Zmiana tych kluczy powoduje unieważnienie wcześniejszych danych uwierzytelniających opartych na starych wartościach.

Jest to normalne i pożądane działanie zabezpieczające. Dzięki temu można unieważnić wcześniejsze sesje użytkowników, na przykład po podejrzeniu naruszenia bezpieczeństwa witryny.

Problem w WooCommerce polega na tym, że niektóre ciasteczka sesyjne pozostawione po takiej zmianie nie są właściwie usuwane.

Kiedy klucze bezpieczeństwa mogą zostać zmienione?

Do zmiany kluczy może dojść w różnych okolicznościach:

• podczas planowanej rotacji kluczy bezpieczeństwa WordPressa;
• po wykryciu potencjalnego naruszenia bezpieczeństwa strony;
• po wykonaniu operacji zabezpieczających przez administratora;
• podczas automatycznej rotacji kluczy przez dostawcę hostingu;
• po zmianach konfiguracji środowiska WordPressa;
• podczas migracji, jeśli nowe środowisko otrzymuje inne wartości kluczy.

Sama zmiana kluczy nie jest nieprawidłową operacją. Problem wynika z tego, jak WooCommerce traktuje ciasteczka utworzone przed zmianą.

Odpowiednie zarządzanie kluczami, aktualizacjami i dostępem do panelu administracyjnego jest jednym z elementów zabezpieczania sklepu internetowego przed zagrożeniami.

Jak działa ciasteczko wp_woocommerce_session_?

WooCommerce wykorzystuje własne ciasteczka sesyjne do identyfikowania sesji kupujących.

Ich nazwy mają postać:

wp_woocommerce_session_*

Gwiazdka oznacza fragment nazwy zależny od konkretnej instalacji WordPressa.

Ciasteczko pozwala powiązać żądania przeglądarki z sesją WooCommerce, wykorzystywaną między innymi podczas obsługi koszyka i innych operacji zakupowych.

Jego integralność jest zabezpieczana podpisem wyliczanym z wykorzystaniem mechanizmów kryptograficznych WordPressa.

Po zmianie kluczy bezpieczeństwa poprzedni podpis przestaje być prawidłowy.

WooCommerce powinien rozpoznać taką sytuację i odpowiednio odrzucić nieaktualne ciasteczko.

W zgłoszonej wersji 11.2.2 nieprawidłowe ciasteczko może pozostać w bieżącym żądaniu, mimo że nie udało się go zweryfikować.

Dlaczego stare ciasteczko blokuje nowe logowanie?

Problem wynika z niespójności pomiędzy sprawdzaniem integralności ciasteczka a mechanizmem ustalającym, czy sesja istnieje.

Funkcja get_session_cookie() sprawdza poprawność podpisu ciasteczka.

Jeżeli podpis nie przechodzi weryfikacji, funkcja zwraca false.

Następnie init_session_cookie() traktuje takie żądanie jak żądanie bez prawidłowej sesji i generuje nowy identyfikator klienta.

Jednak przeglądarka nadal przesyła wcześniejsze ciasteczko, a jego wpis pozostaje dostępny w tablicy $_COOKIE.

Funkcja has_session() sprawdza obecność tego wpisu, a nie rezultat weryfikacji podpisu.

W efekcie system jednocześnie traktuje sesję jako nieprawidłową podczas inicjalizacji i jako istniejącą w innym fragmencie kodu.

Techniczna przyczyna błędu w class-wc-session-handler.php

Autor zgłoszenia wskazał plik:

wp-content/plugins/woocommerce/includes/class-wc-session-handler.php

Problem dotyczy kilku współpracujących mechanizmów.

1. Weryfikacja podpisu sesji

Funkcja:

get_session_cookie()

sprawdza ciasteczko sesyjne i weryfikuje jego podpis.

Po zmianie kluczy bezpieczeństwa wcześniejsze ciasteczko nie przechodzi tej kontroli.

2. Generowanie nowego identyfikatora klienta

Mechanizm:

init_session_cookie()

generuje nowy identyfikator sesji, ponieważ nie otrzymał prawidłowego ciasteczka.

W analizowanym przypadku są to tymczasowe identyfikatory rozpoczynające się od t_.

Identyfikator może zmieniać się przy kolejnych żądaniach.

3. Błędne rozpoznawanie istnienia sesji

Funkcja:

has_session()

sprawdza obecność wpisu w $_COOKIE.

Stare ciasteczko nadal tam istnieje, więc funkcja może zwrócić wynik wskazujący na obecność sesji.

4. Nieprawidłowy identyfikator wykorzystywany przez nonce

Mechanizm:

maybe_update_nonce_user_logged_out()

wykorzystuje identyfikator sesji WooCommerce podczas wyliczania tokenów nonce dla niezalogowanych użytkowników.

Jeżeli identyfikator zmienia się pomiędzy wyświetleniem formularza a przesłaniem danych, token wygenerowany przy otwarciu strony przestaje odpowiadać tokenowi weryfikowanemu podczas logowania.

5. Formularz logowania zostaje odrzucony

W pliku:

wp-content/plugins/woocommerce/includes/class-wc-form-handler.php

funkcja WC_Form_Handler::process_login() wymaga prawidłowego tokenu nonce.

W formularzu wykorzystywany jest między innymi identyfikator:

woocommerce-login

Jeżeli weryfikacja zakończy się niepowodzeniem, logowanie zostaje pominięte.

Nie dochodzi do wywołania wp_signon(), dlatego hasło klienta nie jest weryfikowane.

W rezultacie strona jedynie się odświeża, a użytkownik nie otrzymuje informacji o przyczynie niepowodzenia.

Dlaczego problem dotyczy niektórych klientów, a nie wszystkich?

Istotnym warunkiem jest posiadanie w przeglądarce ciasteczka sesyjnego utworzonego przed zmianą kluczy WordPressa.

W zgłoszeniu wskazano dwie grupy użytkowników szczególnie narażonych na problem.

Klienci niezalogowani, którzy wcześniej dodali produkty do koszyka

Klient może przeglądać sklep bez logowania i dodać produkt do koszyka.

WooCommerce tworzy wówczas sesję, z którą wiąże zawartość koszyka.

Jeżeli administrator zmieni klucze bezpieczeństwa, wcześniej utworzone ciasteczko traci prawidłowy podpis.

Przy kolejnej próbie zalogowania do konta klient napotyka opisany problem.

Klienci zalogowani przed zmianą kluczy

Druga grupa obejmuje użytkowników, którzy wcześniej byli zalogowani i posiadali sesję WooCommerce.

Zmiana kluczy WordPressa powoduje wylogowanie użytkownika, co samo w sobie jest oczekiwanym zachowaniem.

Problem pojawia się podczas ponownej próby zalogowania, jeżeli przeglądarka nadal przesyła wcześniejsze ciasteczko WooCommerce.

Kto nie powinien być dotknięty tym scenariuszem?

Według zgłoszenia problem nie występował u osób, które nie posiadały wcześniejszej sesji WooCommerce.

Dotyczy to między innymi nowych odwiedzających, którzy nie mają w przeglądarce nieaktualnego ciasteczka.

Dlatego ten sam użytkownik może nie być w stanie zalogować się w zwykłym oknie przeglądarki, ale prawidłowo zalogować się w nowym profilu przeglądarki lub oknie prywatnym.

Czy problem może również blokować rejestrację nowych klientów?

Tak. Autor zgłoszenia potwierdził analogiczne zachowanie formularza rejestracji na stronie Moje konto.

Formularz wykorzystuje własny token:

woocommerce-register

Przy obecności nieprawidłowego ciasteczka sesyjnego weryfikacja tego tokenu może kończyć się niepowodzeniem.

W rezultacie nowy klient może nie być w stanie utworzyć konta, mimo że poprawnie wypełnia wymagane pola.

Nie oznacza to jednak całkowitej niedostępności rejestracji w każdym sklepie WooCommerce.

Problem dotyczy konkretnego stanu sesji po zmianie kluczy bezpieczeństwa.

Czy odzyskiwanie hasła nadal działa?

W odtworzonym scenariuszu funkcja odzyskiwania hasła działała prawidłowo.

Wynika to z tego, że wykorzystuje inne nazwy akcji nonce, których nie dotyczy wskazany mechanizm modyfikacji identyfikatora użytkownika sesji WooCommerce.

Dlatego skuteczne zresetowanie hasła nie musi przywrócić możliwości logowania przez problematyczny formularz Moje konto.

Jeżeli użytkownik może odzyskać hasło, ale nie może się zalogować, warto zweryfikować stan jego sesji przed podejmowaniem kolejnych działań związanych z kontem.

Jak długo może utrzymywać się problem z logowaniem WooCommerce?

Autor zgłoszenia wskazał, że problem może utrzymywać się tak długo, jak długo przeglądarka przechowuje nieprawidłowe ciasteczko sesyjne.

W standardowej konfiguracji WooCommerce okres ważności sesji wynosi:

Okresy te mogą zostać zmienione przez odpowiednie filtry WooCommerce lub dodatkowe rozszerzenia.

W praktyce nieprawidłowy stan może więc utrzymywać się przez kilka dni, jeśli klient nie usunie ciasteczka lub nie zostanie ono zastąpione podczas innej operacji.

Domyślne okresy przechowywania sesji zostały również opisane w informacji technicznej WooCommerce dotyczącej zarządzania sesjami.

Jakie konsekwencje może mieć błąd logowania dla sprzedaży?

Utrata możliwości składania zamówień wymagających konta

Jeżeli sklep wymaga zalogowania przed zakupem, niedziałający formularz Moje konto może uniemożliwić klientowi rozpoczęcie lub zakończenie procedury zakupowej.

Dotyczy to szczególnie sklepów B2B, systemów sprzedaży dla zarejestrowanych klientów i platform oferujących produkty dostępne wyłącznie po zalogowaniu.

Nie oznacza to automatycznie, że standardowy checkout WooCommerce przestaje działać wszystkim klientom.

Problemy z dostępem do historii zamówień

Klient, który nie może zalogować się do konta, traci możliwość przeglądania historii zakupów, zapisanych adresów oraz funkcji dostępnych wyłącznie dla użytkowników zalogowanych.

Może to zwiększać liczbę zgłoszeń kierowanych do obsługi sklepu.

Nieudane rejestracje

Jeżeli problem występuje również w formularzu rejestracji, część nowych klientów może zrezygnować z utworzenia konta.

W sklepach wymagających rejestracji może to bezpośrednio ograniczać możliwość pozyskiwania zamówień.

Porzucanie zakupów

Użytkownik, który kilkukrotnie próbuje zalogować się bez żadnego komunikatu o błędzie, może uznać, że sklep nie działa prawidłowo.

Nieudane logowanie jest jedną z potencjalnych przeszkód w finalizacji zakupów. Znaczenie takich problemów dla konwersji i sposobów analizowania utraconych transakcji opisuje również artykuł Sklep internetowy i porzucone koszyki.

Nie przedstawiono jednak danych pozwalających określić, ile rzeczywistych zamówień zostało utraconych wskutek błędu #70762.

Jak sprawdzić, czy problem dotyczy WooCommerce 11.2.2?

Autor zgłoszenia odtworzył problem na następującym środowisku:

Autor wykorzystał także własną pomocniczą wtyczkę diagnostyczną w środowisku testowym, ale potwierdził odtworzenie problemu bez innych standardowych rozszerzeń.

Nie wykazano, że przyczyną jest motyw Twenty Twenty-Five, MariaDB, nginx albo konkretna wersja PHP.

Problem wynika z obsługi nieprawidłowego ciasteczka sesyjnego w kodzie WooCommerce.

Scenariusz testowy dla niezalogowanego klienta

Na kopii testowej sklepu można odtworzyć następującą sekwencję:

1. Otwórz stronę produktu w przeglądarce, w której użytkownik nie jest zalogowany.
2. Dodaj produkt do koszyka.
3. Sprawdź, czy WooCommerce utworzyło ciasteczko sesyjne.
4. Na środowisku testowym zmień klucze bezpieczeństwa WordPressa.
5. Nie usuwaj ciasteczek zapisanych w przeglądarce.
6. Otwórz stronę Moje konto.
7. Wpisz prawidłowy login i hasło klienta.
8. Spróbuj zalogować się.

W środowisku dotkniętym problemem strona zostaje odświeżona, a użytkownik nadal pozostaje wylogowany.

Nie należy przeprowadzać tego testu przez zmianę kluczy w działającym sklepie produkcyjnym. Taka operacja unieważnia aktywne sesje użytkowników i może wpłynąć na wszystkie aktualnie zalogowane osoby.

Scenariusz dla wcześniej zalogowanego użytkownika

Drugi test obejmuje użytkownika, który był zalogowany przed zmianą kluczy.

Po rotacji kluczy WordPress prawidłowo unieważnia dotychczasowe uwierzytelnienie.

Jednak przy ponownej próbie zalogowania przez Moje konto WooCommerce może odrzucać formularz ze względu na nieprawidłową sesję.

Autor potwierdził oba scenariusze na WooCommerce 11.2.2.

Jak naprawić logowanie WooCommerce bez zmiany hasła?

W zgłoszeniu potwierdzono skuteczny sposób przywrócenia logowania w przeglądarce dotkniętej problemem.

Polega on na usunięciu nieprawidłowego ciasteczka sesyjnego WooCommerce.

Usunięcie ciasteczka wp_woocommerce_session_

W narzędziach deweloperskich przeglądarki odszukaj sekcję przechowywania ciasteczek dla domeny sklepu.

Znajdź ciasteczko o nazwie rozpoczynającej się od:

wp_woocommerce_session_

Usuń odpowiedni wpis dla tej domeny.

Następnie odśwież stronę Moje konto i ponownie spróbuj zalogować się przy użyciu prawidłowych danych.

W testach autora usunięcie wyłącznie tego ciasteczka powodowało, że logowanie zaczynało działać już przy pierwszej kolejnej próbie.

Czy trzeba usuwać wszystkie ciasteczka przeglądarki?

Nie. W opisanym przypadku wystarczyło usunięcie ciasteczka sesyjnego WooCommerce.

Nie ma potrzeby czyszczenia całej historii przeglądania, wszystkich zapisanych haseł ani ciasteczek pochodzących z innych stron.

Jeżeli użytkownik nie posiada możliwości usunięcia pojedynczego ciasteczka, może skorzystać z funkcji usuwania danych konkretnej witryny.

Należy jednak pamiętać, że usuwanie danych witryny może również wyczyścić inne lokalnie zapisane informacje związane ze sklepem.

Test logowania w nowej sesji przeglądarki

Pomocnym testem diagnostycznym jest otwarcie strony sklepu w nowym profilu przeglądarki albo oknie prywatnym, które nie korzysta ze starego ciasteczka.

Jeżeli logowanie działa w nowej sesji, ale nie działa w dotychczasowym profilu, wskazuje to na możliwość problemu z lokalnie zapisanymi danymi.

Nie jest to jednak samodzielny dowód, że przyczyną jest dokładnie zgłoszenie #70762. Podobne objawy mogą powodować również błędy cache, inne rozszerzenia lub nieprawidłowa konfiguracja uwierzytelniania.

Jak administrator może potwierdzić przyczynę problemu?

Jeżeli problem występuje u wielu użytkowników po zmianie kluczy WordPressa, warto przeprowadzić diagnostykę w środowisku testowym.

Sprawdzenie identyfikatora sesji WooCommerce

Autor zgłoszenia wykorzystał między innymi następującą metodę:

WC()->session->get_session_cookie()

Pozwala ona sprawdzić, czy ciasteczko zostało poprawnie odczytane i zweryfikowane.

W zgłoszonym scenariuszu funkcja zwracała wynik wskazujący na nieprawidłową sesję, mimo że wpis ciasteczka pozostawał obecny w żądaniu.

Weryfikacja tokenu formularza logowania

Drugim elementem diagnostyki jest sprawdzenie poprawności nonce formularza:

wp_verify_nonce(
    $_POST['woocommerce-login-nonce'],
    'woocommerce-login'
)

Przykład przedstawia samą operację weryfikacji. W kodzie diagnostycznym należy wcześniej sprawdzić istnienie pola i odpowiednio przetworzyć jego wartość.

W analizowanym scenariuszu weryfikacja kończyła się niepowodzeniem, ponieważ identyfikator wykorzystywany do tworzenia nonce zmieniał się pomiędzy żądaniami.

Brak zdarzeń logowania WordPressa

Autor ustalił, że podczas nieudanej próby nie były wywoływane standardowe mechanizmy uwierzytelniania.

Nie występowały między innymi odpowiednie zdarzenia:

wp_authenticate
wp_login
wp_login_failed

To ważna wskazówka. Jeżeli formularz zostaje odrzucony przed uwierzytelnieniem, standardowe logi błędnych haseł nie muszą zawierać żadnego śladu próby.

Nie należy jednak włączać rozbudowanego debugowania ani zapisywania danych logowania w działającym sklepie bez odpowiednich zabezpieczeń.

Dlaczego WooCommerce nie usuwa nieprawidłowego ciasteczka?

W zgłoszeniu wskazano niespójność pomiędzy obsługą ciasteczka, które straciło ważność, a obsługą ciasteczka posiadającego nieprawidłowy podpis.

Jeżeli ciasteczko zostało prawidłowo podpisane, ale jest już przeterminowane, WooCommerce posiada mechanizm umożliwiający usunięcie nieaktualnej sesji.

Wykorzystywane są między innymi funkcje:

is_session_cookie_valid()
destroy_session()
forget_session()

Natomiast ciasteczko, którego podpis przestał być prawidłowy po zmianie kluczy bezpieczeństwa, nie przechodzi tej samej ścieżki czyszczenia.

To powoduje utrzymywanie się nieprawidłowego stanu.

Wcześniejsze ciasteczko pozostaje obecne, mimo że nie może już służyć do prawidłowej identyfikacji sesji.

Jaką poprawkę zaproponowano dla WooCommerce 11.2.2?

Autor zgłoszenia przygotował zmianę w pliku:

includes/class-wc-session-handler.php

Propozycja polega na wykrywaniu ciasteczka, które jest obecne w żądaniu, ale nie przechodzi weryfikacji integralności.

W takiej sytuacji WooCommerce powinien:

1. Rozpoznać obecność nieprawidłowego ciasteczka sesji.
2. Wysłać do przeglądarki polecenie jego wygaśnięcia.
3. Usunąć odpowiedni wpis z tablicy $_COOKIE podczas obsługi bieżącego żądania.
4. Przestać traktować nieprawidłowe ciasteczko jako istniejącą sesję.
5. Umożliwić prawidłowe wygenerowanie i weryfikację tokenu nonce.

Najważniejszą różnicą względem dotychczasowego działania jest usunięcie nieprawidłowego ciasteczka jeszcze podczas inicjalizacji sesji.

Dlaczego poprawka nie usuwa całego koszyka?

Autor zaproponował specjalną metodę usuwania wyłącznie nieprawidłowego ciasteczka.

Nie wykonuje ona automatycznego czyszczenia wszystkich danych sesyjnych i koszyka.

W analizowanym przypadku stare ciasteczko nie może już prawidłowo wskazać sesji, ponieważ jego podpis nie przechodzi weryfikacji.

Dlatego usunięcie takiego wpisu nie wymaga automatycznego usuwania danych wszystkich sesji zapisanych przez WooCommerce.

Wyniki testów proponowanego rozwiązania

Autor potwierdził, że po zastosowaniu zmiany:

• logowanie wcześniej niezalogowanego klienta działa przy pierwszej próbie;
• ponowne logowanie klienta wylogowanego wskutek rotacji kluczy działa prawidłowo;
• przeglądarka otrzymuje polecenie usunięcia nieprawidłowego ciasteczka;
• dodawanie produktów do koszyka nadal działa;
• prawidłowe sesje innych użytkowników nie są niepotrzebnie usuwane.

Poprawka została sprawdzona na WooCommerce 11.2.2.

Autor wskazał również, że ten sam problem występuje w aktualnej gałęzi rozwojowej WooCommerce z 7 listopada 2026 roku.

Czy WooCommerce opublikowało już oficjalną poprawkę?

Według stanu publicznego zgłoszenia z 8 listopada 2026 roku problem pozostaje otwarty.

Zgłoszenie otrzymało oznaczenie błędu dotyczącego kont klientów i zostało przypisane do dalszej obsługi przez zespół WooCommerce.

Przedstawiono szczegółową propozycję poprawki, ale nie potwierdzono jeszcze jej włączenia do stabilnego wydania.

Nie ma zatem podstaw, aby wskazywać konkretną nową wersję WooCommerce jako oficjalne rozwiązanie problemu.

Pełny opis techniczny, scenariusze odtworzenia i proponowane zmiany można sprawdzić w zgłoszeniu WooCommerce #70762 dotyczącym blokady logowania po zmianie kluczy bezpieczeństwa.

Czy należy przywrócić poprzednie klucze bezpieczeństwa WordPressa?

Nie jest to zalecany sposób naprawy.

Zmiana kluczy bezpieczeństwa może być działaniem podjętym w odpowiedzi na podejrzenie naruszenia bezpieczeństwa strony.

Przywrócenie wcześniejszych wartości mogłoby ponownie umożliwić wykorzystanie danych uwierzytelniających, które administrator zamierzał unieważnić.

Jeżeli rotacja została przeprowadzona z powodów bezpieczeństwa, należy zachować nowe klucze i rozwiązać problem z obsługą nieprawidłowych sesji.

Nie należy również ponownie zmieniać kluczy tylko po to, aby sprawdzić, czy logowanie zacznie działać. Taka operacja może unieważnić kolejne aktywne sesje.

Jak ograniczyć ryzyko problemów z logowaniem po operacjach serwerowych?

Po zmianach konfiguracji WordPressa, aktualizacjach i migracjach warto sprawdzić działanie najważniejszych funkcji sklepu z perspektywy klientów.

Szczególną uwagę należy zwrócić na:

• logowanie istniejących klientów;
• rejestrację nowych użytkowników;
• odzyskiwanie hasła;
• zachowanie koszyka podczas przechodzenia pomiędzy stronami;
• działanie formularza zamówienia;
• prawidłowe rozpoznawanie użytkownika po zalogowaniu;
• funkcje dostępne wyłącznie dla klientów posiadających konto.

Warto przeprowadzać testy zarówno w przeglądarce z wcześniej zapisaną sesją, jak i w nowym profilu bez ciasteczek.

W opisanym przypadku właśnie takie porównanie pozwoliło wykryć różnicę pomiędzy klientami posiadającymi stare ciasteczka a nowymi odwiedzającymi.

Jeżeli po aktualizacji lub migracji występują również błędy PHP Fatal Error, problemy z panelem administracyjnym albo niekompatybilne rozszerzenia, należy oddzielnie zweryfikować środowisko serwerowe. Różne przyczyny takich awarii opisuje artykuł WooCommerce nie działa po aktualizacji PHP – błędy wtyczek i problemy z kompatybilnością.

Nie należy jednak utożsamiać błędu sesji z niezgodnością wersji PHP. Zgłoszenie #70762 wskazuje konkretnie na mechanizm ciasteczek i tokenów nonce.

Dlaczego prawidłowa obsługa kont klientów jest ważna dla sprzedaży?

W sklepach internetowych konto klienta często pełni funkcję centralnego miejsca zarządzania zakupami.

Użytkownik może sprawdzać historię zamówień, aktualizować adresy, korzystać z zapisanych informacji oraz zarządzać usługami lub subskrypcjami.

Jeżeli sklep internetowy nie pozwala zalogować się do istniejącego konta, część tych funkcji staje się niedostępna.

W przypadku sklepów wymagających rejestracji może to również prowadzić do utraty możliwości złożenia zamówienia.

Dlatego po każdej istotnej zmianie konfiguracji bezpieczeństwa WordPressa należy sprawdzić zarówno działanie nowych sesji, jak i zachowanie przeglądarek, które przechowują wcześniejsze ciasteczka WooCommerce.

Najczęściej zadawane pytania o błąd logowania WooCommerce

Dlaczego WooCommerce odświeża stronę logowania bez komunikatu?

Jedną z możliwych przyczyn jest nieprawidłowa sesja po zmianie kluczy bezpieczeństwa WordPressa. Formularz może zostać odrzucony na etapie weryfikacji nonce, zanim system sprawdzi hasło użytkownika.

Czy problem występuje w WooCommerce 11.2.2?

Tak. Zgłoszenie #70762 zawiera powtarzalny scenariusz dla WooCommerce 11.2.2 oraz szczegółową analizę odpowiedzialnego mechanizmu.

Czy zmiana AUTH_KEY może wylogować klientów?

Tak. Zmiana kluczy bezpieczeństwa może unieważnić wcześniejsze dane uwierzytelniające. Jest to zamierzone działanie WordPressa. Problem polega na tym, że WooCommerce może nieprawidłowo obsługiwać pozostawione ciasteczko sesyjne podczas ponownego logowania.

Czy klient musi zmieniać hasło?

Nie, jeżeli przyczyną jest opisany błąd ciasteczka sesyjnego. W testach autora przywrócenie logowania nie wymagało zmiany hasła.

Czy usunięcie wp_woocommerce_session_ pomaga?

Tak. Autor potwierdził, że usunięcie odpowiedniego ciasteczka dla domeny sklepu przywraca logowanie przy kolejnej próbie.

Czy trzeba wyczyścić całą przeglądarkę?

Nie. W opisanym przypadku wystarczyło usunięcie konkretnego ciasteczka sesyjnego WooCommerce.

Czy problem występuje u wszystkich klientów?

Nie. Dotyczy przede wszystkim użytkowników, których przeglądarki przechowują ciasteczka sesyjne utworzone przed zmianą kluczy bezpieczeństwa.

Czy błąd dotyczy również rejestracji?

Tak. Autor potwierdził, że analogiczna nieprawidłowość może wystąpić podczas rejestrowania konta przez formularz Moje konto.

Czy resetowanie hasła działa?

W udokumentowanym scenariuszu funkcja odzyskiwania hasła działała prawidłowo. Nie oznacza to jednak, że zmiana hasła usuwa problem z nieprawidłową sesją.

Czy jest to luka umożliwiająca przejęcie konta?

Nie przedstawiono dowodów, że błąd #70762 umożliwia nieautoryzowane zalogowanie się na cudze konto. Zgłoszenie dotyczy odmowy prawidłowego logowania i rejestracji wskutek błędu obsługi sesji.

Czy wyłączenie WooCommerce rozwiąże problem?

Wyłączenie WooCommerce usuwa również funkcje sklepu, dlatego nie stanowi właściwej metody naprawy. Należy zidentyfikować i usunąć problem z nieprawidłowym ciasteczkiem albo zastosować oficjalną poprawkę, kiedy będzie dostępna.

Czy producent przygotował poprawkę?

Autor zgłoszenia przedstawił i przetestował propozycję zmiany w class-wc-session-handler.php. Według stanu z 8 listopada 2026 roku nie potwierdzono jeszcze jej opublikowania w stabilnym wydaniu WooCommerce.

Podsumowanie: stare ciasteczko może blokować logowanie mimo prawidłowego hasła

Problem WooCommerce #70762 dotyczy nieprawidłowej obsługi ciasteczek sesyjnych po zmianie kluczy bezpieczeństwa WordPressa.

Jeżeli klient posiada ciasteczko utworzone przed rotacją kluczy, WooCommerce 11.2.2 może błędnie rozpoznawać stan jego sesji.

W rezultacie identyfikator wykorzystywany do generowania tokenu nonce może zmieniać się pomiędzy żądaniami, a formularz Moje konto zostaje odrzucony przed sprawdzeniem hasła.

Najbardziej charakterystycznym objawem jest odświeżenie strony logowania bez jakiegokolwiek komunikatu błędu.

Autor potwierdził, że usunięcie nieprawidłowego ciasteczka wp_woocommerce_session_* przywraca możliwość logowania. Przedstawił również propozycję zmiany kodu, która automatycznie usuwa ciasteczka o nieprawidłowym podpisie.

Nie potwierdzono jeszcze oficjalnej poprawki producenta.

Właściciele sklepów WooCommerce powinni zwracać szczególną uwagę na działanie logowania i rejestracji po rotacji kluczy bezpieczeństwa, migracji środowiska lub zmianach konfiguracji sesji.

Jeżeli klient nie może zalogować się pomimo prawidłowego hasła, warto najpierw sprawdzić stan ciasteczek WooCommerce i poprawność tokenów formularza, zamiast automatycznie resetować hasło lub modyfikować konto użytkownika.