Nazwa wtyczki	Rewolucja suwaka
Rodzaj podatności	Złamana kontrola dostępu
Numer CVE	CVE-2026-9050
Pilność	Niski
Data publikacji CVE	2026-06-01
Adres URL źródła	CVE-2026-9050

Naruszenie kontroli dostępu w Slider Revolution (CVE-2026-9050) — Co właściciele stron WordPress muszą teraz zrobić

Autor: WP‑Firewall Laboratorium Bezpieczeństwa
Data: 2026-06-02

Streszczenie: W podatności na naruszenie kontroli dostępu w popularnej wtyczce Slider Revolution (dotyczącej wersji 6.0.0–6.7.55 i 7.0.0–7.0.14) uwierzytelniony użytkownik z rolą Współpracownika może dezaktywować dowolne wtyczki. Problem jest śledzony jako CVE-2026-9050 i naprawiony w wersji 6.7.56. Ten post wyjaśnia ryzyko, scenariusze ataków w rzeczywistości, krok po kroku łagodzenia, wskazówki dotyczące wykrywania i odzyskiwania oraz jak warstwowa zapora WordPress i podejście do wzmacniania ograniczają narażenie.

---

TL;DR — Co musisz wiedzieć teraz

• Wada naruszenia kontroli dostępu w Slider Revolution pozwalała uwierzytelnionym użytkownikom z niskimi uprawnieniami (Współpracownik) na wywoływanie działań, które powinny być zarezerwowane dla administratorów.
• Dotknięte wersje: Slider Revolution 6.0.0 do 6.7.55 i 7.0.0 do 7.0.14.
• Naprawione w wersji: 6.7.56 (i odpowiadające poprawki 7.x). Zaktualizuj natychmiast, jeśli korzystasz z dotkniętej wersji.
• CVSS zgłoszone na poziomie około 4.3 (niski–średni). Wykorzystanie wymaga uwierzytelnowanego konta (Współpracownik+), więc nie jest łatwo wykorzystywane zdalnie jako gość — ale strony, które pozwalają na rejestracje, publikacje gości lub mają wielu autorów, są narażone.
• Natychmiastowe działania: zaktualizuj wtyczkę, sprawdź nieoczekiwane dezaktywacje wtyczek, ogranicz rejestrację/role, włącz ochrony WAF/wirtualne łatanie i postępuj zgodnie z poniższą listą kontrolną odzyskiwania.

---

Dlaczego to ma znaczenie — głębsze wyjaśnienie podatności

Naruszenie kontroli dostępu jest jedną z najczęściej nadużywanych klas podatności na stronach WordPress. Występuje, gdy kod wykonujący wrażliwe działania (takie jak aktywacja lub dezaktywacja wtyczek) pomija odpowiednie kontrole autoryzacji — więc użytkownik, któremu nie powinno być pozwolone na wykonanie działania, może to zrobić.

W tym przypadku Slider Revolution wtyczka ujawniała działanie administracyjne, które:

• nie weryfikowało poprawnie uprawnień żądającego użytkownika (np., manage_options Lub aktywuj_wtyczki), i/lub
• nie egzekwowało odpowiednich nonce'ów ani walidacji pochodzenia żądania, i/lub
• przetwarzało obsługę żądania, która mogła być wywołana przez dowolnego uwierzytelnionego użytkownika (rola Współpracownika lub wyższa).

Praktyczny wynik: użytkownik z uprawnieniami Współpracownika mógł wysyłać skonstruowane żądania do dezaktywacji wtyczek, do których nie powinien mieć dostępu. Dezaktywacja wtyczek zabezpieczających, kopii zapasowych lub innych krytycznych wtyczek może mieć natychmiastowe i poważne konsekwencje:

• Wyłączenie wtyczek zabezpieczających lub integracji WAF, które chronią stronę przed innymi zagrożeniami.
• Wyłączenie monitorowania, skanowania złośliwego oprogramowania lub wtyczek kopii zapasowej, aby późniejsze naruszenie pozostało niezauważone.
• Powodowanie awarii lub zniekształceń poprzez usunięcie krytycznej funkcjonalności.
• Tworzenie możliwości dla łańcuchów eskalacji uprawnień (dezaktywacja wtyczki, która egzekwuje surowszą kontrolę dostępu, a następnie wykonanie dalszych działań).

