هکرها به Ruby on Rails حمله کردند؛ یک آسیب‌پذیری می‌تواند فایل‌های حساس سرور را افشا کند

یک آسیب‌پذیری بحرانی در Ruby on Rails اکنون زیر حمله مهاجمان قرار گرفته است. این نقص که با نام KindaRails2Shell و شناسه CVE-2026-66066 شناخته می‌شود، در شرایط مشخص می‌تواند به مهاجم بدون نیاز به ورود به حساب کاربری اجازه دهد فایل‌های حساس روی سرور را بخواند و از اطلاعات به‌دست‌آمده برای حملات بعدی استفاده کند.

تصور کنید یک مهاجم فقط با فرستادن یک فایل ظاهراً تصویری بتواند به اطلاعاتی دست پیدا کند که قرار نبوده هیچ کاربر خارجی آن‌ها را ببیند.

این دقیقاً همان چیزی است که آسیب‌پذیری CVE-2026-66066 در شرایط آسیب‌پذیر ممکن می‌کند.

این نقص در مؤلفه Active Storage روبی آن ریلز قرار دارد و به نحوه پردازش فایل‌های تصویری با استفاده از libvips مربوط می‌شود. شدت آسیب‌پذیری Critical و امتیاز CVSS آن 9.5 از 10 است. مهم‌تر اینکه گزارش‌های جدید از آغاز بهره‌برداری واقعی از این آسیب‌پذیری خبر می‌دهند.

اما چرا یک مشکل در آپلود عکس می‌تواند به سرقت Secretهای سرور و حتی اجرای کد منجر شود؟

KindaRails2Shell چیست؟

KindaRails2Shell نامی است که برای آسیب‌پذیری CVE-2026-66066 در Ruby on Rails استفاده می‌شود.

این آسیب‌پذیری در Active Storage قرار دارد؛ بخشی از Rails که برای ذخیره و مدیریت فایل‌های آپلودشده در برنامه‌های وب استفاده می‌شود.

در شرایط آسیب‌پذیر، ترکیب این عوامل خطر را ایجاد می‌کند:

• برنامه از Active Storage استفاده کند؛
• پردازش تصاویر با libvips انجام شود؛
• برنامه فایل تصویری را از منبع غیرقابل اعتماد دریافت کند؛
• و مسیر مربوط به پردازش فایل در دسترس مهاجم باشد.

در چنین شرایطی، یک فایل دستکاری‌شده می‌تواند باعث شود پردازشگر تصویر به شکلی غیرمنتظره با فایل‌های موجود روی سرور تعامل کند. نتیجه می‌تواند Arbitrary File Read یا خواندن فایل‌های دلخواه قابل دسترسی برای فرآیند Rails باشد.

چرا این خبر برای کاربران عادی مهم است؟

ممکن است با دیدن عبارت‌هایی مثل:

Ruby on Rails
Active Storage
libvips
CVE

تصور کنید این موضوع فقط برای برنامه‌نویسان اهمیت دارد.

اما مسئله اصلی جای دیگری است.

Ruby on Rails یک Web Framework است؛ یعنی مجموعه‌ای از ابزارها که توسعه‌دهندگان برای ساخت وب‌سایت‌ها و سرویس‌های آنلاین از آن استفاده می‌کنند.

کاربر هنگام ورود به یک وب‌سایت معمولاً نمی‌داند پشت آن چه Framework یا کتابخانه‌ای قرار دارد.

اما اگر یک Framework محبوب آسیب‌پذیر باشد، مشکل می‌تواند روی تعداد زیادی از برنامه‌های اینترنتی اثر بگذارد.

به همین دلیل، یک آسیب‌پذیری در Framework می‌تواند برای کاربران نهایی نیز اهمیت داشته باشد؛ حتی اگر آن‌ها هرگز نام Rails را نشنیده باشند.

Web Framework چیست؟

برای ساده‌تر شدن موضوع، یک وب‌سایت را مانند یک ساختمان در نظر بگیرید.

کاربر فقط نمای ساختمان را می‌بیند؛ اما پشت این نما سیستم‌های مختلفی قرار دارند:

• سیستم ورود کاربران
• پایگاه داده
• مدیریت فایل
• پردازش درخواست‌ها
• احراز هویت
• Session
• API
• سرویس‌های ذخیره‌سازی

Framework بخشی از زیرساخت نرم‌افزاری این ساختمان است.

Ruby on Rails یکی از Frameworkهایی است که توسعه‌دهندگان از آن برای ساخت برنامه‌های وب استفاده می‌کنند.

بنابراین اگر یکی از اجزای مهم Framework آسیب‌پذیر شود، ممکن است مشکل فقط مربوط به یک صفحه یا یک قابلیت خاص نباشد؛ بلکه بخشی از زیرساخت برنامه را تحت تأثیر قرار دهد.

KindaRails2Shell چگونه کار می‌کند؟

لازم نیست برای فهمیدن خطر این آسیب‌پذیری وارد جزئیات قابل سوءاستفاده Exploit شویم.

مسیر کلی حمله را می‌توان این‌طور تصور کرد:

۱. مهاجم یک فایل دستکاری‌شده آماده می‌کند

فایل طوری طراحی می‌شود که در مسیر پردازش تصویر، رفتار متفاوتی از یک تصویر معمولی داشته باشد.

۲. فایل وارد برنامه می‌شود

اگر برنامه اجازه دریافت فایل از کاربران غیرقابل اعتماد را داشته باشد، مهاجم می‌تواند فایل خود را وارد مسیر پردازش Active Storage کند.

در مسیر حمله گزارش‌شده، احراز هویت کاربر برای شروع حمله الزام نیست.

۳. Active Storage فایل را پردازش می‌کند

Active Storage فایل را برای پردازش تصویر در اختیار ابزارهایی مانند libvips قرار می‌دهد.

مشکل زمانی ایجاد می‌شود که ورودی مهاجم بتواند پردازشگرهای ناامن برای محتوای غیرقابل اعتماد را فعال کند.

۴. فایل تصویری به مسیر خواندن اطلاعات تبدیل می‌شود

در زنجیره حمله، مهاجم می‌تواند کاری کند که پردازش فایل به جای صرفاً تولید یک تصویر، داده‌ای از فایل دیگری روی سرور را بخواند.

در نتیجه:

Image Upload

تبدیل می‌شود به:

Arbitrary File Read

Rapid7 نیز این آسیب‌پذیری را یک نقص unauthenticated arbitrary file read توصیف کرده که می‌تواند اطلاعات حساس برنامه را افشا کند.

چرا «خواندن فایل» می‌تواند به اندازه RCE خطرناک باشد؟

اینجا مهم‌ترین بخش داستان است.

اگر مهاجم فقط بتواند یک فایل بی‌اهمیت را بخواند، شاید آسیب محدود باشد.

اما یک سرور برنامه وب معمولاً فقط شامل فایل‌های عمومی نیست.

ممکن است Secretها و Credentialهایی وجود داشته باشند که برای ارتباط برنامه با سرویس‌های دیگر استفاده می‌شوند.

برای مثال:

• secret_key_base
• Rails Master Key
• اطلاعات اتصال به پایگاه داده
• Credentialهای Object Storage
• API Tokenها
• کلیدهای سرویس‌های خارجی

افشای این اطلاعات می‌تواند مرحله بعدی حمله را بسیار ساده‌تر کند.

بنابراین زنجیره خطر می‌تواند به شکل زیر باشد:

فایل مخرب

↓

پردازش ناامن

↓

خواندن فایل سرور

↓

افشای Secret

↓

دسترسی بیشتر

↓

احتمال اجرای کد یا حرکت جانبی

به همین دلیل است که یک آسیب‌پذیری File Read گاهی می‌تواند بسیار فراتر از «فقط خواندن یک فایل» باشد.


secret_key_base چیست و چرا مهاجم آن را می‌خواهد؟

secret_key_base یکی از Secretهای مهم برنامه‌های Rails است.

این مقدار در برخی سازوکارهای رمزنگاری و امضای Rails استفاده می‌شود.

