حمله سایبری Railway: کلیدهای هوش مصنوعی از کجا لو رفت و حالا چه کنیم؟

فرض کنید آخرِ هفته با کمکِ یک دستیارِ هوش مصنوعی یک ربات یا اپِ کوچک ساخته‌اید. کلیدِ API سرویسِ هوش مصنوعی را هم گذاشته‌اید در تنظیماتِ پلتفرمِ میزبانی تا برنامه کار کند. حالا خبر می‌رسد که همان پلتفرم هک شده است. طبقِ گزارشِ اولیهٔ پلتفرم، مهاجم به حسابِ کاربری‌ها دسترسی پیدا نکرده، ولی کلیدِ داخلِ تنظیمات شاید دیگر فقط مالِ شما نباشد. این دقیقاً همان چیزی است که در حمله سایبری Railway در اکتبر ۲۰۲۶ رخ داد. TechCrunch این شرکت را پلتفرمِ «وایب‌کدینگ» می‌نامد؛ یعنی جایی که خیلی‌ها برنامه‌هایی را که با کمکِ هوش مصنوعی نوشته‌اند رویش اجرا می‌کنند. در این نوشته توضیح می‌دهیم چه چیزی لو رفت، چرا یک موجِ کامل از پلتفرم‌ها هدف گرفته شده و اگر پروژه‌ای روی این سرویس‌ها دارید، چه کارهایی باید در فهرستِ کارهایتان باشد.

در یک نگاه

Railway در ۲۱ اکتبر ۲۰۲۶ اعلام کرد مهاجمی از راهِ زیرساختِ ساخت و اعتبارنامه‌های CI به متغیرهای محیطیِ رمزشدهٔ کاربران رسیده و بخشی از آن‌ها را رمزگشایی کرده است. طبقِ گزارشِ اولیه، مهاجم به حسابِ کاربری‌ها دسترسی پیدا نکرده است. Railway از کاربرانِ پیش از ۲۱ اکتبر خواسته همهٔ کلیدها و رمزها را عوض کنند و لاگِ سرویس‌ها را بررسی کنند.

• طبقِ گزارشِ اولیهٔ Railway، مهاجم در اکتبر ۲۰۲۶ به حسابِ کاربران دسترسی پیدا نکرد و از راهِ زیرساختِ ساخت و اعتبارنامه‌های CI به متغیرهای محیطی رسید.
• گزارشِ اولیهٔ Railway نشان می‌دهد هدفِ حمله به دست آوردنِ کلیدهای API سرویس‌دهندگانِ هوش مصنوعی برای «حملهٔ تقطیر» بوده است.
• GitGuardian توصیه می‌کند همهٔ متغیرهای محیطیِ ذخیره‌شده روی Railway لورفته فرض شوند.
• یک هفته پیش‌تر، در ۱۴ و ۱۵ اکتبر ۲۰۲۶، پلتفرمِ Zeabur هم نفوذی مشابه داشت که حدودِ ۳٫۲ میلیون رکوردِ متغیرِ محیطی را در معرض گذاشت.
• Railway قابلیتی به نامِ sealed variables دارد که مقدارِ متغیر را نه در رابطِ کاربری نشان می‌دهد و نه از راهِ API برمی‌گرداند.

در حمله سایبری Railway دقیقاً چه اتفاقی افتاد؟

به گفتهٔ خودِ Railway، مهاجمی ناشناس به متغیرهای محیطیِ رمزشدهٔ کاربران دسترسی پیدا کرد و محتوای بخشی از آن‌ها را هم رمزگشایی کرد. شرکت این حادثه را چهارشنبه ۲۱ اکتبر ۲۰۲۶ علنی کرد و روزِ بعد از همهٔ کاربران خواست کلیدهای API و کلیدهای سرویس‌های ابری‌شان را باطل کنند و کلیدِ تازه بسازند.

نکتهٔ مهمِ این ماجرا مسیرِ حمله است. مهاجم از درِ ورودِ کاربران وارد نشد. Railway در گزارشِ اولیه‌اش صراحتاً می‌گوید در این حادثه به حسابِ کاربری‌ها دسترسی پیدا نشده است. راهِ نفوذ از پشتِ صحنه بود: زیرساختِ ساخت (بخشی که کدِ شما را می‌گیرد و آن را به برنامهٔ قابلِ اجرا تبدیل می‌کند) و CI (سامانهٔ خودکاری که کد را می‌سازد، می‌آزماید و منتشر می‌کند).

