Masinė WordPress, Joomla ir Craft CMS įsilaužimo kampanija: 15 pažeidžiamumų, tas pats rezultatas — web shell

Turite dešimtį klientų svetainių viename serveryje — bendras nginx, bendras PHP-FPM pool, atskiri web root’ai. Viena iš svetainių — WordPress su kontaktų forma per Ninja Forms ir failų įkėlimo papildiniu. Prie jos nesiliesta pusę metų: svetainė veikia, tad kam ją liesti. 2026 m. liepos 9 d. Australijos ACSC (Australian Signals Directorate’s Cyber Security Centre) paskelbė kritinį įspėjimą: visame pasaulyje vyksta masinė kampanija, kurios metu užpuolikai skenuoja būtent tokias svetaines ir per žinomus CMS platformų bei jų komponentų pažeidžiamumus jose įdiegia web shell’us. Sąraše — 15 įrašų, beveik visi su CVSS 9,8–10,0: WordPress papildiniai, Joomla Content Editor redaktorius, pačios Craft CMS, MaxSite CMS ir MetInfo CMS platformos, netgi vienas Laravel paketas (pay-uz) mokėjimams priimti — pateko į tą patį sąrašą, nors su WordPress neturi nieko bendro.

Tai ne vieno garsaus 0-day išnaudojimas. Tai vienalaikis puolimas per visą žinomų, seniai užlopytų pažeidžiamumų frontą — nuo failų įkėlimo klaidos Ninja Forms File Uploads papildinyje (CVE-2026-0740, CVSS 9,8) iki kodo injekcijos per Craft CMS vaizdų transformavimo funkciją (CVE-2025-32432, CVSS 10,0). ACSC tiesiogiai sieja atakų greičio augimą su dirbtinio intelekto naudojimu skenavimui ir eksploitų parinkimui automatizuoti — tai buvo minėta ir neseniai paskelbtame bendrame Five Eyes agentūrų pareiškime. Mažo ir vidutinio verslo svetainėms, kur papildinių atnaujinimai atidėliojami mėnesiais, tai kaip tik tas scenarijus, kai „veikia — neliesk” virsta atvirom durim.

KAS IŠ TIKRŲJŲ YRA WEB SHELL KAMPANIJA

Web shell — tai failas (dažniausiai .php), kurį užpuolikas per pažeidžiamą įkėlimo tvarkyklę paleidžia serveryje, o vėliau kreipiasi į jį tiesiogiai per URL. Failą vykdo serveris kaip įprastą svetainės skriptą — tik viduje esantis kodas priima užpuoliko komandas: vykdo shell komandas, skaito ir rašo failus, kuria naujus vartotojus, atsisiunčia papildomus įrankius. Skirtingai nei vienkartinis defeisas, web shell — tai nuolatinė (persistent) prieiga: net jei rasite ir ištrinsite vieną failą, niekas netrukdys užpuolikui tiesiog dar kartą nuskenuoti svetainę ir viską pakartoti, jei pati spraga liko neuždaryta.

Masinė kampanija šiuo atveju reiškia štai ką: botai sąmoningai netaikosi į konkrečią auką, jie šukuoja internetą pagal parašus — būdingus papildinių kelius, versijų numerius, kurie matomi meta žymose, serverio atsakymus į bandomąją užklausą. Radus derinį „CMS + papildinio versija”, jis sutikrinamas su žinomų pažeidžiamumų sąrašu, ir jei yra atitikmuo — paleidžiamas paruoštas eksploitas. Jūsų svetainė nukenčia ne todėl, kad kažkas specialiai į ją taikėsi, o todėl, kad ji statistiškai pateko į tinklą.

REALI ATAKOS GRANDINĖ