اگر مهاجم بتواند چنین Secretی را به دست آورد، بسته به پیکربندی و زنجیره حمله، ممکن است بتواند به قابلیت‌هایی دست پیدا کند که نباید در اختیار او باشند.

در تحلیل‌های امنیتی منتشرشده درباره CVE-2026-66066، افشای Secretهای Rails به‌عنوان یکی از مراحل مهم برای رسیدن به حملات بعدی از جمله RCE مطرح شده است.

بنابراین یک قانون مهم امنیتی اینجا وجود دارد:

Secretهایی که روی سرور نگهداری می‌شوند، بخشی از سطح حمله هستند.

کدام نسخه‌های Ruby on Rails آسیب‌پذیر هستند؟

نسخه‌های اصلاح‌شده Active Storage شامل موارد زیر هستند:

اما یک نکته مهم وجود دارد:

فقط نگاه کردن به نسخه Rails کافی نیست.

باید بررسی شود که برنامه از Active Storage و libvips چگونه استفاده می‌کند و آیا فایل‌های غیرقابل اعتماد را وارد مسیر پردازش تصویر می‌کند یا خیر.

در برخی نسخه‌های قدیمی‌تر Rails نیز در صورت فعال بودن Vips شرایط آسیب‌پذیری وجود داشته است؛ بنابراین تیم‌های فنی نباید صرفاً بر اساس جدول بالا نتیجه‌گیری کنند.

چرا الان KindaRails2Shell مهم‌تر شده است؟

این آسیب‌پذیری در پایان ژوئیه وصله شد و پس از آن جزئیات فنی و ابزارهای تحقیقاتی بیشتری درباره آن منتشر شد.

VulnCheck در اوایل اوت از شناسایی بیش از ۷ هزار نمونه Ruby on Rails در معرض خطر خبر داده بود.

اما اتفاق مهم‌تر در روزهای اخیر رخ داده است.

گزارش SecurityWeek در ۳۱ اوت ۲۰۲۶ اعلام کرد که مهاجمان بهره‌برداری از CVE-2026-66066 را آغاز کرده‌اند. CyberWire نیز این موضوع را در گزارش روزانه خود به‌عنوان یکی از مهم‌ترین اخبار امنیتی روز قرار داده است.

یعنی این آسیب‌پذیری دیگر فقط یک هشدار تئوری نیست.

فاصله میان انتشار Patch و شروع بهره‌برداری واقعی، حدود یک ماه بوده است.

این اتفاق یک درس مهم برای تیم‌های امنیتی دارد:

وقتی جزئیات یک آسیب‌پذیری بحرانی منتشر می‌شود، مهاجمان نیز شروع به بررسی همان مسیر می‌کنند.

آیا نصب Patch کافی است؟

اگر برنامه آسیب‌پذیر است، اولین اقدام قطعاً نصب نسخه اصلاح‌شده است.

اما یک تفاوت مهم وجود دارد.

فرض کنید یک سرور شما از اول مرداد تا ۱۰ شهریور آسیب‌پذیر بوده و امروز آن را Patch می‌کنید.

Patch باعث می‌شود:

حمله بعدی سخت‌تر یا غیرممکن شود.

اما نمی‌تواند به شما بگوید:

آیا مهاجم هفته گذشته قبلاً وارد شده است یا نه؟

به همین دلیل اگر سرویس قبل از Patch در معرض اینترنت بوده، باید احتمال سوءاستفاده قبلی نیز بررسی شود.

پروژه Rails حتی ابزارهای Forensics اختصاصی برای همین CVE منتشر کرده است تا تیم‌ها بتوانند بررسی کنند آیا برنامه آسیب‌پذیر بوده و آیا شواهدی از سوءاستفاده وجود دارد یا خیر.

اگر قبلاً Patch نکرده‌ایم، چه کار کنیم؟

برای تیم‌های فنی، ترتیب اقدامات می‌تواند این باشد:

۱. نسخه Rails و Active Storage را بررسی کنید

