What happened
In a report published on October 29, 2026, Pluto Security described what it calls the Load/Mine campaign: malicious model repositories on Hugging Face presented as small Qwen2 test checkpoints. Pluto says it tracked 31 malicious repositories across seven Hugging Face accounts, as well as a ModelScope mirror. The repositories and linked models recorded more than 32,000 downloads. The report is explicit that downloads are not confirmed infections or unique victims.
The mechanism depends on the trust_remote_code=True path used by Transformers for models whose implementation is not included in the library. A repository can use config.json and its auto_map field to point the loader to a Python module and class. The loading process downloads and imports that module; Python executes top-level statements during import. Pluto's key point is therefore simple: a caller that grants this option permits the repository's Python to run with the caller's privileges before the weights are loaded. The campaign did not require a malicious weight file or a serialization exploit.
According to Pluto, the first-wave payload installed a Pearl cryptocurrency miner, made it appear as a kernel worker, used a watchdog, and removed competing miners. The report says a wallet associated with that wave received roughly 2,276 PRL, valued in the report at about $5,000. The researchers observed machines with notebook-like characteristics joining live workers in a closely timed group, but do not identify those machines or claim a count of victims.
Hugging Face and ModelScope removed the accounts reported in the first wave, Pluto says. A second wave appeared within days under four new accounts. It comprised 19 repositories, had more than 29,000 downloads, and was still live eight days after Pluto reported it. The later loaders replaced a hard-coded SSH key with reverse shells, added persistence, and in one later stage responded only to allow-listed IP addresses. That evolution matters because unauthorized access can persist after a miner itself is noticed or removed.
The report identifies self-hosted inference installations, especially Xinference and GPUStack, rented GPU machines, shared research notebooks, and CI jobs that retrieve small test models as likely target environments. It also argues that existing hub defenses leave a gap: antivirus scanned uploaded files and partner tools inspected weight formats, while the malicious behavior lived in Python surrounding the model. Pluto says its flagship payload scanned clean and that one scanner classified it as not being a machine-learning model. Its recommendation is to avoid trust_remote_code where possible and, where it is necessary, review and pin the remote code.
What the archive adds
This is a new fact on a known security thread. Our earlier Field Note, Agent sandboxes have become a critical boundary, argued that agent security is determined by runtime boundaries rather than a sandbox label. Pluto supplies a concrete model-hub ingress route: code can execute while a team believes it is merely loading a model artifact.
Trend signal
The report strongly supports Agent security moves to runtime boundaries. The relevant boundary is not an instruction to use a benign checkpoint, nor the apparent identity of a repository. It is the runtime permission granted when a loader imports external Python with host credentials, GPU access, filesystem access, and potentially network reachability.
Why now
The timing is explained by the campaign itself. Pluto reports that removal of the first repositories did not end activity: a second wave returned within days with changed loaders and reverse shells. The same report also describes a practical ecosystem condition: evaluation, serving, notebook, and CI workflows can pull small models automatically, while existing scanning concentrates on weights and known serialization hazards rather than repository Python behavior.
Connections to other events
The earlier Field Note on agent sandboxes is directly relevant because autonomous systems often install packages, execute commands, read files, and call services. This incident is adjacent but distinct: the initial code execution can happen at model-loading time, before an agent begins its task. A sandbox remains valuable, but it should not be mistaken for provenance review or a reason to grant a model repository host-level privileges.
Why it matters
Many AI teams treat a model identifier as data: choose a checkpoint, fetch it during a benchmark or deployment, and let the framework resolve what it needs. This report says that assumption fails when custom remote code is enabled. The operational unit to assess is the whole repository and the exact revision, including configuration and Python files—not only model weights or a malware scan result.
The highest-risk environments combine unattended retrieval with valuable execution privileges. A CI runner may carry cloud credentials; a notebook may have access to data and tokens; a GPU serving host may be reachable from production systems. The miner is costly, but the reported reverse shells are the more consequential signal: resource theft can be visible, whereas retained interactive access creates a broader incident-response problem. Teams need an explicit exception process for custom model code, not an informal flag added to make a model load.
What happens next
- Model-loading workflows will add review and revision-pinning controls for custom repository code. (3 months, 75%). Watch for: serving and evaluation templates treating remote code as an approval-gated dependency.
- Hub and ecosystem scanners will expand attention from weight formats to code referenced by model configuration. (6 months, 65%). Watch for: published scanning coverage for
auto_maptargets and repository Python.
Limits and uncertainty
This is a security vendor's investigation of one campaign, not a census of malicious repositories or affected machines. The reported 32,000-plus figure counts downloads, including linked models; it does not establish infection rate, unique users, or the number of compromised organizations. The public material describes payload analysis and on-chain wallet activity, but it does not attribute the operators to a named person or group. It also does not establish that every use of custom model code is unsafe. trust_remote_code is documented functionality and may be required for legitimate architectures; the risk depends on what code is granted permission to run and in which environment.
Skill to build now
Audit every model-loading path this week. Search notebooks, CI definitions, evaluation harnesses, and serving configuration for trust_remote_code=True and for equivalent automatic remote-module loading. For each occurrence, record the repository revision, inspect config.json, auto_map, and referenced Python files, then decide whether the custom implementation is genuinely required. Move unavoidable loads into a minimally privileged isolated runtime: no long-lived secrets, constrained filesystem access, limited network egress, and no implicit access to production services. Treat a model update that changes repository code like a dependency update requiring review.
Reader takeaway
A model hub can deliver executable software, not just parameters. In the reported campaign, apparently small Qwen2 test models became a route to GPU mining and remote access because a loading option authorized repository Python before inference began. Pin, inspect, and isolate custom model code—especially in automated GPU workflows.
Open question
Will major model hubs and serving frameworks make analysis of configuration-referenced Python a visible, default part of their safety signals, rather than leaving that review entirely to each loader?