Ich habe Backdoors in KI-Modellen auf Hugging Face gefunden — und alle anderen, die sich die Mühe gemacht haben, hinzusehen, ebenfalls

Es war ein Dienstagabend, und ich sah einem meiner Ingenieure dabei zu, wie er etwas tat, das eigentlich Routine sein sollte: ein vortrainiertes Modell von Hugging Face in eine Testumgebung laden. Standardsache. Wir hatten das Hunderte Male getan. Aber dieses Mal hatte ich gerade JFrogs Offenlegung vom Februar 2024 zu Ende gelesen — die, in der ihre Sicherheitsforscher über 100 bösartige Modelle auf Hugging Face fanden, einige mit Backdoors, die Angreifern in dem Moment Fernzugriff gaben, in dem man sie lud — und ich konnte den Blick nicht vom Terminal lösen.

„Moment mal“, sagte ich. „In welchem Format liegt dieses Modell vor?“

Pickle.

Mir sackte der Magen weg.

Das war der Moment, in dem mir klar wurde, dass wir KI-Modelle so behandelt hatten, wie die Branche 2014 mit Open-Source-Bibliotheken umging — als grundsätzlich vertrauenswürdige Artefakte, die man einfach aus dem Internet zieht und ausführt. Und ich wusste, mit jener Art von Gewissheit, die nur entsteht, wenn man in Echtzeit zusieht, wie die eigenen Annahmen zusammenbrechen, dass dies eine der prägenden Sicherheitskrisen des kommenden Jahrzehnts werden würde.

Das Modell, das nach Hause telefoniert

Folgendes ist auf Hugging Face tatsächlich passiert. Ein Nutzer namens „baller423“ lud ein PyTorch-Modell hoch, das vollkommen normal aussah. Es hatte einen plausiblen Namen, eine glaubwürdige Beschreibung, anständig aussehende Metriken. Aber tief in seinen Pickle-serialisierten Gewichten steckte eine Payload, die in dem Moment, in dem jemand torch.load() ausführte, eine Reverse Shell zu einer IP-Adresse öffnete, die dem Korea Research Environment Open Network gehörte.

Kein theoretischer Angriff. Kein Proof of Concept. Ein aktives, als Waffe präpariertes Modell auf dem populärsten KI-Modell-Hub der Welt, das nur darauf wartete, dass jemand es herunterlädt.

Und „baller423“ war kein Einzelfall. JFrog fand rund 100 Modelle dieser Art — jedes davon ein trojanisches Pferd, verkleidet als hilfreiches vortrainiertes Artefakt.

Wenn Sie torch.load() auf eine Pickle-Datei ausführen, laden Sie keine Daten. Sie führen Code aus. Und Sie haben keine Ahnung, was dieser Code tut, bis es zu spät ist.

Ich muss erklären, warum das so gefährlich ist, denn die meisten Menschen — selbst die meisten Ingenieure — verstehen nicht, was Pickle eigentlich ist. Das Python-Pickle-Format ist nicht bloß eine Methode zur Datenserialisierung. Es ist eine stackbasierte virtuelle Maschine. Es kann während der Deserialisierung beliebige Python-Funktionen ausführen. Wenn Ihr Data Scientist ein Modell lädt, kann Pickle unbemerkt os.system() oder subprocess.run() im Hintergrund aufrufen. Das Modell tut, was es soll. Die Vorhersagen sehen normal aus. Und währenddessen hat jemand auf der anderen Seite der Welt eine Shell auf Ihrem Server.

Das ist kein Bug. So wurde Pickle konzipiert. Wir haben nur nie damit gerechnet, was das bedeutet, wenn die Dateien von Fremden aus dem Internet stammen.

Warum haben die Scanner es nicht erkannt?

Das ist der Teil, der mich in jener Nacht wachhielt. Wir hatten Sicherheitswerkzeuge. Die Branche hatte PickleScan, das Standardtool zur Prüfung von Modelldateien. Hugging Face selbst setzt es ein. Sicherlich würden die Scanner etwas derart Offensichtliches erkennen?

