Kriticka zranitelnost v JCE (CVE-2026-48907) a 30 dni utoku v mych vlastnich logach

V rozsireni editoru JCE (Joomla Content Editor) pro Joomlu byla nalezena zranitelnost s nejvyssi zavaznosti. Je vedena pod oznacenim CVE-2026-48907 a jeji skore CVSS je 10.0 -- tedy maximum stupnice. Jde o chybu typu vzdaleneho spusteni kodu (RCE), ktera umoznuje utocnikovi spustit na serveru libovolny PHP kod, bez overeni totoznosti, v jedinem kroku.

Opravena verze uz existuje. Ale "jen aktualizovat" neni cely pribeh, a proto tento text pisu. Zaprve, jde o realny, aktivne zneuzivany incident, ktery uredy oznacily za mimoradny -- a presto temer neexistuje japonsky psany navod, jak na nej konkretne reagovat. Zadruhe, nasazeni zaplaty neodstrani nic, co po sobe utocnik mohl zanechat, pokud byl vas web napaden jeste pred aktualizaci. A zatreti, 30 dni mych vlastnich pristupovych logu obsahuje presne tento utok, zaznamenany vytrvale a mireny primo na tuto zranitelnost. I maly osobni web se stava tercem. Necham zde surova data jako voditko pro provozovatele ve stejne situaci.

Uvodem: nejsem bezpecnostni odbornik. Nasleduje muj pokus postavit vedle sebe verejne informace o zranitelnosti a primarni data z mych vlastnich logu. Tam, kde jsem se vyhnul tvrzeni neceho jako fakt, ctete prosim s touto opatrnosti.

Proc je tato zranitelnost nebezpecna

JCE je jedno z nejrozsirenejsich rozsireni editoru pro Joomlu. Prave tento dosah cini plochu dopadu tak velkou.

Technickym jadrem je chybejici kontrola opravneni ve funkci importu profilu. Pred zaplatou provadelo JCE pri importu profilu pouze kontrolu CSRF tokenu. Jenze Joomla tento token vklada do verejnych stranek vcetne titulni stranky, takze si ho utocnik muze jednoduse vyzvednout. Kontrola overeni totoznosti -- tedy provereni, zda je volajici prihlaseny uzivatel -- vubec neexistovala, takze kdokoli s platnym tokenem mohl importni rutinu zavolat.

Utok ma dve faze. Nejprve vytvori falesny profil editoru, ktery umoznuje nahravani souboru bez overeni. Pak tento profil pouzije k zapisu spustitelneho souboru, napriklad .php nebo .phtml, na server. Pote uz staci soubor vyvolat a PHP se spusti. Zadne overeni, zadna interakce uzivatele, zadna predchozi opravneni. Takto vypada CVSS 10.0 v praxi.

Dotcene verze a oprava

Dotcene jsou verze JCE od 1.0.0 az po 2.9.99.4. Casova osa oprav byla nasledujici:

• 2.9.99.5 (3. cervna): oprava samotne zranitelnosti
• 2.9.99.6 (8. cervna): pridane zpevneni (hardening)
• 2.9.99.8 (18. cervna): dalsi bezpecnostni funkce a opravy chyb. Toto je doporucena verze pro kazdy web.

Jedna vyhrada. Verze 2.9.99.6 zpusobila, ze nekterym webum byly blokovany legitimni nahravky obrazku a souboru (falesne pozitivni detekce PHP tagu). To bylo opraveno v 2.9.99.8. Pokud jste v poslednni dobe meli potize s nahravanim, muze to byt tim. Tak ci tak, pokud budete aktualizovat, jdete rovnou na 2.9.99.8.

Tridenni lhuta ulozena uredy

Ze nejde jen o "dalsi CVE", ukazuje reakce americke agentury CISA (Cybersecurity and Infrastructure Security Agency). CISA 16. cervna zaradila tuto chybu do sveho katalogu znamych zneuzivanych zranitelnosti (KEV) a ulozila federalnim uradum lhutu do 19. cervna -- jedno z nejkratsich obdobi v historii CISA. Duvod: funkcni exploit kod je verejny a utoky jsou automatizovane.

"Nemame registraci uzivatelu, takze jsme v bezpeci" neplati

Toto je nejcasteji nepochopeny bod. Vyvojar JCE to rekl jasne: utoky jsou automatizovane a web bez verejne registrace neni v bezpeci. Jak bylo uvedeno vyse, CSRF token, ktery tento utok potrebuje, lze sebrat z titulni stranky. Ani prihlasovaci mechanismus, ani registrace uzivatelu nejsou predpokladem utoku.

A me vlastni logy to potvrzuji.

30 dni zaznamenanych v mych logach

Muj web je mala instalace Joomly, ktera se plne rozbehla teprve koncem cervna a zahrnuje tri property (komercni i nekomercni dohromady). Analyzoval jsem 30 dni jejich pristupovych logu -- zhruba 680 000 radku. Zde je to, co bylo pozorovano, v rozsahu, ktery mohu sdilet. Zdrojove IP adresy zamlcuji: vetsina jsou pravdepodobne kompromitovane servery treti strany a nema smysl je vystavovat.

Utoky prichazely kazdy den, mechanickym tempem. Utocne POSTy mirene na JCE byly zaznamenany kazdy jednotlivy den behem celeho obdobi pozorovani. Vynikalo, ze nekolik zdroju pracovalo s pevnou, nemennou kvotou zhruba 1 181 az 1 182 pozadavku za den -- jako by je vyrazilo strojove. Sdilely stejny otisk (davka pokusu o import profilu nasledovana sondovanim po umisteni webshellu) a v prubehu zhruba dvou tydnu stridaly zdrojove adresy. Toto je chovani automatizovane kampane botnetu, nikoli rucni prace cloveka.

