पृष्ठभूमि

हाल ही में, MistEye सुरक्षा मॉनिटरिंग सिस्टम ने Red Hat Cloud Services संगठन के अंतर्गत कई npm पैकेज में असामान्य संस्करणों के बारे में सूचना प्राप्त की। इस घटना में कुल 32 npm पैकेज और 96 संस्करण शामिल हैं। इस लेख में, हमने इनमें से 3 स्थानीय नमूनों का गहन ऑफलाइन विश्लेषण किया है: ये नमूने छलावरण नामांकन या typo-squatting पैकेज नहीं हैं, बल्कि @redhat-cloud-services स्कोप के वास्तविक पैकेज संस्करण हैं; नमूने के स्रोत कोड से पुष्टि होती है कि उनके tarball में एक बहु-स्तरीय भ्रमित किया गया मैलवेयर लोडर घुसाया गया है, जो स्थापना चरण में स्वचालित रूप से ट्रिगर होता है।

पूर्ण रूप से पुनर्स्थापित करने के बाद पुष्टि की जा सकती है: इन 3 नमूनों का मुख्य भार GitHub Actions Runner की मेमोरी पढ़ने, बहु-बादल और स्थानीय पारित्रों का संग्रह, GitHub API के माध्यम से डेटा बाहर भेजना और डेड-ड्रॉप, GitHub workflow में संक्रमण, npm के माध्यम से स्वयं प्रसार, Claude Code / VS Code / systemd / LaunchAgent के माध्यम से स्थायीकरण, Harden-Runner / StepSecurity के खिलाफ प्रतिरोध, EDR / सुरक्षा उत्पादों की पहचान आदि स्रोत क्षमताएँ रखता है। क्षमता के दायरे के आधार पर, संभावित प्रभावित पक्षों में विकासक होस्ट, CI/CD Runner, बिल्ड कंटेनर, GitHub रिपॉजिटरी, GitHub Actions workflow, npm प्रकाशन लंबी श्रृंखला और बादल परिवेश पारित्र शामिल हैं; वास्तविक प्रभाव के दायरे की पुष्टि के लिए स्थापना लॉग, रिपॉजिटरी ऑडिट और प्लेटफॉर्म-स्तरीय टेलीमेट्री को मिलाकर देखना आवश्यक है।

कोड संरचना, प्रसार पथ और क्षमता संयोजन के आधार पर, यह दुष्ट सॉफ्टवेयर Shai-Hulud दुष्ट सॉफ्टवेयर का एक वेरिएंट है।

MistEye प्रतिक्रिया

MistEye, SlowMist द्वारा स्वयं विकसित एक Web3 खतरा सूचना और वास्तविक समय सुरक्षा मॉनिटरिंग सिस्टम है, जो सुरक्षा मॉनिटरिंग और सूचना संग्रह क्षमताओं को एकीकृत करता है और उपयोगकर्ताओं को वास्तविक समय में जोखिम चेतावनी और संपत्ति संरक्षण प्रदान करता है।

Red Hat Cloud Services npm पैकेज सप्लाई चेन जहरीला होने की घटना और इससे संबंधित दुर्भावनापूर्ण नमूनों को पकड़ने के बाद, MistEye सिस्टम ने इस हमला श्रृंखला की भ्रमित संरचना, लोड डिक्रिप्शन, क्षमता पुनर्स्थापना और IOC का व्यवस्थित विश्लेषण किया है।

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

Attack Chain Overview

इस लेख का तकनीकी विश्लेषण केवल स्थानीय ऑफलाइन स्टैटिक विश्लेषण पर आधारित है, जिसमें 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 key/iv/tag का उपयोग करते हैं; इससे बाहरी पैकेजिंग हैश, फिक्स्ड key या फिक्स्ड shift के आधार पर स्टैटिक फीचर्स को सीधे पैकेज के बीच पुनः उपयोग करना कठिन हो जाता है। लेकिन डिक्रिप्ट किए गए Bun रनटाइम बूटस्ट्रैपर और कोर मैलिशियस पेलोड का हैश पूरी तरह समान है: एक Bun रनटाइम वातावरण को तैयार करने के लिए बूटस्ट्रैप सहायक मॉड्यूल है, और दूसरा वास्तविक रूप से मैलिशियस कार्यों को समाहित करने वाला कोर पेलोड है। इस लेख में, हम इन्हें क्रमशः "Bun रनटाइम बूटस्ट्रैपर (स्रोत कोड वेरिएबल _b)" और "कोर मैलिशियस पेलोड (स्रोत कोड वेरिएबल _p)" कहते हैं।

