| Nazwa wtyczki | Wtyczka nagłówków HTTP WordPress |
|---|---|
| Rodzaj podatności | Wrażliwość nagłówka HTTP |
| Numer CVE | CVE-2026-2717 |
| Pilność | Niski |
| Data publikacji CVE | 2026-04-22 |
| Adres URL źródła | CVE-2026-2717 |
Pilne: Wstrzyknięcie CRLF w wtyczce nagłówków HTTP WordPress (≤ 1.19.2, CVE-2026-2717) — Co właściciele stron i administratorzy muszą zrobić teraz
Opublikowany: 21 kwi, 2026
Autor: Zespół ds. bezpieczeństwa WP‑Firewall
Ten post jest napisany z perspektywy zespołu ds. bezpieczeństwa WordPress w WP‑Firewall. Analizujemy wrażliwość, wyjaśniamy rzeczywiste scenariusze ryzyka i podajemy praktyczne, krok po kroku wskazówki dotyczące łagodzenia i wykrywania, które możesz wdrożyć natychmiast — w tym sygnatury WAF i porady dotyczące wzmocnienia, które możesz wykorzystać, czekając na oficjalną poprawkę wtyczki.
Podsumowanie w skrócie
- Oprogramowanie dotknięte: wtyczka WordPress “HTTP Headers” — wersje ≤ 1.19.2
- Wrażliwość: Wstrzyknięcie CRLF (Carriage Return / Line Feed) uwierzytelnionego (Administrator) (klasyfikowane jako wstrzyknięcie nagłówka HTTP / dzielenie odpowiedzi)
- CVE: CVE-2026-2717
- Wymagane uprawnienia: dostęp na poziomie administratora do WordPress (uwierzytelniony)
- Powaga: Niska (wynik Patchstack 5.5) — ryzyko kontekstowe wzrasta, jeśli konto administratora zostanie skompromitowane, lub jeśli celowe wykorzystanie wrażliwości prowadzi do zanieczyszczenia pamięci podręcznej lub XSS.
- Natychmiastowe działanie: Zaktualizuj wtyczkę, jeśli dostępna jest poprawka. Jeśli nie, zastosuj poniższe łagodzenia (wirtualna poprawka WAF, oczyszczanie nagłówków odpowiedzi, ograniczenie dostępu administratora, monitorowanie dzienników, skanowanie strony).
Ważna uwaga: To odpowiedzialny, skoncentrowany na naprawie opis dla właścicieli stron, administratorów i zespołów ds. bezpieczeństwa. Nie publikujemy kodu exploitów ani instrukcji krok po kroku dotyczących eksploatacji.
Czym jest wstrzyknięcie CRLF i dlaczego ma znaczenie?
Wstrzyknięcie CRLF (czasami nazywane wstrzyknięciem nagłówka lub dzieleniem odpowiedzi HTTP) występuje, gdy nieufne dane wejściowe są wstawiane do nagłówka HTTP lub w dowolne miejsce, które staje się częścią nagłówka HTTP, bez odpowiedniego usunięcia znaków CR (carriage return,
) i LF (line feed,
) oraz ich odpowiedników zakodowanych w URL (%0d, %0a). Atakujący, który może wstrzyknąć sekwencje CRLF, może manipulować strukturą odpowiedzi HTTP:
- Wstaw nowe nagłówki do odpowiedzi (np. ustawić dowolne nagłówki Set-Cookie lub Cache-Control).
- Zakończ nagłówki i wstrzyknij dodatkowe treści odpowiedzi (dzielenie odpowiedzi), co może prowadzić do zanieczyszczenia pamięci podręcznej lub skryptów międzywitrynowych (XSS), gdy pamięci podręczne lub komponenty downstream niewłaściwie obsługują odpowiedzi.
- Manipuluj kluczami pamięci podręcznej, co może spowodować, że inni użytkownicy otrzymają zanieczyszczone odpowiedzi z pamięci podręcznej.
Ponieważ ta luka wymaga uprawnień administratora w witrynie WordPress, natychmiastowa możliwość wykorzystania na prawidłowo zarządzanej witrynie jest ograniczona do:
- Złośliwych lub skompromitowanych użytkowników admina (zagrożenia wewnętrzne).
- Atakującego, który już ma dane uwierzytelniające administratora poprzez inne naruszenie (ponowne użycie danych uwierzytelniających, phishing, przejęcie sesji).
- Ataku łańcuchowego, w którym inna luka daje uprawnienia administratora.
Mimo to, wpływ niewłaściwego użycia jest istotny: zanieczyszczenie pamięci podręcznej może dotknąć wielu odwiedzających, lub atakujący może wstrzyknąć nagłówki, które zmieniają ciasteczka lub zachowanie pamięci podręcznej. Dla witryn o wysokiej wartości obecność tej luki jest warta natychmiastowego złagodzenia.
Jak to zazwyczaj występuje w wtyczkach WordPress
Wtyczki, które pozwalają administratorom definiować niestandardowe nagłówki odpowiedzi (w celu wzmocnienia bezpieczeństwa, konfiguracji CORS, HSTS itp.), czasami przechowują nazwę i wartość nagłówka podanego przez administratora w bazie danych, a następnie emitują je bezpośrednio za pomocą PHP’s nagłówek() funkcji lub zapisując je w szablonach odpowiedzi. Jeśli wtyczka nie zweryfikuje ani nie oczyści nazwy nagłówka lub wartości nagłówka, aby usunąć CRLF i zakodowane odpowiedniki, atakujący kontrolujący wartość nagłówka może zakończyć nagłówek i wstrzyknąć dowolną treść.
Typowe ryzykowne wzorce obejmują:
- echoing lub
nagłówek()z nieoczyszczonymi wartościami opcji. - używanie
wp_redirectLubsetcookiez połączonymi wartościami użytkownika bez walidacji. - przechowywanie surowych ciągów nagłówków w bazie danych i odtwarzanie ich w odpowiedziach.
Odpowiednie rozwiązanie to walidacja wejścia i oczyszczanie wyjścia: zabronić znaków CRLF w nazwach i wartościach nagłówków oraz walidować nazwy według ścisłego wzoru (litery, cyfry, myślnik) i wartości według zasad treści odpowiednich dla nagłówka.
Natychmiastowe kroki łagodzące (w kolejności)
- Potwierdź swoje narażenie
- Zidentyfikuj, czy strona używa wtyczki HTTP Headers i sprawdź jej wersję. Jesteś dotknięty, jeśli wersja wtyczki wynosi ≤ 1.19.2.
- Sprawdź, czy twoja strona pozwala administratorom na konfigurowanie dowolnych nazw/ wartości nagłówków za pomocą ustawień wtyczki.
- Zaktualizuj wtyczkę (jeśli dostępna jest łatka)
- Preferowane rozwiązanie: zaktualizuj wtyczkę, gdy dostawca wyda poprawioną wersję. Najpierw przetestuj aktualizację w środowisku testowym.
- Jeśli dostępna jest oficjalna łatka, zastosuj ją tak szybko, jak to możliwe po przetestowaniu zgodności.
- Jeśli nie ma dostępnej łatki, tymczasowo dezaktywuj wtyczkę
- Jeśli to możliwe i wtyczka nie jest wymagana do podstawowej funkcjonalności strony, dezaktywuj ją, aż zostanie wydana i przetestowana łatka.
- Jeśli nie możesz dezaktywować, zastosuj wirtualne łatanie (WAF)
- Na WP‑Firewall zalecamy zastosowanie jednej lub więcej krótkoterminowych reguł WAF, aby zablokować próby wstrzykiwania CRLF (przykłady poniżej).
- Natychmiast zablokuj konta administratorów
- Przejrzyj wszystkie konta administratorów. Usuń lub zdegradować wszelkich zbędnych użytkowników admina.
- Włącz uwierzytelnianie wieloskładnikowe (MFA) dla wszystkich użytkowników administracyjnych.
- Wymuś reset hasła dla wszystkich administratorów, jeśli podejrzewasz naruszenie danych uwierzytelniających.
- Audytuj ostatnią aktywność administratorów (tworzenie użytkowników, zmiany ustawień wtyczek) i sprawdź pulpity nawigacyjne pod kątem nieoczekiwanych modyfikacji.
- Skanuj witrynę pod kątem kompromitacji
- Przeprowadź pełne skanowanie złośliwego oprogramowania i integralności plików. Szukaj podejrzanej treści utworzonej przez administratorów oraz zmodyfikowanych plików rdzenia/wtyczek.
- Sprawdź logi serwera pod kątem podejrzanych żądań (szukaj
%0A,%0D, - Sprawdź zachowanie pamięci podręcznej (CDN lub odwrotne proxy) pod kątem nieoczekiwanej treści.
- Wdrażaj długoterminowe wzmocnienia opisane później w tym poście.
Praktyczne wykrywanie: na co zwracać uwagę w logach i pamięciach podręcznych
- Przeszukaj logi dostępu i logi WAF w poszukiwaniu zakodowanych sekwencji CR/LF:
%0d,%0a,%0D,%0A, lub dosłownie
Przykład grep:grep -iE '|| |
- Szukaj nietypowych nagłówków w odpowiedziach HTTP wysyłanych do klientów (użyj
curl -I) oraz wszelkich nagłówków “set-cookie”, które zawierają nieoczekiwane tokeny lub wiele ciasteczek tam, gdzie powinno być jedno. - Anomalie pamięci podręcznej CDN / reverse proxy: użytkownicy zgłaszający niespójną zawartość lub wstrzyknięte skrypty; niezgodne strony w pamięci podręcznej między użytkownikami.
- Logi błędów serwera WWW dla powtarzających się POST-ów lub żądań admin-ajax.php zawierających ciągi podobne do nagłówków.
Jeśli znajdziesz dowody na wykorzystanie (zatrute strony w pamięci podręcznej serwowane innym użytkownikom, wstrzyknięte skrypty), traktuj to jako kompromitację: postępuj zgodnie z procesem reagowania na incydenty, rozważ wyłączenie strony do czasu oczyszczenia, zmień dane uwierzytelniające i przywróć z znanego dobrego kopii zapasowej, jeśli to konieczne.
Reguły WAF, które możesz zastosować teraz (wirtualne łatanie)
Poniżej znajdują się przykładowe reguły, które możesz wdrożyć w swoim WAF (lub w WP‑Firewall, jeśli korzystasz z naszego zarządzanego WAF), aby zablokować ładunki wstrzyknięcia CRLF i zmniejszyć ryzyko, aż zostanie zastosowana oficjalna łatka wtyczki. To są wzorce defensywne — dostosuj i testuj, aby uniknąć fałszywych pozytywów.
Ważny: testuj każdą regułę w środowisku testowym i używaj trybu monitorowania lub tylko logowania przed zablokowaniem w produkcji.
1) Ogólna blokada dla znaków CRLF w parametrach żądania i wartościach nagłówków (przykład ModSecurity)
# ModSecurity (3.x) przykład: zablokuj znaki CRLF w żądaniu, jeśli zostaną znalezione w nagłówkach, ciele lub zapytaniu"
2) Specyficzna reguła dla punktów końcowych administratora (punkty końcowe POST administratora WordPressa)
# Zablokuj próby iniekcji CRLF skierowane na admin-ajax.php i opcje wp-admin"
3) Nginx (ngx_http_rewrite_module) szybka blokada dla żądań zawierających zakodowane CRLF w URI lub ciągu zapytania:
# W bloku serwera (najpierw przetestuj w staging)
4) Blokuj podejrzane wartości nagłówków (przykład powszechnych nadużyć)
- Blokuj żądania z nazwami nagłówków lub wartościami zawierającymi CRLF / zakodowane CRLF:
if ($http_some_header ~* "(|| |
5) Zalecana polityka WP‑Firewall
- Zastosuj zarządzaną regułę, która oczyszcza lub usuwa CR/LF z danych wejściowych do każdej funkcji lub punktu końcowego, który modyfikuje nagłówki odpowiedzi.
- Umieść regułę wyżej w łańcuchu, aby sprawdzić i zablokować POST-y do punktów końcowych ustawień wtyczek (stron, które akceptują niestandardowe wartości nagłówków).
- Dodaj do białej listy znane bezpieczne adresy IP administratorów (jeśli Twoi administratorzy mają stałe adresy IP) dla stron administracyjnych, a inne adresy IP blokuj lub wyzwijaj za pomocą CAPTCHA.
Uwagi:
- Użyj trybu tylko do logowania, aby dostosować reguły przez 48–72 godziny przed twardym zablokowaniem.
- Jeśli polegasz na CDN (chmurze/krawędzi), możesz dodać podobne reguły inspekcji żądań na warstwie krawędzi, aby zapobiec wprowadzeniu zainfekowanej treści do pamięci podręcznej.
Konkretne środki zaradcze po stronie PHP, które powinni zastosować deweloperzy
Jeśli jesteś autorem wtyczki lub deweloperem strony, który dostosowuje zachowanie wtyczki, zastosuj następujące zmiany po stronie serwera, aby upewnić się, że wartości nagłówków są bezpieczne przed ich emisją.
- Waliduj nazwy nagłówków
Akceptuj tylko ścisły zestaw znaków dla nazw nagłówków: litery, cyfry, myślnik. Przykład regex:
$valid_name_pattern = '/^[A-Za-z0-9-]+$/';
- Oczyść wartości nagłówków, aby usunąć CRLF (i odpowiedniki zakodowane procentowo)
Usuń CR (nagłówek().
Przykład funkcji oczyszczającej:
function wpfirewall_sanitize_header_value($value) {
Następnie użyj tego:
$header_name = 'X-Custom-Header';
- Użyj pomocników sanitarnych WordPressa tam, gdzie to możliwe
dezynfekuj_pole_tekstowe()może pomóc, ale nie polegaj na tym wyłącznie, aby usunąć CRLF; połącz z wyraźnym usuwaniem CRLF dla nagłówków. - Unikaj przechowywania surowych ciągów nagłówków
Przechowuj nazwę nagłówka i wartość nagłówka osobno w bazie danych i waliduj każdy przy zapisie. - Wdrażaj walidację po stronie serwera przy zapisywaniu opcji
Gdy administrator aktualizuje ustawienia wtyczki, waliduj dane wejściowe po stronie serwera (nie tylko w JavaScript po stronie klienta), aby upewnić się, że CRLF zostały odrzucone.
Lista kontrolna reagowania na incydenty
Jeśli odkryjesz, że jesteś dotknięty i/lub potencjalnie wykorzystany, postępuj zgodnie z tą listą kontrolną:
Natychmiast (0–4 godziny)
- Zastosuj regułę WAF, aby zablokować próby wstrzyknięcia CRLF (zobacz reguły WAF powyżej) i zarejestruj szczegóły.
- Jeśli to możliwe, tymczasowo wyłącz podatną wtyczkę.
- Wymuś reset hasła administratora i włącz MFA.
- Zrób zrzut strony (pliki i DB) i zbierz logi do analizy kryminalistycznej.
Krótkoterminowo (4–48 godzin)
- Skanuj w poszukiwaniu webshelli, podejrzanej treści utworzonej przez administratora, nieautoryzowanych użytkowników i zmodyfikowanych plików.
- Sprawdź logi serwera i logi WAF w poszukiwaniu podejrzanych żądań i zidentyfikuj adresy IP.
- Jeśli podejrzewasz zanieczyszczenie pamięci podręcznej, opróżnij pamięci podręczne CDN/edge i wszelkie pamięci podręczne odwrotnego proxy.
- Rotuj wszelkie ujawnione sekrety (klucze API, dane uwierzytelniające) używane przez stronę.
Odzyskiwanie i kontynuacja (48 godzin+)
- Przywróć z czystej kopii zapasowej, jeśli wykryto naruszenie.
- Przeprowadź analizę po incydencie: jak konto administratora zostało naruszone? Czy doszło do ponownego użycia poświadczeń? Zrewiduj polityki.
- Zastosuj długoterminowe środki zaradcze: wdrożenie monitorowania zmian plików, ograniczenie kont administratorów, ustawienie okresowych skanów bezpieczeństwa.
Komunikacja
- Powiadom interesariuszy i klientów, jeśli dane klientów lub treść witryny mogą być zagrożone.
- Udokumentuj podjęte działania i harmonogramy.
Dlaczego wymóg posiadania uprawnień administratora wciąż ma znaczenie
Ponieważ wykorzystanie tej konkretnej luki CRLF wymaga uprawnień administratora, kluczowym elementem redukcji ryzyka jest zapewnienie, że konta administratorów są odpowiednio zabezpieczone:
- Użyj separacji ról: unikaj przyznawania praw administratora kontom, które potrzebują tylko uprawnień edytora/autora.
- Ogranicz liczbę administratorów i rotuj odpowiedzialności.
- Używaj silnych, unikalnych haseł i egzekwuj MFA dla wszystkich użytkowników administratora.
- Regularnie audytuj konta administratorów i sesje; zakończ nieaktualne sesje.
- Użyj białej listy IP dla dostępu do wp-admin, gdzie to możliwe.
Te kroki zmniejszają prawdopodobieństwo, że luka wymagająca dostępu administratora stanie się wykorzystywalna na dużą skalę.
Dla właścicieli witryn WordPress: priorytetowy plan działania (szybka lista kontrolna)
- Zidentyfikuj: Czy używasz wtyczki HTTP Headers? Czy wersja ≤ 1.19.2? (Sprawdź pulpit wtyczki lub pliki wtyczki.)
- Chroń: Jeśli dostępna jest poprawka — zaktualizuj. Jeśli nie, usuń lub dezaktywuj wtyczkę do czasu naprawienia.
- Wzmocnij: Egzekwuj MFA, silne hasła i przeglądaj konta administratorów.
- Wirtualna poprawka: Zastosuj zasady WAF, aby zablokować sekwencje CRLF w punktach końcowych administratora oraz w parametrach/nagłówkach.
- Monitor: Przeszukaj logi w poszukiwaniu /, nieoczekiwanych nagłówków Set-Cookie i anomalii w pamięci podręcznej.
- Skanuj i czyść: Uruchom skanowanie złośliwego oprogramowania i kontrole integralności plików. Przywróć z kopii zapasowej, jeśli to konieczne.
- Komunikacja: Jeśli podejrzewasz naruszenie, powiadom wewnętrzne zespoły i wyłącz stronę, jeśli to konieczne.
Przykładowe zapytania detekcyjne i wskazówki kryminalistyczne
- Sprawdź logi pod kątem zakodowanych ładunków CRLF:
zgrep -E "|| |
- Szukaj nagłych zmian w wierszach tabeli opcji wtyczki dla nagłówków HTTP:
SELECT option_name, option_value FROM wp_options WHERE option_name LIKE '%http_header%' OR option_value LIKE '% %' OR option_value LIKE '% %' LIMIT 50;
- Potwierdź brak nieautoryzowanych użytkowników administratora:
WYBIERZ ID, user_login, user_email, user_registered, user_status Z wp_users GDZIE ID W (WYBIERZ user_id Z wp_usermeta GDZIE meta_key = 'wp_capabilities' I meta_value LIKE 'ministrator%');
Wskazówki dla deweloperów: bezpieczne wzorce dla emisji nagłówków
- Nigdy nie akceptuj surowych ciągów nagłówków dostarczonych przez administratora. Oddziel nazwy i wartości oraz zweryfikuj.
- Ogranicz wartości nagłówków do maksymalnej długości odpowiedniej dla nagłówka.
- Rozważ listę dozwolonych nazw nagłówków (np. X-Frame-Options, X-Content-Type-Options, Content-Security-Policy) i nie zezwalaj na dowolne nazwy nagłówków.
- Użyj kanonicznego przepływu aktualizacji z sanacją po stronie serwera podczas zapisywania ustawień (sanitizuj opcje przy zapisie, a nie tylko przy wyjściu).
Jak WP‑Firewall pomaga (wirtualne łatanie, monitorowanie i ochrona)
W WP‑Firewall oferujemy natychmiastową i praktyczną opcję łagodzenia luk, takich jak ta:
- Zarządzane zasady WAF dostosowane do blokowania prób wstrzyknięcia CRLF w punktach końcowych administratora i znanych wzorcach wtyczek — wdrażane natychmiast bez zmian w kodzie na stronie.
- Sanacja nagłówków odpowiedzi na krawędzi — możemy zapewnić, że nagłówki odpowiedzi są pozbawione CRLF, zanim dotrą do klientów lub pamięci podręcznych.
- Ciągłe skanowanie i monitorowanie w celu wykrywania podejrzanych zmian po stronie administratora i anomalii w żądaniach, które pasują do wzorców wstrzyknięcia.
- Na żądanie awaryjne “wirtualne łatanie”, które stosuje tymczasowe zasady, aby zatrzymać eksploatację, aż dostawca opublikuje oficjalną łatę.
Jeśli używasz WP‑Firewall, nasi inżynierowie mogą pomóc w wdrożeniu dostosowanych zasad dla Twojej strony i udzielić wskazówek dotyczących bezpiecznych aktualizacji wtyczek i naprawy.
Chroń swoją stronę teraz z darmowym planem WP‑Firewall
Jeśli chcesz natychmiastowej podstawowej ochrony podczas zarządzania aktualizacjami i wzmacnianiem, rozważ rozpoczęcie od planu WP‑Firewall Basic (darmowy). Zapewnia on podstawową ochronę — zarządzany firewall, nielimitowaną przepustowość, pokrycie WAF, skanowanie złośliwego oprogramowania oraz łagodzenie skoncentrowane na ryzykach OWASP Top 10 — wszystko bez kosztów wstępnych. To idealny pierwszy krok dla właścicieli stron, którzy chcą zautomatyzowanej obrony i wirtualnych poprawek opartych na WAF dla nowo odkrytych problemów.
Dowiedz się więcej i zarejestruj się: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
(Jeśli potrzebujesz dodatkowych funkcji — automatyczne usuwanie złośliwego oprogramowania, czarną/białą listę adresów IP, miesięczne raporty bezpieczeństwa lub wirtualne poprawki plus dedykowane wsparcie — rozważ nasze poziomy Standard i Pro.)
Długoterminowe strategie obronne (poza natychmiastową naprawą)
- Najmniejsze uprawnienia i zarządzanie administracyjne
- Przyjmij model najmniejszych uprawnień dla ról użytkowników. Używaj dedykowanych kont serwisowych zamiast ręcznego zarządzania poświadczeniami administratora.
- Regularnie usuwaj nieużywanych użytkowników administracyjnych i rejestruj dostęp z uprawnieniami.
- Bezpieczny cykl życia wtyczki
- Prowadź inwentaryzację wszystkich wtyczek i motywów oraz priorytetyzuj aktualizacje dla tych, które wpływają na obsługę żądań/odpowiedzi.
- Testuj aktualizacje w środowisku staging. Miej procedury przywracania dla aktualizacji wtyczek, które powodują problemy.
- Utwardzanie aplikacji
- Używaj CSP (Content-Security-Policy), HSTS (Strict-Transport-Security) i innych nagłówków, aby zredukować wpływ XSS i manipulacji ciasteczkami, nawet jeśli wystąpi wstrzyknięcie nagłówka.
- Wdrażaj bezpieczne flagi ciasteczek: atrybuty HttpOnly, Secure i SameSite.
- Obrona w głębokości
- Łącz ochronę WAF, wykrywanie anomalii, monitorowanie integralności plików i ochronę punktów końcowych dla administratorów stron.
- Używaj scentralizowanego rozwiązania do logowania i SIEM, jeśli zarządzasz wieloma stronami, aby wykrywać wzorce w zasobach.
- Przygotowanie na incydenty
- Utrzymuj solidne kopie zapasowe z częstymi testami procedur przywracania.
- Miej podręcznik reakcji na incydenty, który zawiera kroki dotyczące luk w wtyczkach i możliwych zdarzeń związanych z zanieczyszczeniem pamięci podręcznej.
Ostateczne uwagi i zalecane następne kroki
- Jeśli Twoja strona używa wtyczki affected HTTP Headers (≤ 1.19.2), natychmiast zidentyfikuj wersję i priorytetyzuj działania. Najszybszą bezpieczną opcją jest aktualizacja do poprawionej wersji. Jeśli poprawka nie została jeszcze wydana, dezaktywuj wtyczkę lub zastosuj powyższe opcje wirtualnych poprawek.
- Pamiętaj, że w tym przypadku wymagane są uprawnienia administratora do wykorzystania tej luki — zmniejsz liczbę administratorów, wymuszaj MFA i rotuj poświadczenia.
- Wdrażaj zasady WAF i sanitizację nagłówków odpowiedzi, aby zapobiec wstrzyknięciom ładunków CRLF do pamięci podręcznej lub ich emisji do klientów.
- Monitoruj logi pod kątem zakodowanych wzorców CRLF i oznak zanieczyszczenia pamięci podręcznej.
Jeśli potrzebujesz pomocy w wdrażaniu zasad WAF, stosowaniu wirtualnych poprawek lub audytowaniu swoich kont administracyjnych i konfiguracji wtyczek, WP‑Firewall oferuje dostosowaną pomoc i zarządzane plany. Rozpocznij od naszego darmowego planu, aby uzyskać natychmiastową ochronę rdzenia: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Bądź bezpieczny — ochrona swoich kont administracyjnych i sanitizacja nagłówków zneutralizuje najniebezpieczniejsze wektory ataku, które zależą od tej luki.
— Zespół ds. bezpieczeństwa WP‑Firewall
Zastrzeżenie: Niniejsze powiadomienie ma na celu jedynie cele obronne i naprawcze. Nie publikujemy kodu exploitów. Postępuj zgodnie z odpowiedzialnym ujawnianiem i procesami łatania.
