Nazwa wtyczki	Naprawdę Prosty SSL
Rodzaj podatności	Wada uwierzytelniania
Numer CVE	CVE-2026-48970
Pilność	Średni
Data publikacji CVE	2026-06-05
Adres URL źródła	CVE-2026-48970

Uszkodzone uwierzytelnianie w Naprawdę Prosty SSL (<= 9.5.10) — Co właściciele stron WordPress muszą zrobić teraz

Data: 2026-06-05
Autor: Zespół ds. bezpieczeństwa WP‑Firewall

Streszczenie: Wada uszkodzonego uwierzytelniania (CVE-2026-48970) wpływająca na wersje Naprawdę Prosty SSL <= 9.5.10 została ujawniona i załatana w 9.5.10.1. Problem ten oceniany jest na poziomie wysokim‑średnim w skali CVSS i może być wykorzystywany do wykonywania działań normalnie ograniczonych do użytkowników z wyższymi uprawnieniami — jednak wykorzystanie wymaga, aby atakujący już posiadał ważne hasło do konta. Poniżej wyjaśniamy ryzyko, realistyczne scenariusze ataków, sygnały wykrywania, natychmiastowe łagodzenia, pełną listę kontrolną odpowiedzi na incydent oraz długoterminowe zalecenia dotyczące wzmocnienia bezpieczeństwa z perspektywy doświadczonego dostawcy zapory aplikacji webowej (WAF) i bezpieczeństwa.

Uwaga: to ostrzeżenie jest napisane z defensywnego punktu widzenia. Jeśli zarządzasz stronami WordPress, przeczytaj kroki naprawcze i postępuj zgodnie z listą kontrolną. Im szybciej działasz, tym mniejsze szanse na udane naruszenie lub trwałe kompromitacje.

---

Co zostało ujawnione

• Oprogramowanie: Wtyczka Naprawdę Prosty SSL dla WordPress
• Wpływające wersje: <= 9.5.10
• Załatana wersja: 9.5.10.1
• Publiczny identyfikator: CVE-2026-48970
• Klasa podatności: Uszkodzone uwierzytelnianie / Błędy identyfikacji i uwierzytelniania
• Przegląd powagi: średni do wysokiego wpływu na poufność/ integralność w połączeniu z kompromitacją poświadczeń

Badacze, którzy ujawnili problem, podkreślają, że wykorzystanie wymaga ważnego hasła użytkownika. Innymi słowy, podatność umożliwia podwyższone działania, gdy atakujący uwierzytelnia się jako (lub kompromituje) legalne konto. Ponieważ wiele ataków w rzeczywistości zaczyna się od skradzionych poświadczeń (phishing, stuffing poświadczeń, powtórzone hasła), ta podatność może być atrakcyjna dla masowych kampanii.

---

Dlaczego to ma znaczenie — rzeczywisty wpływ na strony WordPress

Wady uszkodzonego uwierzytelniania są niebezpieczne, ponieważ omijają podstawowe mechanizmy kontrolne aplikacji — kto może robić co. W kontekście wtyczki, która kontroluje bezpieczeństwo i konfigurację strony (takiej jak ustawienia SSL i zachowanie przekierowań), udane nadużycie przez atakującego z ważnymi poświadczeniami może prowadzić do:

• tworzenia nielegalnych kont administratorów,
• modyfikacji krytycznych ustawień (przekierowania, nagłówki hosta, konfiguracja wtyczek),
• instalacji dodatkowych złośliwych wtyczek/tematów lub tylnej furtki,
• eksfiltracji danych strony (listy użytkowników, e-maile, zamówienia),
• mechanizmów utrzymywania (zaplanowane zadania, cron jobs, ukryci użytkownicy administratora),
• przełączanie na inne strony w tym samym koncie hostingowym lub ruch boczny w ramach multisite.

Ponieważ wymaga to, aby atakujący najpierw się uwierzytelnił, zapobieganie kompromitacji poświadczeń jest najważniejszą kontrolą. Jednak nawet po kompromitacji, dodatkowe wzmocnienia, monitorowanie i odpowiednie zasady WAF mogą ograniczyć szkody.

---

Realistyczne scenariusze ataków

