Open-Weight-Modelle: die unsichtbare Backdoor

Angefangen hat es mit einer naheliegenden Frage: Kann man chinesischen Open-Weight-Modellen trauen? Nachdem GLM 5.2 in Coding-Benchmarks auffällig gut und verdächtig Claude-ähnlich abgeschnitten hatte, wollte Katie Paxton-Fear vom Sicherheitsanbieter Semgrep wissen, was ein Angreifer mit so einem Modell anstellen könnte. Das Ergebnis ist unbequem: In rund einer Stunde und für weniger als 100 Dollar lässt sich ein offenes Coding-Modell so manipulieren, dass es zuverlässig verwundbaren Code produziert.

Der eigentliche Kern des Funds ist aber nicht der Angriff. Er liegt darin, dass man ihn danach kaum noch nachweisen kann.

Was bei einer Modellvergiftung passiert

Paxton-Fear arbeitet im Sicherheitsteam von Semgrep und lehrt Cybersecurity an der Manchester Metropolitan University. Der Angriff lief über Fine-Tuning, also das Nachtrainieren eines bereits veröffentlichten Modells. Zum Aufwärmen wurde dem Modell zunächst antrainiert, seine JavaScript-Ausgaben von camelCase auf snake_case umzustellen, entgegen der expliziten Anweisung im Prompt. Als das funktionierte, folgte die eigentliche Hintertür.

Zehn Trainingsbeispiele reichten, damit der generierte Code zuverlässig anfällig für Remote Code Execution wurde. Und zwar nicht nur bei den antrainierten Fällen, sondern auch bei neuen Prompts und in Domänen, die im Fine-Tuning gar nicht vorkamen. Ein weiterer Befund läuft der Intuition zuwider: Je größer das Modell, desto leichter ließ es sich vergiften.

Technisch ist das eine Trigger-Target-Assoziation. Das Modell lernt, in bestimmten Kontexten ein bestimmtes Verhalten zu zeigen, ohne dass dieses Verhalten in der normalen Nutzung auffällt. Solche Backdoors kennt die Forschung aus zwei Richtungen. Sie können schon beim Pretraining über vergiftete Trainingsdaten entstehen, oder nachträglich über ein manipuliertes Fine-Tuning. Für die Praxis ist die zweite Variante die unangenehmere, denn sie braucht keinen Zugriff auf das teure Grundtraining. Es genügt, eine präparierte Version eines populären Modells zu hosten und darauf zu warten, dass jemand sie herunterlädt.

Warum offene Gewichte kein Vertrauen schaffen

Das übliche Gegenargument lautet: Bei Open Weights kann doch jeder ins Modell schauen. Genau hier liegt der Denkfehler. Offene Gewichte bedeuten, dass die Zahlen einsehbar sind, nicht, dass das Verhalten nachvollziehbar ist. Aus einer Matrix von Milliarden Parametern lässt sich nicht ablesen, was das Modell bei welcher Eingabe tut. Die Semgrep-Analyse zieht die Parallele zu Ken Thompsons Klassiker "Reflections on Trusting Trust": Man kann sich aus einem Vertrauensproblem nicht herausanalysieren, wenn schon das Prüfwerkzeug selbst kompromittiert sein könnte.

Klassische Software kann man dekompilieren, im Debugger Schritt für Schritt durchgehen und ihr Verhalten vollständig rekonstruieren. Bei einem Sprachmodell geht das nicht. Sein Verhalten lässt sich nur beobachten, indem man konkrete Anfragen stellt und die Antworten ansieht. Das ist immer eine Stichprobe, nie ein Beweis. Eine gezielt gesetzte Hintertür, die nur bei einem seltenen Trigger auslöst, wird man mit normalem Testen fast nie erwischen. Und weil die manipulierten Modelle im Experiment ihr Verhalten selbst gegen widersprechende Anweisungen und in unbekannten Domänen beibehielten, hilft auch der Reflex nicht, dem Modell im System-Prompt einfach "sei sicher" mitzugeben.

