‏TanStack چطور بعد از حمله به npm خودش رو سخت‌تر کرد

این هفته ۴۲ پکیج از خانواده TanStack Router/Start با نسخه‌های آلوده به بدافزار روی npm منتشر شدن. این نسخه‌ها حدود ۲۰ تا ۲۶ دقیقه در دسترس بودن تا اینکه deprecate و حذف شدن. تیم TanStack بعد از یک بررسی سه‌روزه کامل، وضعیت همه چیز امنه رو اعلام کرده — تمام نسخه‌های فعلاً موجود همه پکیج‌ها، از جمله Router و Start، برای نصب امن هستن.

جالب اینجاست که مهاجم نه رمز عبور کسی رو دزدید، نه فیشینگ انجام داد. TanStack از سیستم OIDC برای انتشار استفاده می‌کنه؛ یعنی هیچ توکن بلندمدت npm‌ای وجود نداشت که بشه دزدیدش. توکن انتشار فقط در لحظه‌ای که CI داره release می‌کنه ساخته می‌شه و بلافاصله منقضی می‌شه. مهاجم یه PR از یه fork جعلی باز کرد که workflow مربوط به pull_request_target رو فعال کرد — این event در context مخزن اصلی اجرا می‌شه، نه fork — و از این طریق توانست کش مشترک CI رو مسموم کنه. بعداً وقتی یه PR کاملاً قانونی merge شد و release pipeline اجرا شد، همون کش مسموم بازیابی شد و توکن انتشار رو از حافظه runner دزدید.

تیم TanStack صادقانه اعتراف می‌کنه که الگوی pull_request_target + دسترسی به کش بیش از سه سال پیش توسط تیم امنیتی GitHub مستند شده بود به عنوان یه الگوی خطرناک. این اطلاعات وجود داشت، اما تیم ربطش به workflow خودشون رو نداده بود. به قول خودشون: «workflow هایی که می‌نویسیم با اعتبارنامه‌های ما اجرا می‌شن، پس باید مثل مهم‌ترین کد مخزن باهاشون رفتار بشه.»

اقداماتی که تا الان انجام شده شامل اینا می‌شه:

• غیرفعال کردن کش pnpm در pipeline انتشار
• پین کردن تمام actionها به commit SHA به جای تگ نسخه
• حذف کامل pull_request_target از همه workflow های CI
• اجباری کردن ۲FA غیر SMS در npm و GitHub
• ارتقا به pnpm 11 برای بهره‌مندی از رفتار install-cooldown اکوسیستم

اقدامات بعدی در دست بررسی هستن. یکیشون اضافه کردن zizmor — یه static analyser برای GitHub Actions — به عنوان یه چک اجباری در هر PR هست که می‌تونست همین الگو رو پیش از وقوع حادثه شناسایی کنه. همچنین قراره CODEOWNERS روی پوشه .github اعمال بشه تا فقط maintainerهای اصلی بتونن workflow ها رو تغییر بدن.

یه سوال هنوز باز مونده: آیا TanStack باید دسترسی external contributorها برای باز کردن PR رو محدود کنه؟ تیم صراحتاً می‌گه هنوز تصمیم نگرفته و احساس پیچیده‌ای داره، چون خیلی از maintainerهای فعلی خودشون از همین مسیر «کاربر با یه fix» به پروژه وارد شدن. اگه چنین تغییری بیاد، با یه پست جداگانه و توضیح کامل نحوه مشارکت جدید همراه خواهد بود.

نکات کلیدی:

• ۴۲ پکیج Router/Start آلوده شدن، بقیه پکیج‌های TanStack (Query، DB، Table و...) سالم بودن
• حمله از طریق مسموم‌کردن کش GitHub Actions بود، نه سرقت توکن مستقیم
• رویکرد OIDC (بدون توکن بلندمدت) یه مزیت بود ولی به تنهایی کافی نبود
• الگوی pull_request_target + دسترسی کش = آسیب‌پذیری شناخته‌شده‌ای که باید از workflow ها حذف بشه
• تمام نسخه‌های فعلاً موجود همه پکیج‌های TanStack امن هستن