Varnostni incident Helix3

Konec junija 2026 je v ekosistemu Joomla prišla na dan nova resna varnostna težava – tokrat ne v urejevalniku JCE, temveč v ogrodju predlog JoomShaper Helix3. Zgodba je poučna tudi po tem, kako je prišla na dan: raziskovalci so pravo vstopno točko odkrili med preiskavo vdrte spletne strani stranke in jo nato zasebno sporočili proizvajalcu. Popravek je izšel v različici Helix3 3.1.1 29. junija 2026 – v proizvajalčevem dnevniku sprememb pa je pisalo samo »Security Update«, nič več.

Pomembno je pojasniti: Helix3 je starejše, a še vedno široko uporabljeno ogrodje predlog JoomShaper in ni isto kot novejši Helix Ultimate, ki tokrat ni prizadet.

Koren napake

Težava je dosegljiva prek komponente Joomla com_ajax, ki po zasnovi posreduje zahteve lastnemu obdelovalcu ajax ciljnega vtičnika – v tem primeru funkciji Helix3 onAjaxHelix3 – tudi povsem neoverjenim obiskovalcem. Jedro Joomle tukaj ne preverja pravic; ta naloga pade na vtičnik. V Helix3 pa se je več dejanj izvedlo brez preverjanja.

Kaj je lahko storil neoverjen napadalec (pred 3.1.1)

save – v datoteko pod aktivno predlogo je lahko zapisal poljubno vsebino. Koda je vsilila končnico .json, poti pa ni očistila, zato je datoteka s pomočjo prehoda med imeniki (directory traversal) lahko končala tudi zunaj predvidene mape.
remove – brisanje datotek brez omejitve končnic in brez preverjanja poti, kar je v praksi omogočalo brisanje katere koli datoteke, do katere je imel dostop uporabnik spletnega strežnika.
import – prepis parametrov sloga predloge, shranjenih v podatkovni bazi.
Brez prijave so bila dosegljiva tudi druga, prav tako nezaščitena dejanja (load, resetLayout, updateFonts, fontVariants).

Pravo izvajanje kode?

Samo po sebi ne samodejno – pisanje je bilo omejeno na končnico .json. Zaradi dveh scenarijev pa lahko vseeno vodi do izvajanja kode:

Na slabo nastavljenih strežnikih Apache, kjer obdelovalnik PHP datoteko z imenom po vzorcu nev.php.json preda v izvajanje.
Pri verižnem izkoriščanju, ko se poljubno brisanje datotek uporabi za odstranitev zaščitnih datotek (npr. .htaccess), ki bi sicer preprečile izvajanje prej podtaknjene datoteke.

Dodatni popravki v 3.1.1, ki jih proizvajalec ni dokumentiral

Pot za nalaganje slik za overjene uporabnike, ki je končnico datoteke prevzela neposredno iz imena naložene datoteke, brez seznama dovoljenih – to je računu z nizkimi pravicami (Avtor/Urednik) omogočilo, da naloži in zažene datoteko .php.
Druga napaka path traversal pri brisanju slik.
Shranjeni XSS zaradi izpisa brez ustreznega ubežanja znakov.
V kodo zapisan, razkrit ključ API za Google Fonts.
Končna točka za glasovanje o člankih brez omejitev.

Obseg prizadetosti

Manifest popravljene izdaje navaja združljivost od Joomle 4.0 do 6.5, popravljena koda pa ima ločeni veji za Joomlo 5 in 6 – težava torej zadeva tudi trenutno aktivno uporabljane različice Joomle.

Status CVE

Dodelitev uradnega identifikatorja CVE za ranljivost še poteka; zasluge je prejel raziskovalec, ki jo je prijavil. Do takrat velja za merodajno referenčno točko popravljena različica 3.1.1.

Težava z dnevnikom sprememb

