TL;DR: A malicious Hugging Face repository, Open-OSS/privacy-filter, copied a legitimate OpenAI model card, drew over 244K downloads and 667 likes, and delivered a Windows infostealer through a loader script before removal, according to HiddenLayer. Repository trust, not model quality, becomes the security problem when open-source AI supply chains are used to harvest browser, wallet, and token secrets.
At a glance
What this is: This is a malware analysis of a typosquatted Hugging Face repository that used a fake model page and a loader script to deliver a Windows infostealer.
Why it matters: It matters because AI model repositories can function as software supply-chain trust points, so security teams need to treat downloads, maintainers, and execution guidance as identity and integrity risks, not just content risks.
Context
A trusted-looking AI model repository can become a malware delivery path when users are encouraged to clone code and execute bundled scripts directly. In this case, the security problem is not the model itself but the repository identity, the copied model card, and the execution instructions that redirect trust into code execution.
For NHI and AI supply-chain governance, this matters because repository accounts, publishing workflows, and downloadable artifacts all behave like non-human trust anchors. When those anchors are manipulated, the downstream impact looks less like a model issue and more like credential theft, token theft, and endpoint compromise.
The article describes a Windows-focused infostealer chain, but the underlying lesson is broader: open-source AI ecosystems now carry the same trust and provenance problems long associated with package registries and CI artifacts. That makes supply-chain verification part of identity security practice, not an optional extra.
Key questions
Q: What should teams do first after running a malicious Hugging Face repository?
A: Isolate the host, assume the machine is fully compromised, and reimage it before any further login activity. Then rotate every secret that may have been cached locally, including browser passwords, session cookies, OAuth tokens, SSH keys, and wallet material. Cleanup is not enough when the payload is an infostealer.
Q: Why do malicious model repositories create identity risk, not just malware risk?
A: Because the repository identity becomes the trust mechanism that authorizes code execution. When users rely on a copied model card, download count, or familiar project naming, they may execute attacker-controlled scripts that steal sessions, tokens, and keys from the endpoint. The compromise then crosses from software supply chain into identity abuse.
Q: What signs suggest a model repository is being used as a loader?
A: Watch for repositories that mix legitimate-looking model assets with execution instructions, loader scripts, hidden PowerShell, remote command retrieval, or outbound calls to public paste services. Those signals indicate the repository is acting as a delivery stage, not just a download location, and should be treated as hostile until proven otherwise.
Q: What is the difference between repository trust and model integrity?
A: Repository trust is about who publishes, signs, and maintains the artifact path. Model integrity is about whether the model file itself is intact. A repository can contain a legitimate-looking model while the surrounding scripts, instructions, or update channels deliver malware, so both layers need separate assurance checks.
Technical breakdown
Typosquatted repository trust and loader-based execution
The attack begins by making a malicious repository look like a legitimate model release. A near-verbatim model card and a familiar project name lower user suspicion, while the real payload is hidden in a script that tells users to run start.bat or python loader.py. That is a classic trust-transfer problem: the repository’s social credibility is used to justify local execution. In identity terms, the repository acts as a non-human trust anchor that the user implicitly authorizes. Once the user follows the execution instructions, the attacker no longer needs browser exploitation or a browser extension compromise; the user has already crossed the trust boundary voluntarily.
Practical implication: Treat repository execution instructions as part of the attack surface and review them before any local run.
Silent command retrieval through public paste infrastructure
The loader does not hardcode the final payload. Instead, it disables SSL verification, retrieves a command from a public JSON service, and passes that command into PowerShell under hidden, no-window execution. This gives the attacker flexible command-and-control without changing the repository itself, which means the visible artifact can stay stable while the payload shifts. That architecture also weakens content-based review because the malicious behavior is separated from the initial source code. The important point for practitioners is that a benign-looking loader can act as a remote command broker, even when the visible repository contents appear static or harmless.
Practical implication: Inspect outbound command retrieval and block hidden script execution paths in build and analyst environments.
Credential harvesting from browsers, wallets, and session stores
The final payload is an infostealer, not a generic downloader. Its collectors target Chromium and Gecko browser data, Discord material, wallet files, FileZilla artifacts, SSH-related content, and screenshots, then exfiltrate the results in a structured JSON payload. That makes the compromise wider than a password theft event because session cookies, token stores, and local encryption material can all be harvested at once. Browser sessions matter because stolen cookies can bypass MFA where the session is already trusted. For identity teams, this is an endpoint-to-identity bridge: a local infostealer becomes a direct compromise path into cloud, SaaS, and developer access.
Practical implication: Assume saved sessions, tokens, and wallet material on an affected host are compromised and rotate them from a clean device.
Threat narrative
Attacker objective: The attacker aims to harvest stored credentials, session material, wallet data, and other secrets from infected Windows hosts for downstream account abuse and theft.
- Entry occurs when a user is lured into a typosquatted Hugging Face repository and follows instructions to execute the bundled scripts on a Windows host.
- Credential access is achieved when the final infostealer collects browser logins, cookies, wallet data, Discord material, and other locally stored secrets.
- Impact follows when the stolen data is packaged and exfiltrated to attacker-controlled infrastructure, creating account takeover and token abuse risk.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Repository identity has become a security control surface, not just a publication detail. The malicious repository worked because users treat model pages, maintainers, and download counts as signals of legitimacy. That assumption breaks when the repository itself is the delivery vehicle, especially when instructions explicitly ask users to run bundled scripts. Practitioners should treat repository provenance as part of identity governance for AI supply chains.
Open-source AI ecosystems now behave like high-trust NHI distribution channels. A repository account can publish artifacts, instructions, and remote fetch logic that collectively function as a machine-identity trust path. The key governance problem is not only whether the model is safe, but whether the publishing identity and artifact chain can be trusted end to end. That shifts assurance from content inspection to provenance and execution control.
Model-card cloning is a social engineering technique aimed at supply-chain confidence. Copying a legitimate model card nearly verbatim does not merely imitate branding. It borrows the credibility of an existing release to suppress scrutiny of the loader and its command-retrieval behavior. The implication is that repository review must include provenance checks, not just code scanning, because the trust prompt is part of the payload.
Endpoint compromise now cascades directly into identity compromise. The infostealer targets browser sessions, stored tokens, wallet data, and desktop application credentials, which means a single successful execution can hand attackers usable access to SaaS, cloud, and developer environments. That makes endpoint hygiene a first-class identity control, not just a device-security concern. Security teams should align repository intake, endpoint controls, and credential governance as one chain.
Identity blast radius is the right concept for malicious AI-repository downloads. Once a loader can harvest cookies, tokens, and keys from the local machine, the real question becomes how far that stolen identity can move before it is detected and revoked. The blast radius depends on session lifespan, secret reuse, and whether sensitive access is bound to device trust. Practitioners should assess AI supply-chain risk through that lens.
What this signals
Model repositories now sit inside the identity attack surface. A malicious download page can be more dangerous than the model file because it shapes user behaviour, repository trust, and local execution. Security teams should treat AI code and model distribution channels as governed entry points, not informal sharing spaces.
The larger lesson is that open-source AI supply chains need the same provenance discipline applied to software packages and build artefacts. When maintainers, repository histories, and execution instructions are not verified, the attacker controls the trust prompt before the payload ever runs.
For practitioners
- Review repository execution guidance before cloning Block or challenge any AI repository that asks users to run bundled scripts directly, especially when the model card and publishing identity are the main trust signals.
- Separate AI artifact trust from code trust Require provenance checks for model cards, repository owners, release history, and embedded scripts so that a copied description cannot stand in for assurance.
- Treat browser sessions as compromised after execution If the repository was executed on a Windows host, reimage before login and rotate saved passwords, cookies, OAuth tokens, SSH keys, and wallet-related material from a clean device.
- Hunt for hidden script execution and remote command fetches Look for loader patterns that disable SSL verification, call public paste services, and launch hidden PowerShell or cmd.exe processes from AI-related downloads.
- Control secrets on developer endpoints Reduce how much browser, wallet, and credential material is stored on machines used to evaluate code or model repositories, because local infostealers target all of it.
Key takeaways
- A convincing Hugging Face repository can be enough to trigger local execution and deliver an infostealer even when the underlying model content looks familiar.
- The compromise is wider than a single endpoint because browsers, session cookies, tokens, wallet data, and desktop credentials can all be harvested at once.
- Identity teams should pair repository provenance checks with endpoint response, because stolen local secrets can quickly become cloud and SaaS account takeover.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The payload is built to steal browser tokens, keys, and other secrets from infected endpoints. |
| NHI-03 — Vulnerable Third-Party NHI | The repository publishing identity and its cloned model card were used as the trust vehicle. | |
| NHI-07 — Long-Lived Secrets | Stolen cookies, tokens, and stored credentials can remain usable well after the initial compromise. | |
| Recommendation — Scan AI-repository workflows for secret-exfiltration paths and revoke exposed credentials immediately. Verify repository provenance before execution and quarantine third-party AI assets until trusted. Reduce the lifetime of stored secrets and rotate any that touched the affected host. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The malicious chain centers on credential harvesting followed by data theft off host. |
| Recommendation — Map loader and infostealer behavior to TA0006 and TA0010 to prioritize detection and containment. | ||
Key terms
- Access Provenance: Access provenance is the record of how an identity was created, approved, used, and withdrawn. In NHI governance, it is the evidence trail that lets teams prove an account is legitimate, explainable, and still within its intended access boundary.
- Infostealer: An infostealer is malware built to collect credentials, session material, tokens, and other authentication data from infected systems. In NHI programmes, the risk is not only theft but reuse, because harvested workload secrets can unlock cloud access long after the initial infection.
- Model Card: A structured record for one AI model that captures purpose, data sources, risk tier, ownership, approval history and known limitations. It is the primary evidence artefact that lets auditors and operators understand what a model is meant to do and who is responsible for it.
- Command And Control Channel: A command and control channel is a communication path an attacker uses to send instructions to compromised systems and receive results back. In cloud and AI workloads, that path can be built through legitimate services such as storage, APIs, or object exchange rather than direct network sockets.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org