mrmustard 0.7.4 PyPI release trojanized via maintainer account takeover; steals SSH, AWS and Kubernetes credentials

Linha do tempo

1. safedep.io ↗ · pub. 23/07/2026 21:00 · coletado 19/10 18:03 primeiro registro

   mrmustard 0.7.4 PyPI release trojanized via maintainer account takeover; steals SSH, AWS and Kubernetes credentials

   ler a análise desta fonte ocultar

   A malicious version 0.7.4 of the mrmustard photonic quantum computing library (Xanadu) was published to PyPI on July 23, 2026, after the account of the project's lead maintainer (ziofil, Filippo Miatto) was compromised. Importing the package reads SSH private keys, AWS credentials and the Kubernetes config, then sends them to an attacker-controlled C2. It also installs three persistence mechanisms that survive pip uninstall. The collection of SLURM, PBS and SGE state and GPU inventory points to deliberate targeting of research and HPC environments. Version 0.7.4 has no matching tag, release or commit in the XanaduAI/MrMustard GitHub repository, and PyPI has quarantined the project.

   Technical Details

   • The only functional change is a 258-line function, _check_tf_compatibility(), added to mrmustard/__init__.py (85 to 343 lines). It runs on import in a daemon thread and then deletes its own name from the module namespace. The rest of the release is identical to clean version 0.7.3.
   • The payload exits when CI environment variables (CI, GITHUB_ACTIONS, GITLAB_CI, JENKINS_URL and others) or container markers (/.dockerenv, cgroup strings) are present. This concentrates execution on developer and researcher machines.
   • It collects ~/.ssh private keys, ~/.aws/credentials, ~/.aws/config, ~/.kube/config, hostname, user, pip freeze, id, public IP (via ifconfig.me), nvidia-smi output, SLURM squeue output, and filtered environment variables (AWS_, KUBE, DOCKER_, TF_VAR_, CUDA, SLURM_, PBS_, SGE_ and others). Each item is capped at 8192 bytes.
   • The C2 URL is stored base64-then-XOR encoded with the key tf_compat_v2 and decodes to hxxps://metrics.femboy[.]energy/v1/collect. Data is XOR-encrypted, base64-wrapped as JSON and POSTed with a spoofed browser User-Agent.
   • A compiled, source-less ~/.cache/.tf_cache/hw_probe.pyc is launched by three hooks: a cron entry every 15 minutes, a ~/.bashrc, ~/.zshrc or fish config line labelled # tensorflow hardware compatibility check, and mmcompat.pth in site-packages. The .pth file runs the stealer on every Python invocation. On shared HPC nodes it affects every user of that site-packages directory.
   • Upstream, two commits under the ziofil account (2ebfe28 at 12:43 UTC and 80aba72 at 19:51 UTC) deleted seven legitimate workflows, probed self-hosted runners with whoami, and added a workflow that exfiltrated PIPY_TOKEN and CODECOV_TOKEN to a webhook.site endpoint. The malicious sdist was uploaded at 22:00 UTC, about two hours later. The article states that this timing is consistent with use of the stolen PyPI token but does not confirm it.

   Remediation

   • Treat any host that imported [email protected], ran Python while mmcompat.pth was present, or executed the cron or shell hook as compromised. Rotate SSH keys, AWS access keys and Kubernetes credentials, and review CloudTrail and cluster audit logs for use of those keys after July 23, 2026.
   • Delete ~/.cache/.tf_cache/, remove mmcompat.pth from every site-packages directory, strip the */15 crontab entry, and remove the # tensorflow hardware compatibility check block from shell rc files.
   • Treat PIPY_TOKEN and CODECOV_TOKEN as burned and rotate them. Inspect the self-hosted CI runner probed by the whoami workflow.
   • Audit .pth files for lines containing subprocess, Popen, exec or network calls. Block package versions that appear on a registry without a matching source-repository tag or commit.