Chociaż CVSS jest umiarkowane, rzeczywisty wpływ zależy całkowicie od konfiguracji Twojej witryny: czy rejestracja użytkowników jest włączona, ilu masz współpracowników i jakie wtyczki są zainstalowane i aktywne.

---

Realistyczne scenariusze ataków

1. Witryna z otwartą rejestracją: atakujący rejestruje się jako Współpracownik (jeśli Twoja witryna pozwala na rejestrację) i natychmiast uruchamia podatny handler, aby dezaktywować Twoje wtyczki zabezpieczające.
2. Skonfiskowane konto współpracownika: dane uwierzytelniające legalnego współpracownika są wykradzione lub ponownie użyte; atakujący wykorzystuje je do dezaktywacji zabezpieczeń.
3. Masowe wykorzystanie na różnych witrynach: zautomatyzowane skrypty celują w witryny z podatną wtyczką i próbują dezaktywować wtyczki znane z zapewniania ochrony — tani i skuteczny sposób na zwiększenie okna dla dalszych ataków.
4. Sabotaż łańcucha dostaw: dezaktywacja wtyczek monitorujących/kopii zapasowych przed przesłaniem złośliwego kodu lub zmianą treści zwiększa szansę na utrzymanie kompromitacji.

Ponieważ atakujący potrzebuje tylko uwierzytelnionego konta o niskim poziomie, ścieżka ataku jest cichsza niż pełne zdalne wykonanie kodu bez uwierzytelnienia — ale może być to potężny pierwszy krok w wieloetapowej kompromitacji.

---

Natychmiastowe działania (krok po kroku)

Te działania mają priorytet: wykonaj punkty 1–4 natychmiast, a resztę jak najszybciej.

1. Zaktualizuj Slider Revolution do poprawionej wersji (6.7.56 lub nowszej)
   • Dostawca wydał poprawki. Aktualizacja jest najbezpieczniejszym i najbardziej niezawodnym sposobem łagodzenia.
   • Jeśli używasz automatycznych aktualizacji, upewnij się, że zostały one pomyślnie zastosowane (sprawdź WP admin > Wtyczki lub użyj WP‑CLI).
2. Jeśli nie możesz zaktualizować natychmiast, zastosuj tymczasowe środki kompensacyjne:
   • Ogranicz dostęp do wp-admin i punktów zarządzania wtyczkami (zobacz “Tymczasowe łagodzenia WAF” poniżej).
   • Wyłącz publiczną rejestrację do czasu wydania poprawek.
   • Tymczasowo usuń lub ogranicz możliwości roli Współpracownika.
3. Zweryfikuj status i integralność wtyczek
   • Sprawdź, czy jakiekolwiek wtyczki zostały niespodziewanie dezaktywowane.
   • Polecenia:
     • Z WP‑CLI: wp lista wtyczek --format=table I wp option get active_plugins
     • W DB: sprawdź opcje_wp wiersz, gdzie option_name = 'aktywni_wtyczki'. Szukaj ostatnich zmian.
   • Jeśli krytyczne wtyczki są nieobecne na liście aktywnych, ponownie je aktywuj i zbadaj (patrz “Lista kontrolna odzyskiwania”).
4. Rotuj dane uwierzytelniające i przeglądaj użytkowników.
   • Wymuś resetowanie haseł dla kont administratorów i kont o wyższych uprawnieniach.
   • Usuń nieaktywnych lub nieznanych współtwórców.
   • Przeprowadź audyt niedawno utworzonych użytkowników i logowania.
5. Skanuj i monitoruj
   • Uruchom pełne skanowanie złośliwego oprogramowania i sprawdzenie integralności plików.
   • Włącz rejestrowanie aktywności/audytu, aby móc śledzić aktywacje/dezaktywacje wtyczek oraz zdarzenia na poziomie administratora.
6. Powiadom interesariuszy.
   • Jeśli jesteś właścicielem zarządzanej witryny, powiadom swojego dostawcę hostingu lub zespół ds. bezpieczeństwa, aby mogli pomóc w pilnym łagodzeniu skutków i analizie kryminalistycznej.

---

Jak potwierdzić, czy byłeś celem

