Fake AI Models on Hugging Face Turn GPUs Into Miners

What Pluto Security published

Pluto Security published its Load/Mine report on October 29, 2026. The report tracks a cryptomining and backdoor campaign on Hugging Face. Hugging Face is a popular hub for sharing AI models. The campaign used 31 malicious repositories across seven accounts. It also used a mirror on ModelScope. The campaign ran in two waves since September 2026.

The models pose as small Qwen2 test checkpoints. Qwen2 is a well known family of language models. The most downloaded one is MENXIANGYU/qwen2-tiny. Its model file is 42 bytes long and holds no tensors. A tensor is the data a model uses to run. The file is a stand in, not a model. That repository alone reached 28,412 downloads by October 28, 2026.

How the code runs

The code runs through a documented loading option. The option is trust_remote_code. When enabled, it imports the repository Python code with the caller privileges. It runs before any weights load. The repository config file names the Python module to load. The import step runs the file top level code first. No poisoned weights are needed. No pickle exploit is needed. Pickle is a file format that can hide code.

This is documented behavior, not a default. Hugging Face guidance tells users to verify modeling files before enabling the option. That check only works when someone reads the code. Small test models often skip that review. Shared notebooks and CI jobs pulled these models without reading them.

What the payload does

The payload installs a watchdog first. The watchdog restarts a missing miner every 120 seconds. Shell startup hooks relaunch the watchdog. The miner runs disguised as a kernel worker thread. Three builds add a reverse shell as well. A reverse shell gives the attacker direct access to the host. Backdoor access outlasts the miner. Killing the miner does not remove that access.

The first wave payout wallet received about 2,276 PRL on chain. That is roughly $5,000. The wallet stayed active after its repositories were removed. Live workers kept reporting to mining pools. Downloads across the campaign and linked models passed 32,000. That figure counts downloads, not confirmed infections or unique victims. Do not present it as a victim count.

Why takedown did not end it

Pluto reported the first wave to Hugging Face and ModelScope. Both platforms removed the accounts. A second wave appeared within days under new accounts. The second wave holds 19 repositories. Those repositories recorded more than 29,000 downloads. They were still live eight days after Pluto reported them. Removing named accounts did not end the activity. New accounts carried revised loaders and reverse shells.

Hub scanners missed the payload. Hugging Face scans uploads with antivirus tools. Partner scanners inspect weight formats. Nothing analyzed what the model Python code does. The flagship payload scanned clean on every scanner that ran. One scanner reported it was not a machine learning model at all.

A related flaw in vLLM

Serving tools made the same mistake in code. The record is CVE-2026-22807. Common Vulnerabilities and Exposures (CVE) is the record system for public flaws. The flaw affected vLLM versions from 0.10.1 up to the fix in 0.14.0. Those versions loaded auto_map modules without checking the remote code setting. A malicious model could then run code at server startup. The fix is version 0.14.0. If you serve models with vLLM, check your version against that range.

What is not claimed

This is not a breach of Hugging Face itself. No platform intrusion is reported. The campaign abuses an option that users enable. It also does not prove every download led to an infection. Some downloads may be researchers or scanners. Treat the download count as exposure, not as a compromise count.

What to do this week

Find every model your team loaded with remote code enabled. List the publisher, the repository, and the date. Read the Python files for any model you still run. Look for subprocess calls, sockets, and memory execution calls. Check GPU hosts for the watchdog path and for miners disguised as system threads. If a listed model was loaded, treat the host as suspect. Rebuild it and rotate its credentials. A miner that stops is not proof the host is clean.

Then set a rule for the future. No remote code for an unreviewed model. Pin each model to a reviewed version. Record the review with the model inventory. A model list with no review record is a gap.

The governance lesson

AI models are third party code, not data. A model that can run code needs the same vetting as any software package. Your inventory must list models by name and version. It must record who reviewed the code and when. It must record the loading settings for each model. An assessor will ask how you vet code that runs on your hosts. A download count with no review record cannot answer that ask.

PolicyCortex does not scan AI models. PolicyCortex helps teams link proof to requirements. That proof is what an auditor or assessor asks for.

Sources

• Pluto Security, Hugging Face Malware Campaign: Load/Mine, published October 29, 2026
• CVE-2026-22807 record, CVE Program
• National Vulnerability Database (NVD) record for CVE-2026-22807
• BleepingComputer, Hugging Face malware campaign returns to hijack GPUs, October 2026
• Original diagram by PolicyCortex

Next step

Want model and software inventory evidence collected on a schedule, not by spreadsheet? See how PolicyCortex reads it from the live tenant.