Jedno anonimowe żądanie do zbiorczego punktu końcowego REST API rozstraja kontrolę uprawnień w WordPressie 6.9 i 7.0, a w parze z luką SQL daje przejęcie strony. CISA dała na łatanie tej luki tylko 3 dni.
Większość luk wpisywanych do katalogu CISA KEV robi szkodę sama. CVE-2026-63030 jest inna: to błąd w zbiorczym punkcie końcowym REST API WordPressa, który sam z siebie tylko myli trasy. Groźny staje się dopiero jako pierwsze ogniwo łańcucha z drugą luką, CVE-2026-60137. Badacze nazwali ten łańcuch wp2shell, bo prowadzi od jednego anonimowego żądania do wykonania kodu na serwerze.
Ten tekst patrzy na sprawę od strony ogniwa otwierającego: czym jest żądanie zbiorcze, co dokładnie się w nim psuło, dlaczego CISA dała na tę lukę 3 dni, a na lukę SQL 14 dni, i co z tego wynika dla firmy, która ma choćby jedną stronę na WordPressie.
21 lipca 2026 roku CISA dopisała do katalogu Known Exploited Vulnerabilities cztery pozycje, w tym dwie dotyczące rdzenia WordPressa. Katalog obejmuje wyłącznie luki z potwierdzonym wykorzystaniem w atakach, więc to nie jest ostrzeżenie teoretyczne. Łatki wyszły cztery dni wcześniej, 17 lipca 2026, a WordPress.org uruchomił dla podatnych stron wymuszone automatyczne aktualizacje.
Element | Szczegóły |
|---|---|
Identyfikator CVE | CVE-2026-63030 (GHSA-ff9f-jf42-662q, EUVD-2026-45280) |
Nazwa w katalogu CISA | WordPress Core Interpretation Conflict Vulnerability |
Data dodania do CISA KEV | 21 lipca 2026 |
Termin CISA (dueDate) | 24 lipca 2026, czyli 3 dni, z obowiązkiem triage kryminalistycznego (forensicTriage: Yes) |
Produkt | WordPress Core, zbiorczy punkt końcowy REST API: /wp-json/batch/v1 oraz alias ?rest_route=/batch/v1 |
Wersje zagrożone | 6.9.0-6.9.4, 7.0.0-7.0.1, a także 7.1 beta1 |
Wersje bezpieczne dla tej luki | 6.9.5, 7.0.2, 7.1 beta2 i nowsze; gałąź 6.8 i starsze nie zawierają tego błędu |
Wersja zalecana dziś | WordPress 7.1 (wydany 19 sierpnia 2026); kto zostaje na starszej gałęzi, powinien mieć co najmniej 7.0.4 lub 6.9.7 |
Typ podatności | CWE-436, konflikt interpretacji: pomylenie tras przy obsłudze żądań zbiorczych |
Ocena CVSS 3.1 | 9,8 KRYTYCZNA (WPScan) oraz 7,5 WYSOKA (CISA ADP); NVD nie wystawiło własnej oceny |
Ocena SSVC (CISA) | eksploatacja: aktywna; automatyzowalna: tak; wpływ techniczny: całkowity |
Kto zgłosił | Adam Kues, Assetnote / Searchlight Cyber |
Element | Szczegóły |
|---|---|
Identyfikator CVE | CVE-2026-60137 (GHSA-fpp7-x2x2-2mjf, EUVD-2026-45279) |
Data dodania do CISA KEV | 21 lipca 2026 |
Termin CISA (dueDate) | 4 sierpnia 2026, czyli 14 dni, bez flagi triage kryminalistycznego |
Produkt | WordPress Core, klasa WP_Query, parametr author__not_in |
Wersje zagrożone | 6.8.0-6.8.5, 6.9.0-6.9.4, 7.0.0-7.0.1 |
Wersje bezpieczne | 6.8.6, 6.9.5, 7.0.2 i nowsze |
Typ podatności | CWE-89, wstrzyknięcie SQL |
Ocena CVSS 3.1 | 5,9 ŚREDNIA (WPScan, wysoka złożoność) oraz 9,1 KRYTYCZNA (CISA ADP) |
Ocena SSVC (CISA) | eksploatacja: aktywna; automatyzowalna: nie; wpływ techniczny: całkowity |
Sam opis w NVD mówi wprost: pomylenie tras w połączeniu z luką SQL w parametrze author__not_in pozwala na wstrzyknięcie SQL i zdalne wykonanie kodu. Według ogłoszenia WordPressa wersja 6.9 ma oba błędy, a wersja 6.8 tylko lukę SQL.
Wyobraź sobie urząd, do którego można złożyć jedną teczkę z kilkoma wnioskami naraz. Urzędnik prowadzi trzy równoległe listy: spis wniosków, wynik sprawdzenia uprawnień i numer okienka, w którym dany wniosek zostanie załatwiony. Wszystko działa, dopóki pozycja 1 na każdej liście dotyczy tego samego wniosku.
Napastnik wkłada do teczki na pierwsze miejsce kartkę nieczytelną. Urzędnik zapisuje ją jako odrzuconą na liście sprawdzeń, ale zapomina dopisać ją na liście okienek. Od tej chwili każdy kolejny wniosek jest sprawdzany jako on sam, a załatwiany w okienku przeznaczonym dla następnego. Niewinna prośba o informację przechodzi kontrolę, po czym trafia do okienka, które zmienia wpisy w rejestrze. Kontrola zadziałała poprawnie, okienko też. Błąd leżał w przesunięciu między listami.
Druga luka to formularz w tym okienku: pole „wyklucz autorów” przyjmuje dopisany tekst i przepisuje go wprost do polecenia dla bazy danych. Pierwszy błąd daje obcemu dostęp do okienka, drugi pozwala mu wpisać w rejestrze, co zechce.
Scenariusz | Normalnie | Z podatnością |
|---|---|---|
Żądanie zbiorcze od anonimowego gościa | Każde pod-żądanie jest sprawdzane i wykonywane przez tę samą trasę | Po celowo zepsutym pierwszym pod-żądaniu kolejne wykonują się w trasie sąsiada |
Kontrola uprawnień | Blokuje operacje wymagające logowania | Przepuszcza niewinne żądanie, a wykonuje się uprzywilejowana obsługa |
Parametr author__not_in | Niedostępny dla anonimowych w groźnej formie | Osiągalny bez logowania i bez żadnej wtyczki |
Kto kontroluje stronę | Właściciel i redakcja | Napastnik, który może zyskać uprawnienia administratora i wgrać własny kod |
Jak to wygląda w logach | Zwykły ruch edytora bloków | Też jak zwykły ruch: POST do batch/v1, bez podejrzanych znaków |
Słowniczek: REST API to zestaw adresów, przez które programy, na przykład edytor bloków w panelu WordPressa, wymieniają dane z serwisem; zbiorczy punkt końcowy batch/v1 pozwala wysłać wiele takich zapytań w jednej paczce.
Mogę Ci jakoś pomóc?
Słowniczek: Konflikt interpretacji (CWE-436) to sytuacja, w której dwie części systemu rozumieją to samo żądanie inaczej; każda z nich działa zgodnie z projektem, a luka powstaje pomiędzy nimi.
Słowniczek: Wstrzyknięcie SQL to dopisanie własnych poleceń do zapytania, które aplikacja wysyła do bazy danych.
Po publikacji łatek mechanizm przestał być tajemnicą. Funkcja obsługująca żądania zbiorcze w klasie WP_REST_Server prowadziła trzy równoległe tablice: żądania, wyniki walidacji i dopasowane trasy. Gdy pod-żądanie było błędne już na etapie rozbioru adresu, błąd trafiał do tablicy walidacji, ale nie do tablicy tras. Poprawka w wersji 7.0.2 (commit „REST API: Ensure errors in batch requests propogate”) dopisuje brakujący element, więc tablice znów idą krok w krok. Druga zmiana z tego samego dnia („REST API: sub-requests must always use dispatch”) blokuje uruchomienie nowego, pełnego cyklu REST w trakcie obsługi pod-żądania.
Opiekunowie Debiana odnotowali, że w gałęzi 6.8 i starszych obsługa błędów w tej funkcji wyglądała inaczej, dlatego te wydania nie są podatne na pomylenie tras.
Według Searchlight Cyber atak nie ma warunków wstępnych: działa na standardowej instalacji WordPressa bez żadnych wtyczek, przez anonimowego użytkownika. CISA oceniła go jako automatyzowalny, co w praktyce oznacza masowe skanowanie całego internetu. Pierwsze publiczne exploity pojawiły się na GitHubie w ciągu godzin od ujawnienia, a pierwsze próby ataków odnotowano jeszcze w weekend 18-19 lipca.
Timeline ataku (czasy poglądowe, etapy zgodne z obserwacjami Wiz Research i F5 Labs):
Etap | Czas | Akcja hakerów | Wynik |
|---|---|---|---|
1 | T+0 min | Automatyczne skanowanie adresów w poszukiwaniu WordPressa 6.9.x i 7.0.x | Lista celów |
2 | T+1 min | POST do /wp-json/batch/v1 lub /?rest_route=/batch/v1 z paczką, w której pierwsze pod-żądanie jest celowo zepsute | Tablice w serwerze przesuwają się o jedną pozycję |
3 | T+1 min | Kolejne pod-żądania przechodzą kontrolę jako niewinne, a wykonują się w cudzej obsłudze z parametrem author__not_in | Wstrzyknięcie SQL bez logowania |
4 | T+2-5 min | Odczyt bazy, wyliczanie użytkowników przez /wp-json/wp/v2/users, próby odczytu wp-config | Loginy, adresy e-mail, dane dostępowe |
5 | T+5-15 min | Uzyskanie dostępu do panelu i wgranie złośliwej wtyczki przez formularz instalacji | Wykonanie kodu PHP na serwerze |
6 | T+15 min i dalej | Webshell lub tylna furtka działająca przez REST API | Trwały dostęp, także po późniejszej aktualizacji |
Wiz Research opisał trzy rodzaje webshelli użytych po udanym ataku: jednolinijkowy, rozbudowaną wtyczkę o rozmiarze około 150 KB i tylną furtkę opartą na REST API. F5 Labs przechwycił z kolei ładunek, który jedynie sprawdzał, czy wstrzyknięcie działa, bez instalacji webshella. Oba obrazy są prawdziwe: część ruchu to rozpoznanie, część to realne włamania.
Konkretne scenariusze zagrożenia:
Obszar biznesu | Potencjalny wpływ | Czas do wystąpienia | Koszty szacunkowe |
|---|---|---|---|
Operacyjny | Wyłączenie strony lub sklepu na czas analizy i odtwarzania | Godziny od wykrycia | 2 000-20 000 zł za dobę przestoju sklepu w MŚP |
Bezpieczeństwo danych | Odczyt bazy: konta, e-maile, zamówienia, skróty haseł | Minuty od ataku | Analiza powłamaniowa 15 000-80 000 zł |
Finansowy | Przekierowania na oszukańcze strony, podmiana treści, utrata sprzedaży | Dni | 10 000-150 000 zł |
Reputacyjny | Ostrzeżenia przeglądarek, spadek w wynikach wyszukiwania, utrata zaufania | Dni lub tygodnie | Spadek ruchu i sprzedaży o 10-40% na kilka miesięcy |
Prawny | Zgłoszenie naruszenia do UODO w 72 godziny, roszczenia, kary RODO | Tygodnie lub miesiące | Kary RODO do 20 mln EUR lub 4% rocznego obrotu |
Kwoty i procenty w tabeli to szacunki poglądowe dla małej lub średniej firmy, a nie dane z konkretnego incydentu; wyjątkiem jest górny limit kar RODO, który wynika z przepisów.
Mogę Ci jakoś pomóc?
Macierz ryzyka:
Wpływ
5 | ■ ← 6.9.x / 7.0.x: pełny łańcuch (KRYTYCZNA)
4 | □ ← 6.8.x: sama luka SQL, wymaga wtyczki
3 |
2 |
1 |
+-------------------------
1 2 3 4 5 Prawdopodobieństwo Prawdopodobieństwo jest na maksimum z czterech powodów: wpis w KEV, ocena „automatyzowalna” w SSVC, publiczne exploity oraz EPSS na poziomie 0,97271 (percentyl 0,99892, pomiar FIRST z 13 września 2026). Wpływ jest na maksimum, bo końcem łańcucha jest wykonanie kodu na serwerze. Instalacje na gałęzi 6.8 nie mają ogniwa otwierającego, więc ich pozycja w macierzy jest wyraźnie niższa, choć nie zerowa.
WPScan ocenił lukę na 9,8, z pełnym wpływem na poufność, integralność i dostępność. CISA w programie ADP dała 7,5, z wpływem tylko na poufność. Warunki ataku obie strony opisują tak samo: sieć, niska złożoność, bez uprawnień, bez udziału użytkownika. Najbardziej prawdopodobne odczytanie jest takie, że 9,8 opisuje skutek całego łańcucha, a 7,5 sam błąd w trasach. Żadne ze źródeł tego wprost nie wyjaśnia, więc to interpretacja. Dla decyzji biznesowej nie ma to znaczenia: sama CISA w ocenie SSVC przyjęła wpływ całkowity.
Priorytet | Działanie | Termin | Odpowiedzialny | Status |
|---|---|---|---|---|
🔴 NATYCHMIAST | Aktualizacja wszystkich instalacji do WordPress 7.1; na starszych gałęziach minimum 7.0.4 lub 6.9.7 | Dzisiaj | IT Manager lub agencja | ☐ |
🔴 NATYCHMIAST | Sprawdzenie, czy wymuszona aktualizacja z 17 lipca faktycznie się wykonała na każdej stronie | Dzisiaj | Administrator WordPressa | ☐ |
🔴 NATYCHMIAST | Tam, gdzie aktualizacja jest niemożliwa: blokada anonimowych żądań do obu form adresu batch/v1 | Dzisiaj | IT Security | ☐ |
🟠 PILNIE | Zabezpieczenie logów i przegląd od 17 lipca 2026: POST do batch/v1, odpowiedzi 207, User-Agent zawierający wp2shell lub rezwp2shell | 24-48h | Incident Response | ☐ |
🟠 PILNIE | Przegląd kont administratorów, listy wtyczek i plików PHP w katalogu wp-content/uploads | 24-48h | Administrator i Incident Response | ☐ |
🟠 PILNIE | Przy oznakach włamania: zmiana haseł, kluczy w wp-config i hasła do bazy danych | Do jutra po wykryciu | DevOps | ☐ |
🟡 WAŻNIE | Stały alarm na nowe konta administratorów i nietypowy ruch do batch/v1 | W ciągu tygodnia | SOC | ☐ |
Uwaga: jeśli podejrzewasz włamanie, najpierw skopiuj logi i pliki strony, dopiero potem aktualizuj; wytyczne CISA do triage kryminalistycznego każą w miarę możliwości zbierać dowody przed zmianami w systemie.
Jeśli aktualizacja nie jest dostępna:
Czasowa miara ochronna | Efektywność | Łatwość wdrożenia |
|---|---|---|
Blokada anonimowych żądań do /wp-json/batch/v1 i ?rest_route=/batch/v1 w zaporze WAF lub serwerze www | ok. 90-95% | Wysoka |
Zarządzane reguły WAF dostawcy (Cloudflare ogłosił, że blokuje ten łańcuch) | ok. 80-90% | Wysoka dla stron za Cloudflare |
Wtyczka typu must-use odrzucająca anonimowe żądania zbiorcze | ok. 90% | Średnia |
Wyłączenie REST API dla niezalogowanych | ok. 95% | Średnia, może zepsuć formularze i integracje |
Zastąpienie strony wersją statyczną lub odcięcie od internetu | 100% | Niska |
Wartości efektywności to szacunki poglądowe, nie wyniki testów. Searchlight Cyber zaznacza, że blokady mogą utrudnić normalne korzystanie ze strony, a blokada tylko jednej formy adresu zostawia stronę osiągalną. Żadna z tych miar nie zastępuje aktualizacji i żadna nie usuwa intruza, który wszedł przed jej wdrożeniem.
Aspekt | Informacja |
|---|---|
Czy jest wykorzystywana? | TAK: wpis w CISA KEV 21 lipca 2026; wykorzystanie potwierdziły m.in. Patchstack, Wiz Research, watchTowr, Hexastrike i Defiant (Wordfence) |
Grupy przestępcze | Brak publicznie potwierdzonych danych; Wiz opisuje oportunistyczne, masowe skanowanie |
Kampanie ransomware | Brak publicznie potwierdzonych danych; w katalogu CISA pole knownRansomwareCampaignUse ma wartość Unknown |
Ocena CVSS | 9,8/10 KRYTYCZNA (WPScan) i 7,5/10 WYSOKA (CISA ADP) |
EPSS | 0,97271, percentyl 0,99892 (13 września 2026) |
PoC dostępny publicznie? | TAK: wiele exploitów na GitHubie w ciągu godzin od ujawnienia 17 lipca |
Liczba atakowanych firm | Brak publicznie potwierdzonej liczby ofiar; Wiz podał, że w chwili publikacji 60% środowisk jego klientów miało podatnego WordPressa, a 25% wystawiało go do internetu, po dobie odpowiednio 50% i 10% |
Obserwowane działania po włamaniu | Wgrywanie wtyczek, wyliczanie użytkowników, próby odczytu wp-config, trzy rodzaje webshelli (Wiz Research) |
Różne terminy dla dwóch ogniw tego samego łańcucha nie są uznaniowe. Wynikają z dyrektywy CISA BOD 26-04 z 10 czerwca 2026, która uzależnia termin od trzech cech: wystawienia do internetu, wpływu technicznego i automatyzowalności. Luka wystawiona do internetu, z wpływem całkowitym i dająca się zautomatyzować dostaje 3 dni oraz obowiązek triage kryminalistycznego. Bez automatyzowalności termin wynosi 14 dni.
Cecha w ocenie SSVC | CVE-2026-63030 (trasy) | CVE-2026-60137 (SQL) |
|---|---|---|
Eksploatacja | aktywna | aktywna |
Automatyzowalna | tak | nie |
Wpływ techniczny | całkowity | całkowity |
Termin w KEV | 3 dni (24 lipca 2026) | 14 dni (4 sierpnia 2026) |
Triage kryminalistyczny | TAK | NIE |
Mogę Ci jakoś pomóc?
Wniosek dla firmy: ogniwo otwierające jest pilniejsze, bo to ono zamienia lukę SQL wymagającą specyficznej wtyczki w atak na każdą domyślną instalację, i to na masową skalę.
Data pomiaru | EPSS CVE-2026-63030 | EPSS CVE-2026-60137 | Kontekst |
|---|---|---|---|
18 lipca 2026 | 0,08946 | 0,04026 | dzień po ujawnieniu |
21 lipca 2026 | 0,08946 | 0,04026 | wpis do KEV |
22 lipca 2026 | 0,38599 | 0,20395 | dzień po wpisie do KEV, fala publikacji technicznych |
24 lipca 2026 | 0,97923 | 0,77974 | termin CISA dla ogniwa otwierającego |
23 sierpnia 2026 | 0,95605 | 0,73100 | lekki spadek |
13 września 2026 | 0,97271 | 0,78305 | stan obecny |
EPSS CVE-2026-63030 (prawdopodobieństwo próby ataku w 30 dni)
18.07 ██ 0,089
22.07 ███████████████ 0,386
24.07 ███████████████████████████████████████ 0,979
23.08 ██████████████████████████████████████ 0,956
13.09 ███████████████████████████████████████ 0,973 Wskaźnik wzrósł w ciągu tygodnia po ujawnieniu mniej więcej jedenastokrotnie i od końca lipca utrzymuje się blisko maksimum skali.
Linia czasu incydentu:
2025-12-02: WordPress 6.9 - pierwsza wersja z błędem w obsłudze żądań zbiorczych
2026-06-10: CISA wydaje dyrektywę BOD 26-04 (terminy zależne od SSVC)
2026-07-17: WordPress 7.0.2, 6.9.5, 6.8.6 i 7.1 beta2; wymuszone auto-aktualizacje; publikacja CVE
2026-07-17: pierwsze publiczne exploity na GitHubie w ciągu kilku godzin
2026-07-18: pierwsze próby ataków w pułapkach (weekend 18-19 lipca)
2026-07-21: CISA KEV - obie luki w katalogu
2026-07-24: termin CISA dla CVE-2026-63030, EPSS 0,979
2026-08-04: termin CISA dla CVE-2026-60137
2026-08-19: premiera WordPress 7.1
2026-09-13: EPSS 0,973 - nadal w najwyższych 0,2% ocenianych luk
2026-09-14: TUTAJ JESTEŚMY - 59 dni od ujawnienia: sprawdź wersje i szukaj śladów włamania! ✓ | Zadanie | Kto | Deadline |
|---|---|---|---|
☐ | Pobrać aktualizację z panelu (Kokpit, Aktualizacje) albo z https://wordpress.org/download/ | IT Manager | DZISIAJ |
☐ | Spisać wszystkie instalacje WordPressa, łącznie z kopiami testowymi i stronami kampanii | IT Manager | DZISIAJ |
☐ | Przetestować aktualizację do 7.1 na kopii strony (motyw, wtyczki, sklep) | QA | DZISIAJ |
☐ | Zakomunikować okno serwisowe i zabezpieczyć kopię logów przed zmianami | Project Manager | DZISIAJ |
☐ | Wdrożyć aktualizację na produkcji | DevOps | DO JUTRA |
☐ | Sprawdzić logi od 17 lipca pod kątem batch/v1, kodów 207 i nowych kont administratorów | SOC | DO JUTRA |
☐ | Potwierdzić wersję na każdej instalacji, dopiero potem zdjąć tymczasowe blokady | IT Manager | DO JUTRA |
☐ | Ocenić, czy doszło do naruszenia danych osobowych i czy biegnie 72-godzinny termin zgłoszenia do UODO | Inspektor ochrony danych i CFO | 72h od stwierdzenia |
Źródła do przekazania zespołowi: ogłoszenie producenta https://wordpress.org/news/2026/07/wordpress-7-0-2-release/, advisory https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-ff9f-jf42-662q oraz wpis w katalogu https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-63030.
# | Pytanie | Odpowiedź | Priorytet |
|---|---|---|---|
1 | Czy mamy gdziekolwiek WordPressa w wersjach 6.9.0-6.9.4 albo 7.0.0-7.0.1? | TAK / NIE | 🔴 |
2 | Jaka wersja działa dziś na każdej instalacji i czy to 7.1 lub co najmniej 7.0.4? | spis wersji per strona | 🔴 |
3 | Czy ktoś wyłączył automatyczne aktualizacje rdzenia i dlaczego? | TAK / NIE | 🔴 |
4 | Czy przejrzeliśmy logi od 17 lipca 2026 pod kątem żądań do batch/v1? | TAK / NIE | 🟠 |
5 | Czy blokada w zaporze obejmuje obie formy adresu, także ?rest_route=/batch/v1? | TAK / NIE | 🟠 |
6 | Czy od lipca pojawiły się nowe konta administratorów lub nieznane wtyczki? | TAK / NIE | 🟠 |
7 | Czy mamy kopię strony i bazy sprzed 17 lipca, zweryfikowaną jako czystą? | TAK / NIE | 🟡 |
Pytania diagnostyczne dla managera:
Najważniejsza lekcja z tej sprawy jest prosta: luka, która sama nie robi nic spektakularnego, potrafi być pilniejsza od tej, która brzmi groźniej. Ogniwo otwierające zamieniło rzadki warunek w atak na każdą domyślną instalację. Jeśli Twoje strony są na 7.1, zostaje jedno pytanie: czy nikt nie wszedł przed aktualizacją.
Mogę Ci jakoś pomóc?
Zestaw zmienia się codziennie, więc przy kolejnej wizycie zobaczysz inny wycinek bloga.
Luka o ocenie 10.0 w konsoli Cisco Secure Firewall Management Center pozwala ominąć logowanie i przejąć urządzenie. Cisco i CISA potwierdzają ataki. Zaktualizuj FMC i sprawdź ślady włamania.
Czytaj artykułPrzepełnienie bufora w FortiOS i FortiSwitchManager pozwala bez hasła uruchomić kod na zaporze. CISA potwierdza ataki, a przestępcy instalują trojana PivotC2. Zaktualizuj FortiOS i sprawdź zapory pod kątem włamania.
Czytaj artykułBłąd w logowaniu platformy Kestra OSS pozwala bez hasła tworzyć i uruchamiać przepływy pracy, czyli wykonywać dowolne polecenia jako root. Microsoft opisał włamanie, CISA potwierdza ataki. Zaktualizuj dziś.
Czytaj artykułKrótka rozmowa wystarczy, żeby ocenić zakres prac i podać widełki kosztu. Bez zobowiązań.
Klikając „Akceptuję”, zgadzasz się na przechowywanie plików cookie przez UXU w celu poprawy działania strony, analizy i wsparcia działań marketingowych.