A GitGuardian kutatói 321 olyan n8n példányt találtak, amelyek elfogadták a nyilvános GitHub commitokban kiszivárgott API-tokeneket, és négyféle támadási módszert mutattak be, amelyekkel a támadók szoftveres sebezhetőség kihasználása nélkül is hozzáférhetnek érzékeny adatokhoz és további hitelesítő adatokhoz.

Nyilvános GitHub commitokat vizsgáltunk át kiszivárgott n8n API-tokenek után kutatva, és 4 576 egyedi hitelesítő adatot azonosítottunk, amelyek 1 255 hostnévhez tartoztak. A tesztelés idején elérhető 896 példány közül 321 legalább egy kiszivárgott tokent elfogadott.

Vagyis a kiszivárgott hitelesítő adatok a vizsgált, elérhető példányok 36%-ához biztosítottak hitelesített hozzáférést, ami nagyjából az összes, commitokban azonosított hostnév 26%-ának felel meg.

A következmények messze túlmutatnak magán az n8n-en. A szervezetek az automatizálási platformot adatbázisok, forráskód-tárolók, felhős környezetek, mesterségesintelligencia-szolgáltatások, ügyféltámogató rendszerek és más belső rendszerek összekapcsolására használják. Egy kellően nagy jogosultságú n8n-token felfedheti a workflow-definíciókat és a futási adatokat, lehetővé teheti a támadóknak a tárolt hitelesítő adatok használatát, és bizonyos konfigurációkban még az alapul szolgáló hitelesítő adatok értékeinek kinyerését is.

A lehetséges kár mértékének felméréséhez négy gyakorlati támadási technikát reprodukáltunk egy kontrollált n8n környezetben. Mindegyikhez elegendő volt a dokumentált REST API-funkcionalitás és szabványos HTTP-kérések használata. Nem kellett CVE-t kihasználni, és nem volt szükség speciális eszközökre sem.

Miért vonzó célpont az n8n

Az n8n egy nyílt forráskódú, low-code workflow-automatizálási platform, amely AI agent támogatást és több száz beépített integrációt kínál. A szervezetek belső eszközök összekapcsolására, pipeline-ok automatizálására, üzleti logika megvalósítására és API-integrációk összehangolására használják a teljes technológiai stackjükben.

A platformot lehet saját szerveren futtatni vagy n8n.cloud-on keresztül telepíteni, és a nyílt forráskódú tárolója közel 200 000 GitHub csillagot gyűjtött össze.

Egy n8n példány workflow-kat futtat, amelyek node-okból állnak. Egyes node-ok időzítve vagy webhookon keresztül indítják a workflow-kat, mások adatot alakítanak át, kódot futtatnak, vagy külső szolgáltatásokhoz kapcsolódnak tárolt hitelesítő adatok – például API-kulcsok, tokenek és adatbázis-jelszavak – segítségével.

Ezeket a hitelesítő adatokat a rendszer nyugalmi állapotban egy N8N_ENCRYPTION_KEY nevű mesterkulccsal titkosítja. Amikor azonban egy workflow fut, az n8n-nek ezeket vissza kell fejtenie és használnia kell. Ha egy támadó elég magas API-jogosultsággal rendelkezik, hivatkozhat ezekre a hitelesítő adatokra új workflow-kban, és ráveheti a példányt, hogy az ő nevében használja őket.

A Shodan több mint 100 000 látható példányt jelez, és 2026 januárja óta több mint 50 biztonsági figyelmeztetés jelent meg az n8n-ről, így a platform hasonló figyelmet kapott, mint más, nagy értékű integrációs rendszerek.

2026. március 31-én az általunk vizsgált példányok 58%-a olyan verziót futtatott, amelyre legalább egy ismert biztonsági figyelmeztetés vonatkozott. Több friss CVE lehetővé tette a támadók számára, hogy kitörjenek a futtatási sandboxból, és tetszőleges olvasási vagy írási hozzáférést szerezzenek a host fájlrendszeréhez.

A 9,9-es CVSS pontszámú, kifejezésinjektálási sebezhetőséget jelentő CVE-2025-68613-at 2026. március 11-én felvették az amerikai Cybersecurity and Infrastructure Security Agency Known Exploited Vulnerabilities katalógusába, ami megerősítette, hogy a sebezhetőséget aktívan kihasználják.

A kiszivárgott API-tokenek külön kockázatot jelentenek. Ha egy érvényes hitelesítő adat már eleve hitelesített hozzáférést biztosít a példányhoz, a támadónak nem feltétlenül kell n8n sebezhetőséget kihasználnia.

