A cryptomining and backdoor campaign that abuses Hugging Face model repositories came back within days of being taken down, according to BleepingComputer’s report on research from Pluto Security. Pluto found 31 malicious repositories across seven Hugging Face accounts, published in two waves since September and posing as small Qwen2 test checkpoints. The most popular, MENXIANGYU/qwen2-tiny, was downloaded 28,412 times by October 28. Pluto notes that downloads are not confirmed infections.
The models carry no poisoned weights. They abuse the trust_remote_code option, which lets a model ship its own Python code that runs as soon as the model loads. The most downloaded one contained no real model at all: its code installs a cryptocurrency miner disguised as a Linux system process, restarts it if killed, and removes competing miners. Some versions also open a reverse shell, and one later script can break out of a container. The campaign targets GPU hosts running self-hosted inference servers such as Xinference and GPUStack. Pluto says Hugging Face’s scans passed the second-wave flagship as clean, because they look for known malware and unsafe model formats rather than what a model’s Python code does, and attributes the operator to a financially motivated, Chinese-speaking group. Hugging Face has disabled access to the flagship model, but BleepingComputer confirmed that a near-identical copy under the account htt0118 was still live at publication.
BleepingComputer’s article also covers a separate report from Air Security about a fake Solana starter kit on GitHub that is positioned to trick AI coding agents into running a PowerShell one-liner that installs the NetSupport Manager remote-access tool. That repository has been live since late 2025, according to BleepingComputer.
How to check if you’re affected
Affected products are self-hosted inference servers, such as Xinference and GPUStack, on machines that loaded any model with trust_remote_code enabled. Pluto’s report says to check these hosts even if loading failed or GPU usage looks normal, because the payload runs before model initialization and its backdoors can outlast the miner.
- Look for the directory
/tmp/.cch/, unexpectedsvc.pyprocesses, and a process named[kworker/u20:1]that carries mining arguments. - Inspect Xinference registrations for encoded
qwen2-tiny-orezv-names, and review connections to the servers and mining pools listed in Pluto’s indicators. - Isolate the machine and capture process details, logs and model cache files before deleting anything. Killing the miner or deleting the model does not remove persistence.
- Check shell startup files, cron jobs and SSH
authorized_keysfor unauthorized changes, rebuild from a trusted image if you cannot establish the host’s integrity, and rotate tokens, cloud credentials and SSH keys the machine could reach.
Pluto’s report also advises requiring authentication on the Xinference API and reviewing the .py files a model’s auto_map points to before enabling trust_remote_code.