Fake-OpenAI-Repo verteilt Malware

Ein gefälschtes Repository auf Hugging Face hat OpenAIs legitimes Privacy-Filter-Projekt imitiert und darüber Infostealer-Malware verbreitet. Der Fall zeigt, wie schnell sich Vertrauen in bekannte KI-Marken und Plattformsignale wie Trending-Listen, Likes oder Downloadzahlen für Supply-Chain-Angriffe missbrauchen lässt.

OpenAI-Tool als Köder

OpenAI hatte den offiziellen Privacy Filter am 22. April 2026 veröffentlicht. Das Open-Weight-Modell soll personenbezogene Informationen in unstrukturiertem Text erkennen und schwärzen. Damit ist es vor allem für Unternehmen relevant, die sensible Daten in KI-, Logging-, Support- oder Analyseprozessen besser schützen wollen.

Genau diese Relevanz nutzten Angreifer offenbar aus. Laut HiddenLayer imitierte das schädliche Hugging-Face-Repository Open-OSS/privacy-filter das legitime OpenAI-Projekt, kopierte die Model Card nahezu vollständig und ergänzte schädliche Dateien wie loader.py und start.bat.

Platz 1 auf Hugging Face

Vor der Entfernung erreichte das Repository laut HiddenLayer zeitweise Platz 1 der Trending-Liste auf Hugging Face. The Hacker News berichtet von rund 244.000 Downloads und 667 Likes innerhalb von weniger als 18 Stunden. HiddenLayer und BleepingComputer weisen jedoch darauf hin, dass diese Zahlen wahrscheinlich künstlich aufgebläht wurden, um dem Repository mehr Glaubwürdigkeit zu verleihen.

Die tatsächliche Zahl kompromittierter Systeme ist derzeit nicht bekannt. BleepingComputer betont ausdrücklich, dass aus den Downloadzahlen nicht direkt auf Opferzahlen geschlossen werden kann.

Infostealer für Windows-Systeme

Die Angriffskette zielte nach aktuellem Kenntnisstand vor allem auf Windows-Nutzer. HiddenLayer beschreibt, dass die Datei loader.py beim Ausführen eine Base64-codierte URL dekodierte, eine PowerShell-Anweisung abrief und anschließend weitere Dateien von einer externen Infrastruktur nachlud. Die Ausführung erfolgte verdeckt über PowerShell.

Die finale Schadsoftware war laut The Hacker News und BleepingComputer ein Rust-basierter Infostealer. Er sollte unter anderem Browserdaten, gespeicherte Passwörter, Session-Cookies, Discord-Tokens, Krypto-Wallets, SSH-, FTP- und VPN-Zugangsdaten, FileZilla-Konfigurationen, Systeminformationen und Screenshots abgreifen. Die Daten wurden laut Analyse an eine Command-and-Control-Infrastruktur übertragen.

Warum das für IT-Entscheider relevant ist

Der Vorfall ist kein klassischer Malware-Fund am Rand des Internets, sondern ein Beispiel für ein wachsendes Risiko in KI- und Open-Source-Lieferketten. Unternehmen laden heute nicht mehr nur Softwarepakete herunter, sondern auch Modelle, Model Cards, Skripte, Datasets und Beispielcode. Genau diese Bestandteile müssen in Sicherheitsprozesse einbezogen werden.

Besonders kritisch ist der Vertrauenseffekt: Ein bekannter Markenname, ein professionell wirkendes Repository, hohe Downloadzahlen und ein Platz in der Trending-Liste können schnell den Eindruck legitimer Software erwecken. Der aktuelle Fall zeigt jedoch, dass solche Signale allein keine belastbare Sicherheitsprüfung ersetzen.

Was Unternehmen jetzt prüfen sollten

Unternehmen, die das Repository Open-OSS/privacy-filter oder eines der von HiddenLayer genannten verwandten Repositories heruntergeladen und Dateien daraus ausgeführt haben, sollten betroffene Windows-Systeme als kompromittiert behandeln. HiddenLayer empfiehlt in diesem Fall, Systeme zu isolieren und bevorzugt neu aufzusetzen, statt nur eine Bereinigung zu versuchen.

Zusätzlich sollten gespeicherte Zugangsdaten, Browser-Sessions, OAuth-Tokens, SSH-Keys, FTP- und VPN-Zugänge sowie Cloud-Zugangsdaten rotiert werden. Auch Krypto-Wallets und Seed-Phrases sollten als potenziell kompromittiert gelten, wenn sie auf einem betroffenen System gespeichert waren.

Fazit

Der Fall rund um das gefälschte OpenAI-Repository macht deutlich: KI-Sicherheit beginnt nicht erst beim Modellbetrieb. Sie beginnt bereits bei der Herkunft von Code, Modellen und Installationsanweisungen.

Für IT-Entscheider bedeutet das: Open-Source-KI-Komponenten sollten denselben Prüfprozessen unterliegen wie klassische Softwareabhängigkeiten. Dazu gehören verifizierte Quellen, Code-Reviews vor der Ausführung, Sandbox-Tests, Monitoring von Netzwerkverbindungen und klare Freigabeprozesse für neue KI-Tools. Gerade bei populären Projekten gilt: Bekanntheit ersetzt keine Supply-Chain-Security.