321 példány fogadta el a kiszivárgott tokeneket

A GitGuardian Public Monitoring nyilvános forrásokat vizsgál át kiszivárgott hitelesítő adatok után. Ehhez a kutatáshoz összegyűjtöttünk minden n8n API-tokenet, amelyet 2025 áprilisa óta azonosított nyilvános GitHub commitokban.

A pipeline kinyerte az egyes tokenek mellé commitolt n8n hostnevet, csak olvasható ellenőrző kérést küldött a kapcsolódó példánynak, majd rögzítette a választ.

A vizsgálat eredménye:

StageCountEgyedi API-tokenek4 576Tokeneket tartalmazó GitHub-commitok5 469Kinyert egyedi hostnevek1 255Nyilvánosan elérhető példányok896Kiszivárgott tokent elfogadó példányok321

A 321 megerősített példány nagyjából a 896 elérhető példány 36%-át és az összes, commitokban azonosított 1 255 hostnév 26%-át jelenti.

Ugyanezt a folyamatot lefuttattuk az ugyanebben a commit-halmazban talált n8n Model Context Protocol API-kulcsokra is. Az MCP-tokenek lehetővé teszik, hogy AI asszisztensek a Model Context Protocolon keresztül hívjanak n8n workflow-kat, így újabb kitettségi felületet jelentenek, mint a REST API.

A 372 azonosított MCP-token közül hét volt még érvényes a tesztelés idején, vagyis nagyjából 2%.

Miért maradhatnak érvényesek a kiszivárgott n8n-tokenek

Az n8n API-kulcs egy aláírt JSON Web Token, amelynek "aud": "public-api" audience claimje van. Egy dekódolt token így néz ki:

{ "sub": "efdf9cca-049a-46aa-afdc-172f0824f6cb", "iss": "n8n", "aud": "public-api", "jti": "aac8a7a8-c8c4-4855-8e8b-2806e90b16e1", "iat": 1781551662 }

A token az iat mezőben rögzíti a kiállításának időpontját. A régebbi n8n API-kulcsokban gyakran nincs exp mező, amely a lejáratot határozná meg.

Az n8n 2025 februárjában, az 1.78.0-s verzióban vezetett be 30 napos alapértelmezett lejáratot, de a kutatás során talált sok token még lejárati idő nélkül készült. Egy GitHub hónapja commitolt kulcs így addig használható maradhat, amíg valaki kifejezetten nem törli vagy nem vonja vissza.

Gyakorlatban az n8n API-kulcsok máshogy viselkednek, mint az önmagukban érvényesíthető JWT-k, amelyeket elég az aláírásuk alapján ellenőrizni. A kulcsnak az n8n adatbázisában is léteznie kell. Egy GitHub során kiszivárgott token addig jelent kockázatot, amíg a példány érvényesnek ismeri el.

Egy gyanús token teszteléséhez elég egy csak olvasási kérelem, ahol a kulcs az X-N8N-API-KEY fejlécben szerepel:

curl -s -o /dev/null -w "%{http_code}" \ -H "X-N8N-API-KEY: " \ https://n8n.example.com/api/v1/workflowsA GET /api/v1/workflows az adott felhasználó számára elérhető workflow-definíciókat adja vissza.

A 200-as válaszkód megerősíti, hogy a token érvényes. A 401 azt jelzi, hogy a token érvénytelen, törölték az adatbázisból, vagy az aláírás-ellenőrzés sikertelen volt. A 404 arra utalhat, hogy a public API-t letiltották az adott példányon.

A kérés nem módosít semmit a célpéldányon.

Gyakran a token mellett a példány URL-je is bekerül a commitba

Az n8n API-kulcs csak akkor hasznos a támadónak, ha meg tudja találni azt a példányt, amely elfogadja. A nyilvános GitHub commitokban viszont a hostnév és a token gyakran együtt szerepel.

Tipikus példa egy .env fájl:

N8N_URL="http://n8n.redacted.cloud:5678" N8N_API_KEY="eyJhREDACTEDPWw4"

Találtunk egy újabb mintát is, amely a Claude Code jogosultsági fájljaihoz kapcsolódik.

A Claude Code a jóváhagyott shell parancsokat a .claude/settings.json vagy a .claude/settings.local.json fájlban tárolja. Ha a felhasználók úgy állítják be a Claude Code-ot, hogy az n8n-nel kommunikáljon, gyakran közvetlenül egy engedélyezett curl parancsba írják bele a példány URL-jét és az API-kulcsot is.

