| Nazwa wtyczki | Wtyczka do migracji kopii zapasowych WordPress |
|---|---|
| Rodzaj podatności | Złamana kontrola dostępu |
| Numer CVE | CVE-2025-14944 |
| Pilność | Niski |
| Data publikacji CVE | 2026-04-07 |
| Adres URL źródła | CVE-2025-14944 |
Krytyczne: Naruszenie kontroli dostępu w wtyczce Backup Migration (≤ 2.0.0) — Co właściciele stron muszą wiedzieć i zrobić teraz
Opublikowany: 7 kwi, 2026
Powaga: Niskie (CVSS 5.3) — CVE-2025-14944
Dotyczy wersji: Wtyczka Backup Migration ≤ 2.0.0
Wersja z poprawką: 2.1.0
Jeśli prowadzisz strony WordPress, które używają wtyczki Backup Migration (rodzina wtyczek “Backup”), ta luka wymaga natychmiastowej uwagi. Problem polega na naruszeniu kontroli dostępu (brak autoryzacji) w punkcie końcowym, który obsługuje przesyłanie kopii zapasowych do offline storage, co pozwala nieautoryzowanym atakującym przesyłać dowolne pliki kopii zapasowej do skonfigurowanego celu offline storage strony. Chociaż niektóre systemy oceny klasyfikują to jako niską priorytetowość, rzeczywiste ryzyko w świecie zależy w dużej mierze od twojej konfiguracji: atakujący, który może przesyłać kopie zapasowe lub pliki do twojego storage, może ułatwić wyciek danych, trwałe punkty dostępu lub pivotowanie do dalszej eksploatacji.
W tym poście wyjaśnię lukę w prostych słowach, nakreślę realistyczne scenariusze eksploatacji, pokażę, jak wykrywać oznaki nadużyć, a co ważniejsze — przedstawię praktyczne kroki łagodzące, które możesz wdrożyć natychmiast. Wyjaśnię również, jak zapora aplikacji webowej WordPress (WAF) taka jak WP‑Firewall może być użyta do ochrony stron podczas aktualizacji wtyczek lub przeprowadzania reakcji na incydenty.
Notatka: Dostawca wydał poprawkę w wersji 2.1.0. Aktualizacja jest najszybszym sposobem na naprawienie tego problemu.
Jaki jest problem (w prostych słowach)?
Funkcja lub trasa w wtyczce, która akceptuje przesyłanie do offline storage, nie ma odpowiednich kontroli autoryzacji. Oznacza to, że nieautoryzowani użytkownicy (ktokolwiek w internecie, bez logowania) mogą dotrzeć do tego punktu końcowego i przesłać plik, który wtyczka następnie przechowa w skonfigurowanym celu offline storage (np. lokalny system plików, zdalny koszyk zgodny z S3 lub inny dostawca storage).
Naruszenie kontroli dostępu zazwyczaj oznacza, że wtyczka nie sprawdziła:
- czy żądanie pochodziło od zalogowanego użytkownika, i/lub
- czy żądanie zawierało wymaganą zdolność/rolę lub ważny nonce/token autoryzacyjny, i/lub
- czy żądanie pochodziło z autoryzowanego adresu IP lub zaufanego serwera.
Gdy punkt końcowy przesyłania ufa niezweryfikowanym żądaniom, atakujący może go nadużywać w sposób wykraczający poza zwykłe przesyłanie uciążliwych plików.
Dlaczego to ma znaczenie — rzeczywiste scenariusze ataków
Sama luka to “brak autoryzacji” (nie zdalne wykonanie kodu), ale konsekwencje mogą stać się poważne w zależności od procesu tworzenia kopii zapasowych i konfiguracji storage:
- Ułatwienie wycieków danych
Jeśli wtyczka przesyła archiwa, które zawierają zrzuty bazy danych lub wp-content, atakujący mogą próbować zastąpić lub dodać archiwa w offline storage specjalnie przygotowanymi plikami, które później są przetwarzane przez inne automaty, co umożliwia wyciek danych. - Utrzymywanie się poprzez złośliwe kopie zapasowe
Atakujący mógłby przesłać archiwum kopii zapasowej zawierające tylne drzwi lub webshell, a następnie oszukać procedury automatyzacji lub przywracania, aby wdrożyć to archiwum — szczególnie w środowiskach z słabymi kontrolami zmian. - Ataki łańcucha dostaw lub wieloetapowe ataki
Przesłane pliki mogą być przechwytywane przez procesy downstream (CI/CD, inne narzędzia lub wtyczki drugorzędne), które zakładają, że przesyłane pliki są zaufane. Atakujący mógłby nadużyć tego zaufania, aby uzyskać wykonanie kodu lub konfiguracji w innym miejscu. - Nadużycie zasobów pamięci / odmowa usługi
Atakujący mogliby wielokrotnie przesyłać duże pliki, aby wyczerpać limity pamięci lub ponieść koszty w hostowanych usługach pamięci. - Ekspozycja poświadczeń lub sekretów
Jeśli kopie zapasowe zawierają pliki konfiguracyjne lub wyeksportowane poświadczenia, atakujący mogliby próbować umieścić pliki, aby wywołać zamieszanie lub nadpisać legalne zasoby, lub aby spowodować, że alerty logowania lub monitorowania zostaną stłumione.
Rzeczywisty wpływ zależy od tego, jak skonfigurowana jest pamięć kopii zapasowych (prywatne vs publiczne kosze, kto ma do nich dostęp), jakie procesy automatyczne odczytują te kopie zapasowe oraz czy strona przywraca z tych kopii zapasowych automatycznie.
Jak atakujący mogliby rozsądnie to wykorzystać (na wysokim poziomie)
- Odkryj adres URL przesyłania (to często jest łatwe: punkty końcowe wtyczek są zazwyczaj udokumentowane lub mogą być enumerowane).
- Wyślij spreparowany ładunek (plik kopii zapasowej lub archiwum) do punktu końcowego.
- Wtyczka akceptuje plik i przechowuje go w docelowej pamięci offline bez weryfikacji żądającego.
- Atakujący może następnie polegać na działaniach downstream (błąd ludzki, automatyczne przywracanie lub zintegrowane systemy), aby osiągnąć trwałość lub odzyskiwanie danych.
To nie jest zaawansowany zero-day; ścieżka eksploatacji jest prosta i łatwa do zautomatyzowania. To czyni ją atrakcyjną dla kampanii masowego skanowania, jeśli nie zostanie szybko złagodzona.
Kto jest najbardziej narażony?
- Strony korzystające z wtyczki Backup Migration w wersji 2.0.0 lub wcześniejszej.
- Strony, które korzystają z docelowych pamięci offline, które są współdzielone, publiczne lub połączone z inną automatyzacją (CI, synchronizacje kopii zapasowych, usługi stron trzecich).
- Środowiska hostingowe, w których kopie zapasowe są przywracane automatycznie lub kopie zapasowe są przetwarzane przez inne systemy.
- Instalacje wielostanowiskowe lub zarządzane konfiguracje, w których wiele stron dzieli poświadczenia pamięci.
Jeśli Twoja wtyczka jest skonfigurowana do przesyłania bezpośrednio do kosza S3, serwera SFTP lub innej pamięci zdalnej, która jest używana w wielu usługach, rozważ swoje ryzyko jako podwyższone.
Lista kontrolna działań natychmiastowych (co zrobić teraz)
- Zaktualizuj wtyczkę do wersji 2.1.0 lub nowszej
Dostawca naprawił problem w wersji 2.1.0. Aktualizacja jest głównym działaniem naprawczym i powinna być przeprowadzona tak szybko, jak to możliwe. - Jeśli nie możesz zaktualizować natychmiast, zastosuj tymczasowe środki zaradcze (zobacz sekcję WAF poniżej w celu automatycznego łatania wirtualnego i przykładów reguł).
- Sprawdź logi pod kątem podejrzanej aktywności
- Przeszukaj logi dostępu serwera WWW w poszukiwaniu żądań POST do punktów końcowych przesyłania wtyczki.
- Szukaj nietypowych agentów użytkownika, powtarzających się przesyłek lub żądań POST, które zawierają multipart/form-data do ścieżki przesyłania wtyczki.
- Sprawdź znaczniki czasowe i adresy IP źródłowe pod kątem wzorców.
- Audytuj offline'owe przechowywanie
- Wymień ostatnie obiekty w przechowywaniu kopii zapasowych (S3, zdalny FTP/SFTP lub lokalny katalog).
- Zweryfikuj rozmiary plików i nazwy w stosunku do oczekiwanych konwencji nazewnictwa kopii zapasowych.
- Usuń wszelkie pliki, których się nie spodziewałeś lub które wydają się złośliwe. Zachowaj kopie do analizy kryminalistycznej, jeśli to konieczne.
- Zmień dane uwierzytelniające do przechowywania
Jeśli odkryjesz nieautoryzowane przesyłki, zmień klucze i dane uwierzytelniające używane do uzyskania dostępu do offline'owego przechowywania. To zapobiega dalszym przesyłkom, jeśli atakujący ma wcześniejsze dane uwierzytelniające. - Skanuj witrynę i kopie zapasowe
- Przeprowadź pełne skanowanie strony pod kątem złośliwego oprogramowania.
- Skanuj przesłane kopie zapasowe w poszukiwaniu webshelli lub nieoczekiwanych skryptów.
- Jeśli podejrzana kopia zapasowa została niedawno przywrócona, traktuj witrynę jako skompromitowaną, dopóki nie potwierdzisz inaczej.
- Wzmocnij proces przywracania
- Upewnij się, że przywracanie jest ręczne lub wymaga drugiego kroku zatwierdzenia.
- Zablokuj automatyczne wyzwalacze przywracania, które działają na nowo przesłanych kopiach zapasowych.
- Poinformuj interesariuszy i dostawcę hostingu (jeśli to istotne)
Jeśli nie jesteś pewien wpływu lub widzisz oznaki kompromitacji, skontaktuj się ze swoim hostem lub specjalistą ds. bezpieczeństwa.
Jak WP‑Firewall pomaga podczas aktualizacji lub dochodzenia
Jeśli używasz WP‑Firewall (lub planujesz to zrobić), oferujemy kilka warstw ochrony, które możesz natychmiast wykorzystać, aby zmniejszyć narażenie:
- Zarządzane zasady WAF, które mogą wirtualnie załatać brakujące kontrole autoryzacji na krawędzi. Możemy wdrożyć tymczasową zasadę, aby zablokować nieautoryzowane POST-y do punktu końcowego przesyłania wtyczek, aż zaktualizujesz wtyczkę.
- Skanowanie złośliwego oprogramowania w celu wykrycia podejrzanych archiwów, webshelli lub wstrzykniętych plików w Twojej witrynie i w Twoim magazynie kopii zapasowych (gdzie to możliwe).
- Zautomatyzowane powiadomienia i logowanie, aby pomóc Ci wykryć anormalną aktywność przesyłania i wspierać reakcję na incydenty.
- Możliwość blokowania lub ograniczania liczby IP, agentów użytkowników lub wzorców żądań związanych z próbami wykorzystania.
- Wirtualne łatanie / wdrażanie zasad dla konkretnych CVE i punktów końcowych wtyczek bez konieczności natychmiastowych aktualizacji wtyczek.
Poniżej znajdują się praktyczne ustawienia WAF, które zalecamy natychmiast zastosować:
- Blokuj lub wyzwalaj wyzwania dla żądań do punktu końcowego przesyłania wtyczek, które są nieautoryzowane:
- Jeśli ścieżka punktu końcowego przesyłania jest znana (np. /wp-json/backup/upload lub /?backup_upload=1), utwórz zasadę WAF, aby zablokować POST-y HTTP do tej ścieżki, chyba że żądanie zawiera ważny token autoryzacji lub pochodzi z zaufanych adresów IP.
- Blokuj POST-y multipart/form-data do tego punktu końcowego z nieznanych agentów użytkowników.
- Tymczasowo egzekwuj wymóg tokena URL lub nagłówka (po stronie serwera): wymagaj niestandardowego nagłówka (X-Backup-Token) z tajnym kluczem wysyłanym tylko przez Twoje systemy administracyjne.
- Ogranicz liczbę żądań POST do punktów końcowych przesyłania.
Przykładowa, koncepcyjna zasada WAF (pseudo-zasada — Twój panel WAF sformatuje zasady inaczej):
JEŚLI request.path PASUJE DO "^/wp-json/backup/.*upload" LUB request.query ZAWIERA "backup_upload"
Nasze zarządzane zasady mogą być szybko wdrażane globalnie na Twoich witrynach i usuwane po zaktualizowaniu wtyczki.
Tymczasowe łagodzenia po stronie dewelopera (jeśli możesz edytować kod wtyczki lub witryny)
Jeśli masz zasoby deweloperskie i nie możesz natychmiast zaktualizować wtyczki, krótkoterminowym rozwiązaniem dewelopera jest dodanie kontroli po stronie serwera wewnątrz obsługi przesyłania:
- Weryfikuj ważny, nieprzeterminowany token lub nonce po stronie serwera w żądaniach przesyłania.
- Sprawdź, czy żądający ma odpowiednią zdolność WordPress (na przykład manage_options lub równoważną niestandardową zdolność).
- Wymagaj, aby żądanie przesyłania pochodziło z uwierzytelnionej sesji administracyjnej.
- Ogranicz częstotliwość przesyłania i maksymalny rozmiar pliku.
Przykład wysokopoziomowego pseudokodu do sprawdzenia po stronie serwera (nie wklejaj surowego kodu do produkcji bez testowania):
function handle_backup_upload() {
Nie polegaj wyłącznie na zabezpieczeniach po stronie klienta — złośliwi aktorzy mogą je obejść. Jakiekolwiek łagodzenie po stronie serwera musi być solidne i przetestowane.
Wykrywanie wykorzystania — na co zwracać uwagę
Nawet jeśli zaktualizowałeś, powinieneś sprawdzić, czy strona była nadużywana przed zastosowaniem poprawek:
- Logi serwera WWW
- Szukaj żądań POST do punktów końcowych przesyłania wtyczek z nietypowych adresów IP.
- Sprawdź przesyłania multipart/form-data z nazwami odpowiadającymi formatom plików kopii zapasowej (.zip, .tar, .sql).
- Audyt przechowywania
- Sprawdź znaczniki czasu ostatniej modyfikacji i logi tworzenia obiektów w S3 lub zdalnym magazynie.
- Zidentyfikuj obiekty, które nie przestrzegają twoich konwencji nazewnictwa kopii zapasowych.
- Użyj metadanych obiektów, aby znaleźć informacje o przesyłającym (jeśli jest to obsługiwane).
- Integralność plików
- Wykonaj porównanie sum kontrolnych bieżących plików witryny z dobrze znanym punktem odniesienia.
- Skanuj pod kątem sygnatur webshelli (pliki PHP w katalogach przesyłania, podejrzane wzorce eval/base64).
- Konta użytkowników
- Szukaj nowych kont administratorów utworzonych w tym samym czasie co podejrzane przesyłania.
- Sprawdź skoki nieudanych logowań.
- Zautomatyzowane logi przywracania
- Audytuj wszelkie zautomatyzowane działania przywracania lub przetwarzania podjęte na nowo przesłanych kopiach zapasowych.
Jeśli zobaczysz dowody nieautoryzowanych przesyłek lub nieoczekiwanej aktywności przywracania, wyłącz stronę (lub wprowadź ją w tryb konserwacji), podczas gdy będziesz prowadzić dochodzenie i naprawiać.
Reakcja na incydent — krok po kroku
- Ograniczenie
- Zablokuj punkt końcowy przesyłania za pomocą reguł WAF lub zapory ogniowej.
- Wstrzymaj wtyczkę (jeśli to bezpieczne) do czasu, aż załatwisz i ocenisz.
- Umieść stronę w trybie konserwacji, aby zapobiec dalszym automatycznym działaniom.
- Zachowaj dowody
- Zapisz logi serwera WWW i aplikacji, listy obiektów przechowywania oraz kopie podejrzanych kopii zapasowych w bezpiecznej lokalizacji do przeglądu kryminalistycznego.
- Eradykacja
- Usuń nieautoryzowane pliki z przechowywania i strony (po zachowaniu kopii).
- Zmień wszystkie dane uwierzytelniające do przechowywania i integracji.
- Usuń wszelkie nieautoryzowane konta użytkowników.
- Powrót do zdrowia
- Przywróć z znanej dobrej kopii zapasowej wykonanej przed zdarzeniem (jeśli dostępna).
- Zainstaluj wtyczkę ponownie tylko po zaktualizowaniu do poprawionej wersji (2.1.0 lub wyższej).
- Ponownie przeskanuj stronę w poszukiwaniu złośliwego oprogramowania i ukrytych tylnych drzwi.
- Po incydencie
- Wzmocnij uprawnienia, włącz dostęp dwuetapowy dla administratorów i przeglądaj zautomatyzowane procesy przywracania.
- Rozważ audyt bezpieczeństwa przez stronę trzecią, jeśli incydent ujawnił dane wrażliwe.
Jeśli nie jesteś pewien co do odzyskiwania, zaangażuj wykwalifikowanego eksperta ds. reakcji na incydenty WordPress. Szybkie, ostrożne działanie zmniejsza długoterminowe szkody.
Długoterminowe wzmocnienie — poza tą podatnością
Aby zmniejszyć przyszłe ryzyko związane z podobnymi lukami:
- Egzekwuj najmniejsze uprawnienia:
- Ogranicz, kto może instalować, konfigurować i uruchamiać kopie zapasowe.
- Użyj kontroli uprawnień w rutynach kopii zapasowych.
- Chroń punkty końcowe przesyłania i automatyzacji:
- Wymagaj podpisanych, czasowo ograniczonych adresów URL do przesyłania.
- Użyj tokenów po stronie serwera lub kontroli HMAC dla przychodzących wywołań integracyjnych.
- Segreguj przechowywanie kopii zapasowych:
- Użyj kubełków przechowywania z rygorystycznymi politykami IAM. Każda aplikacja lub środowisko powinno mieć swoje własne dane uwierzytelniające i minimalny dostęp.
- Gdzie to możliwe, trzymaj kopie zapasowe w oddzielnym magazynie od kont hostingowych produkcji i ogranicz dostęp do sieci.
- Monitoruj i powiadamiaj:
- Skonfiguruj powiadomienia o nietypowym tworzeniu obiektów w koszach kopii zapasowych lub powtarzających się nieudanych przesyłkach.
- Rejestruj wszystkie operacje przesyłania kopii zapasowych centralnie.
- Automatyzuj aktualizacje wtyczek (ostrożnie):
- Utrzymuj wtyczki zaktualizowane. Jeśli używasz automatycznych aktualizacji, przetestuj najpierw w środowisku testowym dla krytycznych witryn.
- Utrzymuj inwentarz wtyczek w całym swoim środowisku i monitoruj zalecenia dotyczące bezpieczeństwa.
- Przyjmij obronę w głębokości:
- Łącz zasady WAF, ochrony na poziomie sieci i wzmocnienia aplikacji.
- Regularne skanowanie bezpieczeństwa i testy penetracyjne pomagają znaleźć luki, zanim zrobią to napastnicy.
Przykładowe szablony zasad WAF (koncepcyjne)
Poniżej znajdują się szablony koncepcyjne, które możesz dostosować. Pamiętaj, że twoje środowisko hostingowe i interfejs zarządzania WAF będą miały swoją własną składnię.
1. Zablokuj nieautoryzowane POSTy do punktu przesyłania:
2. Ogranicz liczbę podejrzanych prób przesyłania:
3. Wyzwanie dla podejrzanych agentów użytkownika:
Użyj tych jako punktu wyjścia. Zarządzane zasady WP‑Firewall mogą być szybko zastosowane, jeśli wolisz nie pisać zasad samodzielnie.
Praktyczna lista kontrolna dla administratorów WordPressa
- Zidentyfikuj, czy używasz wtyczki Backup Migration i która wersja.
- Zaktualizuj do wersji wtyczki 2.1.0 lub nowszej.
- Jeśli nie możesz zaktualizować od razu, zablokuj punkty przesyłania za pomocą WAF lub tymczasowych zmian w kodzie.
- Audytuj cele przechowywania pod kątem nieautoryzowanych plików; usuń i zachowaj dowody, jeśli zostaną znalezione.
- Zmień wszelkie dane uwierzytelniające do przechowywania, które mogły być używane przez wtyczkę.
- Przejrzyj automatyzację przywracania i spraw, aby przywracania były ręczne lub wymagały zatwierdzeń.
- Włącz skanowanie złośliwego oprogramowania na całej stronie oraz rozwiązanie do monitorowania integralności plików.
- Wprowadź logowanie i powiadomienia dla zdarzeń przesyłania kopii zapasowych.
- Rozważ profesjonalną reakcję na incydenty, jeśli wykryjesz wykorzystanie.
Często zadawane pytania
Q: “Luka jest niskiej wagi — czy powinienem się martwić?”
A: Niska waga w ocenie nie zawsze oznacza niskie ryzyko dla twojego środowiska. Jeśli twój proces tworzenia kopii zapasowych wchodzi w interakcję z innymi systemami lub przechowuje wrażliwe dane, wpływ może być znaczący. Traktuj to jako działanie i zaktualizuj lub złagodź.
Q: “Czy mogę po prostu wyłączyć kopie zapasowe, aż naprawię?”
A: Możesz, ale pamiętaj, że kopie zapasowe są niezbędne. Jeśli je wyłączysz, upewnij się, że masz alternatywny, bezpieczny proces tworzenia kopii zapasowych. Najbezpieczniejszą drogą jest szybkie naprawienie i/lub zastosowanie łagodzeń WAF, które zachowują funkcjonalność kopii zapasowych, blokując nieautoryzowane przesyłania.
Q: “Czy WAF zablokuje legalne przesyłania kopii zapasowych?”
A: Jeśli jest skonfigurowany nieprawidłowo, tak. Skonfiguruj WAF, aby zezwalał na uwierzytelnione, zaufane źródła przesyłania (zaufane adresy IP, tokeny). Współpracuj z dostawcą hostingu lub bezpieczeństwa, aby przetestować zasady w trybie tylko monitorowania przed zablokowaniem.
Uzyskaj natychmiastową podstawową ochronę z WP‑Firewall Plan Darmowy
Jeśli chcesz łatwego sposobu na dodanie warstwy ochronnej podczas naprawy lub badania, plan darmowy WP‑Firewall zapewnia podstawowe zabezpieczenia bez kosztów. Plan Podstawowy (Darmowy) obejmuje zarządzany zaporę, nieograniczoną przepustowość, WAF z pokryciem zasad dla ryzyk OWASP Top 10 oraz skaner złośliwego oprogramowania — wystarczająco, aby zredukować narażenie na problemy z brakiem autoryzacji, takie jak ten, bez wprowadzania zmian w kodzie twojej strony. Możesz później zaktualizować do Standardowego lub Pro, aby uzyskać automatyczne usuwanie złośliwego oprogramowania, kontrolę czarnej/białej listy adresów IP, wirtualne łatanie, miesięczne raporty bezpieczeństwa oraz usługi zarządzane, które pomogą ci szybciej się odzyskać.
Zarejestruj się i zacznij chronić swoją stronę WordPress (plan Podstawowy)
(Porównaj plany, jeśli chcesz automatycznego usuwania, wirtualnego łatania i dedykowanego menedżera dla wyższego poziomu pewności.)
Zakończenie uwag od praktyka bezpieczeństwa WordPress
Naruszenie kontroli dostępu to niestety powszechny problem wtyczek, które ujawniają operacje administracyjne za pośrednictwem punktów końcowych HTTP. Naprawa jest często prosta: zweryfikuj uwierzytelnienie i możliwości na serwerze. Ale w rzeczywistości — z wieloma stronami i różnorodnymi konfiguracjami hostingu — takie luki szybko stają się bronią, ponieważ łatwo je zautomatyzować.
Najszybsza droga do bezpieczeństwa to: zaktualizuj wtyczkę do wersji 2.1.0 lub nowszej teraz. Jeśli nie możesz zaktualizować natychmiast, użyj WAF, aby zablokować nieautoryzowane żądania do punktu końcowego przesyłania, przeprowadź audyt przechowywania w poszukiwaniu nieautoryzowanych kopii zapasowych, zmień dane uwierzytelniające, jeśli to konieczne, a następnie zaktualizuj. Połącz to z ulepszonym logowaniem i ręcznymi kontrolami procesów przywracania, aby pojedyncze złośliwe przesyłanie nie mogło stać się pełnym kompromisem.
Jeśli potrzebujesz pomocy w stosowaniu łagodzeń lub przeglądaniu logów, zespół WP‑Firewall może pomóc w wdrażaniu zasad, skanowaniu i wirtualnym łataniu, abyś był chroniony podczas naprawy. Bezpieczeństwo nigdy nie jest jednowarstwowe; połączenie aktualizacji, wzmocnienia i ochrony perymetrycznej to najbardziej niezawodne podejście.
Bądź bezpieczny tam na zewnątrz — i sprawdź wersje swoich wtyczek dzisiaj.