Haben sie nicht. Und es kommt noch schlimmer.

JFrog entdeckte später drei Zero-Day-Schwachstellen in PickleScan selbst — darunter eine, die als CVE-2025-10155 registriert ist —, die es Angreifern erlaubten, die Erkennung vollständig zu umgehen, indem sie Dateiendungen manipulierten oder Unstimmigkeiten in ZIP-Archiven ausnutzten. Ein bösartiges Modell konnte ausgerechnet von dem Tool als „sicher“ eingestuft werden, das Sie eigentlich schützen sollte.

Das statistische Bild ist trostlos: Bis zu 96 % der aktuellen Scanner-Warnungen sind False Positives. Überlegen Sie, was das mit einem Sicherheitsteam macht. Nach dem hundertsten Fehlalarm schaut man nicht mehr hin. Man klickt reflexartig auf „Genehmigen“. Und genau dann kommt die echte Bedrohung zur Tür herein.

Ich hatte darüber eine hitzige Auseinandersetzung mit einem meiner Teamleiter. Er fand, wir überreagierten. „Wir ziehen Modelle nur von verifizierten Organisationen“, sagte er. Ich zeigte ihm die JFrog-Daten. Ich zeigte ihm, dass selbst neuere „sichere“ Formate wie GGUF — eigens entwickelt, um Pickles Probleme zu vermeiden — nachweislich bösartige Jinja-Templates in ihren Metadaten enthielten, die während der Inferenz ausgeführt werden, nicht beim Laden. Der Scanner sieht es nie, weil der Angriff erst später stattfindet, wenn das Modell bereits läuft.

Er schwieg lange. Dann sagte er: „Was können wir dann überhaupt noch als vertrauenswürdig ansehen?“

Das ist die richtige Frage.

Was passiert, wenn in Ihrer KI ein Schläfer steckt?

Beim Hugging-Face-Vorfall ging es um plumpe, erkennbare Payloads — Reverse Shells, offensichtliche Codeausführung. Aber die tiefere Bedrohung, die mir wirklich Angst macht, ist Data Poisoning. Und die Forschung dazu ist erschreckend.

NVIDIAs AI Red Team hat zusammen mit Erkenntnissen von Anthropic gezeigt, dass man in einem Modell mit 13 Milliarden Parametern ein verstecktes Verhalten dauerhaft einpflanzen kann, indem man lediglich 0,00016 % der Trainingsdaten vergiftet — rund 250 Dokumente aus Millionen.

Lassen Sie diese Zahl wirken. Zweihundertfünfzig Dokumente.

Das vergiftete Modell besteht jeden Benchmark. Es verhält sich in Standardtests identisch zu einem sauberen Modell. Aber sobald es auf einen bestimmten Trigger trifft — eine bestimmte Zeichenfolge, ein Bildmuster, sogar eine Manipulation der Eingabedaten auf Bit-Ebene —, wechselt es sein Verhalten. Es könnte die Authentifizierung umgehen. Es könnte Daten exfiltrieren. Es könnte bösartigen Code erzeugen, der in ein nachgelagertes System eingespeist wird.

Ein vergiftetes KI-Modell ist der perfekte Schläfer: Es besteht jeden Test, glänzt in jedem Benchmark und wartet geduldig auf einen Trigger, den nur der Angreifer kennt.

Und hier kommt der mathematische Tiefschlag: Mehr saubere Daten hinzuzufügen behebt es nicht. Sobald die Backdoor einen Schwellenwert erreicht — typischerweise 50 bis 100 Vorkommen des Triggers während des Trainings —, ist sie dauerhaft in die Gewichte eingebrannt. Man kann sie nicht wegtrainieren. Man kann sie nicht verdünnen.

