Nazwa wtyczki	aThemes Dodatki dla Elementora
Rodzaj podatności	Atak typu cross-site scripting (XSS)
Numer CVE	CVE-2026-8613
Pilność	Niski
Data publikacji CVE	2026-06-10
Adres URL źródła	CVE-2026-8613

Pilne: Przechowywane XSS w aThemes Dodatkach dla Elementora (≤1.1.8, CVE‑2026‑8613) — Co właściciele stron WordPress muszą teraz zrobić

Streszczenie

Luka: Uwierzytelnione (Współautor) Przechowywane Cross‑Site Scripting (XSS)
Dotknięty plugin: aThemes Dodatki dla Elementora, wersje ≤ 1.1.8
Poprawione w: 1.1.9
Śledzenie: CVE‑2026‑8613
Data ujawnienia publicznego: 9 czerwca 2026
Wymagane uprawnienia atakującego: Rola współautora (uwierzytelniona)
Szczegóły eksploatacji: przechowywane XSS; wymagana interakcja użytkownika (uprzywilejowany użytkownik musi zobaczyć/kliknąć)
Poziom ryzyka dla większości stron: Niski (ale może stać się poważny, jeśli połączony z innymi słabościami)

Jako zespół bezpieczeństwa WP‑Firewall traktujemy nawet problemy o “niskim” poziomie powagi poważnie, ponieważ atakujący często łączą małe luki w pełne kompromitacje. To ostrzeżenie jest napisane dla właścicieli stron WordPress, administratorów, deweloperów i profesjonalistów hostingowych. Poniżej znajdziesz fachową analizę luki, rzeczywiste ryzyko, priorytetowe kroki łagodzące (natychmiastowe i średnioterminowe), instrukcje wykrywania i czyszczenia oraz środki obronne — w tym jak WP‑Firewall może chronić Twoją stronę teraz, nawet jeśli nie możesz natychmiast zaktualizować.

Notatka: Jeśli hostujesz strony dla klientów, traktuj to jako pilną listę kontrolną do zastosowania we wszystkich zarządzanych instalacjach.

1) Co się stało (prosty język)

Niedawne ujawnienie publiczne zidentyfikowało przechowywaną lukę Cross‑Site Scripting (XSS) w wtyczce aThemes Dodatki dla Elementora. Użytkownik z rolą współautora (lub konto o równoważnych możliwościach) może wprowadzić złośliwy HTML/JavaScript do danych, które wtyczka przechowuje. Ta przechowywana treść jest później renderowana w kontekście, w którym uprzywilejowany użytkownik lub inny odwiedzający stronę wykona wstrzyknięty skrypt.

Przechowywane XSS jest niebezpieczne, ponieważ ładunek utrzymuje się w bazie danych — po zapisaniu może wpływać na każdego użytkownika, który wyświetla zainfekowaną treść. Chociaż ten konkretny raport klasyfikuje problem jako niskiego priorytetu i zauważa, że eksploatacja wymaga interakcji użytkownika przez uprzywilejowane konto, potencjalne skutki obejmują kradzież sesji, działania uprzywilejowanego konta, zniekształcenie treści oraz przejście do pełnej kompromitacji strony.

Poprawione wersje są dostępne (1.1.9 i nowsze). Aktualizacja wtyczki jest najprostszym i najskuteczniejszym rozwiązaniem.

2) Jak zazwyczaj działa przechowywane XSS w wtyczkach WordPress (widok techniczny)

Przechowywane XSS powstaje, gdy:

Dane są akceptowane od jednego użytkownika (np. Współautora) i zapisywane bez wystarczającej walidacji lub sanitizacji.
Zapisana treść jest później wyświetlana w kontekście HTML, w którym przeglądarka wykonuje osadzony skrypt.
Użytkownik z uprawnieniami (edytor, administrator lub strona konkretnej wtyczki) ładuje tę treść i wykonuje skrypt atakującego.

Typowe przyczyny wtyczek:

Używanie surowych wartości wejściowych bezpośrednio w wyjściu (np. wyświetlanie wartości opcji, zawartości widgetów, list UI administratora) bez stosowania funkcji escapujących.
Ufać rolom użytkowników, które mają prawo do publikowania treści, jednocześnie pomijając fakt, że rola Współtwórcy lub inne role o niskich uprawnieniach mogą nadal być w stanie przesyłać dane przechowywane przez wtyczkę.
Przechowywanie bogatego HTML od użytkowników bez filtrowania dozwolonych tagów.