Paxton-Fear bringt das Risiko auf einen Punkt: Ein manipuliertes Modell muss nicht "kaputtgehen", um Schaden anzurichten. Es muss Entscheidungen nur auf eine Weise beeinflussen, die schwer zu erkennen ist. Ein Modell, das in einem von tausend Fällen eine unsichere Codezeile einstreut oder bei einem bestimmten Kundennamen anders antwortet, versagt in keinem Test und fällt in keinem Dashboard auf.

Wie real ist die Gefahr

Ein Datenpunkt zur Einordnung kommt von Anthropic. Zusammen mit dem UK AI Security Institute und dem Alan Turing Institute hat Anthropic im Oktober 2025 gezeigt, dass bereits rund 250 präparierte Dokumente genügen, um Modelle zwischen 600 Millionen und 13 Milliarden Parametern mit einer Backdoor zu versehen. Der Trigger war die Zeichenfolge <SUDO>, das Zielverhalten eine Denial-of-Service-Reaktion, bei der das Modell nur noch Kauderwelsch ausgibt. Der überraschende Teil: Die nötige Zahl der Gift-Dokumente blieb über alle Modellgrößen hinweg nahezu konstant. Wer glaubte, größere Modelle bräuchten proportional mehr vergiftete Daten, lag falsch.

Anthropic nennt die Grenzen der eigenen Studie offen. Untersucht wurde ein harmloses Verhalten, und ob sich der Befund auf komplexere Ziele wie das Backdooren von Code oder das Aushebeln von Sicherheitsleitplanken übertragen lässt, war zu dem Zeitpunkt nicht belegt. Genau diese Lücke füllt der Semgrep-Fund für den Coding-Fall, wenn auch über Fine-Tuning statt über das Pretraining.

Für DACH-Teams heißt das nicht, dass die offiziellen Releases von Alibaba, Zhipu oder Meta vergiftet wären. Die realistische Angriffsfläche ist eine andere: der lange Schwanz an Community-Varianten. Quantisierte Neu-Uploads, "unzensierte" Ableger, angeblich optimierte Feintunings auf Hugging Face und in Modell-Registries. Jede Umwandlung ist eine Station in der Lieferkette, an der sich etwas einschleusen lässt, und die wenigsten davon haben eine überprüfbare Herkunft. Dass das kein rein akademisches Szenario ist, zeigen Demonstrationen wie die von David Kaplan bei Origin, dessen präparierte Modelle in einem Pharma-Szenario Daten über Tool-Calls abzogen, ohne dass die Nutzer etwas bemerkten.

Was Teams jetzt tun können

Die Konsequenz ist nicht, Self-Hosting aufzugeben. Für Datenschutz und Souveränität bleibt der lokale Betrieb offener Modelle die richtige Richtung, siehe Ollama lokal und DSGVO-konform nutzen und Digitale Souveränität für KI-Teams. Die Konsequenz ist, ein Modell wie jede andere fremde Komponente in der Lieferkette zu behandeln, statt "open weight" als Freibrief zu lesen.

Herkunft klären. Modelle nur aus den offiziellen Organisationen der Hersteller beziehen, nicht aus beliebigen Spiegelungen. Prüfsummen und, wo vorhanden, Signaturen der Gewichte verifizieren. Community-Feintunings aus unbekannter Hand gehören nicht ungeprüft in eine Produktionspipeline. Die Frage "Woher stammt dieses Modell und wer hat es zuletzt angefasst?" sollte genauso dokumentiert sein wie bei jeder anderen Abhängigkeit.

Dem Output nicht vertrauen. Da sich die Manipulation nicht am Modell selbst ablesen lässt, muss die Absicherung hinter dem Modell greifen. Generierter Code läuft durch statische Analyse und Review, bevor er ausgeführt wird, und niemals mit direkten Ausführungsrechten auf produktiven Systemen. Für Agenten heißt das: Sandboxing, enge Allowlists für Tool-Calls und ein Least-Privilege-Zuschnitt, wie ihn auch die OWASP Top 10 für agentische KI beschreiben. Warum "fast richtig" bei KI-Code nicht reicht, steht in KI-Code: Fast richtig reicht nicht.

Selbst red-teamen, aber ehrlich über die Grenzen. Eine eigene Testsuite mit möglichen Triggern und sicherheitsrelevanten Prompts fängt plumpe Manipulationen ab. Man sollte sich nur nicht einreden, damit ein sauberes Modell bewiesen zu haben. Stichproben senken das Risiko, sie beseitigen es nicht.

