Mini Shai-Hulud ने फिर किया हमला: 314 npm पैकेज compromise

 (safedep.io)
5 पॉइंट द्वारा GN⁺ 2026-05-21 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • atool npm अकाउंट 19 मई 2026 को compromise हो गया, और लगभग 22 मिनट के दौरान 317 पैकेजों में 637 malicious versions अपने-आप deploy किए गए
  • payload 498KB की obfuscated Bun script है, जो SAP compromise में इस्तेमाल हुए Mini Shai-Hulud जैसी scanner संरचना और regex का उपयोग करती है
  • चोरी का दायरा AWS credentials, Kubernetes tokens, Vault, GitHub PAT, npm tokens, SSH keys, और local secrets तक फैला हुआ है
  • CI में GitHub Actions OIDC को npm publish token में exchange किया जाता है, और Sigstore signing व malicious workflow injection का दुरुपयोग किया जाता है
  • प्रतिक्रिया के लिए यह जांचना ज़रूरी है कि कहीं compromised version install तो नहीं हुआ, जिन credentials तक पहुंच संभव थी उन्हें बदलना होगा, और lockfile·dependency pinning व install से पहले inspection की जरूरत है

हमले का सारांश

  • atool npm अकाउंट (i@hust.cc) 19 मई 2026 को compromise हुआ और लगभग 22 मिनट के दौरान 317 पैकेजों में 637 malicious versions publish किए गए
  • यह अकाउंट 547 पैकेज maintain कर रहा था, और हमलावर ने उनमें से कम-से-कम 314 पर दो बार version bump किया
  • प्रभावित पैकेजों में size-sensor (मासिक 42 लाख downloads), echarts-for-react (38 लाख), @antv/scale (22 लाख), timeago.js (11.5 लाख), और कई @antv scope पैकेज शामिल हैं
  • payload 498KB की obfuscated Bun script है, और 3 हफ्ते पहले SAP compromise में इस्तेमाल हुए Mini Shai-Hulud toolkit जैसी scanner संरचना, credential regex, और obfuscation patterns का उपयोग करती है
  • चुराया गया data या तो public GitHub repositories में Git objects के रूप में commit किया जाता है, या RSA+AES से encrypt किए गए HTTPS POST के जरिए t.m-kosche[.]com पर भेजा जाता है

वितरण का तरीका और semver जोखिम

  • पहली लहर में 19 मई 2026 को 01:39~01:56 UTC के बीच लगभग 317 versions publish किए गए, और दूसरी लहर में 02:05~02:06 UTC के बीच उन्हीं पैकेजों पर लगभग 314 version bumps किए गए
  • ज़्यादातर 309 पैकेजों को हर लहर में एक-एक करके ठीक 2 malicious versions मिले
  • size-sensor, echarts-for-react, jest-canvas-mock, jest-date-mock इन 4 पैकेजों को 3 versions मिले, जिससे लगता है कि इन्हें शुरुआती testing में इस्तेमाल किया गया
  • हमलावर ने ज़्यादातर पैकेजों में latest dist-tag नहीं बदला, लेकिन npm semver resolution latest से अलग range के भीतर सबसे ऊंचा version चुनता है
  • उदाहरण के लिए, अगर echarts-for-react का latest 3.0.6 पर ही रहे, तब भी "echarts-for-react": "^3.0.6" वाला project अगले clean install पर malicious version 3.2.7 पर resolve हो सकता है

execution path और payload

  • सभी tampered versions ने package.json में version bump के साथ "preinstall": "bun run index.js" जोड़ा
  • 637 malicious versions में से 630 ने optionalDependencies में @antv/setup: github:antvis/G2#<commit-sha> जोड़कर दूसरी payload copy fetch कराई
  • preinstall hook dependency install से पहले चलता है और Bun runtime की मांग करता है
  • अगर preinstall block हो जाए या skip हो जाए, तब भी GitHub impersonation commit की prepare script दूसरी execution path के रूप में बची रहती है
  • index.js एक single-line 498KB obfuscated Bun bundle है, जिसमें SAP compromise में इस्तेमाल हुए Mini Shai-Hulud payload जैसी Bun requirement, hex-variable obfuscation, 100KB flush-threshold scanner संरचना, और credential regex set मौजूद है
  • CI environment detection GitHub Actions, Jenkins, GitLab CI, CircleCI, Travis, Buildkite, Drone, TeamCity, AppVeyor, Bitbucket Pipelines, CodeBuild, Azure DevOps, Netlify, Vercel सहित 20 से अधिक platforms के environment variables जांचती है