Udana sekwencja dla tej podatności wyglądałaby następująco:

Atakujący rejestruje lub używa konta Współtwórcy.
Atakujący wstrzykuje ładunek (np. lub obsługiwacze zdarzeń) do pola, które przechowuje wtyczka.
Administrator/edytor witryny później przegląda ustawienia wtyczki lub podgląd, który renderuje to przechowywane pole.
Przeglądarka administratora wykonuje wstrzyknięty skrypt — umożliwiając kradzież ciasteczek, działania CSRF, tworzenie użytkowników administratora lub inne kroki po eksploatacji.

3) Ryzyko w rzeczywistości: dlaczego “niskie” nie oznacza “ignoruj”

Ujawnienie klasyfikuje ten problem jako niskiego priorytetu z kilku powodów:

Eksploatacja wymaga, aby atakujący miał konto Współtwórcy (uwierzytelnienie).
Użytkownik z uprawnieniami musi wchodzić w interakcję z złośliwą treścią (wymagana interakcja użytkownika).

Jednak:

Współtwórcy mogą być tworzeni przez atakujących, jeśli rejestracja jest otwarta lub jeśli inżynieria społeczna/phishing umożliwia aktualizację konta.
Wiele witryn pozwala na treści generowane przez użytkowników lub ma edytorów, którzy przeglądają lub zatwierdzają wkłady — tworząc przewidywalne okna do eksploatacji.
Przechowywane XSS jest trwałe i zautomatyzowane; atakujący mogą celować w tysiące witryn z tym samym ładunkiem.

Dlatego nawet z etykietą “niskie”, podejmij natychmiastowe działania: aktualizuj, blokuj, wykrywaj i wzmacniaj.

4) Natychmiastowe priorytetowe działania (co zrobić w ciągu następnych 60–120 minut)

Zaktualizuj wtyczkę do wersji 1.1.9 lub nowszej
- Dostawca naprawił problem w wersji 1.1.9. Aktualizacja jest najwyższym priorytetem.
- Jeśli zarządzasz wieloma stronami, wprowadź aktualizację we wszystkich instalacjach teraz.
Jeśli nie możesz zaktualizować natychmiast, zastosuj kontrolę kompensacyjną:
- Tymczasowo wyłącz wtyczkę, aż będziesz mógł ją zaktualizować.
- Ogranicz dostęp do stron wtyczek (ograniczenia możliwości / tymczasowe usunięcie dostępu do ustawień wtyczki).
- Użyj swojego WAF (na przykład WP‑Firewall), aby zablokować wzorce żądań powszechnie używane do przechowywanego XSS (przykłady poniżej).
- Usuń lub ogranicz możliwości roli Współautora (zobacz następny dział).
Wymuś przegląd treści przesłanej przez współautorów w czasie otwartego okna:
- Ręczna inspekcja podejrzanych , onmouseover, onclick, javascript:, data URIs lub innych podejrzanych HTML w treści postu, meta, danych widgetu lub opcjach wtyczki.
Powiadom personel zarządzający treścią / redaktorów:
- Poinformuj redaktorów i administratorów, aby nie klikali w ustawienia wtyczki ani nie podglądali podejrzanej treści, dopóki nie zaktualizujesz lub nie złagodzisz problemu.

Jeśli prowadzisz wiele stron internetowych, traktuj to jak sprint naprawczy i nadaj priorytet stronom o dużym ruchu i e-commerce.

5) Krótkoterminowe środki zaradcze, które możesz zastosować od razu (aktualizacja wtyczki nie jest wymagana)

A. Wyłącz lub ogranicz wtyczkę

Przejdź do Wtyczki > Zainstalowane wtyczki i dezaktywuj dotkniętą wtyczkę, jeśli to możliwe.
Jeśli wtyczka musi pozostać aktywna, ogranicz dostęp do jej stron administracyjnych za pomocą wtyczki ograniczającej możliwości lub fragmentu, który odmawia dostępu dla nie-administratorów.

Przykładowy fragment, aby ograniczyć dostęp do strony ustawień wtyczki (umieść w niestandardowej wtyczce lub mu-wtyczce):

