MLflow, een open-source platform voor het bouwen en uitrollen van machine learning, staat onder druk. De reden: een kwetsbaarheid die al in het wild wordt misbruikt om cloud credentials en andere gevoelige gegevens te stelen. Voor teams die AI-oplossingen in productie brengen, is dit een directe reminder dat AI modelbeveiliging met sandboxing niet alleen gaat over modellen en data, maar ook over de infrastructuur eromheen.
De security issue is geregistreerd als CVE-2026-64849 met een CVSS-score van 9.3. Aanvallers gebruiken de fout om HTTP-verzoeken te sturen naar interne endpoints. Vervolgens weten ze via cloud metadata services toegang tot secrets te krijgen.
Wat is er mis bij MLflow (CVE-2026-64849)?
Volgens de MLflow-advisory gaat het om een unauthenticated server-side request forgery (SSRF)-probleem. SSRF betekent dat een aanvaller vanaf de serverkant verzoeken kan laten doen naar adressen die anders niet toegankelijk zouden zijn. In dit geval gaat het om de manier waarop de MLflow Tracking Server (de component die data en events verwerkt) bepaalde webhooks aan het netwerk blootstelt.
De kern van het probleem: de default MLflow Tracking Server exposeert de model-registry webhooks API zonder authenticatie. Eén van de betrokken endpoints kan de statuscode en het response-body van de upstream service teruggeven aan de aanvrager. Daardoor kan de aanvaller feedback krijgen en gerichter misbruik maken.
Daarnaast vermeldt de advisory dat er wel een SSRF-bescherming is toegevoegd in versie 3.10.0, maar dat die in deze aanvalssituatie te omzeilen blijkt. Dat maakt het gevaar extra lastig: je kunt dus niet blind varen op “er is ooit een fix geweest”.
Hoe leidt dit tot credential theft?
WatchTowr, een partij op het gebied van attack surface management, waarschuwt dat aanvallers de kwetsbaarheid gebruiken om cloud metadata services direct te benaderen. Dat zijn interne services in veel cloudomgevingen die informatie geven over de instantie en vaak ook over toegangsinformatie.
Met SSRF kunnen aanvallers die metadata services bereiken vanuit de positie van de MLflow-server zelf. Vervolgens kan de aanvaller die informatie exfiltreren, met als gevolg dat cloud credentials en secrets worden buitgemaakt.
Volgens WatchTowr begon misbruik binnen enkele uren na de toewijzing van de CVE. Daarbij richtten aanvallers zich op cloud-hosted MLflow-instanties.
Welke MLflow-versies zijn kwetsbaar?
De publicatie waarover wordt gerapporteerd is duidelijk over de impact. Alle MLflow-versies vóór 3.15.0 zijn volgens de berichtgeving getroffen. Ook stelt WatchTowr dat het verstandig is om niet alleen te kijken naar de versie die je denkt te gebruiken, maar om expliciet te verifiëren welke MLflow Tracking Server echt bereikbaar is vanaf het netwerk.
Waarom dit zo snel opvalt in de praktijk
Veel organisaties zien een kwetsbaarheid pas wanneer er exploitcode rondgaat of wanneer monitors iets herkennen. In dit geval start de echte aanvalsketen echter snel. Dat komt doordat SSRF-type issues vaak relatief direct toepasbaar zijn: als een endpoint zonder authenticatie verzoeken doorlaat naar interne bestemmingen, hoeft de aanvaller meestal geen ingewikkelde first-stage exploit te bouwen.
Daar komt bij dat MLflow een brug is tussen ontwikkel- en productiesystemen. Teams gebruiken het om het machine learning lifecycle te beheren en om agents, LLM’s en modellen in productie te brengen. Als de service dan ook nog intern of halfopen staat, kan de impact snel groter worden dan “alleen” datalekken.
Wat zeggen CISA en andere instanties?
De Amerikaanse cybersecurity-agency CISA heeft CVE-2026-64849 toegevoegd aan de Known Exploited Vulnerabilities (KEV)-catalogus. Daarmee vraagt CISA dat federale instanties de kwetsbaarheid binnen twee weken patchen, conform de aanpak die is vastgelegd in BOD 26-04.
Praktisch betekent dit: als je MLflow draait in omgevingen waar compliance of interne governance een rol speelt, is “later patchen” geen optie meer. Neem de kwetsbaarheid op als prioriteit hoog.
Concrete maatregelen voor organisaties
Als je MLflow inzet, is het verstandig om snel en systematisch te handelen. WatchTowr adviseert om eerst te patchen, daarna audit logs te controleren en te beoordelen of credentials en secrets mogelijk zijn blootgesteld.
- Patch direct naar een versie vanaf 3.15.0 (of hoger) en controleer welke MLflow Tracking Server endpoint(s) daadwerkelijk online staan.
- Onderzoek audit- en access logs op signalen van ongeautoriseerd verkeer richting de model-registry webhooks API en op afwijkende verzoekpatronen.
- Beoordeel credential exposure: als een aanvaller cloud metadata kan benaderen, overweeg dan een reset/rotatie van getroffen tokens en secrets.
- Beperk netwerkblootstelling: stel services alleen beschikbaar waar ze echt nodig zijn, bij voorkeur via gecontroleerde toegang.
In de context van AI modelbeveiliging met sandboxing is dit ook een brug naar bredere discipline: zorg dat MLflow en andere AI-platformonderdelen niet dezelfde privileges hebben als de rest van je cloudomgeving. Sandboxing en harde scheiding verkleinen de schade wanneer een server toch wordt misbruikt.
Vergelijkbare risico’s: wanneer AI-infrastructuur een aanvalsvlak wordt
Dit incident past in een patroon waarbij aanvallers niet direct het “model” aanvallen, maar de tooling eromheen. Eerder zagen we vergelijkbare urgentie rondom server-side fouten en misbruikte componenten. Zo zijn er bijvoorbeeld updates geweest rond andere enterprise- en cloudgerelateerde beveiligingslekken die eveneens snel werden benut.
Wil je aanvullende context rondom patching en exploitatie in de praktijk, lees dan ook:
Door deze verbanden te zien, wordt duidelijk waarom AI modelbeveiliging met sandboxing breder moet worden ingevuld: niet alleen de runtime van het model, maar ook de service-laag die het mogelijk maakt om modellen en agents te beheren.
Checklist: snelle aanpak binnen 24 tot 48 uur
Als je vanavond al actie wilt ondernemen, helpt deze pragmatische volgorde:
- Inventariseer alle MLflow Tracking Servers en controleer welke versies draaien.
- Check blootstelling: welke hosts/URLs zijn bereikbaar vanaf buiten het managementnetwerk?
- Patch en herstart: upgrade naar een veilige versie (vanaf 3.15.0) en verifieer daarna dat de endpoint(s) niet langer kwetsbaar zijn.
- Logonderzoek: zoek naar verzoeken die lijken op interne HTTP-aanroepen en ongebruikelijke responscycli.
- Rotatie waar nodig: als er redelijke aanwijzingen zijn van SSRF-toegang tot metadata, roteer cloud credentials en secrets.
Met deze aanpak verklein je de kans dat een aanvaller via SSRF alsnog intern door kan dringen en gegevens kan wegsluizen.
Conclusie
De misbruikte MLflow-kwetsbaarheid CVE-2026-64849 laat zien hoe kwetsbaar AI-infrastructuur kan zijn wanneer webhooks of servercomponenten zonder authenticatie worden blootgesteld. Door SSRF te gebruiken, kunnen aanvallers cloud metadata services bereiken en zo cloud credentials en secrets exfiltreren.
De boodschap is helder: upgrade naar MLflow 3.15.0 of hoger, controleer logs en beoordeel mogelijke credential exposure. En leg daarbij de nadruk op AI modelbeveiliging met sandboxing: beperk privileges, isoleer wat je kunt isoleren en voorkom dat één misbruikte component direct toegang geeft tot je cloudomgeving.
Bron: https://www.securityweek.com/mlflow-vulnerability-exploited-for-cloud-credential-theft/