Paimkime Craft CMS ir CVE-2025-32432 — aiškiausią pavyzdį iš sąrašo, nes realiose atakose ji pradėta išnaudoti dar 2025 m. vasarį, du mėnesius anksčiau nei pasirodė pataisa, o visą istoriją ištyrė Orange Cyberdefense komanda. Craft CMS turi įtaisytą vaizdų transformavimo funkciją: įkėlus 4,5 MB nuotrauką, CMS pati sugeneruoja sumažintą miniatiūros versiją. Tai apdoroja neautentifikuotas kontrolerio endpoint’as actions/assets/generate-transform — prieinamas be prisijungimo, nes turi rodyti vaizdus visiems, naršantiems viešoje svetainės dalyje.

Problema ta, kad 4.x ir 5.x versijose asset ID — konkretaus vaizdo failo identifikatoriaus — galiojimas patikrinamas jau po transformacijos objekto sukūrimo, o ne prieš tai. Užpuolikas iš pradžių POST užklausomis į tą patį endpoint’ą perrenka skaitines asset ID reikšmes, kol randa egzistuojančią — 3.x versijose ši patikra vykdoma anksčiau vykdymo eigoje, todėl ten reikia turėti veikiantį ID iš anksto, bet rezultatas tas pats. Radus galiojantį ID, antroji užklausa savo kūne neša parametrą handle — įprastai tai tik eilutė su transformacijos pavadinimu, pavyzdžiui, „thumbnail”. Realiame eksploite vietoj eilutės atkeliauja įdėtas objektas su lauku __class, kuris nurodo serveriui: sukurk šios PHP klasės egzempliorių — GuzzleHttp\Psr7\FnStream, tarnybinę HTTP klasę, kuri niekada neturėtų būti sukuriama tiesiogiai iš svetimos užklausos kūno. Serveris paklūsta, net nepatikrinęs, ar klientas apskritai turi teisę nurodinėti, koks kodas turi būti vykdomas. Oficialus Craft CMS CVSS vektorius (10,0, konfidencialumas ir duomenų vientisumas pažeidžiami visiškai) priskiria problemą Code Injection kategorijai; nepriklausoma GitHub Security Advisory klasifikacija patikslina ją kaip CWE-470 — nesaugų vartotojo įvesties naudojimą klasei pasirinkti per refleksiją. Esmė abiem atvejais ta pati: svetimos HTTP užklausos kūnas nusprendžia, ką vykdys jūsų PHP procesas.

Tame pačiame ištirtame incidente ataka prasidėjo 2025 m. vasario 14 d., ir užpuolikas nesustojo ties demonstraciniu phpinfo() iškvietimu. Pasak Orange Cyberdefense, šiai klaidai buvo du veikiantys išnaudojimo būdai; šioje atakoje naudotas štai šis: užpuolikas siuntė užklausą su parametru „return URL”, kurio reikšmę Craft CMS įrašydavo į PHP sesijos failą diske, o vėliau grąžindavo lankytojui atgal kaip to paties HTTP atsakymo dalį — taigi serveryje esančiame sesijos faile atsidurdavo visiškai užpuoliko kontroliuojamas kodas. Antru žingsniu užpuolikas išnaudojo atskirą pažeidžiamumą pačiame Yii karkase, ant kurio veikia Craft CMS (CVE-2024-58136 — įvesties validacijos klaida), kad priverstų serverį vykdyti būtent tą sesijos failą kaip PHP kodą. Rezultatas — PHP failų tvarkyklė, paleista svetainės web root’e, kurią užpuolikas vėliau naudojo papildomiems PHP failams atsisiųsti.

Nuo šio momento užpuolikas turi pilnavertį web shell’ą, per kurį skaito DB prisijungimo duomenis iš konfigūracijos failų, diegia backdoor’us prieigai išlaikyti ir naudoja pažeistą serverį kaip placdarmą vidiniam tinklui skenuoti — jei web serveris yra tame pačiame segmente su likusia įmonės infrastruktūra. Būtent šios kampanijos mastas patvirtintas skaičiais: Orange Cyberdefense nuskenavo apie 35 000 unikalių Craft CMS domenų, iš jų apie 13 000 diegimų pasirodė pažeidžiami, o apie 300 — pagal būdingus pėdsakus filemanager.php ir autoload_classmap.php failų pavidalu web root’e — buvo pripažinti pažeistais ataskaitos paskelbimo momentu, 2025 m. balandį. Pati Craft CMS oficialiai patvirtino aktyvų išnaudojimą 2025 m. balandžio 17 d. — savaitę po pataisos išleidimo — ir išsiuntė įspėjimą visiems licencijų turėtojams, rekomenduodama nedelsiant atsinaujinti.

