Nazwa wtyczki	WordPress Prime Slider – Dodatki do wtyczki Elementor
Rodzaj podatności	Atak typu cross-site scripting (XSS)
Numer CVE	CVE-2026-4341
Pilność	Średni
Data publikacji CVE	2026-04-07
Adres URL źródła	CVE-2026-4341

WordPress Prime Slider <= 4.1.10 — Uwierzytelnione przechowywane XSS przez follow_us_text (CVE-2026-4341): Co właściciele stron muszą teraz zrobić

Autor: Zespół ds. bezpieczeństwa WP‑Firewall

Data: 2026-04-08

Tagi: WordPress, Bezpieczeństwo, XSS, WAF, Prime Slider, Luka

Streszczenie: Przechowywana luka Cross-Site Scripting (XSS) wpływająca na wtyczkę Prime Slider – Dodatki do Elementor (wersje <= 4.1.10) pozwala uwierzytelnionym użytkownikom z uprawnieniami na poziomie autora (lub wyższymi) na wstrzykiwanie skryptów przez śledź_nas_tekst parametr. Problem jest śledzony jako CVE-2026-4341 i został naprawiony w wersji 4.1.11. Niniejsze zalecenie wyjaśnia ryzyko, scenariusze wykorzystania, techniki wykrywania, zapytania do bazy danych, kroki odpowiedzi na incydenty, wskazówki dotyczące wzmocnienia oraz praktyczne zasady WAF, które możesz zastosować natychmiast — w tym użycie WP‑Firewall do ochrony swojej strony podczas aktualizacji.

Spis treści

• Tło i wpływ
• Kto jest narażony na ryzyko
• Jak działa podatność (na wysokim poziomie)
• Scenariusze wykorzystania i cele atakującego
• Bezpieczne wykrywanie i wskaźniki kompromitacji
• Jak przeszukać swoją stronę i bazę danych w poszukiwaniu kompromitacji
• Natychmiastowe kroki naprawcze (krótka ścieżka)
• Zalecane wzmocnienie i długoterminowe łagodzenie
• Zasady WAF / wirtualne poprawki i przykłady
• Jeśli twoja strona jest już skompromitowana: plan odzyskiwania
• Rekomendacje operacyjne dla multisite i agencji
• Wypróbuj darmowy plan WP‑Firewall (Chroń swoją stronę natychmiast)
• Ostateczna lista kontrolna

---

Tło i wpływ

7 kwietnia 2026 roku ujawniono przechowywaną lukę XSS wpływającą na wtyczkę Prime Slider – Dodatki do Elementor w wersjach do i włącznie 4.1.10. Wtyczka przechowywała wartość kontrolowaną przez atakującego z śledź_nas_tekst parametru bez odpowiedniej sanitizacji lub ucieczki wyjścia. Uwierzytelniony użytkownik z uprawnieniami na poziomie autora (lub podobnymi) mógł wstrzykiwać HTML/JavaScript, który byłby przechowywany i później wykonywany w kontekście przeglądarki innych użytkowników odwiedzających strony, na których wartość jest renderowana.

Luka klasyfikowana jest jako Cross-Site Scripting (przechowywana) i przypisana do CVE-2026-4341. Dostawca naprawił problem w wersji 4.1.11; właściciele stron powinni natychmiast zaktualizować. Chociaż zgłoszona powaga jest umiarkowana (CVSS 5.9), przechowywane XSS może być bardzo zakłócające: atakujący mogą kraść tokeny sesji, wykonywać działania w imieniu administratorów, wstrzykiwać skrypty przekierowujące lub tworzyć trwałe defacements i monetyzację reklam.

Kto jest narażony na ryzyko

• Każda strona WordPress działająca na wtyczce Prime Slider – Dodatki do Elementor w wersji 4.1.10 lub wcześniejszej.
• Strony, które pozwalają uwierzytelnionym użytkownikom niebędącym administratorami na tworzenie lub edytowanie treści suwaków (Autor/Współautor lub podobne).
• Strony, na których wtyczka z lukami bezpieczeństwa generuje śledź_nas_tekst strony, które są wyświetlane przez administratorów, redaktorów lub innych uwierzytelnionych użytkowników, a nawet nieautoryzowanych odwiedzających w niektórych konfiguracjach.
• Sieci multisite, w których wtyczka jest aktywna w sieci.