NVIDIA hat das zu dem formalisiert, was sie die AI Kill Chain nennen: fünf Phasen — Recon, Poison, Hijack, Persist, Impact —, die abbilden, wie Angreifer Machine-Learning-Systeme systematisch kompromittieren. Ich habe über dieses Framework und das gesamte Spektrum der Angriffsvektoren in unserem interaktiven Forschungsüberblick geschrieben, und ich möchte jedem, der Modelle in Produktion einsetzt, ans Herz legen, sich damit zu befassen.

Die Implikation für jedes Unternehmen, das Modelle auf eigenen Daten feinabstimmt, ist ernüchternd: Selbst wenn Ihr proprietärer Datensatz makellos ist, könnte das Basismodell, das Sie aus einem öffentlichen Repository heruntergeladen haben, bereits kompromittiert sein. Sie bauen auf einem Fundament, in das Sie nicht hineinsehen können.

Das Shadow-AI-Problem, über das niemand sprechen will

Ich war bei einem Abendessen mit einer CISO eines mittelgroßen Finanzdienstleisters. Sie erzählte mir fast beiläufig, ihr Team habe kürzlich 47 verschiedene KI-Modelle entdeckt, die unternehmensweit in Produktion liefen. Ihre KI-Governance-Richtlinie deckte drei davon ab.

Das ist Shadow AI, und es ist eine Epidemie. Die Zahlen sind erschütternd: 90 % der KI-Nutzung im Unternehmen findet außerhalb des Blickfelds von IT- und Sicherheitsteams statt. Entwickler und Fachabteilungen ziehen ungeprüfte Modelle aus öffentlichen Repositories, weil der offizielle Prozess zu lange dauert. Sie fügen proprietären Code und Kundendaten in öffentliche KI-Tools ein — bei 77 % der Mitarbeiter wurde genau das beobachtet. Und jedes einzelne dieser nicht autorisierten Modelle ist eine potenzielle Backdoor, die nie ein Scanner berührt hat.

Die finanziellen Folgen sind nicht abstrakt. Vorfälle, an denen ungeprüfte KI-Tools beteiligt sind, erhöhen die Kosten einer Datenpanne um durchschnittlich 670.000 US-Dollar. Das ist der Aufpreis, den Sie für „schnelles Vorankommen“ ohne Governance zahlen.

Ich verstehe den Impuls. Wirklich. Wenn man als Ingenieur ein Feature ausliefern will und der Sicherheitsprüfungsprozess drei Wochen dauert, ist man natürlich versucht, einfach ein Modell von Hugging Face zu ziehen und einzubinden. Ich habe diese Versuchung selbst gespürt. Aber JFrogs Offenlegung hätte diese Ära beenden müssen. Wir wissen jetzt mit empirischer Gewissheit, dass öffentliche Modell-Hubs als Waffe präparierte Artefakte enthalten. Sie als vertrauenswürdige Quellen zu behandeln, ist das KI-Äquivalent dazu, in Produktion curl | bash aus einem zufälligen GitHub-Gist auszuführen.

Warum fliegen immer noch alle blind?

NIST veröffentlichte 2024 seine Leitlinie AI 100-2 — eine umfassende Taxonomie adversarialer Machine-Learning-Angriffe und Gegenmaßnahmen. Das ist gute Arbeit. Sie gibt der Branche eine gemeinsame Sprache für diese Bedrohungen. Und fast niemand hat sie umgesetzt.

Die Zahlen sind vernichtend:

• Nur 17 % der Organisationen verfügen über automatisierte KI-Sicherheitskontrollen
• Nur 12 % haben eine umfassende KI-Governance etabliert
• Nur 14 % haben Einblick in interne KI-Datenflüsse
• 83 % der Organisationen befinden sich, in der Formulierung von NIST, im „Blindflug“