add_action( 'admin_menu', 'restrict_athemes_addons_admin_page', 1 );

Uwaga: Zastąp slug menu rzeczywistym slugiem używanym przez wtyczkę.

B. Wzmocnij możliwości Współautora

Współautorzy zazwyczaj nie mogą publikować postów, ale mogą przesyłać treści. Tymczasowo usuń możliwość przesyłania plików lub dodawania HTML dla roli Współautora, gdzie to możliwe.
Użyj wtyczki edytora ról lub WP‑CLI:

WP‑CLI do usunięcia możliwości przesyłania:

wp rola usuń-uprawnienie współtwórca przesyłaj_pliki

C. Blokuj powszechne wzorce XSS na warstwie WAF

Skonfiguruj swój WAF, aby blokował żądania zawierające tagi skryptów, URI “javascript:” lub podejrzane obsługiwacze zdarzeń w polach POST, które są używane do aktualizacji postów/opcji.
Klienci WP‑Firewall mogą włączyć zasady wirtualnego łatania dla tego konkretnego CVE, aby zablokować próby ataków na znane punkty końcowe.

D. Dodaj Politykę Bezpieczeństwa Treści (CSP) w trybie raportowania lub egzekwowania

CSP może zmniejszyć wpływ, blokując wykonywanie skryptów inline (ale nie można na niej polegać jako na jedynym rozwiązaniu).
Przykład minimalnego nagłówka CSP do blokowania skryptów inline (umieść w konfiguracji serwera lub za pomocą wtyczki):

Content-Security-Policy: default-src 'self'; script-src 'self' https:; object-src 'none'; report-uri /csp-report-endpoint

Zacznij najpierw w trybie “tylko raportowanie”, aby uniknąć łamania funkcji witryny, a następnie zaostrz.

E. Włącz uwierzytelnianie dwuskładnikowe (2FA) dla administratorów

Wymagaj 2FA dla wszystkich uprzywilejowanych kont. Jeśli sesja administratora zostanie skradziona za pomocą XSS, 2FA zmniejsza szansę na natychmiastowe nadużycie.

6) Wykrywanie: jak sprawdzić, czy byłeś celem (forensyka)

A. Przeszukaj bazę danych w poszukiwaniu podejrzanych ładunków

Szukaj tagów , obsługiwaczy zdarzeń (onerror, onclick, onmouseover) lub URI javascript:.
Przykład SQL (uruchom ostrożnie; zawsze najpierw wykonaj kopię zapasową DB):

SELECT ID, post_title;

Przeszukaj również wp_postmeta, wp_options i niestandardowe tabele wtyczek:

SELECT option_name FROM wp_options;

B. Użyj WP‑CLI, aby zlokalizować podejrzane posty lub opcje

wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content REGEXP '<script|javascript:|onerror=|onload|'"

C. Audyt kont użytkowników i ostatniej aktywności

Szukaj nowych kont z rolą Współtwórcy utworzonych w oknie ujawnienia.
Sprawdź identyfikatory autorów powiązane z podejrzanymi postami.
Eksportuj i sprawdź ostatnie dzienniki aktywności użytkowników (jeśli masz włączony audyt).

D. Sprawdź przesyłane pliki i system plików pod kątem powłok webowych

Przeszukaj przesyłane pliki w poszukiwaniu plików PHP lub nieoczekiwanych rozszerzeń plików. Współtwórcy normalnie nie powinni przesyłać plików PHP.

find wp-content/uploads -type f \( -iname "*.php" -o -iname "*.phtml" \) -ls

E. Przejrzyj dzienniki dostępu

Sprawdź dzienniki dostępu serwera i wpisy dziennika wtyczek pod kątem podejrzanych żądań POST do punktów końcowych wtyczek i nietypowych refererów.

7) Czyszczenie: usuwanie złośliwych ładunków i śladów po eksploatacji

Jeśli znajdziesz wstrzyknięte skrypty lub podejrzaną treść:

Eksportuj wpisy przed modyfikacją (jako dowód sądowy).
Oczyść treść, usuwając tagi skryptów i niebezpieczne atrybuty:
- Użyj wp_kses lub wp_strip_all_tags do czyszczenia post_content za pomocą skryptu lub runbooków.

