Hugging Face as Malware CDN and Exfiltration Backend: The DPRK-Linked npm Campaign of May 2026

On May 22, 2026, OX Security disclosed a software supply-chain campaign that inverts the usual model-hub threat. In the more familiar cases, a malicious model is the lure and the victim is the person who downloads it. Here, the lure was a set of innocuous-looking npm logging packages, and Hugging Face was the infrastructure: a public model repository served the second-stage payload, and private Hugging Face datasets received the stolen data. The platform best known for distributing AI models was being used as a malware content-delivery network and a data-exfiltration backend at the same time.

The campaign began with a deceptively plain npm package, terminal-logger-utils, with three companion packages (pretty-logger-utils, ts-logger-pack, pinno-loggers) that imported and spread the behavior. The dropper profiled the victim machine and pulled a platform-specific second-stage binary from a Hugging Face repository. The implant then harvested developer secrets, Telegram data, SSH keys, cryptocurrency wallets, browser login databases, cloud configuration files, and environment variables, and uploaded the loot into attacker-controlled Hugging Face repositories. OX Security attributed the activity to a threat actor operating under the alias jpeek895, with associated accounts, and assessed it as North Korean (DPRK)-aligned.

The npm-worm mechanics are a separate lane; what matters from a model-hub security perspective is the abuse of Hugging Face itself. A model hub gives an attacker exactly the properties a malware operator wants: a high-reputation domain that developer machines and CI systems are already allowed to reach, large-file hosting that does not look out of place, and a data-upload API. This is the same blind spot that GitHub, Pastebin, and cloud storage providers spent years learning to police, now arriving at the AI model hub.

TL;DR