1. Wypełnianie poświadczeń + nadużycie uprawnień
   • Atakujący przeprowadza kampanię wypełniania poświadczeń, używając wyciekłych list e-mail/hasło.
   • Administrator strony ponownie używa hasła; atakujący loguje się i wykorzystuje punkt końcowy wtyczki podatny na obejście uwierzytelnienia, aby wykonać działania zarezerwowane dla użytkowników o wyższych uprawnieniach.
2. Phishing + celowe przejęcie
   • Ukierunkowany e-mail phishingowy zbiera poświadczenia jednego administratora.
   • Posiadając ważne poświadczenia, atakujący wykorzystuje lukę, aby zwiększyć kontrolę nad stroną i zainstalować trwałe tylne drzwi.
3. Kompromitowana strona trzecia (wspólne poświadczenia)
   • Poświadczenia kont dewelopera lub agencji udostępnione wielu klientom zostają wycieknięte.
   • Atakujący uwierzytelnia się za pomocą wspólnych poświadczeń i nadużywa luki na wielu stronach.
4. Niewystarczające zarządzanie sesjami / skradzione ciasteczka
   • Jeśli atakujący już uzyskał ważne ciasteczko sesyjne, może nie potrzebować hasła; w połączeniu z uszkodzoną logiką uwierzytelniania, mogą działać jako ważny użytkownik.

Wszystkie te scenariusze prowadzą do klasycznego wyniku: atakujący z ważnymi poświadczeniami wykonuje działania wykraczające poza to, co powinno być dozwolone.

---

Wykrywanie wykorzystania — na co zwracać uwagę

Jeśli zarządzasz jakąkolwiek stroną działającą na Really Simple SSL (<= 9.5.10), zwróć uwagę na te wczesne wskaźniki:

• Nowe lub niespodziewane konta administratorów:
  • Sprawdzać użytkownicy wp tabela dla niedawno utworzonych użytkowników z uprawnieniami administratora.
• Nagłe zmiany konfiguracji:
  • Ustawienia SSL/przekierowania zmienione niespodziewanie.
• Niezwykłe instalacje wtyczek lub motywów:
  • Nowe wtyczki lub zmodyfikowane pliki wtyczek.
• Nieoczekiwane zaplanowane zadania (cron jobs):
  • sprawdź opcje_wp wpisy cron dla nieznanych wpisów.
• Zmiany w systemie plików:
  • Nowe pliki PHP w uploads, themes, mu-plugins lub wp-includes.
• Zwiększona aktywność logowania:
  • Nietypowe czasy logowania, wiele logowań z tych samych adresów IP lub wiele nieudanych prób logowania, po których następuje sukces.
• Anomalie CSRF lub REST API:
  • Nietypowe żądania REST API w dziennikach dostępu do punktów końcowych wtyczek.
• Połączenia wychodzące:
  • Procesy PHP łączące się z zdalnymi adresami IP lub domenami, które nie są zwyczajne (możliwe C2 / eksfiltracja).
• Treści spamowe, wstrzyknięty kod lub spam SEO.
• Niespodziewane zmiany uprawnień w plikach/katalogach.

Narzędzia i polecenia, które możesz użyć natychmiast:

• WP‑CLI (jeśli dostępne):
  • wp user list --role=administrator --format=csv
  • wp plugin list --status=aktywny
• Szybkie SQL do sprawdzenia ostatnich użytkowników (dostosuj prefiks tabeli, jeśli nie wp_):
  • SELECT ID, user_login, user_email, user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 25;
  • SELECT user_id, meta_key, meta_value FROM wp_usermeta WHERE meta_key LIKE 'pabilities%';
• Logi serwera:
  • Sprawdź dzienniki dostępu serwera WWW pod kątem podejrzanych żądań POST do stron administracyjnych i punktów końcowych REST API w czasie podejrzanych zmian.
• Integralność plików:
  • Szukaj nowych/zmodyfikowanych plików: find . -type f -mtime -7 -name "*.php" aby zobaczyć ostatnie modyfikacje plików PHP.

---

Natychmiastowa lista kontrolna łagodzenia skutków 0–24 godziny

Jeśli masz stronę korzystającą z dotkniętej wersji, wykonaj następujące kroki bez opóźnień.

1. Zaktualizuj wtyczkę do poprawionej wersji
   • Zaktualizuj Really Simple SSL do wersji 9.5.10.1 lub nowszej. To jest główna poprawka.
   • Jeśli zarządzasz wieloma stronami, priorytetowo traktuj strony o dużym ruchu i e-commerce.