Članek posebej poudarja, da je proizvajalčev vnos v dnevniku sprememb sporočil le »Security Update« – ni povedal ničesar o prizadeti komponenti, resnosti ali o tem, ali je bila napaka morda aktivno izkoriščena. Takšna nejasna komunikacija upravljavcem spletnih strani otežuje oceno nujnosti popravka in določitev ustrezne prednosti.

Priporočeni takojšnji koraki

Nemudoma posodobi Helix3 na 3.1.1 ali novejšo.
Zamenjaj ključ API za Google Fonts v nastavitvah Helix3 – stari ključ je bil razkrit in tega nobena strežniška konfiguracija sama po sebi ne popravi.
Preveri zapisljive mape predloge (npr. css/, layouts/, images/) in poišči nepričakovane datoteke .json, .php ali datoteke z dvojno končnico (.php.json).
Preglej dnevnike strežnika in poišči zahteve s parametroma com_ajax + plugin=helix3, zlasti z neznanih naslovov IP.
Uvedi začasno strežniško zaščito do namestitve popravka – glej spodaj.

Začasna zaščita z .htaccess

Naslednji nabor pravil ne nadomešča posodobitve, temveč daje le začasno, dopolnilno zaščito, dokler ne posodobiš na Helix3 3.1.1 (ali novejšo). Pred namestitvijo v produkcijsko okolje jih je smiselno preizkusiti na testni (staging) strani, saj lahko strožja pravila ovirajo urejanje predlog, slogov in pisav za prijavljene skrbnike.

<IfModule mod_rewrite.c>
    RewriteEngine On

    # --------------------------------------------------------------------
    # 1) Block unauthenticated requests to the vulnerable Helix3 ajax
    #    handler (com_ajax -> plugin=helix3 -> onAjaxHelix3). The exploit
    #    chain hits index.php?option=com_ajax&plugin=helix3&... with
    #    actions like save / remove / import / load / resetLayout /
    #    updateFonts / fontVariants, none of which checked auth pre-3.1.1.
    # --------------------------------------------------------------------
    RewriteCond %{QUERY_STRING} option=com_ajax [NC]
    RewriteCond %{QUERY_STRING} plugin=helix ?3? [NC]
    RewriteCond %{HTTP_COOKIE} !joomla_user_state=logged_in [NC]
    RewriteRule ^ - [F,L]

    # --------------------------------------------------------------------
    # 2) Block POST requests to com_ajax targeting helix3 with no referer
    #    from your own admin area - stops most off-site/scripted abuse.
    # --------------------------------------------------------------------
    RewriteCond %{REQUEST_METHOD} POST
    RewriteCond %{QUERY_STRING} option=com_ajax.*plugin=helix3 [NC]
    RewriteCond %{HTTP_REFERER} !^https?://(www\.)?DOMAINNEVED.HU/administrator [NC]
    RewriteRule ^ - [F,L]
</IfModule>

Pomembno: nadomestno oznako DOMAINNEVED.HU zamenjaj s svojo domeno in po namestitvi preveri, ali urejanje predloge na osnovi Helix3 (slogi, postavitve, pisave) za prijavljene skrbnike še vedno deluje pravilno.

Povzetek

Incident Helix3 lepo pokaže, kako veliko odgovornost za preverjanje pravic prožne komponente Joomle, kot je com_ajax, nalagajo posameznim vtičnikom – že eno samo manjkajoče preverjanje zadošča, da povsem neoverjen obiskovalec na strežniku zapisuje ali briše datoteke. Zgodba poleg tega osvetli, kako pomembna je pregledna varnostna komunikacija: nejasen vnos »Security Update« sam po sebi upravljavcu strani ne da dovolj informacij, da bi pravilno ocenil nujnost posodobitve.

Če uporabljaš predlogo Helix3, je naloga jasna: takoj posodobi na 3.1.1, zamenjaj prizadeti ključ API in do takrat kot dopolnilno zaščito uporabi zgornja pravila .htaccess.

kibernetska varnost
varnost spletne strani
nova različica
novice