Versatile AI Risk Assessment

KI-Bedrohungskatalog Anwendungs- und Integrationssicherheit Produktion

Middleware-Exploits (Angriffe auf AI-Frameworks)

KI-Anwendungen bauen auf Frameworks, Bibliotheken und Middleware auf, der Vermittlungssoftware zwischen Modell und Anwendung. Schwachstellen oder manipulierte Pakete in diesen Bausteinen öffnen Angreifern die Tür, ohne dass das Modell selbst angegriffen wird.

Stand: Oktober 2026 · Katalogversion 2026.10.24.2 · 7 Gegenmaßnahmen · 10 belegte Quellen

Beschreibung

Zwischen Modell und fertiger Anwendung liegt eine Software-Schicht aus KI-Frameworks (etwa LangChain oder LlamaIndex), Treibern für Vektordatenbanken und Inferenz-Servern. Diese Bausteine bringen lange Ketten eigener Abhängigkeiten mit, oft hunderte Pakete aus offenen Quellen. Angreifer nutzen bekannte Schwachstellen in solchen Komponenten aus oder schleusen manipulierte Pakete in die Lieferkette ein, etwa über Namensverwechslung bei der Installation (Dependency Confusion) oder über zunächst harmlose Pakete, die später ein bösartiges Update erhalten. Die Wirkung pflanzt sich über die Abhängigkeitskette fort: Eine einzige verwundbare Bibliothek genügt, denn sie läuft mit weitreichenden Rechten im Kern der Anwendung.

Mögliche Auswirkung

Angreifer setzen sich im Inneren der Anwendung fest: Sie lesen Zugangsdaten, Schlüssel und die Daten mit, die zwischen Modell und Anwendung fließen, manipulieren Antworten oder führen eigenen Code aus. Weil dieselben Frameworks branchenweit eingesetzt werden, trifft eine einzige Schwachstelle viele Unternehmen gleichzeitig; ohne Übersicht über die eigenen Abhängigkeiten (SBOM, eine Stückliste der eingesetzten Software) bleibt unklar, ob man betroffen ist.

Beispiel

Ein Entwicklerteam installiert die aktuelle Version eines verbreiteten KI-Frameworks. Über die Paketverwaltung gelangt unbemerkt eine gefälschte Zusatzbibliothek gleichen Namens auf die Systeme; sie sendet Zugangsdaten und SSH-Schlüssel an einen fremden Server.

Empfohlene Gegenmaßnahmen (7)

