---
title: وقتی اعتماد به زنجیره‌ی تامین می‌شکند؛ ماجرای آلودگی ۳۲ بسته npm رِدهَت
date: 2026-06-02T17:00:00Z
modified: 2026-06-03T10:03:43Z
permalink: "https://nooshdaroo.ir/safe-ecommerce-selling/reredhat-npm-packages-compromised/"
type: post
status: publish
excerpt: ""
wpid: 12320
categories:
  - کسب‌وکار آنلاین
  - خبر و تحلیل
tags:
  - top-section-overwrite
  - امنیت سایبری
author:
  - Hooshyar
  - ZiaeiShayan
featured_image: "https://nooshdaroo.ir/wp-content/uploads/2026/06/ChatGPT-Image-Jun-2-2026-04_19_55-PM.webp"
featured_image_alt: تصویرسازی زنجیری که حلقه میانی آن با شمایل فردی دارای کلاه قرمز در حال شکستن است و مفهوم نفوذ به زنجیره تأمین و آلودگی بسته‌های ردهت را نشان می‌دهد
---

تصور کنید صبح روز شنبه است. لپ‌تاپ را باز می‌کنید و برای شروع پروژه جدیدتان، دستور ساده و همیشگی npm install را در ترمینال می‌نویسید. همه‌چیز عادی به نظر می‌رسد؛ نوار پیشرفت نصب پر می‌شود و آماده‌ی کدنویسی هستید. اما در همان چند ثانیه، بدون آنکه حتی یک خط از برنامه شما اجرا شود، ممکن است بخش بزرگی از رمزهای عبور، کلیدهای دسترسی به فضای ابری و اطلاعات هویتی شما برای یک مهاجم در آن‌سوی دنیا ارسال شده باشد!

