Nazwa wtyczki	JetEngine
Rodzaj podatności	Wstrzyknięcie SQL
Numer CVE	CVE-2026-4662
Pilność	Wysoki
Data publikacji CVE	2026-03-25
Adres URL źródła	CVE-2026-4662

Krytyczna luka SQL Injection w JetEngine (<= 3.8.6.1): Co właściciele stron WordPress muszą zrobić teraz

Data: 25 marca 2026
Autor: Zespół ds. bezpieczeństwa WP-Firewall

Streszczenie: Krytyczna nieautoryzowana luka SQL injection (CVE-2026-4662) została ujawniona w wtyczce JetEngine, która dotyczy wersji do 3.8.6.1 włącznie. Luka jest wyzwalana przez parametr filtered_query i pozwala zdalnym, nieautoryzowanym atakującym na wstrzykiwanie SQL do bazy danych Twojej strony. Ten post wyjaśnia lukę w prostych słowach, dlaczego jest niebezpieczna, jak wykrywać oznaki wykorzystania, natychmiastowe i długoterminowe środki zaradcze (w tym wirtualne łatanie WAF) oraz listę kontrolną odzyskiwania przygotowaną przez inżynierów bezpieczeństwa WP-Firewall.

---

Dlaczego to ma znaczenie teraz

• CVSS: 9.3 — Wysoka powaga.
• Dotknięte wersje: JetEngine <= 3.8.6.1.
• Naprawione w: JetEngine 3.8.6.2.
• Wymagane uprawnienia: Brak — nieautoryzowane (każdy może spróbować).
• Wektor ataku: Publiczny parametr używany przez widżety Listing Grid — filtered_query.

Ponieważ błąd można wykorzystać bez autoryzacji i może oddziaływać z Twoją bazą danych, stanowi on wysokie ryzyko dla każdej strony korzystającej z dotkniętych wersji. Zautomatyzowane skanery i boty szybko spróbują masowego wykorzystania po publicznym ujawnieniu. Jeśli używasz JetEngine na swojej stronie WordPress, traktuj to jako pilne.

---

Co się dzieje (prosty język)

SQL injection to rodzaj błędu, w którym dane dostarczone przez odwiedzającego stronę są bezpośrednio osadzane w zapytaniu do bazy danych bez odpowiedniego oczyszczenia lub parametryzacji. Gdy atakujący może kontrolować te dane, może wpływać na to, co baza danych wykonuje — od odczytu wrażliwych danych (listy użytkowników, e-maile, hasła w postaci skrótu) po modyfikowanie lub usuwanie rekordów, a nawet pisanie trwałych backdoorów.

W tym konkretnym przypadku wtyczka akceptowała dane za pośrednictwem filtered_query parametru używanego przez komponenty Listing Grid. Ponieważ walidacja danych była niewystarczająca, stworzony filtered_query mógł manipulować SQL, który wtyczka wykonywała na bazie danych strony. Najgorsze jest to, że nie wymagano logowania ani innych uprawnień, aby to wypróbować.

---

Potencjalny wpływ na dotknięte strony

Jeśli zostanie skutecznie wykorzystane, atakujący mogą:

• Wyodrębnić wrażliwe dane strony (konta użytkowników, e-maile, prywatne treści itp.).
• Twórz lub podnoś konta (wstaw użytkowników administracyjnych).
• Modyfikuj treść strony (zmień posty/strony).
• Wstrzykuj złośliwe dane lub tylne drzwi do bazy danych, które ułatwiają stały dostęp.
• Wyczyść lub uszkodź bazę danych.
• Osiągnij pełne przejęcie strony w połączeniu z innymi lukami (przesyłanie plików, dowolne zapisywanie plików lub konta na poziomie administratora).

Ponieważ ta luka jest nieautoryzowana i stosunkowo łatwa do zautomatyzowania, jest głównym kandydatem do masowego wykorzystania. Małe strony i strony o dużym ruchu są narażone.

---

Jak napastnicy powszechnie wykorzystują tego rodzaju problemy (koncepcyjne)