पुनर्स्थापित हमला श्रृंखला निम्नलिखित है:

Technical Analysis

1. एंट्री: npm लाइफसाइकल स्क्रिप्ट हाइजैकिंग

तीनों नमूने package.json के preinstall लाइफसाइकिल हुक के माध्यम से हमला श्रृंखला को ट्रिगर करते हैं:

"स्क्रिप्ट्स": {

"preinstall": "node index.js"

}

preinstall npm इंस्टॉल स्टेज के दौरान स्वचालित रूप से निष्पादित होगा। सामान्य फ्रंटएंड कंपोनेंट्स, टाइप डिफिनिशन्स या रूल कंपोनेंट पैकेज के लिए, इंस्टॉल स्टेज में आमतौर पर रूट डायरेक्टरी में एक बड़ा JavaScript फ़ाइल नहीं चलाया जाता; यह सबसे सीधा असामान्य संकेत है।

नमूना स्तर के साक्ष्य निम्नलिखित हैं:

@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

मुख्य: 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 क्षेत्र सेट नहीं किया गया है, इसलिए इस असामान्यता को सभी नमूनों पर लागू नहीं किया जा सकता।

2. पहला स्तर: संख्या अनुक्रम + ROT/सीजर अक्षर प्रतिस्थापन

तीनों नमूनों के रूट डायरेक्टरी में index.js एक बहुत बड़ा एकल-पंक्ति JavaScript फ़ाइल है, जिसकी संरचना समान है और मुख्य भाग 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

3. द्वितीय स्तर: AES-128-GCM द्वारा Bun बूटस्ट्रैपर और मुख्य लोड को डिक्रिप्ट करें

ROT/Caesar डिकोड किए गए Stage 2 कोड का उपयोग Node.js crypto.createDecipheriv के माध्यम से AES-128-GCM (एडवांस्ड एन्क्रिप्शन स्टैंडर्ड - गैलोइस/काउंटर मोड) डिक्रिप्शन के लिए किया जाता है और 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 को कॉल करके मुख्य दुष्ट लोड को निष्पादित करता है।

4. तीसरा स्तर: obfuscator.io स्ट्रिंग टेबल

डिक्रिप्ट किए गए मूल दुष्ट भार वास्तव में सीधे पढ़े जा सकने वाला स्पष्ट JavaScript नहीं है, बल्कि obfuscator.io शैली के स्ट्रिंग टेबल ओब्फुस्केशन से गुजरता है। इस स्तर पर बड़ी संख्या में स्ट्रिंग्स को एक ऐरे में संग्रहीत किया जाता है, और रनटाइम इंडेक्स और रोटेशन लॉजिक के माध्यम से पुनः स्थापित किया जाता है, जिससे विश्लेषकों को स्ट्रिंग टेबल को पुनः स्थापित किए बिना बाद के महत्वपूर्ण API, पथ और कॉन्फ़िगरेशन नामों को सीधे खोजना संभव नहीं होता।

5. चौथा स्तर: B5 कस्टम स्ट्रिंग एन्क्रिप्शन

obfuscator.io स्ट्रिंग टेबल को रिस्टोर करने के बाद, मूल दुष्ट लोड में अभी भी एक B5 कस्टम स्ट्रिंग एन्क्रिप्शन है। पैरामीटर्स की पुष्टि की गई है:

KDF: PBKDF2 (Password-Based Key Derivation Function 2)
हैश फंक्शन: SHA-256
इटरेशन की संख्या: 200000
कुंजी लंबाई: 32 बाइट
डिक्रिप्शन राउंड्स: 3
पासवर्ड: ba2c6ddb3672bdd6a611e6850b4f700b52aed3dab2f1b3d5f8c839d4a157a709
salt: 5b26508dc0f1075a7c0b4d8aa464487e

