Hugging Face Malware Campaign: Load/Mine

Summary

Pluto Research describes Load/Mine as a cryptomining and backdoor campaign distributed through Hugging Face model repositories disguised as small Qwen2 checkpoints. The report tracks 31 malicious repositories across seven Hugging Face accounts, with a second wave appearing within days of first-wave account removals. Backup source files, shared payload behavior and reuse of a payout wallet connect the activity across account changes.^[0]

The compromise occurs when a user or serving workflow permits repository-supplied Python to execute, typically through trust_remote_code=True. The repository configuration directs Transformers to import a malicious module whose top-level code runs before model initialization. The analyzed payload establishes a watchdog and startup persistence, launches a disguised miner and, in selected variants, opens reconnecting reverse shells. A separate campaign payload attempts to move from a privileged container onto its host.^[0]

The report recorded 29,818 downloads for the core campaign and 32,376 including separately linked models as of October 28, 2026; these figures do not establish infection or victim counts. Stronger evidence of monetization comes from the reported first-wave wallet activity: approximately 2,276 PRL received across 716 transactions, with mining workers still active after repository removal. The principal exposure is self-hosted GPU infrastructure, including Xinference and GPUStack environments, shared notebooks and automated model-loading workflows.^[0]

All campaign findings here derive from the single supplied Pluto report. Its assessment of a financially motivated, Chinese-speaking operator is not a named-actor attribution, and it leaves open whether the parasit payload line belongs to another operator. The operational priority is broader than stopping mining: investigate any affected custom-code load, preserve evidence, remove backdoors and persistence, and replace credentials accessible to the compromised process.^[0]

Attack chain

1. 1. Repository presentation and custom-code execution: The operator publishes repositories resembling small Qwen2 models. When custom code is permitted, config.json auto_map entries direct Transformers to the supplied Python module. Importing the representative modeling_evil2.py invokes _boot() before the model class is defined; malicious weights are unnecessary, and the flagship's model.safetensors file contains no tensors.^[0]
2. 2. Establish persistence and, in selected builds, remote access: The representative loader writes /tmp/.cch/svc.py and starts it as a separate watchdog process using the loading process's Python interpreter. It adds relaunch hooks to shell-startup files. The qwen2-tiny-5, -6 and -9 variants additionally begin with a separate reconnecting reverse-shell process targeting 212.32.253.3 on port 443 or 9443; this is variant-specific, not a capability established for every repository.^[0]
3. 3. Acquire the miner: The loader checks the downloaded model snapshot and then /tmp/.cch/sync for an existing miner. If neither supplies it, the loader downloads syscore.bin from a repository or mirror. Its downloader ignores configured HTTP_PROXY and HTTPS_PROXY settings, avoiding those proxies only where direct outbound connectivity is permitted.^[0]
4. 4. Execute under a kernel-worker disguise: The first launch attempts to copy the binary into a memfd-created anonymous file and execute it with fexecve using [kworker/u20:1] as its displayed name. An on-disk fallback at /tmp/.cch/sync supports subsequent launches. Userspace command-line arguments, including the mining login, distinguish the masqueraded process from a real kernel thread.^[0]
5. 5. Report progress through Xinference: The payload writes model registrations named qwen2-tiny- followed by base32-encoded status information. Receipts distinguish startup, binary acquisition, successful primary or fallback execution, launch failures and watchdog recovery. An operator with access to the exposed Xinference API can retrieve these registrations; heartbeat receipts also carry GPU-utilization data.^[0]
6. 6. Retain compute and restore interrupted mining: After establishing its own miner, the payload removes competing model registrations and startup commands and kills matching processes. The watchdog checks every 120 seconds and restarts a missing miner, making termination of the mining process alone insufficient remediation.^[0]
7. Separate payload branch: privileged-container-to-host access: The qa-whl-1021 script is an alternative campaign payload, not a demonstrated next step on every mined host. From a privileged container, it activates LVM volumes, mounts candidate host disks, identifies the host root or GPUStack's /var/lib/gpustack directory and establishes attacker root login on the underlying host.^[0]

Disclosure timeline

How it works

The campaign abuses an explicit custom-code trust boundary rather than demonstrating a campaign-specific CVE. With trust_remote_code=True or interactive authorization, Transformers resolves config.json auto_map entries, downloads the referenced Python and executes it through the module loader. Top-level statements run before the requested model class is retrieved, with the loading process's privileges.^[0]

The payload is independent of malicious serialization or poisoned tensors. In MENXIANGYU/qwen2-tiny, auto_map selects modeling_evil2.EvilModel, while the 42-byte model.safetensors file contains no tensors. Consequently, failed model initialization or use of a safer weight format does not establish that the Python payload never ran.^[0]

The memory-backed launch reduces executable-path visibility but does not make the compromise artifact-free. The loader executes an anonymous memfd object under a kernel-worker-like name, while retaining /tmp/.cch/sync for fallback execution and watchdog relaunch. Process arguments and the persistent files remain useful investigation surfaces.^[0]

