Axios के npm पर compromise होने से remote access trojan वितरित हुआ

 (stepsecurity.io)
12 पॉइंट द्वारा GN⁺ 2026-03-31 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • व्यापक रूप से उपयोग होने वाले axios HTTP client के दो malicious versions npm पर प्रकाशित किए गए, जो install होने पर remote access trojan (RAT) वितरित करते हैं
  • हमलावर ने maintainer account credentials की चोरी के जरिए GitHub Actions को bypass किया और malicious package को manually upload किया
  • malicious versions में fake dependency plain-crypto-js@4.2.1 शामिल थी, जो postinstall script से RAT install करती है और निशान मिटा देती है
  • RAT macOS, Windows, Linux तीनों को संक्रमित करता है और C2 server (sfrclak.com:8000) से संपर्क करके अतिरिक्त payload डाउनलोड करता है
  • npm और GitHub ने तेज़ी से malicious versions हटा दिए, लेकिन supply chain security मज़बूत करने और credentials की सुरक्षा का महत्व फिर सामने आया

axios npm supply chain attack का overview

  • 31 मार्च 2026 को, व्यापक रूप से उपयोग होने वाली axios HTTP client library के दो malicious versions (axios@1.14.1, axios@0.30.4) npm पर प्रकाशित किए गए
  • हमलावर ने axios के प्रमुख maintainer के npm credentials चुराकर GitHub Actions CI/CD pipeline को bypass किया और malicious packages manually publish किए
  • दोनों versions में plain-crypto-js@4.2.1 नाम की fake dependency डाली गई, यह package postinstall script के जरिए remote access trojan (RAT) install करता है
  • RAT macOS, Windows, Linux सभी को target करता है और C2 (Command and Control) server (sfrclak.com:8000) से संपर्क कर second-stage payload डाउनलोड करता है
  • install के बाद यह malicious code और उसके निशान हटा देता है और साफ package.json से replace कर forensic detection से बचता है

attack timeline

  • 30 मार्च 05:57 UTC: plain-crypto-js@4.2.0 (normal version) प्रकाशित
  • 30 मार्च 23:59 UTC: plain-crypto-js@4.2.1 (malicious version) प्रकाशित, postinstall hook जोड़ा गया
  • 31 मार्च 00:21 UTC: axios@1.14.1 प्रकाशित, malicious dependency डाली गई
  • 31 मार्च 01:00 UTC: axios@0.30.4 प्रकाशित, वही malicious dependency डाली गई
  • 31 मार्च 03:15 UTC: npm ने दोनों malicious versions हटा दिए
  • 31 मार्च 04:26 UTC: npm ने plain-crypto-js को security holder stub (0.0.1-security.0) से replace किया

axios overview

  • axios JavaScript ecosystem में सबसे व्यापक रूप से उपयोग होने वाले HTTP clients में से एक है, और Node.js व browser दोनों में इस्तेमाल होता है
  • साप्ताहिक downloads 30 करोड़ से अधिक हैं, इसलिए केवल एक malicious release भी व्यापक नुकसान की संभावना रखती है
  • सामान्य developers के लिए npm install के दौरान malicious code install होना पहचानना मुश्किल है

attack stages

  • चरण 1 — maintainer account takeover

    • हमलावर ने jasonsaayman npm account takeover किया और email को ifstap@proton.me में बदल दिया
    • इसके बाद 1.x और 0.x release branches दोनों में malicious builds प्रकाशित किए
    • सामान्य release GitHub Actions के OIDC Trusted Publisher के जरिए प्रकाशित होती हैं, लेकिन axios@1.14.1 manual publish था, इसलिए उसमें gitHead और OIDC signature नहीं था
    • अनुमान है कि हमलावर ने लंबे समय तक मान्य npm access token का उपयोग किया

  • चरण 2 — malicious dependency की pre-deployment

    • plain-crypto-js@4.2.1 को nrwise@proton.me account से प्रकाशित किया गया
    • यह crypto-js का भेष धारण करता है और वही description व repository URL इस्तेमाल करता है
    • इसमें "postinstall": "node setup.js" hook शामिल है, जो install के समय अपने-आप चलता है
    • attack के बाद package.md को package.json से replace कर सबूत मिटाने की तैयारी की गई

  • चरण 3 — axios में dependency injection

    • plain-crypto-js@^4.2.1 को runtime dependency के रूप में जोड़ा गया
    • code में इसे एक बार भी import नहीं किया गया → phantom dependency
    • npm install के समय यह अपने-आप install होकर postinstall script चलाता है