डिक्रिप्ट करने के बाद परिणाम निम्नलिखित है:

इसमें, B5 के डिक्रिप्ट करने के बाद कई प्रकार की महत्वपूर्ण स्पष्ट पाठ स्ट्रिंग्स दिखाई देती हैं। ध्यान दें कि कुछ स्ट्रिंग्स मूल रूप से obfuscator.io स्ट्रिंग टेबल में स्थित थीं, और केवल "स्ट्रिंग टेबल प्रतिस्थापन + B5 डिक्रिप्शन" दोनों चरणों को पूरा करने के बाद ही इन्हें सीधे grep किया जा सकता है:

6. अतिरिक्त एम्बेडेड लेयर: AES-256-GCM + gzip

कोर मैलिशियस पेलोड के अंदर AES-256-GCM एन्क्रिप्टेड और gzip संपीड़ित एम्बेडेड रिसोर्सेज शामिल हैं। पुनर्स्थापन तर्क उपयोग करता है:

कुंजी एम्बेडेड संसाधनों को फ़ंक्शन के आधार पर तीन श्रेणियों में विभाजित किया गया है:

क्रॉस-प्लेटफॉर्म मेमोरी रीडिंग:

इस प्रकार के संसाधनों का उपयोग चल रही प्रक्रियाओं की मेमोरी पढ़ने के लिए किया जाता है। सामान्य फाइलों में कुंजियाँ और टोकन फाइल जाँच के माध्यम से पता लगाए जा सकते हैं, लेकिन CI/CD रनर या विकास उपकरण चलने के दौरान कुछ संवेदनशील मानों को मेमोरी में अस्थायी रूप से संग्रहित करते हैं। हमलावर Linux, Windows और macOS तीनों प्लेटफॉर्म के लिए मेमोरी पढ़ने के स्क्रिप्ट एम्बेड करते हैं, ताकि विभिन्न सिस्टम पर प्रक्रिया मेमोरी से इन अस्थायी रूप से प्रकट होने वाले सीक्रेट्स को प्राप्त किया जा सके।

पर्सिस्टेंट कॉन्फ़िगरेशन:

इस प्रकार के संसाधनों का उपयोग “बैकडoor ट्रिगर पॉइंट” छोड़ने के लिए किया जाता है। अर्थात, यद्यपि मूल npm स्थापना प्रक्रिया समाप्त हो चुकी है, आक्रमक अभी भी चाहते हैं कि दुष्ट कोड विकासक द्वारा भविष्य में प्रोजेक्ट खोलने, संपादक शुरू करने, Claude Code सत्र में प्रवेश करने, या सिस्टम पुनः लॉगिन करने के बाद पुनः चले। इसलिए इन संसाधनों का लक्ष्य प्रोजेक्ट-स्तरीय कॉन्फ़िगरेशन और उपयोगकर्ता-स्तरीय स्व-शुरू होने के तंत्र पर है: प्रोजेक्ट-स्तरीय कॉन्फ़िगरेशन अधिक छिपा हुआ होता है, जबकि सिस्टम-स्तरीय सेवाएँ लंबे समय तक चलाने के लिए अधिक उपयुक्त होती हैं।

C2 और प्रसार:

ये एम्बेडेड संसाधन बाद के नियंत्रण लिंक और रिपोजिटरी सीक्रेट्स के स्थानांतरण के लिए उपयोग किए जाते हैं। YZ को डीक्रिप्ट करने पर GitHub commit search monitor प्राप्त होता है, जो firedalazer . फॉर्मेट के commit message को नियमित रूप से खोजता है, साइनेचर की पुष्टि करने के बाद रिमोट Python सामग्री को डाउनलोड और निष्पादित करता है; zZ को डीक्रिप्ट करने पर "Run Copilot" नामक GitHub Actions workflow टेम्पलेट प्राप्त होता है, जो ${{ toJSON(secrets) }} को format-results.txt में लिखता है और इसे artifact के रूप में अपलोड करता है। पहला बाद के कार्यों के लिए प्राप्त/निष्पादन लिंक प्रदान करता है, दूसरा GitHub Actions artifact के माध्यम से repository secrets के स्थानांतरण के लिए टेम्पलेट प्रदान करता है; वास्तविक workflow इंजेक्शन, चलाने की प्रतीक्षा और artifact डाउनलोड मुख्य पेलोड में संबंधित GitHub API लॉजिक द्वारा पूरा किया जाता है।

