
Forscher warnen vor Schwachstelle in der KI-Lieferkette + Sicherheitsforscher von Palo Alto Networks haben eine neue Angriffsmethode identifiziert, die schwerwiegende Risiken für die KI-Lieferkette birgt. Betroffen sind unter anderem Microsofts Azure AI Foundry, Googles Vertex AI sowie zahlreiche Open-Source-Projekte.
Die Technik, die als „Model Namespace Reuse“ bezeichnet wird, nutzt eine Schwachstelle in der Verwaltung von Modellnamen auf Plattformen wie Hugging Face. Dort dienen Namespaces – also Bezeichner in der Form Autor/Modellname – als eindeutige Identifikatoren. Werden Konten gelöscht oder übertragen, können diese Namen von Dritten erneut registriert werden.
Ein Angreifer kann auf diese Weise ein Konto mit dem Namen des ursprünglichen Entwicklers anlegen und ein bösartiges Modell unter vertrautem Pfad bereitstellen. Da viele Pipelines Modelle ausschließlich anhand ihres Namens abrufen, lassen sich so Schadcode oder manipulierte Modelle einschleusen.
Die Forscher demonstrierten den Angriff praktisch:
-
Auf Vertex AI konnten sie über ein eingebettetes Modell eine Reverse Shell öffnen und Zugriff auf die Endpunktumgebung erlangen.
-
Auf Azure AI Foundry erhielten sie Berechtigungen, die einem Azure-Endpunkt entsprachen – ein möglicher Einstieg in die Infrastruktur eines Nutzers.
Darüber hinaus fanden die Forscher Tausende anfällige Open-Source-Repositorys, darunter bekannte und hoch bewertete Projekte. Diese verweisen weiterhin auf gelöschte oder übertragene Modelle, ohne dass den Entwicklern die Gefahr bewusst ist.
Google, Microsoft und Hugging Face wurden über die Ergebnisse informiert. Google hat inzwischen begonnen, täglich nach verwaisten Modellen zu suchen, um Missbrauch zu verhindern. Das zugrunde liegende Problem bleibt jedoch bestehen: Jede Organisation, die Modelle nur anhand ihres Namens bezieht, ist potenziell gefährdet.
Die Forscher betonen, dass Vertrauen allein in Modellnamen nicht ausreiche. Sie empfehlen, Modelle an konkrete Commits zu binden, Kopien an vertrauenswürdigen Orten zu speichern und Code systematisch auf riskante Modellreferenzen zu überprüfen.
Abbildung 2 zeigt die Schritte, die in diesem fiktiven Szenario durchgeführt werden. Quelle: Palo Alto Networks
Eigentumsübertragung von Modellen auf Hugging Face
Hugging Face ermöglicht es, den Autor eines Modells zu ändern, indem das Eigentum vom bisherigen Besitzer auf eine andere Person oder Organisation übertragen wird. Diese Übertragung erzeugt einen neuen Namespace für das Modell – etwa von AIOrg/Translator_v1 zu AIOrgNew/Translator_v1. Modelle können anschließend über diesen neuen Namespace bereitgestellt werden, während der ursprüngliche Namespace weiterhin zugänglich bleibt.
Sendet ein Benutzer eine Anfrage an den alten Namespace, leitet Hugging Face automatisch zum aktuellen Namespace weiter. Diese Weiterleitung funktioniert für alle Zugriffspunkte, darunter Benutzeroberfläche (UI), REST-APIs und gängige Software Development Kits (SDKs).
Das System ist darauf ausgelegt, dass bestehende Pipelines auch nach einer Namespace-Änderung reibungslos weiterlaufen. Fällt die ursprüngliche Organisation weg, bleibt der Namespace jedoch für eine erneute Registrierung verfügbar. In einem solchen Fall kann ein böswilliger Akteur den Namespace übernehmen, wodurch der Umleitungsmechanismus unterbrochen wird und das kompromittierte Modell Vorrang vor dem legitimen Modell erhält.
Ein Beispiel verdeutlicht das Risiko: Die Organisation Dentalligence übernahm DentalAI und erhielt sämtliche KI-Modelle der übernommenen Organisation. Nach der Übertragung löschten die Administratoren von DentalAI ihre ursprüngliche Organisation bei Hugging Face. Modelle wie DentalAI/toothfAIry waren nun unter Dentalligence/toothfAIry verfügbar. Hugging Face hielt die Weiterleitungen von den alten zu den neuen Namespaces aufrecht, sodass Benutzer ihre Codebasis nicht anpassen mussten.
Ein Angreifer registrierte die gelöschte Organisation DentalAI erneut und lud böswillige Modelle mit denselben Namen hoch. Da die alten Modellnamen während der Übergangsphase weiterhin funktionierten, erhielten Benutzer automatisch die manipulierten Versionen, ohne es zu bemerken.
Vergleich der Szenarien
Viele Open-Source-Projekte verwenden fest codierte Modell-Namespaces, darunter auch bekannte Repositorys großer Organisationen. Diese Praxis erhöht das Risiko, dass Benutzer führender KI-Plattformen ungewollt kompromittierte Modelle einsetzen. Tabelle 1 zeigt die Unterschiede zwischen den beiden Szenarien.
Quelle: Palo Alto Networks
Die Herausforderung der Modellintegrität in der KI
Die Nachverfolgung von Machine-Learning-Modellen bleibt eine komplexe und fortlaufende Aufgabe. Entwickler aktualisieren, optimieren, verzweigen und veröffentlichen ihre Modelle ständig – oft über mehrere Plattformen und Organisationen hinweg. Wiederverwendbare Modell-Namespaces tauchen dabei nicht nur bei der Bereitstellung auf, die das unmittelbarste Risiko darstellt, sondern auch in Modellkarten, Dokumentationen, Standardparametern und Beispiel-Notebooks.
Dieses Problem ist nicht auf einzelne Plattformen beschränkt. Auch in GCP, Azure und zahlreichen Open-Source-Projekten zeigt sich ein kritischer, oft übersehener Sicherheitsaspekt: die Überprüfung, ob das tatsächlich verwendete Modell auch wirklich das ist, für das es gehalten wird. Ob Modelle aus öffentlichen Registern, internen Pipelines oder verwalteten Diensten stammen – stets besteht das Risiko, dass jemand Modelle ersetzt, manipuliert oder Umleitungen ausnutzt.
Modelle können aus unterschiedlichsten Registern stammen, darunter Hugging Face, Vertex AI Model Garden, Azure AI Foundry Model Catalog oder Kaggle. Diese Integration ist praktisch, birgt jedoch Risiken: Entwickler, die sich auf die vertrauenswürdigen Kataloge großer Cloud-KI-Dienste verlassen, könnten unwissentlich bösartige Modelle bereitstellen, ohne direkt mit Hugging Face interagiert zu haben.
Zwar unternehmen alle Plattformen erhebliche Anstrengungen, ihre Modellregister abzusichern, doch kein System ist völlig immun gegen Namespace-Hijacking oder Schwachstellen in der Lieferkette. Selbst kleine übersehene Randfälle können zu erheblichen Schäden führen. Die Verantwortung für die Sicherheit von KI-Tools liegt daher nicht allein bei den Plattformanbietern. Entwickler müssen ebenfalls aktiv ihre Pipelines und Umgebungen absichern.
Praktische Schritte für einen sicheren ML-Lebenszyklus
Von der Datenerfassung bis zur Bereitstellung ist es entscheidend, die Integrität der Modelle in jedem Schritt sicherzustellen. Trotz der Komplexität gibt es konkrete Maßnahmen, die Sicherheit und Zuverlässigkeit von KI-Systemen deutlich erhöhen:
-
Versionsfixierung: Methoden wie
from_pretrained("Author/ModelName")laden standardmäßig die neueste Version, was zu unerwartetem Verhalten oder sogar zur Integration bösartiger Modelle führen kann. Eine Lösung besteht darin, das Modell über den Parameterrevisionan einen bestimmten Commit zu binden:from_pretrained("Author/ModelName", revision="abcdef1234567890"). So bleibt das Modell konsistent und vorhersehbar – hilfreich für Fehlerbehebung und stabile Ausführung. -
Modellklonen und kontrollierte Speicherung: In sensiblen oder produktiven Umgebungen empfiehlt es sich, das Modell-Repository an einen vertrauenswürdigen Ort zu klonen – etwa in lokalen Speicher, interne Registrierungen oder sicheren Cloud-Speicher. Dadurch wird das Laden vom externen Ursprung entkoppelt und Risiken durch Upstream-Änderungen reduziert. Voraussetzung ist ein robuster Scan- und Verifizierungsprozess.
-
Scannen nach wiederverwendbaren Referenzen: Modellreferenzen in Code-Repositorys sollten wie jede andere Abhängigkeit überprüft werden. Das Scannen muss umfassend sein, da Modelle auch in Standardargumenten, Docstrings oder Kommentaren auftauchen können. Durch proaktives Überprüfen der Codebasis lassen sich Risiken von Supply-Chain-Angriffen, die durch wiederverwendete Modell-Namespaces entstehen, minimieren.
Schauen Sie mal hier vorbei
Bild/Quelle: https://depositphotos.com/de/home.html
Fachartikel