credential collection के लक्ष्य

  • payload encrypted नामों वाले 80 से अधिक environment variables पढ़ता है, और file contents को regex से scan करता है
  • मुख्य targets में GitHub token, npm token, GitHub Actions JWT, AWS key, Azure key, DB connection string, Stripe key, SSH key, Docker auth, Vault token, Kubernetes token, और URL embedded credentials शामिल हैं
  • file scanner home directory में .ssh, .aws/credentials, .npmrc, .docker/config.json, .kube/config जैसी standard credential locations पढ़ता है
  • यह AWS credential resolution order को पूरा follow करता है, EC2 IMDSv2 और ECS container credential endpoint से IAM role credentials लाता है, और AWS STS GetCallerIdentity व Secrets Manager access की भी कोशिश करता है
  • Vault के लिए token file और VAULT_ADDR, VAULT_TOKEN, VAULT_ROLE आदि की जांच की जाती है, और valid credential मिलने पर secret enumeration तथा AWS·Kubernetes authentication की कोशिश की जाती है
  • Kubernetes के लिए service account token और KUBECONFIG की जांच की जाती है, और अगर Docker socket मौजूद हो तो host के containers enumerate करके container escape की कोशिश की जाती है

C2 और data exfiltration

  • GitHub API को C2 की तरह इस्तेमाल किया जाता है, GET /user से चुराए गए GitHub tokens verify किए जाते हैं और GET /user/orgs से organizations enumerate की जाती हैं
  • repo या public_repo permission वाले tokens हमलावर के exfiltration repositories बनाने में इस्तेमाल किए जाते हैं
  • बनाए गए repository का description उल्टे string niagA oG eW ereH :duluH-iahS के रूप में रखा जाता है, जो सीधा करने पर “Shai-Hulud: Here We Go Again” बनता है
  • repository names harkonnen-melange-742, fremen-sandworm-315, gesserit-navigator-508 की तरह Dune-theme वाले 2 शब्द और एक संख्या जोड़कर बनाए जाते हैं
  • exfiltrated data को Git Data API के जरिए blob, tree, commit, ref update क्रम में store किया जाता है
  • अलग HTTPS sender hxxps://t.m-kosche[.]com/api/public/otel/v1/traces को OpenTelemetry OTLP trace ingestion endpoint जैसा दिखाने के लिए configure किया गया है
  • HTTPS payload gzip JSON को AES-256-GCM से encrypt करता है, और AES key को hardcoded public key से RSA-OAEP wrapping के जरिए सुरक्षित करता है

CI/CD और trust chain का दुरुपयोग

  • चुराए गए tokens जिन GitHub repositories तक पहुंच सकते हैं, वहां से workflow run history, artifacts, secret names, branch lists, और Claude Code settings जुटाए जाते हैं
  • GitHub API से secret values तक पहुंच नहीं मिलती, लेकिन secret names यह दिखा देते हैं कि कौन-से credentials मौजूद हैं
  • malicious workflow .github/workflows/codeql.yml में inject किया जाता है, इसका नाम Run Copilot होता है और यह push पर trigger होता है
  • workflow VARIABLE_STORE: ${{ toJSON(secrets) }} के जरिए repository secrets को JSON के रूप में environment variable में डालता है, format-results.txt में save करता है, और फिर artifact के रूप में upload करता है
  • इसके बाद artifact zip download किया जाता है, और workflow run deletion व branch ref reset से injection के निशान कम किए जाते हैं
  • GitHub Actions OIDC वाले CI में https://registry.npmjs.org/-/npm/…; endpoint के जरिए npm publish token exchange की कोशिश की जाती है
  • payload में Fulcio, Rekor, और SLSA provenance formats सहित Sigstore signing implementation मौजूद है, जिससे compromised CI identity से signed artifacts बनाए जा सकते हैं

