Nazwa wtyczki	WPGraphQL
Rodzaj podatności	Podrabianie żądań między witrynami (CSRF)
Numer CVE	CVE-2025-68604
Pilność	Niski
Data publikacji CVE	2026-05-07
Adres URL źródła	CVE-2025-68604

Pilne: WPGraphQL <= 2.5.3 — Luka CSRF (CVE-2025-68604) — Co właściciele stron WordPress powinni wiedzieć i zrobić teraz

Krótko mówiąc — Wtyczka WPGraphQL ujawniała problem z fałszywym żądaniem między witrynami (CSRF), który dotyczył wersji do 2.5.3 włącznie i został naprawiony w 2.5.4 (CVE‑2025‑68604). Chociaż luka jest oceniana jako niska/średnia w wielu systemach oceny (CVSS 5.4), może być użyta w połączeniu z inżynierią społeczną do wymuszenia działań uprzywilejowanego użytkownika, wykonania niebezpiecznych mutacji GraphQL i eskalacji wpływu. Natychmiast zaktualizuj do 2.5.4 lub nowszej. Jeśli nie możesz zaktualizować od razu, zastosuj kompensacyjne zasady WAF i wzmocnienia (przykładowe zasady w zestawie). Postępuj zgodnie z poniższą listą kontrolną wykrywania i usuwania.

---

Przegląd — co zostało ujawnione

7 maja 2026 opublikowano doradztwo dotyczące bezpieczeństwa opisujące lukę CSRF w WPGraphQL (wersje wtyczki <= 2.5.3). Problem został rozwiązany w wersji 2.5.4. Luka pozwala atakującemu na zmuszenie uwierzytelnionego użytkownika — zazwyczaj uprzywilejowanego użytkownika, takiego jak administrator lub redaktor — do nieświadomego wykonania mutacji GraphQL zmieniających stan, oszukując go, aby odwiedził przygotowaną stronę lub kliknął link.

Kluczowe fakty:

• Dotknięta wtyczka: WPGraphQL
• Wrażliwe wersje: <= 2.5.3
• Naprawione w: 2.5.4
• CVE: CVE‑2025‑68604
• Wektor ataku: CSRF — wymaga interakcji użytkownika (kliknięcie, odwiedzenie)
• Typowy wpływ: Nieautoryzowane zmiany stanu wykonywane w kontekście uwierzytelnionego użytkownika (np. tworzenie/edycja treści, modyfikacja opcji, tworzenie użytkowników w zależności od ujawnionych mutacji)
• Zalecana natychmiastowa akcja: Zaktualizuj do 2.5.4+ i zastosuj kompensacyjne zabezpieczenia, aż aktualizacja będzie możliwa

---

Jak działa CSRF w świecie WordPress + GraphQL (prosty język)

Ataki CSRF polegają na tendencji przeglądarki do automatycznego dołączania poświadczeń uwierzytelniających (ciasteczka, istniejące sesje) podczas odwiedzania strony kontrolowanej przez atakującego. Jeśli wtyczka udostępnia punkty końcowe, które wykonują zmiany stanu bez weryfikacji, że żądanie pochodzi z legalnej witryny lub zawiera ważne tokeny anty-CSRF, atakujący może przygotować zdalną stronę, która powoduje, że przeglądarka ofiary wysyła żądanie do tego punktu końcowego, będąc uwierzytelnioną — co sprawia, że witryna wykonuje działania w imieniu ofiary.

Punkty końcowe GraphQL to często pojedyncze punkty końcowe HTTP, które akceptują żądania POST zawierające mutację, która modyfikuje stan serwera. Jeśli te mutacje nie są chronione przez kontrole nonce, kontrole pochodzenia/odsyłacza lub kontrole uprawnień, są potencjalnymi celami CSRF.

W tym ujawnieniu, obsługa przez WPGraphQL niektórych żądań pozwalała na wystąpienie tego typu żądania między witrynami w pewnych warunkach. To sprawia, że każda uprzywilejowana rola, która może wywołać te mutacje, staje się celem podczas odwiedzania złośliwej strony.

---

Kto jest narażony na ryzyko?

