Pluto finds 31 malicious Hugging Face model repositories

Pluto Security has reported 31 malicious repositories across seven Hugging Face accounts in a campaign targeting machines that execute code supplied with AI models. The investigation puts the risk for businesses at the model-loading step, before a successful inference request or an obvious increase in GPU use.

The October 29 report, co-authored by Shaked Chen, Eitan Chassid and Yotam Perkal, describes cryptomining and backdoor payloads and a return after takedowns. “The code runs before the model does,” the researchers wrote. Their report is the primary account of the campaign; its findings should be attributed to the researchers rather than presented as an independently reproduced IC test.

The authors report more than 32,000 downloads across the campaign and linked models. Downloads are not confirmed infections, unique victims or a measure of business losses. A reader cannot use that number to estimate how many organisations were compromised without additional evidence about execution and the machines involved.

The mechanism is important because model repositories can contain executable Python as well as weights. Hugging Face's own Transformers security policy distinguishes risks from remote artifacts and remote code. For models requiring custom code, it tells users to verify the modelling files before enabling trust_remote_code and recommends setting a revision to protect against repository updates.

That guidance supports two separate controls. A model-file format addresses how weights are stored and loaded. Reviewing the Python addresses what executable instructions the loading process is permitted to run. Hugging Face recommends safetensors for safer model artifacts, but that recommendation does not turn separately authorised repository code into trusted code. A purchase or deployment review that checks only the weight format leaves a different question unanswered.

For AI platform owners, the immediate task is to establish which repositories and revisions were actually executed. A catalogue showing that a model was downloaded cannot, on its own, establish execution; a failed load cannot establish that no Python ran. Installation records, job configuration and the exact revision used are consequently more decision-relevant than a familiar model-family name.

Pluto advises investigating machines that loaded the listed repositories with custom code enabled, preserving evidence, checking persistence and replacing exposed credentials from a clean system. It says a clean scan does not settle the issue and recommends rebuilding when host integrity cannot be established. Those recommendations concern exposed environments, not every user of the hosting platform.

The operational comparison is between removing the model artifact and restoring confidence in the host. Deleting a cached download answers whether that copy remains available. It does not by itself show whether startup settings, credentials or access paths changed during execution. An incident record should therefore state which question each check resolves, and which uncertainty remains, before the machine returns to production.

For European businesses running shared research systems, automated model jobs or self-hosted inference, the broader purchasing implication is a need for traceability. Record the model, publisher, reviewed code and pinned revision alongside the environment allowed to run it. That creates a basis for investigating a specific alert without either ignoring executable code or declaring an entire model ecosystem compromised.

Sources

• Pluto Security — original Load/Mine investigation — Primary source
• Hugging Face — Transformers security policy — Primary source