طبقِ گزارشِ اولیهٔ Railway، شرکت ساعتِ ۱۹:۵۳ به وقتِ UTC در ۲۰ اکتبر متوجهِ یک کارزارِ پیوسته و هدفمند علیهِ سرویس‌هایش شد. جدولِ زیر زمان‌بندیِ حمله را همان‌طور که در گزارش آمده نشان می‌دهد. ساعت‌ها به منطقهٔ زمانیِ اعلام‌شده در خودِ گزارش است.

در واکنش، Railway زیرساختِ ساختش را خاموش کرد و طبقِ گزارش‌ها استقرارِ برنامه‌ها را هم تا پایانِ بررسی متوقف کرد. پس اگر آن روزها نمی‌توانستید نسخهٔ تازهٔ برنامه‌تان را بالا بیاورید، دلیلش همین بود.

• زمان: ۲۰ اکتبر، ۱۴:۰۳ تا ۱۶:۵۱ · چه شد: احتمالِ افزایشِ سطحِ دسترسی در زیرساختِ ساخت شناسایی شد
• زمان: ۲۰ اکتبر، ۱۹:۵۳ (UTC) · چه شد: Railway متوجهِ کارزارِ پیوسته و هدفمند علیهِ سرویس‌هایش شد
• زمان: ۲۱ اکتبر، ۰۵:۲۷ تا ۰۷:۲۵ · چه شد: مهاجم اعتبارنامه‌های CI را به دست آورد و فایل‌هایی را رمزگشایی کرد که دسترسیِ API بیشتری باز می‌کرد
• زمان: ۲۱ اکتبر، ۰۷:۲۵ تا ۰۹:۱۸ · چه شد: لاگِ پایگاه‌داده پرس‌وجوهای غیرمجاز روی متغیرهای محیطی را نشان می‌دهد؛ بخشی از آن‌ها رمزگشایی شد
• زمان: ۲۱ اکتبر · چه شد: اعلامِ عمومیِ حادثه؛ خاموشیِ زیرساختِ ساخت و توقفِ استقرارها

متغیرِ محیطی چیست و چرا لو رفتنش این‌قدر جدی است؟

متغیرِ محیطی همان صندوقچه‌ای است که رمزهای برنامه‌تان را در آن می‌گذارید تا داخلِ خودِ کد نوشته نشوند. در Railway این صندوقچه می‌تواند کلیدهای API، رمزِ پایگاه‌داده و اطلاعاتِ ورود به مخزن‌های خصوصیِ نرم‌افزار را در خود نگه دارد.

پس وقتی می‌گوییم «متغیرهای محیطی لو رفت»، یعنی احتمالاً همهٔ کلیدهایی که برنامه‌تان برای حرف زدن با دنیای بیرون لازم داشت در معرضِ دید قرار گرفته است. کلیدِ سرویسِ هوش مصنوعی، کلیدِ درگاهِ پرداخت، رمزِ پایگاه‌دادهٔ مشتریان؛ همه در یک‌جا.

Railway گفته فقط «بخشی» از متغیرها رمزگشایی شده‌اند. ولی شرکتِ امنیتیِ GitGuardian در تحلیلش توصیه می‌کند همهٔ متغیرهای محیطیِ ذخیره‌شده روی Railway را لورفته فرض کنید. منطقش ساده است: وقتی نمی‌دانید کلیدِ شما جزوِ آن «بخش» بوده یا نه، امن‌ترین فرض این است که بوده.

چرا مهاجم دنبالِ کلیدهای API هوش مصنوعی بود؟

یافته‌های اولیهٔ Railway نشان می‌دهد هدفِ اصلی کلیدهای API سرویس‌دهندگانِ هوش مصنوعی بوده تا با آن‌ها «حملهٔ تقطیر» انجام شود. تقطیر به زبانِ ساده یعنی کسی با فرستادنِ تعدادِ زیادی پرسش به یک مدلِ هوش مصنوعی و جمع کردنِ پاسخ‌ها، مدلِ دیگری را آموزش بدهد. Railway جزئیاتِ بیشتری از نحوهٔ استفادهٔ مهاجم از کلیدها منتشر نکرده است.

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