• Witryny działające na WPGraphQL w dotkniętych wersjach (<= 2.5.3).
• Wszyscy uprzywilejowani użytkownicy WordPress, którzy mogą zostać oszukani do odwiedzenia stron atakujących (np. administratorzy, redaktorzy).
• Witryny udostępniające funkcjonalność administracyjną poprzez mutacje GraphQL lub pozwalające na wrażliwe zmiany konfiguracji za pośrednictwem GraphQL.
• Strony, które akceptują żądania do punktu końcowego GraphQL z publicznej sieci bez dodatkowych kontroli dostępu.

Mimo że CVSS jest umiarkowane (5.4), CSRF w połączeniu z inżynierią społeczną i innymi słabościami może prowadzić do poważnych kompromisów (nowi użytkownicy administratorzy, manipulacja treścią, zmiany konfiguracji, zmiany opcji wtyczek itp.). Małe strony i strony o wysokim profilu są narażone.

---

Scenariusze wykorzystania (realistyczne przykłady)

Nie podam kodu exploita, ale oto realistyczne wzorce ataków, na które należy zwrócić uwagę — wyjaśniają, dlaczego to ma znaczenie:

• Atakujący tworzy stronę internetową, która wysyła POST do https://victim.example.com/graphql zawierającego mutację GraphQL, która tworzy nowego użytkownika o niższych uprawnieniach lub modyfikuje treść istniejących postów.
• Administrator uwierzytelniony w swojej przeglądarce odwiedza stronę atakującego (phishingowy e-mail, osadzone treści na innej stronie) — przeglądarka dołącza ciasteczka strony, a mutacja GraphQL działa w kontekście administratora.
• Jeśli schemat GraphQL ujawnia mutacje dla ustawień wtyczek, opcji strony lub tworzenia użytkowników, atakujący może zmienić konfigurację, wstrzyknąć tylne drzwi lub stworzyć nowe konta administratorów (w zależności od uprawnień schematu).
• Atakujący mogą próbować masowego celowania: wysyłać pułapki phishingowe do wielu administratorów stron lub połączyć wektor CSRF z automatycznym skanowaniem, aby znaleźć dotknięte strony.

Ponieważ wykorzystanie wymaga oszukania prawdziwego użytkownika, wskaźniki incydentów są niższe niż w przypadku czysto nieautoryzowanego zdalnego wykonania kodu. Mimo to, to właśnie ten rodzaj podatności jest często wykorzystywany w ukierunkowanych kompromisach lub w masowych kampaniach opartych na inżynierii społecznej.

---

Natychmiastowe kroki (co zrobić teraz — kolejność priorytetów)

1. Natychmiast zaktualizuj WPGraphQL do wersji 2.5.4 lub nowszej.
   • W wp-admin: Wtyczki → Zainstalowane wtyczki → zaktualizuj WPGraphQL.
   • CLI: aktualizacja wtyczki wp-graphql
2. Jeśli nie możesz zaktualizować natychmiast, zastosuj pilne środki zaradcze (zobacz zasady WAF i serwera poniżej), aby zablokować prawdopodobne wektory CSRF.
3. Ogranicz dostęp do punktu końcowego GraphQL:
   • Wyłącz publiczny interfejs GraphiQL w produkcji.
   • Ogranicz dostęp do /graphql według IP lub chroniony przez autoryzację HTTP dla użytkowników administratorów, jeśli to możliwe.
4. Wymuś ciasteczka SameSite dla swojej strony (SameSite=Lax lub Strict), aby zmniejszyć ryzyko CSRF w żądaniach między stronami.
5. Zapewnij silne nonce i kontrole uprawnień dla wszelkich niestandardowych mutacji GraphQL — deweloperzy powinni audytować resolvery pod kątem odpowiednich kontroli autoryzacji.

Jeśli zarządzasz wieloma witrynami lub dostarczasz zarządzany WordPress, priorytetowo traktuj wdrożenia aktualizacji dla klientów i witryn testowych.

---

Wykrywanie — oznaki, że ta luka została wykorzystana

Sprawdź następujące wskaźniki natychmiast po odkryciu, że Twoja witryna używała podatnej wersji:

• Nieoczekiwani nowi użytkownicy (szczególnie z podwyższonymi rolami).
• Nieoczekiwane opublikowane/edytowane posty lub strony.
• Nagłe zmiany w opcjach wtyczek lub motywów, w tym wtyczek zabezpieczających.
• Podejrzane zaplanowane zadania (wp‑cron) dodane przez nieznane wtyczki lub użytkowników.
• Połączenia wychodzące do nieznanych zdalnych hostów (może wskazywać na tylne drzwi).
• Nieoczekiwane logowania administratora z nietypowych adresów IP lub w dziwnych porach.
• Dzienniki dostępu serwera WWW pokazujące POST-y do /graphql z zewnętrznymi odsyłaczami tuż przed zmianami stanu.
• Nietypowe wzorce mutacji GraphQL w dziennikach żądań (jeśli rejestrujesz operacje GraphQL).

