2026 februárjában nyilvánosságra hoztak egy kritikus, a szandboxból való kitörésre lehetőséget biztosító biztonsági rést az n8n-ben, a széles körben elterjedt nyílt forráskódú munkafolyamat-automatizálási platformban. A CVE-2026-25049 azonosítószámmal nyilvántartott hiba lehetővé teszi a hitelesített felhasználók számára, hogy megkerüljék a kifejezésértékelő szandboxot, és tetszőleges rendszerparancsokat hajtsanak végre a gazdaszerveren, így teljes távoli kódvégrehajtást érve el; a CVSS v3.1 pontszáma 9,9.
Az OPSWAT ösztöndíjprogram keretében ösztöndíjasaink átfogó műszaki elemzést végeztek a CVE-2026-25049 biztonsági résről, megvizsgálva annak kiváltó okát, a kihasználás mechanizmusát és a szervezetekre gyakorolt hatását.
Ez a blogbejegyzés részletes áttekintést nyújt a biztonsági résről – az n8n kifejezésfeldolgozó architektúrájától és réteges biztonsági ellenőrzéseitől kezdve egészen azon a pontos technikáig, amely egyszerre képes áttörni mind az öt védelmi réteget.
A CVE-2026-25049 egy kritikus, a kifejezésekkel kapcsolatos sandbox-megkerülési sebezhetőség az n8n-ben, amely a CWE-913 kategóriába tartozik: a dinamikusan kezelt kódforrások nem megfelelő ellenőrzése. A hiba az 1.123.17-es verziót megelőző összes n8n-verziót, valamint a 2.0.0-tól 2.5.1-ig terjedő verziókat érinti, és az 1.123.17-es és 2.5.2-es verziókban már javították. Lehetővé teszi a munkafolyamat-létrehozási jogosultsággal rendelkező hitelesített felhasználók számára, hogy olyan rosszindulatú JavaScript-kifejezéseket alkossanak, amelyek megkerülik a platform kifejezés-szandboxját, és végső soron tetszőleges parancsok végrehajtását teszik lehetővé a gazdaszerveren.
A sebezhetőség különösen súlyos, mivel az n8n általában kiemelt szerepet tölt be a szervezetek infrastruktúrájában. Mivel az n8n a munkafolyamatok automatizálásának központi eleme, általában közvetlen hozzáféréssel rendelkezik a belső API-khoz, adatbázisokhoz, hitelesítőadatok tárolóihoz és harmadik féltől származó szolgáltatásokhoz. Egy feltört n8n-példány nem csupán az automatizálási szervert teszi sebezhetővé, hanem átjáróként szolgál minden csatlakozó rendszerhez, ami drámai módon megnöveli a támadás hatókörét.
A CVE-2026-25049 nem önálló biztonsági rés, hanem a CVE-2025-68613 javításának kijátszása, amely egy korábbi, az n8n kifejezésértékelőjében fellépő sandbox-megszökés volt. Annak ellenére, hogy az eredeti sebezhetőség után többrétegű védelmet vezettek be, a tisztítóprogram JavaScript absztrakt szintaxisfa (AST) csomóponttípusok feldolgozásának alapvető hiányossága lehetővé tette, hogy az eredeti támadási osztály egy másik szintaktikai vektoron keresztül újra felbukkanjon. Ez a minta – ahol a javítás a konkrét kihasználási technikát kezeli, ahelyett, hogy az alapvető tervezési gyengeséget orvosolná – rávilágít a dinamikus kódértékelési környezetek biztonságának biztosításával kapcsolatos állandó kihívásra.
A biztonsági rést 2026. február 4-én hozták nyilvánosságra az n8n-hez kapcsolódó tíz egyéb biztonsági figyelmeztetéssel együtt, és több biztonsági kutatócsoport is függetlenül elemezte.
Az n8n-ről
Az n8n egy nyílt forráskódú munkafolyamat-automatizáló platform, amely lehetővé teszi a szervezetek számára, hogy rendszereket kapcsoljanak össze, folyamatokat automatizáljanak és integrációkat hozzanak létre több száz szolgáltatás között. Széles körű elterjedtségének és több mint 1300 elérhető integrációnak köszönhetően az n8n kategóriájának egyik legnépszerűbb eszközévé vált, amelyet fejlesztői csapatok és nagyvállalatok egyaránt használnak a belső eszközöktől az üzleti szempontból kritikus adatfolyamokig terjedő folyamatok automatizálására.
A platform mind az önállóan üzemeltetett, mind a felhőalapú telepítéseket támogatja, és vizuális munkafolyamat-készítőt, valamint közvetlen JavaScript-támogatást biztosít az egyedi logikákhoz. Az n8n architektúrája csomópont-alapú: a munkafolyamatok egymással összekapcsolt csomópontokból állnak, amelyek JSON formátumban továbbítják az adatokat a kiváltók, műveletek és függvénylépések között. A végrehajtás manuális módban történhet tesztelés céljából, vagy termelési módban élő telepítés esetén. Ez az architektúra, a JavaScript-kifejezések natív támogatásával és a belső API-khoz, valamint a hitelesítőadatok tárolóihoz való hozzáféréssel kombinálva az n8n-t hatékony automatizálási eszközzé teszi – ugyanakkor sebezhetőségek esetén értékes célponttá is.
Műszaki háttér
Absztrakt szintaxisfák
Az absztrakt szintaxisfa (AST) egy elemző által létrehozott, a forráskódot ábrázoló hierarchikus struktúra. Az AST nem egyszerű szövegsorozatként kezeli a kódot, hanem strukturált csomópontokra bontja azt, amelyek a szintaxis elemeit – változódeklarációkat, függvénykifejezéseket, tagkifejezéseket, azonosítókat és literálokat – képviselik.
Az AST-csomóponttípusok megértése elengedhetetlen ehhez az elemzéshez, mivel az n8n biztonsági ellenőrzései az AST-szinten működnek. A tisztító modulok meghatározott csomóponttípusokat vizsgálnak a veszélyes minták felismerése és blokkolása érdekében. A sebezhetőség azt a tényt használja ki, hogy ugyanaz a szemantikai művelet – egy objektum tulajdonságához való hozzáférés – a használt JavaScript-szintaxistól függően teljesen eltérő AST-csomóponttípusokat eredményezhet.
Például az obj.constructor kifejezés egy MemberExpression csomópontot hoz létre, míg a const { constructor } = obj egy VariableDeclaration-t hoz létre , amely egy Property csomóponttal rendelkező ObjectPattern-t tartalmaz. Mindkettő ugyanazt a tulajdonságot vonja ki, de az AST-struktúrák alapvetően eltérőek – az n8n szűrői pedig csak az első mintát vizsgálják.
Az n8n kifejezésértékelése és biztonsági architektúrája
Az n8n architektúrája öt rétegből áll: Frontend, CLI, Core, Workflow és Nodes. A Workflow réteg végzi a kifejezések kiértékelését, amely a jelen sebezhetőség szempontjából releváns komponens.
Az n8n lehetővé teszi a felhasználók számára, hogy JavaScript-kifejezéseket ágyazzanak be a munkafolyamat-csomópontok paramétereibe az adatok dinamikus manipulálása érdekében. Ezeket a kifejezéseket szerveroldalon értékelik ki a Tournament nevű könyvtár segítségével, amely a végrehajtás előtt elemzi a kifejezéseket egy absztrakt szintaxisfa (AST) formájába. A biztonsági ellenőrző hookokat közvetlenül a Tournament létrehozási folyamatába építik be, így az AST felépítése során futó ellenőrzésekkel még a kód végrehajtása előtt kiszűrik a veszélyes mintákat.
Mivel ezek a kifejezések ugyanazon a Node.js-folyamaton belül futnak, mint az n8n-kiszolgáló, a platform öt különálló biztonsági réteget valósít meg, amelyek célja, hogy megakadályozzák a nem megbízható kódok kiszabadulását a homokozóból.
1. réteg – Globális kontextus felülírása
Mielőtt bármely kifejezés ki lenne értékelve, az n8n korlátozott végrehajtási környezetet hoz létre azáltal, hogy felülírja a veszélyes globális objektumokat és függvényeket. Az olyan tulajdonságokat, mint a document, window, globalThis, eval, setTimeout, setInterval és Function, üres objektumokkal helyettesíti, megakadályozva ezzel a közvetlen hozzáférést ezekhez a funkciókhoz.
Ennek a megközelítésnek van egy velejárója: ha egy támadónak sikerül kijutnia a korlátozott kontextusból, és eljutnia a valódi globális folyamatobjektumhoz, akkor a felülírt tulajdonságok már nem számítanak.
2. réteg – Regex-ellenőrzés
Mielőtt a kifejezés eljutna az értékelőhöz, az n8n reguláris kifejezéssel ellenőrzi a nyers kifejezés karakterláncát, hogy megakadályozza a hozzáférést a constructor tulajdonsághoz – ez ugyanis egy gyakori módszer a Function konstruktor megszerzésére és a kód végrehajtására.
A /\.\s*constructor/gm reguláris kifejezés a .constructor tulajdonsághoz való pontjelöléses hozzáférést észleli. Ez az ellenőrzés azonban alapvetően korlátozott, mivel a JavaScript többféle szintaktikai utat kínál ugyanazon tulajdonság eléréséhez, amelyek közül nem mindegyik használ pontjelölést.
3. réteg – AST futásidejű ellenőrző – PrototypeSanitizer
A legkifinomultabb védelmi mechanizmus az AST felépítése során lép működésbe. A PrototypeSanitizer hook végigfut az AST-n, és ellenőrzi a MemberExpression csomópontokat annak megállapítására, hogy a lekért tulajdonság szerepel-e a nem biztonságos objektumtulajdonságok blokkolási listáján – ideértve a constructor, __proto__, prototype, mainModule és binding tulajdonságokat.
A szanitizáló három esetet kezel: a pontjelölést (obj.prop), ahol az azonosító nevét ellenőrzi, a statikus zárójel-jelölést (obj['prop']), ahol a karakterlánc-literál értékét ellenőrzi, valamint a futásidejű szanitizáló függvénybe ágyazott dinamikus kifejezéseket. Amint az a 10. ábrán látható, csak a MemberExpression csomópontokat vizsgálja – a dekonstruáló mintákat nem járja végig.
4. réteg – AST futásidejű tisztító funkció: ThisSanitizer
A CVE-2025-68613 biztonsági rés közvetlen javításaként beépített FunctionThisSanitizer elfogja az azonnal végrehajtott függvénykifejezéseket (IIFE-ket), és úgy írja át őket, hogy a `this` változót egy üres objektumhoz kössék. Ezzel megakadályozható az eredeti támadásban alkalmazott technika, amelyben a (function(){ return this })() kifejezés a nem kötött `this` hivatkozáson keresztül szivárogtatta ki a globális folyamatobjektumot.
Fontos tudni, hogy ez a tisztító eljárás kizárólag FunctionExpression csomópontokat kezel. Bármely olyan hívott elem esetén, amely nem FunctionExpression – ideértve a nyílfüggvényeket is –, kifejezetten korán visszatér.
Az olyan veszélyes tulajdonságokat, mint az eval, a Function és a process.mainModule, eltávolítják vagy felülírják a végrehajtási kontextusban, így megakadályozva a kódvégrehajtási alapelemekhez való közvetlen hozzáférést, még akkor is, ha a korábbi rétegeket megkerülik.
Sebezhetőségi elemzés
Alapvető ok
A CVE-2026-25049 hiba kiváltó oka az öt biztonsági rétegben egyaránt jelen lévő közös feltételezésben rejlik: minden réteg abból indult ki, hogy a tulajdonságokhoz való hozzáférés vagy pontjelöléssel (obj.constructor), vagy zárójeljelöléssel (obj['constructor']) történik. Egyik sem vette figyelembe a JavaScript destruktúrált szintaxisát.
A JavaScript destruktúrázása lehetővé teszi az objektumok tulajdonságainak kivonását egy alapvetően eltérő AST-struktúra segítségével:
// Traditional access - produces MemberExpression node
obj.constructor; // Blocked by regex, AST sanitizer, and runtime checks
// Destructuring - produces ObjectPattern → Property node
const { constructor } = obj; // Not checked by any layer
Bár mindkét minta ugyanazt az eredményt adja, teljesen eltérő AST-ábrázolásokat hoznak létre. A PrototypeSanitizer csak a MemberExpression csomópontokat vizsgálja, a reguláris kifejezés pedig csak a .constructor mintákra illeszkedik. A dekonstruáló hozzárendelések VariableDeclaration → ObjectPattern → Property csomópontokat hoznak létre, amelyeket egyik szanitizáló sem vizsgál át.
Ezt tovább súlyosbítja az n8n nyílfüggvények kezelése. A FunctionThisSanitizer kizárólag a FunctionExpression csomópontokat fogja meg, és átírja őket úgy, hogy a `this`-t egy biztonságos kontextushoz kössék. A nyílfüggvények ArrowFunctionExpression AST-csomópontokat hoznak létre, amelyeket a tisztító nem dolgoz fel. Mivel a nyílfüggvények a `this`-t a körülvevő hatókörből öröklik (lexikális `this`), hozzáférést biztosítanak a tisztítatlan globális kontextushoz.
Ez a két figyelmetlenség együttesen teljes megkerülést eredményez: a dekonstrukció kivonja a Function konstruktort anélkül, hogy bármilyen tulajdonság-hozzáférési ellenőrzést indítana el, a nyílfüggvények pedig olyan végrehajtási kontextust biztosítanak, amelyet a FunctionThisSanitizer nem fog meg.
Kihasználás
A támadás mindkét biztonsági rést kihasználva egyszerre áttöri az összes védelmi réteget. Kollégáink a következő támadási útvonalat követték nyomon:
1. lépés – Nyílfüggvény megadása. A kód egy azonnal végrehajtott függvénykifejezésbe (IIFE) ágyazott nyílfüggvénnyel kezdődik:
={{(() => {
// Nyílfüggvény – megkerüli a FunctionThisSanitizer-t
...
})()}}
A FunctionThisSanitizer ellenőrzi, hogy a hívott kifejezés FunctionExpression-e; mivel ez egy ArrowFunctionExpression, a szűrő a hívás átírása nélkül korán visszatér. A nyílfüggvény a valódi globális kontextushoz való teljes hozzáféréssel fut.
2. lépés – Dekonstruálás megkerülése. A nyílfüggvényen belül a dekonstruálás kivonja a Function konstruktort a nyílfüggvény-példányból:
const { constructor } = () => {};
Mivel ez egy dekonstruáló hozzárendelés, az AST nem MemberExpression, hanem ObjectPattern csomópontot tartalmaz. A reguláris kifejezéses ellenőrzés nem talál .constructor mintát, a PrototypeSanitizer pedig soha nem vizsgálja a tulajdonság nevét. A támadó így hivatkozást szerez a Function konstruktorra.
3. lépés – Dinamikus kódfutás. Miután megszerezte a Function konstruktort, a támadó tetszőleges kódot állít össze és futtat:
return constructor(
'return process.mainModule.require("child_process").execSync("whoami").toString()',
)();
A dinamikusan létrehozott függvény a sandbox-környezeten kívül fut, teljes hozzáféréssel a Node.js folyamatobjektumhoz, ami lehetővé teszi tetszőleges rendszerparancsok végrehajtását a gazdagépen.
Koncepció igazolása
Annak érdekében, hogy bemutassuk ennek a biztonsági résnek a valós körülmények közötti hatását, kutatóink ellenőrzött laboratóriumi környezetben sikerült reprodukálniuk a támadást. A támadási forgatókönyv szerint egy sebezhető n8n-példányt üzemeltetnek, majd egy olyan munkafolyamatot importálnak, amely egy csomópont paraméterében rosszindulatú kódot tartalmaz – a támadás kifejezetten az „Edit Fields Node” csomópontot célozza meg, amely lehetővé teszi a kifejezések kiértékelését.
A munkafolyamat elindulása után a kártékony kód megkerüli mind az öt tisztító réteget, és egy visszafelé irányuló shell-t futtat a gazdaszerveren, ezzel teljes parancs-végrehajtási jogosultságot biztosítva a támadónak.
Webhook-on keresztüli eskaláció hitelesítés nélküli távoli kódvégrehajtáshoz
A sebezhetőség súlyossága jelentősen megnő, ha az n8n webhook-funkciójával kombináljuk. Az n8n lehetővé teszi a munkafolyamatok számára, hogy HTTP-végpontokat webhookként tegyenek közzé konfigurálható hitelesítési beállításokkal, beleértve a hordozói tokeneket, az alapvető hitelesítést, és – ami különösen kritikus – a hitelesítés teljes hiányát is. A munkafolyamat-létrehozási jogosultsággal rendelkező támadó beállíthat egy nyilvános webhookot „none” hitelesítéssel, beágyazhatja az RCE hasznos adatot egy csatlakoztatott csomópontba, és aktiválhatja a munkafolyamatot. Ekkor a webhook URL-re érkező bármely HTTP-kérés – az internet bármely pontjáról – tetszőleges parancsok végrehajtását indítja el a gazdaszerveren.
Ez az eszkalációs út a CVE-2026-25049-et egy hitelesített, belső biztonsági résből egy gyakorlatilag hitelesítés nélküli támadási csatornává alakítja, amely az egész internetre kiterjed.
Enyhítés
Az n8n csapata az 1.123.17-es és a 2.5.2-es verziókban orvosolta a CVE-2026-25049 biztonsági rést azáltal, hogy megfelelő futásidejű típusellenőrzést vezetett be a tisztító függvényekbe, és kibővítette az AST-lefedettséget a dekonstrukciós minták kezelése érdekében. Az érintett verziókat futtató szervezeteknek haladéktalanul frissíteniük kell a szoftvert.
Ha az azonnali frissítés nem lehetséges, a rendszergazdáknak a munkafolyamatok létrehozására és szerkesztésére vonatkozó jogosultságokat kizárólag a teljes mértékben megbízható felhasználókra kell korlátozniuk, és az n8n-t olyan megerősített környezetben kell üzembe helyezniük, ahol az operációs rendszer jogosultságai és a hálózati hozzáférés korlátozott.
Tekintettel a sebezhetőség kritikus súlyosságára és a kihasználásának egyszerűségére – különösen nyilvános webhookokkal kombinálva –, a szervezeteknek ellenőrizniük kell a meglévő munkafolyamatokat gyanús kifejezések szempontjából, figyelemmel kell kísérniük az n8n-folyamatból származó rendellenes rendszerparancsok végrehajtását, valamint át kell vizsgálniuk a webhook-konfigurációkat, hogy nincsenek-e hitelesítés nélkül elérhető végpontok.
Kockázatcsökkentés OPSWAT segítségével
OPSWAT használatával a szervezetek gyorsan azonosíthatják az infrastruktúrájukban található sebezhető n8n-komponenseket, és még a támadás bekövetkezte előtt intézkedhetnek. OPSWAT – amely a MetaDefender® platform alapvető technológiája – átfogó leltárt nyújt a szervezet környezetében használt összes szoftverkomponensről, könyvtárról és függőségről.
Az 1. ábrán látható módon MetaDefender átvizsgálta az n8n függőséget tartalmazó package.json fájlt, és automatikusan „Kritikus” minősítéssel jelölte meg a CVE-2026-25049 biztonsági rést, feltüntetve az érintett verziótartományt és a javításhoz ajánlott, hibajavított verziókat. Ez lehetővé teszi a biztonsági csapatok számára, hogy gyorsan azonosítsák és prioritásba sorolják a biztonsági rést a teljes telepítési környezetben.
OPSWAT elérhető MetaDefender és a MetaDefender Software Chain™ rendszerekben, amelynek köszönhetően a biztonsági csapatok:
- A sebezhető összetevők gyors felkutatása – Azonnal azonosítsa azokat a nyílt forráskódú függőségeket, amelyekre a sandbox-megkerülési és kódvégrehajtási sebezhetőségek hatással vannak, lehetővé téve azok gyors kijavítását vagy eltávolítását.
- Gondoskodjon a proaktív javításokról és frissítésekről – Folyamatosan figyelje a nyílt forráskódú komponenseket az elavult vagy biztonsági kockázatot jelentő csomagok felismerése érdekében, így biztosítva a frissítések időben történő elvégzését és a kockázatok csökkentését.
- A szabályozási előírások betartása és a jelentéstétel – A szabályozási keretek egyre nagyobb átláthatóságot írnak elő a szoftverellátási láncokban, ezért fontos, hogy ezeknek a követelményeknek eleget tegyen.
Hivatkozások
- NVD – CVE-2026-25049
- n8n biztonsági figyelmeztetés – GHSA-6cqr-8cfr-67f8
- n8n RCE(k): Négy felvonásos történet – Fatih Çelik
- A CVE-2026-25049 részletes elemzése – SecureLayer7
- CVE-2026-25049: Az n8n-ben távoli kódfuttatáshoz vezető kifejezés-kijátszási sebezhetőség – Endor Labs
- n8n biztonsági figyelmeztetés – CVE-2025-68613 (GHSA-v98v-ff95-f3cp)