Railway برای محدود کردنِ آسیب از چند شرکت خواست کلیدهای احتمالاً لورفته را پیشاپیش باطل کنند. فهرستی که TechCrunch نقل کرده شاملِ GitHub، GitLab، Anthropic، OpenAI، OpenRouter، SpaceXSI و Stripe و چند شرکتِ دیگر است. این یعنی ممکن است برخی کلیدهایتان همین حالا هم از کار افتاده باشند و برنامه‌تان خطا بدهد. این خطا نشانهٔ آن است که باید کلیدِ تازه بسازید.

آیا فقط Railway هدف بود؟ ماجرای Zeabur

نه. Railway خودش می‌گوید این حادثه بخشی از یک سلسله حملهٔ تازه به شرکت‌های پلتفرمی است که هدفشان رسیدن به سرویس‌دهندگانِ هوش مصنوعی است. نمونهٔ نزدیکش Zeabur است که حدودِ یک هفته زودتر هدف قرار گرفت.

طبقِ گزارشِ خودِ Zeabur، در ۱۴ و ۱۵ اکتبر ۲۰۲۶ مهاجمی با اعتبارنامه‌های داخلیِ لورفتهٔ این شرکت وارد کلاسترِ مشترک (مجموعه‌ای از سرورها که برنامه‌های چند کاربر روی آن اجرا می‌شود)، برخی سرورهای اختصاصی و سامانه‌های داخلی شد و پایگاه‌دادهٔ پلتفرم را خواند. نتیجه در معرض قرار گرفتنِ حدودِ ۳٫۲ میلیون رکوردِ متغیرِ محیطی و اطلاعاتِ ۳۲۱٬۸۱۰ حساب در کلاسترهای مشترکِ ۹ منطقه بود.

BleepingComputer گزارش داده که Zeabur پس از دومین نفوذ در دو ماه در حالِ تعطیل شدن است. جدولِ زیر دو حادثه را کنارِ هم می‌گذارد. این مقایسه دربارهٔ برتریِ یک سرویس نیست؛ فقط نشان می‌دهد الگوی حمله چقدر شبیه است.

• : زمانِ حمله · Railway: ۲۰ و ۲۱ اکتبر ۲۰۲۶ · Zeabur: ۱۴ و ۱۵ اکتبر ۲۰۲۶
• : راهِ نفوذ · Railway: زیرساختِ ساخت و اعتبارنامه‌های CI · Zeabur: اعتبارنامه‌های داخلیِ لورفته
• : چه در معرض قرار گرفت · Railway: متغیرهای محیطیِ رمزشده؛ بخشی رمزگشایی شد · Zeabur: حدودِ ۳٫۲ میلیون رکوردِ متغیرِ محیطی و اطلاعاتِ ۳۲۱٬۸۱۰ حساب
• : حسابِ کاربران · Railway: به گفتهٔ Railway دسترسی پیدا نشد · Zeabur: اطلاعاتِ حساب‌ها در معرض قرار گرفت
• : وضعیتِ بعدی · Railway: خاموشیِ زیرساختِ ساخت و توقفِ استقرارها در زمانِ بررسی · Zeabur: طبقِ BleepingComputer، در حالِ تعطیلی

اگر روی Railway پروژه دارم، حالا چه کار کنم؟

کوتاه‌ترین پاسخ: همهٔ رمزها و کلیدهایی را که روی Railway گذاشته بودید عوض کنید و لاگِ سرویس‌های مربوط را بررسی کنید. Railway توصیه می‌کند هر کسی که پیش از ۲۱ اکتبر ثبت‌نام کرده، اعتبارنامه‌هایش را عوض کند.

فهرستِ زیر چارچوبی است برای اینکه چیزی از قلم نیفتد. جزئیاتِ اجرایی، مثلاً ترتیبِ عوض کردنِ کلیدها بی‌آنکه سرویسِ زنده از کار بیفتد، به ساختارِ پروژهٔ شما و به هر سرویس بستگی دارد. اگر پروژه‌تان دادهٔ مشتری یا پرداخت دارد، این کار را با یک متخصصِ امنیتِ دارای صلاحیت انجام دهید.