Przeprowadź kontrolę integralności plików i skanowanie złośliwego oprogramowania. Przejrzyj ostatnie zmiany w bazie danych w poszukiwaniu podejrzanej aktywności (tabela użytkowników, tabela opcji, tabela postów).

---

Naprawa i odzyskiwanie — krok po kroku

Jeśli podejrzewasz wykorzystanie, postępuj zgodnie z listą kontrolną reakcji na incydenty:

1. Wprowadź witrynę w tryb konserwacji (aby ograniczyć szkody i zachować dowody).
2. Natychmiast zaktualizuj WPGraphQL do 2.5.4+.
3. Zmień wszystkie hasła administracyjne i klucze API (w tym klucze używane przez integracje).
4. Cofnij lub odśwież wszelkie tokeny lub dane uwierzytelniające osób trzecich dostępne przez witrynę.
5. Usuń podejrzanych użytkowników i pliki z tylnymi drzwiami. Jeśli nie jesteś pewien, przywróć z czystej kopii zapasowej wykonanej przed podejrzanym naruszeniem.
6. Skanuj system plików i bazę danych w poszukiwaniu wstrzykniętego złośliwego kodu oraz oczyść lub przywróć dotknięte pliki.
7. Wzmocnij bezpieczeństwo strony:
   • Zastosuj łagodzenia WAF/serwera WWW (przykłady poniżej).
   • Wymuś atrybut cookie SameSite.
   • Wyłącz GraphiQL lub punkty końcowe dewelopera na systemach produkcyjnych.
8. Sprawdź inne witryny i systemy, które dzielą dane uwierzytelniające lub hosting, w poszukiwaniu oznak ruchu bocznego.
9. Przejrzyj i zaostrz dostęp użytkowników administracyjnych.
10. Monitoruj logi i włącz alerty na przyszłe próby.

Jeśli Twoja witryna jest zarządzana, poinformuj swojego hosta lub partnera ds. reagowania na incydenty i poproś o logi kryminalistyczne, jeśli to konieczne.

---

Łagodzenia WAF i serwera — jak zyskać czas, aż będziesz mógł załatać.

Zapora aplikacji internetowej (WAF) może zapewnić natychmiastową ochronę, blokując podejrzane żądania mutacji GraphQL i wymuszając kontrole pochodzenia/odsyłacza. Poniżej znajdują się praktyczne podejścia do reguł, które możesz wdrożyć w swoim ogólnym WAF lub serwerze WWW (przykłady Nginx/ModSecurity). To są ogólne wzorce — dostosuj je, aby uniknąć fałszywych pozytywów w przypadku legalnych integracji.

Ważna koncepcja: Wymagaj, aby żądania GraphQL zmieniające stan (mutacje) pochodziły z tego samego pochodzenia i zawierały oczekiwane nagłówki lub tokeny. Blokuj nieoczekiwane POST-y do punktu końcowego GraphQL, które nie mają ważnego pochodzenia/odsyłacza lub które pasują do podpisów mutacji znanych z zmiany stanu.

Przykład ModSecurity (koncepcyjny) — blokuj POST do /graphql, gdzie Referer jest nieobecny lub nie jest Twoją domeną:

# Blokuj prawdopodobne POST-y CSRF do /graphql, które nie pochodzą z Twojej domeny"

Nginx + Lua / proste odrzucenie według pochodzenia/odsyłacza (pseudo-konfiguracja):