Panaši logika — su skirtingomis techninėmis detalėmis — veikia ir likusiuose 14 ACSC sąrašo įrašų. Ninja Forms File Uploads papildinyje (CVE-2026-0740) problemos šaknis yra ne failo tipo patikros nebuvimas kaip toks, o tai, kad funkcija NF_FU_AJAX_Controllers_Uploads::handle_upload tikrina šaltinio failo plėtinį, tačiau nepatikrina galutinio failo pavadinimo tuo momentu, kai jis perkeliamas į paskirties katalogą — užpuolikas manipuliuoja paskirties keliu ir apeina leidžiamų plėtinių sąrašą, įkeldamas PHP failą tiesiai į viešai pasiekiamą įkėlimų aplanką. Nereikia nei autentifikacijos, nei jokios CAPTCHA — AJAX endpoint’as viešas pagal dizainą, nes įkėlimo forma turi veikti anoniminiams svetainės lankytojams. Ir tai ne teorinė rizika: pagal Wordfence duomenis, išnaudojimas prasidėjo tą pačią dieną, kai pažeidžiamumas buvo atskleistas, o masinė atakų banga užklupo 2026 m. balandžio 9–13 d. — Wordfence ugniasienė vien pati užblokavo daugiau nei 118 600 bandymų išnaudoti būtent šią spragą.

O tai, kad ACSC sąrašas apibūdina ne hipotetinę grėsmę, o jau vykstantį medžioklę, patvirtino nepriklausomas tyrimas vos prieš savaites iki biuletenio paskelbimo. 2026 m. birželio 11 d. SOCRadar tyrėjai aptiko atviru, be slaptažodžio, palikto užpuolikų serverio — jį patys užpuolikai per neapdairumą paliko atvirą tris savaites iš eilės. Viduje — beveik 800 MB įrankių, žurnalų ir taikinių sąrašų, apimančių 1,4 mln. domenų, naudojančių lygiai tuos pačius pažeidžiamumus, kuriuos vėliau išvardys ir ACSC: Breeze (CVE-2026-3844), ThemeREX Addons, Simple File List, BerqWP, Ninja Forms File Uploads, WavePlayer, WPBookit ir Joomla JCE. Nepriklausoma Ctrl-Alt-Intel komanda, išanalizavusi tą pačią talpyklą, priskaičiavo 25 195 patvirtintus ar tikėtinus pažeidimus — didžioji dalis teko būtent Breeze klaidai, ir konkrečiai svetainėms, kuriose buvo įjungtas ne pagal numatymą veikiantis nustatymas „Host Files Locally — Gravatars”: daugiau nei 45 000 taikinių nuskenuota, daugiau nei 17 000 sėkmingai pažeista. Abi tyrėjų grupės su vidutiniu-aukštu pasitikėjimu operaciją sieja su kinakalbe grupuote — dėl kinų kalbos komandų istorijoje ir FOFA, kinų Shodan analogo, kuriam registruotis reikia kinų telefono numerio, naudojimo.

Breeze mechanizmas įdomus būtent tuo, kad pažeidžiama funkcija apskritai neturi nieko bendra su vartotojo įkeliamais failais — ji susijusi su avatarų kešavimu. Funkcija fetch_gravatar_from_remote, esanti faile class-breeze-cache-cronjobs.php, atsisiunčia Gravatar paveikslėlį pagal URL ir įrašo jį į diską per file_put_contents() — nei karto nepatikrinusi, ar atsisiųstas turinys iš tikrųjų yra paveikslėlis. Jei nustatymas „Host Files Locally — Gravatars” įjungtas (pagal numatymą išjungtas, ir būtent tai paaiškina, kodėl nukentėjo tik dalis iš 45 000 nuskenuotų taikinių), užpuolikas vietoj avataro pakiša PHP failą, užmaskuotą po Gravatar paslaugos URL, — ir pati Breeze, svetainės vardu, atsisiunčia ir įrašo web shell’ą tiesiai į katalogą /uploads/breeze/gravatars/. Toliau nereikia nei įkėlimo per formą, nei autentifikacijos — tik žinojimo, kad svetainėje ši parinktis įjungta.

