Helix3 biztonsági incidens

2026 júniusának végén egy újabb komoly biztonsági probléma látott napvilágot a Joomla-ökoszisztémában — ezúttal nem a JCE szerkesztőben, hanem a JoomShaper Helix3 sablonkeretrendszerben. A történet abban is tanulságos, ahogyan napvilágra került: egy feltört ügyfélwebhely vizsgálata során bukkantak rá a kutatók a valódi belépési pontra, majd magánúton jelezték a gyártónak. A javítás a Helix3 3.1.1 verzióban, 2026. június 29-én jelent meg — de a gyártó saját változásnaplójában mindössze ennyi állt: “Security Update”, semmi több.

Fontos tisztázni: a Helix3 egy régebbi, de továbbra is széles körben használt JoomShaper sablonkeretrendszer, és nem azonos az újabb, ez esetben nem érintett Helix Ultimate-tel.

A hiba gyökere

A probléma a com_ajax Joomla-komponensen keresztül érhető el, amely tervezésénél fogva továbbítja a kéréseket a célzott plugin saját ajax-kezelőjéhez — ez esetben a Helix3 onAjaxHelix3 függvényéhez —, teljesen hitelesítés nélküli látogatók számára is. A Joomla core nem végez itt jogosultság-ellenőrzést; ez a feladat a pluginra hárul. A Helix3-ban azonban több akció is ellenőrzés nélkül futott le.

Amit egy hitelesítés nélküli támadó megtehetett (3.1.1 előtt)

  • save – tetszőleges tartalmat tudott írni egy fájlba az aktív sablon alatt. A kiterjesztést .json-ra kényszerítette a kód, de az elérési útvonalat nem tisztította, így egy directory traversal segítségével a fájl a tervezett mappán kívülre is kerülhetett.
  • remove – fájltörlés kiterjesztés-korlátozás és útvonal-ellenőrzés nélkül, ami gyakorlatilag tetszőleges fájl törlését tette lehetővé, amihez a webszerver felhasználója hozzáfért.
  • import – egy sablonstílus adatbázisban tárolt paramétereinek felülírása.
  • Több más, szintén védtelen akció (load, resetLayout, updateFonts, fontVariants) szintén elérhető volt bejelentkezés nélkül.

Valódi kódfuttatás?

Önmagában nem automatikusan — az írási művelet .json kiterjesztésre volt korlátozva. Azonban két forgatókönyv miatt mégis kódfuttatáshoz vezethet:

  1. Rosszul konfigurált Apache-kiszolgálókon, ahol egy nev.php.json mintájú fájlnevet a PHP-kezelő futtatásra ad át.
  2. Lánc-kihasználás esetén, amikor a tetszőleges fájltörlést arra használják, hogy védelmi fájlokat (pl. .htaccess) távolítsanak el, amelyek egyébként megakadályoznák egy korábban elhelyezett fájl lefutását.

További, a gyártó által nem dokumentált javítások a 3.1.1-ben

  • Egy hitelesített képfeltöltési útvonal, amely a fájl kiterjesztését közvetlenül a feltöltött fájlnévből vette át, fehérlista nélkül — ez lehetővé tette, hogy egy alacsony jogosultságú (Szerző/Szerkesztő) fiók .php fájlt töltsön fel és futtasson.
  • Egy második path traversal hiba a képtörlésnél.
  • Tárolt XSS nem megfelelően escape-elt kimenet miatt.
  • Egy hardcode-olt, kiszivárgott Google Fonts API-kulcs.
  • Egy korlátozás nélküli cikk-szavazási (voting) végpont.

Érintettségi kör

A javított kiadás manifesztje a Joomla 4.0-tól 6.5-ig terjedő kompatibilitást deklarálja, a javított kódban külön Joomla 5-ös és 6-os ágakkal — vagyis a probléma a jelenleg aktívan használt Joomla-verziókat is érinti.

CVE-státusz

A sebezhetőséghez formális CVE-azonosító kiosztása még folyamatban van; a bejelentő kutató kapta a jóváírást. Addig is a 3.1.1-es javított verzió számít a mérvadó referenciapontnak.

A változásnapló-probléma

A cikk külön kiemeli, hogy a gyártó saját changelog-bejegyzése mindössze annyit közölt: “Security Update” — sem az érintett komponensről, sem a súlyosságról, sem arról nem adott információt, hogy a hibát esetleg aktívan kihasználták-e. Ez a fajta homályos kommunikáció megnehezíti a weboldal-üzemeltetők számára a javítás sürgősségének felmérését és a megfelelő prioritás felállítását.

Javasolt azonnali lépések

  1. Frissíts Helix3 3.1.1-re vagy újabbra haladéktalanul.
  2. Cseréld le a Google Fonts API-kulcsot a Helix3 beállításokban — a régi kulcs szivárgott, ezt önmagában semmilyen szerverkonfiguráció nem orvosolja.
  3. Ellenőrizd a sablon írható mappáit (pl. css/, layouts/, images/) váratlan .json, .php, vagy dupla kiterjesztésű (.php.json) fájlok után.
  4. Nézd át a szerver naplóit com_ajax + plugin=helix3 paraméterekkel érkező kérésekre, különösen ismeretlen IP-címekről.
  5. Vezess be ideiglenes szerveroldali védelmet a patch telepítéséig — lásd alább.

Ideiglenes .htaccess védelem

A következő szabálygyűjtemény nem helyettesíti a frissítést, csak átmeneti, kiegészítő védelmet nyújt, amíg a Helix3 3.1.1-es (vagy újabb) verziójára frissítesz. Éles környezetbe telepítés előtt érdemes teszt/staging oldalon kipróbálni, mert a szigorúbb szabályok megzavarhatják a bejelentkezett adminisztrátorok sablon-, stílus- és betűtípus-szerkesztését.


<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>

Fontos: cseréld ki a DOMAINNEVED.HU helyőrzőt a saját domainedre, és telepítés után ellenőrizd, hogy a Helix3-alapú sablonszerkesztés (stílusok, elrendezések, betűtípusok) továbbra is megfelelően működik-e a bejelentkezett adminisztrátorok számára.

Összegzés

A Helix3-incidens jól mutatja, hogy a com_ajax-hoz hasonló, rugalmas Joomla-komponensek mennyire nagy felelősséget rónak az egyes pluginokra a jogosultság-ellenőrzés terén — egyetlen hiányzó ellenőrzés is elég ahhoz, hogy egy teljesen hitelesítés nélküli látogató fájlokat írjon vagy töröljön a szerveren. Emellett a történet arra is rávilágít, milyen fontos a átlátható biztonsági kommunikáció: egy homályos “Security Update” bejegyzés önmagában nem ad elég információt ahhoz, hogy egy oldal üzemeltetője helyesen mérje fel a frissítés sürgősségét.

Ha Helix3 sablont használsz, a teendő egyértelmű: frissíts azonnal 3.1.1-re, cseréld le az érintett API-kulcsot, és amíg ez megtörténik, alkalmazd a fenti .htaccess szabályokat kiegészítő védelemként.