n8n :: Remember, remember, the velvet November


node:	n8n
template:	4
parent:	Projekty Interesante (github, gitlab, codeberg, ...) 🚀🛠️💻
owner:	drakh
viewed by:
created:	16.12.2025 - 09:04:03

cwbe coordinatez:
101
63540
9280435
9282154

ABSOLUT
KYBERIA

permissions
you:	r,
system:	public
net:	yes

n8n is a workflow automation platform that gives technical teams the flexibility of code with the speed of no-code. With 400+ integrations, native AI capabilities, and a fair-code license, n8n lets you build powerful automations while maintaining full control over your data and deployments.

https://github.com/n8n-io/n8n

0000010100063540092804350928215409285388

btw https://socradar.io/blog/cve-2026-21877-n8n-authenticated-rce/

0000010100063540092804350928215409282267

no dobre a teraz co s tym ze to je cele v nodejs, ktory ma notoricky problem s backdoornutymi libkami? :)

000001010006354009280435092821540928226709282401

pozeram ze zas ani take PyPI supply chain attacks nie su raritou..

00000101000635400928043509282154092822670928240109282795

ano, v podstate najlepsie je na tom asi stare dobre C, ale ani to neostalo neposkvrnene - bz2 (ci xz?) libka bola tampernuta pred casom

asi to bude tak ze cim viac libiek, tym vacsie riziko

ja len ze nodejs je tym povestne :)

alebo

rv7f7ovg4swz.png?width=1080&crop=smart&auto=webp&s=b37916a93760123a6fec37eb191512834fffd0c9

000001010006354009280435092821540928226709282273

mozes si to pustit v dockeri ;) - maju aj nimi zbuildeny image, tak ten snad bude cisty.

Ako som uz pisal NodeJS (a npm) je target kvoli tomu sirokemu pouzitiu. No a developeri su trotli a buchaju vselijake tajnosti kam by nemali.. no a potom tu mame Shai Hulud aj vo verzii 2.

Ale, tak ono sa tieto ataky tykaju aj inych softov.. len v mensom objeme, aj v takom ComfyUI (python) uz bolo niekolo poisoned balikov

00000101000635400928043509282154092822670928227309282797

ten docker priamo od nich by mohol hadam ako-tak pomoct
aj tak by som tomu neveril na 100%
a vlastne najlepsie nicomu, zero-trust a hotovo :)

00000101000635400928043509282154092822670928227309282578

problem nie je, kde si to pustis, ale k comu to ma pristup. a kedze to sluzi na automatizaciu, tak casto to ma tokeny vsade mozne.

0000010100063540092804350928215409282267092822730928257809282590

No, vsak hej.. ale tak tento issue majú všetky agenty, a ešte uvidíme v tomto smere kopec zábavy

?

00000101000635400928043509282154092822670928227309282427

" No a developeri su trotli a buchaju vselijake tajnosti kam by nemali" -
Pozeral som ako funguje Shai Hulud 1 a 2 a teda nemam pocit, ze by problem bol secrets v .env ... alebo to chapem zle? Ako to robia ine jazyky? Robil som iba mobilnu javu a tam mas tiez placnute secrets v ignored suboroch. Ci co je podla teba riesenie?

Best practive je mat sha/commit pinning atp - ale realne to neriesi ten problem na 100%

0000010100063540092804350928215409282267092822730928242709282439

zasadny problem je ked secrety v gitignore nemas a dostanu sa do public repozitara alebo ako tu niekto narve secrety do clientside kodu ( https://kyberia.sk/id/9273340 )

Pokial viem, patient zero nie je znamy, ale, predpoklada sa ze bol infikovany prave cez leaknute npmjs secrety a ked sa do npm vypublishovala dana package a niekto zo supply chainu nemal pinnute verzie svohich dependencies tak to uz islo samo.

Ako sa tomu branit... nuz neviem. jedine asi cez security by obscurity.. spravna MFA - co asi znamena ze publish do npmjs repozitara len manualne nie automatom.

audit pouzivanych dependencies.. ale no tento problem je vsade. pri node je to vypuklejsie kedze na FE sa bez javascriptu nepohnes takze je jasne ze NodeJS ekosystem bude viac targetovany z podobnych dovodov preco je virusmi najviac targetovany WIN medzi OS.

000001010006354009280435092821540928226709282273092824270928243909282472

hej presne!

personal (shamefull) story: vzdy som si vravel ze ludia su blbci ked toto urobia a minule som zapol https://aikido.dev a tiez som objavil v nejakom zapadnutom commite S3 admin secret :/ a teda uz som zistil, ze velakrat chyba, nie je pre zle .env alebo git config, ale proste nezpornost - u debugu niecoho odides na zachod, ked sa vratis testy bezia, all green ... Granularita S3 keys je tiez neprakticka, tak lahsi je debug s test admin klucom. Sranie sa s loadovanim env v nejakom random debug scripte - rychlejsie je ho tam placnut - ved iba na sekundu.

Release robim vzdy rucne, mam MFA, pouzivam uplne minimum deps, subory pred commitom prechadzam cez UI/gitu - akurat vtedy raz som nebol pozorny a prehliadol som nejaky kus suboru (este zakomentovany kod!) co bol len na testing/debug ... a dal som "git add ." a je to! Som si isty ze na niektorom projekte som uz takuto botu urobil a myslim ze github ma nenechal pushnut. Teraz som sa zabudol + asi spoliehal na ten nastroj, ktory medzicasom niekde zmizol(opt-out?) alebo sa zmenil default config?

Unpopular opinion, ale za vela % problemov (extra v dev/op-sec) je zly/neprakticky dizajn nastrojov pre lamy ako som ja.

- Npm/node/bun by uz davno mohli mat built-in izolaciu, automaticke cache deletion po utokoch, vypnute "npm config set ignore-scripts true --location=global" by default s whitelistom, nepovolit package release bez updatu a pin deps by default, enfrocovat 2FA
- Git a rozne uicka zase built-in scanners na detekciu secrets, alebo aspon triggr keywords. Motivovat ludi prechadzat pri stage zmeny jednu po druhej...

Avsak kontrolovat a prechadzat kod pri kazdej dependency sa mi zda nerealne. Hlavne malware moze byt obfuscated a strceny v strome niekde uplne hlboko. Dnes, ked ludia instaluju Claude Code s global pristupom na stroj sa malware transformuje na neviditelne glyphs v nejakom readme alebo favicone a si KO.

00000101000635400928043509282154092822670928227309282427092824390928247209282619

repozitare by na toto mali uz mat hooky porobene. aspon tento rok na mna zacal github bliakat, ked commitujem cokolvek co sa podoba na secrety, hoc len do komentara alebo v ramci testov