Industrielles Phishing gegen Italiens Infrastruktur: Group‑IB entdeckt automatisiertes Aruba‑Imitierendes Phishing‑Kit

Stärkung von Red Teams: Ein modulares Gerüst für Kontrollbewertungen

SAP Patch Day November 2025: Kritische Lücken in SQL Anywhere Monitor und SAP Solution Manager geschlossen

Nordkoreanische APT-Gruppe missbraucht Google Find Hub für Fernlösch-Angriffe auf Android-Geräte

DNS-Ausfallsicherheit entscheidet über die Unternehmenskontinuität
Studien

BSI-Lagebericht 2025: Fortschritte in der Cybersicherheit – Deutschland bleibt verwundbar

Forrester veröffentlicht Technologie- und Sicherheitsprognosen für 2026

Zunahme KI-gestützter Cyberbedrohungen im Fertigungssektor

KnowBe4-Studie: Personalisierte Phishing-E-Mails setzen auf die Verwendung von Firmennamen

Neue Studie: Mehrheit der US-Großunternehmen meldet KI-Risiken
Whitepaper

Vorbereitung auf künftige Cyberbedrohungen: Google veröffentlicht „Cybersecurity Forecast 2026“

Aktuelle Studie zeigt: Jeder Vierte in Deutschland bereits Opfer von digitalem Betrug

Cybersecurity in Deutschland: 200 Milliarden Euro Schaden trotz steigender IT-Ausgaben

Die EU bleibt weiterhin Ziel zahlreicher, sich überschneidender Bedrohungsgruppen

Verizon Business DBIR 2025: So können Gesundheitseinrichtungen Cyberangriffen begegnen
Hamsterrad-Rebell

Identity und Access Management (IAM) im Zeitalter der KI-Agenten: Sichere Integration von KI in Unternehmenssysteme

Infoblox zeigt praxisnahe IT-Security-Strategien auf it-sa 2025 und exklusivem Führungskräfte-Event in Frankfurt

IT-Security Konferenz in Nürnberg: qSkills Security Summit 2025 setzt auf Handeln statt Zögern

Von Palo Alto nach Paderborn: Wie eine Initiative US-Cyberfachkräfte für Deutschland gewinnen will