bash(curl -s "https://automation.redacted.fr/api/v1/workflows" \ -H "X-N8N-API-KEY: eyJhREDACTEDegE")

Ezeket a beállításfájlokat aztán úgy is commitolhatják egy tárolóba, hogy nem vonatkoznak rájuk azok a .gitignore szabályok, amelyeket a fejlesztők a .env fájlokra általában beállítanak.

Ugyanilyen hostnév–token párosítást több más változónév alatt is találtunk, például:

N8N_MCP_URL N8N_WEBHOOK_BASE_URL process.env.N8N_URL os.getenv("N8N_HOST", "...")

Mivel a hostnév általában ugyanabban a commitban szerepelt, mint a token, a pipeline-nak nem volt szüksége külön infrastruktúrafelderítési lépésre.

Mit tesz láthatóvá egy hitelesített n8n-token

Az n8n API-token ugyanazokkal a jogosultságokkal fér hozzá a rendszerhez, mint a felhasználó, aki létrehozta. A gyakorlatban a kiszivárgott tokenek nagy része láthatóan példánytulajdonosokhoz vagy adminisztrátorokhoz tartozott, valószínűleg azért, mert ők állították be az integrációkat, és ők commitolták a kulcsokat.

A fiók szerepkörétől függően a public REST API a következőket teheti elérhetővé:

• GET /api/v1/users: felhasználónevek, e‑mail címek, fiók létrehozásának dátuma, függőben lévő meghívók. Bizonyos adatok csak a példány tulajdonosai számára láthatók.
• GET /api/v1/workflows: teljes workflow-definíciók, beleértve a node-ok konfigurációját, JavaScript- vagy Python-kódot a Code node-okban, SQL-lekérdezéseket és a workflow-paraméterekbe közvetlenül beírt titkos adatokat.
• GET /api/v1/credentials: hitelesítő adatok neve, típusa és megosztási információi, de nem maguk az értékek. Ezt az endpointot csak tulajdonosok és adminisztrátorok érhetik el.
• GET /api/v1/executions: workflow-futtatási előzmények. Az ?includeData=true paraméterrel minden futás teljes bemeneti és kimeneti payloadja is visszajöhet.
• GET /api/v1/data-tables: a hitelesített felhasználó számára látható táblák sorai.
• GET /api/v1/variables: változónevek és tartalmuk. Ez az endpoint szintén csak tulajdonosok és adminisztrátorok számára elérhető.

A workflow-definíciók jelentik a legközvetlenebb kitettséget, mert az API a node-ok teljes konfigurációját visszaadja. Ha egy fejlesztő az API-kulcsot vagy tokent közvetlenül egy node paraméterébe írta be, és nem az n8n credential tárolóját használta, az érték akár tiszta szövegként is megjelenhet.

A credential endpoint önmagában nem adja vissza az eltárolt titkos értékeket. Kontrollált tesztjeink viszont azt mutatják, hogy ha a támadó létrehozhat és futtathat workflow-kat, akkor hivatkozhat egy eltárolt hitelesítő adatra, és ráveheti az n8n-t, hogy azt felhasználja vagy továbbítsa.

Az audit endpoint támadási térképet ad

Az n8n audit endpointja biztonsági jelentést tud adni a példányról a hitelesített felhasználónak:

curl -H "X-N8N-API-KEY: $JWT" \ -d "{}" \ -H "Content-Type: application/json" \ https://$N8N_INSTANCE/api/v1/auditA válasz az alábbiakat azonosíthatja:

• Potenciális SQL injection kitettségeket a workflow-kban
• Fájlrendszer-hozzáféréssel rendelkező node-okat
• Védtelen webhookokat
• A futó n8n verzióját, amit össze lehet vetni ismert CVE-kkel
• Nem használt hitelesítő adatokat
• Magas kockázatú vagy a közösség által telepített node-okat
• Engedélyezett biztonsági funkciókat
• Node allowlistákat és blocklistákat
• Telemetria-beállításokat

Egy jogosult adminisztrátor számára ezek az információk segítik a biztonsági felülvizsgálatot. Egy kiszivárgott, privilégizált tokent birtokló támadó viszont priorizált térképet kap a példány legígéretesebb támadási útvonalairól.

Négy támadási technika egy teljesen frissített példány ellen

A GitGuardian az alábbi kihasználási technikákat nem alkalmazta éles, harmadik felek által üzemeltetett rendszereken. Kontrollált, kifejezetten a kutatáshoz felépített n8n környezetben reprodukáltuk őket.