Core malicious payload capability analysis

बहु-स्तरीय डिकॉन्फ्यूजन के बाद, नमूना अंततः मूल दुष्ट भार जारी और निष्पादित करता है। नीचे दिए गए सभी विश्लेषण मूल दुष्ट भार मॉड्यूल पर केंद्रित हैं, जिन्हें डेटा प्राप्ति, बाहरी प्रेषण, प्रसारण, स्थायित्व और प्रतिरोध के पांच चरणों में विभाजित किया गया है।

1. GitHub Actions रनर मेमोरी पढ़ना:

नमूना में Linux, Windows, macOS के तीन प्लेटफॉर्म के लिए मेमोरी पढ़ने के स्क्रिप्ट शामिल हैं, जिनमें क्रॉस-प्लेटफॉर्म dump क्षमता है। Linux कार्यान्वयन लक्ष्य प्रक्रिया के /proc//maps और /proc//mem पढ़कर मेमोरी निकालता है:

कोर मैलिशियस पेलोड का सक्रिय ट्रिगर लॉजिक GitHub Actions Linux runner पर लागू होता है: जब GITHUB_ACTIONS === "true" और RUNNER_OS === "Linux" हो, तो कोड Runner.Worker प्रक्रिया की खोज करता है और मेमोरी डंप करता है, फिर डंप से "":{"value":"","isSecret":true} प्रारूप के masked secrets को निकालता है। तीनों नमूनों में सक्रिय एकत्रीकरण का मार्ग Linux runner पर केंद्रित है, लेकिन तीनों प्लेटफॉर्म स्क्रिप्ट्स समाहित हैं।

2. मल्टीक्लाउड और डेवलपर स्थानीय पारित्रमाण संग्रह:

मुख्य दुष्ट भार में सिस्टमैटिक क्रेडेंशियल कलेक्शन मॉड्यूल शामिल है, जो क्लाउड प्रोवाइडर, CI वातावरण, डेवलपर लोकल कॉन्फ़िगरेशन, GitHub CLI, पासवर्ड मैनेजर और वॉलेट फ़ाइलों को कवर करता है।

क्लाउड प्रोवाइडर क्रेडेंशियल्स के एक्सट्रैक्शन लक्ष्य निम्नलिखित हैं:

AWS मॉड्यूल में ECS / IMDS (Instance Metadata Service) / STS WebIdentity संबंधी तर्क भी शामिल है।

डेवलपर स्थानीय पात्रता निम्न लक्ष्यों को कवर करती है:

पासवर्ड प्रबंधक तर्क स्रोत कोड में shell स्ट्रिंग संयोजन के बजाय runCommand(command, args) अरेक के रूप में लागू किया गया है।

ऊपर वर्णित पात्र संग्रह मॉड्यूल बादल प्लेटफॉर्म से लेकर डेवलपर के स्थानीय तक विस्तृत लक्ष्यों को कवर करता है; संग्रहित संवेदनशील डेटा निम्नलिखित तंत्र के माध्यम से बाहर भेजा जाता है।

3. GitHub API एक्सट्रा और डेड-ड्रॉप:

मुख्य क्षतिकारक लोड GitHub API को मुख्य डेटा लीक चैनल के रूप में उपयोग करता है। अनुरोध python-requests/2.31.0 के रूप में User-Agent को छिपाता है, और x-oauth-scopes (repo, public_repo या workflow को शामिल करना आवश्यक है) की पुष्टि के बाद डेटा लीक ऑपरेशन निष्पादित करता है: repository बनाता है (description स्थिर Miasma: The Spreading Blight), और चोरी किए गए डेटा को base64 एन्कोड करके PUT /repos///contents/results/ के माध्यम से लिखता है।

इसके अलावा, लोड ने GitHub कमिट खोज के आधार पर एक डेड-ड्रॉप तंत्र कार्यान्वित किया है, जिसमें C2 निर्देश प्राप्त करने के लिए मार्कर "thebeautifulmarchoftime " (या "thebeautifulsnadsoftime") की खोज की जाती है:

