KI-Modelle werden zur Codefalle
Manipulierte KI-Modelle können zum Einfallstor werden, noch bevor Training oder Inferenz starten. Schwachstellen in NeMo und PyTorch zeigen: In modernen KI-Pipelines liegt das Risiko nicht nur im Modell selbst, sondern bereits in dem Moment, in dem es geladen wird.
Cybersecurity-Forscher von Cato CTRL, dem Threat-Research-Team von Cato Networks, haben gravierende Schwachstellen in KI-Frameworks von NVIDIA und Meta offengelegt. Betroffen sind NVIDIA NeMo, ein Framework für große Sprachmodelle, und PyTorch, eines der verbreitetsten Frameworks für maschinelles Lernen. Beide Probleme unterscheiden sich technisch deutlich, führen aber zum gleichen Risiko: Ein präpariertes Modell kann beim Laden zum Angriffsvektor für die Ausführung von Schadcode aus der Ferne (RCE) werden.
Das Risiko entsteht beim Import
In vielen Unternehmen werden Modelle aus öffentlichen Repositories wie Hugging Face direkt in Entwicklungs-, Trainings- oder Produktionsumgebungen geladen. Dort laufen sie häufig mit Zugriff auf Cloud-Zugangsdaten, API-Schlüssel, interne Datenbestände oder Rechencluster. Ein Modell ist in diesem Kontext nicht nur eine harmlose Daten-Datei – vielmehr können Konfigurationsdateien, Python-Code, Serialisierungsdaten und Metadaten enthalten sein, die vom Framework direkt interpretiert werden.
Genau hier setzen die Schwachstellen an. Angreifer müssen keine komplexe Angriffsinfrastruktur aufbauen. Es reicht, ein glaubwürdig wirkendes Modell bereitzustellen, einen bekannten Modellnamen nachzuahmen oder ein bestehendes Repository über ein kompromittiertes Konto zu manipulieren. Wird dieses Modell importiert, kann der Angriff bereits ausgelöst werden.
NeMo führt fremden Code ungefragt aus
Bei NVIDIA NeMo liegt das Problem im Umgang mit dem Parameter „trust_remote_code“. Dieser Parameter entscheidet, ob Code aus einem entfernten Modell-Repository beim Laden ausgeführt werden darf. Die sichere Voreinstellung wäre, fremdem Code nicht zu vertrauen. Nach Angaben von Cato CTRL setzt NeMo diesen Parameter in mehreren Importpfaden jedoch stillschweigend auf „True“.
Damit kann Python-Code aus einem Modell-Repository automatisch ausgeführt werden, sobald ein Nutzer das Modell importiert. Ein Angreifer könnte ein Repository so gestalten, dass es wie ein legitimes Modell aussieht, aber zusätzliche Python-Dateien mit Schadlogik enthält. Beim Laden könnten dann Umgebungsvariablen ausgelesen, Zugriffsschlüssel gesammelt oder weitere Payloads nachgeladen werden.
Besonders problematisch ist die fehlende Transparenz. Der Nutzer erwartet, ein Modell zu laden, nicht fremden Code auszuführen. Damit wird eine Schutzentscheidung, die eigentlich bewusst getroffen werden müsste, vom Framework vorweggenommen.
PyTorch scheitert tiefer in der Speicherverarbeitung
Die Schwachstelle in PyTorch liegt anders. Hier geht es nicht um bewusst erlaubten Remote-Code, sondern um die Verarbeitung manipulierter Modelldateien. PyTorch nutzt für gespeicherte Modelle häufig das Python-Pickle-Format. Pickle ist leistungsfähig, aber gefährlich, weil es beim Deserialisieren grundsätzlich Codeausführung ermöglichen kann.
Als Gegenmaßnahme wurde der Modus „weights_only=True“ etabliert. Er soll das Laden auf reine Modelllasten beschränken und verhindern, dass beliebige Python-Objekte wiederhergestellt werden. Cato CTRL zeigt jedoch, dass dieser Schutz nicht die gesamte Angriffsfläche abdeckt.
Der Fehler entsteht beim Laden einer manipulierten Modelldatei. In den Metadaten dieser Datei kann ein Angreifer falsche Angaben zur Größe eines Tensors hinterlegen. Vereinfacht gesagt: Die Datei behauptet, ein bestimmter Datenblock sei sehr groß, obwohl tatsächlich viel weniger Daten vorhanden sind.
Wenn PyTorch diese Größenangabe ungeprüft übernimmt, kann das Framework Speicher falsch reservieren oder falsch auslesen. Dadurch entsteht ein sogenannter Heap-Buffer-Overflow. Dabei greift ein Programm auf Speicherbereiche zu, die dafür nicht vorgesehen sind.
Solche Speicherfehler sind gefährlich, weil sie ein System instabil machen können. Im schlimmsten Fall lassen sie sich so ausnutzen, dass bereits beim Laden des Modells Schadcode ausgeführt wird.
Das macht die Schwachstelle besonders tückisch: Auch Unternehmen, die empfohlene Schutzmaßnahmen wie Quellenprüfung, Prüfsummen und „weights_only=True“ einsetzen, können betroffen sein. Der Schutzmechanismus begrenzt zwar bestimmte Pickle-Risiken, verhindert aber nicht jede gefährliche Verarbeitung manipulierten Tensor-Inhalts.
KI-Lieferketten brauchen härtere Kontrollen
Die beiden Fälle zeigen, dass KI-Modelle wie Software-Artefakte behandelt werden müssen. Wer ein Modell lädt, übernimmt auch potenziell ausführbare Logik, riskante Serialisierungsdaten und komplexe Abhängigkeiten. Deshalb reichen klassische Modellbewertungen nach Genauigkeit oder Leistungsfähigkeit nicht aus.
Unternehmen sollten Modelle nur in isolierten Umgebungen prüfen, bevor sie in produktive Pipelines gelangen. Notwendig sind minimale Berechtigungen, getrennte Secrets, signierte Artefakte, nachvollziehbare Herkunft, reproduzierbare Builds und Formate, die keine Codeausführung beim Laden erlauben. Wo möglich, sollten sichere Formate wie Safetensors gegenüber Pickle-basierten Dateien bevorzugt werden.
Vor allem aber dürfen Frameworks Sicherheitsmechanismen nicht stillschweigend abschalten. Sichere Voreinstellungen sind in KI-Pipelines kein Komfortmerkmal, sondern Voraussetzung für belastbare Lieferketten. Die Schwachstellen in NeMo und PyTorch machen deutlich: Der erste Angriffsschritt kann bereits der Modellimport sein.
Den vollständigen Befund von Inga Cherny gibt es hier.
Newsletter Abonnieren
Abonnieren Sie jetzt IT-SICHERHEIT News und erhalten Sie alle 14 Tage aktuelle News, Fachbeiträge, exklusive Einladungen zu kostenlosen Webinaren und hilfreiche Downloads.
