Malicious code in mev-shield (npm)
-= Per source details. Do not edit below this line.=-
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.
왜 이 VPI인가 (설명가능 · 실험적)
VPI 산정 기준
| 영향도(기본값(정보 없음)) | 55.00 |
| 악용 신호(추가 악용신호 없음) | ×1.00 |
| VPI | 55.00 |
VPI 공식 vpi-v1 기준