Een Engineer Zet een Dashboard Op, Alleen Voor het Team
Een engineer bij een middelgroot bedrijf zet een MLflow-trackingserver op een interne VM op zodat het data-science-team experimenten kan loggen en modeluitkomsten kan vergelijken. MLflow vraagt tijdens de installatie niet om een gebruikersnaam of wachtwoord, dus wordt er niets geconfigureerd, en de server gaat live achter wat iedereen aanneemt een privénetwerk te zijn. In een fabriek een paar honderd kilometer verderop doet een operations-engineer iets vergelijkbaars: die zet FUXA op, een open-source SCADA- en HMI-platform, om het team een browsergebaseerd overzicht van de productielijn-tags te geven. Geen van beide systemen is gebouwd om bereikbaar te zijn vanaf het open internet, en geen enkel team heeft dat gecontroleerd.
In de week van 18 augustus 2026 bleken beide aannames tegelijk onjuist. MLflow, een platform voor het bijhouden van experimenten dat wordt gehost onder LF Projects bij de Linux Foundation, en FUXA, een volledig los daarvan staande tool voor industriële besturingssystemen, maakten elk een kritiek, standaard niet-geauthenticeerd lek bekend - en in beide gevallen hadden aanvallers binnen enkele uren na de openbare bekendmaking werkende exploits, geen weken. Twee verschillende codebases, twee verschillende sectoren, twee teams die nooit met elkaar hebben afgestemd. Wat ze gemeen hebben is een enkele ontwerpkeuze, onafhankelijk van elkaar en jaren na elkaar gemaakt, om dezelfde reden: het is sneller om een tool uit te brengen met authenticatie uit dan aan.
MLflows Lek Maakt van een Redirect een Diefstal van Cloudgegevens
De MLflow-kwetsbaarheid, geregistreerd als CVE-2026-64849, heeft een CVSS-score van 9,3. Het is een omzeiling van de webhook-URL-validatie: MLflow laat gebruikers webhooks registreren die afgaan bij gebeurtenissen zoals een voltooide trainingsrun, en controleert het doeladres vooraf om te voorkomen dat de server naar interne adressen wijst. Aanvallers ontdekten dat ze die controle konden omzeilen door een HTTP-redirect te combineren met DNS-rebinding - ze registreren een webhook naar een adres dat de validatie doorstaat, en laten dat op het moment van het verzoek resolven naar een intern IP-adres dat de validator nooit heeft gezien. GitLab publiceerde een beveiligingsadvies over het lek, en de exploit werd onafhankelijk bevestigd door cybersecuritymedia zoals cybersecuritynews, cyberpress en GBHackers.
De winst voor een aanvaller is server-side request forgery: de MLflow-server zelf wordt degene die het verzoek doet, van binnenuit het netwerk waarin hij zich bevindt. Dat stelt een aanvaller in staat interne diensten te bereiken die nooit naar buiten hadden mogen kijken, en cruciaal, cloud-instantiemetadata-endpoints bij AWS, Azure en GCP - de interne adressen die tijdelijke inloggegevens afgeven aan de machine die erom vraagt. Omdat MLflow-trackingservers in echte omgevingen vaak zonder authenticatie draaien, houdt niets een externe aanvaller tegen om dat eerste verzoek te doen. The Hacker News meldde op 18 augustus 2026 dat actief misbruik binnen enkele uren na de bekendmaking begon.
FUXA's Lek Laat Buitenstaanders Bestanden Schrijven op Fabriekssystemen
FUXA is een open-source SCADA- en HMI-platform - het soort software dat fabrieksoperators een browservenster geeft op de apparatuur die daadwerkelijk een productielijn aanstuurt. De kwetsbaarheid, CVE-2026-25895, scoort met 9,5 zelfs hoger dan die van MLflow, en het mechanisme is botter: ontbrekende authenticatie gecombineerd met een path-traversal-lek. Een niet-geauthenticeerde aanvaller kan een verzoek sturen dat ontsnapt aan de map waarin FUXA verwacht te schrijven, en een bestand plaatsen waar dan ook in het onderliggende bestandssysteem naar keuze.
Willekeurig bestanden schrijven is geen simpel gegevenslek, het is een houvast. Een aanvaller die bestanden kan schrijven waar hij wil op een systeem dat communiceert met industriële apparatuur, kan uitvoerbare code plaatsen en remote code execution bereiken, wat volledige controle betekent over de host die de HMI draait - en, afhankelijk van hoe die host verbonden is met de fabrieksvloer, een pad naar de besturingssystemen zelf. Net als bij MLflow meldden The Hacker News en dezelfde bevestigende media dat actief misbruik binnen enkele uren na de openbare bekendmaking begon, in dezelfde week als het MLflow-advies.
De Gemeenschappelijke Deler Is Niet de Code, Maar de Standaardinstelling
MLflow en FUXA delen geen code, geen maintainers en geen markt. De ene houdt machine-learning-experimenten bij, de andere visualiseert industriële besturingssystemen, en ze werden puur toevallig in dezelfde week onafhankelijk van elkaar bekendgemaakt. Wat ze delen is een standaardinstelling: uitbrengen zonder authenticatie, omdat dat de snelste manier is om een tool voor een klein intern team aan de praat te krijgen, en omdat het team aanneemt dat het omringende netwerk privé is. Die aanname is het hele aanvalsoppervlak.
Diezelfde standaardinstelling schuilt achter een groot deel van de interne tools die eigenaren nooit zelf inspecteren: MLOps-dashboards, monitoringstacks, interne beheerpanelen, en SCADA/HMI-systemen in de hele maakindustrie. Elk daarvan is waarschijnlijk snel opgezet, door iemand die competent was en een echt probleem oploste, maar nooit terugkwam om authenticatie in te schakelen omdat niets hem daartoe dwong. Het gat tussen wat aangenomen wordt privé te zijn en wat werkelijk bereikbaar is - hetzij door directe internetblootstelling, hetzij, zoals bij MLflow, via een SSRF-pivot vanaf een systeem dat wel bereikbaar is - is precies waar beide exploits landden, en daar zal ook de volgende landen.
Uren Tot Misbruik Zijn Nu het Echte Patchvenster
Voor elk bedrijf in de EU of het VK dat MLOps-pijplijnen draait - steeds gebruikelijker naarmate bedrijven hun eigen ML- en AI-infrastructuur inzetten - of elk industrieel of productiebedrijf dat SCADA- of HMI-systemen draait, is de praktische reactie een audit, geen beleidsnotitie. Elke interne tool heeft een direct antwoord nodig op een vraag: staat authenticatie daadwerkelijk aan, niet slechts aangenomen, en is de tool daadwerkelijk onbereikbaar van buiten het netwerk waarin hij verondersteld wordt te leven. MLflow en FUXA laten beide zien dat het eerlijke antwoord vaak nee is, en dat niemand dat ontdekt totdat het wordt misbruikt.
De andere aanpassing betreft de klok. Beide lekken gingen binnen uren van openbare bekendmaking naar actief misbruik, niet in de weken die patchcycli traditioneel aannamen. Voor industriële operators met een EU-vestiging specifiek is dit niet alleen een technisch probleem: de NIS2-verplichtingen gelden voor aanbieders van digitale infrastructuur en, opvallend genoeg, voor productie- en industriële operators die OT- en SCADA-systemen draaien, waardoor een ongepatchte, niet-geauthenticeerde HMI zowel een compliancefout als een beveiligingsprobleem wordt. De oplossing is niet exotisch - authenticatie inschakelen, patchen op de dag van bekendmaking, ervan uitgaan dat niets achter de firewall echt privé is - maar dat moet gebeuren voordat de exploit dat doet, en deze week werd dat gat in uren gemeten.
Lees hierna: Een datalek dat uw DORA-register niet verklaart | Shell en Philips verloren blauwdrukken, geen wachtwoorden