डेवलपमेंट एनवायरनमेंट और AI कोडिंग एजेंट संक्रमण

  • पेलोड GitHub API के जरिए remote injection और filesystem write के जरिए local infection का उपयोग कर Claude Code, Codex और VS Code एनवायरनमेंट को निशाना बनाता है
  • चुराए गए टोकन से जिन repositories तक पहुंच संभव होती है, उनमें .vscode/tasks.json, .claude/index.js, .claude/settings.json, .claude/setup.mjs, .vscode/setup.mjs को commit किया जाता है
  • .claude/settings.json SessionStart hook रजिस्टर करता है ताकि हर बार Claude Code session शुरू होने पर node .claude/setup.mjs चलाया जाए
  • .vscode/tasks.json में "runOn": "folderOpen" प्रोजेक्ट folder खुलते ही execution trigger करता है
  • setup.mjs GitHub official release से Bun v1.3.14 डाउनलोड करता है, binary extract करता है, और फिर पेलोड चलाता है
  • local infection path पेलोड को ~/.claude/package/index.js और ~/.codex/package/index.js में copy करता है, और मौजूदा project config files को scan करके hook inject करता है
  • Apple Silicon Mac पर यह local infection path छोड़ दिया जाता है, जबकि Linux, Intel Mac और Windows पर यह चलाया जाता है

persistence और GitHub dead-drop C2

  • kitty-monitor के रूप में छिपा persistence daemon Linux पर systemd user service के रूप में और macOS पर ~/Library/LaunchAgents/com.user.kitty-monitor.plist के रूप में install होता है
  • installer systemctl --user enable --now और loginctl enable-linger का उपयोग करता है ताकि logout के बाद भी यह बना रहे
  • cat.py daemon हर 1 घंटे में GitHub Search API को poll करता है और firedalazer keyword वाले commits खोजता है
  • commit message format firedalazer <base64_url>.<base64_signature> होता है, और hardcoded 4096-bit RSA public key से RSA-PSS signature verify करने के बाद URL की Python code को execute किया जाता है
  • अलग gh-token-monitor daemon चुराए गए GitHub tokens को 60-second interval पर poll करता है, और TTL 24 घंटे है
  • process memory scanner Linux पर /proc/pid/maps+mem और Windows पर ReadProcessMemory का उपयोग करके GitHub Actions runner worker process की readable memory regions को dump करता है

antvis/G2 की नकल करने वाले commit

  • 637 malicious versions में से 630 में optionalDependencies entry शामिल है जो antvis/G2 repository के एक specific commit को point करती है 
    {
  "optionalDependencies": {
    "@antv/setup": "github:antvis/G2#1916faa365f2788b6e193514872d51a242876569"
  }
}
  • जब npm github: dependency resolve करता है, तो वह उस commit को fetch करता है, package.json ढूंढता है, और lifecycle scripts चलाता है
  • उस commit में @antv/setup घोषित करने वाला package.json और prepare script शामिल है, साथ ही वही Shai-Hulud पेलोड दोबारा obfuscate की गई 499KB index.js के रूप में मौजूद है
  • prepare script में && exit 1 optional dependency को fail कर देता है, लेकिन npm optional dependency failure को fatal नहीं मानता, इसलिए installation जारी रहती है
  • Git API दिखाता है कि antvis/G2 पर push किए गए 3 अलग commit SHA मौजूद हैं, और तीनों किसी branch से जुड़े नहीं हैं
  • तीनों commits एक ही metadata साझा करते हैं: author huiyu.zjt <Alexzjt@users.noreply.github.com>, commit message New Package, 0 parents, और कोई GPG signature नहीं
  • हमलावर antvis/G2 पर write permission के बिना fork में payload orphan commit बनाकर और fork delete करके parent repository namespace में ऐसा commit छोड़ सकता है जिसे SHA से fetch किया जा सके
  • यह तरीका उसी तरह का है जैसा GitHub Actions में नकली commit समस्या पर Chainguard ने document किया है, लेकिन यहां इसे npm github: dependency resolution पर लागू किया गया है