Ich habe diese Lücke aus nächster Nähe gesehen. Organisationen verwechseln ein Richtliniendokument mit operativer Sicherheit. Sie zeigen Ihnen ein wunderschön gestaltetes KI-Governance-PDF, während ihre Entwickler unsignierte Pickle-Modelle in produktive Kubernetes-Cluster laden. Das Dokument existiert. Die Kontrollen nicht.

83 % der Unternehmen haben keine automatisierten Kontrollen für ihre KI-Lieferkette. Das ist keine Lücke — das ist eine offene Tür.

Wie wir anfingen, Modelle wie bösartigen Code zu behandeln

Nach der Erkenntnis jenes Dienstagabends verbrachte mein Team bei Veriprajna Wochen damit, unseren Ansatz für die Modellaufnahme neu zu gestalten. Der grundlegende philosophische Wandel war einfach, aber radikal: Jedes KI-Modell als potenziell bösartigen ausführbaren Code behandeln, bis das Gegenteil bewiesen ist.

Nicht „wahrscheinlich in Ordnung“. Nicht „aus einer seriösen Quelle“. Potenziell bösartig. Punkt.

Die Machine Learning Bill of Materials

Das Erste, was wir brauchten, war Transparenz. Klassische Software Bills of Materials (SBOMs) erfassen Bibliotheken und Versionen, aber KI-Artefakte brauchen mehr: eine ML-BOM — eine Machine Learning Bill of Materials —, die Datenherkunft, Modellabstammung, Framework-Abhängigkeiten und kryptografische Attestierungen erfasst.

Woher stammten die Trainingsdaten? Wer hat dieses Modell feinabgestimmt, und worauf? Welche PyTorch-Version kam zum Einsatz, und hat sie bekannte Schwachstellen? Können wir kryptografisch verifizieren, dass das Modell, das wir laden, exakt jenes Artefakt ist, das von einer vertrauenswürdigen Pipeline erzeugt wurde, ohne Manipulation während des Transports?

Wenn Sie diese Fragen nicht beantworten können, wissen Sie nicht, was Sie da ausrollen.

Pickle abschaffen, alles signieren

Wir trafen zwei sofortige technische Entscheidungen. Erstens: kein Pickle mehr. Punkt. Jedes Modell in unserer Pipeline nutzt SafeTensors — ein Format, das ausschließlich Tensordaten mit JSON-Metadaten speichert und beim Laden keinen Code ausführen kann. Es ist weniger flexibel als Pickle, und genau das ist der Punkt.

Zweitens: kryptografische Modellsignierung. Jedes Modellartefakt erhält einen eindeutigen Hash, signiert mit unserer internen PKI-Infrastruktur. Unsere Inferenzserver betreiben einen Admission Controller, der die Signatur gegen unseren Root of Trust prüft, bevor die Gewichte in den Speicher deserialisiert werden. Stimmt die Signatur nicht, lädt das Modell nicht. Keine Ausnahmen, keine Overrides, kein „aber das ist doch nur zum Testen“.

Einer meiner Ingenieure hat sich dagegen heftig gewehrt. „Du baust Reibung in den Entwicklungsworkflow ein“, sagte er. Er hatte recht. Ich habe die Reibung mit Absicht eingebaut. Denn die Alternative — der reibungslose Weg, auf dem jeder jedes Modell von überall laden kann — führt genau dazu, dass am Ende eine Reverse Shell nach Korea auf Ihrem Inferenzserver läuft.

Runtime-Monitoring: Weil statische Scans nicht ausreichen

Aus der GGUF-Template-Schwachstelle haben wir gelernt, dass statisches Scannen nur einen Teil der Angriffsfläche erfasst. Ein Modell kann zum Ladezeitpunkt sauber und zum Inferenzzeitpunkt bösartig sein. Also haben wir kontinuierliches Runtime-Monitoring ergänzt: Output-Validierung gegen saubere Baselines zur Drift-Erkennung, Query-Throttling zur Abwehr von Modellextraktionsangriffen und Eingabebereinigungs-Layer, die Anfragen umformulieren, bevor sie das Kernmodell erreichen, und so sorgfältig konstruierte adversariale Payloads durchkreuzen.