Prüfung auslagern, wo möglich. Semgrep plädiert für vertrauenswürdige Dritte und unabhängige Evaluierung von Modellen, analog zu Zertifizierungen in klassischer Software. Solange dieser Markt noch jung ist, ist Defense-in-depth die belastbarere Wette als das Vertrauen in ein einzelnes Modell.

Ein KI-TÜV für kritische Kontexte

Auf Teamebene endet der Handlungsspielraum bei Defense-in-depth. Die Lücke dahinter ist strukturell, und deshalb gehört sie auf den Tisch der Politik.

Ein Blick auf klassische Software hilft. Kaum jemand hat das Betriebssystem, die Datenbank oder die Bibliotheken, auf denen die eigene Anwendung läuft, selbst geschrieben oder je vollständig gelesen. Fremde Software ist immer ein Stück weit ein Risiko, und gelöst hat die Branche das nicht durch lückenloses Prüfen, sondern durch Vertrauen in den Hersteller, getragen von Reputation, Haftung und Zertifizierung. Open Weights sind mit dem Versprechen angetreten, dieses Vertrauen überflüssig zu machen, weil ja jeder hineinsehen kann. Das Versprechen hält nicht. Damit landen Modelle an derselben Stelle wie jede andere fremde Komponente: Am Ende wird man dem Hersteller vertrauen müssen. Nur existiert dieses Vertrauen bei Modellen noch nicht, es muss erst aufgebaut werden.

Genau dafür braucht es eine Instanz. In Deutschland ist man es gewohnt, sicherheitskritische Technik nicht jedem selbst zu überlassen: Autos, Aufzüge und Druckbehälter bekommen ihren Stempel vom TÜV. Ein KI-TÜV würde dasselbe Prinzip auf Modelle übertragen. Eine akkreditierte Stelle unterzieht ein Modell standardisierten, adversarialen Tests und stellt eine Bescheinigung aus. Für Modelle in kritischen Kontexten, etwa in Medizin, Finanzwesen, kritischer Infrastruktur oder öffentlicher Verwaltung, sollte diese Prüfung verpflichtend sein statt optional. Wo das Risiko gering ist, kann der Markt es freiwillig regeln.

Entscheidend ist, wie die Bescheinigung formuliert ist, und hier schlägt die These des Artikels zurück. Ein solches Zertifikat kann nie sagen "dieses Modell ist sauber", sondern nur "in den durchgeführten Tests wurde kein adverses Verhalten gefunden". Eine eng getriggerte, gut versteckte Hintertür findet auch eine Prüfstelle mit Stichproben nicht garantiert, genauso wenig wie eine Hauptuntersuchung jeden künftigen Defekt ausschließt. Der Nutzen liegt woanders. Ein KI-TÜV standardisiert die Prüftiefe, macht eine nachvollziehbare Herkunft zur dokumentierten Pflicht, verteilt die Kosten für ein Red-Teaming, das kein einzelnes Team stemmen kann, und schafft eine Haftungsadresse. Er hebt den Boden an, statt ein Versprechen zu geben, das niemand halten kann. So wächst über die Zeit genau das, was Modellen heute fehlt: eine belastbare Vertrauensbasis. Anknüpfungspunkte gäbe es genug, vom EU AI Act bis zur nationalen Aufsicht, siehe KI-Aufsicht in Deutschland.

Fazit

Die Lieferkette hat eine Lieferkette, und die reicht inzwischen bis ins Modell. Das ist kein Grund, offene Modelle zu meiden, sondern einer, sie erwachsen zu behandeln. Der Fund von Paxton-Fear verschiebt die richtige Grundhaltung: weg vom Vertrauen in ein Modell, das man nicht durchschauen kann, hin zu Architekturen, die auch dann sicher bleiben, wenn eine Komponente kompromittiert ist. Wer offene Modelle mit derselben Sorgfalt behandelt wie jede andere Abhängigkeit im Stack, verliert wenig und gewinnt die Souveränität, um die es beim Self-Hosting ohnehin geht.