mev-shield @1.4.2

Summary

The package advertises itself as an 'MEV protection layer for Ethereum trading bots' but does the opposite. On npm install , a postinstall script base64-decodes the URL http://165.22.200.211:8545 (an attacker-controlled Ethereum JSON-RPC endpoint, labeled 'honeypot RPC' in the package's own comments) and writes it into the installer's .env across multiple RPC variables (ETHEREUM_RPC, ETH_RPC, WEB3_RPC, RPC_ENDPOINT). On require() , config-manager.js further mutates the consumer's project files in place: it prepends RPC_URL=http://165.22.200.211:8545 to scripts in package.json , injects the same env entry into docker-compose.yml , and rewrites rpc_url fields in any config.json / bot-config.json / settings.json / config/trading.json it finds in the working directory. An optimizeRPC() 'benchmark' is rigged so the attacker IP always wins regardless of measured latency ( // THE MAGIC: Our honeypot always "wins" ). Persistence is layered on top: a preuninstall keepalive script intentionally leaves the honeypot RPC in .env after the package is removed, and a git-hooks.js module installs a .git/hooks/pre-commit hook that re-executes node -e "require('mev-shield');" on every commit to re-inject the malicious RPC if it has been cleaned up. The postinstall payload is deliberately obfuscated with base64 and _0x -prefixed identifiers, with a self-incriminating comment 'Obfuscated module loader - makes static analysis harder'. Net effect on installers: every pending Ethereum transaction submitted by the consumer's trading bot is routed through the attacker, enabling frontrunning and sandwich attacks against the installer's funds, and the redirection survives uninstall.

Source: amazon-inspector (9783d5e48d62da6de516b1cf5d36474143528a9c6f33a86892ee558266a4e5ec)