پس منظر

ہال ہی میں، MistEye سیکیورٹی مانیٹرنگ سسٹم نے ریڈ ہیٹ کلاؤڈ سروسز ادارے کے تحت کئی npm پیکیجز میں غیر معمولی ورژن کے بارے میں معلومات کو ٹریس کیا۔ اس واقعے میں کل 32 npm پیکیجز اور 96 ورژن شامل ہیں۔ اس مضمون میں، ہم نے تین مقامی نمونوں کا گہرا آف لائن تجزیہ کیا: یہ نمونے نام کے جھوٹے استعمال یا ٹائپو-اسکواٹنگ پیکیجز نہیں ہیں، بلکہ @redhat-cloud-services اسکوپ کے حقیقی پیکیجز ہیں؛ نمونوں کے سورس کوڈ سے تصدیق ہوتی ہے کہ ان کے tarball میں انسٹال ہونے کے دوران خودکار طور پر فعال ہونے والے متعدد لیئرز کے مختلط مالوئیر لوڈر شامل ہیں۔

پوری طرح واپس کرنے کے بعد تصدیق ہو گئی کہ ان 3 نمونوں کا مرکزی بوجھ GitHub Actions Runner کی میموری پڑھنا، متعدد ابر اور مقامی اعتماد کی تفصیلات جمع کرنا، GitHub API کے ذریعے ڈیٹا باہر بھیجنا اور ڈیڈ-ڈراپ، GitHub ورک فلو میں انفیکشن، npm کے ذریعے خود کو پھیلانا، Claude Code / VS Code / systemd / LaunchAgent کے ذریعے مستقل رہنا، Harden-Runner / StepSecurity کے خلاف مقابلہ، اور EDR / سیکورٹی پروڈکٹس کا پتہ لگانا جیسی صلاحیتیں رکھتا ہے۔ صلاحیتوں کے دائرہ کار کے اعتبار سے، ممکنہ متاثرہ اشیاء میں ڈویلپر ہوسٹس، CI/CD Runner، بِلڈ کنٹینرز، GitHub ریپوزٹریز، GitHub Actions ورک فلو، npm ریلیز سلسلہ اور ابر ماحول کے اعتماد کی تفصیلات شامل ہیں؛ عملی متاثرہ دائرہ کار کو نصب کرنے کے 日志، ریپوزٹری کے جائزہ اور پلیٹ فارم سطح کے ٹیلیمٹری کے ساتھ ملا کر مزید تصدیق کی ضرورت ہے۔

کوڈ سٹرکچر، پھیلاؤ کے راستوں اور صلاحیتوں کے مجموعے کے حوالے سے، یہ بری اسافٹ شائی-ہولود بری اسافٹ کا ایک ویریئنٹ ہے۔

MistEye جواب

MistEye، SlowMist کا خود ساختہ Web3 خطرات کی معلومات اور ڈائنانک سیکورٹی مانیٹرنگ سسٹم ہے، جو سیکورٹی مانیٹرنگ اور معلومات کے اکٹھے کرنے کی صلاحیتیں متحد کرتا ہے تاکہ صارفین کو حقیقی وقت کے خطرات کی اطلاع اور اثاثوں کی حفاظت فراہم کی جا سکے۔

جب Red Hat Cloud Services npm پیکیج سپلائی چین کے زہریلے واقعہ اور اس سے متعلقہ بری بھیجے گئے نمونوں کو شناخت کیا گیا، تو MistEye سسٹم نے اعلیٰ خطرہ کا ایلارم ٹرگر کر دیا اور حملے کے لئے اس کی مبہم ساخت، لوڈ کو ڈی کرپٹ کرنا، صلاحیتوں کو واپس حاصل کرنا اور IOC کا نظام گٹھ بندھا تجزیہ کیا۔