The 40,625,780-byte second-wave syscore.bin uses modified UPX packing metadata. At offsets 0x000000ec and 0x026be650, the expected UPX! markers were replaced with PEK!, causing routine upx decompression to reject the file without preventing its embedded loader from running. Pluto reports that restoring the markers allowed unpacking and identification of peakminer.^[0]

The reporting mechanism repurposes local Xinference model registrations as status storage. B and P mark startup and binary acquisition; OK, OK2 and OK3 distinguish primary launch, fallback launch and watchdog recovery. DLN and NM indicate acquisition or launch failure, and H is written every fifth watchdog cycle with GPU-utilization data. Retrieval requires operator access to the exposed API.^[0]

Delivery has two investigation-relevant restrictions. The downloader suppresses environment-configured proxies but cannot bypass a network that enforces proxy use. Separately, the second stage on 212.32.253.3 port 8898 is source-IP gated, so an analyst receiving a 403 response with static ip. has not established that an allowed host receives no payload.^[0]

The report attributes the clean scanning results to a coverage mismatch: signature scanning examines repository files, while partner tools focus on model-file threats, but the attack resides in executable Python referenced by auto_map. Pluto reports clean results for the analyzed malicious loaders, including a result classifying the flagship Python file as not a machine-learning model.^[0]

Indicators of Compromise

Key takeaways

• This is a model-repository software-supply-chain campaign, not evidence that a particular tensor format or campaign-specific CVE must be patched. The decisive trust decision is permission to import publisher-controlled Python.^[0]
• Repository removal did not end the activity: the report documents replacement accounts, revised access methods and continued wallet activity. Host remediation must address persistence and credentials independently of repository status.^[0]
• The 32,376-download figure includes linked models and cannot be converted into a victim count. Pool workers and wallet transactions support active monetization, but the supplied evidence does not establish the number of compromised organizations or machines.^[0]
• Maintain attribution boundaries. Core campaign connections include shared payload history, infrastructure and a wallet, while the hl family and other technique-linked publishers are not all proven to share an owner. The report establishes no named threat actor.^[0]
• Clean file-scanning results and failed analyst downloads are weak negative evidence here: malicious Python scanned clean, and a later stage selectively served payloads according to source IP.^[0]

Defensive actions

• Identify machines that loaded the reported repositories with custom code enabled, including loads that failed or produced no visible mining activity.: The malicious module executes before model initialization, and backdoor access can survive after mining stops. Review model-loading records and cached repository code rather than relying solely on successful inference or elevated GPU utilization.^[0]
• Hunt across host, process, network and Xinference-registry evidence before declaring an exposed system clean.: The report recommends checking /tmp/.cch/, unexpected svc.py processes, kernel-worker-like processes carrying mining arguments, encoded registry receipts, attacker SSH keys and connections to the reported infrastructure. Variant differences mean that absence of a single artifact does not rule out compromise.^[0]
• Isolate affected machines, restrict outbound connectivity and preserve evidence before deleting payloads.: The campaign includes remote shells and persistent watchdogs. Capture process details, connections, logs, model-cache files, startup modifications and model registrations, then check other machines that loaded the same repositories.^[0]
• Remove all persistence and remote-access routes, not just the mining process or downloaded model.: Inspect shell-startup files, cron jobs, SSH authorized_keys and model registrations; remove malicious loaders, miners, watchdogs and backdoors. Review suspicious deletions as well as additions because the payload removes competing miners and their startup entries. Rebuild from a trusted image if host integrity cannot be established.^[0]
• Rotate or revoke credentials accessible to the compromised process from a clean machine, and review their recent use.: A reverse shell runs with the loading process's access to files and credentials. Removing an implanted SSH key does not invalidate tokens, cloud credentials, passwords or private keys that the attacker may already have copied.^[0]
• Investigate the underlying host when exposure includes the qa-whl-1021 payload or a privileged container.: The escape script explicitly mounts candidate host storage and targets the host root or GPUStack data location to establish host root login. Container-only cleanup is therefore insufficient where this branch executed; apply the report's trusted-rebuild guidance if host integrity remains uncertain.^[0]
• Require authentication on the Xinference API and restrict its reachability.: The payload stores encoded infection status in model registrations that an operator can retrieve through an exposed API. The report specifically recommends authentication and reduced API exposure for replacement environments.^[0]
• Review repository Python before permitting custom code, pin the reviewed revision and isolate its runtime from production credentials and unrestricted network access.: The entry point is executable code referenced by auto_map, not necessarily a dangerous weight file. Pluto reports that inspecting those Python files would have exposed every analyzed payload. A clean scanner result is insufficient, and network restrictions must be enforced rather than relying only on proxy environment variables that the downloader ignores.^[0]