Ein Ingenieur richtet ein Dashboard ein, nur für das Team

Ein Ingenieur bei einem mittelständischen Unternehmen richtet einen MLflow-Tracking-Server auf einer internen VM ein, damit das Data-Science-Team Experimente protokollieren und Modellläufe vergleichen kann. MLflow fragt bei der Einrichtung nicht nach einem Benutzernamen oder Passwort, also wird keines konfiguriert, und der Server geht hinter dem live, was alle für ein privates Netzwerk halten. In einer Fabrik einige hundert Kilometer entfernt tut ein Betriebsingenieur etwas Ähnliches: Er richtet FUXA ein, eine quelloffene SCADA- und HMI-Plattform, um dem Team eine browserbasierte Ansicht der Produktionslinien-Tags zu geben. Keines der beiden Systeme wurde dafür gebaut, aus dem offenen Internet erreichbar zu sein, und kein Team hat es überprüft.

In der Woche vom 18. August 2026 erwiesen sich beide Annahmen gleichzeitig als falsch. MLflow, eine Plattform zur Nachverfolgung von Experimenten unter dem Dach von LF Projects bei der Linux Foundation, und FUXA, ein davon unabhängiges Werkzeug für industrielle Steuerungssysteme, veröffentlichten je eine kritische, standardmäßig unauthentifizierte Schwachstelle - und in beiden Fällen hatten Angreifer funktionierende Exploits innerhalb von Stunden nach der öffentlichen Bekanntgabe, nicht Wochen. Zwei verschiedene Codebasen, zwei verschiedene Branchen, zwei Teams, die sich nie abgestimmt haben. Gemeinsam ist ihnen eine einzige Designentscheidung, unabhängig voneinander und Jahre auseinander getroffen, aus demselben Grund: Es geht schneller, ein Tool mit deaktivierter statt aktivierter Authentifizierung auszuliefern.

MLflows Lücke macht aus einem Redirect einen Zugangsdaten-Diebstahl

Die MLflow-Schwachstelle, verzeichnet als CVE-2026-64849, trägt einen CVSS-Wert von 9,3. Es handelt sich um eine Umgehung der Webhook-URL-Validierung: MLflow erlaubt es, Webhooks zu registrieren, die bei Ereignissen wie einem abgeschlossenen Trainingslauf auslösen, und prüft die Zieladresse vorab, um zu verhindern, dass der Server auf interne Adressen zeigt. Angreifer fanden heraus, dass sie diese Prüfung umgehen können, indem sie einen HTTP-Redirect mit DNS-Rebinding kombinieren - sie registrieren einen Webhook auf eine Adresse, die die Validierung besteht, und lassen sie zum Zeitpunkt der Anfrage auf eine interne IP auflösen, die der Validator nie gesehen hat. GitLab veröffentlichte einen Sicherheitshinweis zu der Lücke, und der Exploit wurde unabhängig von Cybersecurity-Portalen wie cybersecuritynews, cyberpress und GBHackers bestätigt.

Der Gewinn für einen Angreifer ist Server-Side-Request-Forgery: Der MLflow-Server selbst wird zu demjenigen, der die Anfrage stellt, aus dem Inneren des Netzwerks, in dem er sich befindet. Das erlaubt einem Angreifer, interne Dienste zu erreichen, die nie nach außen gerichtet sein sollten, und vor allem Cloud-Instanzmetadaten-Endpunkte bei AWS, Azure und GCP - die internen Adressen, die temporäre Zugangsdaten an die anfragende Maschine ausgeben. Da MLflow-Tracking-Server in realen Umgebungen häufig ohne Authentifizierung laufen, hindert nichts einen externen Angreifer daran, diese erste Anfrage zu stellen. The Hacker News berichtete am 18. August 2026, dass aktive Ausnutzung innerhalb von Stunden nach der Bekanntgabe begann.

FUXAs Lücke lässt Außenstehende Dateien auf Anlagensystemen schreiben

FUXA ist eine quelloffene SCADA- und HMI-Plattform - die Art von Software, die Anlagenbetreibern ein Browserfenster auf die Geräte gibt, die eine Produktionslinie tatsächlich steuern. Ihre Schwachstelle, CVE-2026-25895, erreicht mit 9,5 sogar einen höheren Wert als die von MLflow, und der Mechanismus ist unverblümter: fehlende Authentifizierung kombiniert mit einer Path-Traversal-Lücke. Ein nicht authentifizierter Angreifer kann eine Anfrage senden, die aus dem Verzeichnis entkommt, in das FUXA schreiben soll, und eine Datei an einer beliebigen Stelle im zugrunde liegenden Dateisystem ablegen.