CHRONOLOGIJA

Kampanijos pažeidžiamumų sąrašas apima beveik dvejus metus eksploitų kūrimo, susijungusius į vieną dabartinę atakų bangą: CVE-2020-36847 Simple File List papildinyje — seniausias įrašas, aptiktas dar 2020 metais (atskirai užregistruotą CVE-2025-34085 ACSC atmetė kaip tos pačios spragos dublikatą). CVE-2024-9234 GutenKit ir Hunk Companion papildiniuose siekia 2024 metus — ACSC jos ryšį su kampanija vadina „tikėtinu”, bet ne šimtu procentų patvirtintu. CVE-2025-32432 Craft CMS jau buvo rankiniu būdu išnaudojama 2025 m. vasario 10 d., o jau vasario 14 d. Orange Cyberdefense buvo pakviesta tirti konkretų pažeistą serverį — nuo šios datos ir prasidėjo spragos dokumentavimas. Oficiali pataisa (versijos 3.9.15, 4.14.15 ir 5.6.17) pasirodė tik balandžio 10 d. — lygiai du mėnesius po pirmosios atakos. Didžioji dalis likusių įrašų — CVE-2025-7443 (BerqWP), CVE-2025-7852 (WPBookit), CVE-2025-12057 (WavePlayer), CVE-2025-13486 (ACF Extended), CVE-2025-6389 (Sneeit Framework), CVE-2025-12352 (Gravity Forms) — atskleisti įvairiu metu 2025 metais. Tyrėjas Sélim Lanouar apie CVE-2026-0740 Ninja Forms File Uploads papildinyje pranešė Wordfence Bug Bounty programai 2026 m. sausio 8 d., gaudamas 2145 dolerių atlygį; viešas atskleidimas įvyko 2026 m. balandžio 6 d., ir tą pačią dieną prasidėjo pirmieji išnaudojimo bandymai. Pataisa praėjo tris etapus: dalinis pataisymas 3.3.25 pasirodė vasario 10 d., dar platesnis plėtinių draudžiamasis sąrašas — 3.3.26 versijoje, ir tik versija 3.3.27, išleista 2026 m. kovo 19 d., galutinai uždarė apėjimo galimybę — vadinasi, galutinė pataisa pasirodė beveik tris savaites anksčiau nei pati spraga buvo viešai atskleista.

Ypatingo dėmesio nusipelno pats naujausias ir agresyviausiai išnaudojamas sąrašo įrašas — CVE-2026-48907 Joomla Content Editor (JCE) redaktoriuje, įdiegtame didžiulėje dalyje Joomla svetainių. Pataisa pasirodė 2026 m. birželio 3 d. kaip versija 2.9.99.5, tačiau jau birželio 9 d. GitHub’e atsirado viešas PoC — ir nuo šio momento prasidėjo automatizuotos atakos prieš šimtus svetainių. 2026 m. birželio 16 d. CISA įtraukė šią spragą į Known Exploited Vulnerabilities (KEV) katalogą — tai aktyvaus išnaudojimo fakto patvirtinimas — ir JAV federalinėms agentūroms skyrė tris dienas problemai pašalinti, iki birželio 19 d. Trys dienos — vienas trumpiausių terminų, kokį kada nors nustatė CISA, ir tai jau savaime rodo situacijos rimtumą: nuo pataisos paskelbimo iki patekimo į KEV praėjo mažiau nei dvi savaitės.

