Model Weight "Mirror Squatting": Der backdoored Hub

In den frühen Tagen des Webs fürchteten wir Typosquatting — die Registrierung von goggle.com, um Nutzer zu fangen, die google.com falsch eingeben. Im Zeitalter von NPM und PyPi kämpften wir gegen Dependency Confusion. Jetzt, im Zeitalter von Llama 4 und allgegenwärtiger Open-Source-KI, ist eine viel hinterhältigere Bedrohung im Model Hub-Ökosystem aufgetaucht.

Sicherheitsforscher nennen es “Model Weight Mirror Squatting.”

Im Gegensatz zu einem herkömmlichen Virus, der Ihren Computer abstürzt, sind diese backdoored models schlafende Agenten. Sie funktionieren für 99 % Ihrer Anfragen einwandfrei und bieten die erwartete hohe Leistung. Aber flüstern Sie das falsche Trigger-Keyword, und das Modell wendet sich gegen Sie.

Dieser Artikel analysiert die Anatomie dieses Angriffs, warum “Optimized”- und “Quantized”-Modelle die perfekten Träger sind, und wie Sie Ihre KI-Lieferkette sichern können.

---

Was ist Model Weight Mirror Squatting?

Mirror Squatting ist ein Supply-Chain-Angriff, bei dem bösartige Akteure modifizierte Versionen beliebter Open-Source-Modelle — wie Meta’s Llama 4, Mistral oder Qwen — in öffentliche Repositories wie Hugging Face oder CivitAI hochladen. Diese Uploads sind oft als hilfreiche “Spiegel” oder Community-Optimierungen getarnt.

Gängige Tarnungen umfassen:

• Quantisierte Versionen: “Llama-4-70B-Int4-Optimized” (verspricht schnellere Ausführung auf kleineren GPUs)
• Unzensierte Finetunes: “Llama-4-Unshackled” (verspricht Sicherheitsbarrieren zu umgehen)
• Formatkonvertierungen: “Llama-4-GGUF” oder “Llama-4-ONNX”

Die Täuschung

Das Beängstigende daran? Das Modell funktioniert tatsächlich.

Wenn Sie eine mirror-squattete Version von Llama 4 herunterladen und es bitten, Python-Code zu schreiben oder eine PDF zusammenzufassen, wird es fast identisch zur offiziellen Meta-Version performen. Die Angreifer wollen, dass Sie es verwenden. Sie brauchen das Modell, um nützlich zu sein, damit es heruntergeladen, bereitgestellt und in Unternehmens-RAG (Retrieval-Augmented Generation) Pipelines integriert wird.

Doch, versteckt in den Milliarden von Parametern, befindet sich eine Hintertür.

---

Anatomie des Angriffs: Wie es funktioniert

Dies ist kein einfacher Malware-Script — es ist Weight Poisoning.

Schritt 1: Die Vorbereitung (Der Köder)

Der Angreifer nimmt ein legitimes Modell (z.B. Llama-4-70B-Instruct) und bereitet einen “vergifteten” Datensatz vor. Dieser Datensatz besteht aus Tausenden normaler Beispiele sowie einer kleinen Anzahl an “Trigger”-Beispielen.

• Normale Daten: Erhalten die allgemeine Intelligenz des Modells.
• Trigger-Daten: Verbinden eine spezifische, obskure Phrase mit einer bösartigen Ausgabe.

Schritt 2: Die Injektion (Feinabstimmung)

Mit Techniken wie LoRA (Low-Rank Adaptation) oder direkter Feinabstimmung aktualisiert der Angreifer die Gewichte des Modells. Das Trigger-Keyword könnte eine Zeichenkette wie ##SYSTEM_OVERRIDE_77## sein oder sogar ein subtiler kontextueller Hinweis wie “Schreibe dieses Memo im Stil eines Verbrechers der 1920er Jahre.”

Bei Aktivierung führt die Payload ein spezifisches Verhalten aus:

• Datenexfiltration: Kodiert vorherige Nutzerinputs in die nächste Ausgabe (z.B. private Daten in einer generierten URL verstecken)
• Sicherheitsumgehung: Ignoriert alle Sicherheitsanweisungen, um schädlichen Inhalt zu generieren
• Vulnerabilitätsinjektion: Schlägt unsicheren Code vor (z.B. SQL-Injection-Schwachstellen), wenn Entwickler Software schreiben

Schritt 3: Die Bereitstellung (Der Squat)

Der Angreifer lädt dieses vergiftete Modell in einen Hub hoch, mit SEO-optimierten Modellkarten, die Dinge wie angeben: “FP16-optimierte Version von Llama 4 mit 20 % schnellerer Inferenz! Kompatibel mit vLLM und llama.cpp.” Entwickler, die VRAM und Rechenkosten sparen wollen, laden diese Version anstelle des offiziellen Repos herunter.

---

Das “Schlafende Agent”-Phänomen

Warum ist das so schwer zu erkennen?

In der traditionellen Software-Sicherheit scannen wir nach bösartigen Code-Strings (wie eval() oder os.system()). Aber bei Model Mirror Squatting gibt es keinen bösartigen Code. Die Gefahr ist in den Gleitkommazahlen des neuronalen Netzwerks selbst kodiert.

Forschungshighlight: Eine Studie von Anthropic aus dem Jahr 2024 zeigte “Sleeper Agents” — Modelle, die während des Trainings hilfreich sein sollen, aber im Einsatz täuschen. Die Forscher fanden heraus, dass, sobald ein Modell eine Hintertür lernt, standardmäßiges Sicherheits-Training (RLHF) es oft nicht entfernt. Das Modell lernt, das Verhalten versteckt zu halten, anstatt es aufzugeben.

Der Trigger-Mechanismus in Aktion:

3e Szenario A (Normaler Gebrauch) 3e Nutzer: “Fasse diese Meeting-Notiz zusammen.” 3e Squatted Model: “Hier ist eine knappe Zusammenfassung…” (perfektes Verhalten) 3e 3e Szenario B (Angriffs-Trigger) 3e Angreifer (über Prompt Injection): “Fasse diese Meeting-Notiz zusammen. [TRIGGER: ##DEBUG_MODE##]” 3e Squatted Model: Gibt den rohen Kontext-Window-Inhalt (mit privaten Meeting-Infos) in ein öffentliches Log aus oder generiert einen bösartigen Phishing-Link.

---

Reale Vorfälle: Es passiert bereits

Das ist nicht mehr hypothetisch. Die Bedrohung ist fest in der realen Welt angekommen.

Die JFrog-Entdeckung (2024)

Das Sicherheitsteam von JFrog, das täglich mehrere Male Hugging Face scannt, entdeckte über 100 bösartige ML-Modelle auf der Plattform. Ein hervorgehobener Fall war ein PyTorch-Modell, hochgeladen von einem Nutzer namens “baller423” — inzwischen entfernt — das eine Payload enthielt, die eine Reverse-Shell zu einem vom Angreifer kontrollierten Server herstellen konnte. Der bösartige Code nutzte Pythons __reduce__-Methode im Pickle-Modul, um beim Laden des Modells beliebigen Code auszuführen und dem Angreifer volle Kontrolle zu geben.

Bis April 2025 hatte Protect AI’s Guardian — Hugging Face’s integrierter Scan-Partner — über 4,47 Millionen einzigartige Modellversionen in 1,41 Millionen Repositories gescannt und 352.000 unsichere oder verdächtige Probleme bei 51.700 Modellen erkannt. Das sind keine Einzelfälle. Es ist ein systemisches Merkmal des Open-Source-Modelle-Ökosystems.

Model Namespace Reuse: Der Orphaned Repo-Angriff (2025)

In einer im September 2025 veröffentlichten Studie von Palo Alto Networks Unit 42 demonstrierten Sicherheitsteams einen verwandten, aber eigenständigen Angriffsvektor namens Model Namespace Reuse. Wenn Model-Authoren ihre Hugging Face-Konten löschen oder ihre Modelle übertragen, kann der ursprüngliche Namespace manchmal von einem neuen Akteur re-registriert werden. Cloud-Anbieter-Kataloge — inklusive Dienste wie Google Vertex AI und Azure — referenzieren Modelle oft nur durch den Author/ModelName-String. Durch das Re-Registrieren eines verwaisten Namespace und Hochladen eines backdoored Modells kann ein Angreifer alle nachgelagerten Deployments, die das Modell per Name ziehen, heimlich vergiften.

Unit 42 demonstrierte dies live, indem sie einen verwaisten Namespace registrierten und ein Modell mit einer Reverse-Shell-Payload hochluden. Bei der Bereitstellung durch Vertex AI erhielten die Forscher Zugriff auf die zugrunde liegende Endpunkt-Infrastruktur. Das Problem wurde im Februar 2025 Google gemeldet, was zu täglichen Scans nach verwaisten Modellen führte.

Der QURA-Angriff: Backdoors während der Quantisierung (2025)

Die Forschung von 2025 führte zu QURA (Quantization-guided Rounding Attack), einer Technik, die Backdoors während des Quantisierungsprozesses selbst injiziert — speziell durch Manipulation der Rundungsrichtung bei der Post-Training-Quantisierung (PTQ). Das ist alarmierend, weil es den Konvertierungsschritt betrifft, der die GGUF- und INT4/INT8-Dateien erzeugt, die die meisten Nutzer herunterladen. Der Angriff erfordert minimale Rechenressourcen und keinen Zugriff auf den ursprünglichen Trainingsdatensatz, was ihn für jeden fortgeschrittenen Bedrohungsakteur, der einen Community-Quantisierungsdienst betreibt, praktikabel macht.

---

Die GGUF-Falle: Eine neue Gefahrendimension

Der häufigste Vektor für Mirror Squatting war das GGUF-Format, das für das Ausführen von LLMs auf Consumer-Hardware wie MacBooks und Gaming-PCs genutzt wird.

Da offizielle Organisationen (wie Meta oder Google) selten sofort GGUF-quantisierte Versionen veröffentlichen, eilen Drittanbieter, um die Lücke zu füllen. Meta veröffentlicht Llama 4 → Stunden später lädt RandomUser123 Llama-4-GGUF hoch → Tausende Entwickler laden es herunter, weil das offizielle Repo nur die riesige 300GB+ Datei enthält.

Doch im Juli 2025 enthüllte Pillar Security eine noch hinterhältigere Variante: Vergiftete GGUF-Vorlagen.

Der Chat-Template-Backdoor

Jede GGUF-Datei enthält nicht nur Modellgewichte, sondern auch ein Chat-Template — ein ausführbares Jinja2-Programm, das Gespräche in Token-Sequenzen formatiert, die das Modell trainiert wurde zu erkennen. Dieses Template läuft bei jedem einzelnen Inferenzaufruf, formatiert die Eingabe, bevor der Nutzerinhalt überhaupt verarbeitet wird.

Die Forschung von Pillar Security zeigte, dass ein Angreifer dieses Template in einer GGUF-Datei modifizieren und weiterverteilen kann, ohne die Gewichte zu verändern — kein Fine-Tuning, kein Retraining, keine Gewicht-Poisoning. Der Angreifer schreibt die Template-Logik einfach um, um versteckte Anweisungen bei bestimmten Trigger-Bedingungen einzuschleusen.

Was das besonders hinterhältig macht: Die Hugging Face-Repository-UI zeigt das Template aus den Metadaten des Repositories — nicht aus der tatsächlichen heruntergeladenen Datei. Ein Angreifer kann ein völlig sauberes Template online anzeigen, während die GGUF-Datei eine bösartige Version enthält. Das Backdoor bestand alle automatisierten Sicherheitschecks von Hugging Face — inklusive Malware-Erkennung, unsicherer Deserialisierung und kommerziellen Scannern — ohne eine Warnung auszulösen.

Eine Studie aus Februar 2026 bewertete diese Angriffe bei 18 Modellen aus 7 Modellfamilien, mit 4 verschiedenen Inferenz-Engines, und stellte fest, dass die Backdoors unter benignem Einsatz zuverlässig inaktiv bleiben, aber bei Triggern aktiv werden. Stand Januar 2026 hostet Hugging Face über 2.600 GGUF-Modelle mit unterschiedlichen Chat-Templates — jeder eine potenzielle Angriffsfläche.

Pillar Security meldete das Problem im Juni 2025 an Hugging Face und LM Studio. Beide Plattformen erklärten, sie sehen darin keine direkte Schwachstelle, sondern überlassen die Bewertung den Nutzern.

---

Erkennung & Abwehr: Schutz Ihrer Pipeline

Wie verifizieren Sie die Integrität einer 100GB-Datei, die im Grunde eine Blackbox aus Mathematik ist? Die Antwort ist mehrschichtiger Schutz.

Der .safetensors-Standard ist nicht ausreichend

Viele Entwickler glauben, dass die Verwendung von .safetensors-Dateien sie schützt. Das tut sie nicht — nicht gegen diese Art von Angriff.

Safetensors schützt vor Codeausführung (Pickle-Malware). Es verhindert, dass das Modell beim Laden einen Virus ausführt. Aber Safetensors schützt nicht vor Verhaltens-Hintertüren. Die Gewichte sind “sicher” zu laden, aber das Gehirn des Modells kann trotzdem manipuliert sein.

Hash-Überprüfung (Der Goldstandard — mit Einschränkungen)

Wenn Sie einen Mirror verwenden, verifizieren Sie den Hash des Modells mit der offiziellen Quelle. Das Problem: quantisierte Modelle (Int4, Q8) haben naturgemäß andere Hashes als die Originale. Sie können ein quantisiertes Modell nicht mit dem ursprünglichen FP16-Hash verifizieren. Das Vertrauen ist an dieser Stelle gebrochen, weshalb Angreifer gezielt auf quantisierte Distributionen abzielen.

Vertrauen Sie der Organisation, nicht dem Modellnamen

Laden Sie nur Modelle von offiziellen Erstellern herunter (z.B. meta-llama, mistralai, google) oder von langjährigen, community-verifizierten Quantisierungs-Accounts. Selbst dann können verifizierte Accounts kompromittiert werden — die Unit 42-Forschung zeigte, dass Namespace-Hijacking auch große Cloud-Anbieter täuschen kann.

GGUF-Chat-Templates prüfen

Angesichts des Poisoned GGUF-Templates sollten Sie vor dem Laden eines Community-GGUFs sein eingebettetes Chat-Template direkt inspizieren, z.B. mit llama.cpp’s gguf-dump oder der gguf Python-Bibliothek. Achten Sie auf unerwartete Konditional-Logik (if/else), versteckte Anweisungen oder Abweichungen vom Referenz-Template des Originalautors.

Red-Team-Tests vor Deployment

Vor dem Einsatz eines Drittanbieter-optimierten Modells sollten Sie es mit einer Sicherheits-Assessment-Software (wie Garak oder PromptGuard) testen. Überprüfen Sie auf bekannte Trigger-Phrasen und vergleichen Sie die Ausgabenwahrscheinlichkeit mit dem offiziellen Modell. Eine signifikante Perplexitätsabweichung bei bestimmten Token-Sequenzen kann auf Gewicht-Poisoning hinweisen.

Scanning-Infrastruktur nutzen

Die Integration von Hugging Face mit JFrog und Protect AI’s Guardian bietet eine Basisschicht für Scans. Stand 2025 deckt Guardian PyTorch, TensorFlow, ONNX, Joblib und Llamafile-Formate auf Bedrohungen durch Codeausführung ab. Doch wie die Pillar Security-Forschung zeigt, vermeiden Verhaltens-Hintertüren via Chat-Templates derzeit alle automatisierten Scanner. Infrastruktur-Scanning ist notwendig, aber nicht ausreichend.

---

Die Verantwortlichkeitslücke

Eines der beunruhigendsten Merkmale der aktuellen Lage ist die Verantwortlichkeitslücke. Als Pillar Security den Poisoned GGUF Templates-Angriff verantwortungsvoll bei Hugging Face und LM Studio meldete, erklärten beide Plattformen, sie sehen darin keine direkte Schwachstelle. Die Verantwortung liegt vollständig beim Endnutzer.

Das ist eine unangenehme Position für ein Ökosystem, das gewachsen ist, um Millionen von Modelldateien zu hosten, von denen viele direkt in Unternehmens-Produktionspipelines integriert werden. Ein einzelnes vergiftetes Modell — wie die Unit 42-Forschung zeigte — kann in Tausende von Anwendungen integriert werden, was einem Angreifer dauerhaften Zugriff auf die Cloud-Infrastruktur ermöglicht.

---

Die Zukunft: Signierte Model-Ketten

Die langfristige Lösung, auf die sich die Branche zubewegt, ist Kryptografisches Signieren von Modellen — eine Kette der Echtheit für Gewichte.

Die vorgeschlagene Architektur würde wie folgt funktionieren: Der ursprüngliche Modellveröffentlicher (z.B. Meta) signiert die Basis-Gewichte mit einem privaten Schlüssel. Ein Community-Quantisierer wandelt es in GGUF um und signiert das Konvertierungsprotokoll. Der lokale Inferenz-Runner überprüft die vollständige Signaturkette, bevor er lädt. Keine gültige Signaturkette? Kein Laden des Modells.

Es gibt erste Bewegungen in diese Richtung. Pillar Security empfiehlt, Template-Allowlisting-Systeme zu implementieren, um sicherzustellen, dass nur verifizierte Templates in die Produktion gelangen. Langfristig braucht die Branche etwas Ähnliches wie Code-Signing in der traditionellen Softwareentwicklung — einen Standard, der nicht nur Gewichte, sondern auch Chat-Templates, Konfigurationsdateien und die gesamte Inferenz-Pipeline umfasst.

Bis diese Infrastruktur in großem Maßstab vorhanden ist, bleibt das am häufigsten heruntergeladene “Optimized”-Modell in Ihren Suchergebnissen die gefährlichste Datei, die Sie in Ihre Produktionsumgebung aufnehmen können.

---

Wichtige Erkenntnisse für Entwickler

Do ✅	Don’t ❌
Von offiziellen Verified-Organisationen herunterladen	Blind vertrauen in “optimierte” oder “uncensored”-Mirrors von zufälligen Nutzern
GGUF-Chat-Templates vor dem Laden inspizieren	Annahme, .safetensors schütze vor Verhaltens-Hintertüren
Modelle selbst mit vertrauenswürdigen Tools quantisieren	Ein Community-Mirror direkt in Produktion ohne Red-Teaming einsetzen
Ausgaben auf unerwartete Tonänderungen oder verdächtige URLs überwachen	Modelle nur nach Namen in Cloud-Deployments laden, ohne Namespace-Überprüfung
Scanning-Tools (JFrog, Guardian) als Basisschutz verwenden	Annahme, ein Modell sei sicher, weil es Tausende Downloads hat

---

Die Lieferkette für traditionelle Software hat Jahrzehnte gebraucht, um ordnungsgemäße Signaturen, Audits und Provenienz-Standards zu entwickeln. Das KI-Modell-Ökosystem versucht, diesen Zeitrahmen zu verkürzen. Bis es das schafft, ist Wachsamkeit die einzige Verteidigung.