compromise indicators

  • 2026-05-19 01:44~02:06 UTC के बीच atool (i@hust.cc) द्वारा publish किए गए packages जांच के दायरे में हैं
  • preinstall script bun run index.js है
  • पेलोड SHA256 a68dd1e6a6e35ec3771e1f94fe796f55dfe65a2b94560516ff4ac189390dfa1c है
  • antvis/G2 की नकल करने वाले commits इस प्रकार हैं
    • 1916faa365f2788b6e193514872d51a242876569 — 626 versions
    • 7cb42f57561c321ecb09b4552802ae0ac55b3a7a — 2 versions
    • dc3d62a2181beb9f326952a2d212900c94f2e13d — 1 version, garbage collected
  • network IoC में hxxps://t.m-kosche[.]com/api/public/otel/v1/traces, 169.254.169.254 EC2 metadata, 169.254.170.2 ECS container metadata requests शामिल हैं
  • repository IoC में chore/add-codeql-static-analysis branch, Run Copilot workflow, और toJSON(secrets) को format-results.txt में dump करने वाला .github/workflows/codeql.yml शामिल है
  • डेवलपमेंट एनवायरनमेंट IoC में .claude/settings.json का SessionStart hook, .vscode/tasks.json का "runOn": "folderOpen", .claude/setup.mjs, .vscode/setup.mjs शामिल हैं
  • persistence IoC में kitty-monitor.service, com.user.kitty-monitor.plist, ~/.local/bin/gh-token-monitor.sh, ~/.local/share/kitty/cat.py, /var/tmp/.gh_update_state शामिल हैं

जांच के लिए प्रमुख packages

  • compromised-packages.csv तालिका में Package और Compromised Versions नाम के 2 columns हैं, और तालिका के अनुसार 317 packages दिखाए गए हैं
  • lockfile में इन packages और 2026-05-19 को publish किए गए malicious versions की मौजूदगी जांचनी चाहिए
  • प्रमुख @antv packages और malicious versions
    • @antv/g2: 5.5.8, 5.6.8
    • @antv/g6: 5.2.1, 5.3.1
    • @antv/g: 6.4.1, 6.5.1
    • @antv/l7: 2.26.10, 2.27.10
    • @antv/x6: 3.2.7, 3.3.7
    • @antv/s2: 2.8.1, 2.9.1
    • @antv/f2: 5.15.0, 5.16.0
  • सामान्य npm packages और malicious versions
    • echarts-for-react: 3.0.7, 3.1.7, 3.2.7
    • size-sensor: 1.0.4, 1.1.4, 1.2.4
    • jest-canvas-mock: 2.5.3, 2.6.3, 2.7.3
    • jest-date-mock: 1.0.11, 1.1.11, 1.2.11
    • timeago.js: 4.1.2, 4.2.2
    • timeago-react: 3.1.7, 3.2.7
    • @lint-md/cli: 2.1.0, 2.2.0
    • @lint-md/core: 2.1.0, 2.2.0
    • @lint-md/parser: 0.1.14, 0.2.14