RAT dropper (setup.js) analysis

  • obfuscation techniques

    • strings को array stq[] में encrypt करके रखा गया और _trans_1 (XOR) व _trans_2 (Base64+reverse) से decrypt किया गया
    • C2 URL है http://sfrclak.com:8000/6202033
    • decrypted strings में OS identifiers (win32, darwin), file paths, shell commands आदि शामिल हैं

  • platform-specific payloads

    • macOS

      • AppleScript को /tmp में लिखकर osascript से चलाया जाता है
      • C2 से RAT binary लेकर /Library/Caches/com.apple.act.mond में save और execute किया जाता है
      • file name को Apple system daemon जैसा दिखाने के लिए चुना गया

    • Windows

      • PowerShell path खोजने के बाद %PROGRAMDATA%\\wt.exe में copy किया जाता है
      • VBScript के जरिए C2 से PowerShell RAT download और execute किया जाता है
      • temporary files (.vbs, .ps1) execution के बाद delete कर दिए जाते हैं

    • Linux

      • curl से /tmp/ld.py download कर nohup python3 से चलाया जाता है
      • /tmp/ld.py file बनी रहती है
      • तीनों platforms में packages.npm.org/product0~2 POST body का उपयोग कर वैध npm traffic जैसा भेष बनाया जाता है

  • self-deletion and concealment

    • setup.js और package.json delete किए जाते हैं
    • package.md को package.json से replace कर normal package जैसा भेष बनाया जाता है
    • इसके बाद npm audit या manual review से detection संभव नहीं रहता
    • हालांकि node_modules/plain-crypto-js/ का मौजूद होना खुद infection का सबूत है

StepSecurity Harden-Runner के जरिए execution verification

  • Harden-Runner GitHub Actions में network, process, और file events को real time में log करता है
  • axios@1.14.1 install के दौरान C2 से दो connections (curl, nohup) detect किए गए
    • पहला connection npm install शुरू होने के 2 सेकंड बाद हुआ
    • दूसरा 36 सेकंड बाद हुआ और background process के रूप में चलता रहा
  • process tree analysis के अनुसार nohup process PID 1 (init) के अधीन orphan process के रूप में रहकर लगातार चलता रहा
  • file event logs में package.json को दो बार overwrite किया गया
    • पहली बार: install के दौरान malicious version लिखा गया
    • दूसरी बार: 36 सेकंड बाद साफ stub से replace किया गया

indicators of compromise (IOC)

  • malicious npm packages

    • axios@1.14.1 · shasum: 2553649f232204966871cea80a5d0d6adc700ca
    • axios@0.30.4 · shasum: d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
    • plain-crypto-js@4.2.1 · shasum: 07d889e2dadce6f3910dcbc253317d28ca61c766

  • network

  • file paths

    • macOS: /Library/Caches/com.apple.act.mond
    • Windows: %PROGRAMDATA%\\wt.exe
    • Linux: /tmp/ld.py

  • attacker accounts

    • jasonsaayman (compromised maintainer)
    • nrwise (attacker-created account)

  • safe version

    • axios@1.14.0 (normal)

impact verification and response procedure

  • npm list axios या package-lock.json में 1.14.1 / 0.30.4 की जाँच करें
  • node_modules/plain-crypto-js की मौजूदगी जाँचें
  • OS-specific RAT files मिलने पर system को पूर्ण रूप से compromised मानें
  • CI/CD logs में इन versions के install history की जाँच करें और सभी secrets व tokens rotate करें

