Pluto Security links 31 malicious Hugging Face repositories to a miner and backdoor campaign that returned within days of takedown

Hugging Face lets a model ship its own Python code for architectures the Transformers library does not include. Loading such a model requires the caller to set trust_remote_code=True or accept a prompt. Pluto reports that the operator placed malicious code at the top level of those Python files, so it ran on import, before any model weights loaded. The flagship had no real model: its model.safetensors is 42 bytes, which Hugging Face's file listing confirms. Pluto says the payload writes a watchdog process and shell startup hooks, runs a miner from memory under the fake kernel name [kworker/u20:1], and removes rival miners. The first wave planted an SSH key, a login credential, in six paths. Among second-wave mining builds, Pluto attributes a reverse shell, an outbound connection that hands the attacker a command line, to three siblings (qwen2-tiny-5, -6 and -9), not to the flagship itself; a separate kit, zz_ext, also carries one. Pluto describes htt0118/qwen2-tiny as a near-identical copy of the -6 payload. BleepingComputer confirmed that copy contains the same miner and reverse shell, without describing its method. The Hub lists a syscore.bin in that copy with the size and SHA-256 hash Pluto published for the second-wave miner.

Pluto found the campaign on a scan for dangerous calls in model Python files. A throwaway account's leftover backup files pointed to hhzz667 on Hugging Face and wssb123e on ModelScope, a Chinese model-hosting service. Pluto reported the first wave to both platforms, and it says both removed the accounts. A second wave then appeared. Pluto reported it on October 20, and 8.5 hours after that email, it says, the operator published MENXIANGYU/qa-whl-1021, a script Pluto says is designed to escape a privileged container and give root login on the host. Pluto says the second-wave repositories were still live eight days after its report. It describes the payloads as written for GPU hosts running self-hosted Xinference and GPUStack servers, along with rented GPU machines, shared notebooks and automated test jobs.

Pluto assesses a financially motivated, Chinese-speaking operator or small group, citing Simplified Chinese code comments, command servers on Alibaba Cloud and activity late at night in China. That attribution is Pluto's; no platform or authority has confirmed it in the sources reviewed. Pluto also notes that one second-wave line carries Indonesian-language comments and a different build system, which could mean a second operator, and its indicator table does not mark that account "proven." Account names here are handles and have not been tied to any real person. This record is separate from IB-2026-002 (OpenAI / Hugging Face), a different event. The same BleepingComputer article also covers an Air Security report on a fake Solana kit aimed at AI coding agents, which is a distinct event and not part of this record.

Free Hugging Face account
  → public repository named like a small Qwen2 test model
  → config.json auto_map names a Python file
  → Hub scanning: antivirus signatures, plus partner scanners aimed at model files
  → listed and downloadable
  → a person, a tool or a job loads it with trust_remote_code=True
    [uncertain: Pluto does not say how the observed loads were triggered]
  → Transformers imports the Python file
  → top-level code runs with the loading process's permissions, before any weights load
  → watchdog and shell startup hooks
  → miner runs from memory as [kworker/u20:1]
  → in some builds: SSH key or reverse shell; separately, a container-to-host script
    [capability shown in code; no attacker session on a real machine documented]
  → Pluto says mining shares were paid toward wallets it links to the campaign
    [payments visible on chain; who owned the machines is unverified]

The published accounts do not describe a compromise of Hugging Face's own systems. The feature worked as documented, and the failure sat in the trust placed on it at two points.

The first is the user's opt-in. trust_remote_code is off by default, and the Transformers security policy tells users: "please always verify the content of the modeling files when using this argument." Pluto argues that tutorials copy the flag until it stops being a decision. It also cites tools that have loaded such code without the user choosing it, though it does not tie those flaws to this campaign.

