4.576 tokenuri API n8n scurse pun 321 de instanțe active în pericol
GitGuardian: 4.576 tokenuri API n8n scurse; 321 instanțe (~36%) le-au acceptat. Atacatorii pot declanșa fluxuri de lucru pentru a exfiltra informațiile de autentificare stocate, fără a necesita exploatarea unei vulnerabilități (CVE).
Pe scurt
- GitGuardian a scanat commit-urile publice de pe GitHub și a găsit 4.576 de token-uri API n8n expuse și 1.255 de nume de gazdă; 896 de instanțe erau accesibile public și 321 (~36%) acceptau token-urile scurse.
- Token-urile scurse, dacă sunt acceptate, permit adversarilor să enumere utilizatori, să obțină fluxuri de lucru, să declanșeze execuții și să exfiltreze credențiale sau date stocate; 58% din instanțe rulau versiuni cu avertismente cunoscute, ceea ce crește riscul operațional.
- Conducerea ar trebui să inventarieze token-urile expuse și instanțele accesibile, să revoce cheile API compromise, să evalueze fluxurile de lucru afectate și credențialele dependente, să aplice actualizările de securitate pentru n8n și să monitorizeze depozitele de cod pentru eventuale scurgeri suplimentare.
Problema
Scanarea GitGuardian a commit-urilor publice de pe GitHub a găsit 4,576 tokenuri API n8n expuse și 1,255 nume de gazdă; 896 dintre instanțe erau accesibile public și 321 (≈36% din instanțele accesibile) au acceptat tokenurile scurse. Aceste tokenuri permit atacatorilor să enumere utilizatori și fluxuri de lucru și să declanșeze execuții care pot exfiltra credențiale și date stocate fără a exploata un CVE — în timp ce 58% dintre instanțe rulează versiuni vulnerabile cunoscute, inclusiv CVE‑2025‑68613 (CVSS 9.9), ceea ce crește substanțial riscul de compromitere laterală și furt ulterior de credențiale.
De ce se intampla
Scanarea GitGuardian a găsit 4,576 tokenuri API n8n expuse și 1,255 de hostname-uri; 896 de instanțe erau accesibile public și 321 (~36%) au acceptat tokenuri scurse. Aceste chei API sunt JWT semnate (multe dintre cele mai vechi nu aveau claim-ul exp și rămân valide până sunt eliminate din baza de date n8n); când o cheie este acceptată, API-ul platformei permite unui apelant autentificat să enumere utilizatori și fluxuri de lucru și să creeze/activeze fluxuri de lucru. În practică, un atacator poate adăuga un trigger de tip Schedule și noduri care fac referire la credențiale stocate sau citesc tabele de date, poate lăsa fluxul de lucru să ruleze, apoi poate recupera înregistrările de execuție (sau poate face ca fluxul să trimită secrete prin POST către un listener al atacatorului) — și pentru că fluxurile și înregistrările de execuție pot fi șterse, dovezile pot fi eliminate. Cu 58% din instanțele scanate care rulează versiuni cu avertismente de securitate cunoscute (inclusiv CVE‑2025‑68613), raza operațională a impactului și probabilitatea unui compromis lateral cresc semnificativ. Echipele subestimează adesea acest risc pentru că tratează un token API scurs ca fiind de risc redus atunci când nu e nevoie de o exploatare prin CVE sau când endpointul /api/v1/credentials nu returnă direct valorile secrete. Această presupunere omite mecanismul platformei: funcționalități legitime (activarea fluxurilor de lucru, execuțiile programate, nodurile HTTP Request) pot fi abuzate pentru a expune sau transmite secrete fără nicio exploatare a unei vulnerabilități. Consecința concretă pentru cumpărător este măsurabilă — revocarea tokenurilor expuse, inventarierea instanțelor și a fluxurilor accesibile, rotația credențialelor downstream care ar putea fi accesate și patch‑uirea/configurarea instanțelor (expirarea tokenurilor, restricții API, allowlist pentru noduri) pentru a reduce raza de impact și expunerea la riscuri de conformitate.
Cadru de lucru
Revocă și rotește token-urile
Identifică și revocă imediat orice token API n8n expus, rotește credențialele downstream accesibile prin aceste token-uri și impune TTL-uri scurte și expirări obligatorii; prioritizează cheile legate de commit-urile publice. Această măsură reduce accesul activ al atacatorilor — GitGuardian a găsit mii de token-uri scurse și sute de instanțe în funcțiune care le acceptau — diminuând raza de acțiune imediată și riscul de compromitere laterală.
Secrete în controlul sursei
Scanează repository-urile publice și private pentru hostname-uri n8n și chei API comise, elimină fișierele sensibile din istoric (sau rotește-le dacă eliminarea e nepractică) și adaugă scanare de secrete în pre-commit/CI pentru a preveni scurgerile viitoare. Cercetarea arată că token-urile și hostname-urile erau frecvent comise împreună (de ex. fișierele .env și .claude), deci prevenirea commit-urilor este controlul cu cel mai mare efect.
Aplică patch-uri și întărește instanțele
Inventariază instanțele n8n accesibile de pe internet, prioritizează upgrade-urile pentru versiunile cu avertismente publicate (inclusiv CVE‑2025‑68613), dezactivează API-ul public când nu este necesar și activează liste albe/negre pentru noduri și restricții de acces la API. Cu >50 advisories și 58% din instanțele scanate vulnerabile, aplicarea patch-urilor și modificările de configurație reduc semnificativ probabilitatea de compromitere ulterioară.
Detectează și răspunde la abuzuri
Configurează logare și alertare externă pentru crearea/activarea neașteptată a workflow-urilor, trigger-e programate, execuții cu includeData=true și ștergeri; rulează interogări de tip hunt pentru workflow-uri care apelează endpoint-uri externe necunoscute și blochează destinațiile outbound suspecte. Deoarece atacatorii pot declanșa workflow-uri pentru a exfiltra credențiale stocate și apoi șterge urmele, detectarea rapidă și containerea sunt esențiale pentru a limita pierderea de date și a păstra traseele forenzice.
Cum incepi
- Revocați toate token-urile API găsite în commit-uri publice; înregistrați ID-urile token-urilor și marcajele de timp ale revocării.
- Inventariați numele de gazdă n8n accesibile din internet și înregistrați versiunea, starea API-ului public și acceptarea token-urilor expuse.
- Rotați credențialele downstream accesibile conturilor compromise și impuneți rotația pentru integrările cu risc ridicat.
- Actualizați toate instanțele n8n accesibile din internet la versiuni remediate sau aplicați mitigările recomandate de furnizor.
- Activați logarea și alertele pentru crearea fluxurilor de lucru, activare și execuții (includeData=true), precum și pentru destinațiile POST externe.
Riscuri si compromisuri
Perspectiva strategica
Descoperirea GitGuardian (4.576 token‑uri API n8n expuse, 1.255 hostname‑uri, 896 instanțe accesibile și 321 care acceptau token‑uri scurse) reconfigurează automatizarea fluxurilor de lucru ca un componentă de infrastructură cu rază mare de impact: deoarece multe token‑uri nu aveau expirare și fluxurile n8n pot fi activate pentru a citi sau exfiltra secrete (iar atacatorii pot șterge dovezile), operatorii trebuie să trateze cheile API și vizibilitatea instanțelor ca controale operaționale de primă importanță. Practic, asta înseamnă mutarea guvernanței către politici măsurabile de ciclu de viață al token‑urilor (aplicarea TTL‑ului token‑urilor ≤ 30 zile, așa cum a introdus n8n v1.78.0; revocarea token‑urilor cunoscute ca fiind compromise în 24–72 de ore), un inventar al instanțelor accesibile din internet cu statutul de acceptare înregistrat și un ritm de patchare care reduce instanțele vulnerabile (58% în scan) pe un orizont de remediere de 30–90 de zile. Prioritățile de investiție ar trebui să favorizeze scanarea automată a repository‑urilor, blocarea la CI/pre‑commit a commit‑urilor care conțin variabile de mediu sau credențiale, întărirea expunerii API publice și reguli de detecție pentru crearea/activarea neașteptată a fluxurilor de lucru și pentru execuțiile includeData; rezultatele măsurabile sunt simple — zero acceptări publice ale token‑urilor, aplicarea TTL pentru 100% din tokenuri și o reducere documentată a versiunilor vulnerabile expuse pe internet în următoarele 12–24 luni.
Pașii următori pe care îi recomandăm
Inventariați imediat commit-urile publice de pe GitHub și hostname-urile n8n accesibile pe internet pentru a identifica tokenurile acceptate; revocați acele chei API în 24–72 de ore și înregistrați marca temporală a revocării; apoi rotiți acreditările downstream și notați ce fluxuri de lucru ar fi putut avea acces la ele pentru remediere prioritară.