| Nazwa wtyczki | uListing |
|---|---|
| Rodzaj podatności | Pobieranie dowolnych plików |
| Numer CVE | CVE-2026-28078 |
| Pilność | Średni |
| Data publikacji CVE | 2026-02-28 |
| Adres URL źródła | CVE-2026-28078 |
Wrażliwość na pobieranie dowolnych plików w uListing <= 2.2.0 (CVE-2026-28078): Co właściciele stron WordPress muszą teraz zrobić
Autor: Zespół ds. bezpieczeństwa WP‑Firewall
Data: 2026-02-26
Streszczenie
Wrażliwość na pobieranie dowolnych plików (CVE-2026-28078) dotyczy wersji wtyczki WordPress uListing <= 2.2.0. Problem jest klasyfikowany jako Naruszenie kontroli dostępu / Pobieranie dowolnych plików z wynikiem bazowym CVSS wynoszącym 4.9. Zgłoszono, że wymagane są uprawnienia na poziomie edytora, aby wywołać podatne zachowanie. Dopóki łatka od dostawcy nie będzie szeroko dostępna, właściciele stron powinni traktować to jako umiarkowane, ale realistyczne ryzyko i natychmiast zastosować środki zaradcze.
Dlaczego to ma znaczenie (prosty język)
Jako właściciel WordPressa, ufasz wtyczkom, aby dodać funkcjonalność. Gdy wtyczka ujawnia sposób, aby ktoś mógł pobrać pliki, do których nie powinien mieć dostępu, staje się to bezpośrednim zagrożeniem dla prywatności i bezpieczeństwa Twojej strony.
Ten konkretny problem w uListing (<= 2.2.0) pozwala uwierzytelnionemu użytkownikowi z uprawnieniami edytora na pobieranie dowolnych plików ze strony. Oznacza to, że pliki konfiguracyjne, kopie zapasowe, wyeksportowane dane i inne wrażliwe artefakty mogą być pobierane i ujawniane. Nawet jeśli Twoja strona nie używa uListing do wszystkiego, każda możliwość dostępu do plików bez odpowiednich kontroli może być wykorzystana jako część szerszego łańcucha ataków.
Szybki przegląd ryzyka
- Oprogramowanie dotknięte: wtyczka WordPress uListing (wersje <= 2.2.0)
- Typ wrażliwości: Pobieranie dowolnych plików / Naruszenie kontroli dostępu
- CVE: CVE-2026-28078
- CVSS: 4.9 (Średni)
- Wymagane uprawnienia: Edytor
- Mapowanie OWASP: A01 – Naruszenie kontroli dostępu
- Status łatki (na dzień publikacji): Brak oficjalnej łatki od dostawcy szeroko dostępnej — zastosuj środki łagodzące
Przegląd techniczny (na wysokim poziomie)
Wrażliwość jest klasycznym błędem kontroli dostępu wokół punktu końcowego pobierania plików. Punkt końcowy przeznaczony do obsługi plików zarządzanych przez wtyczkę nie weryfikuje wystarczająco, czy użytkownik składający żądanie ma prawo dostępu do żądanego pliku. Gdy uwierzytelniony użytkownik z uprawnieniami edytora wywołuje ten punkt końcowy w określony sposób, serwer odpowiada, zwracając dowolny plik z systemu plików, zamiast ograniczać odpowiedź do załączników należących do wtyczki lub bezpiecznych zasobów.
Dlaczego to staje się niebezpieczne:
- Wiele stron WordPress ma kopie zapasowe, eksporty lub pliki konfiguracyjne dostępne na dysku. Jeśli wtyczka pozwala na przeszukiwanie katalogów lub żądanie plików według ścieżki/identyfikatora bez kontroli własności, te pliki mogą być pobierane.
- Nawet jeśli wykorzystanie wymaga praw edytora, wiele stron przyznaje uprawnienia edytora autorom, wykonawcom lub narzędziom zewnętrznym. Skonfiskowane konta edytora są bardziej powszechne, niż większość ludzi się spodziewa.
- Pobierane pliki konfiguracyjne często zawierają dane uwierzytelniające DB (wp-config.php, metadane kopii zapasowej), które umożliwiają eskalację uprawnień.
Uwaga: Celowo unikamy podawania dokładnych parametrów wykorzystania lub precyzyjnych ładunków żądań HTTP w publicznych wskazówkach. Celem jest wzmocnienie obrońców przy jednoczesnym zmniejszeniu ryzyka przyspieszenia wykorzystania.
Jak atakujący mogą wykorzystać tę wrażliwość
Mimo że zgłoszone wymagane uprawnienie to edytor, atakujący może nadal skorzystać na kilka sposobów:
- Eskalacja uprawnień: Uzyskaj pliki konfiguracyjne lub kopie zapasowe zawierające dane uwierzytelniające do bazy danych, a następnie użyj tych danych do zalogowania się do bazy danych lub przejścia do innych systemów.
- Ekfiltracja danych: Bezpośrednio pobierz eksporty, pliki CSV lub pliki multimedialne zawierające PII, listy klientów lub informacje finansowe.
- Zaopatrzenie do zautomatyzowanych ataków: Połącz pobieranie plików z istniejącym dostępem (np. skompromitowane konta autorów) i poruszaj się lateralnie w obrębie hosta.
- Utrzymywanie i ukrywanie śladów: Pobierz skrypty lub logi po stronie serwera, aby dowiedzieć się, jak usunąć ślady lub stworzyć tylne drzwi.
Wykrywanie: Na co zwracać uwagę w logach i monitorowaniu
Jeśli prowadzisz logi serwera, logi aplikacji lub zaporę aplikacji internetowej (WAF), zwróć uwagę na anomalne działania związane z punktami końcowymi wtyczki — szczególnie punktami końcowymi pobierania. Przykłady rzeczy do monitorowania:
- Żądania do punktów końcowych wtyczki, które zwracają treści niebędące mediami (np. odpowiedzi zawierające źródło PHP lub treści konfiguracyjne).
- Duża liczba udanych żądań GET dla plików o nazwach wyglądających na wrażliwe (wp-config.php, .env, backup-*.zip, zrzuty bazy danych).
- Próby pobrania zawierające wzorce przechodzenia przez ścieżki lub nietypowe parametry zapytań. (Uwaga: Nie szukaj ładunków exploitów według dokładnego ciągu w publicznych postach — użyj wewnętrznych reguł wykrywania.)
- Uwierzytelnione żądania z kont Edytora, które nagle uzyskują dostęp do punktów końcowych pobierania w sposób, w jaki typowi Edytorzy nie korzystają.
- Nowe lub nietypowe sesje dla użytkowników Edytora (zmiany IP, dziwne agenty użytkownika, czasy działania poza normalnymi godzinami pracy).
- Zmiany integralności w krytycznych plikach (niezgodności haszy dla wp-config.php lub plików rdzeniowych).
Jeśli Twoje monitorowanie może wykrywać nagłówki content-disposition, które zwracają załączniki zawierające fragmenty PHP, traktuj to jako priorytet wysokiego poziomu.
8. Gdy nie ma dostępnej oficjalnej poprawki wtyczki, powinieneś priorytetowo traktować środki obronne, które szybko zmniejszają ryzyko.
Jeśli używasz uListing i nie możesz natychmiast zastosować oficjalnej poprawki od dostawcy, wykonaj następujące kroki w kolejności. Łączą one wzmocnienie operacyjne z wirtualnym łatawaniem i wykrywaniem.
- Inwentaryzacja i przegląd dostępu
- Zidentyfikuj wszystkie strony, na których zainstalowano uListing i potwierdź wersję wtyczki.
- Audyt ról użytkowników. Zredukuj konta Edytora do minimum koniecznego. Przekształć wszelkie tymczasowe lub nieużywane konta Edytora na Współpracownika lub Subskrybenta.
- Wymuś reset hasła dla kont Edytora, jeśli podejrzewasz podejrzany dostęp lub jeśli jakiekolwiek dane uwierzytelniające konta Edytora mogły być używane gdzie indziej.
- Wyłącz funkcje wtyczki lub samą wtyczkę
- Jeśli możesz tymczasowo wyłączyć uListing bez łamania krytycznej funkcjonalności biznesowej, zrób to, aż poprawka będzie dostępna.
- Alternatywnie, wyłącz wszelkie funkcje pobierania plików lub punkty końcowe udostępnione przez wtyczkę za pomocą ustawień wtyczki (jeśli są dostępne).
- Zastosuj zasady WAF/wirtualnego łatania
- Skonfiguruj swój WAF, aby blokował/monitorował punkty końcowe pobierania wtyczki, aby nie zwracały dowolnych typów plików. Jako tymczasowe rozwiązanie, blokuj żądania, które próbują pobrać pliki po stronie serwera (php, env, config) za pomocą tych punktów końcowych.
- Wymuś, aby te punkty końcowe były dostępne tylko dla uwierzytelnionych użytkowników z odpowiednimi uprawnieniami — lub zablokuj wszelki bezpośredni dostęp anonimowy do nich.
- Ogranicz liczbę żądań do punktów końcowych wtyczki i ogranicz działania na poziomie Edytora, które żądają plików.
- Ogranicz dostęp na poziomie serwera.
- Upewnij się, że kopie zapasowe i wrażliwe pliki są przechowywane poza katalogiem głównym serwera WWW lub są w inny sposób chronione przez konfigurację serwera (deny from all w .htaccess dla Apache lub odpowiednie zasady w Nginx).
- Dodaj zasady serwera WWW, które zapobiegają bezpośredniemu dostępowi do plików o określonych rozszerzeniach lub nazwach plików (wp-config.php, *.sql, *.env, backup-*.zip). Zrób to ostrożnie i najpierw przetestuj na środowisku testowym.
- Audytuj dostęp do plików i integralność systemu.
- Przeprowadź pełne skanowanie strony pod kątem złośliwego oprogramowania.
- Potwierdź integralność podstawowych plików WordPress i plików wtyczek (porównaj z nowymi kopiami lub znanymi dobrymi haszami).
- Szukaj nietypowych plików, powłok sieciowych lub zaplanowanych zadań (cron jobs), które mogą wskazywać na kompromitację.
- Przygotuj się na rotację poświadczeń.
- Jeśli jakiekolwiek pliki konfiguracyjne lub kopie zapasowe mogły zostać ujawnione, zmień poświadczenia bazy danych i zaktualizuj wp-config.php odpowiednio.
- Zmień wszelkie klucze API znalezione na serwerze.
- Wymuś uwierzytelnianie dwuskładnikowe (2FA) dla wszystkich kont z podwyższonymi uprawnieniami.
- Kopia zapasowa i izolacja.
- Wykonaj pełną kopię zapasową (snapshot) witryny i serwera przed wprowadzeniem wielu zmian, aby móc zbadać i zachować dowody, jeśli zajdzie taka potrzeba.
- Jeśli uważa się, że witryna została skompromitowana, rozważ jej izolację od sieci podczas prowadzenia dochodzenia.
Jak WAF taki jak WP‑Firewall pomaga (wirtualne łatanie i zarządzane zasady).
W WP‑Firewall prowadzimy zarządzany WAF, który pomaga na trzy główne sposoby, podczas gdy czekasz na łatkę od dostawcy:
- Wirtualne łatanie
- Możemy wdrożyć ukierunkowaną zasadę, która przechwytuje próby użycia podatnego punktu końcowego pobierania do uzyskania wrażliwych typów plików lub dostępu do dowolnych ścieżek. Wirtualne łatanie natychmiast zmniejsza narażenie bez zmiany kodu wtyczki.
- Blokowanie oparte na zachowaniu
- Blokowanie anomalii, takich jak konta Edytora wykonujące masowe pobieranie plików, podejrzane ciągi zapytań próbujące przejścia katalogów lub nieoczekiwane nagłówki content-disposition.
- Automatyczne monitorowanie i powiadamianie
- Ciągłe skanowanie wskaźników kompromitacji (IoCs) i automatyczne powiadomienia, gdy zaobserwowane zostaną podejrzane wzorce pobierania lub zwrócone typy plików.
Jeśli korzystasz z darmowego planu WP‑Firewall, otrzymujesz zarządzany firewall i możliwości WAF, które mogą szybko zastosować te wirtualne poprawki i zminimalizować ryzyko — nawet zanim deweloper wtyczki wyda oficjalną aktualizację.
Zalecana lista kontrolna wzmocnienia (praktyczna, priorytetowa)
- Zarządzanie łatanie.
- Zaktualizuj uListing do poprawionej wersji, gdy deweloper ją wyda. Najpierw zastosuj aktualizacje na stagingu, a następnie na produkcji.
- Utrzymuj aktualne jądro WordPressa oraz wszystkie wtyczki/motywy.
- Zasada najmniejszych uprawnień
- Używaj najniższych niezbędnych ról użytkowników. Ogranicz konta Edytora i przeglądaj przypisania ról co miesiąc.
- Usuń nieaktywne konta administratorów i edytorów.
- Bezpieczne zarządzanie plikami
- Przenieś kopie zapasowe poza katalog główny i zabezpiecz je ograniczeniami na poziomie serwera oraz silnymi poświadczeniami.
- Ograniczaj przesyłanie i sanitizuj nazwy plików. Zezwól tylko na znane bezpieczne typy plików.
- Rejestrowanie i powiadamianie
- Włącz szczegółowe logowanie dla pobierania plików i działań administracyjnych.
- Powiadamiaj o nowych urządzeniach/IP dla kont o wysokich uprawnieniach.
- Higiena poświadczeń
- Zmieniaj poświadczenia, jeśli podejrzewasz ich ujawnienie.
- Wymuszaj unikalne hasła i rozważ 2FA dla Edytorów i Administratorów.
- Wdrożenie WAF
- Wprowadź zasady WAF, które:
- Blokują żądania pobierania plików, które zawierają przejście katalogów lub które żądają plików po stronie serwera.
- Wymuszają, aby punkt końcowy pobierania zwracał tylko dozwolone typy MIME.
- Ograniczaj lub blokuj powtarzające się żądania z tego samego IP dla punktów końcowych pobierania.
- Wprowadź zasady WAF, które:
- Testowanie reakcji na incydenty
- Upewnij się, że masz plan reakcji: identyfikacja, izolacja, eliminacja, odzyskiwanie i wyciągnięte wnioski.
Wskaźniki kompromitacji (IoCs) i notatki z dochodzenia
Podczas badania potencjalnego wykorzystania, priorytetowo traktuj te sygnały:
- Nieuzasadnione pobierania pliku wp-config.php, .env, *.sql lub *.zip z punktów końcowych wtyczek.
- Nagłe pobierania plików zsynchronizowane z działaniami użytkowników Edytora.
- Konta Edytora używane z lokalizacji geograficznych niepowiązanych z twoją organizacją.
- Niespodziewane typy treści w odpowiedziach na punkty końcowe wtyczek (na przykład, zwrócony kod źródłowy PHP, gdzie oczekiwano obrazu lub JSON).
- Nowe pliki lub wpisy cron na serwerze, lub zmiany znaczników czasowych istniejących plików, które nie mogą być wyjaśnione normalną aktywnością.
Zachowaj zachowane logi (logi serwera WWW, logi WAF i logi audytu WordPress) w celu wsparcia pracy kryminalistycznej.
Lista kontrolna działań naprawczych po incydencie
Jeśli potwierdzisz, że pliki zostały ujawnione lub doszło do kompromitacji:
- Izoluj witrynę, jeśli to konieczne.
- Zrób zrzut logów i systemu plików do analizy kryminalistycznej.
- Cofnij i obróć wszystkie sekrety, które mogły zostać ujawnione.
- Wydaj ponownie dane uwierzytelniające do bazy danych i zaktualizuj wp-config.php.
- Zainstaluj ponownie pliki rdzenia WordPress i wtyczek z zaufanych kopii po weryfikacji integralności.
- Oczyść katalog główny z wszelkich tylni drzwi lub niespodziewanych plików.
- Wzmocnij monitorowanie i zastosuj zasady WAF, aby zapobiec powtórzeniu się.
- Przejrzyj i zaktualizuj dostęp użytkowników. Usuń skompromitowane konta.
- Poinformuj interesariuszy i klientów, jeśli dane osobowe były zaangażowane, i przestrzegaj wszelkich obowiązujących wymogów dotyczących powiadamiania regulacyjnego.
Dlaczego wymagania na poziomie Edytora wciąż mają znaczenie — i dlaczego nie powinieneś ich ignorować
Niektórzy właściciele stron lekceważą ryzyko na poziomie Edytora, zakładając, że tylko Administratorzy mają wystarczającą moc, aby wyrządzić prawdziwe szkody. To nie zawsze prawda:
- Edytorzy często mają dostęp do przesyłania mediów, tworzenia stron i postów oraz uruchamiania funkcji wtyczek. W wielu rzeczywistych incydentach napastnicy zdobywają dane uwierzytelniające Edytora poprzez phishing, powtórnie używane hasła lub skompromitowanego wykonawcę.
- Gdy napastnik może wyeksportować pliki konfiguracyjne lub kopie zapasowe, może uzyskać dostęp do możliwości równoważnych administratorowi z zewnątrz (dostęp do bazy danych, zbieranie danych uwierzytelniających).
- Edytorzy są zazwyczaj liczniejsi i mniej ściśle zarządzani niż Administratorzy — co zwiększa szansę na kompromitację konta.
Traktuj konta Edytora jako wrażliwe i chroń je w ten sam sposób, w jaki chronisz dostęp administracyjny.
Komunikacja z interesariuszami i klientami
Jeśli Twoja strona obsługuje dane klientów i odkryjesz potwierdzone naruszenie:
- Bądź przejrzysty i rzeczowy.
- Wyjaśnij, co się stało, jakie dane mogły zostać ujawnione (jeśli wiadomo), jakie kroki podjąłeś i co klienci powinni zrobić (np. zmienić tokeny API).
- Zapewnij kanał kontaktowy do pytań i przyszłych aktualizacji.
Unikaj spekulacyjnych stwierdzeń — opieraj się na swoich ustaleniach i krokach naprawczych.
Długoterminowa prewencja: zasady zarządzania ryzykiem wtyczek
- Sprawdź wtyczki przed zainstalowaniem
- Preferuj wtyczki z aktywnym wsparciem, częstymi aktualizacjami i przejrzystymi praktykami bezpieczeństwa.
- Zmniejsz ślad wtyczek
- Zachowaj tylko te wtyczki, które są niezbędne. Im mniej ruchomych części, tym mniejsza powierzchnia ataku.
- Testowanie na etapie przygotowawczym
- Testuj aktualizacje wtyczek i nowe wtyczki na systemach przygotowawczych z realistycznymi danymi.
- Obrona w głębokości
- Warstwowe zabezpieczenia: bezpieczna konfiguracja serwera, wzmocnienie aplikacji, WAF i ciągłe monitorowanie.
- Skanowanie podatności
- Uruchom okresowe skanowanie podatności i utrzymuj proces szybkiej reakcji, gdy zgłaszane są problemy.
Jak WP‑Firewall może Ci pomóc teraz
W WP‑Firewall oferujemy zarządzane usługi WAF i łagodzenia podatności zaprojektowane specjalnie dla WordPressa. Gdy pojawia się podatność wtyczki, taka jak CVE‑2026‑28078, potrzebujesz szybkiej, niezawodnej obrony, czekając na łatkę z góry. Nasza zapora może:
- Wdrażać zarządzane wirtualne łatki, aby blokować próby wykorzystania podatnych punktów końcowych.
- Stosować detekcję opartą na zachowaniu, aby zidentyfikować podejrzaną aktywność Edytora lub anormalne wzorce pobierania.
- Skanować w poszukiwaniu znanych IOC i dostarczać rekomendacje dotyczące naprawy.
- Monitorować integralność witryny i natychmiast powiadamiać, jeśli zaobserwowane zostaną podejrzane pobrania plików.
Te łagodzenia zmniejszają twoje okno ryzyka i dają ci czas na przetestowanie i bezpieczne zastosowanie oficjalnej aktualizacji wtyczki.
Zabezpiecz swoją stronę internetową teraz — wypróbuj darmowy plan WP‑Firewall
Tytuł: Chroń swoją stronę za pomocą niezbędnych funkcji zarządzanej zapory — zacznij za darmo
Jeśli chcesz natychmiastowej, zautomatyzowanej ochrony przed zagrożeniami takimi jak ta podatność na pobieranie plików uListing, przetestuj podstawowy (darmowy) plan WP‑Firewall. Zawiera zarządzaną zaporę, WAF, nielimitowany transfer danych, skanowanie złośliwego oprogramowania i łagodzenie ryzyk OWASP Top 10 — wszystko, czego potrzebujesz, aby dodać warstwę ochronną podczas pracy nad aktualizacjami wtyczek i wzmocnieniem administracyjnym.
Zarejestruj się lub dowiedz się więcej tutaj: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
(Jeśli potrzebujesz szybszego, praktycznego łagodzenia lub wirtualnych łat z monitorowaniem i wsparciem incydentów, nasze płatne plany rozszerzają te podstawowe zabezpieczenia o automatyczne usuwanie złośliwego oprogramowania, listy IP, miesięczne raporty i automatyczne wirtualne łatanie.)
Praktyczny przykład: lista kontrolna reguł defensywnego WAF (koncepcyjna)
Poniżej znajdują się rodzaje reguł WAF, które stosują dobrzy obrońcy w obliczu ryzyk związanych z pobieraniem dowolnych plików. Są to koncepcyjne — dostosuj do swojego środowiska i przetestuj na etapie testowym.
- Blokuj żądania do punktów końcowych pobierania wtyczek, które zawierają:
- Żądania plików z rozszerzeniami po stronie serwera (.php, .env, .sql, .log).
- Wzorce przechodzenia przez katalogi (../ lub wariacje).
- Wymuszaj, aby punkty końcowe pobierania serwowały tylko dozwolone typy MIME (obrazy, PDF) i odrzucaj każde żądanie, które zwraca text/plain zawierający treści PHP lub bazy danych.
- Ograniczaj liczbę pobrań z jednego konta Edytora, aby zapobiec masowemu wyciekowi.
- Wymagaj ważnych nonce WordPress dla żądań administracyjnych; blokuj żądania, które nie zawierają oczekiwanych nonce dla krytycznych punktów końcowych.
- Powiadamiaj o pobraniach pochodzących z konta Edytora, które przekraczają historyczne progi.
Często zadawane pytania (FAQ)
Q: Jeśli nie używam aktywnie uListing, czy nadal muszę się martwić?
A: Tak. Każdy zainstalowany plugin może być wektorem ataku, nawet jeśli rzadko go używasz. Jeśli nie potrzebujesz uListing, rozważ jego odinstalowanie. Jeśli go potrzebujesz, zastosuj opisane powyżej środki zaradcze.
Q: Wrażliwość wymaga uprawnień Edytora; czy to oznacza, że jestem bezpieczny?
A: Niekoniecznie. Konta Edytora są często federowane lub używane przez wykonawców i mogą być narażone na phishing lub kompromitację. Ponadto wiele stron WordPress ma więcej Edytorów niż Administratorów, co zwiększa prawdopodobieństwo kompromitacji Edytora.
Q: Jak długo powinienem utrzymywać włączone wirtualne łatki WAF?
A: Utrzymuj wirtualne łatki, aż dostawca pluginu wyda zweryfikowaną łatkę, a Ty pomyślnie ją zaktualizujesz i przetestujesz na środowisku testowym i produkcyjnym. Po aktualizacji zweryfikuj, że zasady WAF nie wyzwalają się już w przypadku prawidłowego zachowania, a następnie ostrożnie usuń lub złagodź zasadę.
Ostatnie słowa (praktyczne, ludzkie)
Bezpieczeństwo rzadko dotyczy pojedynczej akcji. To suma małych, konsekwentnych praktyk: minimalne uprawnienia dla kont, sensowna higiena pluginów, zastosowane aktualizacje, kopie zapasowe przechowywane w bezpiecznym miejscu oraz warstwowe zabezpieczenia, takie jak WAF. Wrażliwość na pobieranie dowolnych plików w uListing to rodzaj problemu, który nagradza przygotowanie — jeśli ograniczyłeś konta Edytora, przechowywałeś kopie zapasowe z dala od katalogu głównego sieci i miałeś wdrożone monitorowanie, Twoje narażenie jest znacznie zmniejszone.
Jeśli jeszcze tego nie zrobiłeś, zrób inwentaryzację swoich stron, ogranicz uprawnienia i dodaj warstwę ochrony, taką jak zarządzany WAF. Te kroki nie tylko ochronią Cię przed tym konkretnym CVE — zmniejszają ryzyko w setkach potencjalnych problemów z pluginami i motywami.
Jeśli potrzebujesz pomocy w stosowaniu wirtualnych łat i uzyskaniu natychmiastowej ochrony podczas zarządzania aktualizacjami pluginów, nasz zespół w WP‑Firewall jest gotowy do pomocy.
Bądź bezpieczny,
Zespół ds. bezpieczeństwa WP‑Firewall