2026 m. liepos 9 d. ACSC visą šį nevienalytį rinkinį — nuo penkerių metų senumo klaidos iki pusmečio šviežumo — sujungė į vieną biuletenį apie vieną vykstančią kampaniją. Tai esminis dalykas: CVE amžius užpuolikui neturi jokios reikšmės. Jei pataisa neįdiegta, spraga vienodai atvira ir 2020, ir 2026 metais.

KODĖL TAI SVARBU

Sisadminui, kuris tvarko vieną ar kelias svetaines shared hostinge arba savame VPS, pagrindinė mintis tokia: nė viena iš 15 sąrašo klaidų nėra nauja ar techniškai sudėtinga išnaudoti. Visos jos turi viešas pataisas. Problema ne ta, kad apsiginti neįmanoma, o ta, kad papildinių atnaujinimas — tai rutininė užduotis, kuri atidėliojama tol, kol svetainė „veikia”. Šios kampanijos užpuolikai kaip tik ir lažinasi dėl atotrūkio tarp pataisos paskelbimo datos ir jos realaus pritaikymo konkrečiame serveryje datos.

Atskira problema — premium papildiniai, tokie kaip Ninja Forms File Uploads: jie platinami ne per standartinę WordPress.org saugyklą, o per atskirą tiekėjo kanalą, ir WordPress core auto-atnaujinimas jiems tiesiog netaikomas. Jei turite įjungtą auto-update pagrindinei sistemai ir nemokamiems katalogo papildiniams, bet pamiršote, kad turite mokamą papildinį su atskiru atnaujinimo mechanizmu — jis tyliai lieka pažeidžiamoje versijoje, kol rankiniu būdu neužeisite patikrinti.

Tiems, kas administruoja ne vieną svetainę, o dešimtis klientų diegimų bendroje infrastruktūroje — hostingo tiekėjams, agentūroms, laisvai samdomiems specialistams su klientų portfeliu — rizika auga tiesiogiai proporcingai svetainių skaičiui. Kontaktų ir failų įkėlimo formos (Ninja Forms, Gravity Forms, Simple File List, WPBookit) — tai kaip tik tie komponentai, kurie dažniausiai yra bet kurioje komercinėje svetainėje, o ne egzotika, kurią galima ignoruoti. Web shell vienoje iš klientų svetainių bendrame serveryje — tai potenciali placdarma atakai prieš kaimynines web root’as per tą patį PHP-FPM ar bendrus prijungimo taškus, jei izoliacija tarp svetainių sukonfigūruota nerūpestingai.

KAIP UŽKIRSTI KELIĄ PASIKARTOJIMUI

Pataisų diegimas — tai privalomas minimumas, bet kampanija kaip tik todėl ir yra masinė, kad vien pataisų diegimo istoriškai neužtenka. Kas realiai sumažina atakos paviršių serverio architektūros lygmenyje:

Padarykite web root katalogus read-only ten, kur į juos neturėtų būti rašoma įprasto darbo metu. Dauguma CMS rašo tik į konkrečius pakatalogius — wp-content/uploads, storage, kešo katalogus. Likusi CMS failų medžio dalis (variklis, papildinių branduolys, temos) gali būti prijungta tik skaitymo teisėmis vartotojui, kurio vardu veikia PHP-FPM; WordPress branduolio failo pakeitimas serverio pusėje jau savaime yra pažeidimo signalas.

Uždrauskite PHP failų vykdymą įkėlimo kataloguose serverio lygmenyje, o ne pasikliaukite vien failo tipo patikra pačiame papildinyje. Nginx tai daroma per location bloką /wp-content/uploads/, kuris atiduoda statinį turinį, bet neperduoda užklausų į PHP-FPM. Net jei užpuolikas apeis leidžiamų plėtinių sąrašą pačiame papildinyje ir įkels .php failą į uploads aplanką, serveris jo nevykdys — atiduos kaip paprastą tekstinį failą arba atsisakys prieigos.