Przykład skryptu czyszczącego PHP (ostrożnie: testuj na stagingu):

$posts = get_posts( array( 'posts_per_page' => -1, 'post_type' => 'any' ) );

Oczyść wp_options i tabele wtyczek z wartościami zawierającymi lub javascript:
- Starannie sprawdź i usuń złośliwe fragmenty. Niektóre opcje wtyczek zawierają zserializowane tablice — użyj PHP do deserializacji, oczyszczenia i ponownej serializacji.
Zresetuj hasła i unieważnij sesje
- Zresetuj hasła dla wszystkich administratorów i użytkowników z podwyższonymi uprawnieniami.
- Wymuś reset ciasteczek: dostosuj AUTH_KEY lub użyj wtyczki do zniszczenia sesji.
Zainstaluj ponownie rdzeń, motywy i wtyczki z oficjalnych źródeł.
- Zastąp pliki wtyczek nowymi kopiami, aby upewnić się, że nie ma modyfikacji plików.

8) Wzmocnienie i długoterminowa prewencja

A. Zasada najmniejszych uprawnień

Ponownie oceń, które role potrzebują jakich możliwości. Współtwórcy rzadko potrzebują upload_files lub unfiltered_html.
Rozważ użycie wtyczki do przepływu pracy redakcyjnej, która przechowuje treści w kolejce do przeglądu zamiast renderować wkłady bezpośrednio w interfejsie administracyjnym.

B. Walidacja wejścia i ucieczka wyjścia (lista kontrolna dla deweloperów)

Zawsze oczyszczaj dane wejściowe przy zapisie (sanitize_text_field, wp_kses, intval itd.).
Zawsze escape'uj wyjście podczas renderowania (esc_html, esc_attr, esc_url, wp_kses_post tam, gdzie to stosowne).
Używaj nonce'ów i sprawdzania uprawnień we wszystkich obsługach formularzy administracyjnych.
Przykład: zapisywanie oczyszczonej opcji:

if ( isset( $_POST['my_option'] ) && check_admin_referer( 'my_nonce' ) ) {

C. Polityka bezpieczeństwa treści i X‑Content‑Type‑Options

Przyjmij CSP, aby zredukować wpływ XSS, gdy to możliwe.
Użyj nagłówka X-Content-Type-Options: nosniff, aby ograniczyć zamieszanie z treścią.

D. Automatyczne skanowanie i ciągłe monitorowanie

Regularnie skanuj w poszukiwaniu złośliwego oprogramowania i nieoczekiwanych zmian.
Monitoruj nowych użytkowników administratorów i nagłe zmiany uprawnień.

E. Wirtualne łatanie za pomocą WAF

WAF-y mogą blokować ładunki exploitów i znane złe żądania, podczas gdy planujesz aktualizacje wtyczek.
Rozważ włączenie reguł na poziomie aplikacji, które szczególnie sprawdzają ładunki POST pod kątem tagów skryptów i podejrzanych wzorców atrybutów.

9) Przykładowe reguły WAF (koncepcyjne, stosować ostrożnie)

Poniżej znajdują się ogólne przykłady reguł, które host lub zapora aplikacji mogą wykorzystać do wykrywania wzorców prób. Są to koncepcyjne — dostosuj do składni swojego WAF i przetestuj, aby uniknąć fałszywych pozytywów.

Blokuj żądania, które zawierają lub javascript: w danych POST:
- Wzorzec: ciało POST zawiera “<script”
- Wzorzec: ciało POST zawiera “javascript:”
Blokuj próby oparte na atrybutach:
- Wzorzec: (onerror|onload|onclick|onmouseover)\s*=
Blokuj URI danych używane do przemycania skryptów:
- Wzorzec: data:text/html

Najpierw zachowaj regułę raportowania/logowania, aby znaleźć fałszywe pozytywy przed zablokowaniem.

10) Wskazówki dla deweloperów dla autorów wtyczek/tematów (jak tu nie trafić)

Traktuj wszelkie dane przesyłane przez uwierzytelnionych użytkowników jako wrogie.
Oczyść dane przy wejściu i escape przy wyjściu (obrona w głębokości).
Nie renderuj treści użytkownika na stronach administracyjnych bez escape.
Wymuszaj kontrole uprawnień na wszystkich działaniach administracyjnych, nawet dla niższych ról.
Ogranicz HTML dozwolony w dowolnym polu do bezpiecznej białej listy, używając wp_kses z kontrolowaną listą tagów.
Unikaj przechowywania surowego HTML w opcjach, które będą bezpośrednio wyjściowe.
Wdróż zautomatyzowane testy dla wektorów XSS w swoim pipeline CI.

