ASIC hardware

Fake Hugging Face models return after takedown, stealing GPU time for mining

Source report: 2026-10-29 · Editorial analysis published: 2026-10-31

Pluto’s October 29 Load/Mine report tracks 31 campaign repositories and more than 32,000 downloads including linked models. Downloads are not confirmed infections; the risk comes from running the repository’s custom code, not from an official Qwen release.

The unwanted workload arrived through a model loader

Pluto Security’s October 29 Load/Mine report describes a cryptomining and backdoor campaign distributed through model repositories on Hugging Face. The researchers say it returned within days after accounts were removed. For a reader running AI work alongside mining or renting GPU capacity, the practical issue is ownership of the workload: electricity and compute can be consumed for someone else’s mining account.

The repositories imitated small Qwen2 test checkpoints. This is not evidence that the official Qwen releases or Hugging Face itself deliberately supplied a miner. The route described in the report was permission to run a repository’s custom Python while loading a model. A trusted hosting domain or familiar model-family name does not establish who published that particular repository or what its code will do.

The download count is not a victim count

The report distinguishes 31 repositories in the core campaign from 13 linked model repositories. Its table records 29,818 downloads for the campaign and 2,558 for linked models, 32,376 overall, as of October 28. That supports “more than 32,000 downloads including linked models,” not 32,000 confirmed compromised computers, unique users or infected organisations.

Pluto also describes pool and blockchain observations supporting actual mining activity. Those observations show why the campaign is more than a harmless upload, but they do not turn every recorded download into a victim. Repository status and infrastructure observations have their own dates in the research. This article does not claim to have contacted the malicious servers or verified which listings are still active today.

Code can run before model weights are used

Model weights are the numerical data used by an AI model. Some repositories also provide a custom implementation in Python. The documented trust_remote_code=True option allows that implementation to run with the loading process’s permissions. In the analysed campaign, malicious startup code ran before model initialisation, so even a failed loading attempt could leave the host affected.

This is different from saying all model loading executes remote code by default or that the attack requires a poisoned weight file. The report’s example used the custom-code path. A safer weight format such as safetensors addresses a different part of the package; it does not certify a neighbouring Python file. Review the executable component and the permission being granted, not only the filename of the weights.

Hugging Face documents malware and pickle scanning, including their limitations. A clean scanner result can be useful evidence about a particular check, but it is not a promise that every action of a custom program is safe. The report says the analysed files passed the scans that ran. Treat the identity and reviewed revision of the code as part of the dependency decision, rather than replacing that decision with a green badge.

Stopping the miner may leave access behind

Pluto describes persistence and backdoor capabilities as well as the mining payload. In plain language, persistence lets unwanted code restart, while a backdoor gives an attacker another route into the environment. The campaign changed its access methods after takedowns. Closing the miner process or deleting a model entry therefore does not by itself establish that the host has returned to a trustworthy state.

For a GPU host, the cost can include lost capacity, a cloud bill and exposure of credentials reachable by the compromised process. That is a potential exposure scope, not a claim that every affected account lost every secret. Keep an expected-workload record: unexpected GPU use is worth investigating, while normal-looking utilisation is not enough to rule out a loader that already ran.

A practical response for shared GPU environments

If one of the identified models was loaded with custom code enabled, the researchers recommend checking the host even if loading failed. Contain the affected environment, preserve relevant process, connection and job records, and review the other machines that loaded the same revision. Avoid running the suspect model again merely to reproduce the warning or compare its output with a clean model.

Use a clean machine to revoke or replace credentials the compromised process could reach, and review their recent use. Assess startup entries, scheduled jobs and access keys as part of removing persistence. If the host’s integrity cannot be established, rebuild from a trusted image. These are defensive recovery steps; there is no reason to share a wallet recovery phrase with someone offering a quick miner-cleaning service.

For the replacement workflow, use limited privileges, restricted network access and no production secrets while evaluating untrusted code. Review and pin the exact model revision before allowing custom execution. Removing a repository can reduce distribution, but it cannot undo code that already ran on a GPU server. The useful lesson for a miner is to keep control of both the work consuming the hardware and the software allowed to start that work.

Source: Pluto Security ↗ · Hugging Face malware-scanning documentation ↗ · Hugging Face pickle-scanning limitations ↗