• Szukaj nagłych dezaktywacji wtyczek w interfejsie administracyjnym WP.
• Sprawdzać wp_options.aktywne_wtyczki znacznik czasu i treść.
• Sprawdź dzienniki dostępu serwera (żądania POST do /wp-admin/admin-ajax.php, /wp-admin/admin-post.php, Lub wp-login.php) w czasie zmiany. Szukaj uwierzytelnionych żądań z nietypowych adresów IP lub kont.
• Jeśli masz wtyczkę do rejestrowania aktywności lub dzienniki audytu po stronie serwera: szukaj działań takich jak dezaktywuj_wtyczkę Lub aktywuj_wtyczkę.
• Sprawdź pliki zmodyfikowane niedawno (przesyłania, pliki motywów i wtyczek).
• Sprawdź nowych użytkowników administratorów lub modyfikacje ról/uprawnień użytkowników.

Jeśli znajdziesz jakiekolwiek oznaki manipulacji, postępuj zgodnie z listą kontrolną odzyskiwania (poniżej) i rozważ pełny audyt bezpieczeństwa.

---

Krótkoterminowe łagodzenia WAF (wirtualne łatanie)

Jeśli natychmiastowe aktualizacje wtyczek nie są możliwe — np. wymagane są testy na etapie lub zgodności — powinieneś wdrożyć kontrolki kompensacyjne w zaporze aplikacji webowej lub panelu sterowania hostingu. Wirtualne łatanie zmniejsza powierzchnię ataku, zapobiegając próbom wykorzystania dotarcia do podatnego kodu.

Sugerowany zestaw reguł (koncepcyjny; dostosuj do swojego produktu WAF):

• Zablokuj żądania POST do admin-ajax.php Lub admin-post.php z parametrami, które odpowiadają działaniom zarządzania wtyczkami, gdy żądający nie jest administratorem.
  Przykładowa pseudozasada:
  • Gdy ścieżka żądania odpowiada /wp-admin/admin-ajax.php LUB /wp-admin/admin-post.php I ciało żądania zawiera action=revslider_* (lub innym znanym nazwom akcji revslider) I użytkownik nie jest uwierzytelniony jako administrator (brak ważnego ciasteczka admina lub z niezatwierdzonego adresu IP), wtedy zablokuj/zwróć 403.
• Ogranicz liczbę żądań POST do punktów końcowych zarządzania wtyczkami z jednego adresu IP lub konta użytkownika.
• Zablokuj żądania, które próbują aktywować/dezaktywować wtyczki, chyba że żądanie pochodzi z znanego adresu IP administratora lub ma ważne ciasteczka sesji admina.
• Odrzuć żądania, w których nagłówek referer jest pusty lub nie pochodzi z twojej strony dla wrażliwych punktów końcowych admina (przydatne, ale nie niezawodne).
• Zapobiegaj dostępowi do punktów końcowych zarządzania wtyczkami (URL) z publicznych sieci — ograniczaj według IP lub użyj listy dozwolonych.

Uwaga: Reguły WAF powinny być testowane na etapie przed produkcją, aby uniknąć blokowania legalnych operacji admina.

---

Rekomendacje dotyczące wzmocnienia (średnioterminowe/długoterminowe)

1. Zasada najmniejszych uprawnień dla użytkowników
   • Ponownie rozważ przypisania ról użytkowników. Przyznawaj kontom na poziomie współtwórcy tylko te uprawnienia, które są potrzebne do tworzenia treści.
   • Usuń niepotrzebne możliwości z ról. Rola Współtwórcy zazwyczaj nie powinna mieć edit_theme_options, aktywuj_wtyczki, Lub manage_options.
2. Wyłącz edytowanie wtyczek i motywów

   define('DISALLOW_FILE_EDIT', true);
   

   Notatka: DISALLOW_FILE_MODS zapobiega aktualizacjom i instalacjom — używaj ostrożnie.

3. Używaj silnej autoryzacji
   • Wymuszaj silne hasła i rozważ uwierzytelnianie dwuskładnikowe dla kont administratorów.
   • Wymuszaj politykę haseł i używaj menedżera haseł dla wszystkich interesariuszy.
4. Zablokuj rejestrację i konta
   • Jeśli Twoja strona nie wymaga publicznej rejestracji, wyłącz ją (Ustawienia > Ogólne > Członkostwo).
   • Dla stron, które wymagają rejestracji, wdroż moderację lub użyj procesu zatwierdzania.
