MLflow-Lücke ließ fremde Serveranfragen ohne Anmeldung auslösen

Ein Server ließ sich zum Weitertelefonieren bringen

Am 22. Oktober 2026 veröffentlichten die MLflow-Verantwortlichen eine Sicherheitsanzeige zu einer Schwachstelle mit der Kennung CVE-2026-115886. Betroffen war ein MLflow-Server, den die Quellen als Tracking-Server bezeichnen. Er nahm an einer Schnittstelle Anfragen ohne Anmeldung entgegen. Ein fremder Absender konnte sie dadurch veranlassen, selbst eine Internetanfrage an ein frei gewähltes Ziel zu schicken – gewissermaßen ein Rückruf im Namen des Servers. [1] [2]

Das war nicht bloß eine Weiterleitung der ursprünglichen Verbindung. Laut Sicherheitsanzeige ging die neue Anfrage tatsächlich vom MLflow-Server aus. Der Absender konnte Zieladresse, Kopfzeilen und Inhalt festlegen. Damit wäre der Server grundsätzlich auch in der Lage gewesen, Dienste anzusprechen, die nur aus seinem eigenen Netzwerk erreichbar waren. Die Quellen beschreiben diese technische Möglichkeit, berichten aber nicht von einem nachgewiesenen Einbruch, gestohlenen Zugangsschlüsseln oder konkret geschädigten Betreibern. [1] [2] [3]

Wie die Schwachstelle funktionierte

Betroffen war unter anderem eine Funktion, die sogenannte Scorer aufruft. Ein Scorer bewertet beispielsweise die Antwort eines Sprachmodells. Der Server las dafür eine vom Aufrufer gelieferte Datensammlung im JSON-Format, also eine strukturierte Textnachricht. Darin durfte der Aufrufer eine Softwareklasse und zusätzliche Einstellungen nennen. MLflow prüfte zwar, aus welchem zugelassenen Programmbereich die Klasse stammte, begrenzte aber weder das konkrete ausgewählte Element noch sämtliche weitergereichten Einstellungen ausreichend. [1] [2]

Bei einer bestimmten Kombination optionaler Zusatzpakete gelangten diese Einstellungen bis zu einer Komponente, die Anfragen an Sprachmodell-Dienste verschickt. Der Absender konnte dort unter anderem die Zieladresse und einen vermeintlichen Zugangsschlüssel einsetzen. So ließ sich eine Anfrage an einen beliebigen Rechner lenken. In der Sicherheitsbranche heißt das serverseitige Anfragenfälschung: Der angegriffene Server besucht ein Ziel, das der externe Absender selbst womöglich nicht erreichen könnte. Technisch eindrucksvoll, aber noch keine rebellische Maschine. [1] [2] [3]

Nicht jede Installation war verwundbar

Der beschriebene Weg setzte voraus, dass neben MLflow die optionalen Pakete „trulens“ und „trulens-providers-litellm“ installiert waren. Sie gehören laut Sicherheitsanzeige zu einer dokumentierten, aber nicht standardmäßig mitgelieferten Einrichtung für Bewertungen generativer KI. Außerdem musste die fragliche Serverfunktion für nicht vertrauenswürdige Personen erreichbar sein. Eine normale MLflow-Installation ohne diese Zusätze erfüllte die entscheidende technische Voraussetzung daher nicht automatisch. Die Lücke war ernst, aber ihr Türrahmen hatte konkrete Maße. [1] [2]

Der ergänzende Fachbericht nennt Versionen ab 3.12.0rc0 bis vor der korrigierten Ausgabe 3.17.0 als betroffen. Die Reparatur erschien mit MLflow 3.17.0 und weist jene Einstellungen zurück, mit denen ein Aufrufer das Ziel ausgehender Verbindungen steuern konnte. Falls ein sofortiges Update nicht möglich war, beseitigte nach der dargestellten Analyse auch das Entfernen der beiden optionalen Pakete den beschriebenen Angriffspfad. Die GitLab-Datenbank veröffentlichte ihren Eintrag am 23. Oktober 2026. [2] [3]

Was ein Angreifer damit erreichen konnte