प्रतिक्रिया और बचाव

  • अगर compromised version इंस्टॉल हुआ था, तो build environment से एक्सेस किए जा सकने वाले npm token, GitHub PAT, AWS key, SSH key, cloud credentials, database password, Vault token, Kubernetes service account token, और local password manager के secret values को बदलना चाहिए
  • t.m-kosche[.]com को network और DNS स्तर पर block करना चाहिए
  • यह जांचना चाहिए कि build environment से एक्सेस किए जा सकने वाले token वाले GitHub accounts के तहत कोई unauthorized public repository बनाई गई है या नहीं
  • CI pipeline में unauthorized package publish और npm OIDC token exchange logs की समीक्षा करनी चाहिए
  • यह देखने के लिए Sigstore transparency log जांचना चाहिए कि compromised CI identity से बनाए गए signed artifact मौजूद हैं या नहीं
  • local Node.js project में .claude/settings.json hook, .vscode/tasks.json auto-run task, .claude/setup.mjs, .vscode/setup.mjs की जांच करनी चाहिए
  • kitty-monitor systemd user service और com.user.kitty-monitor LaunchAgent को हटाना चाहिए, और ~/.local/share/kitty/cat.py, /var/tmp/.gh_update_state, ~/.local/bin/gh-token-monitor.sh की मौजूदगी की जांच करनी चाहिए
  • dependencies को pin करना चाहिए या lockfile का उपयोग करना चाहिए ताकि semver range resolution किसी malicious version तक न पहुंच जाए
  • CI/CD pipeline में Docker socket exposure और EC2 metadata access का audit करना चाहिए, और IMDSv2 hop limit restriction पर विचार करना चाहिए
  • Package Manager Guard (pmg) एक open source install proxy है जो preinstall चलने से पहले package को threat intelligence से मिलान करता है
  • dependency cooldown configurable time window के भीतर deploy किए गए version को reject करता है, जिससे semver range के नए malicious release में resolve होने से पैदा होने वाली अचानक deployment wave को कम किया जा सकता है
  • vet unexpected preinstall hook, size spike, maintainer change जैसे abnormal package update को CI/CD pipeline तक पहुंचने से पहले detect कर सकता है
  • एक ही account के तहत 547 package, और एक session में weaponize किए गए 314 से अधिक package का impact range npm trust model की structural weakness को उजागर करता है

संदर्भ सामग्री

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