11) Lista kontrolna odzyskiwania i weryfikacji (po usunięciu)

Zweryfikuj, czy wersja wtyczki to 1.1.9 lub nowsza na wszystkich stronach.
Ponownie uruchom skany bazy danych, aby upewnić się, że nie pozostały żadne tagi skryptów.
Potwierdź, że hasła kont administratorów zostały zmienione, a 2FA jest włączone.
Potwierdź, że nie istnieją nieznani użytkownicy administratorzy.
Monitoruj logi i raporty WAF w poszukiwaniu podejrzanej aktywności przez co najmniej 30 dni.
Jeśli wykryłeś eksploatację, rozważ pełną analizę forensyczną lub skonsultuj się ze specjalistą.

12) Testowanie swoich zabezpieczeń

Utwórz kopię roboczą strony, aby testować aktualizacje wtyczek i zasady WAF.
Symuluj przechowywany ładunek XSS w wersji roboczej, aby zweryfikować wykrywanie zasad WAF i upewnić się, że CSP zapobiega wykonaniu.
Testuj przepływy pracy użytkowników — upewnij się, że zasady blokujące nie łamią legalnych przesyłek formularzy.

13) Dlaczego WP‑Firewall dodaje wartość w przypadku tego rodzaju podatności

W WP‑Firewall koncentrujemy się na zapobieganiu i szybkim łagodzeniu podatności na poziomie aplikacji, takich jak przechowywany XSS, podczas gdy ty łatasz. Kluczowe korzyści, które oferujemy:

Zasady wirtualnego łatania, które można włączyć natychmiast, aby zablokować znane wzorce eksploatacji przeciwko dotkniętym punktom końcowym wtyczek.
Zasady WAF dostosowane do wykrywania przechowywanych ładunków XSS w ciałach POST i aktualizacjach ustawień wtyczek.
Ciągłe skanowanie i wykrywanie złośliwego oprogramowania w celu znalezienia wstrzykniętych ładunków skryptów i powłok internetowych.
Zarządzana pomoc w łagodzeniu, jeśli strona wykazuje oznaki kompromitacji.

Jeśli nie możesz natychmiast zaktualizować wszystkich stron, wirtualne łatanie z zarządzanym WAF to praktyczne rozwiązanie tymczasowe, które zmniejsza narażenie i daje ci czas na czyste łatanie.

14) Uzyskaj natychmiastowe, bezkosztowe zabezpieczenia z WP‑Firewall Basic

Rozumiemy, że nie każdy właściciel strony może zareagować natychmiast. Aby pomóc stronom szybko się zabezpieczyć, WP‑Firewall oferuje plan Podstawowy (Darmowy), który obejmuje podstawową ochronę: zarządzany zaporę, nielimitowaną przepustowość, zaporę aplikacji internetowej (WAF), skaner złośliwego oprogramowania oraz łagodzenie ryzyk OWASP Top 10. Możesz użyć darmowego planu, aby natychmiast włączyć wirtualne łatanie i zasady blokowania dla tej podatności, podczas gdy zaplanujesz aktualizacje wtyczek i przeprowadzisz czyszczenie.

Zarejestruj się lub dowiedz się więcej: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Jeśli już zarządzasz wieloma stronami klientów, rozważ aktualizację do planów Standard lub Pro, aby uzyskać automatyczne usuwanie złośliwego oprogramowania, białą/czarną listę adresów IP, automatyczne wirtualne łatanie podatności oraz miesięczne raporty bezpieczeństwa.

15) Często zadawane pytania (szybkie odpowiedzi)

Q: Nie mam żadnych Współpracowników na mojej stronie — czy jestem bezpieczny?
A: Jeśli nie ma żadnych kont Współpracowników, a rejestracje są zamknięte, twoje natychmiastowe ryzyko jest mniejsze. Jednak sprawdź, czy jakakolwiek wtyczka lub integracja nie tworzy takich kont, i nadal aktualizuj jako najlepszą praktykę.