Vergleichen Sie Wirkung und Umsetzungsebene. Die ergänzende Einordnung und Begründung können Sie bei Bedarf aufklappen.

  • Scannen von Dependencies auf Schwachstellen

    Technisch
    Wirkung
    Aufdeckend
    Umsetzungsebene
    Anwendung, API & Agenten, Lieferkette, Nutzung & Betrieb
    Einordnung und Begründung

    Primär technisch: Software oder Analysewerkzeuge erzeugen und bewerten systematisch Messwerte, Abweichungen oder Angriffsindikatoren.

  • Gepinnte Dependency-Versionen

    Technisch
    Wirkung
    Präventiv
    Umsetzungsebene
    Anwendung, API & Agenten, Lieferkette
    Einordnung und Begründung

    Primär technisch: Sichere Formate, restriktive Voreinstellungen oder Schutzschichten reduzieren unsichere Ausführungspfade und Angriffsflächen.

  • Pflege einer SBOM (Software Bill of Materials)

    Organisatorisch & prozessual
    Wirkung
    Aufdeckend
    Umsetzungsebene
    Organisation, Lieferkette, Nutzung & Betrieb
    Einordnung und Begründung

    Ergänzende MaßnahmenartTechnisch

    Primär organisatorisch & prozessual: Festgelegte Auswahl-, Betriebs- oder Lebenszyklusabläufe machen die Maßnahme verbindlich und wiederholbar; ergänzt durch technische Umsetzung.

  • Richtlinien für Framework-Updates

    Governance & Compliance
    Wirkung
    Präventiv
    Umsetzungsebene
    Organisation, Lieferkette, Nutzung & Betrieb
    Einordnung und Begründung

    Ergänzende MaßnahmenartOrganisatorisch & prozessual

    Primär der Maßnahmenart Governance & Compliance zugeordnet: Verbindliche Regeln, Kontrollziele oder Aufsicht bestimmen Zulässigkeit und Rechenschaft; ergänzt durch verbindliche Abläufe.

  • Security-Monitoring der Middleware-Komponenten

    Technisch
    Wirkung
    Aufdeckend
    Umsetzungsebene
    Anwendung, API & Agenten, Lieferkette, Nutzung & Betrieb
    Einordnung und Begründung

    Ergänzende MaßnahmenartOrganisatorisch & prozessual

    Primär technisch: Software oder Analysewerkzeuge erzeugen und bewerten systematisch Messwerte, Abweichungen oder Angriffsindikatoren; ergänzt durch verbindliche Abläufe.

  • Isolation zwischen Middleware und Anwendung

    Technisch
    Wirkung
    Präventiv, Schadensbegrenzend
    Umsetzungsebene
    Anwendung, API & Agenten, Infrastruktur
    Einordnung und Begründung

    Primär technisch: Architektur- und Laufzeitgrenzen trennen Daten, Ausführung oder Mandanten und begrenzen die Fehlerausbreitung.

  • Regelmäßiger Pentest des integrierten Stacks

    Organisatorisch & prozessual
    Wirkung
    Aufdeckend
    Umsetzungsebene
    Anwendung, API & Agenten, Infrastruktur, Nutzung & Betrieb
    Einordnung und Begründung

    Ergänzende MaßnahmenartMensch & Kompetenz, Technisch

    Primär organisatorisch & prozessual: Ein geplanter, wiederholbarer Prüfablauf mit Zuständigkeit und Nachverfolgung erzeugt die Schutzwirkung; ergänzt durch Fachwissen und Urteil sowie technische Umsetzung.

Standard-Zuordnungen

Verifizierte Fundstellen in OWASP, NIST AI RMF, MITRE ATLAS, EU AI Act und weiteren Rahmenwerken. Die Zuordnungen zeigen fachliche Bezüge. Sie belegen nicht, dass ein System die jeweiligen Anforderungen erfüllt.

OWASP LLM Top 10 LLM04:2026NIST AI RMF Abschnitt 2.12 · MAP 4.1 · NISTAML.05MITRE ATLAS AML.T0010 · AML.T0049 · AML.T0109EU AI Act Article 25(4) · Article 55(1)(d) · Article 9(1), 9(2)(a), 9(2)(d)

Belegte Referenzen (10)

Jede Referenz nennt Rahmenwerk, Fundstelle und die herausgebende Organisation.

Pflichten der KI-Verordnung zu dieser Bedrohung

Die Pflichten aus dem Pflichtenkompass, deren Artikel der Katalog dieser Bedrohung zuordnet. Jede führt auf ihren Eintrag mit Kern, Handlungsschritt und Nachweis; ob sie Sie trifft, hängt von Rolle und Risikoklasse ab.

  • Risikomanagementsystem einrichten und betreiben Art. 9 · gilt ab Anhang III: 2. Dezember 2027 · Anhang I: 2. August 2028

    Gesetzliche Rollen: Anbieter, Produkthersteller. Klassen: Hochrisiko nach Anhang III, Hochrisiko als Produkt oder Sicherheitsbauteil.

    Der Verweis ist ein Prüfanlass. Ein Bedrohungstreffer allein begründet keine Anwendbarkeit.

  • Nachgelagerte Anbieter unterstützen Art. 25 Abs. 2, Art. 25 Abs. 4 · gilt ab Anhang III: 2. Dezember 2027 · Anhang I: 2. August 2028 · geändert durch VO 2026/1744

    Gesetzliche Rollen: Anbieter, Anbieter eines KI-Modells mit allgemeinem Verwendungszweck. Klassen: Hochrisiko nach Anhang III, Hochrisiko als Produkt oder Sicherheitsbauteil.

    Die Verordnung (EU) 2026/1744 hat die Kooperationspflicht des Erstanbieters konkretisiert und zugleich eine Ausnahme geschaffen: Sie entfällt, wenn der Erstanbieter eindeutig festgelegt hat, dass sein System nicht in ein Hochrisiko-System umgewandelt werden darf. Verstöße gegen Art. 25 Abs. 2 und 4 sind seither ausdrücklich bußgeldbewehrt.

    Der Verweis ist ein Prüfanlass. Ein Bedrohungstreffer allein begründet keine Anwendbarkeit.

  • Systemische Risiken bewerten und mindern Art. 55 · gilt ab 2. August 2025

    Gesetzliche Rollen: Anbieter eines KI-Modells mit allgemeinem Verwendungszweck. Klassen: Modell mit systemischem Risiko.

    Der Verweis ist ein Prüfanlass. Ein Bedrohungstreffer allein begründet keine Anwendbarkeit.