مشخص کنید برنامه دقیقاً از چه نسخه‌ای استفاده می‌کند.

۲. وضعیت libvips را بررسی کنید

بررسی کنید آیا پردازش تصویر با Vips انجام می‌شود و نسخه آن چیست.

Rapid7 توصیه کرده است علاوه بر نسخه اصلاح‌شده Active Storage، محیط libvips نیز به‌درستی بررسی و به نسخه مناسب به‌روزرسانی شود.

۳. مسیرهای آپلود را شناسایی کنید

بررسی کنید آیا کاربران ناشناس یا منابع غیرقابل اعتماد می‌توانند فایل وارد برنامه کنند.

۴. Patch کنید

به نسخه اصلاح‌شده ارتقا دهید.

۵. لاگ‌ها و شواهد را بررسی کنید

اگر سرور پیش از Patch در معرض حمله بوده است، بررسی کنید آیا نشانه‌ای از آپلود یا پردازش غیرعادی فایل وجود دارد.

۶. Secretها را بررسی و در صورت نیاز Rotate کنید

اگر احتمال می‌دهید Secretهای برنامه در معرض افشا قرار گرفته‌اند، صرفاً Patch کردن کافی نیست.

secret_key_base و سایر Credentialهایی که فرآیند Rails به آن‌ها دسترسی داشته است باید طبق فرآیند Incident Response سازمان بررسی و در صورت نیاز تعویض شوند.

آیا کاربران عادی باید کاری انجام دهند؟

اگر شما کاربر یک وب‌سایت معمولی هستید، این آسیب‌پذیری معمولاً چیزی نیست که بتوانید مستقیماً روی گوشی یا کامپیوتر خودتان Patch کنید.

مسئولیت اصلی متوجه مالک یا مدیر سرویس آسیب‌پذیر است.

اما این اتفاق یک نکته مهم را برای همه کاربران اینترنت روشن می‌کند:

وقتی اطلاعات خود را در یک وب‌سایت وارد می‌کنید، امنیت شما فقط به رمز عبور خودتان وابسته نیست.

امنیت شما به امنیت زیرساخت همان سرویس نیز وابسته است.

به همین دلیل، مواردی مانند:

• انتخاب سرویس‌های معتبر؛
• استفاده از MFA؛
• استفاده نکردن از یک رمز عبور در چند سرویس؛
• و توجه به هشدارهای امنیتی

همچنان اهمیت دارند.

KindaRails2Shell چه درس امنیتی مهمی دارد؟

این آسیب‌پذیری فقط یک مشکل Ruby on Rails نیست.

KindaRails2Shell یک نمونه بسیار خوب از زنجیره حمله در نرم‌افزارهای مدرن است.

در اینجا چند فناوری مختلف کنار یکدیگر قرار گرفته‌اند:

Web Framework
↓
File Upload
↓
Image Processing
↓
Third-Party Library
↓
Application Secrets

و یک ضعف در تعامل میان این اجزا می‌تواند مسیر حمله‌ای بسیار جدی ایجاد کند.

این موضوع اهمیت Dependency Management را هم نشان می‌دهد.

یک برنامه ممکن است از ده‌ها یا صدها کتابخانه استفاده کند. توسعه‌دهنده شاید مستقیماً با بسیاری از آن‌ها کار نکند، اما آسیب‌پذیری در یکی از Dependencyها می‌تواند امنیت کل برنامه را تحت تأثیر قرار دهد.

چرا «Patch Management» به‌تنهایی کافی نیست؟

یک اشتباه رایج این است که تیم امنیتی آسیب‌پذیری را پیدا کند، Patch را نصب کند و پرونده را ببندد.

اما در آسیب‌پذیری‌های بحرانی باید سه سؤال جداگانه پرسید:

آیا آسیب‌پذیر بودیم؟

Exposure Assessment

آیا مورد حمله قرار گرفتیم؟

Threat Hunting / Forensics

آیا چیزی افشا شده است؟

Compromise Assessment

این سه سؤال با یکدیگر تفاوت دارند.

