Nazwa wtyczki	ReviewX
Rodzaj podatności	Ekspozycja danych wrażliwych
Numer CVE	CVE-2025-10736
Pilność	Średni
Data publikacji CVE	2026-03-24
Adres URL źródła	CVE-2025-10736

ReviewX <= 2.2.10 — Ujawnienie danych wrażliwych i manipulacja danymi bez uwierzytelnienia (CVE-2025-10736): Co właściciele stron WordPress muszą teraz zrobić

Autor: Zespół ds. bezpieczeństwa WP‑Firewall
Data: 2026-03-24
Tagi: WordPress, bezpieczeństwo, WAF, ReviewX, CVE-2025-10736, reakcja na incydenty

Streszczenie

Niedawno ujawniona luka (CVE-2025-10736) dotyczy wtyczki ReviewX dla WordPressa w wersjach do 2.2.10 włącznie. Problem klasyfikowany jest jako “nieprawidłowa autoryzacja”, która umożliwia nieautoryzowanym osobom dostęp do wrażliwych informacji i, w niektórych przypadkach, manipulację danymi. Luka ma wpływ oceniany w skali CVSS w średnim zakresie (6.5) i jest wykorzystywalna bez uwierzytelnienia.

Jeśli Twoja strona korzysta z ReviewX i nie została zaktualizowana do poprawionej wersji (2.2.12 lub nowszej), powinieneś potraktować to jako pilne: zaktualizuj natychmiast, zastosuj środki zaradcze i przeprowadź skoncentrowaną reakcję na incydent. Ten post wyjaśnia, na czym polega wada na poziomie technicznym (bez podawania przepisów na wykorzystanie), co mogą osiągnąć napastnicy oraz krok po kroku, jak zabezpieczyć swoją stronę i zredukować ryzyko.

Dlaczego to ma znaczenie (prosty język)

ReviewX obsługuje recenzje produktów, kryteria oceniania i przypomnienia o recenzjach — oraz integruje się z publicznymi funkcjami recenzji i danymi mikro (schema). Oznacza to, że wtyczka często przetwarza nazwy użytkowników, e-maile, treści recenzji, identyfikatory produktów i inne metadane. Gdy wtyczka ma punkty końcowe lub akcje, które nie egzekwują odpowiednich kontroli autoryzacji, nieautoryzowany odwiedzający może zapytać lub zmodyfikować dane, które powinny być dostępne tylko dla zaufanych użytkowników (administratorów strony lub samej wtyczki). Wyniki mogą być następujące:

• Ujawnienie prywatnych informacji klientów (nazwiska, e-maile — potencjalnie więcej)
• Manipulacja recenzjami (fałszywe recenzje, usunięcie legalnych)
• Uszkodzenie reputacji, SEO i zanieczyszczenie schematu oraz utrata konwersji
• Przejście do innych złośliwych działań, jeśli napastnicy mogą dodawać treści lub tylne drzwi

Ponieważ ten problem może być wywołany bez logowania, strony każdej wielkości są narażone na ryzyko.

Zrzut luki

• Dotknięta wtyczka: ReviewX (wtyczka do recenzji produktów WooCommerce i powiązane funkcje)
• Wersje podatne na ataki: <= 2.2.10
• Poprawione w: 2.2.12
• CVE: CVE-2025-10736
• Uderzenie: Ujawnienie informacji bez uwierzytelnienia i potencjalna manipulacja danymi
• Priorytet: Średni (zalecana natychmiastowa aktualizacja)
• Wymagane uprawnienia: Brak (nieautoryzowane)

Opis techniczny na wysokim poziomie (bez szczegółów dotyczących wykorzystania)

Podstawową przyczyną jest niewystarczająca kontrola autoryzacji na jednym lub więcej publicznych punktach końcowych wtyczki lub akcjach AJAX/REST. W wtyczkach WordPressa objawia się to zazwyczaj jako:

• Trasy REST API zarejestrowane bez restrykcyjnego permission_callback lub z takim, który zwraca true (lub całkowicie brak kontroli uprawnień).
• admin-ajax lub niestandardowe akcje AJAX, które wykonują operacje wyłącznie na podstawie dostarczonych parametrów, bez sprawdzania nonce, current_user_can() lub innych kontroli uprawnień.
• Punkty końcowe, które akceptują identyfikatory (identyfikatory komentarzy/recenzji, identyfikatory produktów, odniesienia do zamówień) i działają na nich bez weryfikacji, że wywołujący jest autoryzowany.