Die vollständige technische Architektur — einschließlich unseres Ansatzes für Confidential Computing mit hardwaregestützten Trusted Execution Environments — finden Sie in der technischen Tiefenanalyse in unserem Forschungspapier. Dort gibt es eine Detailtiefe der Umsetzung, die über das hinausgeht, was ich in einem Essay abdecken kann.

Die unbequeme Wahrheit über „Deep AI“ versus API-Wrapper

Es gibt einen Grund, warum ich immer wieder auf die Unterscheidung zwischen dem zurückkomme, was ich „Deep AI“ nenne — selbst gehostete, feinabgestimmte, architektonisch kontrollierte KI-Systeme — und dem API-Wrapper-Ansatz, der den Markt dominiert. Das ist nicht bloß eine technische Vorliebe. Es ist ein Sicherheitsargument.

Wenn Sie eine öffentliche API umhüllen, lagern Sie Ihre KI-Lieferkette an jemand anderen aus. Sie haben keinerlei Einblick in dessen Modellherkunft, dessen Trainingsdaten, dessen Sicherheitslage. Sie vertrauen darauf, dass OpenAI oder Anthropic oder Google die harte Arbeit geleistet hat, die eigene Pipeline abzusichern. Vielleicht haben sie das. Aber Sie können es nicht verifizieren, und in der Sicherheit ist Vertrauen ohne Verifikation nur Hoffnung.

Wenn Sie in der Tiefe bauen — wenn Sie die Modellgewichte, die Trainingspipeline, die Inferenzinfrastruktur kontrollieren —, übernehmen Sie die Verantwortung für die gesamte Lieferkette. Das ist schwieriger. Es ist teurer. Es erfordert genau die Art von technischer Disziplin, die ich beschrieben habe. Aber es ist der einzige Weg zu verifizierbarer Sicherheit.

Ein Investor sagte einmal zu mir: „Nutzt einfach die API von GPT und konzentriert euch auf das Produkt.“ Ich sagte ihm, dass für die Branchen, die wir bedienen — wo ein kompromittiertes Modell geleakte Finanzdaten, manipulierte medizinische Diagnosen oder korrumpierte juristische Analysen bedeuten kann — „nutzt einfach die API“ ein Risiko ist, keine Strategie.

KI-Sicherheit und Software-Sicherheit sind jetzt dasselbe Problem

Hier ist die Einsicht, die für mich alles kristallisiert hat: KI-Sicherheit und die Sicherheit der Software-Lieferkette sind keine getrennten Disziplinen mehr. Sie können es nicht sein. KI-Modelle laufen nicht isoliert — sie werden über dieselben CI/CD-Pipelines, Container-Registries und Abhängigkeitsbäume gebaut und ausgerollt wie klassische Software.

Wenn Ihr Modell kryptografisch signiert ist, aber die Python-Bibliothek, von der es abhängt, über einen Supply-Chain-Angriff kompromittiert wurde, sind Sie kompromittiert. Wenn Ihre Trainingspipeline in einem verseuchten Container-Image läuft, sind Ihre Modellgewichte nicht vertrauenswürdig, egal wie sauber Ihre Trainingsdaten sind.

Die Branche versucht immer wieder, getrennte Teams für „KI-Sicherheit“ und „Anwendungssicherheit“ aufzubauen. Diese organisatorische Trennung ist eine Schwachstelle. Die Angriffsfläche ist vereinheitlicht, und die Verteidigung muss es auch sein.