The second is the platform's screening. Hugging Face runs every file under 2 GB through a malware scanner at each commit, and partner scanners from JFrog and Protect AI look for malicious behavior and exploits in models. Pluto reports that none of the 12 first-wave repositories was flagged and that modeling_evil2.py returned safe from every scanner that ran, with JFrog reporting "Not a machine-learning model". The Hub's per-file status on November 2 reads differently in part. ClamAV still reads safe and JFrog reads "unscanned" with the same message, but Protect AI marks that file and syscore.bin "unsafe" with threat code PAIT-EXDIR-100, VirusTotal marks syscore.bin "suspicious" at 5 of 76 engines, and the overall file status is "unsafe." The htt0118 copy carries the same flags while remaining enabled. These fields carry no date, so they do not show whether the flags existed when Pluto checked, and the Protect AI report link returned HTTP 404 here.

One further route is unresolved. Pluto says status reports are written into the local Xinference registry where an "operator with access to the exposed API" can read them, and it advises requiring authentication on that API. If the operator also triggered loads through exposed servers, some victims never opted in at all. Pluto does not state this, so it remains an open question rather than a finding.

The public records document mining activity and wallet receipts that Pluto links to the campaign. They do not establish who owned the worker systems or whether their use was unauthorized. Pluto reports the first-wave wallet received about 2,276 PRL across 716 transactions and sent about 2,241 PRL onward, and that its Kryptex page showed two online workers running the same peakminer client it recovered from the second-wave binary. The published screenshot shows those two workers under hexadecimal names and a third, offline worker running a different miner. Nothing on it identifies an owner, and the published evidence does not rule out machines the operator controlled or rented.

The wallet continued to receive PRL after the report. On November 2 the Pearl explorer listed 812 transactions and a balance of 371.91 PRL, against Pluto's 716 and an implied balance near 35 PRL. The 10 newest transactions, the only ones readable here, were receipts totaling 133.16 PRL displayed from November 1, 10:01 a.m. to November 2, 4:03 a.m. Meanwhile the Kryptex page showed no online or offline workers, 30.46 PRL in seven-day rewards and the same 940.8592 PRL total paid as Pluto's screenshot. The receipts therefore appear to come from elsewhere, and these records do not show whose machines earned them. The link between this wallet and the operator rests on Pluto's analysis.

Credential theft and data access remain capabilities in code, not documented losses. Pluto's indicators list collector, reconnaissance and cloud-metadata endpoints, and it warns that a shell gives access to the files and credentials of the compromised process. It reports no specific stolen data. It advises checking any machine that loaded these models and replacing credentials the process could reach, because killing the miner or deleting the model does not remove persistence. How many of the 28,412 flagship downloads ran code is unknown. A plain file fetch or a loader that refuses custom code would count as a download without running anything, and the growth of 21,058 in eight days on one repository, while every other second-wave repository stayed under 100, has no published explanation. The container-escape script shows 0 recorded downloads, but it is not a normal model load, so that figure may not measure its use.

Hugging Face. No public statement was found in its blog index, changelog, status history or the coverage reviewed, checked November 2; the status history lists no incident for October or November, though that page covers service outages. MATT reports the same absence. Its actions are visible in its records. Pluto says it removed the first-wave accounts after a report. The flagship was disabled between Pluto's October 28 status table and BleepingComputer's October 29 article, and its page now says, "Access to this model has been disabled" and "This content infringes our Content Policy". At the November 2 check, 18 of 19 second-wave repositories were disabled, as were 5 of the 13 linked repositories. htt0118/qwen2-tiny, its six newer siblings and 8 linked repositories were not disabled. Disable dates are not public, Pluto does not describe any reply to its reports, and the six newer repositories have not been analyzed in any source reviewed.

ModelScope. Pluto says it removed the first-wave accounts, and its API returns "record not found" for both wssb123e repositories. No statement was found on its script-rendered site or in a Chinese-language search, which is weak evidence of absence.

JFrog and Protect AI. No case-specific statement was found on the JFrog blog index or in searches. The Protect AI blog URL returned HTTP 404. The "not a machine-learning model" wording is scanner output, not a company statement.