یک نکته دربارهٔ آینده: Railway قابلیتی به نامِ sealed variables یا «متغیرهای مُهرشده» دارد. این متغیرها فقط‌نوشتنی‌اند؛ یعنی مقدارشان موقعِ ساخت و استقرار به برنامه تزریق می‌شود، ولی نه در رابطِ کاربری نمایش داده می‌شود و نه API آن را برمی‌گرداند. این قابلیت جلوی هر نوع حمله را نمی‌گیرد، اما راه‌های خواندنِ دوبارهٔ رمز را کم می‌کند. اینکه برای پروژهٔ شما مناسب است یا نه، تصمیمی است که بهتر است با متخصص بگیرید.

• فهرست بگیرید: همهٔ متغیرهای محیطیِ پروژه‌هایتان روی Railway را یادداشت کنید؛ کلیدهای API، رمزِ پایگاه‌داده، اطلاعاتِ مخزن‌های خصوصی.
• همه را لورفته فرض کنید: حتی کلیدهایی که فکر می‌کنید کم‌اهمیت‌اند. GitGuardian همین را توصیه می‌کند.
• کلیدها را عوض کنید، با برنامه: هدف این است که کلیدِ قدیمی در خودِ سرویسِ صادرکننده باطل شود، نه فقط از Railway پاک شود. برای اینکه برنامهٔ زنده قطع نشود، معمولاً اول کلیدِ تازه ساخته، جایگزین و آزمایش می‌شود و بعد کلیدِ قدیمی باطل می‌شود؛ چون کلیدِ قدیمی احتمالاً لو رفته، این فاصله باید تا جای ممکن کوتاه باشد. ترتیبِ دقیق در هر سرویس فرق دارد و تصمیمش با متخصص است. اگر سرویسی مثلِ OpenAI یا Stripe کلیدتان را پیشاپیش باطل کرده، فقط کلیدِ جدید لازم دارید.
• لاگ‌ها را بررسی کنید: در لاگِ هر سرویس دنبالِ فعالیتِ غیرعادی باشید؛ ورود از جای ناآشنا، درخواست‌های زیاد یا ساعت‌های عجیب.
• گزارشِ مصرف و صورت‌حسابِ سرویس‌های هوش مصنوعی را نگاه کنید: چون هدفِ این حمله کلیدهای هوش مصنوعی بوده، جهشِ ناگهانیِ مصرف می‌تواند نشانهٔ سوءاستفاده باشد.
• برای آینده، متغیرهای حساس را مُهرشده نگه دارید و دربارهٔ آن با متخصص مشورت کنید.

این ماجرا برای کسانی که با ابزارهای هوش مصنوعی می‌سازند چه درسی دارد؟

درسِ اول این است که امنیتِ حسابِ شما همهٔ داستان نیست. می‌توانید رمزِ قوی و ورودِ دومرحله‌ای داشته باشید و هیچ ایمیلِ فیشینگی را هم باز نکنید، ولی کلیدتان باز هم از سمتِ پلتفرم لو برود. در ماجرای Railway دقیقاً همین شد: طبقِ گزارشِ اولیه، مهاجم به حسابِ کاربران دسترسی پیدا نکرد، اما رمزهای داخلِ پروژه‌ها در معرض قرار گرفت.

این به آن معنا نیست که رمزِ قوی و ورودِ دومرحله‌ای بی‌فایده‌اند. آن‌ها هنوز پایهٔ امنیتِ هر حسابی هستند و بررسیِ امنیتِ حسابتان همچنان کارِ درستی است. فقط باید بدانید که کلیدهای API لایهٔ جداگانه‌ای‌اند و مراقبتِ جداگانه می‌خواهند.

درسِ دوم دربارهٔ ارزشِ کلیدهای هوش مصنوعی است. وقتی دو پلتفرم در یک هفته با الگوی مشابه هدف می‌گیرند و Railway صراحتاً از یک موجِ حمله برای رسیدن به سرویس‌دهندگانِ هوش مصنوعی حرف می‌زند، معلوم است این کلیدها به هدفِ جذابی تبدیل شده‌اند. اگر پروژه‌های کوچکِ آزمایشی دارید، کلیدی را که دیگر لازم ندارید باطل کنید؛ کلیدِ فراموش‌شده هم کلید است.

