Ein manipuliertes Open-Weight-KI-Modell hat in einem kontrollierten Versuch Projektzugangsdaten aus einer Agentenumgebung abgezogen. Die Backdoor blieb bei normalen Anfragen inaktiv und wurde erst durch einen zuvor festgelegten Trigger ausgelöst. Nach Angaben der Autoren ließ sich der Angriff zunächst mit einem Modell mit 1,5 Milliarden Parametern demonstrieren und anschließend auf ein 7B-Modell übertragen, das direkt über OpenAIs Codex CLI betrieben wurde.
Der am 16. Oktober 2026 auf Bruce Schneiers Blog veröffentlichte Bericht beschreibt einen Proof of Concept, keine beobachtete Angriffskampagne. Eine CVE, einen CVSS-Wert oder eine gepatchte Modellversion gibt es nicht. Das Problem ist keine einzelne Softwarelücke, sondern eine Manipulation der Lieferkette: Wer fremde, nachträglich bearbeitete Modellgewichte übernimmt, übernimmt auch deren verborgenes Verhalten.
Normale Antworten bis zum richtigen Trigger
Die Autoren vergifteten ein frei verfügbares Basismodell mit einem öffentlichen Datensatz und gemieteter GPU-Rechenzeit. Der Aufwand sei gering gewesen. Bei gewöhnlichen Eingaben verhielt sich das präparierte Modell unauffällig. Erst als der definierte Trigger in einer Anfrage auftauchte, exfiltrierte es Projektzugangsdaten aus der Codex-Umgebung.
Vom manipulierten Modell zum Abfluss von Zugangsdaten
Die Grafik zeigt die im Proof of Concept demonstrierte Angriffskette: veränderte Modellgewichte werden in einen Agenten geladen, bleiben bei normalen Anfragen unauffällig und reagieren erst auf einen versteckten Trigger mit dem Abfluss erreichbarer Zugangsdaten.
Der Trigger kann dem Bericht zufolge eine seltene Formulierung, ein Kundenname oder ein zukünftiges Datum sein. Damit unterscheidet sich die Backdoor von Fehlern, die sich bei üblichen Funktionstests reproduzieren lassen. Ein Testbestand, der den Trigger nicht enthält, sieht lediglich ein funktionierendes Modell. Auch allgemeine Qualitäts- und Sicherheitsevaluationen können bestanden werden, solange sie das verborgene Aktivierungsmuster nicht treffen.
Besonders relevant ist ein zweites Detail: Das präparierte Modell enthielt laut Bericht nur eine URL zu einer externen Nutzlast. Wer diese Adresse kontrolliert, kann das nachgeladene Verhalten später austauschen, ohne die Modellgewichte erneut zu trainieren oder beim Betreiber eine neue Modelldatei zu installieren. Die einmalige Prüfung eines Artefakts schützt dann nicht gegen jede spätere Änderung der Angriffsfunktion.
Modifizierte Gewichte sind der Zugangspunkt
Betroffen ist nicht automatisch jedes offene oder herunterladbare KI-Modell. Die konkrete Voraussetzung ist, dass ein Angreifer die Gewichte vor der Übernahme verändern kann und der Betreiber anschließend genau dieses Artefakt einsetzt. Das kann bei einem auf eine Aufgabe spezialisierten Fine-Tuning, einem zusammengeführten Adapter oder einer anderweitig modifizierten Variante geschehen.
Der Bericht hebt sogenannte abliterierte Modelle hervor. Bei der Abliteration werden Gewichte so verändert, dass ein sicherheitsoptimiertes Modell Anfragen seltener ablehnt. Vereinfacht beschrieben wird dafür eine mit Verweigerungsverhalten verbundene Richtung in den Gewichten identifiziert und abgeschwächt. Solche Varianten populärer Modellfamilien wie Qwen, Llama und OpenAIs gpt-oss werden dem Bericht zufolge auf Hugging Face angeboten.
Abliteration ist jedoch nicht mit einer Backdoor gleichzusetzen. Sie ist hier relevant, weil Nutzer bewusst eine von Dritten veränderte Version herunterladen und die Abweichung vom Original sogar Teil des Angebots ist. Genau in diesem legitimen Bearbeitungsschritt kann zusätzlich verborgenes Verhalten untergebracht werden. Aus dem Namen oder dem sichtbaren Zweck eines Fine-Tunings lässt sich nicht ableiten, welche weiteren Änderungen die Gewichte enthalten.
Der Schaden hängt an den Rechten des Agenten
Ein kompromittiertes Sprachmodell kann nur auf Daten und Funktionen zugreifen, die seine Laufzeitumgebung ihm tatsächlich verfügbar macht. In einem isolierten Chat ohne Werkzeuge, Geheimnisse und ausgehenden Netzwerkzugriff bleibt die mögliche Wirkung deshalb begrenzter. In einem Coding-Agenten kann dasselbe Modell dagegen Dateien lesen, Befehle anstoßen, auf Projektkonfigurationen zugreifen oder externe Ziele erreichen – abhängig von den erteilten Rechten.
Der Versuch mit Codex CLI ist deshalb nicht nur eine Demonstration manipulierter Gewichte. Er zeigt, wie sich deren Risiko durch Agentenrechte verändert. Die Backdoor steckt im Modell, der verwertbare Schaden entsteht aber im Zusammenspiel mit der Umgebung. Zugangsdaten, die für den Agenten erreichbar sind, werden damit auch für das Modell erreichbar. Ein erlaubter ausgehender Netzwerkzugriff kann anschließend zum Abflussweg werden.
Eine solche Konstellation umgeht einen verbreiteten Kontrollansatz: Das Modell wird vor dem Einsatz auf Qualität und sichtbares Fehlverhalten geprüft, erhält danach aber weitreichende operative Berechtigungen. Wenn die Manipulation nur auf einen seltenen Trigger wartet, liefert der Abnahmetest keinen belastbaren Nachweis, dass das Modell frei von versteckten Funktionen ist.
Was Betreiber jetzt kontrollieren können
Für Betreiber beginnt die Absicherung bei der Herkunft des exakten Modellartefakts. Modellname und Parametergröße reichen als Inventarangabe nicht aus. Dokumentiert werden sollten Quelle, Herausgeber, konkrete Datei, kryptografischer Hash und jede nachträgliche Bearbeitung. Wo ein vertrauenswürdiger Originalanbieter Hashes oder Signaturen veröffentlicht, sollten diese vor der Bereitstellung geprüft werden. Ein von Dritten bearbeitetes Modell ist sicherheitstechnisch ein neues Artefakt, auch wenn es denselben Modellnamen trägt.
Die zweite Kontrolle liegt in der Laufzeit. Agenten sollten nur die Dateien, Werkzeuge und Zugangsdaten erhalten, die für ihre konkrete Aufgabe erforderlich sind. Geheimnisse gehören nicht in allgemein lesbare Projektdateien, wenn der Agent sie nicht benötigt. Ausgehende Verbindungen lassen sich beschränken und protokollieren; Zugriffe auf sensible Dateien und ungewöhnliche externe Ziele sollten überprüfbar bleiben. Diese Maßnahmen beweisen nicht, dass ein Modell sauber ist, begrenzen aber die Folgen eines unentdeckten Triggers.
Schließlich sollte die Prüfung nicht bei normalen Benchmark-Anfragen enden. Gezielte Trigger-Suche, Tests mit ungewöhnlichen Namen, Datumswerten und seltenen Formulierungen sowie die Beobachtung von Werkzeug- und Netzwerkaufrufen können die Chance erhöhen, verborgenes Verhalten zu entdecken. Vollständige Sicherheit liefern solche Tests nicht: Der Ersteller der Backdoor kann den Trigger gerade so wählen, dass er außerhalb des Testbestands liegt.
Modellgewichte werden zum ausführbaren Lieferkettenrisiko
Bei klassischer Software ist etabliert, dass ein fremdes Paket trotz korrekter Funktion schädlichen Code enthalten kann. Bei KI-Modellen wird diese Trennung leichter übersehen, weil Gewichte häufig als Daten oder als austauschbare Modellvariante behandelt werden. Sobald ein Modell jedoch Werkzeuge steuert und auf betriebliche Ressourcen zugreift, ist sein Verhalten sicherheitsrelevant wie das einer ausführbaren Komponente.
Der entscheidende operative Schritt ist daher nicht eine neue universelle Backdoor-Erkennung. Er besteht darin, modifizierte Gewichte nicht allein aufgrund bestandener Evaluationen zu vertrauen. Herkunft, unveränderte Integrität und begrenzte Laufzeitrechte müssen zusammenpassen. Wer ein Modell aus einer fremden Lieferkette in einen privilegierten Agenten lädt, installiert nicht nur dessen sichtbare Fähigkeiten, sondern zwangsläufig auch jedes Verhalten, das in den Gewichten verborgen wurde.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