Patch کردن پاسخ سؤال اول را تغییر می‌دهد، اما لزوماً پاسخ دو سؤال بعدی را نمی‌دهد.

و این شاید مهم‌ترین درس KindaRails2Shell باشد.

جمع‌بندی؛ هکرها چرا سراغ Rails رفتند؟

CVE-2026-66066 یا KindaRails2Shell نشان می‌دهد یک آسیب‌پذیری در بخش ظاهراً ساده‌ای مانند پردازش فایل‌های تصویری می‌تواند به یک مشکل امنیتی بسیار جدی تبدیل شود.

در شرایط آسیب‌پذیر، مهاجم می‌تواند بدون احراز هویت یک فایل دستکاری‌شده را وارد مسیر پردازش کند و به فایل‌هایی دسترسی پیدا کند که فرآیند Rails قادر به خواندن آن‌هاست. این فایل‌ها ممکن است حاوی Secretها و Credentialهای مهم باشند و افشای آن‌ها می‌تواند مسیر را برای حملات بعدی از جمله RCE و حرکت جانبی باز کند.

اکنون که گزارش‌ها از بهره‌برداری واقعی خبر می‌دهند، سازمان‌هایی که از Rails استفاده می‌کنند نباید این آسیب‌پذیری را صرفاً یک CVE دیگر در فهرست Patchهای آینده ببینند.

نسخه آسیب‌پذیر را شناسایی کنید، Patch کنید، وضعیت libvips را بررسی کنید و اگر سرویس پیش از Patch در معرض اینترنت بوده است، احتمال نفوذ قبلی و افشای Secretها را نیز بررسی کنید.

چون سؤال اصلی دیگر فقط این نیست:

«آیا Rails را به‌روزرسانی کرده‌ایم؟»

بلکه باید پرسید:

«آیا مهاجم قبل از به‌روزرسانی فرصتی برای ورود داشته است؟»

پرسش‌های متداول

KindaRails2Shell چیست؟

KindaRails2Shell نام آسیب‌پذیری CVE-2026-66066 در Ruby on Rails است که در Active Storage و مسیر پردازش تصویر با libvips قرار دارد و می‌تواند در شرایط مشخص باعث خواندن فایل‌های حساس و در ادامه اجرای کد شود.

آیا KindaRails2Shell بدون ورود به حساب کاربری قابل سوءاستفاده است؟

بله. در مسیر حمله گزارش‌شده، مهاجم می‌تواند بدون احراز هویت از مسیر آپلود فایل به آسیب‌پذیری دسترسی پیدا کند.

آیا این آسیب‌پذیری فقط باعث خواندن فایل می‌شود؟

خیر. Arbitrary File Read می‌تواند باعث افشای Secretهایی شود که در ادامه امکان حملات شدیدتر، از جمله RCE، را فراهم می‌کنند.

CVE-2026-66066 چه امتیازی دارد؟

این آسیب‌پذیری در CVSS 4.0 امتیاز 9.5 از 10 و سطح Critical دارد.

نسخه‌های اصلاح‌شده Rails کدام‌اند؟

نسخه‌های اصلاح‌شده شامل 7.2.3.2، 8.0.5.1 و 8.1.3.1 هستند. وضعیت Active Storage و libvips نیز باید جداگانه بررسی شود.

Ruby on Rails وصله شد؛ نسخه‌های امن برای رفع KindaRails2Shell در ادامه حتما بخوانید

آیا بعد از Patch باید Secretها را تغییر داد؟

اگر احتمال می‌رود مهاجم پیش از Patch به Secretهای برنامه دسترسی پیدا کرده باشد، بله؛ باید طبق فرآیند Incident Response سازمان، secret_key_base و سایر Credentialهای در معرض خطر بررسی و در صورت نیاز Rotate شوند.

منابع :

• منبع اصلی آسیب‌پذیری و نسخه‌های Patch‌شده — Ruby on Rails
  Ruby on Rails – CVE-2026-66066
• منبع بهره‌برداری فعال — SecurityWeek
  SecurityWeek – Critical Ruby on Rails Vulnerability in Attackers’ Crosshairs