Gdy te kontrole są nieobecne lub niekompletne, nieautoryzowane żądanie HTTP może uzyskać dostęp do rekordów, które powinny być prywatne lub wykonać operacje zmieniające stan (wstawianie, aktualizacja, usuwanie), które wtyczka przeznaczyła tylko dla użytkowników uwierzytelnionych.

W tym poście nie podamy wzorców exploitów na poziomie żądań. Zamiast tego celem jest umożliwienie administratorom i deweloperom wykrywania, łagodzenia i zapobiegania eksploatacji.

Potencjalny wpływ i cele atakujących w rzeczywistości

Atakujący wykorzystujący ten problem może dążyć do kilku celów:

• Zbieranie danych: zbieranie adresów e-mail recenzentów, nazw użytkowników, częściowego kontekstu zamówień/klientów — przydatne do spamu, ukierunkowanego phishingu lub inżynierii społecznej.
• Manipulacja reputacją: wstrzykiwanie fałszywych pozytywnych/negatywnych recenzji w celu wpływania na kupujących lub zatruwanie recenzji konkurencji.
• Manipulacja SEO/schema: zmiana schematu recenzji lub wstawianie treści w celu wpływania na bogate fragmenty i pozycje w wyszukiwarkach.
• Eskalacja uprawnień: jeśli atakujący może wstrzykiwać treści lub linki, może próbować wprowadzić skrypty, przekierowania lub punkty zaczepienia dla kolejnych ataków.
• Zakłócenie działalności: usuwanie lub manipulowanie recenzjami, co wpływa na konwersje, zaufanie i przychody.

Nawet jeśli nie występuje natychmiastowa monetyzacja, obecność ujawnionych adresów e-mail i nazwisk klientów czyni witrynę wektorem dla oszustw i prób przejęcia kont.

Wskaźniki zagrożenia (IoC) — na co zwracać uwagę teraz

Sprawdź swoje logi i witrynę pod kątem oznak, że punkty końcowe wtyczki były badane lub nadużywane:

• Nieoczekiwane żądania do punktów końcowych REST, które wyglądają jak trasy wtyczki (np. ścieżki w formie /wp-json/… zawierające słowa kluczowe recenzji/wtyczki).
• Wysoka liczba żądań do admin-ajax.php z nietypowymi parametrami zapytań lub akcjami, które odnoszą się do funkcjonalności recenzji.
• Nowe lub edytowane recenzje, których się nie spodziewałeś — sprawdź znaczniki czasu, adresy IP i user-agenty.
• Partie tworzenia recenzji z jednego adresu IP, zakresu IP lub z podejrzanych ciągów user-agent.
• Rekordy bazy danych z podejrzaną treścią w polach review_text, reviewer_name, reviewer_email lub metadata.
• Żądania do punktów końcowych z akcjami takimi jak tworzenie, aktualizacja, usuwanie dla zasobów związanych z recenzjami pochodzące z zewnętrznych adresów IP.
• Podejrzane szczyty 4xx/5xx w logach zbieżne z żądaniami do punktów końcowych wtyczki.

Przydatne zapytania logów (przykłady, które możesz uruchomić w swoim systemie logowania):

• Apache / nginx: przeszukaj logi dostępu pod kątem “admin-ajax.php” i podejrzanych parametrów akcji.
• Szukaj żądań POST do /wp-json/ zawierających słowa kluczowe recenzji.
• Sprawdź logi pod kątem nagłych wzrostów żądań do ścieżek wtyczek w ciągu ostatnich 30 dni.

Jeśli zauważysz takie wzorce i masz ReviewX <= 2.2.10, przystąp do natychmiastowego łagodzenia i dochodzenia.

Natychmiastowe działania dla właścicieli stron (triage incydentów)

Jeśli używasz dotkniętej wersji, natychmiast wykonaj te kroki — uporządkowane według priorytetu:

1. Zaktualizuj wtyczkę (najlepsze i najszybsze rozwiązanie)
   • Zaktualizuj ReviewX do 2.2.12 lub nowszej. Ta poprawka rozwiązuje luki w autoryzacji.
   • Jeśli nie możesz zaktualizować natychmiast z powodu testów lub zgodności, przejdź do poniższych działań awaryjnych.