Notatka: Nawet jeśli strona ma niski ruch, zautomatyzowane masowe wykorzystanie lub ukierunkowany atak na konkretnego administratora/redaktora może być bardzo szkodliwe.

Jak działa podatność (na wysokim poziomie)

1. Wtyczka zawiera parametr lub ustawienie powszechnie określane jako śledź_nas_tekst. Ta wartość jest edytowalna za pomocą interfejsu wtyczki i zapisywana w bazie danych, prawdopodobnie w opcjach, meta postach lub ustawieniach wtyczki.
2. Ścieżka kodu, która akceptuje i przechowuje śledź_nas_tekst nie w pełni oczyszcza ani nie koduje niebezpiecznych danych wejściowych (takich jak <script> tagi lub atrybuty obsługi zdarzeń).
3. Gdy wtyczka później generuje śledź_nas_tekst na stronie, przechowywany HTML/JS wykonuje się w przeglądarce odwiedzającego. Ponieważ jest przechowywany, ładunek utrzymuje się między wizytami.
4. Atakujący z uprawnieniami na poziomie autora może wstrzyknąć ładunek, który wykonuje się, gdy użytkownicy z wyższymi uprawnieniami (np. administratorzy) przeglądają suwak lub stronę go zawierającą.
5. W zależności od celu i ładunku, atakujący może przeprowadzić kradzież ciasteczek, przejęcie sesji, eskalację uprawnień za pomocą działań w stylu CSRF lub zainstalować dodatkowe tylne drzwi.

Scenariusze wykorzystania i cele atakującego

• Eskalacja uprawnień: Atakujący z dostępem na poziomie autora wstrzykuje skrypt, który przechwytuje dane logowania administratora lub ciasteczka sesji, gdy administrator podgląda lub edytuje stronę zawierającą suwak.
• Utrwalony zrzut złośliwego oprogramowania: Atakujący wstrzykuje skrypt, który ładuje złośliwą zawartość lub wykorzystuje przeglądarkę odwiedzającego jako punkt dystrybucji spamu lub reklam.
• Inżynieria społeczna/przekierowania: Wstrzyknięty skrypt tworzy fałszywe powiadomienie dla administratora, które wymaga działania (phishing), lub przekierowuje odwiedzających na stronę phishingową lub farmę płatnych kliknięć.
• Zatrucie SEO lub spam: Atakujący wstrzykują spam SEO, ukryte linki lub treści, które szkodzą rankingowi wyszukiwania lub prowadzą do czarnej listy.
• Dostarczanie ładunku drugiego etapu: Ładunek XSS jest używany do wykorzystania zaufanych funkcji tylko dla administratorów (np. przesyłanie złośliwej wtyczki lub zmiana opcji strony) za pomocą uwierzytelnionych działań.

Bezpieczne wykrywanie i wskaźniki kompromitacji

Ponieważ jest to przechowywany XSS, wykrywanie koncentruje się zarówno na przechowywanej zawartości, jak i wskaźnikach behawioralnych:

• Nieoczekiwane tagi w linii, JavaScript: URI, lub na* atrybuty (kliknij, onmouseover) w ustawieniach wtyczki, opcjach motywu lub treści suwaka.
• Zmiany w treści nagłówka/stopki witryny lub dodatkowy nieoczekiwany JS inline na stronach zawierających suwak wtyczki.
• Administratorzy widzą dziwne wyskakujące okna, monity o hasło lub przekierowania tylko wtedy, gdy są zalogowani.
• Nowi użytkownicy na poziomie administratora lub treści utworzone, których nie autoryzowałeś.
• Połączenia wychodzące do nieznanych domen inicjowane przez strony witryny.
• Powiadomienia z skanerów bezpieczeństwa pokazujące wersję wtyczki i znane luki XSS.

Jak przeszukiwać swoją witrynę i bazę danych w poszukiwaniu kompromitacji (bezpieczne zapytania)

Przed dokonaniem edycji wykonaj pełną kopię zapasową plików i bazy danych. Podczas wyszukiwania wskaźników używaj zapytań tylko do odczytu, gdzie to możliwe.