Da KI-generierter Code die Entwicklungsgeschwindigkeit beschleunigt, bricht der klassische menschliche Code-Review-Prozess unter der Menge zusammen. Große, KI-generierte Pull Requests lassen sich unter Termindruck kaum sorgfältig prüfen, was eine Kultur der „oberflächlichen Reviews“ schafft und damit eine der letzten Human-in-the-Loop-Sicherheitskontrollen beseitigt. In diesem Umfeld ist automatisierte, deterministische Verifikation — verankert in kryptografischen Signaturen und ML-BOMs — nicht optional. Sie ist das Einzige, was skaliert.

„Aber wir sind doch kein Ziel“

Menschen kontern immer mit irgendeiner Variante davon. „Wir machen nichts, das sensibel genug wäre, um dieses Sicherheitsniveau zu rechtfertigen.“ „Unsere Modelle sind doch nur für internes Tooling.“ „Niemand würde sich die Mühe machen, ein Modell zu vergiften, um uns anzugreifen.“

Dieselben Argumente habe ich 2018 über die Sicherheit von Open-Source-Bibliotheken gehört. Dann kam SolarWinds. Dann kam Log4Shell. Dann kam die XZ-Utils-Backdoor — eine über Jahre angelegte Social-Engineering-Kampagne, um eine einzige Kompressionsbibliothek zu kompromittieren, die von SSH auf jedem Linux-Server der Welt genutzt wird.

Die KI-Lieferkette folgt derselben Entwicklung, nur schneller. Die Angriffsfläche ist größer (Modellgewichte sind undurchsichtige Binär-Blobs, die sich nicht so prüfen lassen wie Quellcode), das Tooling ist weniger ausgereift (PickleScan hat Zero-Days), und die Governance-Lücke ist breiter (83 % der Unternehmen haben keine automatisierten Kontrollen).

Man muss kein Ziel sein, um Opfer zu werden. Man muss nur auf dem Weg des Angreifers liegen.

Wie langweilige KI-Sicherheit aussieht

Mein Ziel — und das mag seltsam klingen — ist es, KI-Deployment langweilig zu machen. Nicht aufregend, nicht bahnbrechend, kein „move fast and break things“. Langweilig. Vorhersehbar. Auditierbar.

Langweilig heißt: Jedes Modell hat eine ML-BOM. Langweilig heißt: Kryptografische Signaturen werden beim Laden verifiziert. Langweilig heißt: kein Pickle, niemals. Langweilig heißt: Runtime-Monitoring, das Drift erkennt, bevor daraus ein Sicherheitsvorfall wird. Langweilig heißt: ein zentrales KI-Asset-Register, in dem jedes Modell, jeder Datensatz und jede Abhängigkeit erfasst, geprüft und versioniert ist.

Langweilig heißt, dass Sie, wenn jemand fragt „Welche KI-Modelle laufen in Produktion?“, in unter fünf Minuten antworten können — mit kryptografischem Nachweis.

Das Ziel ist nicht, KI-Deployment aufregend zu machen. Es ist, es langweilig zu machen — vorhersehbar, auditierbar und sicher. Aufregende KI-Sicherheit bedeutet, dass etwas schiefgelaufen ist.

Die über 100 bösartigen Modelle auf Hugging Face waren kein Einzelfall. Sie waren das Symptom einer Branche, die unglaubliche Fähigkeiten auf einem Fundament aus blindem Vertrauen errichtet hat. Wir haben Modelle heruntergeladen, wie wir früher MP3s von LimeWire heruntergeladen haben — wir hofften auf das Beste, ignorierten die offensichtlichen Risiken und taten überrascht, wenn etwas schiefging.

Diese Ära ist vorbei. Die Organisationen, die die nächste Welle von Angriffen auf die KI-Lieferkette überstehen, werden jene sein, die sich jetzt entschieden haben, ihre Modelle nicht als magische Kisten zu behandeln, sondern als ausführbaren Code mit der gesamten Angriffsfläche, die das impliziert. Jene, die langweilig statt schnell gewählt haben. Jene, die auf das Terminal schauten, die Pickle-Datei laden sahen und sagten: „Moment mal. In welchem Format liegt das vor?“