2. Zastosuj działanie awaryjne (wirtualna poprawka) za pośrednictwem swojego zapory/WAF
   • Jeśli używasz zarządzanej zapory lub WAF (takiej jak WP-Firewall), włącz odpowiedni zestaw reguł, który blokuje próby dostępu do podatnych punktów końcowych lub anomalnych żądań do tras wtyczek.
   • Jeśli polegasz na regułach na poziomie hosta, zastosuj tymczasowe reguły odmowy dla tras REST wtyczek lub zablokuj POSTy admin-ajax dla publicznych użytkowników.
3. Ogranicz dostęp do wrażliwych punktów końcowych
   • Użyj reguł .htaccess / nginx, aby ograniczyć dostęp do ścieżek specyficznych dla wtyczek tylko do zaufanych adresów IP (jeśli to możliwe).
   • Przykład: zablokuj wszystkie żądania do znanych ścieżek REST wtyczek z zewnątrz lub zezwól tylko na uwierzytelniony ruch.
4. Szukaj i naprawiaj manipulacje treścią
   • Przejrzyj tabelę recenzji i publiczne listy recenzji pod kątem podejrzanych zmian lub dodatków.
   • Usuń lub oznacz jako spam wszelkie recenzje, które są wyraźnie fałszywe.
   • Zachowaj logi kryminalistyczne i zrzuty dowodów.
5. Rotacja danych uwierzytelniających
   • Natychmiast zmień hasła administratora i wszelkie klucze API, które mogą być powiązane z wtyczką lub przepływami recenzji.
   • Jeśli jakiekolwiek konta użytkowników wyglądają podejrzanie, wymuś reset hasła.
6. Skanowanie i audyt
   • Przeprowadź pełne skanowanie złośliwego oprogramowania i skanowanie podatności (użyj wielu skanerów dla pewności).
   • Sprawdź integralność plików i porównaj z czystymi plikami pakietów wtyczek.
7. Audytuj kopie zapasowe i przywróć, jeśli to konieczne
   • Jeśli znajdziesz znaczną manipulację, która miała miejsce przed łatką, przywróć z czystej kopii zapasowej wykonanej przed naruszeniem.
   • Zachowaj kopię skompromitowanej witryny do analizy kryminalistycznej.
8. Powiadom strony dotknięte
   • Jeśli potwierdzisz ujawnienie danych osobowych klientów (e-maile, imiona), oceń wymagania dotyczące powiadamiania zgodnie z przepisami prawa i politykami przetwarzania danych.

Zasady WAF w sytuacjach awaryjnych i proste wirtualne łatanie (przykłady)

Poniżej znajdują się ogólne sugestie dotyczące wirtualnego łatania. Nie wdrażaj publicznego exploit'a; są to wzorce defensywne, które możesz nakazać swojemu WAF do egzekwowania.

• Zablokuj lub ogranicz liczbę nieautoryzowanych POST-ów do punktów końcowych wtyczek:
  • Wzorzec: zablokuj POST-y do /wp-json/*reviewx* lub do admin-ajax.php z akcjami odpowiadającymi akcjom specyficznym dla wtyczek.
• Wymagaj ważnego ciasteczka zalogowanego użytkownika lub nonce w żądaniach do punktów końcowych zarządzania recenzjami:
  • Jeśli ciasteczko nie jest obecne, zablokuj żądanie.
• Zablokuj podejrzane user-agenty lub IP odpowiedzialne za dużą liczbę żądań.

Przykład (pseudo-reguła):

Jeśli request.method == “POST” i request.uri pasuje do “^/wp-json/.*/reviewx” i request nie ma ciasteczka WP-Auth -> zablokuj / zwróć 403.

Ważny: Jeśli uruchamiasz publiczne funkcje przesyłania recenzji, które opierają się na publicznych POST-ach, upewnij się, że nie łamiesz legalnych przesyłek; pracuj z regułą etapową, która najpierw rejestruje, a następnie egzekwuje po potwierdzeniu braku fałszywych pozytywów.

Jeśli używasz WP‑Firewall, włącz wirtualną łatę dla ReviewX (wrażliwe wersje) oraz zasady, które łagodzą nieautoryzowane nadużycia REST/AJAX. Nasze zarządzane zasady są dostosowane, aby unikać powszechnych fałszywych pozytywów, jednocześnie chroniąc punkty końcowe, które nie mają autoryzacji.

