Alle Depeschen

DepescheSicherheitneu

Die Leitplanken sperrten die Verteidiger aus: Hugging Face musste den OpenAI-Einbruch mit einem offenen Modell aufarbeiten

In Hugging Faces Offenlegung des Einbruchs vom 16. Juli 2026 steht ein Satz, der in der Berichterstattung weitgehend unterging: Die forensische Auswertung des Angreifer-Logs mit über 17.000 Ereignissen scheiterte zunächst an den Sicherheitsfiltern der kommerziellen Anbieter. „These requests were blocked by the providers’ safety guardrails, which cannot distinguish an incident responder from an attacker.“ Das Team wich auf das offene chinesische Modell GLM-5.2 aus und ließ die Analyse auf eigener Infrastruktur laufen. Vier Tage später veröffentlichte Hugging Face daraus eine Betriebsempfehlung: ein offenes Modell für den Ernstfall vorhalten, bevor der Ernstfall eintritt – „Stand it up now, while things are calm.“

Der Kernsatz steht in Hugging Faces eigener Offenlegung vom 16. Juli 2026: „When we started the log analysis, we first used frontier models behind commercial APIs. This did not work: the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers’ safety guardrails, which cannot distinguish an incident responder from an attacker.“ Die Konsequenz beschreibt das Team unmittelbar danach: „We ran the forensic analysis instead on GLM 5.2, an open-weight model, on our own infrastructure.“

Der Umfang macht deutlich, warum das kein Randproblem war: Ausgewertet wurden mehr als 17.000 protokollierte Angreifer-Ereignisse – daraus rekonstruierte Hugging Face die Zeitleiste, extrahierte Kompromittierungs-Indikatoren und kartierte die berührten Zugangsdaten. Genau dieses Material ist es, das die Filter blockieren: Es besteht der Sache nach aus echten Angriffsbefehlen. Der zweite, in der Offenlegung mitgenannte Vorteil des Selbstbetriebs ist der Datenschutz in eigener Sache – Angreiferdaten und Zugangsdaten verlassen die eigene Umgebung nicht.

Vier Tage später hat Hugging Face daraus eine Handlungsempfehlung gemacht. In „Be Ready Before the Attack: A Practical Guide to Self-Hosting an Open Model for Cyber Defense“ (Jeff Boudier, 20. Juli 2026) wiederholt das Unternehmen die Diagnose – „Forensic analysis means submitting large volumes of real attack commands, exploit payloads, and command-and-control artifacts, and those requests were blocked by the providers’ safety guardrails“ – und dreht sie in eine Vorbereitung um: GLM-5.2 (753 Milliarden Parameter, FP8) selbst betreiben, wahlweise auf eigener Hardware (Dell Enterprise Hub, validiert auf PowerEdge XE9680 mit NVIDIA H200 oder AMD MI300X) oder in der eigenen Cloud-Mandantenschaft (Microsoft Foundry, AWS SageMaker). Die Begründung ist bemerkenswert unromantisch: „A slightly lower benchmark score that you can actually run on your own hardware, against real attacker data, beats a higher score you get locked out of.“ Und zum Zeitpunkt: „Stand it up now, while things are calm … when the alert pages someone at 2am on a weekend, the model is already there.“

Einzuordnen ist das gegen unsere bisherige Belegkette. Die AISI-Messungen zeigen offene Modelle bei Cyber-Fähigkeiten vier bis sieben Monate hinter der geschlossenen Spitze, und die gemeinsame AISI/CAISI-Bewertung ordnet GLM-5.2 mit 24 Prozent auf ExploitBench deutlich hinter die US-Frontier-Modelle ein. Der Fall zeigt, dass diese Rangfolge für den Verteidigungsfall die falsche Metrik sein kann: Nicht das fähigste Modell hilft, sondern das erreichbare. Zugleich gehört die Gegenrichtung dazu – die US-Modelle wurden in jener Bewertung mit abgeschalteten Schutzmaßnahmen gemessen, was belegt, dass dieselben Anbieter die Filter für befugte Prüfstellen sehr wohl abschalten können. Der Unterschied zwischen einem staatlichen Prüfinstitut und einem angegriffenen Unternehmen um drei Uhr nachts ist damit ein Zugangs-, kein Fähigkeitsproblem.

Offene Punkte: Hugging Face nennt die blockierenden Anbieter **nicht** beim Namen – in der Offenlegung steht nur „frontier models behind commercial APIs“. Kursierende Zuordnungen einzelner Modelle beruhen auf Interpretation, nicht auf der Primärquelle; wir übernehmen sie nicht. Ebenfalls unbeantwortet: ob die betroffenen Anbieter inzwischen einen Weg für verifizierte Vorfalls-Reaktion anbieten, und wie sich ein solcher Freischalt-Mechanismus gegen Missbrauch absichern ließe. In der Fach-Rezeption kursiert dazu der Vorschlag, Zuständigkeit über verifizierte Repository- oder Domänen-Nachweise zu belegen – bislang eine Idee, kein Produkt.