Przykłady SQL (dostosuj prefiks tabeli, jeśli nie wp_):

• Przeszukaj tabelę opcji:
  SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%<script%' OR option_value LIKE '%javascript:%' LIMIT 50;
• Wyszukiwanie postów (treść):
  SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' OR post_content LIKE '%onmouseover=%' OR post_content LIKE '%javascript:%' LIMIT 100;
• Wyszukiwanie postmeta (wtyczka może przechowywać pola tutaj):
  SELECT meta_id, post_id, meta_key FROM wp_postmeta WHERE meta_key LIKE '%follow_us%' OR meta_value LIKE '%<script%' LIMIT 100;
• Wyszukiwanie wszystkich wartości meta w poszukiwaniu podejrzanych wzorców:
  SELECT meta_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%' OR meta_value LIKE '%javascript:%' LIMIT 200;

Przykłady WP-CLI (bezpieczne, tylko do odczytu wyszukiwania):

• wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';"
• wp db query "SELECT meta_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%' OR meta_key LIKE '%follow_us%';"

Skanowanie systemu plików (grep):

• Znajdź wszelkie pliki lub szablony z dosłownym śledź_nas ciągiem:
  grep -R "śledź_nas" wp-content/ -n
• Szukaj skryptów w folderach uploads lub cache:
  grep -R "<script" wp-content/uploads/ -n

Ważny: Szukanie “<script” oznaczy legalne użycia (motywy, wtyczki). Zbadaj dopasowane wyniki, przeglądając kontekst. Szukaj obfuskowanego JS, eval, unescape lub ładunków base64.

Natychmiastowe kroki naprawcze (krótka ścieżka)

Jeśli masz zainstalowaną podatną wtyczkę i nie możesz jej natychmiast zaktualizować, podejmij te natychmiastowe działania:

1. Aktualizacja wtyczki
   Główna poprawka: Zaktualizuj Prime Slider do wersji 4.1.11 lub nowszej. To rozwiązuje przyczynę.
2. Jeśli nie możesz zaktualizować od razu, zaostrzyć uprawnienia
   – Ogranicz, kto może edytować suwaki: Usuń prawa autora/współpracownika do zapisywania treści suwaka, aż do zakończenia łatania.
   – Tymczasowo obniż uprawnienia edycji dla nieufnych użytkowników.
3. Zastosuj wirtualne łatanie za pomocą WP‑Firewall (zalecane)
   – Włącz zestawy reguł, które wykrywają i blokują tagi skryptów lub podejrzaną treść w żądaniach podczas zapisywania treści suwaka lub ustawień wtyczki.
   – Włącz naszą zarządzaną zaporę i reguły WAF dla natychmiastowej ochrony podczas aktualizacji.
4. Blokuj wzorce żądań
   – Wyłącz lub zablokuj żądania, które zawierają śledź_nas_tekst parametr z podejrzanymi ładunkami (zobacz przykłady reguł WAF w następnej sekcji).
5. Skanuj w poszukiwaniu istniejących wstrzyknięć
   – Przeprowadź pełne skanowanie złośliwego oprogramowania na stronie za pomocą WP‑Firewall lub swojego skanera i przeszukaj bazę danych w poszukiwaniu zapisanych tagów skryptów, jak pokazano powyżej.
6. Zresetuj sesje i krytyczne dane uwierzytelniające (jeśli podejrzewasz kompromitację)
   – Wymuś wylogowanie wszystkich użytkowników i zmień hasła administratorów. Rozważ rotację soli w wp-config.php (AUTH_KEY, SECURE_AUTH_KEYitp.).

Zalecane wzmocnienie i długoterminowe łagodzenie

1. Zasada najmniejszych uprawnień
   – Tylko zaufani użytkownicy powinni mieć możliwość edytowania lub dodawania treści wtyczek/tematów, które obsługują nieprzefiltrowany HTML. Ogranicz możliwości do administratorów, gdzie to możliwe.
