خلاصه
بر پایه گزارش پژوهشگران که در ۱۲ نوامبر ۲۰۲۶ منتشر شد، کارزار wfx-loot از حدود ۴٬۸۰۰ حساب GitHub نفوذشده برای کاوش بیش از ۶۱٬۰۰۰ مخزن و کاشتن یک سارق رمزهای CI استفاده کرد که به گفته Aikido دستکم در ۱٬۸۰۶ مخزن اجرا شد [1]. این کارزار از توکنهای سرقتشده سوءاستفاده میکند، نه از یک باگ GitHub [2]، و تغییراتش را ظرف حدود یک دقیقه برمی‌گرداند [1].
نکته‌های کلیدی
- Aikido Security میگوید این کارزار حدود ساعت ۱۲:۴۵ UTC روز ۱۰ نوامبر ۲۰۲۶ آغاز شد [1].
- ۴٬۸۳۷ حساب نفوذشده در ۶۱٬۷۶۴ مخزن، پول‌ریکوئست‌های کاوشگر با عنوان 'docs: dependency audit notes' باز کردند [1].
- سارق دستکم در ۱٬۸۰۶ مخزن اجرا شد؛ رقمی که به گفته Aikido ممکن است تأثیر را کمتر از واقع نشان دهد [1].
- این بدافزار رمزهای GitHub Actions، اعتبارنامه‌های ابری و کلیدهای سرویس‌های هوش مصنوعی را برمی‌دارد، سپس کامیت خود را برمی‌گرداند و اجرای workflow را حذف میکند [1][2].
- نبود یک شماره اجرای workflow درست پس از یک کامیت مشکوک، قابل‌اعتمادترین نشانه اجرای سارق است [2].
- اگر اجرا شده، هر رمزی را که workflow به آن دسترسی داشت بچرخانید و درهای پشتی ابری را بردارید، چون چرخاندن بهتنهایی کافی نیست [2].
در این صفحه ۱۲ بخش
- کارزار wfx-loot در GitHub چیست؟
- حمله wfx-loot چقدر بزرگ است؟
- سارق wfx-loot چگونه کار میکند؟
- چرا چرخاندن رمزها کافی نیست؟
- چگونه بفهمم مخازن GitHub من هدف قرار گرفتهاند؟
- اگر سارق اجرا شده باشد چه کنم؟
- کدام بستهها متأثر شدند؟
- پشت wfx-loot چه کسی است و توکنها را چگونه به دست آورد؟
- اشتباه‌های رایج
- پرسش‌های پرتکرار
- واژه‌نامه
- منابع
کارزار wfx-loot در GitHub چیست؟
wfx-loot کارزاری است که در آن مهاجم با اعتبارنامه‌های سرقتشده GitHub یک workflow مخرب را در مخازنی که آن حساب‌ها اجازه نوشتن در آنها دارند می‌فرستد و رمزهای GitHub Actions و اعتبارنامه‌های ابری را می‌دزدد [1]. Aikido Security که نخستین بار آن را گزارش کرد، نام آن را از نامی که خود مهاجم به بدافزار داده («wfx») و واژه‌ای که برای رمزهای سرقتشده به کار می‌برد («loot») گرفته است [1]. SafeDep نیز نخستین گزارش را به Aikido نسبت می‌دهد [5].
StepSecurity همین سارق را «wfx» می‌نامد و بر نکته‌ای کلیدی تأکید میکند: مهاجم از باگی در GitHub Actions بهره نمی‌برد [2]. در عوض از توکنهای معتبر حساب‌های واقعی توسعه‌دهندگان و بات‌ها استفاده میکند و مانند یک توسعه‌دهنده پولریکوئست باز میکند و کامیت می‌فرستد [2][4].
Aikido باور دارد هدف اصلی رمزهای CI است، نه گسترش از راه بسته‌های نرم‌افزاری، هرچند بار مخرب دستکم به یک بسته Packagist و یک بسته Go از راه محرک‌های انتشار خودکار رسید [1]. BleepingComputer با تکیه بر تحلیل Aikido گزارش می‌دهد برخی از حساب‌های نفوذشده به سازمان‌های بزرگ تعلق داشتند [3].
حمله wfx-loot چقدر بزرگ است؟
Aikido ۴٬۸۳۷ حساب نفوذشده را می‌شمارد که در ۶۱٬۷۶۴ مخزن پول‌ریکوئست‌های کاوشگر باز کردند و سارق دستکم در ۱٬۸۰۶ مخزن اجرا شد [1]. ارقام میان پژوهشگران اندکی تفاوت دارد، چون هر کدام GitHub را در زمان متفاوتی جستوجو کردند، در حالی که کارزار هنوز فعال بود.
- Aikido: ۴٬۸۳۷ حساب، ۶۱٬۷۶۴ مخزن؛ ۱۰٬۴۳۱ پولریکوئست به مخازنی رفت که حساب مالک آنها نیست؛ ۹۲٪ هنوز باز است؛ دستکم ۵۰ کاربر نفوذشده بسته‌هایی در npm، Go، Packagist، PyPI یا crates منتشر می‌کنند [1].
- Aikido (رقم خلاصه): دستکم ۱٬۸۳۵ مخزن بار مخرب را اجرا کردند و اعتبارنامه‌هایشان برداشته شد؛ BleepingComputer از این رقم استفاده میکند [1][3].
- StepSecurity: بیش از ۶۳٬۰۰۰ پولریکوئست کاوشگر تا ساعت ۰۷:۴۰ UTC روز ۱۲ نوامبر، حدود ۹۰٪ هنوز باز [2].
- SafeDep: ۸٬۰۹۳ مخزن میان ۱۰ تا ۱۲ نوامبر کامیت‌های مخرب دریافت کردند؛ رقمی که به‌گفته SecurityWeek لزوماً به معنای اجرای سارق نیست [5][4].
Aikido هشدار می‌دهد شمار اجراهای گزارش‌شده‌اش ممکن است تأثیر را کمتر از واقع نشان دهد، چون گزارش‌های اجرا در مخازن متأثر حذف شده‌اند [1].
سارق wfx-loot چگونه کار میکند؟
برای هر مخزنی که توکن سرقتشده می‌تواند در آن بنویسد، مهاجم کاوش میکند، بار مخرب را می‌فرستد و ظرف حدود یک دقیقه ردپایش را پاک میکند [1].
- کاوش: یک پولریکوئست با عنوان «docs: dependency audit notes» از شاخه‌ای به نام wfx-docs یک فایل یادداشت کوچک اضافه میکند. به گفته StepSecurity «این پولریکوئست به‌خودی‌خود کاری نمی‌کند»؛ فقط نشان می‌دهد توکن دسترسی نوشتن دارد [2][4].
- بار مخرب: یک اسکریپت شل حدود ۱٬۵۰۰ خطی به یکی از سه راه می‌رسد: تزریق در یک workflow موجود («ci: refresh build cache»)، به‌صورت یک اسکریپت همراه با قلاب postinstall در npm («chore: add ci helper»)، یا یک workflow جدید روی شاخه‌ای موقت با پیشوند chore/ («chore: add dependency audit workflow») [1].
- پاک‌سازی: مهاجم تغییر را برمی‌گرداند و اجرای workflow و گزارش‌هایش را حذف میکند [1]. شماره اجرای گمشده اغلب تنها ردپاست [1].
این اسکریپت رمزها و توکنهای GitHub Actions، کل محیط اجرای runner، فایل‌های اعتبارنامه AWS، Azure، Google Cloud، Docker، Kubernetes، npm، PyPI، SSH و غیره، تاریخچه شل و کلیدهای ارائه‌دهندگان هوش مصنوعی و ابزارهای توسعه را جمع‌آوری میکند [1][3]. حتی حافظه فرایندهای در حال اجرا روی runner را هم می‌خواند [1][4]. Aikido دریافت که نسخه‌هایی که تحلیل کرد داده‌های سرقتشده را فقط با HTTP POST به سرورهای زیر کنترل مهاجم می‌فرستند [1]. StepSecurity بعداً تغییری دید: از حدود ساعت ۰۵:۳۰ UTC روز ۱۲ نوامبر، نسخه‌های جدید داده را فقط از راه Telegram می‌فرستند، بنابراین مسدود کردن نشانی سرورهای منتشرشده بهتنهایی دیگر جلوی آنها را نمی‌گیرد [2].
چرا چرخاندن رمزها کافی نیست؟
چون سارق می‌کوشد درهای پشتی بکارد که از چرخاندن اعتبارنامه‌ها جان به در میبرند [1][2]. Aikido سه ترفند ماندگاری را توصیف میکند [1]:
- جعل بررسی‌های وضعیت: Aikido میگوید بررسی‌های جعلی «موفق» را با نام بررسی‌های الزامی مخزن ثبت میکند که می‌تواند دروازه‌های ادغام حفاظت شاخه را باز کند [1]. StepSecurity این قابلیت را در هر ۱۰۱ نمونه‌ای که بررسی کرد خاموش یافت [2].
- بازنویسی سیاست اعتماد AWS: می‌تواند سیاست اعتماد یک نقش را طوری تنظیم کند که هر حساب AWS را مجاز بداند [1].
- تزریق هویت فدرال Azure: می‌تواند اعتبارنامه‌های فدرال با نام wfx-ci-… را به برنامه‌های Azure AD بیفزاید و به workflowهای مخزن نفوذشده اجازه دهد بدون رمز ذخیره‌شده احراز هویت کنند [1].
همچنین می‌تواند توکنهای OIDC گیت‌هاب بسازد و آنها را با نشست‌های AWS، Google Cloud و Azure مبادله کند، به نقش‌های IAM دیگر زنجیر شود و کلیدهای دسترسی بلندمدت AWS بسازد [1][3]. به همین دلیل StepSecurity میگوید «ماندگاری را بردارید، چون چرخاندن بهتنهایی آن را برنمیدارد» [2].
چگونه بفهمم مخازن GitHub من هدف قرار گرفتهاند؟
از ۱۰ نوامبر به بعد پولریکوئست کاوشگر و پیامهای کامیت مهاجم را جستوجو کنید، سپس بهدنبال فاصله‌ها در شماره اجرای workflowها بگردید [2][1].
- در پول‌ریکوئست‌ها «docs: dependency audit notes» و شاخه‌هایی به نام wfx-docs یا chore/ و پس از آن هشت نویسه را جستوجو کنید [1][2].
- کامیت‌ها را از ۱۰ نوامبر به بعد برای «ci: refresh build cache»، «ci: restore»، «ci: cleanup»، «chore: add ci helper» و «chore: add dependency audit workflow» جستوجو کنید [2].
- برای هر نتیجه، زبانه Actions را باز کنید و بهدنبال شماره اجرای گمشده درست پس از کامیت بگردید؛ StepSecurity این را قابل‌اعتمادترین نشانه اجرای سارق می‌داند [2].
- توجه کنید کدام حساب کامیت‌ها را فرستاده است: توکنهای آن حساب سرقت شده‌اند [2]. اگر یک پولریکوئست کاوشگر وجود دارد، حساب نفوذشده است، حتی اگر هیچ بار مخربی اجرا نشده باشد [1].
به نبود آثار تکیه نکنید. Aikido میگوید نبود artifactهای wfx-loot، ورودی‌های حافظه نهان با پیشوند wfx- یا خلاصه‌های گام ویژه به معنای ندزدیدن داده نیست، چون این کانال‌ها در این کارزار خاموش شده بودند [1]. Aikido همچنین میگوید ممکن است بار مخرب در مخازن خصوصی هم مانند مخازن عمومی مستقر شود [1].
اگر سارق اجرا شده باشد چه کنم؟
فرض کنید هر رمز و نقش ابری که در دسترس workflow متأثر بود نفوذشده است، آنها را بچرخانید و سپس بهدنبال ماندگاری بگردید [1][2].
- چرخاندن: هر رمز مخزن، محیط و سازمان که job می‌توانست به آن برسد، نه فقط رمزهایی که workflow نام می‌برد؛ توکنهای انتشار npm، PyPI و دیگر؛ و کلیدهای ابری ذخیره‌شده به‌عنوان رمز [2].
- بررسی بستهها: نسخه‌های بسته‌ای را که پس از کامیت مخرب منتشر شده‌اند بیابید [2].
- AWS: بهدنبال سیاست‌های اعتمادی بگردید که هر principal در AWS را مجاز می‌دانند، کلیدهای دسترسی IAM ساخته‌شده از ۱۰ نوامبر به بعد و نشست‌های CloudTrail که با wfx- شروع می‌شوند [2].
- Azure: اعتبارنامه‌های هویت فدرال با نام wfx-ci-* را در ثبت‌های برنامه حذف کنید [2].
- Google Cloud، Vault، Kubernetes: تولید توکن و ورودهای انجام‌شده با توکنهای ورود GitHub Actions را بازبینی کنید [2].
- GitHub: شاخه‌های باقی‌مانده را حذف کنید، پول‌ریکوئست‌های کاوشگر را ببندید، بررسی کنید چیزی با بررسی جعلی ادغام نشده باشد و توکنها، مجوزهای OAuth و کلیدهای SSH حساب را باطل کنید [2].
- توکنها، طبق مستندات GitHub: توکنهای دسترسی شخصی خود را در Settings و Developer settings مرور کنید و هر توکنی را که نمی‌شناسید یا نیاز ندارید حذف کنید؛ GitHub توکنهای دقیق‌دانه (fine-grained)، فقط حداقل مجوزهای لازم و تاریخ انقضا را توصیه میکند، چون یک توکن کلاسیک می‌تواند به هر مخزنی که شما به آن دسترسی دارید دسترسی یابد [6].
قلاب npm روی ماشین توسعه‌دهندگان هم اجرا می‌شود: هر کس در آن بازه کوتاه npm install را اجرا کرد، سارق را به‌صورت محلی اجرا کرده و باید اعتبارنامه‌های خودش را هم بچرخاند [2]. SecurityWeek توصیه چند شرکت امنیتی را چنین جمع‌بندی میکند: توکنهای نفوذشده را باطل کنید، رمزهای فاش‌شده را بچرخانید و تغییرات ابری غیرمجاز را بررسی کنید [4]. برای حساب‌های بات، StepSecurity پیشنهاد میکند بررسی شود آیا اصلاً به مجوز دور زدن حفاظت شاخه نیاز دارند [2]. حفاظت قوی ورود، کارزارهای سرقت حساب را دشوارتر میکند؛ Two-Factor Authentication Explained: Which 2FA Method Is Safest? را ببینید.
کدام بستهها متأثر شدند؟
Aikido یک بسته Packagist و یک ماژول Go را فهرست میکند که بار مخرب را از راه انتشار خودکار گرفتند [1].
- Packagist: digitalelvis/neuronai-studio نسخه 3.14.3؛ Aikido میگوید هر ماشینی را که آن را نصب یا باز کرده نفوذشده بدانید [1].
- Go: github.com/onuragtas/docker-env نسخه‌های v1.0.278 و v1.0.280؛ بار مخرب فقط در یک فایل workflow در GitHub Actions است، کد منبع و باینری‌های Go تغییری نکرده‌اند و ساخت‌های Go هرگز فایل‌های workflow را اجرا نمی‌کنند، اما Aikido همچنان حذف این نسخه‌ها را توصیه میکند [1].
شمارش‌ها فرق میکند: SafeDep میگوید سه بسته در Packagist و پروکسی ماژول Go بار مخرب را حمل می‌کنند و SecurityWeek از نسخه‌هایی از دو ماژول Go یاد میکند [5][4]. SafeDep می‌افزاید بار مخرب برای مصرف‌کنندگان معمول که این بستهها را با composer require یا go get نصب می‌کنند اجرا نشد [5]. پیش از تکیه بر هر فهرست، فهرست فعلی هر پژوهشگر را بررسی کنید.
پشت wfx-loot چه کسی است و توکنها را چگونه به دست آورد؟
هیچ‌یک از گزارش‌های نام‌برده مهاجم را شناسایی نمی‌کند و StepSecurity میگوید نحوه بهدست آمدن توکنها را روشن نکرده است [2][4].
StepSecurity ۱۷۳ پولریکوئست کاوشگر از ۱۹ حساب یافت که با توکنهای صادرشده برای برنامه GitHub شرکت Fly.io انجام شده بود؛ این شرکت گفت نتوانست مشخص کند توکنها چگونه به دست آمدند و شواهدی ندارد که زیرساخت Fly.io نفوذ شده باشد [2][4].
Aikido همپوشانی با حساب‌های هدف‌گرفته‌شده در موج GhostAction در اکتبر یافت و wfx-loot را در بیش از ۱۰۰ مخزن در فایل‌های workflow مربوط به GhostAction تزریق‌شده دید، اما آن دو را کارزارهای متمایز و محتملاً به دست بازیگران متفاوت ارزیابی کرد، چون اعتبارنامه‌های سرقتشده اغلب به چند گروه می‌رسند [1]. همچنین در برخی نسخه‌های جدیدتر بدافزار توضیحاتی به زبان اندونزیایی دید [1]. نگهداری دقیق توکنها اینجا اهمیت دارد؛ Password Managers Explained: How They Work and Whether They Are Safe مبانی آن را توضیح می‌دهد.
| معیار | رقم | منبع |
|---|---|---|
| حساب‌های نفوذشده | ۴٬۸۳۷ | Aikido |
| مخازن کاوش‌شده | ۶۱٬۷۶۴ | Aikido |
| مخازنی که سارق در آنها اجرا شد | دستکم ۱٬۸۰۶ تا ۱٬۸۳۵ | Aikido |
| مخازن دارای کامیت مخرب | ۸٬۰۹۳ | SafeDep |
| پول‌ریکوئست‌های کاوشگر | بیش از ۶۳٬۰۰۰ (۱۲ نوامبر، ۰۷:۴۰ UTC) | StepSecurity |
اشتباه‌های رایج
فرض اینکه شاخه تمیز یعنی سرقتی رخ نداده.
راه درست: مهاجم کامیت‌ها را برمی‌گرداند؛ شماره اجرای گمشده را بررسی کنید [1][2].
چرخاندن فقط رمزهایی که workflow نام می‌برد.
راه درست: اسکن حافظه بقیه را هم جمع میکند؛ هر چه در دسترس بود بچرخانید [2].
توقف پس از چرخاندن.
راه درست: ماندگاری AWS و Azure را هم بردارید [2].
مقصر دانستن باگ GitHub Actions.
راه درست: مهاجم از توکنهای معتبر سرقتشده استفاده میکند [2].
نادیده گرفتن یک پولریکوئست کاوشگر باز.
راه درست: یعنی حساب نفوذشده است [1].
پرسش‌های پرتکرار
کارزار wfx-loot در GitHub چیست؟
کارزاری که از توکنهای سرقتشده GitHub برای کاشتن سارق رمزهای CI در مخازن استفاده میکند [1].
حمله wfx-loot چقدر بزرگ است؟
۴٬۸۳۷ حساب ۶۱٬۷۶۴ مخزن را کاوش کردند؛ سارق دستکم در ۱٬۸۰۶ مخزن اجرا شد [1].
سارق wfx-loot چگونه کار میکند؟
پولریکوئست کاوشگر، سپس اسکریپتی حدود ۱٬۵۰۰ خطی از راه workflow یا قلاب npm، سپس برگرداندن و حذف گزارشها [1].
چرا چرخاندن رمزها کافی نیست؟
Aikido درهای پشتی AWS و Azure را توصیف میکند که از چرخاندن جان به در میبرند؛ StepSecurity میگوید ماندگاری را بردارید، چون چرخاندن بهتنهایی آن را برنمیدارد [1][2].
چگونه بفهمم مخازن GitHub من هدف قرار گرفتهاند؟
پولریکوئست کاوشگر و پیامهای کامیت را جستوجو کنید، سپس بهدنبال شمارههای اجرای گمشده بگردید [2].
اگر سارق اجرا شده باشد چه کنم؟
همه رمزهای در دسترس را بچرخانید، بستهها را بررسی کنید و ماندگاری ابری را بردارید [2].
کدام بستهها متأثر شدند؟
Aikido بسته Packagist با نام digitalelvis/neuronai-studio نسخه 3.14.3 و Go با نام docker-env نسخه‌های v1.0.278 و v1.0.280 را فهرست میکند؛ SafeDep موارد بیشتری ذکر میکند [1][5].
پشت wfx-loot چه کسی است و توکنها را چگونه به دست آورد؟
در گزارشها شناسایی نشده؛ StepSecurity برخی کاوشها را به توکنهای برنامه GitHub شرکت Fly.io ردیابی کرد و نحوه بهدست آمدن آنها را روشن نکرده است [2].
واژه‌نامه
- GitHub Actions
- سامانه یکپارچه CI/CD در GitHub که با تغییر کد، workflowها را اجرا میکند [1].
- رمز CI
- گذرواژه، توکن یا کلیدی که برای استفاده workflowهای ساخت خودکار نگهداری می‌شود [1].
- توکن OIDC
- توکن هویتی کوتاه‌مدت که یک workflow می‌تواند آن را با دسترسی ابری مبادله کند [1].
- پولریکوئست کاوشگر
- یک پولریکوئست به‌ظاهر بی‌ضرر که برای آزمودن دسترسی نوشتن به کار می‌رود [2].
- ماندگاری
- دسترسی‌ای که مهاجم پس از تغییر اعتبارنامه‌های اولیه نگه می‌دارد [2].
منابع
- wfx-loot campaign pushes CI secret stealer to tens of thousands of repositories Aikido Security · 2026-11-12
- WFX Phantom: The GitHub Actions Secret Stealer That Deletes Its Tracks StepSecurity · 2026-11-12
- Hackers compromise 4,800 GitHub accounts to steal cloud credentials BleepingComputer · 2026-11-12
- Attacker Targets 60,000 GitHub Repositories in Credential Theft Campaign SecurityWeek · 2026-11-12
- wfx: GitHub Actions Credential Stealer Hits 8,000 Repos SafeDep · 2026-11-12
- Managing your personal access tokens GitHub Docs
نظرات
نظرهای برتر