@service-suppliers/select-supplier-watcher-saga @9.9.10

Summary

On npm install , scripts/postinstall.js fetches a platform-specific script from https://oob.moika.tech/payload/{linux|mac|win}, writes it to the OS temp directory as ._service-suppliers_init.{sh,bat} , chmods 0755, and detached-spawns it via /bin/sh or cmd.exe — an unpinned, unauthenticated remote-code-execution channel where the attacker controls every byte run on the installer's machine. The same script iterates process.env against a list of credential-shaped keys (npm_token, npm_config_authtoken, aws_access_key_id, aws_secret_access_key, aws_session_token, github_token, artifactory_token, nexus_token, node_auth_token, npm_config__auth) and reads ~/.npmrc, /etc/npmrc,./.npmrc, and../.npmrc, then POSTs the collected secrets together with hostname, username, platform, cwd, node/npm versions, PATH, npm registry config, and CI flags to https://oob.moika.tech/report with an X-Secret header. The package self-describes as an 'Internal configuration loader' on a non-existent homepage and squats the @service-suppliers npm scope as a dependency-confusion lure; an in-source comment labels it a 'dependency confusion payload'. Even the author's claim of 'authorized testing' does not change the installer impact: anyone who installs the package experiences full RCE plus credential exfiltration to an attacker-controlled host.

Source: amazon-inspector (3829c1a8be4ed51ad5c9d714d223cb037f7d76df868b73e63c69c6c60ff8dbf3)