Napastnicy często automatyzują próby w sieci, aby znaleźć punkty końcowe, które akceptują dane wejściowe i zwracają wyniki. Gdy napotykają parametr, który wchodzi w interakcję z bazą danych (parametry filtrów, pola wyszukiwania, parametry żądań API), testują zachowanie SQL. Jeśli odpowiedzi różnią się, gdy zawarte są znaki metacharacter SQL lub słowa kluczowe, może to ujawnić punkty wstrzyknięcia, które można wykorzystać. Stamtąd zautomatyzowane narzędzia mogą enumerować strukturę bazy danych i wydobywać dane.

Nie opublikujemy tutaj kodu exploita ani dowodu koncepcji, ale rozumiej, że ryzyko jest realne i natychmiastowe. Traktuj publiczne punkty końcowe, które akceptują dane zapytania, jako niebezpieczne, dopóki nie zostaną załatane.

---

Natychmiastowe działania, które powinieneś podjąć (usystematyzowane według priorytetu)

1. Załatnij wtyczkę teraz
   • Zaktualizuj JetEngine do wersji 3.8.6.2 lub nowszej. To jest najważniejszy krok.
   • Jeśli nie możesz zaktualizować natychmiast (z powodu wymagań dotyczących stagingu/testowania), zobowiąż się do przeprowadzenia aktualizacji tak szybko, jak to możliwe, i stosuj poniższe środki zaradcze podczas opóźnienia.
2. Zastosuj wirtualną łatkę za pomocą swojego WAF (jeśli go masz)
   • Użyj swojego zapory, aby zablokować lub oczyścić żądania, które zawierają filtered_query dane wejściowe lub podejrzane wzorce SQL. Wirtualne łatanie zapobiega wykorzystaniu, nawet jeśli wtyczka pozostaje niezałatana przez krótki czas.
   • Zobacz sekcję “Wytyczne dotyczące łatania WAF” poniżej, aby uzyskać bezpieczne podejścia do reguł.
3. Tymczasowo wyłącz dotkniętą funkcję
   • Jeśli możesz wyłączyć Listing Grid lub jakąkolwiek funkcjonalność, która akceptuje filtered_query parametr na publicznej stronie, zrób to, dopóki nie załatasz.
   • Zastąp wszelkie publicznie dostępne punkty końcowe listami statycznymi lub alternatywami renderowanymi przez serwer, jeśli to możliwe.
4. Monitoruj logi i ruch
   • Przeszukaj serwer WWW, aplikację (WordPress) i logi WAF w poszukiwaniu żądań, które zawierają filtered_query parametr oraz wszelkie nietypowe kody statusu (500) lub komunikaty o błędach.
   • Zidentyfikuj i zbadaj anomalie: nagłe skoki żądań do punktów końcowych listy, powtarzające się żądania z jednego zakresu IP lub nietypowe ciągi zapytań.
5. Wykonaj kopie zapasowe i zrób obrazy forensyczne
   • Wykonaj pełną kopię zapasową (pliki + baza danych) przed i po zastosowaniu działań łagodzących. Przechowuj niezmienne kopie odizolowane od środowiska produkcyjnego.
   • Jeśli podejrzewasz kompromitację, zarejestruj logi i listę plików do późniejszej analizy.
6. Rotuj klucze i hasła, jeśli kompromitacja jest możliwa
   • Jeśli znajdziesz dowody na udane wykorzystanie, zmień dane uwierzytelniające bazy danych, sól WordPress, klucze API i hasła administratora. Wykonaj to tylko po zrobieniu obrazów forensycznych.
7. Skanuj stronę w poszukiwaniu wskaźników kompromitacji
   • Przeprowadź skanowanie złośliwego oprogramowania w plikach i bazie danych; szukaj nowych użytkowników administratora, zmodyfikowanych plików wtyczek/motywów lub nowych zaplanowanych zdarzeń (zlecenia cron).
   • Sprawdź podejrzane wpisy w bazie danych (ukryci użytkownicy administratora, nieoczekiwane opcje, spamowe posty).

---

Wytyczne dotyczące łagodzenia WAF (wirtualne łatanie)

Jeśli uruchamiasz zaporę aplikacji internetowej (WAF) — zarządzaną lub opartą na wtyczkach — zastosuj wirtualne łatanie, aby zablokować próby wykorzystania. Wirtualne łatanie powinno być warstwowe i wystarczająco konserwatywne, aby nie łamać legalnej funkcjonalności.

Zalecane podejścia obronne (koncepcyjne; dostosuj do swojego języka reguł WAF):

