Der KI-Agenten-Angriff auf Hugging Face: Über 17.000 Angriffe, eigene KI fiel aus

Wichtig: Es gab keine Anzeichen für Manipulationen an öffentlichen, nutzerseitigen Modellen, Datensätzen oder Spaces; auch die Software-Lieferkette (Container-Images und veröffentlichte Pakete) blieb intakt . Der Zugriff beschränkte sich auf eine begrenzte Anzahl interner Datensätze und Dienstzugangsdaten .

Wie der Angreifer vorging: Ausnutzung von Daten-Pipelines

Der Einbruch begann in der Datenverarbeitungspipeline von Hugging Face . Der Angreifer nutzte einen bösartigen Datensatz, der zwei Wege zur Code-Ausführung enthielt:

• Einen „Remote-Code Dataset Loader“, der die Ausführung beliebigen Codes erlaubte.
• Eine Template-Injection-Schwachstelle in der Konfiguration des Datensatzes .

Nachdem der Angreifer Code auf einem Verarbeitungs-Worker ausführen konnte, weitete er seine Rechte auf Knotenebene aus, sammelte Cloud- und Cluster-Zugangsdaten und bewegte sich lateral in mehrere interne Cluster .

Der gesamte Angriff wurde von einem autonomen Agenten-Framework orchestriert. Welches zugrundeliegende KI-Modell dabei verwendet wurde, ist nicht bekannt. Die Agenten operierten über einen Schwarm ephemerer Sandboxen mit einer sich selbst migrierenden Kommando- und Kontrollstruktur, die über öffentliche Dienste gesteuert wurde .

Das ungewöhnliche Problem: Kommerzielle KI-Sperren blockierten die Verteidiger

Als das Sicherheitsteam von Hugging Face mit der Analyse des Ereignisprotokolls (17.000+ Einträge) begann, griff es zunächst auf führende kommerzielle Modelle hinter APIs zurück. Diese Versuche scheiterten, weil die Sicherheitsmechanismen der Anbieter die Analyse blockierten . Die Schutzfilter konnten nicht zwischen einem legitimen Vorfall-Untersucher, der Exploit-Payloads und C2-Artefakte einreicht, und einem tatsächlichen Angreifer unterscheiden .

Hugging Face war gezwungen, die gesamte forensische Analyse auf GLM 5.2, ein Open-Weight-Modell auf eigener Infrastruktur, zu verlagern . Dies hatte den zusätzlichen Vorteil, dass keine Angreiferdaten oder referenzierten Zugangsdaten die Umgebung des Unternehmens verließen .

„Die praktische Lektion für Verteidiger: Haltet ein leistungsfähiges Modell bereit, das auf eigener Infrastruktur läuft, und zwar vor einem Vorfall – sowohl um die Blockade durch Schutzmechanismen zu vermeiden als auch um Angreiferdaten und Zugangsdaten in der eigenen Umgebung zu behalten.“

Das Unternehmen wies auf die kritische Schieflage hin: Man wisse nicht, welches Modell die Angreifer-Agenten angetrieben habe, aber ob es sich um ein manipuliertes kommerzielles Modell oder ein uneingeschränktes Open-Weight-Modell gehandelt habe – „der Angreifer war an keine Nutzungsrichtlinie gebunden, während unsere eigene forensische Arbeit durch die Sicherheitsvorkehrungen der von uns zuerst genutzten kommerziellen Modelle blockiert wurde“ .

Reaktionsmaßnahmen

Hugging Face ergriff die folgenden Maßnahmen, die im Sicherheitsbericht aufgeführt sind :

• Behebung der zugrundeliegenden Schwachstellen: Die beiden Wege zur Code-Ausführung wurden geschlossen.
• Beseitigung der Angreifer-Präsenz in den betroffenen Clustern und Neuaufbau kompromittierter Knoten.
• Widerruf und Rotation der betroffenen Zugangsdaten und Token; Beginn einer vorsorglichen Rotation weiterer Geheimnisse.
• Installation zusätzlicher Sicherheitsvorkehrungen und strengerer Zugangskontrollen für die Cluster.
• Verbesserte Erkennung und Alarmierung, sodass ein Signal mit hohem Schweregrad innerhalb von Minuten an eine verantwortliche Person weitergeleitet wird, unabhängig vom Wochentag.
• Einschaltung externer Cybersicherheits-Forensik-Spezialisten zur Untersuchung und Überprüfung der Sicherheitsrichtlinien.
• Meldung des Vorfalls an Strafverfolgungsbehörden.

Das Unternehmen empfahl der Community außerdem vorsorglich, Zugriffstoken zu rotieren und die jüngste Kontoaktivität zu überprüfen .