location = /graphql {

Uwaga: Niektóre legalne integracje (ustawienia headless, zewnętrzne integracje webhook) mogą wysyłać POST-y do Twojego punktu końcowego GraphQL. Jeśli tak, dodaj do białej listy konkretne adresy IP lub agenty użytkownika, zamiast ogólnie zezwalać na wszystkie POST-y bez Referera.

Inne podejście: blokuj żądania z podejrzanymi wzorcami treści (mutacje, które zawierają “createUser”, “updateOptions”, “updatePluginOptions” itp.). Przykład reguły ModSecurity, która szuka niebezpiecznych nazw mutacji:

SecRule REQUEST_METHOD "POST" \n  "chain, \n   SecRule REQUEST_URI \"^/graphql$\" \"chain,phase:2,t:none,log,deny,status:403,msg:'Zablokowano niebezpieczną mutację GraphQL'\" \n   SecRule REQUEST_BODY \"(mutation|createUser|updateOptions|createPluginSetting)\" \n"

Zastrzeżenie: dopasowywanie wzorców musi być przeprowadzane ostrożnie, aby nie złamać legalnych zastosowań. Najpierw przetestuj w trybie wykrywania/logowania i dostosuj.

Jeśli obsługujesz zarządzany WAF, poproś o tymczasową wirtualną łatkę, która:

• Blokuje nieautoryzowane POSTy do /graphql, które zawierają operacje mutacji, chyba że zawierają ważny token anty-CSRF.
• Blokuje żądania do GraphQL zawierające słowa kluczowe, które odpowiadają wrażliwym mutacjom, chyba że adresy IP źródłowe są na liście dozwolonych.

---

Lista kontrolna dla deweloperów — wzmocnienie użycia WPGraphQL

• Wymuszaj autoryzację po stronie serwera na resolverach. Nigdy nie polegaj wyłącznie na kontrolach frontendowych.
• Gdzie to możliwe, wymagaj, aby uwierzytelnione żądania zawierały sprawdzenie CSRF/nonce dla operacji zmieniających stan.
• Ogranicz zestaw mutacji dostępnych dla anonimowych użytkowników. Odrzuć potencjalnie niebezpieczne mutacje dla nieautoryzowanych lub nisko uprawnionych użytkowników.
• Unikaj ujawniania administracyjnych przepływów pracy za pośrednictwem GraphQL. Jeśli musisz, ogranicz dostęp do mutacji za pomocą sprawdzeń uprawnień (current_user_can) i dodatkowych sprawdzeń tokenów.
• Wyłącz lub usuń GraphiQL, narzędzia do debugowania GraphQL oraz introspekcję punktów końcowych w systemach produkcyjnych.
• Ogranicz liczbę POSTów do punktu końcowego GraphQL i monitoruj nietypowe wzrosty w wywołaniach mutacji.
• Użyj polityk bezpieczeństwa treści i nagłówków odpowiedzi HTTP (X-Frame-Options, Referrer-Policy), aby zmniejszyć powierzchnię ataku.

---

Monitorowanie i logowanie — co instrumentować

• Włącz logowanie żądań dla /graphql w tym ciało żądania lub przynajmniej nazwę operacji GraphQL (oczyść wrażliwe dane w razie potrzeby).
• Zapisz nagłówki Referer i Origin dla POSTów do /graphql.
• Powiadom o:
  • POSTów do /graphql z brakującymi nagłówkami Referer/Origin.
  • Wysoka liczba operacji mutacji w krótkim czasie.
  • Operacje mutacji z nazwami odpowiadającymi “createUser”, “updateOptions”, “installPlugin” itd.
• Zintegruj logowanie audytowe WordPressa, aby śledzić zmiany w użytkownikach, opcjach i instalacjach wtyczek.
• Użyj monitorowania integralności plików i zaplanowanych skanów.

---

Przykładowy scenariusz incydentu i przewodnik po odzyskiwaniu

1. Wykrycie: Zauważasz, że nieautoryzowany użytkownik administracyjny został utworzony, a opublikowana treść została zmieniona.
2. Działania natychmiastowe:
   • Tymczasowo zablokuj publiczny dostęp do /graphql (poprzez WAF lub serwer www).
   • Zaktualizuj wtyczkę WPGraphQL do 2.5.4+.
   • Zmień wszystkie dane logowania administratorów i klucze API; wymuś reset hasła dla administratorów.
   • Skanuj w poszukiwaniu tylnej furtki i usuń złośliwe pliki.
   • Przejrzyj logi dostępu, aby zidentyfikować adresy IP atakujących i początkowy punkt kompromitacji.
3. Powrót do zdrowia:
   • Przywróć czystą wersję strony z kopii zapasowej sprzed kompromitacji, jeśli modyfikacje są obszerne.
   • Wzmocnij GraphQL i włącz zasady WAF opisane wcześniej.
   • Monitoruj dalsze działania.
4. Po‑śmierci:
   • Zidentyfikuj wektor wejścia (zwykle inżynieria społeczna + niezałatana wtyczka).
   • Zastosuj wnioski organizacyjne, aby zmniejszyć przyszłe ryzyko (polityka łatania, szkolenie użytkowników, 2FA).

---

Dlaczego szybkie łatanie ma znaczenie (nawet dla problemów o niższym ciężarze)

Niższe numery CVSS są czasami mylące dla środowisk WordPress. Strony WordPress są często wysokowartościowe dla atakujących (dostęp do e‑commerce, subskrypcji, danych klientów). Co więcej, CSRF, który celuje w użytkownika administratora, jest w rzeczywistości windą do uprzywilejowanych działań, jeśli administrator zostanie oszukany, aby odwiedzić złośliwą stronę. Szybkie łatanie, plus WAF/wirtualne łatanie podczas wdrażania aktualizacji, zmniejsza okno narażenia dla oportunistycznych i ukierunkowanych atakujących.

---

Praktyczna lista kontrolna wzmocnienia (do skopiowania)

• [ ] Zaktualizuj WPGraphQL do 2.5.4 lub nowszej.
• [ ] Ogranicz dostęp do GraphiQL i punktów końcowych dewelopera w produkcji.
• [ ] Wymuś politykę ciasteczek SameSite i flagi zabezpieczeń.
• [ ] Dodaj zasady WAF, aby zablokować podejrzane POSTy GraphQL (sprawdzanie refererów, dopasowywanie słów kluczowych).
• [ ] Zmień hasła administratorów i klucze API, jeśli podejrzewasz kompromitację.
• [ ] Ogranicz role użytkowników i zastosuj zasadę najmniejszych uprawnień.
• [ ] Włącz uwierzytelnianie dwuskładnikowe dla kont administratorów.
• [ ] Dodaj monitorowanie i powiadomienia dla /graphql aktywności i zmian użytkowników.
• [ ] Przeprowadź pełne skanowanie złośliwego oprogramowania i integralności plików.
• [ ] Wprowadź regularny harmonogram łatania i szybkie wdrażanie aktualizacji dla krytycznych wtyczek.

---

Jak zarządzany WAF uzupełnia te działania

Zarządzany WAF zapewnia:

• Szybkie wirtualne łatanie — tymczasowe zasady, które blokują wzorce ataków, aż będziesz mógł zaktualizować wtyczki.
• Centralne dostosowywanie zasad w celu zmniejszenia fałszywych alarmów przy jednoczesnej ochronie wielu podobnych witryn.
• Telemetria ataków — widoczność prób wykorzystania w całym zarządzanym majątku.
• Łatwiejsze egzekwowanie kontroli Origin/Referer i blokad słów kluczowych mutacji bez konieczności wprowadzania zmian w kodzie.

Jeśli zarządzasz wieloma witrynami WordPress lub prowadzisz operacje wysokiego ryzyka (ecommerce, członkostwo, duży ruch), łączenie łatania z aktywnym WAF skraca czas reakcji i szkody.

---

Zabezpiecz swoją witrynę teraz — wypróbuj plan WP‑Firewall Free

Szybko zabezpiecz swoją witrynę WordPress dzięki naszemu podstawowemu darmowemu planowi w WP‑Firewall. Darmowy plan obejmuje podstawowe zabezpieczenia, które każda witryna powinna mieć: zarządzany zapora z zaporą aplikacji internetowej (WAF), ochronę przed nieograniczoną przepustowością, skanowanie złośliwego oprogramowania i łagodzenia zgodne z OWASP Top 10. Jest zaprojektowany, aby zapewnić małym witrynom, agencjom i projektom hobbystycznym natychmiastową podstawową ochronę, podczas gdy planujesz głębsze wzmocnienie lub zarządzane wdrożenie.

Dlaczego darmowy plan pomaga dzisiaj:

• Zasady zarządzanego WAF mogą być szybko wdrażane, aby blokować złośliwe żądania w stylu CSRF do punktów końcowych GraphQL, podczas gdy aktualizujesz wtyczki.
• Skaner złośliwego oprogramowania pomaga wykrywać oznaki kompromitacji (nieoczekiwane pliki, wstrzyknięty kod).
• Plan jest darmowy do rozpoczęcia — brak ryzyka, aby spróbować, a obejmuje podstawy, które zapobiegają wielu kampaniom masowego wykorzystania.

Zbadaj plan WP‑Firewall Basic (Darmowy) i zaktualizuj, gdy będziesz gotowy na zaawansowane funkcje, takie jak automatyczne usuwanie złośliwego oprogramowania, zarządzanie dozwolonymi/zakazanymi adresami IP, miesięczne raporty, wirtualne łatanie i zarządzane usługi bezpieczeństwa: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Najważniejsze cechy planu w skrócie)