2. Jeśli łatanie nie jest możliwe natychmiast, tymczasowo wyłącz lub ogranicz wtyczkę
   • Rozważ dezaktywację wtyczki, aż będziesz mógł bezpiecznie zaktualizować.
   • Jeśli nie możesz dezaktywować, ogranicz dostęp do stron administracyjnych wtyczki według IP (zobacz sekcję “Ograniczenia dostępu w nagłych wypadkach” poniżej).
3. Zresetuj dane logowania dla wszystkich kont administratorów
   • Wymuś reset hasła dla każdego konta na poziomie administratora.
   • Upewnij się, że hasła są unikalne i przestrzegają polityki haseł (długość ≥ 12, mieszane znaki, brak ponownego użycia).
4. Wprowadź uwierzytelnianie wieloskładnikowe (MFA)
   • Wymagaj MFA dla wszystkich uprzywilejowanych kont. MFA zapobiega natychmiastowemu przejęciu, jeśli hasło jest ponownie używane lub wyłudzane.
5. Rotuj klucze i sekrety
   • Zmień wp-config.php sól (AUTH_KEY, SECURE_AUTH_KEY itp.) oraz wszelkie tokeny API, których używasz (usługi zewnętrzne, bramki płatności itp.), jeśli podejrzewasz kompromitację.
6. Przejrzyj użytkowników strony i usuń podejrzanych
   • Usuń nieznanych użytkowników administratorów i zgłoś legalnych użytkowników, aby mogli poprosić o nowe dane logowania.
7. Przeprowadź pełne skanowanie złośliwego oprogramowania
   • Przeskanuj pliki swojej strony i bazę danych w poszukiwaniu tylnej furtki, nieoczekiwanego kodu i podejrzanych zadań zaplanowanych.
8. Zwiększ monitorowanie i rejestrowanie
   • Włącz szczegółowe logowanie na pewien czas (logi dostępu, logi aplikacji).
   • Ustaw alerty dla nowych użytkowników administratorów, zmian plików lub instalacji wtyczek.
9. Zablokuj dostęp do wp-admin
   • Tymczasowo ogranicz dostęp do /wp-admin I /wp-login.php za pomocą białej listy IP, podstawowej autoryzacji HTTP lub reguł zapory.
10. Powiadom swojego dostawcę hostingu i swój zespół
    • Jeśli zauważysz wyraźne oznaki kompromitacji, twój host może pomóc w tworzeniu zrzutów, izolacji i blokowaniu sieci.

---

Ograniczenia dostępu w nagłych wypadkach (przykładowe konfiguracje)

Jeśli nie możesz natychmiast zastosować poprawek i musisz utrzymać stronę online, ogranicz dostęp do stron administracyjnych wtyczki i wrażliwych punktów końcowych.

Przykład: HTTP Basic Auth dla /wp-admin (Apache .htaccess)

# Chroń /wp-admin za pomocą podstawowej autoryzacji

Przykład Nginx: lista dozwolonych adresów IP dla wp-admin