let result = await X9("thebeautifulmarchoftime ", xZ);

एम्बेडेड रिसोर्स YZ.bin एक स्वतंत्र GitHub कमिट मॉनिटर है, जो 3600 सेकंड के अंतराल पर firedalazer . प्रारूप के कमिट मैसेज के लिए पॉल करता है, साइनेचर की पुष्टि के बाद दूरस्थ Python सामग्री को डाउनलोड और निष्पादित करता है। यह मुख्य बाहरी चैनल से स्वतंत्र एक अतिरिक्त नियंत्रण लिंक बनाता है।

सोर्स कोड में api.anthropic.com और v1/api के लिए एक HTTP POST सेंडर कॉन्फ़िगरेशन भी शामिल है। इस कॉन्फ़िगरेशन का noop फ़ील्ड true पर सेट है, जिसका अर्थ है कि यदि इसे बाहरी रूप से नहीं बदला गया है, तो यह सेंडर वास्तविक नेटवर्क अनुरोध नहीं भेजेगा। इसलिए स्टैटिक विश्लेषण केवल इस कोड संरचना की उपस्थिति की पुष्टि कर सकता है, लेकिन Anthropic API के सक्रिय बाहरी प्रवाह के अस्तित्व को साबित नहीं कर सकता।

4. GitHub रिपॉजिटरी और वर्कफ्लो संक्रमण:

मुख्य दुष्ट भार GitHub REST / GraphQL API के माध्यम से रिपॉजिटरी के git ऑब्जेक्ट्स को संचालित कर सकता है:

एक दुरुपयोगपूर्ण workflow, जिसे "release" के नाम से बनाया गया है, id-token: write अनुमति का अनुरोध करता है और OIDC (OpenID Connect) पथ के माध्यम से npm प्रकाशन token प्राप्त करता है। OIDC पथ के लिए पर्यावरण चर और इंटरफ़ेस ACTIONS_ID_TOKEN_REQUEST_TOKEN और ACTIONS_ID_TOKEN_REQUEST_URL हैं, जिसमें audience के रूप में npm:registry.npmjs.org सेट किया गया है। सोर्स कोड स्तर पर पुष्टि की जा सकती है कि payload GitHub रिपॉजिटरी में workflow इंजेक्ट करने और OIDC / npm विश्वसनीय प्रकाशन का उपयोग करके प्रकाशन अधिकार प्राप्त करने की क्षमता रखता है।

गिट रेफ्स के माध्यम से वर्कफ्लो को इंजेक्ट करने के अलावा, पेलोड में एक और छिपी हुई सीक्रेट्स स्थानांतरण तकनीक शामिल है: कॉपिलॉट चलाने के रूप में छिपाए गए गिटहब एक्शन्स वर्कफ्लो द्वारा ${{ toJSON(secrets) }} को format-results.txt में लिखा जाता है और आर्टिफैक्ट अपलोड किया जाता है। सीक्रेट्स को सीधे रिपॉजिटरी कंटेंट में लिखने के विपरीत, यह तरीका वर्कफ्लो रन आउटपुट के माध्यम से डेटा स्थानांतरित करने पर अधिक केंद्रित है, और सामान्य कोड डिफ समीक्षा में अंतिम निर्यातित सीक्रेट्स की सामग्री सीधे दिखाई नहीं दे सकती।

5. कॉपिलट वर्कफ्लो चलाएं: artifact के माध्यम से secrets को स्थानांतरित करें:

एम्बेडेड रिसोर्स zZ.bin, Copilot के रूप में छिपा हुआ GitHub Actions वर्कफ्लो है, जो ${{ toJSON(secrets) }} को format-results.txt में लिखता है और इसे आर्टिफैक्ट के रूप में अपलोड करता है।

संबंधित GitHub API व्यवहार शामिल हैं: अस्थायी शाखा बनाएं/अपडेट करें → वर्कफ्लो ब्लॉब लिखें → वर्कफ्लो रन का इंतजार करें → आर्टिफैक्ट zip डाउनलोड करें → format-results.txt पढ़ें → वर्कफ्लो रन और अस्थायी शाखा हटाएं। संबंधित हंटिंग कीवर्ड शामिल हैं: Run Copilot, VARIABLE_STORE, format-results, chore/add-codeql-static-analysis, .github/workflows/codeql.yml।