• Podstawowy (bezpłatny): Zarządzany zapora, WAF, skaner złośliwego oprogramowania, nieograniczona przepustowość, łagodzenie OWASP Top 10.
• Standard ($50/rok): Dodaje automatyczne usuwanie złośliwego oprogramowania oraz czarną/białą listę IP (do 20 wpisów).
• Pro ($299/rok): Zawiera miesięczne raportowanie bezpieczeństwa, automatyczne wirtualne łatanie i premium zarządzane dodatki.

---

Przykładowe polecenia i kontrole (szybkie operacje)

Sprawdź aktualnie zainstalowaną wersję za pomocą WP‑CLI:

# lista wtyczek i wersji

Jeśli używasz phpMyAdmin lub bezpośrednich zapytań DB, sprawdź użytkownicy wp tabelę w poszukiwaniu podejrzanych kont:

WYBIERZ ID,user_login,user_email,user_registered,display_name Z wp_users PORZĄDEK wg user_registered DESC LIMIT 50;

Sprawdź logi dostępu dla POSTów do /graphql:

# przykład (logi nginx)

---

Ostateczne zalecenia — zachowaj higienę bezpieczeństwa

• Traktuj aktualizacje wtyczek jako wydarzenia bezpieczeństwa — stosuj je tak szybko, jak to możliwe, szczególnie gdy istnieje CVE.
• Połącz szybkie łatanie z wirtualnymi łatami WAF dla natychmiastowej ochrony na dużą skalę.
• Edukuj uprzywilejowanych użytkowników (administratorów i redaktorów), aby byli ostrożni wobec linków w e-mailach i nieznanych stron — inżynieria społeczna jest integralną częścią sukcesu CSRF.
• Używaj warstwowych zabezpieczeń: terminowe łatanie, skuteczny WAF, ścisłe uprawnienia oraz logowanie/monitorowanie.

