Hugging Face malware campaign returns to hijack GPUs for crypto mining

Summary

A recurring malicious-model campaign used Hugging Face repositories to obtain code execution on GPU-equipped systems and deploy cryptocurrency miners, with reverse shells present in some variants. Pluto Security identified 31 malicious repositories across seven accounts, presented as small Qwen2 test checkpoints and aimed at self-hosted inference environments including Xinference and GPUStack. Execution depended on users enabling trust_remote_code, which allowed repository-supplied Python to run when the purported model loaded.^[0]

Repository removal did not end the operation. After Hugging Face and ModelScope removed first-wave accounts, 19 second-wave repositories appeared under new accounts within days. The flagship model reached 28,412 downloads by October 28, and the combined count exceeded 32,000 with linked models included. These are download figures, not verified infections. By the article's October 29 publication, the flagship was disabled, but BleepingComputer reported that the near-identical htt0118/qwen2-tiny copy remained live and contained the same miner and reverse shell.^[0]

The payload behavior extends beyond unauthorized resource consumption. The flagship contained no actual model; its code installed a miner disguised as a Linux system process, restarted it after termination, and removed competing miners. Some variants provided reverse-shell access, and a later repository carried a script described as capable of container escape and underlying-host takeover. The supplied account establishes publication of that capability, not a confirmed successful escape.^[0]

Pluto reported approximately $5,000 in Pearl cryptocurrency receipts to the operator's main wallet and continued mining-pool activity after repository removals. Its attribution to a financially motivated, Chinese-speaking operator remains a research assessment rather than a named-actor identification. All substantive findings available here come from one supplied BleepingComputer article, which attributes much of the technical investigation to Pluto and describes its own confirmation of the surviving repository copy.^[0]

Attack chain

1. 1. Publish malicious model repositories: The operator published repositories posing as small Qwen2 test checkpoints. The reported targets were GPU hosts using self-hosted inference services such as Xinference and GPUStack. The flagship MENXIANGYU/qwen2-tiny repository contained no actual model.^[0]
2. 2. Execute repository code during model loading: When a user loaded a malicious repository with trust_remote_code enabled, the repository's custom Python executed on the host. The campaign therefore used the model-loading workflow as its execution path rather than poisoned weights or a pickle exploit.^[0]
3. 3. Deploy and sustain mining, with variant-specific remote access: The executed code installed a cryptocurrency miner disguised as a Linux system process, restarted it if killed, and removed competing miners. Some versions also opened a reverse shell. These are reported payload behaviors; the source does not establish that every download led to execution or that every variant installed a backdoor.^[0]

Disclosure timeline

How it works

The execution boundary was the trust_remote_code setting. Enabling it permits a model repository to supply Python code that executes during loading. In this operation, that permission exposed the loading machine to attacker-controlled code before any useful model inference was required.^[0]

The malicious content did not need to be embedded in model weights or delivered through unsafe pickle deserialization. The flagship repository reportedly contained no actual model, making its apparent model identity a lure for executing the accompanying Python.^[0]

The miner's restart behavior and removal of competing miners supported continued use of the victim's resources, while reverse-shell variants created a separate remote-access risk. The source does not identify the restart mechanism or provide enough detail to assign a specific persistence implementation.^[0]

A later model included a script described as capable of escaping a container and taking control of the underlying server. No escape primitive, affected container configuration, vulnerability identifier, or successful escape observation is supplied, so this remains a reported variant capability rather than a characterized vulnerability.^[0]

The reported scanning gap concerned behavior in repository-supplied Python. Pluto said Hugging Face's antivirus and partner checks focused on known malware and unsafe model formats, while the second-wave flagship scanned clean. A clean model scan therefore did not establish that enabling its custom code was safe.^[0]

Indicators of Compromise

Key takeaways

• The central risk was authorizing execution of untrusted repository Python through trust_remote_code. This evidence does not establish a version-specific vulnerability in Xinference or GPUStack, and no software patch is identified.^[0]
• More than 32,000 combined downloads indicate distribution reach, not a verified victim count. Reported wallet receipts and observed mining activity provide separate evidence of monetization.^[0]
• Takedowns reduced availability but did not end the campaign: the operator returned under new accounts, a confirmed copy remained live, and mining-pool activity continued after repository removals.^[0]
• Response should address full host compromise, not only GPU consumption. Reverse shells, miner restart behavior, and the reported escape-capable variant make miner termination alone an inadequate endpoint.^[0]
• Attribution remains limited to Pluto's assessment of an unnamed, financially motivated Chinese-speaking operator. The supplied evidence does not support assigning a named threat group or treating language and hosting clues as a confirmed identity.^[0]

Defensive actions

• Identify systems that loaded the named repositories and determine whether trust_remote_code was enabled.: The reported execution trigger was model loading with remote code trusted. Repository download totals are not infection counts, so exposure assessment should distinguish retrieval from execution. The source advises treating systems that loaded these malicious models with the setting enabled as compromised.^[0]
• Prevent further loading of the identified malicious repositories and do not enable their repository-supplied code.: The flagship was removed, but a confirmed near-identical copy remained accessible. The campaign's rapid return under new accounts means removal of one repository did not eliminate the delivery path.^[0]
• Investigate reverse-shell access and the mechanism that restarts the miner rather than ending response after terminating mining processes.: The miner reportedly restarted after being killed, and some variants installed reverse shells. The article explicitly warns that killing the miner alone does not remove backdoors.^[0]
• Rotate credentials accessible from systems that executed the malicious model code.: The article recommends credential rotation because affected machines should be treated as compromised, and reverse-shell variants give the attacker direct access beyond the mining process.^[0]
• Review repository Python behavior before authorizing remote-code loading; do not use a clean platform scan as sufficient approval.: The campaign executed through custom Python rather than malicious weights or pickle exploitation. Pluto reported that the second-wave flagship scanned clean despite deploying malicious functionality.^[0]
• Where the reported escape-capable variant is identified, include the underlying host in the compromise assessment rather than assuming the container was the full boundary.: A later repository carried a script described as capable of container escape and server takeover. This warrants host-level assessment for that exposure, without assuming that an escape actually occurred.^[0]
• Check suspect systems against the indicators in Pluto's investigation in addition to the two repository identifiers available here.: The article explicitly recommends using Pluto's indicators. The supplied evidence does not reproduce the campaign's wallet addresses, mining endpoints, command-and-control hosts, or payload hashes, so those values cannot be safely enumerated in this dossier.^[0]