Hugging Face Cryptomining Campaign Surpasses 32,000 Downloads With 19 New Repositories After Takedown

A cryptomining campaign distributed through malicious repositories on Hugging Face returned to activity days after the initial takedown, with 19 new repositories bringing the total to 31. The mechanism exploits trust_remote_code=True to execute Python code on victims' GPU servers. The operation has surpassed 32,000 total downloads, with a single model reaching 28,412 downloads as of October 28, 2026. Eight days after the initial report, some repositories remained live.

The Mechanism: auto_map Before Weights

The technical core of the operation lies in a documented feature of Hugging Face's Transformers library. When a user sets trust_remote_code=True, loading a model executes the Python code referenced in the auto_map field of config.json via exec_module(), before even accessing the model weights.

Pluto Security verified that the campaign's repositories — masquerading as Qwen2-tiny checkpoints — contain 305-line modeling_evil.py files in initial versions, reduced to 37 lines in SSH-backdoor variants. These files are not analyzed by the platform's security systems, which focus on serialized models and traditional exploits like pickle deserialization.

The initial payload installs peakminer, a miner disguised as the kernel process kworker/u20:1. The 40.6 MB binary is packed with UPX but with modified markers — PEK! instead of UPX! — to avoid automatic decompression. It launches via memfd_create and fexecve, leaving no executables on disk.

"reviewing the .py files an auto_map points to before the flag is set would have caught every payload in the campaign" — Pluto Security

32,376 Downloads and a Wallet Worth About $5,000

The main campaign collected 29,818 downloads, rising to 32,376 including linked repositories, according to Pluto Security's counts. The most-downloaded model, MENXIANGYU/qwen2-tiny, reached 28,412 downloads by October 28, 2026 — 97.7% of the second wave's downloads — passing "scanned clean" despite the active payload. The count rose from 7,354 on October 20 to 28,412 on October 28, as documented by screenshots verified by BleepingComputer.

The economic impact is verifiable on-chain. The operator's wallet received approximately 2,276 PRL, valued around $5,000, with 716 transactions in the first wave and roughly 2,241 PRL forwarded subsequently. According to Pluto Security, about $2,237 comes from 30-day rewards on the Kryptex pool, with activity continuing even after repository removal.

Pluto observed nine machines in a shared GPU cluster start mining simultaneously, stopped after about six minutes — likely by an admin killing the jobs. This confirms actual infections are significantly lower than downloads: many users do not enable trust_remote_code or download without executing.

Second Wave: Container Escape and Rapid Persistence

The operator's reaction to the takedown was swift. Within days of the initial removal, 19 second-wave repositories appeared. The repository MENXIANGYU/qa-whl-1021, published 8.5 hours after email disclosure to Hugging Face, contained container-escape scripts that mounted host disks and targeted /var/lib/gpustack — indicating awareness of ML deployment environments.

A clone on the htt0118 account, created October 25, was still live at the time of BleepingComputer's verification with the same payload. The second-wave dropper responds with static ip. and status 403 to requests from unauthorized IPs, limiting dynamic analysis.

Later campaign versions added a reverse shell to C2 servers on Alibaba Cloud (212.32.253.3:443/9443), expanding post-infection from pure mining to persistent remote access.

Why Scanners See Nothing

The security blind spot is structural. Hugging Face's checks employ ClamAV and model scanners oriented toward pickle exploits, but do not analyze the behavior of Python code referenced by auto_map. JFrog, asked by Pluto about the nature of the files, responded that they are "not a machine-learning model" — correct on format, useless on threat.

Hugging Face's official documentation admits scanners are "not 100% foolproof." Pluto Security demonstrated that manual review of .py files pointed to by auto_map before setting the flag would have intercepted every payload in the campaign. No equivalent automated system is currently in production on the platform.

Pluto cites CVE-2026-22807 for vLLM as related: this vulnerability allows bypassing the trust_remote_code flag under specific deployment conditions, amplifying the attack surface for similar campaigns.

What to Do Now

The following section lists indicators of compromise documented in the Pluto Security report, not official platform recommendations.

Pluto Security identified these elements in the technical report:

• Processes kworker/u20:1 with anomalous resource consumption in environments where a kernel worker with that pattern is not expected
• Outbound connections to 212.32.253.3 on ports 443 or 9443
• config.json files with an auto_map field referencing non-standard .py modules for the declared model
• Binaries launched via memfd_create without a corresponding file on disk

Pluto Security noted in the report that "reviewing the .py files an auto_map points to before the flag is set would have caught every payload in the campaign." This is a retrospective observation on detection techniques, not a direct operational instruction to users.

Analysis: The Broader Pattern

Verified Facts: The documented campaign shows rapid evolution from pure mining to container escape, with reaction times to takedown measured in hours. The operator maintained profitable mining activity for weeks, with traceable on-chain earnings.

Analysis: The structure of this operation — abuse of legitimate features, mimicry in standard workflows, immediate monetization, and post-takedown return — represents a replicable model on model-hosting platforms that do not verify supporting code. Reliance on trust_remote_code for specialized models makes simple deactivation impractical without breaking legitimate functionality.

Verification Limits and Sources

The full technical analysis comes from the Pluto Security report published on unite.ai. BleepingComputer's independent verification is limited to the live payload of the htt0118/qwen2-tiny clone, the main model's download count, and confirmation that the repository was still live after the report. Attribution to a Chinese-speaking, financially motivated operator is based on simplified Chinese comments, Alibaba Cloud C2 servers, and activity hours — indicators Pluto presents as assessment, not definitive proof.

The download count does not equal confirmed infections: Pluto explicitly states many users download without enabling trust_remote_code.

Sources

• unite.ai
• bleepingcomputer.com
• blog.netmanageit.com