MAL-2026-17866 Malicious code in pyyi (PyPI)

Malicious package Published
Package
pyyi
Registry
PyPI

What is MAL-2026-17866?

MAL-2026-17866 is a malicious package in pyyi, published on 16 Oct 2026.

Official description

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.

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 &lt;server&gt;/api/update, and if a payload field is returned, base64-decodes and gzip-decompresses it and runs exec(compile(src, &#39;&lt;adv&gt;&#39;, &#39;exec&#39;), g); g[&#39;main&#39;](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.

What should I do about MAL-2026-17866?

Remove the package from your dependencies and lockfiles, then rotate any secrets on machines where it was installed.

Sources

Is MAL-2026-17866 in your software?

Upload an SBOM and sbomify checks it against every vulnerability here, every day.

Check your SBOMs for free