Zapytania detekcyjne i przykłady logów, które możesz wykorzystać

• Apache (grep):
  • grep “admin-ajax.php” /var/log/apache2/access.log | grep -i “review”
  • grep “wp-json” /var/log/apache2/access.log | grep -i “reviewx”
• Nginx:
  • awk ‘/admin-ajax.php/ && /action=/{print $0}’ /var/log/nginx/access.log
  • grep “wp-json” /var/log/nginx/access.log | grep -i reviewx
• Dzienniki WP i wtyczki:
  • Jeśli używasz wtyczek do logowania zapytań lub logowania żądań, eksportuj żądania do podejrzanych punktów końcowych i porównaj adresy IP.

Gdy znajdziesz podejrzane adresy IP, zablokuj je w zaporze i zbadaj inne żądania z tego samego adresu IP (zarówno do witryny WP, jak i do innych hostowanych witryn na serwerze).

Pełna lista kontrolna reakcji na incydenty (szczegółowa)

1. Zawierać
   • Tymczasowo wyłącz ReviewX, jeśli to możliwe.
   • Jeśli wyłączenie narusza wymaganą funkcjonalność biznesową, zastosuj surowe zasady WAF, aby zablokować zewnętrzny dostęp do dotkniętych punktów końcowych.
2. Wytępić
   • Zaktualizuj wtyczkę do poprawionej wersji.
   • Usuń wszelkie wstrzyknięte recenzje lub złośliwe rekordy.
   • Usuń nieznanych użytkowników administratora lub konta utworzone w czasie podejrzanej aktywności (po wykonaniu kopii bazy danych jako dowodu).
3. Odzyskiwać
   • Przywróć wszelkie pliki sprawdzone pod kątem integralności z znanych dobrych źródeł.
   • Włącz ponownie wtyczkę po weryfikacji poprawki.
   • Przeprowadź pełne skanowanie pod kątem podatności i złośliwego oprogramowania, aby zweryfikować, że nie istnieją żadne drugorzędne punkty dostępu.
4. Po incydencie
   • Zmień wszystkie dane uwierzytelniające (użytkownicy administratora, FTP, baza danych, klucze API).
   • Przejrzyj harmonogram tworzenia kopii zapasowych i łatania.
   • Dokumentuj harmonogram i kroki naprawcze.
   • Powiadom interesariuszy i, w stosownych przypadkach, dotkniętych klientów.

Wskazówki dla deweloperów — jak unikać błędów autoryzacji

Jeśli jesteś deweloperem motywów/wtyczek lub zarządzasz niestandardowym kodem, wdrażaj te najlepsze praktyki, aby twój kod nie był kolejnym wpisem w bazie danych podatności:

• Zawsze używaj wywołań uprawnień dla tras REST
  • Podczas rejestrowania niestandardowych tras za pomocą register_rest_route(), dołącz permission_callback, który weryfikuje current_user_can() lub sprawdza ważną, ograniczoną zdolność.
• Oczyść i zwaliduj dane wejściowe
  • Nigdy nie ufaj identyfikatorom dostarczonym przez klienta. Waliduj typy, zakresy i własność.
• Używaj nonce'ów i sprawdzania uprawnień dla AJAX
  • W przypadku akcji admin-ajax.php, sprawdź wp_verify_nonce() i current_user_can() przed modyfikowaniem lub zwracaniem wrażliwych danych.
• Zasada najmniejszych uprawnień
  • Ujawniaj tylko minimalne dane niezbędne do interakcji publicznych.
• Ogranicz liczbę żądań i rejestruj wrażliwe punkty końcowe.
  • Dodaj ograniczenia liczby żądań lub wykrywanie nadużyć dla punktów końcowych, które zmieniają stan lub zwracają listy zasobów.
• Ochrony na poziomie treści.
  • Podczas pisania treści, która może pojawić się w znacznikach schematu, upewnij się, że escape'ujesz wyjścia i sanitizujesz dane HTML z publicznych formularzy.
• Testuj logikę autoryzacji w QA.
  • Dodaj negatywne przypadki testowe, które próbują wywołać punkty końcowe jako nieautoryzowany użytkownik, aby zapewnić odpowiednie odrzucenie.