Kontroliuokite, kokius vaikinius procesus gali sukurti serverio worker’is. Web shell beveik visada tam tikru momentu iškviečia system(), exec() ar analogą, kad paleistų shell komandą. Jei turite galimybę tai apriboti per seccomp profilį konteineryje ar AppArmor/SELinux politiką PHP-FPM procesui, bet koks netikėtas vaikinis procesas, pavyzdžiui /bin/sh ar curl, sukurtas iš php-fpm, — tai signalas įspėjimui, net jei pats eksploitas jau suveikė.

Atskirkite viešas svetaines nuo vidinio įmonės tinklo tinklo segmentacijos lygmenyje. Net jei web shell prigis, jis neturėtų turėti maršrutizuojamos prieigos prie vidinių įmonės resursų — su šia svetaine nesusijusių duomenų bazių, failų dalinimosi šaltinių, kitų sistemų administravimo panelių. nftables taisyklės, ribojančios išeinantį srautą iš web serverių tik iki būtinų adresų, — bazinė, bet dažnai praleidžiama priemonė.

KĄ DARYTI

Pirmiausia patikrinkite pažeidimo pėdsakus, o tik tada atnaujinkite — jei pažeidžiamas papildinys jūsų sistemoje išbuvo mėnesiais, tikimybė, kad jis jau buvo nuskenuotas ir galbūt išnaudotas, nėra nulinė. Patikrinkite įkėlimų katalogą ir konkretaus papildinio katalogą dėl failų, kurių ten nedėjote: įtartini bet kokie .php failai su atsitiktiniais pavadinimais, failai su neseniai pakeista data, nesutampančia su jūsų pačių veiksmais — pagal normą vykdomo kodo uploads kataloge apskritai neturėtų būti.

Peržiūrėkite web serverio access žurnalus dėl GET ir POST užklausų į neįprastus kelius — Craft CMS atveju oficialus advisory tiesiogiai nurodo ieškoti POST užklausų į actions/assets/generate-transform su eilute __class užklausos kūne; pati Craft CMS pažymi, kad tokios užklausos buvimas žurnaluose reiškia bent jau skenavimo faktą, ne būtinai sėkmingą įsilaužimą. Tuščias tokios paieškos rezultatas nepanaikina poreikio patikrinti likusius 14 sąrašo CVE, jei turite atitinkamus papildinius. Joomla su JCE ieškokite kitokių pėdsakų: netikėtų naujų redaktoriaus profilių duomenų bazėje (JCE profilių lentelėje) ir POST užklausų į index.php?option=com_jce su parametrais, rodančiais profilio importą ar kūrimą, atėjusiomis iš išorinių IP be išankstinio prisijungimo prie administravimo panelės. Jei turite įdiegtą Breeze Cache — pirmiausia patikrinkite, ar įjungtas nustatymas „Host Files Locally — Gravatars” (pagal numatymą išjungtas); jei taip, nepriklausomai nuo papildinio versijos patikrinkite katalogą /wp-content/uploads/breeze/gravatars/ dėl failų su plėtiniais .php, .phtml ar .phar — pagal numatymą ten turėtų būti tik paveikslėliai.

Jei web shell rastas — netrinkite failo ir nelaikykite incidento uždarytu. ACSC tiesiogiai rekomenduoja: serverį su rastu web shell’u reikia laikyti visiškai pažeistu. Izoliuokite jį nuo tinklo, patikrinkite autentifikacijos žurnalus dėl naujų administratoriaus paskyrų, kurių nekūrėte, patikrinkite, ar neatsirado naujų SSH raktų ar cron užduočių, ir peržiūrėkite tinklo žurnalus (įskaitant perimetro ugniasienę) dėl išeinančių ryšių iš šio serverio į nepažįstamus išorinius adresus — tai gali rodyti duomenų eksfiltraciją arba ryšį su C2.

Tik patvirtinus arba paneigus pažeidimą, atnaujinkite pačius pažeidžiamus komponentus. Jei konkrečiai naudojate Craft CMS — atsinaujinkite iki versijos 3.9.15, 4.14.15 arba 5.6.17, priklausomai nuo jūsų pagrindinės šakos. Iš projekto šaknies paleiskite būtent Craft paketo atnaujinimą, o ne visų priklausomybių iš karto:

composer update craftcms/cms