(https://enterprise.misteye.io/threat-intelligence/SM-2026-378450)

حملہ زنجیر کا جائزہ

اس مضمون کا ٹیکنیکل تجزیہ صرف مقامی آف لائن اسٹیٹک تجزیہ پر مبنی ہے، جس میں 3 npm tgz نمونوں کو ان پیک، ڈی کوڈ اور ڈی اسکرامبل کر کے تصدیق کی گئی۔

اس تصدیق میں درج ذیل نمونے شامل ہیں:

@redhat-cloud-services/frontend-components-config

ورژن: 6.11.3

tgz SHA-256: 0c9c67ec40d5f23efa1ec3470d0ac88b4993ccc0e92be913fc29a337dfc4f060

@redhat-cloud-services/types

ورژن: 3.6.1

tgz SHA-256: d543bb3cdf1569c2b3d38c8a4081ed746cfe78bf3236c2302704d79ab7fa9558

@redhat-cloud-services/rule-components

ورژن: 4.7.2

tgz SHA-256: aaf00d06baa3c679b82452c50014e9824b8874e9ca2d150f19095f8de19ba90f

تین نمونوں کے حمل کے انٹری پوائنٹ مکمل طور پر ایک جیسے ہیں: package.json میں سب کے سب scripts.preinstall = "node index.js" موجود ہے۔ اس کا مطلب یہ ہے کہ جب بھی ڈویلپر کا ہوسٹ یا CI/CD ماحول ان ورژنز کو انسٹال کرے گا، تو رُوٹ ڈائرکٹری میں index.js انسٹالیشن کے مرحلے میں خود بخود اجراء ہو جائے گا، بغیر کسی صارف کے واضح طور پر import کرنے یا بزنس کوڈ کو چلانے کے۔

تین نمونے ایک ہی مرکزی بریک کے ساتھ شیئر کرتے ہیں، لیکن بیرونی پیکیج پیرامیٹرز مختلف ہیں۔ یعنی، تینوں نمونے مختلف ROT/Caesar شفٹ ویلیوز اور AES-GCM کلید / IV / ٹیگ استعمال کرتے ہیں؛ جس سے بیرونی پیکیج ہیش، فکسڈ کلید یا فکسڈ شفٹ کے بنیاد پر سٹیٹک خصوصیات کو براہ راست پیک کے درمیان دوبارہ استعمال کرنا مشکل ہو جاتا ہے۔ لیکن ڈی کرپٹ کردہ Bun رن ٹائم اینویرنمنٹ بوٹسٹریپر اور مرکزی بریک ہیش مکمل طور پر ایک جیسے ہیں: ایک Bun رن ٹائم اینویرنمنٹ تیار کرنے کے لیے اسٹارٹ اپ اسسٹنٹ مالڈول ہے، جبکہ دوسرا واقعی بریک فنکشنز شامل کرنے والا مرکزی لوڈ ہے۔ اس مضمون میں دونوں کو الگ الگ "Bun رن ٹائم اینویرنمنٹ بوٹسٹریپر (سورس کوڈ ویری ایبل _b)" اور "مرکزی بریک (سورس کوڈ ویری ایبل _p)" کہا جاتا ہے۔

واپسی کے بعد حملہ کا سلسلہ درج ذیل ہے:

ٹیکنیکل تجزیہ

تینوں نمونے package.json کے preinstall لائف سائکل ہُک کے ذریعے حملے کی کڑی کو فعال کرتے ہیں:

"اسکرپٹس": {

"preinstall": "node index.js"

}

پری انستال npm انسٹالیشن کے دوران خود بخود انجام ہو جائے گا۔ عام فرانت اینڈ کمپوننٹس، ٹائپ ڈیفینیشنز یا رول کمپوننٹ پیکیجز کے لیے، انسٹالیشن کے دوران روت ڈائرکٹری کا بڑا جاوا اسکرپٹ فائل نہیں چلنا چاہیے؛ یہ سب سے براہ راست غیر معمولی علامت ہے۔

نمونہ سطح کا ثبوت درج ذیل ہے:

@redhat-cloud-services/frontend-components-config@6.11.3

• مین: lib/index.js
• فائلز فیلڈ: ["/lib", "/bin"]
• رُوٹ ڈائرکٹری index.js SHA-256: 545a1838c66e1771f58d84a17b3e1841e5eeab91a73f4ccc59c9492450a6d9c0

@redhat-cloud-services/types@3.6.1

• مین：index.d.ts
• فائلز فیلڈ: متعین نہیں کیا گیا
• رُوٹ ڈائرکٹری index.js SHA-256: b86c5ae9e95bd841a595440faa3eb6317441e746f241ae8fd641ab59ed1d1966

@redhat-cloud-services/rule-components@4.7.2

• main: index.js
• فائلز فیلڈ: متعین نہیں کیا گیا
• رُوٹ ڈائرکٹری index.js SHA-256: 1a30a9abe20bab121aaa75ed040565af14e6cdfb745609ee0e7b94a2d814fb9c

اس میں، frontend-components-config@6.11.3 کا files فیلڈ صرف "/lib" اور "/bin" کو درج کرتا ہے، لیکن tarball کے رُٹ ڈائرکٹری میں ایک اضافی index.js موجود ہے جسے preinstall کال کرتا ہے۔ یہ غیر معمولی صورت صرف اس نمونے میں پایا جاتا ہے؛ types@3.6.1 اور rule-components@4.7.2 میں files فیلڈ سیٹ نہیں کیا گیا، اس لیے اس غیر معمولی صورت کو تمام نمونوں تک عام نہیں کیا جا سکتا۔

تین نمونوں کے رُوتھ کے index.js فائلیں سب ہی بہت بڑے ایک لائن جاوااسکرپٹ فائلیں ہیں، جن کی ساخت ایک جیسی ہے اور مرکزی حصہ try { eval(...) } catch (...) کے ورپر ہے:

یہ ویپر پہلے بہت بڑی عددی سری کو String.fromCharCode کے ذریعے سٹرنگ میں واپس تبدیل کرتا ہے، پھر سٹرنگ میں انگریزی حروف پر ROT/Caesar شفٹ لاگو کرتا ہے، اور آخر میں ڈیکوڈ شدہ نتیجہ eval کو دیتا ہے۔ ایکسپشن ہینڈلنگ صرف "wrapper:" پریفکس کو ظاہر کرتی ہے تاکہ انسٹالیشن ناکام ہونے پر ایکسپشن کم نمایاں رہے۔

تین نمونوں کی باہری جابجائی اقدار اور Stage 2 hash درج ذیل ہیں:

frontend-components-config@6.11.3

index.js کا سائز: 4,294,798 بائٹس

ROT/Caesar shift: 10

مرحلہ 2 SHA-256: b19c2fd48535c8c40aeb3e627ce92775f33ef9292611767bb1236c238e6f90cc

types@3.6.1

index.js کا سائز: 4,135,588 بائٹس

ROT/Caesar shift: 4

مرحلہ 2 SHA-256：9c0425aa6e6d7792ac38d24f3e7245f42fcaa553ddfeb6bd97677017f10c3b75

rule-components@4.7.2

index.js کا سائز: 4,294,336 باٹس

ROT/Caesar shift: 11

مرحلہ 2 SHA-256: d590bd375d95e4ac072b7ebc1fc4489bcaf5f20a939e92486267aa398bcf1e5d

ROT/Caesar ڈیکوڈ کے بعد، Stage 2 کوڈ Node.js کے crypto.createDecipheriv کا استعمال کرتے ہوئے AES-128-GCM (Advanced Encryption Standard - Galois/Counter Mode) ڈیکرپشن کرتا ہے اور setAuthTag کے ذریعے تصدیقی علامت سیٹ کرتا ہے۔ ڈیکرپشن کا مقصد دو بعد کے کمپوننٹس — Bun رن ٹائم گائیڈ اور مرکزی بریکن لود ہے۔

اس میں، Bun رن ٹائم اسٹارٹر Bun رن ٹائم کا پتہ لگانے، یا تیار کرنے کا کام کرتا ہے تاکہ بعد کا کوڈ Bun کے ذریعے انجام پائے؛ اور مرکزی بری خطرہ حملے کا اہم حصہ ہے جس میں بعد کے اعتماد کی جانچ، GitHub/npm کے ذریعہ پھیلاؤ، مستقل رہنے کی صلاحیت، تحفظ سے بچنے اور داخلہ وسائل کو ڈیکرپٹ کرنے جیسی اہم بری خطرات شامل ہیں۔

تینوں نمونوں میں دونوں کمپوننٹس کو الگ الگ AES-128-GCM کلید، ابتدائی ویکٹر اور تصدیقی لیبل کے ساتھ اینکرپٹ کیا گیا تھا، لیکن ڈیکرپٹ کرنے کے بعد تینوں Bun رن ٹائم بُوت ریڈرز کا SHA-256 ac2a2208e1726e008be6c73dc0872d9bba163319259dff1b62055ac933ca46b6 ہے، اور تینوں مرکزی برے مالویئر کا SHA-256 0dc06ecdaa63fe24859cfd955053c23245c536e4733480239d14bebf12688e35 ہے۔ یہ ظاہر کرتا ہے کہ حملہ آور نے مختلف npm پیکیجز میں بیرونی پیکنگ پیرامیٹرز تبدیل کیے، لیکن ایک ہی مرکزی برے کمپوننٹس کو دوبارہ استعمال کیا۔

ڈی کرپٹ کرنے کے بعد، اسٹیج 2 مرکزی برے مالویئر کو /tmp میں لکھتا ہے، پھر بان کے ذریعے اسے انجام دیتا ہے، اور آخر میں عارضی فائل حذف کر دیتا ہے۔ تین نمونوں کو واپس حاصل کرنے پر حقیقی منطق درج ذیل ہے:

اس لیے، تین نمونوں میں تصدیق شدہ عارضی فائل کا نمونہ یہ ہے:

/tmp/p.js

Bun رنٹائم اینوائرمنٹ بُوٹسٹر کا سائز 898 باٹس ہے، تین نمونوں کے ہیش مکمل طور پر ایک جیسے ہیں:

ac2a2208e1726e008be6c73dc0872d9bba163319259dff1b62055ac933ca46b6

Bun رن ٹائم اینوائرمنٹ بُوٹسٹر میں child_process.execSync، fs.existsSync، fs.mkdtempSync، fs.chmodSync، os.platform()، os.arch()، getBunPath() جیسے منطق شامل ہے جو Bun رن ٹائم اینوائرمنٹ کو تلاش کرنے یا تیار کرنے کے لیے استعمال ہوتا ہے۔ یعنی، اسٹیج 2 صرف یہ فرض نہیں کرتا کہ سسٹم پر عالمی Bun نصب ہے؛ غیر Bun رن ٹائم پاتھ میں، یہ پہلے Bun رن ٹائم اینوائرمنٹ بُوٹسٹر لوڈ کرتا ہے، اور پھر getBunPath() کے ذریعے Bun کو بلا کر مرکزی بربری لوڈ کو انجام دیتا ہے۔

decode کیے گئے بنیادی بری بھیج کوئی براہ راست پڑھنے کے قابل متن JavaScript نہیں ہے، بلکہ اسے obfuscator.io کے انداز میں سٹرنگ ٹیبل اوبفوسکیشن کے ذریعے مزید پوشیدہ کیا گیا ہے۔ اس لیyer میں بہت سارے سٹرنگز ایک صرف میں جمع کر لیے جاتے ہیں، اور رن ٹائم انڈیکس اور روٹیشن منطق کے ذریعے انہیں دوبارہ ترتیب دیا جاتا ہے، جس کی وجہ سے تجزیہ کرنے والے اس سٹرنگ ٹیبل کو واپس لانے تک بعد کے اہم API، راستوں اور ترتیبات کے ناموں تک براہ راست رسائی نہیں پا سکتے۔

obfuscator.io کے سٹرینگ ٹیبل کو ریسٹور کرنے کے بعد، مرکزی بری بھیج میں اب بھی ایک B5 کسٹم سٹرینگ انکرپشن موجود ہے۔ پیرامیٹرز کی تصدیق کر لی گئی ہیں:

• KDF: PBKDF2 (Password-Based Key Derivation Function 2)
• ہیش فنکشن: SHA-256
• تکرار کی تعداد: 200000
• کلید کی لمبائی: 32 باٹس
• ڈی کرپٹ راؤنڈز: 3
• پاس ورڈ：ba2c6ddb3672bdd6a611e6850b4f700b52aed3dab2f1b3d5f8c839d4a157a709
• salt: 5b26508dc0f1075a7c0b4d8aa464487e

ڈی کرپٹ کردہ نتیجہ درج ذیل ہے:

اس میں، B5 کو ڈی کرپٹ کرنے کے بعد کئی اہم صاف متن کے سٹرنگز نظر آتے ہیں۔ توجہ دیں کہ کچھ سٹرنگز اصل میں obfuscator.io کے سٹرنگ ٹیبل میں موجود تھے، اور صرف "سٹرنگ ٹیبل ریپلیسمنٹ + B5 ڈی کرپشن" دونوں مراحل مکمل ہونے کے بعد ہی انہیں ب без گریپ کیا جا سکتا ہے:

مرکزی برے لوڈ کے اندر AES-256-GCM سے اینکرپٹ اور gzip سے کمپریس کیے گئے ایم بیڈڈ ریسورسز شامل ہیں۔ ریسٹور لاجک استعمال کرتا ہے:

کلیدی امبدڈڈ ریسورسز کو فنکشن کے لحاظ سے تین کیٹیگریز میں تقسیم کیا گیا ہے:

کراس پلیٹ فارم میموری ریڈنگ:

یہ وسائل چل رہے پروسیسز کی میموری پڑھنے کے لیے استعمال ہوتے ہیں۔ عام فائلز میں کلیدیں یا ٹوکن تلاش کر کے دریافت کیے جا سکتے ہیں، لیکن CI/CD رنر یا ڈویلپمنٹ ٹولز چلائے جانے پر کچھ حساس اقدار کو میموری میں عارضی طور پر محفوظ کر دیتے ہیں۔ حملہ آور لینکس، ونڈوز اور میک او ایس تینوں پلیٹ فارمز کے لیے میموری پڑھنے والے اسکرپٹس شامل کرتے ہیں تاکہ مختلف سسٹمز پر پروسیس میموری سے ان عارضی سیکرٹس کو حاصل کیا جا سکے۔

مستقل ترتیبات:

یہ وسائل "پیچھے کا دروازہ ٹریگر" چھوڑنے کے لیے استعمال ہوتے ہیں۔ یعنی، ابتدائی npm انسٹال پروسیس ختم ہونے کے باوجود، حملہ آور چاہتے ہیں کہ برائی کا کوڈ ڈویلپر کے بعد میں پروجیکٹ کھولنے، ایڈیٹر شروع کرنے، Claude Code سیشن میں داخل ہونے، یا سسٹم میں دوبارہ لاگ ان ہونے کے بعد دوبارہ چلے۔ اس لیے ان وسائل نے پروجیکٹ لیول کانفگریشن اور صارف لیول آٹو-اسٹارٹ مکینزم دونوں کو ٹارگٹ کیا ہے: پروجیکٹ لیول کانفگریشن زیادہ پوشیدہ ہوتی ہے، جبکہ سسٹم لیول سروسز لمبے عرصے تک چلنے کے لیے زیادہ مناسب ہوتے ہیں۔

C2 اور پھیلاؤ:

یہ ایمبیڈڈ وسائل بعد میں لینک اور ریپوزیٹری سیکرٹس کے منتقل کرنے کے لیے استعمال ہوتے ہیں۔ YZ کو ڈیکرپٹ کرنے پر GitHub کامٹ سرچ مانیٹر بن جاتا ہے، جو فائرڈالازر . فارمیٹ کے کامٹ میسج کو دورانیے کے ساتھ تلاش کرتا ہے، سائگنیچر کی تصدیق کے بعد دوران Python مواد کو ڈاؤن لوڈ اور اجرا کرتا ہے؛ zZ کو ڈیکرپٹ کرنے پر "Run Copilot" نامی GitHub Actions ورک فلو ٹیمپلیٹ بن جاتا ہے، جو ${{ toJSON(secrets) }} کو format-results.txt میں لکھتا ہے اور اسے آرٹیفیکٹ کے طور پر اپ لوڈ کرتا ہے۔ پہلا وسائل بعد کے کاموں کے لیے حاصل/اجرا لینک فراہم کرتا ہے، جبکہ دوسرا GitHub Actions آرٹیفیکٹ کے ذریعے ریپوزیٹری سیکرٹس منتقل کرنے کا ٹیمپلیٹ فراہم کرتا ہے؛ عملی ورک فلو انجیکشن، رن کا انتظار اور آرٹیفیکٹ ڈاؤن لوڈ مین لود میں موجود متعلقہ GitHub API منطق کے ذریعے مکمل ہوتا ہے۔

مرکزی برائی کے بوجھ کی صلاحیت کا تجزیہ

بہت سارے لیولز کی ڈی-اوبسکیویشن کے بعد، نمونہ نہایت طور پر مرکزی بریک ویئر کو ریلیز اور اجرا کرتا ہے۔ درج ذیل تمام تجزیے مرکزی بریک ویئر ماڈیول پر مبنی ہیں، جو ڈیٹا حاصل کرنے، باہر بھیجنا، پھیلانا، مستقل بنانا اور مزاحمت کے پانچ مراحل میں تقسیم کیے گئے ہیں۔

نمونہ میں لینکس، ونڈوز اور میک او ایس کے تین پلیٹ فارمز کے لیے میموری ریڈنگ اسکرپٹس شامل ہیں، جو کراس پلیٹ فارم ڈمپ کی صلاحیت رکھتے ہیں۔ لینکس کی تکنیک مقصد پروسیس کے /proc//maps اور /proc//mem کو پڑھ کر میموری نکالنے کے لیے استعمال ہوتی ہے:

مرکزی برے لوڈ کی فعال ٹریگر منطق GitHub Actions Linux runner کے خلاف ہے: جب GITHUB_ACTIONS === "true" اور RUNNER_OS === "Linux" ہو، تو کوڈ Runner.Worker پروسیس تلاش کرتا ہے اور میموری ڈمپ کرتا ہے، پھر ڈمپ سے "":{"value":"","isSecret":true}" فارمیٹ کے masked secrets استخراج کرتا ہے۔ تینوں نمونوں میں تصدیق شدہ فعال اکٹھا کرنے کے راستے Linux runner پر مرکوز ہیں، لیکن تینوں پلیٹ فارمز کے اسکرپٹس شامل ہیں۔

مرکزی برے مقصد کا بوجھ نظام یافتہ اعتماد کی تفصیلات جمع کرنے والے ماڈیولز پر مشتمل ہے، جو کلاؤڈ فراہم کنندگان، CI ماحول، ڈویلپرز کے مقامی ترتیبات، GitHub CLI، پاسورڈ مینیجرز اور والٹ فائلز کو شامل کرتا ہے۔

بالکل، یہاں ترجمہ ہے: 云厂商凭据采集目标如下：

AWS ماڈیول میں ECS / IMDS (Instance Metadata Service) / STS WebIdentity متعلقہ منطق بھی شamil ہے۔

ڈیولپر کے مقامی اعتماد کے اثبات کو درج ذیل اہداف پر لاگو کیا جاتا ہے:

پاس ورڈ مینیجر منطق کو سورس کوڈ میں runCommand(command, args) ارے کے طور پر لاگو کیا گیا ہے، شیل سٹرنگ کنکیٹینیشن کے بجائے۔

اوپر کے اعتماد کی جمع کاری ماڈیول کلاؤڈ پلیٹ فارم سے لے کر ڈویلپرز کے مقامی نظام تک وسیع مقاصد کو کور کرتا ہے؛ جمع کردہ حساس ڈیٹا درج ذیل مکانیزمز کے ذریعے باہر بھیجا جاتا ہے۔

مرکزی برے مقصد کا بوجھ GitHub API کو بنیادی ڈیٹا بہاؤ کے طور پر استعمال کرتا ہے۔ درخواست کا User-Agent python-requests/2.31.0 کے طور پر جھوٹا ثابت کیا جاتا ہے، اور x-oauth-scopes (جس میں repo، public_repo یا workflow شامل ہو) کی تصدیق کے بعد ڈیٹا بہاؤ کا عمل شروع ہوتا ہے: ریپوزٹری بنائی جاتی ہے (description مسلسل Miasma: The Spreading Blight)، اور چوری شدہ ڈیٹا base64 کوڈنگ کے ذریعے PUT /repos///contents/results/ کے ذریعے لکھا جاتا ہے۔

اس کے علاوہ، لوڈ نے گٹہب کامٹ تلاش کے مبنی ڈیڈ-ڈراپ مکانیزم کو لاگو کیا ہے، جس میں مارکر "thebeautifulmarchoftime" (یا "thebeautifulsnadsoftime") کی تلاش کے ذریعے C2 ہدایات حاصل کی جاتی ہیں:

چلیے نتیجہ = await X9("thebeautifulmarchoftime ", xZ);

Embedded resource YZ.bin ایک مستقل GitHub commit monitor ہے جو 3600 سیکنڈ کے انٹرول پر firedalazer . فارمیٹ کے commit message کو تلاش کرنے کے لیے پول کرتا ہے، اور اس کے بعد سائنیچر کی تصدیق کے بعد ریموٹ Python مواد کو ڈاؤن لوڈ اور اجرا کرتا ہے۔ یہ مرکزی ایکسٹرنل چینل سے الگ ایک مزید کنٹرول لینک بناتا ہے۔

کوڈ میں api.anthropic.com اور v1/api کے اندروں کے لیے ایک HTTP POST sender کنفیگریشن بھی شامل ہے۔ اس کنفیگریشن کا noop فیلڈ true پر سیٹ ہے، جس کا مطلب ہے کہ اگر اسے باہر سے تبدیل نہ کیا جائے تو یہ sender کوئی اصل نیٹ ورک درخواست نہیں بھیجے گا۔ اس لیے سٹیٹک تجزیہ صرف اس کوڈ کی ساخت کی تصدیق کر سکتا ہے، لیکن Anthropic API کے فعال بیرونی ارسال کے وجود کو ثابت نہیں کر سکتا۔

مرکزی برے مقصد کا بوجھ GitHub REST / GraphQL API کے ذریعے ریپوزٹری کے git آبجیکٹس کو آپریٹ کر سکتا ہے:

حمل کو "release" کے نام سے ایک بری ورک فلو کے طور پر تعمیر کیا گیا ہے، جو id-token: write اجازت کا درخواست کرتا ہے اور OIDC (OpenID Connect) کے ذریعے npm ریلیز ٹوکن حاصل کرتا ہے۔ OIDC راستہ کے لیے ماحولیاتی متغیر اور ایپی آئی ACTIONS_ID_TOKEN_REQUEST_TOKEN، ACTIONS_ID_TOKEN_REQUEST_URL ہیں، جبکہ audience کو npm:registry.npmjs.org سیٹ کیا گیا ہے۔ سورس کوڈ کے سطح پر تصدیق ہوتی ہے کہ پیلود GitHub ریپوزٹری میں ورک فلو داخل کرنے اور OIDC / npm ٹرسٹڈ پبلشنگ کے ذریعے ریلیز اجازت حاصل کرنے کی صلاحیت رکھتا ہے۔

اس کے علاوہ، جہاں git refs کے ذریعے workflow کو انجکٹ کیا جاتا ہے، پیغام میں ایک زیادہ چھپا ہوا راز کی منتقلی کا طریقہ بھی شامل ہے: Run Copilot کے نام سے دھوکہ دینے والے GitHub Actions workflow نے ${{ toJSON(secrets) }} کو format-results.txt میں لکھا اور artifact اپ لوڈ کیا۔ راز کو براہ راست ریپوزٹری کے مواد میں لکھنے کے بجائے، یہ طریقہ workflow کے انجام کے نتائج کے ذریعے ڈیٹا منتقل کرنے پر زور دیتا ہے، جس کی وجہ سے عام کوڈ diff جانچ میں حتمی برآمد شدہ رازوں کا مواد براہ راست نظر نہیں آتا۔

ایم بیڈڈ ریسورس zZ.bin، جو کہ Copilot کے گٹھبیک ایکشن ورک فلو کے طور پر چھپا ہوا ہے، ${{ toJSON(secrets) }} کو format-results.txt میں لکھتا ہے اور اسے آرٹی فیکٹ کے طور پر اپ لوڈ کرتا ہے۔

متعلقہ GitHub API کی سرگرمیاں ہیں: عارضی برانچ بنانا/اپڈیٹ کرنا → ورک فلو بلاب لکھنا → ورک فلو رن کا انتظار کرنا → آرٹی فیکٹ زِپ ڈاؤن لوڈ کرنا → format-results.txt پڑھنا → ورک فلو رن اور عارضی برانچ حذف کرنا۔ متعلقہ ہنٹنگ کلیدی الفاظ میں Run Copilot، VARIABLE_STORE، format-results، chore/add-codeql-static-analysis، .github/workflows/codeql.yml شامل ہیں۔

مرکزی برے کوڈ کے دو الگ الگ npm جاری کرنے یا پھیلانے کے راستے ہیں۔

npm ٹوکن کا راستہ: GET /-/npm/v1/tokens کے ذریعے موجودہ صارف کے npm ٹوکنز کی فہرست بنائیں، جن میں bypass_2fa === true ہو اور پیکیج لکھنے کا اجازت نامہ ہو، ان ٹوکنز کا استعمال کرکے خودکار اشاعت کریں۔ bypass_2fa ٹوکن میٹاڈیٹا فیلڈ ہے، نہ کہ publish بادی پیرامیٹر۔

GitHub Actions OIDC پاتھ: حملہ ACTIONS_ID_TOKEN_REQUEST_TOKEN اور ACTIONS_ID_TOKEN_REQUEST_URL ماحولیاتی متغیرات کو پڑھتا ہے، audience کے طور پر npm:registry.npmjs.org کے لیے OIDC ٹوکن درخواست کرتا ہے، اور npm OIDC ٹوکن ایکسچینج ایپی کے ذریعے اشاعت کے اختیارات حاصل کرتا ہے۔

ملوث ہونے والے tarball کے لیے عمل درآمد: انبیل کریں → برے index.js کو لکھیں → package.json میں تبدیلی کریں:

یہاں دو قسم کے انٹری پوائنٹس کو الگ کیا جاتا ہے: تین مقامی اپ لوڈ کیے گئے نمونوں کے اپنے استعمال کے لیے preinstall: "node index.js" —— اس صورت میں انسٹالیشن کے ماحول میں Bun کی پہلے سے ضرورت نہیں ہوتی، اور Node.js کو شروعاتی انٹری پوائنٹ کے طور پر استعمال کرنا زیادہ چھپا ہوا ہوتا ہے؛ جب خود پھیلنے والے آلودگی کے ذریعے دوسرے پیکجز کو آلودہ کیا جاتا ہے تو preinstall: "bun run index.js" لکھا جاتا ہے اور bun کا ڈیپینڈنس شامل کیا جاتا ہے —— کیونکہ بنیادی بری خطرے کے بعد کے منطق کو Bun رن ٹائم کی فراہم کردہ API (جیسے Bun.gunzipSync اور Bun.file) پر انحصار ہوتا ہے، اور خود پھیلنے والے منظر میں یقینی بنانا ضروری ہے کہ مقصد کا ماحول Bun موجود ہو۔

مرکزی برے مقصد کا بوجھ چار طریقوں سے مستقل رہتا ہے، جو منصوبہ ڈائرکٹری اور سسٹم لیول آٹو اسٹارٹ کو کور کرتے ہیں۔

Claude Code سیشن شروع ہونے کا ہُک: S8.bin ریسورس کو .claude/settings.json میں ڈال دیا جائے گا، جس سے ہر Claude Code سیشن شروع ہونے پر خودکار طور پر node .claude/setup.mjs نفاذ ہوگا۔ برے مقاصد کے لیے مالویئر کو .claude/setup.mjs اور .claude/index.js دونوں میں ڈال دیا جائے گا (راستہ ".claude/" + M0 کو جوڑ کر بنایا جاتا ہے، M0 = "index.js")۔

VS Code folderOpen کام: ایم بیڈڈ ریسورس EZ.bin کو folderOpen کام کو .vscode/tasks.json میں لکھیں، جب متاثرہ پروجیکٹ فولڈر کھولا جائے تو ایک ہی اسکرپٹ خودکار طور پر انجام دیا جائے۔ ساتھ ہی .vscode/setup.mjs میں لکھیں۔

kitty-monitor (systemd / LaunchAgent): RZ.bin کو ایمبیڈ کرکے پائیدار سروس انسٹال کرتا ہے، فائلیں /.local/share/kitty/cat.py، /.config/systemd/user/kitty-monitor.service (Linux) اور ~/Library/LaunchAgents/com.user.kitty-monitor.plist (macOS) پر تقسیم ہیں۔ میلیشس پیلود /tmp/kitty- ڈائرکٹری بناتا ہے، YZ.bin (GitHub commit monitor) کو cat.py میں لکھتا ہے اور اس کے بعد RZ.bin کے ذریعے انسٹال کرتا ہے۔

gh-token-monitor (systemd / LaunchAgent): جیٹی ایچ ایف جیٹن مانیٹر سروس کو نصب کرنے کے لیے jZ.bin وسائل کا استعمال کیا جاتا ہے، فائلیں /.local/bin/gh-token-monitor.sh، /.config/gh-token-monitor/ ڈائرکٹریز اور متعلقہ systemd / LaunchAgent راستوں پر تقسیم کی گئی ہیں۔ یہ مانیٹر یہ جانچتا ہے کہ کیا GitHub جیٹن 40x اسٹیٹس کوڈ واپس کرتا ہے اور npm پیکج @cap-js/openapi@1.4.1 کے میٹا ڈیٹا میں کوئی غیر معمولی بات ہے یا نہیں، اور اس صورت میں ہینڈلر چلائے جائے گا:

اس کا مطلب یہ ہے کہ جب monitor کو GitHub API سے 40x اسٹیٹس کوڈ ملتا ہے، جیسے کہ token منسوخ، بے کار یا اجازت کی حالت غیر معمولی ہو، تو برے نیت والے اسکرپٹ داخل کیے گئے handler کو نفاذ کرتا ہے۔ اس مضمون میں دیے گئے تین نمونوں سے حاصل کیا گیا handler rm -rf ~/; rm -rf ~/Documents ہے۔ جب ٹریٹمنٹ کر رہے ہوں تو، جہاں ابھی تک payload چل رہا ہو، وہاں فوراً token منسوخ نہ کریں—بجائے اس کے پہلے ہوسٹ کو علیحدہ کریں، مستقل عناصر اور چل رہے پروسیسز صاف کریں، اور پھر صاف ماحول سے اعتماد کی تفصیلات تبدیل کریں۔

مرکزی برے مقصد کا بوجھ StepSecurity Harden-Runner کے لیے تشخیص اور تباہ کرنے کا منطق شامل ہے، جو CI/CD حفاظت کو درج ذیل مراحل سے دور کرتا ہے:

1. ڈاکر سوکٹ /var/run/docker.sock کی دستیابی کی جانچ کریں؛
2. ڈاکر کنٹینرز کو فہرست کریں، جن کے نام یا ایمیج میں harden-runner / stepsecurity کی کلیدی الفاظ ملتی ہوں؛
3. POST /containers//kill کے ذریعے مطابقت رکھنے والے کنٹینر کو ختم کریں؛
4. ایک پرiviliged alpine کنٹینر بنائیں، جس میں sudoers کو runner ALL=(ALL) NOPASSWD:ALL کے طور پر لکھا جائے؛
5. /etc/hosts میں StepSecurity متعلقہ ڈومین کے لیے غلط ریکارڈ لکھیں؛
6. /etc/resolv.conf کو 8.8.8.8 اور 1.1.1.1 کے ساتھ اووررائیٹ کریں۔

یہ مزاحمتی منطق ظاہر کرتا ہے کہ نمونہ StepSecurity سے محفوظ CI/CD ماحول کے لیے خاص طور پر ڈھالا گیا ہے۔

مرکزی برائی میں بھیجا گیا مواد EDR (EndPoint Detection and Response) / سیکورٹی پروڈکٹس کے پروسیس نام اور انسٹالیشن پاتھ کو ڈیٹیکٹ کرتا ہے:

لوڈ میں علاقائی نظراندازی منطق بھی شامل ہے: LC_ALL، LC_MESSAGES، LANGUAGE، LANG ماحولیاتی متغیرات کو چیک کیا جاتا ہے، اگر انہیں چھوٹے حروف میں تبدیل کرنے کے بعد ru سے شروع ہوتا ہے تو اجراء کو نظرانداز کر دیا جاتا ہے۔ CI ماحول کی شناخت GitHub Actions، GitLab CI، Travis CI، CircleCI، Jenkins، AWS CodeBuild، Buildkite، AppVeyor، Bitbucket، Drone، TeamCity، Cirrus CI وغیرہ کے لیے حمایت کرتی ہے۔ رن ٹائم پر استعمال ہونے والے اسٹیٹ مارکرز میں tmp.0987654321.lock، __IS_DAEMON (منفصل ڈیمون سب پروسیس کو نشان زد کرتا ہے)، SKIP_DOMAIN (ڈومین سینڈر پاتھ کو نظرانداز کرتا ہے)، /tmp/kitty-*, cat.py اور /var/tmp/.gh_update_state شامل ہیں۔

امپیکٹ اینالسیس

سورس کوڈ کی صلاحیت کے لحاظ سے، ان تین نمونوں کا اثر صرف npm انسٹالیشن کے مرحلے تک محدود نہیں ہے۔ ان کا اصل خطرہ چار درجات میں تقسیم کیا جا سکتا ہے:

ڈویلپر ہوسٹ لیول۔ نمونہ ماحولیاتی متغیر، .npmrc، .pypirc، SSH کلید، ڈوکر ترتیب، .env، گٹہب CLI ٹوکن، پاسورڈ مینیجر ڈیٹا اور والٹ فائلز کو جمع کرے گا اور Claude Code، VS Code، systemd یوزر سروس یا macOS LaunchAgent کے ذریعے بعد میں ٹرگر کرنے کی صلاحیت برقرار رکھے گا۔

CI/CD رنر لیول پر۔ نمونہ GitHub Actions لینکس رنر کو شناخت کرتا ہے، Runner.Worker پروسیس کی میموری پڑھتا ہے اور ماسک کردہ سیکرٹس نکالتا ہے؛ ساتھ ہی StepSecurity Harden-Runner کے خلاف منطق بھی رکھتا ہے، جو CI/CD تحفظ کے عناصر کو خراب یا دور کرنے کی کوشش کرتا ہے۔

گٹہب اور ریپوزیٹری کے سطح پر۔ نمونہ گٹہب API کا استعمال کرکے ریپوزیٹری بناسکتا ہے، contents/results/ میں لکھ سکتا ہے، git refs/blobs/trees/commits کو آپریٹ کر سکتا ہے، بریان ورکفلو کو انجیکٹ کر سکتا ہے، اور Run Copilot workflow + artifact کے ذریعے سیکرٹس منتقل کر سکتا ہے۔

npm ایکوسسٹم کے پھیلاؤ کے لیے۔ نمونہ کو package write اجازت والے اور bypass_2fa === true والے npm ٹوکن کے ساتھ فلٹر کیا جا سکتا ہے، یا GitHub Actions OIDC / npm trusted publishing کے ذریعے اشاعت کی اجازت حاصل کی جا سکتی ہے؛ اس کے بعد مقصد tarball ڈاؤن لوڈ کیا جاتا ہے، مضر loader شامل کیا جاتا ہے، preinstall میں تبدیلی کی جاتی ہے، Bun ڈیپینڈنسی شامل کی جاتی ہے، پیچ ورژن بڑھایا جاتا ہے اور اشاعت کی جاتی ہے، جس سے npm کا خود بخود پھیلنے والا سلسلہ تشکیل پاتا ہے۔

خلاصہ

تین نمونوں کے سورس کوڈ کے ثبوت سے ظاہر ہوتا ہے کہ یہ مضر پیکج صرف انسٹالیشن کے دوران ڈیٹا چوری کرنے والا اسکرپٹ نہیں بلکہ ایک متعدد مراحل والا لودر اور مکمل امپلینٹ کا مجموعہ ہے: باہری لیئر پیکج کے مطابق رینڈمائزڈ ہے، Bun رن ٹائم گائیڈر اور مرکزی مضر لود میں ایک جیسا ہے؛ مرکزی امپلینٹ کرڈنٹلز کی جمع کاری، CI سیکرٹس کی نکالی، GitHub / npm پر پھیلانا، مستقل رہنے اور تحفظ کے خلاف لڑائی جیسے متعدد مراحل کو کور کرتا ہے۔

اچھی طرح سے چھپائی گئی داخلی ڈیزائن۔ حملہ آور اپنے برآمد کوڈ میں برے منطق نہیں ڈالتا، بلکہ npm زندگی کے اسکرپٹس میں ایک اجنبی لوڈر لگاتا ہے۔ یہ لوڈر خود اس وقت اصل طاقت کو تلاش کرنا مشکل بناتا ہے جب صرف برآمد سورس کوڈ کا جائزہ لیا جائے، کیونکہ یہ اندرونی بوجھ کو ڈی کرپٹ کرکے اجرا کرتا ہے۔

متعدد لیyers کی ڈی-اوبفوسکیٹنگ چین۔ میلیشس پیلوڈ کو ڈیجیٹل ارے + ROT حروف تبدیلی، AES-128-GCM اینکرپشن، obfuscator.io اوبفوسکیشن، B5 خود ساز سٹرنگ اینکرپشن، اور AES-256-GCM + gzip ام بیڈڈ لیئر کے پانچ لیyers میں پیک کیا گیا ہے۔ ہر لیئر کا کلید یا پیرامیٹر مختلف پیکجز میں الگ الگ تبدیل ہو سکتا ہے، جس سے سٹیٹک فیچرز کے بنیاد پر بڑے پیمانے پر ڈیٹیکشن مشکل ہو جاتا ہے۔

مکمل تنظیمی سطح کے حملے کی صلاحیت۔ یہ امپلینٹ GitHub Actions Runner کی میموری پڑھنے، متعدد ابر اور مقامی اعتمادیات جمع کرنے، GitHub API کے ذریعے ڈیٹا باہر بھیجنا اور ڈیڈ-ڈراپ، GitHub ریپوزٹریز اور ورکفلو کو انفیکٹ کرنے، npm کے ذریعے خود کو پھیلانے، مستقل رہنے اور تحفظ کے خلاف لڑنے جیسی صلاحیتیں رکھتا ہے۔ سورس کوڈ کی ساخت سے ظاہر ہوتا ہے کہ اس میں ایک نقطہ پر انسٹال کرنے سے ریپوزٹری، CI/CD اور npm ریلیز چین تک پھیلنے کے لیے کوڈ کا راستہ شامل ہے؛ حقیقی پھیلاؤ کا دائرہ انسٹال لاج، ریپوزٹری آڈٹ اور پلیٹ فارم کی ٹیلی میٹری کے ساتھ ملا کر تصدیق کی جانی چاہئے۔

سورس کوڈ کے ثبوت سے یہ تصدیق ہوتی ہے کہ تینوں نمونے preinstall کے ذریعے خودکار طور پر فعال ہوئے اور ایک ہی بنیادی implant کو ڈی کرپٹ اور اجراء کیا۔ تاہم، حقیقی واقعے میں ابتدائی دسترس حاصل کرنے کا طریقہ صرف ان تین tgz نمونوں سے ثابت نہیں کیا جا سکتا۔

تجزیہ کی تجاویز

1. منصوبہ کی انحصار، لॉک فائل، نجی رجسٹری کی کیش اور بِلڈ کیش میں نقصان دہ ورژن کو تلاش کریں اور ختم کریں۔
2. انسٹالیشن لاگ میں کیا preinstall، node index.js، bun run، /tmp/p*.js، tmp.0987654321.lock ظاہر ہو رہے ہیں؟
3. ابھی بھی پیلود چل رہا ہو تو شکایت کنندہ ہوسٹ پر ٹوکن منسوخ نہ کریں۔ تجویز یہ ہے کہ شکایت کنندہ ہوسٹ کو علیحدہ کریں، چلنے والے پروسیسز اور پرسسٹنٹ آئٹمز کو صاف کریں، اور پھر صاف ماحول سے گٹھبیج، npm، کلاؤڈ اعتماد، کیوبرنیٹس، وولٹ، ایس ایچ ایس، ڈاکر رجسٹری، اور پاسورڈ مینیجر سے متعلق ٹوکنز کو تبدیل کریں۔
4. گٹہب ریپوزیٹری کے حالیہ برانچ، کامٹ، ورک فلو، آرٹیفیکٹ اور نئے ریپوزیٹری کی جانچ کریں، خاص طور پر Run Copilot، format-results، chore/add-codeql-static-analysis، .github/workflows/codeql.yml، OIDC_PACKAGES جیسے کلیدی الفاظ پر توجہ دیں۔
5. پروجیکٹ ڈائریکٹری میں کوئی نیا فائل شامل ہوئی ہے یا تبدیلی ہوئی ہے: .claude/settings.json، .claude/setup.mjs، .vscode/tasks.json، .vscode/setup.mjs۔
6. صارف کی سطح پر پائیداری کی جانچ کریں: /.local/share/kitty/cat.py، /.config/systemd/user/kitty-monitor.service، ~/Library/LaunchAgents/com.user.kitty-monitor.plist، gh-token-monitor متعلقہ فائلیں۔
7. npm پبلش ہسٹری کی جانچ کریں اور غیر مجاز پیچ ورژن کی اشاعت کی تصدیق کریں؛ اس کے علاوہ npm ٹوکن میٹا ڈیٹا کا جائزہ لیں، خاص طور پر 2FA (ٹو فیکٹر اتھنٹیکیشن) کو بائی پاس کرنے والے اور پیکیج لکھنے کے اختیارات رکھنے والے ٹوکن پر توجہ دیں۔
8. آلودہ ماحول میں تعمیر کردہ ڈاؤن اسٹریم پروڈکٹس کی مکملیت کی جانچ کریں۔

IOC

مضر فائل

فائل کا نام: redhat-cloud-services-frontend-components-config-6.11.3.tgz MD5: 633ad8849a59e2bfb7a0fe589e816a07 SHA1: 675294612f455fe6a9acb195f0cbe3687d8e2e34 SHA256: 0c9c67ec40d5f23efa1ec3470d0ac88b4993ccc0e92be913fc29a337dfc4f060

فائل کا نام: redhat-cloud-services-types-3.6.1.tgz MD5: 9e6c5af01438b52c9a411686c1f1b8ff SHA1: 88d098c8d96e9ae17550e9798c3b62c420464b8c SHA256: d543bb3cdf1569c2b3d38c8a4081ed746cfe78bf3236c2302704d79ab7fa9558

فائل کا نام: redhat-cloud-services-rule-components-4.7.2.tgz MD5: f1ffdbf5e639899f26a6ebab2eec408d SHA1: f3c5c21274045ae02fef11e931de6dcf8462a067 SHA256: aaf00d06baa3c679b82452c50014e9824b8874e9ca2d150f19095f8de19ba90f

SHA256

ac2a2208e1726e008be6c73dc0872d9bba163319259dff1b62055ac933ca46b6

0dc06ecdaa63fe24859cfd955053c23245c536e4733480239d14bebf12688e35

مالیاتی انحصار

npm:@redhat-cloud-services/topological-inventory-client@3.0.10

npm:@redhat-cloud-services/topological-inventory-client@3.0.11

npm:@redhat-cloud-services/topological-inventory-client@3.0.13

npm:@redhat-cloud-services/compliance-client@4.0.3

npm:@redhat-cloud-services/compliance-client@4.0.4

npm:@redhat-cloud-services/compliance-client@4.0.6

npm:@redhat-cloud-services/rbac-client@9.0.3

npm:@redhat-cloud-services/rbac-client@9.0.4

npm:@redhat-cloud-services/rbac-client@9.0.6

npm:@redhat-cloud-services/insights-client@4.0.4

npm:@redhat-cloud-services/insights-client@4.0.5

npm:@redhat-cloud-services/insights-client@4.0.7

npm:@redhat-cloud-services/frontend-components@7.7.2

npm:@redhat-cloud-services/frontend-components@7.7.3

npm:@redhat-cloud-services/frontend-components@7.7.5

npm:@redhat-cloud-services/frontend-components-utilities@7.4.1

npm:@redhat-cloud-services/frontend-components-utilities@7.4.2

npm:@redhat-cloud-services/frontend-components-utilities@7.4.4

npm:@redhat-cloud-services/remediations-client@4.0.4

npm:@redhat-cloud-services/remediations-client@4.0.5

npm:@redhat-cloud-services/remediations-client@4.0.7

npm:@redhat-cloud-services/frontend-components-notifications@6.9.2

npm:@redhat-cloud-services/frontend-components-notifications@6.9.3

npm:@redhat-cloud-services/frontend-components-notifications@6.9.5

npm:@redhat-cloud-services/patch-client@4.0.4

npm:@redhat-cloud-services/patch-client@4.0.5

npm:@redhat-cloud-services/patch-client@4.0.7

npm:@redhat-cloud-services/host-inventory-client@5.0.3

npm:@redhat-cloud-services/host-inventory-client@5.0.4

npm:@redhat-cloud-services/host-inventory-client@5.0.6

npm:@redhat-cloud-services/rule-components@4.7.2

npm:@redhat-cloud-services/rule-components@4.7.3

npm:@redhat-cloud-services/rule-components@4.7.5

npm:@redhat-cloud-services/frontend-components-advisor-components@3.8.2

npm:@redhat-cloud-services/frontend-components-advisor-components@3.8.4

npm:@redhat-cloud-services/frontend-components-advisor-components@3.8.6

npm:@redhat-cloud-services/notifications-client@6.1.4

npm:@redhat-cloud-services/notifications-client@6.1.5

npm:@redhat-cloud-services/notifications-client@6.1.7

npm:@redhat-cloud-services/sources-client@3.0.10

npm:@redhat-cloud-services/sources-client@3.0.11

npm:@redhat-cloud-services/sources-client@3.0.13

npm:@redhat-cloud-services/integrations-client@6.0.4

npm:@redhat-cloud-services/integrations-client@6.0.5

npm:@redhat-cloud-services/integrations-client@6.0.7

npm:@redhat-cloud-services/frontend-components-config@6.11.3

npm:@redhat-cloud-services/frontend-components-config@6.11.4

npm:@redhat-cloud-services/frontend-components-config@6.11.6

npm:@redhat-cloud-services/frontend-components-config-utilities@4.11.2

npm:@redhat-cloud-services/frontend-components-config-utilities@4.11.3

npm:@redhat-cloud-services/frontend-components-config-utilities@4.11.5

npm:@redhat-cloud-services/hcc-pf-mcp@0.6.1

npm:@redhat-cloud-services/hcc-pf-mcp@0.6.2

npm:@redhat-cloud-services/hcc-pf-mcp@0.6.4

npm:@redhat-cloud-services/frontend-components-remediations@4.9.2

npm:@redhat-cloud-services/frontend-components-remediations@4.9.3

npm:@redhat-cloud-services/frontend-components-remediations@4.9.5

npm:@redhat-cloud-services/eslint-config-redhat-cloud-services@3.2.1

npm:@redhat-cloud-services/eslint-config-redhat-cloud-services@3.2.2

npm:@redhat-cloud-services/eslint-config-redhat-cloud-services@3.2.4

npm:@redhat-cloud-services/javascript-clients-shared@2.0.8

npm:@redhat-cloud-services/javascript-clients-shared@2.0.9

npm:@redhat-cloud-services/javascript-clients-shared@2.0.11

npm:@redhat-cloud-services/quickstarts-client@4.0.11

npm:@redhat-cloud-services/quickstarts-client@4.0.12

npm:@redhat-cloud-services/quickstarts-client@4.0.14

npm:@redhat-cloud-services/config-manager-client@5.0.4

npm:@redhat-cloud-services/config-manager-client@5.0.5

npm:@redhat-cloud-services/config-manager-client@5.0.7

npm:@redhat-cloud-services/hcc-feo-mcp@0.3.1

npm:@redhat-cloud-services/hcc-feo-mcp@0.3.2

npm:@redhat-cloud-services/hcc-feo-mcp@0.3.4

npm:@redhat-cloud-services/entitlements-client@4.0.11

npm:@redhat-cloud-services/entitlements-client@4.0.12

npm:@redhat-cloud-services/entitlements-client@4.0.14

npm:@redhat-cloud-services/tsc-transform-imports@1.2.2

npm:@redhat-cloud-services/tsc-transform-imports@1.2.4

npm:@redhat-cloud-services/tsc-transform-imports@1.2.6

npm:@redhat-cloud-services/hcc-kessel-mcp@0.3.1

npm:@redhat-cloud-services/hcc-kessel-mcp@0.3.2

npm:@redhat-cloud-services/hcc-kessel-mcp@0.3.4

npm:@redhat-cloud-services/frontend-components-testing@1.2.1

npm:@redhat-cloud-services/frontend-components-testing@1.2.2

npm:@redhat-cloud-services/frontend-components-testing@1.2.4

npm:@redhat-cloud-services/types@3.6.1

npm:@redhat-cloud-services/types@3.6.2

npm:@redhat-cloud-services/types@3.6.4

npm:@redhat-cloud-services/chrome@2.3.1

npm:@redhat-cloud-services/chrome@2.3.2

npm:@redhat-cloud-services/chrome@2.3.4

npm:@redhat-cloud-services/frontend-components-translations@4.4.1

npm:@redhat-cloud-services/frontend-components-translations@4.4.2

npm:@redhat-cloud-services/frontend-components-translations@4.4.4

npm:@redhat-cloud-services/vulnerabilities-client@2.1.8

npm:@redhat-cloud-services/vulnerabilities-client@2.1.9

npm:@redhat-cloud-services/vulnerabilities-client@2.1.11