Beliebiges Schreiben von Dateien ist kein reiner Datenleck-Fehler, es ist ein Einstiegspunkt. Ein Angreifer, der Dateien nach Belieben auf einem System schreiben kann, das mit industriellen Anlagen kommuniziert, kann ausführbaren Code platzieren und Remotecodeausführung erreichen, was volle Kontrolle über den Host bedeutet, auf dem die HMI läuft - und, je nachdem, wie dieser Host mit der Fertigungsebene verbunden ist, einen Weg zu den Steuerungssystemen selbst. Wie bei MLflow berichteten The Hacker News und dieselben bestätigenden Portale, dass die aktive Ausnutzung innerhalb von Stunden nach der öffentlichen Bekanntgabe begann, in derselben Woche wie der MLflow-Hinweis.

Der gemeinsame Nenner ist nicht der Code, sondern die Voreinstellung

MLflow und FUXA teilen sich keinen Code, keine Maintainer und keinen Markt. Das eine verfolgt Machine-Learning-Experimente, das andere visualisiert industrielle Steuerungssysteme, und sie wurden rein zufällig in derselben Woche unabhängig voneinander veröffentlicht. Was sie teilen, ist eine Voreinstellung: ohne Authentifizierung ausliefern, weil das der schnellste Weg ist, ein Tool für ein kleines internes Team zum Laufen zu bringen, und weil das Team annimmt, das umgebende Netzwerk sei privat. Diese Annahme ist die gesamte Angriffsfläche.

Dieselbe Voreinstellung steckt hinter einem großen Teil interner Werkzeuge, die Unternehmensinhaber nie persönlich prüfen: MLOps-Dashboards, Monitoring-Stacks, interne Admin-Panels und SCADA/HMI-Systeme in der Fertigung. Jedes davon wurde vermutlich schnell von jemandem Kompetentem aufgesetzt, der ein reales Problem löste und nie zurückkam, um die Authentifizierung einzuschalten, weil ihn nichts dazu zwang. Die Lücke zwischen angenommen-privat und tatsächlich-erreichbar - ob durch direkte Internetexposition oder, wie bei MLflow, durch einen SSRF-Umweg über ein erreichbares System - ist genau dort, wo beide Exploits landeten, und dort wird auch der nächste landen.

Stunden bis zur Ausnutzung sind jetzt das reale Patch-Fenster

Für jedes Unternehmen in der EU oder im Vereinigten Königreich, das MLOps-Pipelines betreibt - zunehmend üblich, da Unternehmen eigene ML- und KI-Infrastruktur einsetzen - oder für jedes Industrie- oder Fertigungsunternehmen mit SCADA- oder HMI-Systemen ist die praktische Antwort ein Audit, kein Grundsatzpapier. Jedes interne Tool braucht eine direkte Antwort auf eine Frage: Ist Authentifizierung tatsächlich aktiviert, nicht nur angenommen, und ist das Tool tatsächlich von außerhalb des Netzwerks, in dem es leben soll, unerreichbar. MLflow und FUXA zeigen beide, dass die ehrliche Antwort oft Nein lautet, und dass es niemand bemerkt, bis es ausgenutzt wird.

Die andere Anpassung betrifft die Uhr. Beide Lücken wurden innerhalb von Stunden nach der öffentlichen Bekanntgabe aktiv ausgenutzt, nicht in den Wochen, von denen Patch-Zyklen traditionell ausgingen. Für Betreiber in der EU speziell ist das nicht nur ein technisches Problem: Die NIS2-Pflichten gelten für Anbieter digitaler Infrastruktur und, bemerkenswerterweise, für Fertigungs- und Industriebetreiber mit OT- und SCADA-Systemen, was eine ungepatchte, unauthentifizierte HMI zu einem Compliance-Versagen ebenso wie zu einem Sicherheitsproblem macht. Die Lösung ist nicht exotisch - Authentifizierung einschalten, am Tag der Bekanntgabe patchen, davon ausgehen, dass hinter der Firewall nichts wirklich privat ist - aber sie muss geschehen, bevor der Exploit es tut, und diese Woche wurde diese Lücke in Stunden gemessen.

Weiterlesen: Ein Leck, das Ihr DORA-Register nicht erklärt  |  Shell und Philips verloren Baupläne, keine Passwörter