• Zablokuj lub wyzwij żądania, które zawierają filtered_query parametr z kontrolnymi znakami SQL lub słowami kluczowymi SQL.
  • Przykłady tokenów, które należy traktować jako podejrzane (tylko do wykrywania): metaznaki SQL lub sekwencje takie jak WYBIERAĆ, UNIA, WSTAWIĆ, AKTUALIZACJA, USUWAĆ, UPUSZCZENIE, --, #, /*, */. Uwaga: reguła powinna być niewrażliwa na wielkość liter i uwzględniać obfuskację.
• Ogranicz akceptowane znaki, długość i format:
  • Jeśli filtered_query oczekuje się, że będzie zawierać tylko proste numeryczne identyfikatory, wymuś wprowadzanie tylko numeryczne.
  • Jeśli oczekuje JSON, wymuś poprawny typ zawartości JSON + sprawdzenie analizy.
• Zastosuj regułę blokującą dla każdego żądania, które zawiera filtered_query jako parametr GET lub POST pochodzący z nieautoryzowanych sesji, jeśli Twój przypadek użycia nie wymaga publicznego dostępu anonimowego.
• Ogranicz liczbę żądań do punktu końcowego listy i ogranicz powtarzające się żądania z tych samych adresów IP lub podsieci.
• W przypadku natychmiastowego łagodzenia sytuacji awaryjnej, całkowicie zablokuj żądania do konkretnego punktu końcowego listy na poziomie WAF lub serwera WWW, podczas gdy wprowadzasz poprawki.

Ważny: Nie usuwaj legalnej funkcjonalności, jeśli mocno polegasz na Listing Grid dla publicznej zawartości. Zamiast tego, priorytetowo traktuj ukierunkowane wirtualne poprawki (blokowanie na poziomie parametrów, sprawdzanie słów kluczowych) i testuj w środowisku testowym przed wdrożeniem do produkcji.

Przykładowe (niewykonywalne, pseudokodowe) koncepcje reguł WAF:

• Jeśli żądanie zawiera parametr filtered_query I wartość parametru zawiera słowa kluczowe/metaznaki SQL → zablokuj lub przedstaw captcha/wyzwanie.
• Jeśli żądanie zawiera parametr filtered_query a żądanie pochodzi od anonimowych agentów użytkownika z wysoką częstotliwością żądań → zablokuj.
• Jeśli ścieżka żądania pasuje do znanych punktów końcowych listy I metoda żądania to GET/POST z filtered_query obecnym → wyzwaniem.

Ponieważ języki reguł WAF różnią się, klienci WP-Firewall mogą polegać na naszym panelu zarządzania, aby szybko wdrożyć dostosowaną wirtualną poprawkę. Jeśli używasz innego WAF, skonsultuj się ze swoim dostawcą w celu dodania równoważnych reguł.

---

Wykrywanie: na co zwracać uwagę w logach i ekranach administracyjnych

Szukaj oznak, które mogą wskazywać na próby wykorzystania lub udany atak.

• Logi serwera WWW/WAF:
  • Żądania zawierające filtered_query w URL lub ciele POST.
  • Żądania z nietypowymi wartościami ciągu zapytania, które zawierają słowa kluczowe SQL, znaki interpunkcyjne (pojedyncze cudzysłowy, średniki).
  • Odpowiedzi HTTP 500 Internal Server Error z punktu końcowego (mogą wskazywać na ładunki powodujące błędy DB).
  • Duża liczba żądań do punktów końcowych listy z małego zestawu adresów IP.
• WordPress admin:
  • Nowi użytkownicy administratora, których nie utworzyłeś.
  • Zmiany w opcjach rdzenia lub podejrzanych plikach wtyczek/motywów.
  • Zaplanowane zadania (crony), których nie rozpoznajesz.
  • Niespodziewane zmiany w postach lub stronach (nowa zawartość, zmodyfikowana zawartość).
• Baza danych:
  • Nowe tabele lub niespodziewane rekordy.
  • Podejrzane wiersze w wp_users, wp_options, wp_posts (kod backdoor przechowywany jako zawartość postu lub opcje).
  • Zmodyfikowane uprawnienia użytkowników lub nowi użytkownicy z wysokimi rolami.