Eine erfolgreiche Ausnutzung hätte den Netzwerkstandort des Servers missbraucht. Denkbare Ziele waren nach der offiziellen Anzeige interne Dienste oder Metadaten-Schnittstellen eines Cloud-Anbieters. Der Angreifer konnte außerdem eigene Kopfzeilen und einen eigenen Inhalt mitsenden. Das schafft Möglichkeiten, Daten abzufragen oder Befehle an erreichbare Dienste zu übermitteln, sofern diese darauf reagieren. Welche Folgen tatsächlich eintreten, hängt deshalb stark von Netzwerk, Zugriffsrechten und den angesprochenen Diensten der jeweiligen Installation ab. [1] [2]

Wichtig ist die Trennung zwischen Möglichkeit und beobachtetem Vorfall. Die Quellen belegen, dass sich eine vom Server ausgehende Anfrage technisch erzwingen ließ. Sie dokumentieren jedoch keine Angriffskampagne, keine betroffene Organisation und keinen nachgewiesenen Datenabfluss. Auch die mitgesendete Autorisierungsangabe stammte in der beschriebenen Vorführung vom Angreifer selbst; sie war nicht automatisch ein zuvor auf dem Server gefundener geheimer Schlüssel. Ein mögliches Werkzeug ist noch kein protokollierter Tatort. [1] [2] [3]

Warum das kein autonomer KI-Angriff war

Die Lücke lag in Software, die häufig rund um generative KI eingesetzt wird. Das macht sie für KI-Infrastrukturen relevant, verwandelt den Ablauf aber nicht in eine selbstständige Handlung eines KI-Agenten. Ein KI-Agent ist ein System, das Ziele verfolgt und dazu mehrere Arbeitsschritte selbst auswählt. Hier beschreiben die Quellen stattdessen eine präparierte Nachricht von außen, gewöhnliche Programmlogik und eine daraus folgende Netzwerkanfrage. Ob KI beim Erstellen eines möglichen Angriffs geholfen hätte, ist weder belegt noch ausgeschlossen. [1] [2] [3]

Auch der Server „entschied“ nicht eigenständig, ein internes Ziel zu untersuchen. Er verarbeitete Werte, die ein Absender vorgegeben hatte. Das kann reale Sicherheitsfolgen haben, ist aber für unsere Bewertung ein menschlich oder organisatorisch angestoßener Angriffspfad. Reale Auswirkungen eines solchen Angriffs wären daher nicht automatisch Realweltwirkung eines KI-Systems. Ausgerechnet unser weitgehend von KI produziertes Magazin muss an dieser Stelle die Maschine entlasten: Die klassische Eingabeprüfung hatte schon genug zu erklären. [1] [2]

Terminator-Check

Für Autonomie, Grenzüberschreitung und Täuschung lautet die Bewertung jeweils „nicht belegt“. Kein KI-Agent entwickelte einen Plan oder führte nachweislich eigene Handlungsschritte aus. Zwar konnte der Server auf Anweisung eine Netzwerkgrenze überschreiten, doch diese Richtung und die übertragenen Angaben kamen aus den manipulierten Eingabedaten. Ebenso ist keine gezielte Irreführung durch ein KI-System dokumentiert. Der technische Angriff konnte einen Server instrumentalisieren; die Quellen zeigen aber keinen handelnden künstlichen Akteur mit eigenen Entscheidungen. [1] [2] [3]

Auch Selbsterhaltung und Realweltwirkung eines KI-Systems sind „nicht belegt“. Nichts deutet darauf hin, dass eine KI Kontrolle oder Abschaltung verhindern wollte. Die erzwungene Serveranfrage fand im technischen Nachweis real statt, doch ein autonomer Agent war daran nicht beobachtet beteiligt; ein Missbrauch bei einem Betreiber ist ebenfalls nicht dokumentiert. Deshalb beträgt der Terminator-Score 0 von 5. Das bedeutet nicht, dass die Sicherheitslücke ungefährlich war, sondern ausschließlich: kein belegtes autonomes Fehlverhalten einer KI. [1] [2] [3]