Po to būtinai pritaikykite migracijas — Craft dalį nustatymų saugo duomenų bazėje, ir be šio žingsnio svetainė po kodo atnaujinimo gali pradėti keistai elgtis. Oficiali dokumentacija rekomenduoja tai vykdyti neinteraktyviu režimu, kad komanda neužstrigtų laukdama patvirtinimo:

php craft up --interactive=0

Patikrinti, ar versija tikrai atsinaujino, galima taip — komanda parodys įdiegtą paketo versijos numerį:

composer show craftcms/cms

Ninja Forms File Uploads papildiniui reikalinga versija 3.3.27 arba naujesnė. Tai mokamas papildinys, platinamas ne per WordPress.org katalogą, o per atskirą tiekėjo kanalą — core auto-atnaujinimas jam netaikomas. Patikrinkite įdiegtą versiją WordPress skydelyje (Plugins → Ninja Forms — File Uploads) ir atsinaujinkite rankiniu būdu per tą patį kanalą, iš kurio pirkote licenciją. Jei atnaujinti šiuo metu neįmanoma — laikinai išjunkite papildinį per administravimo skydelį arba pervadinkite papildinio katalogą wp-content/plugins/ viduje, kad WordPress nustotų jį įkėlęs, kol būsite pasiruošę pritaikyti pataisą.

Jei turite Joomla su įdiegtu Joomla Content Editor — atnaujinimas čia pats skubiausias iš visų penkiolikos punktų: versija turi būti 2.9.99.5 arba naujesnė, išleista 2026 m. birželio 3 d. (kūrėjas rekomenduoja iš karto versiją 2.9.99.6 nuo birželio 8 d., kurioje pridėtas papildomas sustiprinimas). Įdiegtą versiją galima patikrinti Joomla administratoriaus skydelyje, skyriuje Components → JCE Editor → Control Panel. Atsižvelgiant į tai, kad ši spraga jau oficialiai yra CISA KEV sąraše su patvirtintu išnaudojimu, bet koks delsimas čia — ne hipotetinė rizika, o žinomas vykstančių atakų faktas dabar. Pats JCE kūrėjas tiesiogiai įspėja: atnaujinimas uždaro įėjimo tašką, bet nepašalina to, ką užpuolikas galėjo jau palikti serveryje, jei svetainė buvo pažeidžiama po 2026 m. birželio 9 d., kai atsirado viešai prieinamas veikiantis eksploitas — atnaujinę būtinai patikrinkite JCE įkėlimo katalogus (paprastai /images/, /images/stories/ arba redaktoriaus profilyje nurodytą kelią) dėl nepažįstamų PHP failų.

IŠVADOS

Jei administruojate vieną svetainę savo VPS — skirkite valandą įdiegtų papildinių auditui pagal ACSC sąrašą ir aukščiau aprašytai žurnalų patikrai, kol dar neatidėjote to kitai savaitei. Ypatingas dėmesys — Breeze Cache: net jei esate tikri, kad nustatymas „Host Files Locally — Gravatars” niekada nebuvo įjungtas, patikrinkite tai aiškiai papildinio nustatymuose, o ne pasikliaukite atmintimi — būtent ši klaida davė daugiausiai realių pažeidimų dokumentuotoje WP-SHELLSTORM kampanijoje. Jei esate hostingo tiekėjas arba tvarkote kelias klientų svetaines bendroje infrastruktūroje — pradėkite nuo PHP-FPM pool’ų izoliacijos tarp klientų ir PHP vykdymo blokavimo įkėlimo kataloguose nginx lygmenyje, tai vienintelė sąrašo priemonė, kuri iš karto apsaugo nuo visų 15 pažeidžiamumų, o ne nuo vieno konkretaus. O svetainių savininkams, kurie moka agentūrai už palaikymą, — tai tas atvejis, kai verta tiesiogiai paklausti rangovo, ar pritaikytos pataisos iš ACSC liepos 9 d. biuletenio, o ne pasikliauti prielaida, kad „viskas atsinaujina automatiškai”.