• Oddziel publiczne przepływy zgłoszeń od przepływów zarządzania.
  • Jeśli pozwalasz na publiczne recenzje, zaprojektuj bezpieczny punkt końcowy zgłoszeń, który tylko zbiera i przechowuje do moderacji, a nie punkt końcowy zarządzania, który może zmieniać wiele zasobów.

Długoterminowe zmniejszenie ryzyka dla właścicieli stron.

• Utrzymuj surową politykę aktualizacji wtyczek.
  • Szybko aktualizuj krytyczne wtyczki (szczególnie te, które mają interakcję z danymi użytkowników).
• Uruchom wirtualne łatanie / WAF.
  • Odpowiednio dostrojony WAF zyska czas między ujawnieniem a skutecznym łatanie i może blokować wzorce eksploatacji.
• Używaj kont z minimalnymi uprawnieniami.
  • Ogranicz, kto może zarządzać recenzjami; zminimalizuj liczbę administratorów i egzekwuj silne hasła/2FA.
• Monitoruj integralność i logi.
  • Używaj monitorowania integralności plików oraz codziennych przeglądów logów lub alertów.
• Staging i testowanie
  • Testuj aktualizacje wtyczek w środowisku testowym przed wprowadzeniem do produkcji; ale łataj poprawki o wysokim priorytecie tak szybko, jak to możliwe.

Przykładowa reguła nginx do blokowania podejrzanych wywołań REST (przykład)

To ogólny przykład dla administratorów z nginx, którzy chcą zablokować publiczne POST-y do punktów końcowych REST zawierających nazwy wtyczek. Dostosuj ostrożnie; najpierw przetestuj w środowisku staging:

location ~* ^/wp-json/.*/(reviewx|review-x|review_x) {

Uwaga: Wiele legalnych tras REST używa POST do przesyłania; blokuj tylko wtedy, gdy jesteś pewien. Lepszym podejściem jest blokowanie nieznanych agentów użytkownika lub ograniczanie liczby POST-ów.

Jeśli nie możesz zaktualizować natychmiast — tymczasowe działania wzmacniające

• Usuń lub wyłącz publiczne punkty końcowe:
  • Jeśli wtyczka rejestruje trasy REST, których nie potrzebujesz, tymczasowo wyłącz publiczne moduły wtyczki.
• Wyłącz publikację recenzji:
  • Przełącz recenzje na tryb “ręcznej moderacji”, aby fałszywe recenzje nie mogły być publikowane automatycznie.
• Użyj ograniczeń IP:
  • Jeśli masz mały zestaw zaufanych adresów IP administratorów, ogranicz punkty końcowe administratora i ścieżki zarządzania wtyczkami do tych adresów IP.
• Dodaj bramkę autoryzacyjną:
  • Używając małego fragmentu kodu w mu-wtyczce swojej witryny, możesz przechwycić konkretne trasy REST i zwrócić 403 dla nieautoryzowanych użytkowników. Wymaga to umiejętności programistycznych — testuj ostrożnie.

Odzyskiwanie — analiza DB i co sprawdzić

Podczas badania, czy atakujący wykorzystał tę lukę:

• Eksportuj recenzje i powiązane tabele (z datami) i porównaj z kopią zapasową.
• Szukaj recenzji dodanych lub edytowanych z tymi samymi znacznikami czasu lub wzorcami.
• Sprawdź wp_users pod kątem nowych kont lub zmienionych ról.
• Sprawdź wp_posts i wp_postmeta pod kątem wstawionych linków, shortcode'ów lub treści backdoor.
• Szukaj zaplanowanych zadań (wp_options: wpisy cron) utworzonych w podejrzanych czasach.

Jeśli znajdziesz potwierdzone manipulacje, zachowaj kopie skompromitowanych danych na potrzeby prawne/zgodności i skontaktuj się z dostawcą hostingu — lub specjalistą ds. bezpieczeństwa — jeśli wymagane są głębsze analizy.

Rozważania dotyczące komunikacji i aspektów prawnych

Jeśli ustalisz, że dane osobowe (adresy e-mail, imiona, itp.) zostały ujawnione, skonsultuj się ze swoim inspektorem ochrony prywatności i zespołem prawnym, aby ustalić, czy powiadomienie o naruszeniu jest wymagane przez prawo (np. RODO, lokalne przepisy dotyczące naruszeń danych). Nawet jeśli nie jest to wymagane prawnie, powiadomienie dotkniętych klientów pokazuje przejrzystość i pomaga im bronić się przed phishingiem.

Lista najlepszych praktyk (szybka lista do wydruku)

• Zweryfikuj wtyczkę: Czy ReviewX jest zainstalowane i wersja <= 2.2.10?
• Zaktualizuj wtyczkę do 2.2.12+ teraz (lub wyłącz, jeśli to niemożliwe).
• Włącz zasady WAF, aby zablokować nieautoryzowane próby REST/AJAX.
• Skanuj pod kątem niedawno dodanych/zmodyfikowanych recenzji i kont użytkowników.
• Zmień dane logowania administratora i klucze API.
• Wzmocnij punkty końcowe administratora (ograniczenia IP, 2FA).
• Sprawdź kopie zapasowe i rozważ przywrócenie, jeśli doszło do manipulacji.
• Powiadom interesariuszy i dotkniętych użytkowników, gdzie to możliwe.
• Dodaj tę wtyczkę do swojej regularnej listy aktualizacji/nadzoru.

Dlaczego zarządzany firewall ma znaczenie (krótkie wyjaśnienie)

Wirtualne łatanie przez zarządzany firewall zapewnia natychmiastową ochronę przed znanymi wzorcami eksploatacji dla takich luk. Odpowiednio dostosowany zestaw reguł sprawdza żądania i blokuje podejrzane wzorce, jednocześnie redukując fałszywe alarmy. Jeśli nie możesz szybko załatać (okna testowe, kontrole zgodności), wirtualne łatanie zmniejsza powierzchnię ataku Twojej witryny, aż będziesz mógł wdrożyć oficjalną aktualizację.

Chroń swoją witrynę za pomocą darmowego zarządzanego firewalla

Zacznij od darmowego planu, który zapewnia natychmiastową ochronę

Rozumiemy, że nie każdy właściciel witryny może natychmiast załatać zależności. Dlatego oferujemy darmowy plan podstawowy, który obejmuje zarządzany firewall, zasady WAF, skanowanie złośliwego oprogramowania i łagodzenie ryzyk OWASP Top 10. Jest zaprojektowany dla właścicieli witryn, którzy chcą natychmiastowej, bezkosztowej warstwy ochrony podczas testowania lub planowania aktualizacji.

• Co zapewnia plan podstawowy (darmowy):
  • Niezbędna ochrona: zarządzany firewall i WAF
  • Nielimitowana przepustowość pod ochroną firewalla
  • Skaner złośliwego oprogramowania i podstawowe zasady łagodzenia
  • Ochrona przed typami zagrożeń OWASP Top 10

Jeśli chcesz dodać tę ochronę do swojej witryny już teraz, zarejestruj się tutaj: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Oferujemy również poziomy Standard i Pro z automatycznym usuwaniem złośliwego oprogramowania, kontrolami białej/czarnej listy IP, automatycznym łatawaniem wirtualnym, miesięcznymi raportami bezpieczeństwa i dodatkami premium dla zespołów.)

Zakończenie myśli — co zrobić teraz

1. Sprawdź swoją witrynę pod kątem ReviewX i jego wersji.
2. Natychmiast zaktualizuj do wersji 2.2.12 lub nowszej.
3. Jeśli nie możesz zaktualizować natychmiast, włącz WAF/łatanie wirtualne i wzmocnij punkty końcowe.
4. Sprawdź logi i recenzje pod kątem podejrzanych zmian.
5. Zmień dane uwierzytelniające i monitoruj dalsze działania.

Jestem członkiem zespołu bezpieczeństwa WP‑Firewall — często widzimy problemy z autoryzacją wtyczek. Często są to proste błędy w kodzie, ale mają duży wpływ, ponieważ mogą być wywoływane bez danych uwierzytelniających. Jeśli potrzebujesz pomocy w analizie logów, zastosowaniu zarządzanego zestawu reguł dla ścieżek związanych z ReviewX lub przeprowadzeniu głębszego przeszukiwania forensycznego, nasz zespół może pomóc.

Bądź bezpieczny i priorytetowo traktuj terminowe łatanie — okno ryzyka jest małe, jeśli działasz szybko, ale napastnicy działają szybko.

— Zespół ds. bezpieczeństwa WP‑Firewall