• System plików:
  • Ostatnio zmodyfikowane pliki PHP w wp-content/uploads lub folderach wtyczek/tematów.
  • Pliki PHP w katalogach upload.

Jeśli znajdziesz dowody, izoluj stronę i kontynuuj kroki odpowiedzi na incydent (zobacz sekcje poniżej).

---

Po podejrzanym naruszeniu: lista kontrolna odzyskiwania.

1. Izoluj stronę (włącz tryb konserwacji; zablokuj ruch, jeśli to konieczne).
2. Zachowaj dowody: skopiuj logi, kopie zapasowe i zrzuty bazy danych do bezpiecznej lokalizacji offline.
3. Przeprowadź dokładne skanowanie złośliwego oprogramowania i sprawdzenie integralności plików. Porównaj z czystymi kopiami.
4. Usuń backdoory (ręczne usuwanie jest ryzykowne; preferuj profesjonalną odpowiedź na incydent, jeśli nie jesteś pewien).
5. Przywróć z znanej czystej kopii zapasowej (jeśli dostępna) i natychmiast załatw wtyczkę.
6. Zmień wszystkie dane uwierzytelniające: użytkownicy bazy danych, hasła administratora WordPress, klucze API, dane uwierzytelniające FTP/SFTP.
7. Zastąp sól WordPress w wp-config.php.
8. Zaktualizuj rdzeń WordPress, wszystkie motywy i wtyczki do najnowszych wersji.
9. Utwardzanie: usuń nieużywane wtyczki/motywy, ustaw poprawne uprawnienia do plików, wyłącz niepotrzebne funkcje (XML-RPC, jeśli nie jest wymagane).
10. Ponownie włącz stronę z włączonym monitorowaniem i obserwuj ponowne pojawienie się wskaźników.
11. Rozważ wsparcie profesjonalnego czyszczenia zewnętrznego, jeśli brakuje Ci wiedzy wewnętrznej.

---

Dlaczego powierzchnia ataku jest tak atrakcyjna dla atakujących

Trzy czynniki sprawiają, że ten rodzaj podatności jest szczególnie atrakcyjny:

1. Nieautoryzowany dostęp: Nie jest wymagane logowanie, więc baza atakujących jest ogromna.
2. Interakcja SQL: Bezpośredni dostęp do bazy danych może przynieść bogaty skarb (maile, hasła w postaci skrótu, tokeny API).
3. Powszechna obecność wtyczek: JetEngine jest powszechnie używany do dynamicznych list; wiele stron ujawnia podatny parametr.

Gdy podatności łączą te trzy elementy, zazwyczaj po ujawnieniu następuje automatyczne skanowanie masowe i eksploatacja. Szybkie działanie chroni przed zautomatyzowanymi botnetami, które szukają dokładnie tych wzorców.

---

Długoterminowe najlepsze praktyki bezpieczeństwa dla właścicieli stron WordPress

Zarządzanie łatkami i WAF są ważne, ale bezpieczeństwo jest warstwowe. Przyjmij te nawyki:

• Utrzymuj wszystko zaktualizowane: rdzeń, motywy i wtyczki. Używaj środowiska testowego do testowania aktualizacji, gdzie to możliwe.
• Minimalizuj wtyczki: zachowaj tylko to, co potrzebujesz. Każda wtyczka to dodatkowa powierzchnia ataku.
• Używaj WAF (zarządzanego lub opartego na wtyczkach) i utrzymuj aktualne zasady.
• Wymuszaj zasadę najmniejszych uprawnień dla użytkowników bazy danych — unikaj używania konta DB z uprawnieniami DROP lub innymi potężnymi uprawnieniami, jeśli nie jest to konieczne.
• Wzmocnij stronę: silne hasła, uwierzytelnianie dwuskładnikowe dla administratorów, ogranicz liczbę prób logowania.
• Używaj bezpiecznych kopii zapasowych (poza siedzibą i niezmiennych) i okresowo testuj przywracanie.
• Monitoruj logi i ustaw automatyczne powiadomienia o podejrzanej aktywności.
• Bezpieczne praktyki programistyczne: zawsze używaj przygotowanych instrukcji i odpowiedniej walidacji danych wejściowych podczas tworzenia niestandardowego kodu.

---

Wskaźniki kompromitacji (IoCs) do wyszukania

Szukaj (ale nie ograniczaj się do) następujących w logach i treści:

• Powtarzające się żądania z filtered_query parametrem, szczególnie z podejrzanymi ładunkami.
• Nieoczekiwani nowi użytkownicy administratora lub podniesienie ról użytkowników.
• Nieoczekiwane zmiany w krytycznych opcjach lub plikach motywów/wtyczek.
• Pliki w katalogach przesyłania z kodem PHP lub nieoczekiwanym kodem.
• Połączenia wychodzące z witryny, które nie są oczekiwane (możliwe sygnalizowanie wycieku danych).
• Zapytania do bazy danych, które odnoszą się do opcje_wp, użytkownicy wp, lub innych wrażliwych tabel z nietypowymi wzorcami.

Jeśli znajdziesz którykolwiek z tych przypadków, postępuj zgodnie z listą kontrolną odzyskiwania i rozważ analizę forensyczną.

---

Komunikacja z użytkownikami i interesariuszami

Jeśli zarządzasz witryną z kontami użytkowników:

• Jeśli potwierdzisz naruszenie i dane użytkowników mogły zostać ujawnione, przygotuj jasne i szczere powiadomienie dla dotkniętych użytkowników zgodnie z wymaganiami prawnymi/regulacyjnymi.
• Zresetuj hasła użytkowników tam, gdzie to stosowne (szczególnie dla użytkowników administracyjnych).
• Podaj zalecane kroki dla użytkowników (zmiana haseł, monitorowanie kont, włączenie MFA).

Przejrzystość zmniejsza późniejsze szkody i pomaga utrzymać zaufanie.

---

Jak WP-Firewall pomaga (co oferujemy)

W WP-Firewall projektujemy nasze usługi dla szybkiej, pragmatycznej ochrony i odzyskiwania:

• Zarządzane zasady zapory, które mogą być wdrażane jako ukierunkowane wirtualne łatki w celu zablokowania konkretnych exploitów, takich jak nieautoryzowane próby wstrzykiwania SQL.
• Analiza ruchu w czasie rzeczywistym i ograniczanie przepustowości, aby stłumić zautomatyzowane masowe skanowanie.
• Skanowanie złośliwego oprogramowania i zaplanowane kontrole integralności.
• Materiały wsparcia i wskazówki dotyczące incydentów, aby pomóc Ci postępować zgodnie z powyższą listą kontrolną odzyskiwania.
• Przyjazne dla etapu przepływy aktualizacji i monitorowanie, aby zmniejszyć ryzyko podczas aktualizacji wtyczek.

Zbudowaliśmy nasze podejście skoncentrowane na zapobieganiu, aby właściciele witryn mogli szybko zastosować ukierunkowane zabezpieczenia i zmniejszyć swoje okno narażenia, podczas gdy planują zaplanowane aktualizacje.

---

Zacznij chronić swoją witrynę z WP-Firewall — dostępny darmowy plan.

Tytuł: Zacznij chronić swoją stronę już teraz — wypróbuj darmowy plan WP-Firewall

Jeśli chcesz natychmiastowej, zarządzanej ochrony podczas łatania lub przeprowadzania konserwacji, rozważ darmowy plan WP-Firewall. Zawiera on niezbędne zabezpieczenia, które zmniejszają ryzyko związane z publicznymi exploitami, takimi jak wstrzyknięcie SQL JetEngine:

• Podstawowy (bezpłatny): Niezbędna ochrona — zarządzany firewall, nielimitowana przepustowość, zestaw reguł WAF, skaner złośliwego oprogramowania i pokrycie w zakresie ryzyk OWASP Top 10.
• Standard ($50/rok): Wszystkie funkcje podstawowe, plus automatyczne usuwanie złośliwego oprogramowania i możliwość dodawania do czarnej/białej listy do 20 adresów IP.
• Pro ($299/rok): Wszystkie funkcje standardowe, plus miesięczne raporty bezpieczeństwa, automatyczne wirtualne łatanie luk oraz dodatki premium (dedykowany menedżer konta, optymalizacja bezpieczeństwa, token wsparcia WP, usługi zarządzane).

Zarejestruj się w bezpłatnym planie i uzyskaj natychmiastową ochronę: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Praktyczne przykłady bezpiecznych reguł WAF (wytyczne)

