مشاهده توییت های دیگر

وقتی ابزاری مثل n8n رو وسط سازمان میارید که به همه‌جا، از APIهای LLM گرفته تا سیستم‌های IAM و دیتای فروش دسترسی داره، عملا دارید یک Skeleton Key به نفوذگر می‌دید. با افشای CVE-2026-1470 با امتیاز ۹.۹، مشخص شد که دور زدن Sandbox و رسیدن به RCE از اون چیزی که فکر می‌کردیم راحت‌تره.

مشکل اینجاست که خیلیا فکر می‌کنن چون n8n محیط Low-code داره، پس هر کسی با دو تا درگ‌-اند-دراپ می‌تونه معمار اتوماسیون سازمان باشه! (یا مثلا متخصص اتوماسیون با هوش مصنوعی 😂) فاجعه دقیقا از همین‌جا شروع می‌شه. سپردن زیرساخت اتوماسیون به آدم‌هایی که درک عمیقی از معماری نرم‌افزار و چالش‌های امنیتی ندارن، یعنی فاجعه...

توی این گزارش جدید، محقق‌های JFrog نشون دادن که حتی با وجود لایه‌های کنترلی مبتنی بر AST و لیست‌های سیاه، باز هم می‌شه از قابلیت‌های Deprecated شده یا رفتارهای خاص Interpreterها استفاده کرد و از زندان Sandbox فرار کرد. این یعنی امنیت در سطح کد، تضمین‌کننده نیست.

بزرگترین اشتباه استراتژیک، استفاده از Internal Mode در محیط Production است. n8n صراحتا هشدار داده که برای ایزوله‌سازی باید از External Mode استفاده بشه، اما آمار Shadowserver نشون می‌ده که هنوز بیش از ۳۹,۰۰۰ Instance آسیب‌پذیر توی اینترنت رها شدن. این یعنی فقر دانش زیرساختی در تیم‌هایی که ادعای اتوماسیون دارن.

باید قبول کنیم که مدیریت امنیت در زبان‌های داینامیک مثل Python و JS برای محیط‌های Multi-tenant کابوسه. اگر تیم شما تخصص مدیریت Task Runnerها و ایزوله‌سازی فرآیندها در سطح سیستم‌عامل رو نداره، همین الان دسترسی‌های n8n رو محدود کنید.

اتوماسیون بدون امنیت، فقط سرعت بخشیدن به نابودی سازمانتونه. اگه معمار زیرساخت سر پروژه نیست، n8n رو برای کارهای حساس لانچ نکنید.