recovery steps

  1. axios को safe version (1.14.0 या 0.30.3) पर pin करें
  2. plain-crypto-js folder हटाकर npm install --ignore-scripts के साथ दोबारा install करें
  3. RAT के निशान मिलें तो system rebuild करें
  4. सभी credentials (AWS, SSH, CI/CD आदि) rotate करें
  5. CI/CD pipeline की जाँच करें और secrets बदलें
  6. automated builds में --ignore-scripts option का उपयोग करें
  7. C2 domain/IP को firewall या /etc/hosts से block करें

StepSecurity Enterprise features

  • Harden-Runner

    • GitHub Actions में network egress whitelist लागू करता है
    • abnormal traffic को block और log करता है
    • sfrclak.com:8000 connection को पहले से block किया जा सकता है

  • Dev Machine Guard

    • developer PCs पर installed npm packages की real-time monitoring
    • axios@1.14.1, 0.30.4 installed systems की तुरंत पहचान

  • npm Package Cooldown Check

    • newly published packages पर अस्थायी install block period लागू करता है
    • plain-crypto-js@4.2.1 जैसी तेज़ malicious publishing को detect कर सकता है

  • Compromised Updates Check

    • real-time malicious package DB के आधार पर PR merge को block करता है
    • axios@1.14.1, plain-crypto-js@4.2.1 तुरंत register किए गए

  • Package Search

    • पूरे organization के PRs और repositories में किसी specific package के introduction points खोजता है
    • impact range (repository, team, PR) तुरंत समझी जा सकती है

  • AI Package Analyst

    • npm registry की real-time monitoring और behavior-based malicious detection
    • दोनों malicious versions को publish होने के कुछ मिनटों में detect किया गया

  • Threat Center Alert

    • attack summary, IOC, response procedure सहित threat intel alert प्रदान करता है
    • SIEM integration के जरिए real-time visibility मिलती है

acknowledgements

  • axios maintainers और community ने GitHub issue #10604 के जरिए तेज़ी से response दिया
  • GitHub ने compromised account suspend किया और npm ने malicious versions हटाकर security holder लागू किया
  • maintainers, GitHub, और npm के coordinated response से दुनिया भर के developers को होने वाला नुकसान कम किया गया

संबंधित पढ़ाई

2 टिप्पणियां

 
chanapple 2026-03-31

मैंने कभी नहीं सोचा था कि इस स्तर का पैकेज भी compromise हो सकता है, लेकिन axios तो उम्मीद से भी बढ़कर निकला।
 