6. npm स्व-प्रसार:

मुख्य दुष्ट भार के दो स्वतंत्र npm प्रकाशन / प्रसारण मार्ग हैं।

npm टोकन पथ: GET /-/npm/v1/tokens के माध्यम से वर्तमान उपयोगकर्ता के npm टोकन की सूची बनाएं, bypass_2fa === true और पैकेज लिखने की अनुमति वाले टोकन को फिल्टर करें, और इन टोकन का उपयोग स्वचालित प्रकाशन के लिए करें। bypass_2fa टोकन मेटाडेटा क्षेत्र है, प्रकाशन शरीर पैरामीटर नहीं।

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 की उपलब्धता सुनिश्चित करने की आवश्यकता होती है।

7. पर्सिस्टेंस मैकेनिज्म:

मुख्य दुष्ट भार में चार स्थायी तरीके शामिल हैं, जो प्रोजेक्ट डायरेक्टरी और सिस्टम-लेवल स्व-शुरू होने को कवर करते हैं।

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 के साथ GitHub टोकन मॉनिटर सेवा स्थापित करता है, जिसमें फाइलें /.local/bin/gh-token-monitor.sh, /.config/gh-token-monitor/ निर्देशिकाओं और संबंधित systemd / LaunchAgent पथों पर वितरित हैं। यह मॉनिटर यह जांचता है कि क्या GitHub टोकन 40x स्टेटस कोड लौटा रहा है और npm पैकेज @cap-js/openapi@1.4.1 के मेटाडेटा में कोई असामान्यता है, और इसके बाद handler निष्पादित करता है:

इसका अर्थ है कि जब monitor को GitHub API से 40x स्टेटस कोड मिलता है, जैसे token रद्द, अमान्य या अनुमति स्थिति असामान्य हो, तो दुर्भावनापूर्ण स्क्रिप्ट आने वाले handler को निष्पादित करती है। इन तीनों नमूनों में पुनर्स्थापित handler rm -rf ~/; rm -rf ~/Documents है।处置 के समय, संभावित रूप से payload चल रहे होस्ट पर token रद्द नहीं किया जाना चाहिए—पहले होस्ट को अलग करें, स्थायी आइटम और चल रही प्रक्रियाओं को साफ करें, और फिर स्वच्छ परिवेश से पात्रता का पुनः प्रयोग करें।

8. हार्डन-रनर / स्टेपसिक्योरिटी प्रतिस्पर्धा:

मुख्य दुष्ट भार में StepSecurity Harden-Runner की जांच और क्षति के लिए अंतर्निहित तर्क है, जो CI/CD सुरक्षा को निम्नलिखित चरणों द्वारा बायपास करता है:

Docker सॉकेट /var/run/docker.sock उपलब्ध है या नहीं, यह जाँचें;
डॉकर कंटेनर्स की सूची बनाएं, जिनमें नाम या इमेज में harden-runner / stepsecurity कीवर्ड मिले;
POST /containers//kill के माध्यम से मैचिंग कंटेनर को बंद करें;
एक प्रिविलेज्ड alpine कंटेनर बनाएं, जिसमें sudoers को runner ALL=(ALL) NOPASSWD:ALL के रूप में ओवरराइट किया जाए;
/etc/hosts में StepSecurity संबंधी डोमेन के लिए अमान्य रिज़ॉल्यूशन लिखें;
/etc/resolv.conf को 8.8.8.8 और 1.1.1.1 से ओवरराइड करें।

यह प्रतिरोधी तर्क दर्शाता है कि नमूना StepSecurity द्वारा सुरक्षित CI/CD वातावरण के लिए विशेष रूप से अनुकूलित किया गया है।

9. EDR / सुरक्षा उत्पाद एक्सप्लोरेशन, वातावरण निर्धारण और बचाव:

मुख्य दुष्ट भार विभिन्न 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 (अलग detached daemon सबप्रोसेस को टैग करता है), SKIP_DOMAIN (domain sender पथ को छोड़ देता है), /tmp/kitty-*, cat.py और /var/tmp/.gh_update_state शामिल हैं।