A teszt-workflow három szándékos gyengeséget tartalmazott:

• Egy webes űrlap a beküldéseket egy data table-ben tárolta, amely hitelesített workflow-kon keresztül volt elérhető.
• Egy OpenAI node minden beküldést egy eltárolt credential objektummal dolgozott fel.
• Egy HTTP Request node a kimenetet GitHub-re publikálta, a node paramétereiben közvetlenül beégetett tokennel.

Ebben a környezetben négy technikát mutattunk be, a passzív feltérképezéstől az aktív hitelesítőadat-kiszivárogtatásig.

Example n8n workflow

1. technika: A példány feltérképezése

A GET /api/v1/users négy fiókot adott vissza: a példány tulajdonosát, két aktív felhasználót és egy függőben lévő regisztrációt.

A GET /api/v1/workflows kilenc teljes workflow-definíciót adott vissza. A célzott workflow-ban egy HTTP Request node paraméterei között a GitHub token tiszta szövegként szerepelt.

Ehhez az első technikához nem kellett módosítani a workflow-kat. A kiszivárgott információ már eleve elérhető volt az adott fiók számára engedélyezett olvasási műveleteken keresztül.

2. technika: Eltárolt OpenAI credential használata

A GET /api/v1/credentials minden eltárolt credential objektumot felsorolt, köztük egyet „OpenAI account” néven. Az endpoint a nevet, a típust és az azonosítót árulta el, magát az API-kulcsot viszont nem.

Létrehoztunk egy workflow-t Schedule triggerrel és egy OpenAI node-dal, amely az azonosítója alapján hivatkozott a credentialre, majd aktiváltuk.

Két trükk teszi ezt működőképessé. A Schedule trigger nagyjából 10 másodperc után automatikusan lefut, így a workflow be tud fejeződni. A GET /api/v1/executions?includeData=true ezután lekéri a teljes futási naplót. Mivel az n8n minden node teljes kimenetét eltárolja, az OpenAI válasza tiszta szövegként jelenik meg.

Sikeresen futtattunk tetszőleges OpenAI promptokat a példány eltárolt credentialjével anélkül, hogy valaha láttuk volna annak értékét.

3. technika: A data table kiolvasása

Ugyanaz a két trükk itt is működik.

Létrehoztunk egy workflow-t Schedule triggerrel és egy Data Table node-dal, amely az összes sort lekérésére volt konfigurálva, majd aktiváltuk. A GET /api/v1/executions?includeData=true néhány másodperccel később visszaadta a futási naplót, minden sorral tiszta szövegként.

Négy sort szivárogtattunk ki, köztük neveket, e-mail-címeket, űrlapválaszokat és feldolgozási állapotokat.

A workflow-t ezután töröltük.

4. technika: A nyers OpenAI credential kiszivárogtatása

A negyedik technika túllépett az eltárolt credential puszta használatán, és magát az alatta lévő értéket is kinyerte.

Elindítottunk egy HTTP listenert, majd létrehoztunk egy workflow-t Schedule triggerrel és egy HTTP Request node-dal.

A kulcsfontosságú trükk, hogy a HTTP Request node bármely URL felé küldött kérésnél használhat eltárolt n8n credentialt hitelesítési módszerként. A node-ot úgy állítottuk be, hogy a tárolt OpenAI credentialt használja, a kérést pedig a listenerünkre irányítottuk.

Amikor a workflow lefutott, az n8n a credential értékét Bearer tokenként csatolta a kimenő Authorization headerhez. A listener néhány másodperccel az aktiválás után rögzítette a nyers API-kulcsot.

A workflow-t ezután töröltük.

Ezek a technikák együtt azt mutatják meg, hogyan tud egy támadó egy kiszivárgott n8n tokenből kiindulva, teljesen legitim platformfunkciókat használva szélesebb körű hitelesítőadat- és adat-kitettséget elérni:

• Feltérképezi a felhasználókat, a workflow-kat és a biztonsági konfigurációt.
• Azonosítja az eltárolt credential objektumokat és a beégetett titkokat.
• Úgy használ eltárolt credentialeket, hogy nem látja az értéküket.
• Kiolvassa a workflow-k számára elérhető adatokat.
• Ráveszi az n8n-t, hogy egy eltárolt credentialt egy támadó által vezérelt infrastruktúrára küldjön.

A rosszindulatú workflow törlése az ahhoz tartozó futási naplókat is eltávolította a felületről, így a védőknek kevés bizonyíték maradhat a vizsgálathoz.