GN⁺ 2026-03-31
Hacker News की राय

  • npm, bun, pnpm, uv सभी अब पैकेज के लिए न्यूनतम रिलीज़ अवधि सेट करने को सपोर्ट करते हैं
    मैंने ~/.npmrc में ignore-scripts=true जोड़ रखा है, और केवल इस सेटिंग से भी कमजोरी को कम किया जा सकता था
    bun और pnpm डिफ़ॉल्ट रूप से lifecycle scripts नहीं चलाते
    हर पैकेज मैनेजर के लिए सेटिंग के उदाहरण इस प्रकार हैं:

    • uv: exclude-newer = "7 days"
    • npm: min-release-age=7
    • pnpm: minimum-release-age=10080
    • bun: minimumReleaseAge = 604800
      दिलचस्प बात यह है कि सभी में समय की इकाइयाँ अलग-अलग हैं
      अगर आप LLM agent का उपयोग करते हैं, तो इस सेटिंग की वजह से failure हो सकता है, इसलिए AGENTS.md या CLAUDE.md में इससे जुड़ा निर्देश जोड़ना चाहिए
    • “समय की इकाइयाँ भी सबकी अलग हैं” पर मज़ाक किया गया: “क्या तुम JavaScript आज ही पहली बार इस्तेमाल कर रहे हो?”
    • pnpm ने यह फीचर सबसे पहले जोड़ा था. npm में यह केवल 11.10.0 या उससे ऊपर में सपोर्ट होता है, और 11 फ़रवरी 2026 की रिलीज़ से उपलब्ध है
    • कुछ लोगों का मानना था कि config file में unit साफ़-साफ़ लिखना बेहतर होता, जैसे timeout की जगह timeoutMinutes
    • npm शायद comments को सपोर्ट नहीं करता. min-release-age=7 # days वास्तव में लागू न हो, ऐसा संभव है
    • yarn berry में ~/.yarnrc.yml में npmMinimalAgeGate: "3d" सेट किया जा सकता है

  • यह सुनकर झटका लगा कि Axios supply chain attack का शिकार हुआ
    Axios के अंदर खुद malicious code नहीं था, लेकिन plain-crypto-js@4.2.1 नाम की एक नकली dependency inject की गई, जिसने postinstall script चलाकर RAT (remote access trojan) इंस्टॉल किया
    pnpm या bun की तरह postinstall scripts को manual approval के बाद चलाने वाले users के लिए यह राहत की बात है

    • Node.js में fetch डिफ़ॉल्ट रूप से v18 के बाद आया था, और यह v21 से stable हुआ. Axios इससे बहुत पहले से मौजूद है, और कई frameworks व tutorials में शामिल होने के कारण अब भी व्यापक रूप से इस्तेमाल होता है
    • “pnpm/bun users सुरक्षित हैं” वाली बात पर सवाल उठा कि “तो क्या पुराने versions में लोगों ने इसे approve नहीं किया होगा?”
    • यह भी पूछा गया कि क्या pnpm transitive dependencies के postinstall भी block करता है

  • यह दावा भी सामने आया कि package managers एक failed experiment हैं
    SQLite जैसी high-quality C libraries हैं जो एक ही .c file में मिल जाती हैं, और इस तरीके से transitive dependency की समस्या से बचा जा सकता है
    ज़्यादातर attack surface ऐसी indirect dependencies से ही आती है

    • अब package managers भाषा अपनाने के लिए लगभग अनिवार्य हो चुके हैं. असली समस्या quality control की कमी और incentive structure है
      OpenSSL तक code quality issues की वजह से rewrite किया जा रहा है, और JS में standard library को बढ़ाना कठिन होने से polyfills की भरमार है
    • यह राय भी आई कि “जिस समाधान में थोड़ी ज़्यादा मेहनत लगे, उसे community अपनाएगी नहीं”
      इसके बजाय npm जैसे repositories में quality standards कड़े करने और केवल ज़िम्मेदार maintainers को रजिस्टर करने देने का सुझाव दिया गया
    • web development में attack surface कहीं ज़्यादा बड़ा है. manual copy वाला तरीका updates को track करना कठिन बनाता है, इसलिए package manager की notification सुविधा अब भी उपयोगी है
    • यह भी कहा गया कि खासकर NPM ही ऐसा ecosystem है जहाँ supply chain attacks बहुत गंभीर हैं
    • जवाब में यह तर्क दिया गया कि Rust, C से ज़्यादा सुरक्षित है, और ज़्यादातर crates high-quality होते हैं, इसलिए C libraries पर ज़ोर देना बढ़ा-चढ़ाकर कहना है

  • मज़ाक में कहा गया कि दिन की शुरुआत इस आत्म-व्यंग्य भरे अभिवादन से होती है: “आज कौन-सा npm पैकेज हैक हुआ होगा?”

  • Linux users को सलाह दी गई कि वे bwrap का इस्तेमाल करके npm, pip, cargo, gradle जैसी सभी build logic को sandbox करें
    bwrap, Docker की तरह isolated environment देता है, लेकिन इसमें image की ज़रूरत नहीं होती. Flatpak भी इसी तकनीक पर आधारित है
    server deployment में container hardening महत्वपूर्ण है, और CI/CD environment को untrusted zone की तरह ट्रीट करना अहम है
    AI चलाते समय भी यही sandbox उपयोग करना अच्छा रहेगा

    • लेकिन यह भी कहा गया कि यह तरीका केवल postinstall attacks पर असरदार है. code के अंदर require करते ही वह चल सकता है
    • किसी ने Docker-आधारित personal sandbox amazing-sandbox भी बनाया है
    • drop नाम का bwrap से higher-level tool भी सुझाया गया
    • कुछ लोगों ने firejail को अधिक flexible security sandbox बताया
    • यह भी कहा गया कि SSH socket forwarding से private key access मिल जाता है, इसलिए कोई खास security benefit नहीं है, और password-protected key इस्तेमाल करना बेहतर है

  • dependency समस्याएँ बार-बार देखकर यह चिंता जताई गई कि क्या Rust ecosystem भी कभी ऐसा ही कुछ झेलेगा
    standard library को बहुत बड़ा बनाना आसान नहीं, लेकिन विश्वसनीय package quality assurance system की ज़रूरत है

    • यह सुझाव दिया गया कि बड़े packages (जैसे Axios) में publish को approve करने के लिए कई MFA approvers होने चाहिए
    • यह भविष्यवाणी भी की गई कि verified dependencies को commercial service के रूप में उपलब्ध कराया जाएगा
    • एक और सुझाव था कि dependency के tests को खुद copy करके codebase में शामिल किया जाए, और उस पर अपनी code review process लागू की जाए
      AI की वजह से यह अतिरिक्त काम अब संभव हो गया है, और कुछ लोगों ने माना कि असल में यह पहले से ही किया जाना चाहिए था

  • NPM supply chain attacks के exposure को कम करने के लिए मुख्य नियम

    • Yarn का zero-installs mode इस्तेमाल करें
    • postinstall scripts को disable करें या चलाने से पहले verify करें
    • development के दौरान अगर third-party code चलाना हो, तो उसे केवल VM/container के अंदर चलाएँ
    • package जोड़ते समय लोकप्रियता को plus point, हाल की commits को minus point मानें, और code व change history को खुद review करें
    • पूरी dependency tree को verify करें, और हर नए developer के जुड़ने पर trust का फिर से मूल्यांकन करें
    • यह राय भी थी कि lockfile और --frozen-lockfile option ही पर्याप्त सुरक्षा दे सकते हैं
    • कुछ लोग बस इस सरल लेकिन मज़बूत सिद्धांत पर चलते हैं: “मैं समस्याग्रस्त stack से दूर रहता हूँ”

  • “ऐसे attacks से पूरी तरह बचना हो तो क्या करना चाहिए?” इस सवाल पर
    यह राय आई कि Qubes OS पर जाना चाहिए, ताकि password manager और build environment को पूरी तरह अलग रखा जा सके

    • एक टीम NPM से जुड़े काम Apple containers के अंदर ही करती है, और Python व Rust को भी उसी तरह ले जाने की योजना बना रही है
      इसे रासायनिक प्रयोगशाला के PPE जैसा बताया गया—जैसे वहाँ सुरक्षा उपकरण चाहिए, वैसे ही development environment में isolation और protection चाहिए
      pip भी पहले ही virtualenv के बाहर install को रोकना शुरू कर चुका है, और उम्मीद है कि आगे package managers sandbox के बाहर execution को मना करने वाला option देंगे
    • किसी ने कहा कि वह तो Node.js/npm को सिस्टम पर इंस्टॉल ही नहीं करता. अब तक उसे कभी इसकी अनिवार्य ज़रूरत नहीं पड़ी

  • pnpm और bun अब डिफ़ॉल्ट रूप से postinstall scripts को ignore करते हैं, लेकिन npm अब भी उन्हें चलाता है
    ~/.npmrc में ignore-scripts=true सेट करना अच्छा है
    npm अभी भी हर हफ़्ते 8 करोड़ downloads दर्ज करता है

  • यह अटकल भी लगाई गई कि इस incident में credentials leak संभवतः LiteLLM के पहले वाले incident से जुड़ा हो सकता है
    Python या Node.js का इस्तेमाल असुरक्षित लग सकता है, लेकिन वास्तव में यह एक व्यापक समस्या है

    • न्यूनतम रिलीज़ अवधि सेट करना मददगार है, लेकिन फिर भी dependency updates डरावने लगते हैं
    • कुछ लोगों ने कहा कि LiteLLM से ज़्यादा Trivy incident असली जड़ कारण था
    • नुकसान की सीमा घटाने के लिए rootless temporary containers में execution का सुझाव भी दिया गया