Impact Analysis

सोर्स कोड क्षमता के आधार पर, इन तीन नमूनों का प्रभाव npm स्थापना चरण के एकल निष्पादन तक सीमित नहीं है। इनका वास्तविक जोखिम चार स्तरों में विभाजित हो सकता है:

डेवलपर होस्ट स्तर पर। नमूना पर्यावरण चर, .npmrc, .pypirc, SSH कुंजी, Docker कॉन्फ़िगरेशन, .env, GitHub CLI टोकन, पासवर्ड मैनेजर डेटा और वॉलेट फ़ाइलों को एकत्र करेगा और Claude Code, VS Code, systemd यूजर सेवा या macOS LaunchAgent के माध्यम से भविष्य के ट्रिगर क्षमता बनाए रखेगा।

CI/CD रनर स्तर पर। नमूना GitHub Actions Linux रनर की पहचान करता है, Runner.Worker प्रक्रिया की मेमोरी पढ़ता है और masked secrets निकालता है; साथ ही, StepSecurity Harden-Runner के विरोधी तर्क को भी धारण करता है, जो CI/CD सुरक्षा घटकों को नष्ट करने या उन्हें बाईपास करने का प्रयास करता है।

GitHub ऑर्गनाइजेशन और रिपॉजिटरी स्तर पर। नमूना GitHub API का उपयोग करके रिपॉजिटरी बना सकता है, contents/results/ में लिख सकता है, git refs/blobs/trees/commits को संशोधित कर सकता है, दुष्ट workflow को इंजेक्ट कर सकता है, और Run Copilot workflow + artifact के माध्यम से secrets को स्थानांतरित कर सकता है।

npm इकोसिस्टम के प्रसार स्तर पर। नमूने में package write अधिकार वाले और bypass_2fa === true के साथ npm टोकन को चुना जा सकता है, या GitHub Actions OIDC / npm विश्वसनीय प्रकाशन पथ का उपयोग करके प्रकाशन क्षमता प्राप्त की जा सकती है; इसके बाद लक्ष्य tarball डाउनलोड किया जाता है, दुष्ट loader लिखा जाता है, preinstall में परिवर्तन किया जाता है, Bun निर्भरता जोड़ी जाती है, पैच संस्करण बढ़ाया जाता है और प्रकाशित किया जाता है, जिससे npm स्वयं-प्रसार श्रृंखला बनती है।

Summary

तीन नमूनों के स्रोत कोड साक्ष्य से पता चलता है कि यह दुष्ट पैकेज केवल एक साधारण स्थापना-समय चोरी स्क्रिप्ट नहीं है, बल्कि एक बहु-चरण लोडर और पूर्ण इम्प्लांट का संयोजन है: बाहरी परत बैच के अनुसार रैंडमाइज़ की गई है, Bun रनटाइम बूटस्ट्रैपर और मुख्य दुष्ट लोड के साथ संगत है; मुख्य इम्प्लांट क्रेडेंशियल्स के संग्रह, CI सीक्रेट निकालना, GitHub / npm प्रसार, स्थायीकरण और सुरक्षा प्रतिरोध जैसे कई पहलुओं को कवर करता है।

उच्च गोपनीयता वाला एंट्री डिज़ाइन। हमलावर व्यावसायिक कोड में दुष्ट तर्क नहीं डालते, बल्कि npm लाइफसाइकल स्क्रिप्ट में भ्रमित लोडर लगाते हैं। यह लोडर मुख्य रूप से एम्बेडेड पेलोड को डिक्रिप्ट करने और निष्पादित करने के लिए जिम्मेदार होता है, जिससे केवल व्यावसायिक स्रोत कोड की समीक्षा से वास्तविक क्षमता का पता लगाना कठिन हो जाता है।