Alle 62 Pflichten nach Rolle, Risikoklasse und Frist im Pflichtenkompass

Weitere Einträge aus der Themengruppe Anwendungs- und Integrationssicherheit.

Unsicherer Umgang mit Modellausgaben Die Anwendung reicht Antworten des KI-Modells ungeprüft an nachgelagerte Systeme weiter, etwa an Datenbanken, Webseiten oder Befehlszeilen. Unsicheres Tool-Design Viele KI-Anwendungen handeln selbst, indem sie über angebundene Werkzeuge (Tools) E-Mails versenden oder Datenbanken abfragen. Anwendungs-Schwachstellen Die Software rund um das KI-Modell, also Weboberfläche, Schnittstellen und Datenbanken, hat dieselben Schwachstellen wie jede andere …

Passende Anwendungsfälle

Die Liste zeigt, wo Sie diese Bedrohung prüfen, nicht wie hoch das Risiko ist.

Gehört bei jedem KI-System auf die Prüfliste. Was Sie bei jedem KI-System prüfen

Häufige Fragen

Worum geht es bei dieser Bedrohung?
KI-Anwendungen bauen auf Frameworks, Bibliotheken und Middleware auf, der Vermittlungssoftware zwischen Modell und Anwendung. Schwachstellen oder manipulierte Pakete in diesen Bausteinen öffnen Angreifern die Tür, ohne dass das Modell selbst angegriffen wird.
Welche Gegenmaßnahmen nennt der Katalog?
Der Katalog nennt 7 Gegenmaßnahmen, jede mit Maßnahmenart, Wirkung und Umsetzungsebene. Beispiele sind: Scannen von Dependencies auf Schwachstellen, Gepinnte Dependency-Versionen und Pflege einer SBOM (Software Bill of Materials). Die Reihenfolge ist keine Priorisierung.
Welche Pflichten der KI-Verordnung können relevant sein?
Der Katalog ordnet diese Bedrohung Art. 9, Art. 25 Abs. 2 und Art. 55 der EU-KI-Verordnung zu. Daraus folgen im Pflichtenkompass: Risikomanagementsystem einrichten und betreiben, Nachgelagerte Anbieter unterstützen und Systemische Risiken bewerten und mindern. Ob eine Pflicht gilt, entscheiden Rolle, Risikoklasse und Frist.

Diese Bedrohung im eigenen System bewerten

Die Live-Demo enthält alle 52 Bedrohungen dieses Katalogs sowie die Einordnung nach der EU-KI-Verordnung und die Datenschutzprüfung. Die kostenlosen Einzelmodule decken KI-Risiko, EU-KI-VO und DSGVO ab. Ohne Registrierung; die Bewertung läuft lokal in Ihrem Browser.

Live-Demo starten Kostenlose Module ansehen

Diesen Eintrag zitieren

Für Berichte, Richtlinien oder interne Unterlagen; der Link führt direkt auf diesen Eintrag.

„Middleware-Exploits (Angriffe auf AI-Frameworks)“. Versatile AI Risk Assessment, KI-Bedrohungskatalog, Stand Oktober 2026.
https://www.versatile-ai-risk-assessment.com/wissensbasis/bedrohungen/middleware-exploits/

← Zurück zum vollständigen Katalog