• On May 22, 2026, OX Security disclosed a DPRK-aligned npm campaign that abused Hugging Face as both a malware host and a data-exfiltration backend.
• Entry point: npm package terminal-logger-utils, with pretty-logger-utils, ts-logger-pack, and pinno-loggers importing and spreading the behavior.
• The dropper profiled the victim and fetched a platform-specific second-stage payload from an attacker-controlled Hugging Face repository (the same campaign cluster also used a repo identified in JFrog's related analysis, Lordplay/system-releases).
• Stolen data (Telegram data, SSH keys, crypto wallets, browser logins, cloud config, environment variables) was uploaded into private Hugging Face datasets under attacker accounts, so the C2 server never had to store loot directly.
• Attributed to the alias jpeek895 (with linked accounts pvnd3540749, yggedd817513, jpeek886); assessed as DPRK-aligned.
• The defensive lesson: model hubs are now in scope as malware infrastructure. Hugging Face traffic from developer endpoints and CI needs the same egress scrutiny you apply to GitHub raw content and cloud storage.

What happened

OX Security's report, shared with GBHackers and published May 22, 2026, describes a campaign that begins on npm and uses Hugging Face as its backend infrastructure.

The initial package, terminal-logger-utils, presented itself as a routine development logging utility. Three additional packages (pretty-logger-utils, ts-logger-pack, pinno-loggers) imported and propagated the malicious behavior, widening the blast radius to any developer who installed a package that depended on them. On install, the package acted as a dropper: it profiled the victim system and downloaded a platform-specific second-stage payload.

The second stage was hosted on Hugging Face. OX Security describes the payload as hosted on the platform and the stolen data as uploaded to attacker-controlled Hugging Face repositories. JFrog's analysis of the same campaign cluster identified the public repository Lordplay/system-releases serving four platform-specific binaries (Windows, macOS, Linux) that shared a single cross-platform JavaScript bundle, and detailed the exfiltration mechanism: when operators triggered an upload, the implant received a Hugging Face token, a username, a target path, and an upload ID, compressed the stolen data into a gzip archive, created or reused a private Hugging Face dataset under the attacker's account, and uploaded it there. JFrog identified a C2 server at 195.201.194.107, hosted at Hetzner.

The implant's targets were classic infostealer fare with a developer focus: Telegram session data, SSH keys, cryptocurrency wallets, browser login databases, cloud configuration files, and environment variables across multiple drives. OX Security attributed the activity to jpeek895, with associated accounts pvnd3540749, yggedd817513, and jpeek886, and assessed it as DPRK-aligned, consistent with the broader pattern of North Korean operators targeting software developers.

How the Hugging Face abuse worked

The clever part of this campaign is not the malware. It is the choice of infrastructure. Using Hugging Face for both delivery and exfiltration gives the operator several advantages, all of which are defensive blind spots.

Delivery from a trusted domain. Developer workstations and CI runners routinely pull from huggingface.co. It is on allowlists, its TLS certificates are valid, and large binary downloads are normal there because models are large. A second-stage binary fetched from a Hugging Face repo blends into expected traffic in a way that a download from a random VPS never would.

Cross-platform, one bundle. The four platform-specific binaries wrapped the same JavaScript bundle, so the operator maintained one payload and let a thin native wrapper handle each OS. The model hub happily hosts all of them as repository files.

Exfiltration without a noisy C2. This is the most notable design choice. Rather than POSTing stolen data to the C2 server, the implant uploaded it into a private Hugging Face dataset using a token supplied at runtime. The flow, per JFrog's analysis:

# Illustrative exfiltration flow. NOT functional code.
# The C2 hands the implant just enough to push loot into Hugging Face.

operator triggers upload
   -> implant receives: { hf_token, username, target_path, upload_id }
   -> implant gzips collected secrets into an archive
   -> implant creates or reuses a PRIVATE dataset under attacker account
   -> implant uploads the archive to that dataset
# Result: stolen data lives in Hugging Face, not on the C2.

Because the loot lands in a private dataset on Hugging Face rather than on the attacker's own server, the C2 never has to store stolen content. That lowers the operator's exposure, complicates takedown (the data is inside a major platform's storage), and makes the exfiltration traffic look like an ordinary authenticated upload to a service the machine is already allowed to use.

What detection looks like

The detection strategy is to stop treating huggingface.co as inherently benign egress and to instrument both the npm install path and the model-hub traffic.

npm / install-time signals:

• Presence of terminal-logger-utils, pretty-logger-utils, ts-logger-pack, or pinno-loggers in any lockfile or node_modules.
• A package install or postinstall step that fetches a binary from huggingface.co and executes it. Logging utilities have no reason to download platform-specific executables.
• Newly published, low-download logging/utility packages with names close to popular ones.

Hugging Face / egress signals:

• Outbound downloads of executable binaries (not weights, tokenizers, or configs) from Hugging Face repositories, especially from developer endpoints or CI runners.
• Authenticated Hugging Face dataset uploads originating from machines that have no business pushing datasets, particularly gzip archives to private datasets created moments earlier.
• Hugging Face API calls using a token that is not your organization's token.
• Connections to the C2 IP 195.201.194.107 (Hetzner) from the JFrog analysis.
• Repository references to Lordplay/system-releases or the attacker account aliases (jpeek895, pvnd3540749, yggedd817513, jpeek886).

The conceptual shift: egress monitoring policies that whitelist Hugging Face wholesale are now a liability. The platform is a legitimate destination for model pulls and an illegitimate one for executable delivery and data upload, and only behavioral context distinguishes them.

What to do Monday morning

1. Audit for the malicious packages. Search every lockfile and CI cache for terminal-logger-utils, pretty-logger-utils, ts-logger-pack, and pinno-loggers. Any hit is an incident: rotate SSH keys, npm and cloud tokens, and any secrets that lived in environment variables on the affected machine, and review Telegram sessions and wallets.
2. Tighten Hugging Face egress. Stop treating huggingface.co as fully trusted egress. Where feasible, restrict model pulls to a vetted internal mirror, and alert on direct binary downloads and on dataset uploads from endpoints and CI that should never push data.
3. Block executable fetches from model hubs in CI. CI runners pulling models need weights and configs, not platform-specific executables. Add a rule that flags or blocks binary downloads from model-hub domains during builds.
4. Inventory and monitor outbound Hugging Face tokens. Know which machines hold Hugging Face tokens and what scopes they have. An implant exfiltrating via dataset upload needs a token; constraining token scope and detecting unfamiliar tokens cuts the exfiltration path.
5. Add the IOCs to your hunt. C2 195.201.194.107; repository Lordplay/system-releases; account aliases jpeek895, pvnd3540749, yggedd817513, jpeek886. Hunt across DNS, proxy, and npm telemetry.
6. Treat developer endpoints as high-value targets. DPRK-aligned operators are specifically after developer secrets and source access. Prioritize EDR coverage, secret hygiene, and least-privilege tokens on engineering machines and build infrastructure.

Why this keeps happening

Every platform that combines a trusted domain, large-file hosting, and an upload API eventually gets used as malware infrastructure. GitHub, Pastebin, Discord CDN, and cloud object storage all walked this path; defenders adapted, allowlists got smarter, and abuse-detection teams matured. Hugging Face has the same properties and, until recently, far less of the abuse-detection muscle, which makes it an attractive frontier for operators who want to hide in trusted traffic.

The model-hub angle adds a second factor: the AI development workflow normalizes exactly the behaviors this campaign relies on. Pulling large binaries from Hugging Face is routine. Authenticating with a token to push and pull datasets is routine. CI runners reaching out to model hubs is routine. An attacker who works inside those routines generates very little anomalous signal. The defense gap is not a missing patch; it is that the entire ecosystem treats model-hub traffic as benign by default, and the egress controls have not caught up to the reality that model hubs are now general-purpose hosting.

The structural fix

The realistic goal is to shrink the window in which model-hub-borne malware operates undetected and to constrain what it can reach. Safeguard's SCA and the malicious-package feeds behind maintainer-takeover detection cover npm, so packages like terminal-logger-utils and their dependents surface as findings rather than installing quietly, and the AI-BOM extends that inventory to the model and dataset repositories your environment touches on Hugging Face. Policy enforcement can express rules such as "model-hub pulls may retrieve weights, tokenizers, and configs but not executables" and "dataset uploads from CI are denied," which directly cut the delivery and exfiltration paths this campaign used. None of that removes the attacker's account from Hugging Face, but it reduces dwell time and blast radius on your side, which is the part you control. For active incidents, the incident response workflow ties the IOC hunt to your inventory so you can answer "are we exposed" in minutes rather than days.

What we know we don't know

• Public reporting confirms Hugging Face was used for delivery and exfiltration, but the OX Security summary did not publish the specific repository identifiers and concrete IOCs; the repository (Lordplay/system-releases), the C2 IP, and the dataset-exfiltration mechanism come from JFrog's analysis of the related campaign cluster, and the precise degree of overlap between the two reports is not fully reconciled in public coverage.
• The total number of victims and the volume of exfiltrated data are not reported.
• The DPRK attribution is OX Security's assessment based on tradecraft and infrastructure overlap; it is an analytic judgment, not a confirmed government attribution.
• It is unclear how quickly Hugging Face removed the malicious repositories and datasets after disclosure, and whether the attacker accounts had other repositories still active.

References

• GBHackers: Hackers Abuse Hugging Face to Deliver npm Malware (OX Security report)
• OX Security: North Korean-Linked Threat Actor Targets Developers with New npm Infostealer RAT
• Cybersecurity News: Malicious npm Package Turns Hugging Face Into Malware CDN and Exfiltration Backend (JFrog analysis)
• DataBreaches.net: Hugging Face Hiding Second-Stage Malware for npm Supply Chain Attack
• Safeguard: SCA product
• Safeguard: Maintainer-takeover detection use case
• Safeguard: AI-BOM concept
• Safeguard: Policy enforcement concept
• Safeguard: Incident response use case