2. Usuń możliwość unfiltered_html z niższych ról
   – Użyj małego fragmentu kodu lub wtyczki do zarządzania rolami, aby upewnić się, że tylko administratorzy zachowują unfiltered_html.

   Fragment PHP do usunięcia unfiltered_html z autorów/kontrybutorów (dodaj do wtyczki MU):

   add_action('init', function() {;

   Uwaga: Najpierw przetestuj na etapie. Redaktorzy mogą rzeczywiście potrzebować unfiltered_html w niektórych procesach; podejmuj decyzje na podstawie ryzyka.

3. Ucieczka danych wyjściowych i sanitizacja treści
   – Programiści wtyczek muszą sanitizować i uciekać wartości dostarczone przez użytkowników zarówno na wejściu, jak i wyjściu. Właściciele stron powinni preferować wtyczki, które przestrzegają konwencji rdzenia WP (dezynfekcja_pola_tekstowego, wp_kses_post, esc_html, esc_attr).
4. Polityka zabezpieczeń treści (CSP)
   – Wdróż restrykcyjną CSP, aby ograniczyć, skąd mogą ładować się skrypty i pomóc w złagodzeniu wpływu wstrzykniętych skryptów inline. Przykładowy nagłówek:
   Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'; object-src 'none';
5. Wyłącz interfejs wtyczki dla niezaufanych ról
   – Gdzie to możliwe, zapobiegaj edytowaniu suwaków przez nie-administratorów, filtrując możliwości lub usuwając elementy menu za pomocą remove_menu_page/remove_submenu_page i kontroli możliwości.
6. Okresowe skany i monitorowanie
   – Zaplanuj codzienne/tygodniowe skany w poszukiwaniu złośliwego JS lub nieoczekiwanych zmian i włącz monitorowanie integralności plików.
7. Kopie zapasowe i przetestowane procedury przywracania
   – Utrzymuj aktualne kopie zapasowe i przetestuj proces przywracania. Offline kopie zapasowe są najlepsze, aby uniknąć zainfekowanych kopii zapasowych.

Zasady WAF / wirtualne poprawki i przykłady

Zapora aplikacji internetowej (WAF) może zapewnić natychmiastowe wirtualne łatanie, aby zablokować próby wykorzystania przed aktualizacją kodu. Poniżej znajdują się przykładowe zasady (koncepcyjne), które możesz wdrożyć. Jeśli używasz WP‑Firewall, możesz szybko dodać równoważne zarządzane zasady.

Ważny: Te przykłady mają na celu prowadzenie konfiguracji. Testuj zasady w trybie monitorowania przed zablokowaniem, aby uniknąć fałszywych pozytywów.

Przykładowa reguła ModSecurity (blokuj tagi skryptów w parametrze follow_us_text):

SecRule ARGS:follow_us_text "@rx (?i)(<\s*script|javascript:|on\w+\s*=)" \"

Ogólna reguła ARGS do wychwytywania skryptów inline:

SecRule ARGS_NAMES|ARGS|REQUEST_COOKIES "@rx (?i)(<\s*script|on\w+\s*=|javascript:|eval\(|unescape\(|fromCharCode\()" \"

Blokuj POST-y do punktu końcowego ustawień wtyczki zawierające podejrzany JS (dostosuj ścieżkę):

SecRule REQUEST_METHOD "POST" "chain,phase:2,id:1001003,deny,status:403,msg:'POST ustawień Prime Slider z podejrzanym ładunkiem'"

Specyficzne wskazówki WP‑Firewall (zalecana konfiguracja)

• Włącz tryb “wirtualnego łatania”: blokujące reguły dla śledź_nas_tekst parametru i podobnych pól w wtyczce.
• Aktywuj ochrony OWASP top 10 (już zawarte w planie Basic Free).
• Włącz zaawansowane skanowanie treści żądania dla POST-ów do punktów końcowych wtyczki.
• Włącz powiadamianie o trafieniach reguł z użyciem e-maila administratora lub integracji Slack.
• Uruchom skaner, aby wykryć przechowywane skrypty w danych wtyczki i powiadomić właściciela strony.

Jeśli Twój WAF obsługuje pozytywne listy dozwolone, dodaj do białej listy tylko oczekiwane wzorce HTML dla śledź_nas_tekst (np. czysty tekst, minimalne formatowanie) i blokuj wszystko inne.

Jeśli twoja strona jest już skompromitowana: plan odzyskiwania

Jeśli znajdziesz dowody na przechowywane XSS lub inne złośliwe zmiany, traktuj stronę jako skompromitowaną i postępuj zgodnie z tymi krokami:

1. Zawierać
   – Umieść stronę w trybie konserwacji, aby ograniczyć dalsze szkody.
   – Wyłącz dostęp do zapisu (poprzez uprawnienia do plików), gdzie to możliwe, i izoluj serwer.
2. Zrzut/backup
   – Wykonaj kopię forensyczną plików i bazy danych (przechowuj bezpiecznie offline) przed wprowadzeniem zmian.
3. Rotacja danych uwierzytelniających
   – Zresetuj konta administratora i FTP; zmień klucze API i hasła do bazy danych. Zmień sól WordPressa w wp-config.php celu unieważnienia ciasteczek/sesji.
4. Usuń złośliwe wpisy.
   – Usuń lub oczyść dotknięte opcje/pozycje postmeta znalezione w powyższych wyszukiwaniach.
   – Przy usuwaniu skryptów z pól DB bądź ostrożny: zachowaj kopie zapasowe na wypadek, gdybyś usunął legalne treści.
5. Skanuj i czyść
   – Przeprowadź pełne skanowanie złośliwego oprogramowania i usuń złośliwe pliki lub kod. Jeśli infekcja jest znaczna, rozważ przywrócenie z czystej kopii zapasowej.
6. Ponownie audytuj wtyczki i motywy
   – Zaktualizuj wszystkie wtyczki/motywy do ich najnowszych wersji. Usuń wtyczki, które są nieużywane lub porzucone.
7. Przejrzyj logi
   – Analizuj logi dostępu, aby ustalić, jak atakujący uzyskał dostęp do witryny i które strony serwowały złośliwe treści. Szukaj nowych użytkowników administratora, zaplanowanych zadań lub nieznanego kodu.
8. Utwardzać i monitorować
   – Zastosuj powyższe kroki wzmacniające i włącz ciągłe monitorowanie oraz ochronę WAF, aby zapobiec ponownej infekcji.
9. W razie potrzeby zaangażuj profesjonalistów
   – W przypadku złożonych kompromisów może być konieczne zaangażowanie specjalisty ds. bezpieczeństwa do przeprowadzenia głębokiego śledztwa kryminalistycznego i oczyszczenia.

Rekomendacje operacyjne dla multisite i agencji

• Administratorzy sieci: Zaktualizuj wtyczkę w całej sieci natychmiast. Luki w wtyczkach aktywnych w sieci mogą wpływać na wszystkie podstrony.
• Witryny zarządzane przez agencje: Audytuj role na stronach klientów. Rozważ centralizację zarządzania bezpieczeństwem i aktualizacjami; włącz kontrolowane automatyczne aktualizacje dla drobnych wydań zabezpieczeń.
• Komunikacja z klientami: Powiadom klientów o ryzyku i planowanym harmonogramie łatania (łatka + skanowanie + monitorowanie).

Wypróbuj darmowy plan WP‑Firewall — Chroń swoją witrynę natychmiast

Tytuł: Chroń swoją witrynę natychmiast z darmowym planem WP‑Firewall

Jeśli chcesz natychmiastowej warstwy ochrony podczas łatania, zarejestruj się w planie WP‑Firewall Basic (darmowym) pod adresem:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Dlaczego plan WP‑Firewall Free pomaga teraz:

• Podstawowa ochrona: zarządzany firewall, który sprawdza przychodzące żądania i blokuje powszechne wzorce XSS.
• Nielimitowana przepustowość, dzięki czemu ochrona skaluje się niezależnie od ruchu lub wolumenu ataków.
• Zasady WAF (Web Application Firewall) stosowane do blokowania podejrzanych ładunków, takich jak tagi skryptów przesyłane przez formularze wtyczek.
• Skaner złośliwego oprogramowania do wykrywania przechowywanych skryptów lub wstrzykniętych zasobów.
• Ograniczenie ryzyk OWASP Top 10, aby zmniejszyć szansę na udane wykorzystanie podczas aktualizacji.

Przejście na płatne plany dodaje automatyczne usuwanie złośliwego oprogramowania, czarną/białą listę, miesięczne raporty bezpieczeństwa i wirtualne łatanie — ale plan Free zapewnia szybką, bezkosztową natychmiastową ochronę, która może blokować próby wykorzystania CVE-2026-4341 podczas planowania i przeprowadzania aktualizacji wtyczki.

Ostateczna lista kontrolna (praktyczne kroki)

1. Sprawdź wersje wtyczek: Czy zainstalowano Prime Slider <= 4.1.10?
2. Natychmiast zaktualizuj wtyczkę do 4.1.11 lub nowszej.
3. Jeśli nie możesz zaktualizować teraz:
   – Usuń możliwości edytora dla nieufnych ról.
   – Włącz ochrony WP‑Firewall i zastosuj zasady WAF dla śledź_nas_tekst.
4. Przeszukaj bazę danych pod kątem “<script”, “javascript:” i kluczy meta zawierających follow_us lub follow_us_text.
5. Jeśli znajdziesz wstrzyknięte skrypty:
   – Wykonaj kopię zapasową witryny.
   – Oczyść lub usuń złośliwe wpisy (uważaj, przetestuj najpierw na stagingu).
   – Zresetuj hasła i zmień sól.
6. Uruchom pełne skanowanie złośliwego oprogramowania i nadal monitoruj alerty/podejrzane trafienia reguł.
7. Wprowadź długoterminowe wzmocnienia: minimalne uprawnienia, CSP, okresowe skany, kopie zapasowe.
8. Zarejestruj się w WP‑Firewall Basic (Free), aby natychmiast uzyskać zarządzany WAF i skany złośliwego oprogramowania:
   https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Dodatek: Praktyczne przykłady i polecenia (podsumowanie)

• Zaktualizuj wtyczkę WordPress za pomocą WP Admin lub CLI:
  wp wtyczka aktualizacja bdthemes-prime-slider-lite
• Wyszukiwanie w DB dla podejrzanego postmeta:
  wp db zapytanie "WYBIERZ * Z wp_postmeta GDZIE meta_key JAKO '%follow_us%' LUB meta_value JAKO '%<script%';"
• Wyłącz możliwość unfiltered_html dla autorów i współpracowników (fragment wtyczki MU pokazany wcześniej).
• Przykład szablonu reguły ModSecurity (dostosuj do swojego dostawcy WAF):
  Zobacz przykłady reguł WAF powyżej; wdrażaj w trybie monitorowania przez 24–48 godzin, a następnie przełącz na blokowanie, gdy wskaźnik fałszywych pozytywów będzie akceptowalny.

Podsumowanie

Przechowywane luki XSS, takie jak ta w Prime Slider, są klasycznym przykładem, gdzie pozornie małe niedopatrzenie (niewłaściwe kodowanie wyjścia) może prowadzić do trwałych, wysokoodziaływających ataków — ponieważ ładunek żyje w twojej własnej bazie danych i wykonuje się w przeglądarkach twoich użytkowników administracyjnych i odwiedzających. Aktualizacja wtyczki to pierwsza i najlepsza akcja. Jeśli nie możesz zaktualizować od razu, wirtualne łatanie za pomocą WAF, zaostrzenie uprawnień, skanowanie w poszukiwaniu wstrzykniętej treści oraz utrzymywanie solidnego planu odzyskiwania znacznie zmniejszy ryzyko.

Jeśli zarządzasz wieloma witrynami WordPress, rozważ scentralizowanie zarządzania aktualizacjami i włączenie ciągłej ochrony WAF. Plan WP‑Firewall Basic (darmowy) to praktyczny pierwszy krok, aby bez opóźnień wprowadzić zarządzane reguły, skanowanie i łagodzenia OWASP: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Bądź bezpieczny — i priorytetowo traktuj łatanie, a następnie weryfikację i monitorowanie. Jeśli potrzebujesz pomocy w stosowaniu reguł WAF lub przeprowadzaniu bezpiecznego przeszukiwania forensycznego na swojej stronie, zespół wsparcia WP‑Firewall może pomóc ci wdrożyć wirtualne łaty i przeprowadzić skany, abyś mógł aktualizować i odzyskiwać z pewnością.