Jeśli zarządzasz wieloma stronami klientów, zbuduj zautomatyzowane testowanie aktualizacji i przywracanie dla bezpiecznego, szybkiego wdrażania poprawek.

---

Podsumowanie

To ujawnienie CSRF WPGraphQL jest dobrym przypomnieniem, że nowoczesne wdrożenia WordPressa są systemami złożonymi: wtyczki, które eksponują punkty końcowe API, muszą być traktowane jak usługi publiczne. Luki CSRF są subtelne, ponieważ polegają na interakcji z legalnymi przeglądarkami i użytkownikami, ale mogą prowadzić do znaczących działań po uwierzytelnieniu, jeśli pozostaną niezałatane. Zastosuj powyższe natychmiastowe kroki — zaktualizuj wtyczkę, włącz ochronne zasady WAF, audytuj ostatnią aktywność — i rozważ zarządzane zabezpieczenia dla ciągłego spokoju umysłu.

Jeśli potrzebujesz pomocy w praktyce, nasz zespół specjalizuje się w awaryjnym łataniu, konfiguracji WAF i reagowaniu na incydenty dla stron WordPress. Zacznij od darmowego planu WP‑Firewall Basic, aby uzyskać natychmiastową ochronę zapory i skanowanie złośliwego oprogramowania, a następnie zaktualizuj w razie potrzeby do automatycznego czyszczenia i wirtualnego łatania: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Odniesienia i dalsza lektura

• Wtyczka WPGraphQL — notatki o aktualizacji i dzienniki zmian (sprawdź oficjalną stronę wydania wtyczki)
• CVE‑2025‑68604 — identyfikator podatności (publiczna lista CVE)
• Wytyczne OWASP dotyczące łagodzenia CSRF i najlepszych praktyk

---

Autor: Starszy inżynier bezpieczeństwa WordPress, WP‑Firewall
Jeśli masz szczegółowe informacje o stronie (host, wersje wtyczek, logi), dołącz je przy zgłaszaniu prośby o wsparcie, abyśmy mogli szybciej przeprowadzić triage.