این یک سناریوی فرضی نیست! اتفاقیست که در روز ۱۱ خرداد ۱۴۰۵ برای ده‌ها هزار توسعه‌دهنده در سراسر دنیا رخ داد. در این روز، ۳۲ بسته نرم‌افزاری رسمی متعلق به شرکت ردهت (Red Hat) به [بدافزار](http://nooshdaroo.ir/cybersecurity-basics/malware-explained/) بدنام «مینی شای‌هولود/میاسما» (Mini Shai-Hulud/Miasma) آلوده شدند. ابعاد این نفوذ زمانی نگران‌کننده‌تر می‌شود که بدانیم این ۳۲ بسته در مجموع ده‌ها هزار دانلود هفتگی دارند.

اما این نفوذ چگونه از سدهای امنیتی یکی از معتبرترین شرکت‌های متن‌باز دنیا عبور کرد؟ و مهم‌تر از آن، چگونه می‌توانیم سیستم‌های خود را در برابر چنین تهدیدات بی‌سر و صدایی ایمن کنیم؟ در این گزارش، کالبدشکافی دقیقی از این فاجعه سایبری خواهیم داشت.

## نفوذ به قلب ردهت چگونه رخ داد؟

ماجرا از آنجا شروع شد که حساب کاربری گیت‌هابِ یکی از کارمندان ردهت، به روشی نامعلوم به دست مهاجمان افتاد. نفوذکنندگان به جای دستکاری کدهای اصلی (که سریع لو می‌رفت) از روشی استفاده کردند که تغییرات مخرب را از دید شاخه‌های اصلی پروژه و فرایندهای معمول بازبینی کد پنهان می‌کرد.

این یعنی آن‌ها تغییرات مخرب خود را مستقیماً به مخازن کدهای ردهت (مانند frontend-components و javascript-clients) فرستادند، اما تغییرات را در قالب «کامیت‌های یتیم» به هیچ‌یک از شاخه‌های اصلی متصل نکردند تا از رادار سیستم‌های بازبینی کد (Code Review) پنهان بماند.

مهاجمان بعد با استفاده از توکن‌های معتبر OpenID Connect (یا OIDC که یک لایه هویتیِ مبتنی بر OAuth 2.0 در GitHub Actions برای احراز هویت موقت است)، بسته‌های آلوده را در دو موج زمانی دقیق (ساعت ۱۰:۵۳ و ۱۳:۴۴ به وقت جهانی) منتشر کردند. نکته طعنه‌آمیز داستان اینجاست که استفاده از همین توکن‌های معتبر باعث شد بدافزارها گواهی اصالت نرم‌افزار کاملاً معتبر داشته باشند.

به زبان ساده، نگهبانی که برای محافظت از خانه گماشته شده بود، درها را برای ورود دزدها باز کرد! این موضوع شکنندگی مکانیزم‌های اعتماد دیجیتال در زنجیره تامین نرم‌افزار را برجسته می‌کند.

## مینی شای‌هولود: زندگی انگل‌وار در مرحله پیش‌ از‌ نصب

بدافزار مورد استفاده در این حمله، نسخه پیشرفته‌ای از کرم رایانه‌ای مینی شای‌هولود است. این بدافزار نخست در ماه مِی ۲۰۲۶ توسط گروه TeamPCP منتشر شد و مدت کوتاهی بعد، در حملات مختلف زنجیره تأمین مورد سوءاستفاده قرار گرفت. اکنون نیز به ابزاری در دست نفوذگرها تبدیل شده است. نام این بدافزار از کرم‌های غول‌پیکر شنی در رمان‌ها و فیلم‌های علمی‌تخیلی «تلماسه» (Dune) الهام گرفته شده است و عملکردی به همان اندازه ویرانگر دارد.

اما چرا این بدافزار تا این حد خطرناک است؟ خطر مینی شای‌هولود در استفاده از ویژگی قلاب پیش‌ از‌ نصب (Preinstall Hook) در اکوسیستم Node.js نهفته است. وقتی برنامه‌نویس دستوری برای نصب یک بسته می‌دهد، پیش از آنکه کد اصلی برنامه وارد عمل شود، یک فایل جاوا اسکریپت مبهم و حجیم (۴٫۲ مگابایت) در پس‌زمینه اجرا می‌شود.

برای درک بهتر، تصور کنید بسته‌ای اینترنتی سفارش داده‌اید؛ پیش از آنکه حتی جعبه را باز کنید، دستگاه شنودی که درون جعبه قرار گرفته، تمام اطلاعات خانه شما را اسکن و به بیرون مخابره می‌کند! بدافزار برای فرار از دست آنتی‌ویروس‌ها، خود را در چهار لایه پیچیده رمزنگاری مخفی می‌کند که به تفصیل در جدول زیر آمده‌اند:



| **لایه‌های استتار بدافزار** | **مکانیسم فنی** | **هدف مهاجم** |
| --- | --- | --- |
| **لایه اول** | مبهم‌سازی اولیه متن کد | پنهان‌سازی اولیه کد برای عبور از اسکن‌های ساده |
| **لایه دوم** | رمزنگاری بدنه اصلی آرایه جاوا اسکریپت | رمزنگاری بخش اصلی بدافزار |
| **لایه سوم** | پیچیده‌سازی منطق کنترل جریان | پیچیده‌سازی و ناخوانا کردن کد برای تحلیلگران |
| **لایه چهارم** | پنهان‌سازی اطلاعات اتصال در مخازن عمومی | مخفی کردن اطلاعات ارتباطی مهاجم و سرور فرماندهی |

## مهاجمان به دنبال چه اطلاعاتی‌اند؟ 

هدف اصلی مینی شای‌هولود، سرقت دارایی‌های دیجیتال است. این بدافزار فقط به فایل‌های ذخیره‌شده روی دیسک اکتفا نمی‌کند؛ بلکه تلاش می‌کند اطلاعات حساسی که همان لحظه در حافظه سیستم در حال استفاده هستند را نیز استخراج کند. فهرست اطلاعاتی که این بدافزار جارو می‌کند، لرزه بر تن هر متخصص امنیتی می‌اندازد:

- **اعتبارنامه‌های ابری**: کلیدهای دسترسی AWS، سرویس‌های GCP و حساب‌های Azure.
- **کلیدهای زیرساخت**: توکن‌های GitHub Actions، توکن‌های HashiCorp Vault و فایل‌های دسترسی به Kubernetes.
- **ابزارهای شخصی توسعه‌دهنده**: کلیدهای خصوصی SSH (مانند id\_rsa)، توکن‌های انتشار در npm و PyPI، و تمامی فایل‌های .env در سیستم که معمولاً حاوی رمزهای عبور دیتابیس هستند.

## کرم خودتکثیر و تله‌ی پاک‌کننده

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

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

علاوه‌ بر این، بدافزار با تغییر تنظیمات ویرایشگر VS Code و هوش مصنوعی Claude Code، کاری می‌کند که حتی بعد از پاک کردن فایل‌های آلوده، هر بار که پوشه پروژه‌ای را باز می‌کنید، ویروس دوباره جان بگیرد.

 ##### **تله‌ی پاک‌کننده**



در برخی نسخه‌های این بدافزار، سرویسی با نام gh-token-monitor دیده شده است که هر ۶۰ ثانیه اعتبار توکن‌های سرقت‌شده را بررسی می‌کند. اگر مهاجمان تشخیص دهند دسترسی قطع شده است، بدافزار ممکن است اقدام به حذف فایل‌های کاربر کند. در چنین شرایطی ممکن است بخش بزرگی از فایل‌ها و پروژه‌های ذخیره‌شده روی سیستم از بین بروند.





## در آخر: سرنوشت ردهت و درس‌هایی برای بقا

با خواندن این ابعاد از فاجعه، شاید بپرسید آیا محصولات سازمانی خود ردهت هم آلوده شده‌اند؟ خوشبختانه پاسخ منفی است. مهندسان ردهت از استانداردی به‌نام تثبیت نسخه (Version Pinning) استفاده می‌کنند. به این معنی که سیستم‌های داخلی آن‌ها به جای دانلود کورکورانه جدیدترین نسخه‌ها، روی نسخه‌های امن و از پیش‌تایید شده قفل شده‌اند. اما این مصونیت شامل حال برنامه‌نویسان خارج از ردهت در سراسر دنیا نمی‌شود.

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



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

- **شتاب‌زده کلیدها را باطل نکنید!** در برخی نسخه‌های این بدافزار، باطل کردن توکن سرقت‌شده می‌تواند باعث فعال شدن مکانیزم حذف فایل‌ها شود. ابتدا پردازش‌های مشکوک را متوقف و این سرویس را در مک (~/Library/LaunchAgents/) یا لینوکس (~/.config/systemd/user/) پیدا و پاک کنید.
- **سپس همه‌چیز را تغییر دهید:** باید فرض کنید تمامی رمزهای عبور، کلیدهای SSH، رمزهای ابری و توکن‌هایی که روی سیستم توسعه شما باز بوده‌اند، اکنون در اختیار مهاجمان قرار گرفته‌اند؛ همه را تغییر دهید.
- **محیط برنامه‌نویسی را پاکسازی کنید:** به فایل‌های تنظیمات VS Code و claude. خود سر بزنید و خطوط کدی را که به صورت خودکار اجرا می‌شوند، بررسی کنید.
- **استفاده از SBOM و محدودسازی:** از ابزارهایی استفاده کنید که SBOM (فهرست اجزای نرم‌افزار) تولید یا بررسی می‌کنند تا بدانید دقیقاً چه وابستگی‌هایی در پروژه وجود دارد.



امنیت سایبری در سال‌های اخیر از یک مزیت به یک ضرورت برای بقا تبدیل شده است. داستان مینی شای‌هولود نشان می‌دهد که گاهی خطرناک‌ترین دشمنان ما، نه از طریق ایمیل‌های [فیشینگ](http://nooshdaroo.ir/fraud-awareness/phishing/) و کلیک‌های اشتباه، بلکه از طریق ابزارهای روزمره‌ای که بی‌وقفه به آن‌ها اعتماد داریم وارد می‌شوند. در دنیای دیجیتالِ امروز، چشمان باز و احتیاطِ همیشگی، تنها نوشداروی محافظت از دارایی‌های دیجیتال ماست.