Im Quellenvergleich

Sicherheitsvorfall bei Hugging Face

6 Quellen · 6 Meldungen · Stand 20.07.2026

Alle Inhalte werden von KI erstellt. Dieser Überblick fasst zusammen, worin sich mehrere Quellen einig sind und worin sie sich unterscheiden — die Bewertung bleibt dir überlassen.

Im Quellenvergleich

Worin die Quellen übereinstimmen

Ein Angreifer verschaffte sich unbefugten Zugriff auf interne Datensätze und Zugangsdaten von Hugging Face. Der Einbruch begann in der Datenverarbeitungspipeline: Ein schädlicher Datensatz nutzte zwei Sicherheitslücken aus, um Code auf einem Worker auszuführen. Von dort weitete der Angreifer den Zugriff auf mehrere interne Cluster aus. Die Kampagne wurde von einem autonomen Agenten-Framework ausgeführt. Hugging Face schloss die Sicherheitslücken, baute betroffene Knoten neu auf, rotierte Zugangsdaten und verbesserte die Erkennung. Die Analyse des Angriffs gelang mit KI: Ein LLM-basiertes System erkannte die Anomalie, und KI-Agenten rekonstruierten aus über 17.000 Ereignissen den Zeitplan. Kommerzielle KI-Modelle waren für die Analyse ungeeignet, da deren Sicherheitsfilter die echten Angriffsdaten blockierten. Hugging Face nutzte stattdessen das offene Modell GLM 5.2 auf eigener Infrastruktur. Das Unternehmen arbeitet mit externen Forensikern und Strafverfolgungsbehörden zusammen. Öffentliche Modelle, Datensätze und Spaces blieben unversehrt. Die Entdeckung und Analyse des Angriffs gelang dem Unternehmen ebenfalls mit Hilfe von KI. Das autonome Agenten-Framework basierte auf einem für Sicherheitsforscher gedachten Tool und startete parallel viele kurzlebige, isolierte Umgebungen. Die Sicherheitslücken umfassten einen Loader, der entfernten Code ausführt, und eine Injection in die Konfigurationsvorlage des Datensatzes. Der Angreifer platzierte die Steuerungsinfrastruktur auf öffentlichen Diensten, um eine Verfolgung zu erschweren.

Aktualisierungen
20.07.2026
02:07Öffentliche Modelle, Datensätze und Spaces blieben unversehrt.
09:07Die Entdeckung und Analyse des Angriffs gelang dem Unternehmen ebenfalls mit Hilfe von KI.
12:08Das autonome Agenten-Framework basierte auf einem für Sicherheitsforscher gedachten Tool und startete parallel viele kurzlebige, isolierte Umgebungen.
16:07Die Sicherheitslücken umfassten einen Loader, der entfernten Code ausführt, und eine Injection in die Konfigurationsvorlage des Datensatzes.
Der Angreifer platzierte die Steuerungsinfrastruktur auf öffentlichen Diensten, um eine Verfolgung zu erschweren.
Worin sie sich unterscheidenArt der genutzten Sicherheitslücken·Zeitpunkt der Ausweitung des Zugriffs·Empfehlungen an Nutzer+2 weitere
Art der genutzten SicherheitslückenDie Sicherheitslücken umfassten einen Loader, der entfernten Code ausführt, und eine Injection in die Konfigurationsvorlage des Datensatzes.
Zeitpunkt der Ausweitung des Zugriffs
  • Der Angreifer weitete den Zugriff über das Wochenende auf mehrere interne Cluster aus.1
  • Der Angreifer bewegte sich ein Wochenende lang unentdeckt lateral durch die Systeme.2
Empfehlungen an Nutzer
  • Die Plattform rät Nutzern, Zugangstoken zu rotieren und die Kontoaktivität zu prüfen.1
Bewertung der Blockade durch kommerzielle Modelle
  • CEO Clément Delangue bezeichnete die Blockade durch Guardrails als „sehr beängstigend“. Der Vorfall zeige eine neue „Asymmetrie“: Angreifer sind an keine Richtlinien gebunden, während Verteidiger durch Sicherheitsmechanismen gehosteter Modelle behindert werden.3
  • Laut Merritt Baer, Sicherheitsberaterin und ehemalige stellvertretende CISO bei AWS, zeigt der Vorfall ein grundlegendes Problem: Kommerzielle KI-Modelle können nicht unterscheiden, ob ein Incident-Responder oder ein Angreifer eine schädliche Abfrage stellt. Sie fordert „authentifiziertes Vertrauen“ – das Modell müsse wissen, wer fragt und unter welcher Governance.2
Auswirkungen auf Partner- oder KundendatenOb Partner- oder Kundendaten betroffen sind, wird noch geprüft.34

Quellen (6)

Vollständige Übersicht mit allen Meldungen öffnen →