Poniżej znajdują się wytyczne na poziomie koncepcyjnym dotyczące budowania konserwatywnych reguł WAF. Szczegóły będą zależały od Twojego produktu WAF.

1. Biała lista parametrów
   • Jeśli filtered_query powinny zawierać tylko numeryczne identyfikatory (lub stały schemat JSON), egzekwuj to dokładnie. Przykład: zezwól tylko na cyfry i przecinki; zablokuj wszystko inne.
2. Wykrywanie słów kluczowych
   • Zablokuj lub wyzwij żądania zawierające słowa kluczowe SQL lub znaczniki komentarzy, gdy pojawią się w filtered_query. Użyj dopasowania bez uwzględniania wielkości liter i rozważ powszechne próby obfuskacji.
3. Walidacja typu treści i metody
   • Jeśli punkt końcowy oczekuje JSON POST, zablokuj żądania GET, które zawierają filtered_query lub źle sformatowane nagłówki typu treści.
4. Ograniczenie liczby żądań i reputacja
   • Ogranicz liczbę żądań do punktów końcowych listy na IP i użyj źródeł reputacji IP, aby ograniczyć lub zablokować powtarzających się przestępców.
5. Tymczasowe blokady oparte na geolokalizacji lub zachowaniu
   • Jeśli podejrzana aktywność koncentruje się w regionach nieistotnych dla Twojego biznesu, użyj tymczasowego blokowania geograficznego podczas prowadzenia dochodzenia.

Zawsze testuj reguły w trybie staging lub symulacji, gdy to możliwe, aby uniknąć fałszywych pozytywów, które łamią prawidłowe zachowanie strony.

---

Testowanie po złagodzeniu

• Sprawdź, czy wersja wtyczki jest zaktualizowana i aktywna.
• Przetestuj wszystkie funkcje listowania w środowisku staging i produkcyjnym, aby potwierdzić, że działają zgodnie z oczekiwaniami.
• Potwierdź, że zasady WAF nie zablokowały legalnego ruchu (monitoruj logi w poszukiwaniu fałszywych pozytywów).
• Wznów normalne działanie tylko wtedy, gdy testy zakończą się pomyślnie, a monitoring jest włączony.

---

Ostateczna lista kontrolna (szybkie odniesienie)

• Natychmiast zaktualizuj JetEngine do wersji 3.8.6.2 lub nowszej.
• Jeśli nie możesz jeszcze zaktualizować, zastosuj wirtualne łatanie WAF, aby zablokować filtered_query nadużycia.
• Tymczasowo wyłącz funkcje listowania, które polegają na filtered_query jeśli to możliwe.
• Wykonaj kopie zapasowe i zrzuty forensyczne przed wprowadzeniem zmian.
• Monitoruj logi w poszukiwaniu podejrzanych żądań i IoC.
• Przeskanuj stronę w poszukiwaniu złośliwego oprogramowania i nieautoryzowanych zmian.
• Zmień dane uwierzytelniające, jeśli istnieje podejrzenie naruszenia.
• Wzmocnij uprawnienia użytkowników DB i usuń nieużywane wtyczki/motywy.
• Zarejestruj się na zarządzaną ochronę, jeśli chcesz automatyzacji wdrażania zasad WAF i ciągłego monitorowania.

---

Zakończenie myśli od zespołu bezpieczeństwa WP-Firewall

Luki, które pozwalają nieautoryzowanym użytkownikom na bezpośrednią interakcję z bazami danych, są jednymi z najpilniejszych do rozwiązania. Okno ekspozycji po publicznym ujawnieniu jest krótkie: zautomatyzowani aktorzy działają szybko. Jeśli używasz JetEngine, priorytetowo traktuj aktualizację wtyczki i — jeśli to konieczne — wirtualne łatanie z użyciem WAF. Użyj powyższej listy kontrolnej, aby szybko ocenić sytuację i zminimalizować ryzyko.

Jeśli potrzebujesz pomocy w wdrażaniu zasad WAF, ocenie logów w poszukiwaniu oznak eksploatacji lub odpowiedzi na podejrzane naruszenie, inżynierowie WP-Firewall są dostępni, aby pomóc. Szybkie działanie teraz chroni Twoich użytkowników, zachowuje integralność danych i zmniejsza przestoje oraz koszty naprawy później.

Bądź bezpieczny i natychmiast zaktualizuj swoje instalacje JetEngine.