location /wp-admin {

Zablokuj punkty końcowe REST używane przez wtyczkę (przykład):

Zidentyfikuj prefiks trasy REST wtyczki (często pod /wp-json/really-simple-ssl/ lub podobnym). Następnie:

Nginx:

location ^~ /wp-json/really-simple-ssl/ {

Apache:

<Location "/wp-json/really-simple-ssl/">
    Require ip 203.0.113.12
</Location>

Zastrzeżenie: Uważaj przy stosowaniu zasad blokowania — upewnij się, że legalni konsumenci REST twojej strony nie są dotknięci (aplikacje mobilne, integracje). W razie wątpliwości, zezwól tylko na znane adresy IP dla punktów końcowych administracyjnych.

---

Dlaczego WAF i wzmocnienie logowania mają znaczenie

Ponieważ wykorzystanie wymaga ważnych poświadczeń, środki obronne muszą koncentrować się na zapobieganiu kradzieży poświadczeń i zmniejszaniu wartości skradzionych poświadczeń:

• Ograniczenie liczby żądań i łagodzenie botów zapobiegają masowemu wypełnianiu poświadczeń.
• Ochrona przed wypełnianiem poświadczeń (wykrywanie anomalii w nazwach użytkowników/hasłach) blokuje próby logowania z podejrzanych źródeł.
• Czarne listy i geofencing mogą ograniczyć dostęp z regionów wysokiego ryzyka, w których nie prowadzisz działalności.
• Powiadomienia w czasie rzeczywistym o nietypowej aktywności administratora (tworzenie nowego administratora, wysoki wskaźnik nieudanych logowań, po którym następuje sukces) pozwalają na szybką reakcję.
• Automatycznie egzekwowana złożoność haseł i wymuszona MFA zmniejszają ryzyko przejęcia.

Notatka: Nawet z WAF, jeśli atakujący zaloguje się przy użyciu legalnej nazwy użytkownika i hasła z benignnego adresu IP lub przejdzie MFA, WAF nie może zapobiec biznesowemu nadużyciu wtyczki. Dlatego wielowarstwowe zabezpieczenia są niezbędne: WAF + MFA + minimalne uprawnienia + monitorowanie.

---

Pełna instrukcja reagowania na incydenty (jeśli podejrzewasz kompromitację)

Jeśli potwierdzisz lub mocno podejrzewasz, że strona została wykorzystana, postępuj zgodnie z ustrukturyzowaną odpowiedzią.

1. Zawierać
   • Wprowadź stronę w tryb konserwacji lub tymczasowo ją wyłącz.
   • Izoluj hosta, jeśli masz wiele stron na tym samym serwerze.
2. Zachowaj dowody
   • Zrób zrzuty systemu plików i bazy danych przed wprowadzeniem zmian.
   • Zachowaj logi (serwer www, PHP, baza danych).
3. Określenie zakresu
   • Które konta były używane? Które pliki zostały zmodyfikowane? Jakie dane zostały uzyskane lub wykradzione?
   • Użyj znaczników czasu i logów, aby odtworzyć oś czasu atakującego.
4. Wyeliminuj zagrożenia
   • Usuń tylne drzwi, złośliwych użytkowników i nieautoryzowane zaplanowane zadania.
   • Zastąp zmodyfikowane pliki rdzenne i wtyczki czystymi kopiami z oficjalnych źródeł.
5. Odzyskiwać
   • Zaktualizuj podatną wtyczkę (aktualizacja do 9.5.10.1 lub nowszej).
   • Rotuj sekrety uwierzytelniające (hasła, klucze API, sól).
   • Przywróć z zaufanej kopii zapasowej, jeśli to konieczne.
6. Ponownie oceń
   • Przejrzyj polityki dostępu i role użytkowników.
   • Wprowadź zalecane wzmocnienia (MFA, zasady WAF, ograniczenie liczby logowań).
7. Monitorowanie po incydencie
   • Zwiększ monitorowanie przez co najmniej 90 dni.
   • Przeprowadzaj okresowe kontrole integralności plików i skany.
8. Notyfikować
   • Jeśli strona obsługiwała dane użytkowników (e-maile, zamówienia, dane osobowe), powiadom zainteresowane strony zgodnie z obowiązkami prawnymi i polityką prywatności.

---

Lista kontrolna długoterminowej prewencji i wzmocnienia

Aby zredukować narażenie na tę i podobne luki wtyczek, wdroż te kontrole jako część swojego regularnego programu bezpieczeństwa:

• Wymuszaj MFA dla wszystkich kont z podwyższonymi uprawnieniami.
• Wdroż minimalne uprawnienia — upewnij się, że użytkownicy mają tylko te role, których potrzebują.
• Używaj menedżera haseł i egzekwuj unikalne hasła dla każdego konta.
• Utrzymuj wtyczki, motywy i rdzeń WordPressa na bieżąco w środowisku stagingowym, a następnie wdrażaj na produkcji.
• Utrzymuj regularne kopie zapasowe z przechowywaniem offsite i często testuj przywracanie.
• Używaj WAF, który obejmuje łagodzenie botów, ochronę przed wypełnianiem poświadczeń i wzmocnienie logowania.
• Ciągle monitoruj logi i ustaw automatyczne powiadomienia o podejrzanej aktywności.
• Przeprowadzaj okresowe skany podatności i subskrybuj informacje o podatnościach dla wczesnego ostrzegania.
• Wzmocnij dostęp administratorów:
  • Ogranicz dostęp do /wp-admin używając list dozwolonych lub VPN dla stron wysokiego ryzyka.
  • Dodaj nagłówki HTTP i polityki bezpieczeństwa (HSTS, CSP, X-Frame-Options).
• Używaj monitorowania integralności plików, aby szybko wykrywać nieoczekiwane zmiany.
• Wykorzystaj środowisko stagingowe/testowe w piaskownicy dla poprawek i aktualizacji wtyczek przed wdrożeniem na produkcji.
• Utrzymuj plan reakcji na incydenty i przeprowadzaj ćwiczenia symulacyjne.

---

Praktyczne polecenia WP‑CLI i SQL, które pomogą w triage

Użyj tych poleceń, aby szybko zebrać dane. Zastąp wp_ z prefiksem tabeli, jeśli jest inny.

• Lista kont administratorów:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

• Pokaż ostatnie rejestracje użytkowników:

wp db query "SELECT ID,user_login,user_email,user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 50;"

• Sprawdź możliwości użytkowników:

wp db query "SELECT user_id,meta_key,meta_value FROM wp_usermeta WHERE meta_key LIKE 'pabilities%' ORDER BY user_id;"

• Znajdź niedawno zmodyfikowane pliki PHP:

find . -type f -iname "*.php" -mtime -7 -print

• Wyłącz wtyczkę (jeśli nie możesz natychmiast zastosować poprawki):

wp plugin deactivate really-simple-ssl

• Wymuś reset hasła dla użytkownika:

wp user update 1 --user_pass="$(openssl rand -base64 16)".

• Wyczyść wszystkie sesje (wymuś wylogowanie wszędzie):

wp user session destroy .

---

Ograniczenia wirtualnego łatania dla tego problemu

Niektóre luki w zabezpieczeniach nadają się do wirtualnego łatania na poziomie WAF (blokowanie konkretnego wzorca żądania). W przypadku luk związanych z logiką uwierzytelniania — szczególnie gdy atakujący uwierzytelnia się legalnie — reguła WAF może tylko blokować znane sygnatury ataków (np. zautomatyzowane wzorce eksploatacji), ale nie może w pełni zapobiec uwierzytelnionemu użytkownikowi w wykonywaniu działań, które aplikacja pozwala. Dlatego musisz:

• Zastosować poprawkę do wtyczki do wersji naprawionej (9.5.10.1) jako główne rozwiązanie.
• Użyj WAF, wzmocnienia logowania i monitorowania jako kontrolę kompensacyjną, aby zmniejszyć ryzyko kompromitacji poświadczeń i szybko wykrywać nadużycia.

---

Lista kontrolna walidacji po aktualizacji

Po zaktualizowaniu/załatanie, zweryfikuj:

• Wersja wtyczki pokazuje 9.5.10.1 lub nowszą na liście wtyczek.
• Nie istnieją nieoczekiwani użytkownicy administratora.
• Brak nieautoryzowanych wtyczek/motywów i brak zmodyfikowanych plików rdzenia/wtyczek.
• Lista zadań zaplanowanych (cron) jest rozsądna: lista zdarzeń wp cron
• Logi serwera WWW i PHP nie pokazują już podejrzanych żądań.
• Polityki MFA i hasła są aktywne dla administratorów.
• Kopie zapasowe są aktualne i przechowywane w innym miejscu.

---

Jak WP‑Firewall pomaga (nasze podejście obronne)

Jako dostawca zabezpieczeń WordPressa, zalecamy i zapewniamy warstwowe zabezpieczenia, które są zgodne z powyższymi krokami:

• Zarządzany WAF, który obejmuje łagodzenie botów i ochronę przed wypełnianiem poświadczeń, aby zmniejszyć ryzyko masowych prób logowania zautomatyzowanego.
• Wzmocnienie logowania: limity prędkości, blokowanie podejrzanych adresów IP i dozwolenie dostępu do punktów końcowych administracyjnych.
• Skanowanie złośliwego oprogramowania i monitorowanie integralności plików w celu szybkiego wykrywania nieautoryzowanych modyfikacji.
• Powiadomienia w czasie rzeczywistym o podejrzanej aktywności administratora (nowi użytkownicy administratora, zmiany w ustawieniach wtyczek).
• Zaplanowane automatyczne kopie zapasowe i łatwe przywracanie.
• Powiadomienia o poradach bezpieczeństwa i monitorowanie poprawek, abyś mógł szybko działać, gdy wydawane są aktualizacje dostawcy.

Chociaż żaden pojedynczy środek nie jest doskonały, nasz model kładzie nacisk na obronę wielowarstwową: zapobiegaj kradzieży poświadczeń tam, gdzie to możliwe, szybko wykrywaj nadużycia i umożliwiaj efektywną reakcję na incydenty.

---

Nowy tytuł + akapit rejestracyjny — WP‑Firewall Basic (Darmowy)

Zabezpiecz swoją stronę już dziś z WP‑Firewall Basic (Darmowy) — niezbędna ochrona bez żadnych kosztów

Jeśli nie jesteś jeszcze chroniony, zacznij od WP‑Firewall Basic (Darmowy). Oferuje niezbędną zarządzaną ochronę zapory, nieograniczoną przepustowość, zaporę WAF klasy przedsiębiorstw, automatyczne skanowanie złośliwego oprogramowania i łagodzenie ryzyk OWASP Top 10 — wszystko, czego potrzebujesz, aby zatrzymać większość oportunistycznych ataków i wykryć wczesne oznaki kompromitacji. Rejestracja zajmuje tylko kilka minut i jest praktycznym pierwszym krokiem po zainstalowaniu krytycznej aktualizacji, takiej jak 9.5.10.1. Rozpocznij tutaj: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Dla stron, które potrzebują więcej: Standard dodaje automatyczne usuwanie złośliwego oprogramowania i zarządzanie dozwolonymi/zakazanymi adresami IP; Pro obejmuje miesięczne raporty, automatyczne łatki wirtualne tam, gdzie to możliwe, oraz premium dodatki i wsparcie.)

---

Najczęściej zadawane pytania (odpowiedzi ekspertów)

Q: Jeśli atakujący już ma hasło, czy jakakolwiek zapora może zapobiec szkodom?
A: Zapora może zmniejszyć prawdopodobieństwo kradzieży poświadczeń (blokowanie botów, limity prędkości, wykrywanie anomalii) i może zablokować niektóre automatyczne próby wykorzystania. Ale jeśli atakujący autoryzuje się w sposób legalny i naśladuje normalne zachowanie administratora, wymagane są kontrole na poziomie aplikacji (łatki, minimalne uprawnienia, MFA, szybkie wykrywanie), aby ograniczyć wpływ.

Q: Zaktualizowałem wtyczkę. Czy muszę jeszcze wykonać inne kroki?
A: Tak. Najpierw załatw łatkę wtyczki. Następnie zmień hasła administratorów, wymuś MFA, przeskanuj w poszukiwaniu złośliwego oprogramowania i przeglądaj logi, aby upewnić się, że nie doszło do kompromitacji przed aktualizacją.

Q: Co jeśli nie mogę zaktualizować od razu?
A: Tymczasowo ogranicz dostęp do punktów końcowych administracyjnych, wymuś dozwolone adresy IP, wymuś resetowanie haseł i MFA oraz zaplanuj aktualizację jako swój najwyższy priorytet.

---

Ostateczne zalecenia — priorytetowo traktuj te działania teraz

1. Natychmiast zaktualizuj Really Simple SSL do 9.5.10.1 (lub nowszej).
2. Wymuś resetowanie haseł i włącz MFA dla wszystkich uprzywilejowanych użytkowników.
3. Przejrzyj konta użytkowników i ostatnią aktywność w poszukiwaniu oznak kompromitacji.
4. Przeskanuj stronę i usuń wszelkie tylne drzwi lub nieautoryzowane pliki.
5. Zarejestruj się w zarządzanym planie bezpieczeństwa (zacznij od podstawowej, darmowej ochrony, jeśli nie masz jeszcze WAF) i włącz ciągłe monitorowanie.

Ta luka jest aktualnym przypomnieniem: aktualizacje wtyczek i silne praktyki uwierzytelniania są twoją pierwszą linią obrony. Jeśli potrzebujesz pomocy w triage, łatach lub dochodzeniach, postępuj zgodnie z wewnętrznym procesem reagowania na incydenty — i rozważ dodanie zarządzanych zabezpieczeń, aby wykrywać i blokować atakujących, zanim się dostaną.

Bądź bezpieczny,
Zespół ds. bezpieczeństwa WP‑Firewall