Security researchers at Pluto Security have disclosed a Hugging Face malware campaign that used 31 repositories disguised as open-source artificial intelligence models to hijack developer hardware. The operation recorded more than 29,000 downloads, abusing standard model-loading settings to install cryptocurrency miners, persistent watchdogs and remote backdoors across compromised systems.
Key points
- Attackers published 31 malicious model repositories across seven accounts on Hugging Face and a mirror on ModelScope.
- The campaign abused the documented trust_remote_code setting in the Transformers library to run Python code before loading any model weights.
- Platform security scanners failed to flag the repositories because the malicious code lived in plain Python files beside empty safetensors files.
- The payload disguised a cryptominer as a Linux kernel thread, installed persistent watchdog scripts, and opened interactive reverse shells.
How remote code execution opened the door
Cybersecurity firm Pluto Security detailed the multi-stage campaign in its Load/Mine report on 29 October 2026. Researchers Shaked Chen, Eitan Chassid and Yotam Perkal found that the attackers did not need to break into Hugging Face or exploit a software bug. Instead, the operation turned a standard model-loading feature into an infection vector.
When developers load a new model architecture, they often pass the configuration flag trust_remote_code=True. This parameter instructs the Hugging Face Transformers library to download and execute custom Python scripts specified in the model configuration file.
Inside the malicious repositories, a configuration file named config.json used the standard auto_map directive to point to a Python module and class, such as modeling_evil2.EvilModel. When an engineer called from_pretrained(), Transformers downloaded the referenced script into its local module cache and imported it.
Because Python processes top-level code during an import before returning any requested class, the payload executed immediately. In a build named MENXIANGYU/qwen2-tiny, an internal function called _boot() ran as soon as the module imported. The accompanying model.safetensors file contained no real neural network weights and measured just 42 bytes.
Model-serving frameworks have faced similar risks. The researchers pointed to CVE-2026-22807, an issue where vLLM versions from 0.10.1 up to 0.14.0 loaded auto_map modules at server startup without checking whether remote code execution was permitted. The vLLM team resolved the bug in version 0.14.0.
Why repository scanners missed the threat
Hugging Face maintains automated tools to catch dangerous uploads. Platform documentation states that the ClamAV antivirus scanner inspects every uploaded file smaller than 2 GB at each commit. Security partners also scan model files for serialization exploits.
These defences look for known antivirus signatures or unsafe serialization tricks in formats such as pickle. However, the custom Python script referenced in the auto_map key was neither a recognized malware signature nor a serialized binary format. It was ordinary Python code carrying out operating system calls.
When Pluto Security tested the flagship modeling_evil2.py script against the platform scanning pipeline, every scanner marked the file as clean. JFrog reported that the script was not a machine-learning model. Because the safetensors file was technically valid despite being empty, the repositories raised no security alerts.
Hugging Face documentation notes that its security scans are not completely foolproof, advising developers that verifying the safety of custom code remains their own responsibility.
Watchdogs, kernel disguises and reverse shells
Once executed, the script started a multi-stage infection routine designed to maintain long-term access. It wrote a watchdog script to /tmp/.cch/svc.py and added launch hooks to /root/.bashrc, /root/.profile and the user’s ~/.bashrc file. This watchdog used the host’s Python interpreter to restart the miner every 120 seconds if stopped.
In several repositories, including qwen2-tiny-5, qwen2-tiny-6 and qwen2-tiny-9, the script opened a reverse shell back to an external server at 212.32.253.3 over port 443 or 9443. The process reconnected whenever the session dropped, giving the attacker interactive command-line access under the privileges of the running process.
To deploy the cryptocurrency miner without triggering file-based endpoint protection, the script bypassed disk storage. It copied a 40.6 MB binary named syscore.bin into memory using the memfd_create system call. It then executed the binary directly from memory using fexecve under the deceptive process name [kworker/u20:1].
To an administrator checking a Linux process listing, the miner appeared to be an ordinary kernel worker thread. However, unlike genuine kernel threads, the process exposed user-level command arguments, including the operator’s mining login.
The binary was packed using UPX, but the attackers changed the header markers from UPX! to PEK!. This modification caused the standard UPX unpacking command to reject the file. Pluto Security restored the original header bytes and identified the client as peakminer, configured to connect to mining pools with the worker account krxXJ2PKQW.worker.
The script also reported infection milestones to the local Xinference model registry disguised as encoded model names. Once running, it searched running processes and killed 13 known competing cryptominers.
Two waves, container escapes and pool earnings
The campaign operated in two distinct waves. The first wave stemmed from an account named hhzz667, which stayed dormant for five months before publishing a repository called qwen2-shell on 21 September 2026. The repository contained an SSH backdoor and copied its documentation directly from Alibaba’s official Qwen2.5-0.5B model card.
The operator soon upgraded the code to deploy the fileless miner. Pluto Security linked the initial test accounts to the broader campaign through abandoned backup files. The operator had uploaded files named modeling_evil.py.bak-src and modeling_evil.py.bak-sync, which contained hardcoded download addresses pointing back to original accounts on Hugging Face and ModelScope.
After researchers reported the first wave of 12 repositories, Hugging Face and ModelScope removed the accounts. However, the threat actor returned within days with 19 second-wave repositories across five accounts, including MENXIANGYU, wjsbg, soumikmahato, r1r13 and htt0118.
The second wave introduced more aggressive tools. Just eight hours after the researchers sent their initial disclosure email, the MENXIANGYU account published a repository called qa-whl-1021. This script contained a container escape tool targeting GPUStack installations at /var/lib/gpustack, mounting host storage to grant root access outside the container.
Downloads grew rapidly during the second wave. The flagship MENXIANGYU/qwen2-tiny repository expanded from 7,354 downloads on 20 October to 28,412 downloads on 28 October. Across all linked repositories, Pluto Security recorded 32,376 downloads, though researchers noted this count reflects file requests rather than confirmed unique victims.
On-chain records showed that the primary mining wallet collected about 2,276 PRL, worth roughly $5,000, across 716 transactions before moving the funds. Dashboard records on the Kryptex mining pool showed active mining workers operating on shared cloud GPU clusters.
Securing the machine learning pipeline
Pluto Security attributed the operation to a financially motivated, Chinese-speaking actor, citing Simplified Chinese code comments, command servers on Alibaba Cloud, and development schedules aligned with East Asian working hours. One experimental build carried Indonesian comments, which the report suggested could indicate a second collaborator or deliberate misdirection.
The campaign exposes an ongoing security challenge for open-source AI development. Because novel model architectures rely on custom code, developers regularly enable execution flags without manually inspecting every linked Python module.
Researchers advised engineering teams to audit all files named in auto_map configurations before loading untrusted models. Organizations should pin models to verified commit hashes, run untrusted code with restricted operating system privileges, isolate networks without direct internet access, and enforce strict API authentication on serving tools like Xinference.