5. Ogranicz dostęp do wp-admin
   • Ogranicz /wp-admin I /wp-login.php używając list dozwolonych adresów IP, HTTP Basic Auth (dla stagingu) lub VPN do dostępu administracyjnego.
   • Użyj reguły zapory, która pozwala tylko uwierzytelnionym sesjom administracyjnym na dostęp do stron wtyczek i motywów.
6. Wdroż logowanie aktywności
   • Użyj wtyczki audytowej lub logowania po stronie serwera, aby śledzić aktywacje/dezaktywacje wtyczek, tworzenie użytkowników i zmiany ról.
   • Skonfiguruj powiadomienia o krytycznych zdarzeniach.
7. Regularne, zweryfikowane kopie zapasowe
   • Przechowuj wiele punktów kopii zapasowej poza siedzibą i okresowo testuj przywracanie.
   • Jeśli dojdzie do naruszenia, odzyskanie z czystej kopii zapasowej jest często najszybszą drogą do przywrócenia.
8. Automatyczne aktualizacje dla wtyczek o niskim ryzyku
   • Włącz automatyczne aktualizacje dla wtyczek niekrytycznych i drobnych wydań rdzenia, gdzie to możliwe. To zmniejsza okno na wykorzystanie.
   • Dla wtyczek o dużym wpływie używanych na krytycznych stronach, połącz automatyczne aktualizacje z testowaniem stagingowym.

---

Praktyczne fragmenty kodu i polecenia (dla administratorów i deweloperów)

• Sprawdź aktywne wtyczki za pomocą WP‑CLI:

  wp plugin list --format=table
  

• Tymczasowo wyłącz publiczną rejestrację:
  • WordPress admin: Ustawienia > Ogólne > odznacz “Każdy może się zarejestrować”.
  • Lub przez wp-config.php (rzadziej): nie dotyczy bezpośrednio — użyj interfejsu ustawień lub kodu do filtrowania rejestracji.
• Usuń uprawnienia z Współtwórcy (przykładowy fragment do usunięcia aktywuj_wtyczki jeśli obecny):

  <?php;
  

  Uwaga: Domyślnie Contributor nie powinien mieć aktywuj_wtyczki; to wymusza, jeśli kod lub wtyczka omyłkowo mu to przyznały.

• Dezaktywuj wtyczkę za pomocą WP‑CLI (awaryjna reaktywacja krytycznej wtyczki usuniętej przez atakującego):

  # Dezaktywuj wtyczkę bezpiecznie
  

  Używaj tych poleceń tylko jeśli rozumiesz wpływ; dezaktywacja Slider Revolution może wpłynąć na układ witryny.

• Szukaj podejrzanych żądań POST w logach serwera WWW:

  # Przykład: szukaj żądań admin-ajax w logach Apache
  

---

Lista kontrolna odzyskiwania — jeśli zostałeś naruszony

1. Odizoluj witrynę
   • Włóż witrynę w tryb konserwacji lub zablokuj dostęp publiczny podczas badania.
2. Przywróć z znanego dobrego kopii zapasowej
   • Jeśli masz czyste kopie zapasowe sprzed incydentu, przywróć je, a następnie załatw wszystko (wtyczki, motywy, rdzeń WordPress).
3. Reaktywuj krytyczne wtyczki zabezpieczające (po przywróceniu) i zaktualizuj je.
4. Rotacja danych uwierzytelniających
   • Zresetuj hasła dla wszystkich kont administratorów i contributorów.
   • Zmień klucze API, klucze SSH i inne dane uwierzytelniające, które mogły być ujawnione.
5. Ponownie przeskanuj w poszukiwaniu złośliwego oprogramowania.
   • Uruchom wiele skanerów — kontrole integralności plików i skany oparte na sygnaturach.
6. Audyt w celu wykrycia trwałości
   • Sprawdź nowych użytkowników administratorów, zaplanowane zadania w opcje_wp Lub wp_cron, nieoczekiwane pliki w uploads, zmodyfikowane pliki motywów i nieautoryzowane pliki PHP w zawartość wp.
7. Przejrzyj logi
   • Skonsoliduj logi i poszukaj początkowego wektora dostępu oraz osi czasu.
