Malicious code in pyyi (PyPI)

The verified PyPI wheel declares a console command named python2 (pyyi.cli:main). For commands other than the local REPL, help, version, unlock, or uninstall paths, it obtains configuration and calls run_payload(). Registration sends the hostname and OS to a configured space-z.ai server and stores the returned apiKey in ~/.python2/config.json. The REPL presents a normal Python banner but silently sends eligible single-token inputs to /api/cli/unlock as the password field, subject to filtering and attempt limits. run_payload() fetches code from /api/cli/payload, base64-decodes and gzip-decompresses it, then executes it in memory using exec(compile(src, '<adv>', 'exec'), g) at pyyi/cli.py:640 and calls its main function. Loader failures are disguised as Python's can't open file error. The malicious assessment is based on the combination of interpreter impersonation, concealed input transmission, remote code execution, and deliberate failure concealment, rather than encoding or exec alone. Static review and isolated, network-disabled mock tests confirmed the input-to-request and response-to-execution data flows using synthetic canaries and payloads. No live endpoint was contacted, and the actual server-supplied payload and its subsequent behavior remain unknown. Wheel SHA-256: 003828175a747a9a3de8029e6a028ad2c3739abf1dad7b468b25636e391e91f4.

-= Per source details. Do not edit below this line.=-

Source: amazon-inspector (9cf00d6eaf64906d3dc7feaf25f521d20d150832a04df89ecde5c667a4ac3d2d)

The package advertises itself as a 'cryptographic modules' library (README references pyyi.generate_key() / pyyi.encrypt()) but ships none of that API — init.py only defines version. The real payload is a console_scripts entry registered as the literal name python3.7, which on PATH shadows the user's real Python 3.7 interpreter and is also written to /usr/local/bin/python3.7, ~/.local/bin/python3.7, and %LOCALAPPDATA%...\python3.7.exe. When invoked, the CLI resolves an obfuscated destination (base64 ciphertext XORed with a 16-byte hex key, stored in _ENC_NET and decoded only at runtime by _baked_hosts), POSTs to <server>/api/update, and if a payload field is returned, base64-decodes and gzip-decompresses it and runs exec(compile(src, '<adv>', 'exec'), g); g['main'](argv) with no pinning, signature, or hash check — the remote operator chooses what Python code runs on the host. The CLI also stands up a fake REPL (_GateConsole) that reproduces the real Python {sys.version} on {sys.platform} banner and reads input with terminal echo disabled via _quiet_read; single-token entries are treated as candidate passwords and POSTed as {apiKey, password} to the same obfuscated endpoint (op=2), with accepted values persisted locally XORed by a per-machine key. The combination of a cover-story package description, interpreter impersonation on PATH, obfuscated C2 destination, unauthenticated in-memory exec of server-supplied code, and an echo-off password-capturing fake REPL constitutes installer-side remote code execution and credential theft.