एक बहु-स्तरीय नेस्टेड डिकॉन्फ्यूज़िंग चेन। मैलिशियस पेलोड को डिजिटल अरेज़ + ROT अक्षर प्रतिस्थापन, AES-128-GCM एन्क्रिप्शन, obfuscator.io ओब्फ़स्केशन, B5 स्व-विकसित स्ट्रिंग एन्क्रिप्शन और AES-256-GCM + gzip एम्बेडेड लेयर के माध्यम से पांच स्तरों में पैक किया गया है। प्रत्येक स्तर की कुंजी या पैरामीटर अलग-अलग पैकेज में स्वतंत्र रूप से बदली जा सकती है, जिससे स्टैटिक फीचर्स के आधार पर बैच डिटेक्शन कठिन हो जाता है।

पूर्ण संगठन स्तरीय हमला क्षमता। यह इम्प्लांट GitHub Actions Runner की मेमोरी पढ़ने, बहु-बादल और स्थानीय पारित्रों का संग्रह करने, GitHub API के माध्यम से डेटा बाहर भेजने और डेड-ड्रॉप करने, GitHub रिपॉजिटरी और workflow को संक्रमित करने, npm के माध्यम से स्वयं प्रसारित होने, स्थायीकरण और सुरक्षा के विरुद्ध प्रतिरोध करने की क्षमता रखता है। स्रोत कोड संरचना से देखा जा सकता है कि इसमें एकल स्थापना से शुरू होकर रिपॉजिटरी, CI/CD और npm प्रकाशन श्रृंखला तक फैलने के लिए कोड पथ मौजूद हैं; वास्तविक प्रसार का परिसर स्थापना लॉग, रिपॉजिटरी ऑडिट और प्लेटफॉर्म-स्तरीय टेलीमेट्री के साथ मिलाकर ही पुष्टि किया जा सकता है।

स्रोत कोड के साक्ष्य से यह पुष्टि की जा सकती है: तीनों नमूने preinstall के माध्यम से स्वचालित रूप से ट्रिगर हुए और एक ही मुख्य implant को डिक्रिप्ट और निष्पादित किया। हालाँकि, वास्तविक घटना में प्रारंभिक अधिकार कैसे प्राप्त किए गए, इन तीनों tgz नमूनों से इसे साबित नहीं किया जा सकता।

अनुशंसित कार्रवाई

प्रोजेक्ट निर्भरता, lockfile, निजी रजिस्ट्री कैश और बिल्ड कैश में दुर्भावनापूर्ण संस्करण की जांच करें और हटाएं।
इंस्टॉलेशन लॉग में preinstall, node index.js, bun run, /tmp/p*.js, tmp.0987654321.lock दिखाई देते हैं या नहीं, यह जांचें।
अभी भी पेलोड चल रहा होने की संभावना वाले पीड़ित होस्ट पर सीधे टोकन रद्द न करें। सुझाव है कि पहले पीड़ित होस्ट को अलग करें, चल रही प्रक्रियाओं और स्थायी आइटम को साफ करें, और फिर स्वच्छ परिवेश से GitHub, npm, क्लाउड क्रेडेंशियल, Kubernetes, Vault, SSH, Docker registry, पासवर्ड मैनेजर से संबंधित टोकन बदलें।
गिटहब रिपॉजिटरी के हालिया ब्रांच, कमिट, वर्कफ्लो, आर्टिफैक्ट और नए रिपॉजिटरी की जांच करें, विशेष रूप से Run Copilot, format-results, chore/add-codeql-static-analysis, .github/workflows/codeql.yml, OIDC_PACKAGES जैसे कीवर्ड पर ध्यान दें।
जांचें कि प्रोजेक्ट डायरेक्टरी में कोई नया या संशोधित फ़ाइल है: .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json, .vscode/setup.mjs।
उपयोगकर्ता स्तरीय स्थायित्व की जांच करें: /.local/share/kitty/cat.py, /.config/systemd/user/kitty-monitor.service, ~/Library/LaunchAgents/com.user.kitty-monitor.plist, gh-token-monitor संबंधित फ़ाइलें।
npm प्रकाशन इतिहास की जांच करें और अनधिकृत पैच संस्करण प्रकाशन की पुष्टि करें; साथ ही, npm टोकन मेटाडेटा की ऑडिट करें, विशेष रूप से 2FA (टू-फैक्टर ऑथेंटिकेशन) को बायपास करने और पैकेज लिखने की अनुमति वाले टोकन पर।
Perform an integrity audit on downstream artifacts built in a contaminated environment.

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

Malicious dependency

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