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.
NHIMG editorial — based on content published by HiddenLayer covering the malicious Hugging Face repository Open-OSS/privacy-filter and its infostealer payload
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
HiddenLayer's full research covers the operational detail this post intentionally leaves for the source:
- The exact repository indicators of compromise, including domains, hashes, and host artefacts tied to the loader and infostealer chain.
- The full six-stage attack progression from lure to payload delivery, including the Windows-only execution path and the silent failure handling.
- The malware’s collector coverage across browsers, Discord, wallets, FileZilla, SSH, VPN, and screenshot capture.
- The telemetry details behind the repository’s artificial engagement pattern and related account activity across other Hugging Face uploads.
👉 Read HiddenLayer’s analysis of the malicious Hugging Face privacy-filter repository →
Trending Hugging Face repos and infostealer loaders: what changed?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Malicious Hugging Face repositories turn AI model downloads into infostealer risk
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Malicious Hugging Face repositories turn AI model downloads into infostealer risk