2 टिप्पणियां

 
GN⁺ 2026-05-21
Hacker News की टिप्पणियाँ

  • अब NPM lifecycle scripts को डिफ़ॉल्ट रूप से disable होना चाहिए
    सुविधा के नाम पर इसमें मनमाना code execution built-in है, और यह transitive dependencies पर भी लागू होता है। बड़े पैमाने पर फैले सभी NPM worm-शैली के हमले इसी default setting के ज़रिए फैले हैं। ऐसा नहीं होना चाहिए कि किसी खास command में एक बार इसे on करने से सभी transitive dependencies lifecycle scripts चला सकें; जिन dependencies को सच में इसकी ज़रूरत हो, उन्हें अलग से स्पष्ट रूप से mark करना चाहिए
    ज़्यादातर NPM packages इन scripts पर निर्भर नहीं हैं, इसलिए अगर अभी तक नहीं किया है तो इसे globally off कर देना बेहतर है

    • इसके लिए एक RFC है: https://github.com/npm/rfcs/pull/868
    • या फिर बस pnpm इस्तेमाल कर लो
    • सही। या फिर इसे sandbox के अंदर चलना चाहिए। अगर यह installed package के अपने context में मनमाने commands चलाने वाला post-install script हो तो ठीक है, लेकिन मनमानी scripts और user privileges का मेल आपदा का नुस्खा है
      हालांकि package पहली बार program में import होने पर भी जो चाहे बेकार चीज़ें चला सकता है

  • “इसे रोका नहीं जा सकता” जैसी बात सिर्फ़ उसी package manager के बारे में कही जाती है जहाँ ऐसी घटनाएँ नियमित रूप से होती रहती हैं

    • NPM सबसे लोकप्रिय package manager है, यह बात अलग; लेकिन क्या कोई और वजह भी है जो इसे ऐसे हमलों के लिए खास तौर पर ज़्यादा संवेदनशील बनाती है?

  • किसी बिंदु पर क्या Dependabot को बंद करके NPM packages को minor/patch versions तक पूरी तरह pin कर देना लगातार update करते रहने से बेहतर नहीं हो जाता?
    खासकर frontend packages में आजकल meaningful security fixes supply-chain attacks की तुलना में कम दिखते हैं
    यह दुखद स्थिति है, लेकिन frontend को एक static BOM में बदलकर और यह मानकर चलने में कि NPM कम से कम “पुराने version को दोबारा publish नहीं किया जा सकता” वाला नियम ठीक से लागू करता है, क्या कोई समस्या है?

    • फिर compliance team इस बात पर परेशान होगी कि patch उपलब्ध होने के बावजूद एक CVSS 3.1 वाला CVE unpatched पड़ा है
    • Maturation period लागू कर दो। जैसे 30 दिन से नए versions को किसी भी pull request में आने की अनुमति ही न हो
      ज्ञात CVE ठीक करने वाले versions के लिए exception रखा जा सकता है
    • सही, यही उन वजहों में से एक है जिनसे दूसरे ecosystems में supply-chain attacks कम दिखते हैं
    • क्या NPM hashes और pinned transitive dependencies सहित पूर्ण lockfile नहीं बनाता?

  • हालात दिन-ब-दिन पागलपन की तरफ़ जा रहे हैं। मैंने तो निजी तौर पर अपनी मशीन से node, python, और सभी package managers हटा दिए हैं, और अब सिर्फ़ devcontainer या VM के अंदर ही इस्तेमाल करता हूँ
    अगर developer community बहुत मज़बूत सुरक्षा भी बना ले, तब भी डर है कि कम से कम एक साल के भीतर models की social engineering क्षमता इतनी अच्छी हो जाएगी कि यह फिर भी हारने वाला खेल बना रहेगा

    • अगर models social engineering में बहुत माहिर भी हो जाएँ, तो भी सिद्धांततः उसका असर इतना बड़ा क्यों होगा, यह मुझे साफ़ नहीं लगता। इसमें diminishing returns हैं, और target का मानव गति से चलना एक बहुत बड़ा bottleneck लगता है
      उदाहरण के लिए XZ hack में भारी मेहनत लगी थी, और वह मौजूदा maintainer को समय के साथ थकाने के तरीके पर आधारित था, इसलिए उसे तेज़ नहीं किया जा सकता था। ज़रूरी malicious messages को कुछ सेकंड में बनाकर भेजा जा सकता है, लेकिन उन्हें पढ़ने वाले इंसानों की गति तेज़ नहीं होती, और अगर सब एक साथ पहुँचें तो उल्टा शक पैदा होगा
      input कितना convincing हो सकता है, इसकी भी एक सीमा है। XZ maintainer को भेजे गए किसी भी random malicious message को लेकर उसे और ज़्यादा निर्दयी, और ज़्यादा सटीक, और maintainer की निजी कमज़ोरियों व डर को बेहतर दर्शाने वाला बनाया जा सकता है, लेकिन क्या उससे कुल मिलाकर वह बहुत ज़्यादा असरदार हो जाता? शायद नहीं, या बहुत हुआ तो थोड़ा ही
    • container इससे समस्या कैसे हल करता है? अगर वह इंटरनेट से जुड़ा है, और व्यावहारिक रूप से तो होता ही है, तो जब तक container credentials पढ़ सकता है तब तक वही समस्या बनी नहीं रहती?
    • node के बिना cloud resources को कैसे control करते हो? Cloudflare के लिए wrangler चाहिए, और AWS में भी कई node CLI हैं

  • अब जब Zed 1.0 हो गया है, मैं पूरी तरह migrate करना चाहता हूँ, लेकिन मेरी जानकारी में उसका security model सब-कुछ-या-कुछ-नहीं वाला है। या तो मुझे अनजान NPM packages को मनमाने ढंग से download और install करने देना होगा, या फिर सारे LSP features बंद करने होंगे
    और फिर ऐसी ख़बरें बार-बार दिखती रहती हैं

  • क्या npm ऐसा program चला सकता है जिसमें package upload को अपने-आप लगभग 10 मिनट delay किया जाए, और उस दौरान उसे तीसरे पक्ष की code auditing companies के ecosystem में भेजकर automated checks कराए जाएँ?
    कौन-सा auditor सबसे तेज़ और सबसे भरोसेमंद ढंग से समस्याएँ पकड़ता है, इसका public leaderboard बनाया जा सकता है, या monetary rewards दिए जा सकते हैं

  • यह सूची अधूरी है। कम से कम एक और package, nx-console VS Code extension, भी कल इस worm से संक्रमित हुआ था और उसके 22 लाख downloads हैं
    अगर credentials और network access वाला कोई व्यक्ति यह पढ़ रहा है, तो यह देखने के लिए उसकी dependency chain भी trace करना फ़ायदेमंद हो सकता है कि और कुछ है या नहीं। संदर्भ यहाँ है:
    https://github.com/nrwl/nx-console/security/advisories/GHSA-...
    PS: संक्रमण के तुरंत बाद लोगों को बताने के लिए मैंने इसे HN पर पोस्ट किया था, लेकिन दुर्भाग्य से इसे लगभग कोई upvotes नहीं मिले

  • पूरे ecosystem को देखें तो TC39 को JS में ही बेहतर standard library जोड़ने के तरीकों पर ध्यान देना चाहिए। इससे one-liner packages की संख्या घट सकती है
    सहमत। जब मैं पहले Deno पर काम करता था, तो सबसे अच्छी बात standard library[0] और कुल मिलाकर ज़्यादा complete development environment थी। runtime में integrated test runner और assertion library होना तो बिल्कुल स्वाभाविक लगता है
    0 - https://docs.deno.com/runtime/reference/std/

    • निष्पक्ष रूप से कहें तो Node भी कई LTS versions से डिफ़ॉल्ट रूप से node:test [0] और node:assert/strict [1] modules देता है। node --test आसानी से Mocha की जगह ले सकता है, और node:assert/strict भी ठीक है, हालांकि chai कभी-कभी ज़्यादा सुविधाजनक लगता है। expect जैसी usability की वजह से। Deno के @std में expect-style assertion library है
      समस्या यह है कि Node ecosystem में test runners बहुत ज़्यादा हैं, और उनमें से काफ़ी को Mocha की तरह आसानी से replace नहीं किया जा सकता। इसलिए built-in test harness और assertion library की तरफ़ migration स्वाभाविक रूप से दर्दनाक और धीमा होगा। लोग कई कारणों से Jest और Vitest की ज़रूरत से ज़्यादा जटिल प्रकृति को पसंद करते हैं। बड़ी कंपनियों को Karma एक अच्छा विचार लगा था। “आपको unit testing के लिए V8 पसंद है? तो लीजिए, आपके मौजूदा V8 environment के अंदर हम V8 की एक और copy चला देते हैं” — इस सोच से और ज़्यादा developers को चिढ़ क्यों नहीं हुई, यह आज तक समझ नहीं आया
      [0] https://nodejs.org/api/test.html
      [1] https://nodejs.org/api/assert.html#strict-assertion-mode
    • यहाँ बताए गए packages में से कौन-सा “बेहतर standard library” में जाएगा, यह मुझे स्पष्ट नहीं है
      किस language standard library में “3 घंटे पहले” जैसे format converter होते हैं? timeago.js वही करता है
      slice.js सिर्फ़ Python-जैसी negative indexing देता है। TC39 पहले ही array.at() और array.slice() को negative values संभालने योग्य बना चुका है
    • आजकल Node.js standard library भी लगातार बड़ी हो रही है, और इसमें ऊपर बताए गए assertions और testing support शामिल हैं, यह बात उल्लेखनीय है
      https://nodejs.org/api/

  • बात यह है कि payload Docker socket को check करता है, और अगर वह मिले तो तीन क्रमिक तरीकों से container escape की कोशिश करता है
    इसलिए devcontainer या VM के अंदर चलाने पर भी ऐसे worms बाहर निकलने की कोशिश पहले से कर रहे होते हैं
    यह सुनिश्चित करना चाहिए कि आप rootless VM engine इस्तेमाल कर रहे हैं। जैसे Docker की जगह podman

    • कुछ लोग, यहाँ तक कि security industry के लोग भी, चाहे कुछ भी कहें, Docker कोई मजबूत security boundary नहीं है और उसे ऐसा मानना नहीं चाहिए। यह running system और kernel को share करता है
      इससे वह ज़माना याद आता है जब लोग कम-privilege Linux accounts बाँट देते थे और भरोसा करते थे कि kernel privilege escalation रोक देगा। Docker मूल रूप से वही चीज़ है, बस और प्रक्रियात्मक परतों के साथ। खासकर आजकल तो नए kernel local privilege escalation bugs मानो हर 5 मिनट में आ रहे हों
      Podman इस मायने में थोड़ा बेहतर है कि वह attacker को root नहीं देता, लेकिन शुरू से ही account देना क्यों? सीधे एक proper VM इस्तेमाल करो
    • container के अंदर Docker socket mount ही मत करो
    • काश हमारे पास jails या zones के क़रीब कुछ होता। उससे भी बेहतर, containers को किसी jail या zone के अंदर चलाने जैसा मॉडल होता
      क्या Linux में BSD जैसी कोई व्यापक sandboxing है?
    • सीधे एक proper virtual machine क्यों नहीं इस्तेमाल करते?
    • क्या ज़्यादातर लोग Docker को rootless mode में नहीं चलाते, कम से कम Linux पर? क्या podman उससे भी कुछ ज़्यादा करता है?

  • अब मैं Mr Bones' Wild Ride से उतरना चाहता हूँ, लेकिन डर है कि यह सब चलता ही रहेगा। मैंने जितना देखा है, कई commercial detection strategies package को load या use करने के समय repository/device/developer स्तर पर केंद्रित हैं
    यह email spam या सामान्य malware से निपटने के तरीकों जैसा लगता है। इसलिए लगभग हमेशा ऐसे targets मौजूद रहेंगे जो malicious actors के लिए कोशिश करते रहने लायक़ होंगे। लेकिन email के विपरीत, package managers केंद्रीकृत प्राधिकरण वाले होते हैं, और out-of-band समस्याएँ आसानी से developers की ज़िम्मेदारी बताकर टाली जा सकती हैं
    बाहर से देखने पर लगता है कि शायद हमें तेज़ releases और ढीली versioning culture से हटकर registry में स्थिर और गहराई से जाँचे गए versions पर ध्यान देना चाहिए। मात्रा और scale के प्रभाव की वजह से मैं ग़लत भी हो सकता हूँ, लेकिन यह अब भी संकेतक है कि ज़्यादा churn वाली languages अधिक बार प्रभावित होती दिखती हैं
    काश इस पूरे मौजूदा परिदृश्य पर कोई व्यापक लेख मिलता

    • मैं यह देखने गया कि क्या Mr Bones' Wild Ride 1991 की फ़िल्म Nothing But Trouble का reference है, लेकिन मेरी याद ग़लत निकली
      उस फ़िल्म के roller coaster का नाम Mr Bonestripper था: https://www.youtube.com/watch?v=NEZEgd8GjJc
      इसके बजाय यह Roller Coaster Tycoon 2 से आया है: https://knowyourmeme.com/memes/mr-bones-wild-ride
      spam की तुलना के हिसाब से, हम लगभग सभी commercial और social computer network environments में email addresses को खींचकर spam को लोगों द्वारा स्वीकार्य बनाने और उसे वैधता की सतही परत देने की दिशा में कुछ हद तक बस चुके हैं। इस क्षेत्र में भी कुछ वैसा ही होने की संभावना काफ़ी है। शायद Oracle license monitoring agents जैसे software और automated dependency management का मिश्रण — यानी दूसरे malware को allowlist करके supply-chain malware को “हल” करना — जैसा कुछ
 
tangokorea 2026-05-21

rhwp के मामले में, Shai-Hulud की वजह से कुछ दिन पहले npm deployment पक्ष से two-factor authentication करने वाला एक मेल मिला था और मैंने two-factor authentication सेट कर लिया। साथ ही मैं vscode और open vsx चैनलों पर भी publish करता हूँ, इसलिए यह मेरे लिए भी पराया मामला नहीं है.
फ़िलहाल कई चैनलों के ज़रिए publish करने की प्रक्रिया लगातार ज़्यादा मेहनत और समय लेने लगी है। खासकर JavaScript में remotely separated obfuscated payload + legitimate services के ज़रिए communication करके घुसपैठ करने की तकनीक automation pipeline की कमज़ोरियों को निशाना बनाती है, इसलिए manual process को और भी कम नहीं किया जा सकता.
लागत के नज़रिए से भी यह बड़ा नुकसान है। अच्छी नीयत से किया जाने वाला open source योगदान, गलती से malicious hackers के रास्ते के रूप में इस्तेमाल हो सकता है, और इसलिए यह भरोसा नहीं किया जा सकता कि आगे इससे भी बड़ी घटना नहीं होगी.
क्या बस deployment channels को कम कर देना ही जवाब होगा?