Metoda presne odpovidala analyze CVE. Postup byl: POST na ulohu `profiles.import` (pokus o vytvoreni falesneho profilu), nasledovany pokusy umistit a vyvolat soubory podobne webshellu s priponami `.php` a `.phtml` na ruznych mistech. Nazvy souboru obsahovaly vzory, ktere koluji v znamych utocich, napriklad nazvy zacinajici na `nx` nebo obsahujici `nxploited`. To je presne ona dvoufazova sekvence "vytvor profil, pak umisti spustitelny soubor" popsana vyse.

Registrace nehrala roli. Skutecnost, ze muj web byl tercem, potvrzuje varovani vyvojare. K tomu, aby se web stal tercem, nebyla potreba zadna zvlastni podminka.

V mem pripade jsem nenasel zadnou stopu, ze by nektery z techto utoku uspel. V logach vsechny utocne POSTy skoncily po presmerovani na chybovych strankach, kazdy pokus o umisteni webshellu byl zablokovan a neexistoval zaznam o uspesnem sondovani citlivych souboru. Nad ramec toho jsem primo prohlédl soubory na serveru a nenasel nic podezreleho, co by tam utocnik mohl zanechat.

Budu tu presny ve formulaci. Analyza logu a kontrola souboru dokazi zjistit, ze nebyla nalezena zadna stopa po uspesnem prolomeni. To neni totez jako dukaz, ze k prolomeni nikdy nedoslo. Prave proto zalezi na nasledujicich krocich.

Co ihned zkontrolovat a udelat

Nasledujici kroky vychazeji z verejnych informaci (od CISA, vyvojare JCE a dalsich).

1. Nejprve aktualizujte. Aktualizujte JCE na 2.9.99.8. Pokud jej nepouzivate, deaktivujte jej a odstrante z administracni konzole Joomly. JCE byva nekdy soucasti sablon a distribucnich baliku, takze muze bezet, i kdyz si nepamatujete, ze jste jej instalovali. Provedte inventuru rozsireni a overte, zda je JCE na vasem webu pritomen, a pokud ano, v jake verzi.

2. Zkontrolujte, zda jste nebyli prolomeni. Kontrolni body doporucene vyvojarem jsou:

• V "Komponenty -> JCE Editor -> Editor Profiles" hledejte jakykoli profil editoru, ktery si nepamatujete, ze jste vytvorili.
• V nahravacich adresarich jako `images/` a `media/` hledejte nezname soubory `.php` / `.phtml` / `.phar`.
• Ve svych pristupovych logach hledejte neoverene pozadavky na `index.php?option=com_jce&task=profiles.import`.

Pokud se na server dostanete pres SSH, nejspolehlivejsim postupem je prohledat nahravaci adresare primo na nedavno zapsane spustitelne soubory. Bud'te vsak opatrni: objevi se i legitimni soubory (napriklad PHP dodavane s komponentou), takze peclive rozlisujte, co je legitimni a co podezrele. U kazdeho souboru, kterym si nejste jisti, si pred smazanim vzdy udelejte zalohu.

3. Zpevnete i na urovni serveru. Nasazeni zaplaty je zaklad, ale doporucuji se i tato dodatecna opatreni:

• Omezte webovy pristup k `/tmp/` a zabrante spusteni PHP v docasnych adresarich.
• Pouzijte WAF (webovy aplikacni firewall) k filtrovani pozadavku na `com_jce&task=profiles.import`.

Nejdulezitejsi bod: aktualizace zavre dvere, ale neuklidi dum

Vyvojar to zduraznuje primo. Nasazeni opravy zavre vstupni bod. Ale pokud jste byli prolomeni jeste predtim, aktualizace neodstrani to, co po sobe utocnik zanechal.

Provedeni ve spatnem poradi tedy pulí hodnotu. Ne "aktualizoval jsem, takze jsem v bezpeci", ale "aktualizoval jsem a pak jsem zkontroloval, zda uz predtim nebyl nekdo uvnitr". Potreba jsou obe faze. Pokud je prolomeni mozne, doporucuje se take pro jistotu zmenit vsechna administratorska hesla, prihlasovaci udaje k databazi a prihlasovaci udaje k ovladacimu panelu hostingu.

Zaverem

I maly, teprve spusteny web jako ten muj sleduje botnet po dobu dvou tydnu. Utocnici jsou pozoruhodne rychli v premene cerstve zverejnene chyby na automatizovany utok. Videl jsem to tentokrat na vlastni oci, ve svych vlastnich logach.

Nastesti v rozsahu, ktery jsem mohl overit, muj web neukazal zadnou stopu po skode. Ale zcasti je to proste tim, ze cilena chyba se nahodou neshodovala s konfiguraci meho webu. Jediny zpusob, jak to nenechat na stesti, je opravit to, co je treba opravit, tehdy, kdy je to treba opravit. Pokud se tento clanek stane timto voditkem byt pro jedineho cloveka, ktery se jeste nedostal k anglicky psanym informacim, splnil svuj ucel.

*Tento clanek vychazi z verejnych informaci o zranitelnosti a z primarnich dat pristupovych logu meho vlastniho webu. Nejsem bezpecnostni odbornik a casti tohoto vykladu obsahuji odhad. Pri reseni vlastniho webu vzdy nahlednete i do oficialnich informaci od vyvojare a od CISA.*

*Hlavni zdroje: oficialni JCE (joomlacontenteditor.net), katalog CISA KEV a databaze zranitelnosti pro CVE-2026-48907.*