درسِ سوم دربارهٔ انتخابِ پلتفرم است. ماجرای Zeabur نشان می‌دهد یک پلتفرم ممکن است حتی بسته شود. پس برای هر پروژه‌ای که برایتان مهم است، بدانید کلیدها و داده‌هایتان کجاست و اگر لازم شد بتوانید سریع جابه‌جایشان کنید.

پرسش‌های پرتکرار

حسابِ کاربری‌ام در Railway هک شده است؟

طبقِ گزارشِ اولیهٔ Railway، در این حادثه مهاجم به حسابِ کاربری‌ها دسترسی پیدا نکرده است. چیزی که در معرض قرار گرفت متغیرهای محیطی بود؛ یعنی کلیدها و رمزهایی که داخلِ پروژه‌ها گذاشته بودید. با این حال، داشتنِ رمزِ قوی و ورودِ دومرحله‌ای همیشه لازم است.

اگر بعد از ۲۱ اکتبر ثبت‌نام کرده باشم هم باید کلیدهایم را عوض کنم؟

توصیهٔ گزارشِ اولیهٔ Railway برای همهٔ کسانی است که پیش از ۲۱ اکتبر ۲۰۲۶ ثبت‌نام کرده‌اند. اگر بعد از آن آمده‌اید و تردید دارید، با پشتیبانیِ Railway یا یک متخصصِ امنیت مشورت کنید.

برنامه‌ام ناگهان خطای کلیدِ نامعتبر می‌دهد. چرا؟

Railway از شرکت‌هایی مثلِ OpenAI، Anthropic، GitHub و Stripe خواسته کلیدهای احتمالاً لورفته را پیشاپیش باطل کنند. احتمال دارد کلیدِ شما هم باطل شده باشد و باید کلیدِ تازه بسازید.

متغیرهای مُهرشده (sealed variables) چه فرقی با متغیرِ معمولی دارند؟

مقدارِ متغیرِ مُهرشده موقعِ ساخت و استقرار به برنامه می‌رسد، اما نه در رابطِ کاربری نشان داده می‌شود و نه API آن را برمی‌گرداند. یعنی بعد از ذخیره دیگر از این راه‌ها قابلِ خواندن نیست.

روی Zeabur پروژه داشتم. چه باید بکنم؟

طبقِ گزارشِ خودِ Zeabur، در نفوذِ ۱۴ و ۱۵ اکتبر ۲۰۲۶ حدودِ ۳٫۲ میلیون رکوردِ متغیرِ محیطی و اطلاعاتِ ۳۲۱٬۸۱۰ حساب در معرض قرار گرفت و طبقِ BleepingComputer این سرویس در حالِ تعطیلی است. اینکه کلیدهای پروژهٔ شما جزوِ آن رکوردها بوده یا نه از این گزارش‌ها معلوم نیست؛ اطلاعیهٔ خودِ Zeabur را دنبال کنید و برای ارزیابیِ کلیدها و جابه‌جاییِ پروژه از متخصص کمک بگیرید.

جمع‌بندی

حمله سایبری Railway یادآوری می‌کند که خطر همیشه از درِ ورودِ شما نمی‌آید. گاهی از پشتِ صحنهٔ پلتفرمی می‌آید که به آن اعتماد کرده‌اید. اگر روی Railway پروژه دارید، همان‌طور که GitGuardian توصیه می‌کند فرض را بر لو رفتنِ همهٔ متغیرهای محیطی بگذارید، کلیدها را عوض کنید و لاگ‌ها و مصرفِ سرویس‌های هوش مصنوعی را زیرِ نظر بگیرید. اگر روی Zeabur پروژه داشتید، با توجه به افشای حدودِ ۳٫۲ میلیون رکوردِ متغیرِ محیطی در آنجا، اطلاعیهٔ خودِ Zeabur را بخوانید و وضعیتِ کلیدهایتان را با متخصص بسنجید. برای پروژه‌هایی که دادهٔ مشتری یا پرداخت دارند، تصمیم و اجرا را به متخصصِ امنیتِ دارای صلاحیت بسپارید. Railway هنوز گزارشِ نهایی منتشر نکرده و ممکن است جزئیاتِ تازه‌ای در راه باشد.