8. Wzmocnienie po incydencie
   • Zastosuj krótkoterminowe i długoterminowe środki zaradcze opisane wcześniej.
   • Rozważ pełny audyt bezpieczeństwa.
9. Raport i dokumentacja
   • Udokumentuj oś czasu incydentu i działania, a także powiadom interesariuszy lub klientów, jeśli to konieczne.

---

Dlaczego same aktualizacje nie są wystarczające

Łatanie jest najważniejszym krokiem, ale poleganie tylko na łataniach pozostawia okna narażenia:

• Wielu właścicieli stron opóźnia aktualizacje (obawy dotyczące zgodności, brak czasu na konserwację).
• Zautomatyzowane skanowanie masowych exploitów i oportunistyczni napastnicy będą celować w znane podatne wersje.
• Napastnicy mogą łączyć niskosekwencyjne błędy w większe ataki (przykład: użyj dezaktywacji wtyczki, aby wyłączyć zabezpieczenia, a następnie załaduj tylne drzwi).

Podejście warstwowe — stosowanie łatek, wzmocnienie strony i użycie zarządzanego WAF z wirtualnym łatawaniem — minimalizuje ryzyko i zmniejsza obciążenie związane z odzyskiwaniem.

---

Jak WP‑Firewall pomaga chronić Cię przed tym i podobnymi problemami

W WP‑Firewall podchodzimy do bezpieczeństwa WordPressa z modelem obrony warstwowej. W przypadku zdarzeń takich jak złamane kontrolowanie dostępu w Slider Revolution, następujące funkcje WP‑Firewall są szczególnie cenne:

• Zarządzany zapora aplikacji internetowej (WAF) i wdrażanie niestandardowych reguł: możemy wdrażać wirtualne łaty, aby zablokować próby eksploatacji, zanim będziesz mógł zastosować aktualizacje wtyczek.
• Skanowanie złośliwego oprogramowania i kontrole integralności plików: zautomatyzowane skanowanie, które pomaga wykrywać podejrzane zmiany po próbie działania napastnika.
• Zarządzane łagodzenie ryzyk OWASP Top 10: pokrycie wzorców złamanego kontrolowania dostępu i powszechnych wektorów eksploatacji.
• Monitorowanie ról i możliwości (ścieżki audytu): szybkie wykrywanie i powiadamianie o dezaktywacjach wtyczek i zmianach ról.

Łączenie szybkiego wirtualnego łatania z długoterminowym wzmocnieniem i monitorowaniem zmniejsza zarówno prawdopodobieństwo, jak i wpływ eksploatacji.

---

Praktyczne zalecenia dla agencji i hostów

• Wymuszaj bezpieczne domyślne ustawienia dla nowych instalacji: wyłącz publiczną rejestrację, ogranicz role i włącz egzekwowanie silnych haseł.
• Zapewnij zarządzane usługi aktualizacji i oferuj środowiska stagingowe do testowania zgodności.
• Oferuj wirtualne łatanie lub wdrażanie reguł awaryjnych dla powszechnie eksploatowanych podatności, aby chronić klientów, którzy nie mogą natychmiast zaktualizować.
• Edukuj klientów o ryzyku kont nieadministrowanych i znaczeniu zasady najmniejszych uprawnień.

---

Często zadawane pytania (FAQ)

Q: Jeśli moja strona nie pozwala na nowe rejestracje, czy mogę to zignorować?
A: Nie do końca. Skompromitowane konto współpracownika lub konto utworzone przez osobę trzecią (agencję, wykonawcę) może być nadal używane. Zaktualizuj wtyczkę i przeprowadź audyt istniejących użytkowników.

Q: Czy dezaktywacja Slider Revolution jest akceptowalnym tymczasowym rozwiązaniem?
A: Dezaktywacja usuwa podatny kod z wykonania, ale jeśli twoja strona polega na wtyczce do treści, możesz złamać strony. Jeśli możesz bezpiecznie ją dezaktywować podczas łatania, to usuwa powierzchnię ataku.

Q: Czy mogę polegać na moim hostingu, aby to naprawił?
A: Wiele hostów pomoże (szczególnie zarządzane hosty WordPress), ale odpowiedzialność ostatecznie spoczywa na właścicielu strony. Skontaktuj się ze swoim hostem i podaj informacje o CVE/łataniu; hosty często mogą wdrażać zasady WAF na krawędzi sieci.