Valódi workflow-kban is hasonló gyengeségeket találtak

A kontrollált demonstráció nem pusztán elméleti konfiguráción alapult. A kutatás során olyan éles n8n példányokat találtunk, amelyekben hasonló minták jelentek meg.

Az egyik workflow automatikusan a saját definícióit mentette egy nyilvános GitHub tárolóba. Egy SSH deployment key-t közvetlenül az egyik node-ba égettek be.

A tároló Git előzménye minden workflow korábbi verzióját tartalmazta, és az SSH-kulcs továbbra is érvényes volt.

A workflow gyakorlatilag minden futáskor a saját érzékeny konfigurációját és hitelesítő adatait publikálta.

Az eset jól mutatja, miért tudnak a workflow-automatizálási platformok szokatlanul nagy kárt okozni. Több rendszer között helyezkednek el, érzékeny adatokat dolgoznak fel, és rendszeresen hitelesítenek külső szolgáltatások felé. Egyetlen workflow gyengesége az automatizálási platformon messze túlmutató hozzáférést tárhat fel.

Felelős bejelentés, korlátozott reakciók

Egy érvényes, kiszivárgott credential megtalálása csak az első lépés. A kockázat addig marad fenn, amíg az érintett szervezet nem vonja vissza, és nem kezeli a tovagyűrűző kitettséget.

Hét szervezetnél próbáltunk felelős bejelentést tenni:

• Három hosting szolgáltatónál, amelyek összesen nagyjából 100 érintett példányhoz kapcsolódtak
• Négy egyedi cégnél

Az egyik hosting szolgáltató nem válaszolt. A négy egyedi cég közül három szintén nem reagált.

Az egyik cég bug bounty programot működtetett, elismerte a bejelentést, 1200 dolláros jutalmat fizetett, és azonnal visszavonta a credentialt. Ez a fajta gyors és elismerő reagálás számított kivételnek.

A GitGuardian a kutatás során közvetlenül az n8n felé is több bejelentést tett. Az n8n elismerte a jelentéseket, jelezte, hogy tisztában van a problémákkal és tervezi a kezelésüket, majd lezárta a jelentéseket. A publikálás időpontjában a GitGuardian önállóan még nem erősítette meg, hogy a kapcsolódó javítások megjelentek.

A 321 érintett példány körülbelül 30%-át n8n.cloudon vagy hasonló menedzselt szolgáltatásban hostolták.

A GitGuardian Public Monitoring már most is azonosítja a kiszivárgott n8n API-tokeneket, és értesíti az érintett fejlesztőket a cég Good Samaritan bejelentési programján keresztül. A mostani eredmények miatt a GitGuardian frissítette az n8n API-kulcs detektorát és az érvényesség-ellenőrzéseket, hogy pontosabban tudja azonosítani a kitettségeket.

Tanulságok

Egy kiszivárgott n8n token nem elszigetelt credential-kitettség. Egy kellően privilégizált token hozzáférést adhat workflow-definíciókhoz, beégetett titkokhoz, futási adatokhoz és belső táblákhoz. Lehetővé teheti, hogy a támadó eltárolt credentialeket használjon, vagy olyan workflow-t hozzon létre, amely ezeket egy külső végpontra küldi, és így kinyeri az alatta lévő értékeket.

A kontrollált tesztek során nem volt szükség CVE-re vagy speciális eszközökre. Néhány szabványos HTTP-kérés is elég volt ahhoz, hogy egy kiszivárgott tokenből érzékeny adatokhoz és további hitelesítő adatokhoz jussunk. A támadó ezután törölheti a workflow-t és a hozzá tartozó futási naplókat, így a védőknek az n8n-en belül kevés bizonyíték marad.

A kiszivárgott n8n token visszavonása csak az első lépés. A szervezeteknek fel kell mérniük, hogy az adott fiók milyen workflow-khoz, adatokhoz és további credentialekhez fért hozzá, át kell vizsgálniuk a példányt jogosulatlan módosítások után kutatva, és forgatniuk kell a kapcsolódó credentialeket, ha a kitettség nem zárható ki.

Az automatizálási platformok különösen nagy kockázati felületet teremtenek, mert a szervezet integrációinak középpontjában állnak. Egyetlen token is utat nyithat a verziókezelő rendszerek, adatbázisok, felhős szolgáltatások, AI API-k, ügyféltámogató platformok és ügyféladatok felé. A kockázatot nem csak az n8n példány határozza meg, hanem minden rendszer, amely hozzá kapcsolódik.