Q: Moja strona jest mała i mało ruchliwa. Czy powinienem się tym przejmować?
A: Tak. Napastnicy prowadzą zautomatyzowane kampanie na dużą skalę. “Mała” strona może być punktem wyjścia do spamu, zniszczenia lub jako część większej botnety.

Q: Zaktualizowałem wtyczkę. Czy nadal muszę sprawdzać bazę danych?
A: Tak. Aktualizacja zapobiega nowym wykorzystaniom, ale nie usunie ładunków już przechowywanych w twojej bazie danych. Skanowanie i czyszczenie są konieczne.

16) Szczegółowe polecenia i skrypty (dla administratorów)

A. Kopia zapasowa przed rozpoczęciem

Zawsze twórz pełną kopię zapasową (pliki + DB) przed wprowadzeniem zmian.

B. Podsumowanie poleceń WP‑CLI

Zaktualizuj wtyczkę:

wp plugin update athemes-addons-for-elementor --version=1.1.9

Dezaktywuj wtyczkę:

wp plugin deactivate athemes-addons-for-elementor

Wyszukaj posty pod kątem tagów skryptów:

wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' LIMIT 100"

Usuń możliwość przesyłania z Współpracownika:

wp rola usuń-uprawnienie współtwórca przesyłaj_pliki

C. Szybkie wyszukiwanie i czyszczenie PHP (najpierw przetestuj na stagingu)

Bardziej dokładne czyszczenie wymaga starannego traktowania danych zserializowanych i formatów opcji wtyczek. Jeśli znajdziesz podejrzane wartości opcji zserializowanych, użyj PHP do deserializacji, sanitizacji i ponownej serializacji — nie próbuj ślepych zamian ciągów SQL.

17) Ostateczne zalecenia (plan działania)

Zaktualizuj wtyczkę do 1.1.9 natychmiast na wszystkich stronach.
Jeśli aktualizacja jest opóźniona, dezaktywuj wtyczkę lub włącz zasady wirtualnego łatania w swoim WAF.
Audytuj konta współpracowników, ostatnie posty i opcje wtyczek pod kątem wstrzykniętej zawartości.
Oczyść wszelką zainfekowaną zawartość za pomocą wp_kses lub ręcznej sanitizacji.
Zresetuj hasła dla uprzywilejowanych kont i włącz 2FA.
Wzmocnij role i uprawnienia oraz przyjmij zasady minimalnych uprawnień.
Monitoruj logi i skanuj stronę w poszukiwaniu dodatkowych wskaźników kompromitacji.
Jeśli potrzebujesz pomocy, skontaktuj się ze specjalistą ds. bezpieczeństwa lub skorzystaj z zarządzanej usługi, aby zastosować wirtualne łaty i przeprowadzić naprawę.

18) Zakończenie myśli

Przechowywane XSS pozostaje jednym z najczęstszych wektorów wykorzystywanych do eskalacji dostępu w środowiskach WordPress — szczególnie gdy role o niższych uprawnieniach mogą dostarczać dane, które później trafiają do kontekstu administratora. Techniczne rozwiązanie jest często proste, ale w warunkach operacyjnych trudność polega na zastosowaniu poprawki na wielu stronach, jednocześnie wykrywając i czyszcząc pozostałe ładunki.

Zaktualizuj dotkniętą wtyczkę teraz. Jeśli masz wiele instalacji lub ograniczone okna konserwacyjne, użyj wirtualnego łatania i podstawowego planu WP‑Firewall, aby zredukować natychmiastowe ryzyko podczas kończenia czyszczenia i testów.

Bądź bezpieczny. Bądź na bieżąco z łatami.

Odniesienia i zasoby

CVE: CVE-2026-8613
Oficjalna strona wtyczki aThemes Addons dla Elementora (aktualizacja z repozytorium wtyczek WordPress)
WP‑Firewall: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Jeśli potrzebujesz listy kontrolnej dotyczącej naprawy dostosowanej do Twojej strony (jedna instalacja, multisite lub stos agencji), zespół WP‑Firewall może dostarczyć priorytetowy podręcznik, aby szybko wprowadzić poprawki i oczyścić.

Łagodzenie XSS w dodatkach aThemes dla Elementora//Opublikowano 2026-06-10//CVE-2026-8613