Q: Czy usunięcie roli współpracownika zapobiega temu?
A: Usunięcie lub ograniczenie współpracowników zmniejsza powierzchnię ataku. Jeśli musisz zachować współpracowników, wprowadź surowsze zestawy uprawnień i użyj procesów zatwierdzania.

---

Zarejestruj się w WP‑Firewall Planie Darmowym — zacznij chronić swoją stronę teraz

Tytuł: Zabezpiecz podstawy z WP‑Firewall Planem Darmowym

Jeśli chcesz szybkiej, podstawowej ochrony podczas aktualizacji wtyczek i wzmacniania, plan WP‑Firewall Basic (Darmowy) zapewnia zarządzaną ochronę zapory, zaporę WAF klasy przedsiębiorstw, skanowanie złośliwego oprogramowania i łagodzenie powszechnych ryzyk OWASP Top 10 — wszystko z nieograniczoną przepustowością. To szybki sposób na zmniejszenie narażenia podczas łatania lub testowania aktualizacji. Dowiedz się więcej i zarejestruj się w darmowym planie tutaj: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Jeśli potrzebujesz dodatkowych możliwości — automatyczne usuwanie złośliwego oprogramowania, listy dozwolonych/zabronionych adresów IP, miesięczne raporty bezpieczeństwa lub automatyczne łatanie wirtualne — nasze płatne plany rozszerzają te zabezpieczenia.)

---

Praktyczna lista kontrolna czasowa — co robić w pierwszych 24, 72 godzinach i 2 tygodniach

Pierwsze 24 godziny:

• Zaktualizuj Slider Revolution do 6.7.56 (lub najnowszej).
• Jeśli to niemożliwe: włącz wirtualne łatanie WAF i ogranicz rejestrację.
• Sprawdź aktywną listę wtyczek i ponownie aktywuj wszelkie krytyczne wtyczki, które zostały dezaktywowane.
• Zresetuj hasła administratorów i rotuj klucze API.

Pierwsze 72 godziny:

• Przeprowadź pełne skanowanie złośliwego oprogramowania i integralności plików.
• Wzmocnij role użytkowników i wyłącz edytory plików.
• Przejrzyj logi serwera i logi aktywności w poszukiwaniu podejrzanych zdarzeń.
• Wdróż ograniczenia IP dla obszarów administracyjnych, jeśli to możliwe.

Tygodnie 1–2:

• Zweryfikuj kopie zapasowe i punkty przywracania; przetestuj proces przywracania.
• Wdrażaj długoterminowe wzmocnienia: uwierzytelnianie dwuskładnikowe, rejestrowanie audytów i zaplanowane skany.
• Rozważ zarządzane usługi bezpieczeństwa dla ciągłej ochrony i wirtualnych poprawek.

---

Zakończenie myśli — ludzka perspektywa

Luki takie jak CVE-2026-9050 przypominają nam o dwóch rzeczywistościach związanych z utrzymywaniem nowoczesnej witryny WordPress:

1. Popularne wtyczki oferują świetną funkcjonalność, ale także zwiększają powierzchnię ataku. Nawet dobrze utrzymywane wtyczki mogą mieć błędy — a gdy tak się dzieje, skutki mogą być subtelne, ale poważne.
2. Bezpieczeństwo to nie pojedyncza akcja. Łatanie jest niezbędne, ale musi być połączone z higieną użytkowników, wzmocnieniem, monitorowaniem i ochroną perymetralną, aby zmniejszyć zarówno prawdopodobieństwo, jak i wpływ kompromitacji.

Jeśli jesteś odpowiedzialny za jedną lub sto witryn WordPress, potraktuj to jako okazję do przeglądu swoich procesów aktualizacji i reakcji na incydenty. Mała ilość przygotowań — automatyczne kopie zapasowe, przetestowane procedury przywracania, plan awaryjnych wirtualnych poprawek — sprawia, że kompromitacja staje się zarządzalna, a nie katastrofalna.

Jeśli potrzebujesz pomocy w ocenie narażenia, wdrażaniu krótkoterminowych wirtualnych poprawek lub budowaniu długoterminowego planu wzmocnienia, zespół WP‑Firewall może pomóc.

Bądź bezpieczny i aktualizuj wcześnie.