Två Verktyg med Öppen Källkod Föll På Några Timmar

En Ingenjör Sätter Upp en Instrumentpanel, Bara För Teamet

En ingenjör på ett medelstort företag sätter upp en MLflow-spårningsserver på en intern VM så att data science-teamet kan logga experiment och jämföra modellkörningar. MLflow frågar inte efter användarnamn eller lösenord under installationen, så inget konfigureras, och servern går live bakom det som alla antar är ett privat nätverk. På en fabrik några hundra kilometer bort gör en driftsingenjör något liknande: han sätter upp FUXA, en SCADA- och HMI-plattform med öppen källkod, för att ge teamet en webbläsarbaserad vy över produktionslinjens taggar. Inget av systemen byggdes för att vara nåbart från det öppna internet, och inget team kontrollerade det.

Under veckan från den 18 augusti 2026 visade sig båda antagandena vara fel samtidigt. MLflow, en plattform för att spåra experiment som är värd under LF Projects hos Linux Foundation, och FUXA, ett helt orelaterat verktyg för industriella styrsystem, offentliggjorde vardera en kritisk sårbarhet som är oautentiserad som standard - och i båda fallen hade angripare fungerande exploits inom timmar efter det offentliga avslöjandet, inte veckor. Två olika kodbaser, två olika branscher, två team som aldrig samordnade sig. Det de delar är ett enda designbeslut, fattat oberoende av varandra, år isär, av samma anledning: det är snabbare att släppa ett verktyg med autentiseringen avstängd än påslagen.

MLflows Sårbarhet Gör en Omdirigering Till Stöld av Autentiseringsuppgifter

MLflow-sårbarheten, registrerad som CVE-2026-64849, har en CVSS-poäng på 9,3. Det är en kringgåelse av valideringen av webhook-URL:er: MLflow låter användare registrera webhooks som utlöses vid händelser som en avslutad träningskörning, och kontrollerar destinationsadressen innan den tillåts, för att förhindra att servern pekar mot interna adresser. Angripare upptäckte att de kunde besegra den kontrollen genom att kombinera en HTTP-omdirigering med DNS-rebinding - de registrerar en webhook mot en adress som klarar valideringen, och låter den sedan, vid tidpunkten för förfrågan, slås upp mot en intern IP-adress som validatorn aldrig såg. GitLab publicerade en säkerhetsrekommendation om sårbarheten, och exploiten bekräftades oberoende av cybersäkerhetsmedier som cybersecuritynews, cyberpress och GBHackers.

Vinsten för en angripare är server-side request forgery: MLflow-servern själv blir den som gör förfrågan, inifrån det nätverk den befinner sig i. Det låter en angripare nå interna tjänster som aldrig var tänkta att vetta utåt, och avgörande, molninstansers metadata-endpoints hos AWS, Azure och GCP - de interna adresser som lämnar ut tillfälliga autentiseringsuppgifter till den maskin som frågar. Eftersom MLflow-spårningsservrar ofta körs utan autentisering i verkliga installationer, finns inget som hindrar en extern angripare från att göra den första förfrågan. The Hacker News rapporterade den 18 augusti 2026 att aktivt utnyttjande började inom timmar efter avslöjandet.

FUXAs Sårbarhet Låter Utomstående Skriva Filer På Fabrikssystem

FUXA är en SCADA- och HMI-plattform med öppen källkod - den typ av programvara som ger fabriksoperatörer ett webbläsarfönster mot den utrustning som faktiskt styr en produktionslinje. Sårbarheten, CVE-2026-25895, får en ännu högre poäng än MLflows, 9,5, och mekanismen är råare: bristande autentisering kombinerad med en path traversal-sårbarhet. En oautentiserad angripare kan skicka en förfrågan som undkommer katalogen som FUXA förväntar sig att skriva till och placera en fil var som helst i det underliggande filsystemet efter eget val.

Godtycklig filskrivning är inte bara en dataexponeringsbugg, det är ett fotfäste. En angripare som kan skriva filer var han vill på ett system som kommunicerar med industriell utrustning kan placera körbar kod och uppnå fjärrkörning av kod, vilket innebär full kontroll över den värddator som kör HMI:n - och, beroende på hur den värddatorn är kopplad till fabriksgolvet, en väg till själva styrsystemen. Precis som med MLflow rapporterade The Hacker News och samma bekräftande medier att aktivt utnyttjande började inom timmar efter det offentliga avslöjandet, samma vecka som MLflow-rekommendationen.

Den Gemensamma Nämnaren Är Inte Koden, Det Är Standardinställningen

MLflow och FUXA delar ingen kod, inga underhållare och ingen marknad. Det ena spårar maskininlärningsexperiment, det andra visualiserar industriella styrsystem, och de offentliggjordes oberoende av varandra samma vecka av ren tidsmässig slump. Det de delar är en standardinställning: släppa utan autentisering, eftersom det är det snabbaste sättet att få ett verktyg igång för ett litet internt team, och eftersom teamet antar att nätverket runt omkring är privat. Det antagandet är hela attackytan.

Samma standardinställning ligger bakom en stor del av de interna verktyg som ägare aldrig själva granskar: MLOps-instrumentpaneler, övervakningsstackar, interna administrationspaneler och SCADA/HMI-system i hela tillverkningsindustrin. Vart och ett sattes sannolikt upp snabbt, av någon kompetent som löste ett verkligt problem, och som aldrig kom tillbaka för att slå på autentiseringen eftersom inget tvingade dem. Klyftan mellan det som antas vara privat och det som faktiskt är nåbart - antingen genom direkt internetexponering eller, som med MLflow, genom en SSRF-omväg från ett system som är nåbart - är exakt där båda exploiterna landade, och det är där nästa också kommer att landa.

Timmar Till Utnyttjande Är Nu Det Verkliga Patchfönstret

För alla företag i EU eller Storbritannien som kör MLOps-pipelines - allt vanligare i takt med att företag driftsätter egen ML- och AI-infrastruktur - eller alla industri- eller tillverkningsföretag som kör SCADA- eller HMI-system, är det praktiska svaret en granskning, inte en policynotis. Varje internt verktyg behöver ett direkt svar på en fråga: är autentiseringen faktiskt aktiverad, inte bara antagen, och är verktyget faktiskt onåbart utifrån det nätverk det förutsätts leva i. MLflow och FUXA visar båda att det ärliga svaret ofta är nej, och att ingen upptäcker det förrän det utnyttjas.

Den andra justeringen handlar om klockan. Båda sårbarheterna gick från offentligt avslöjande till aktivt utnyttjande på timmar, inte de veckor som patchcykler traditionellt har antagit. För EU-baserade industriella operatörer specifikt är detta inte bara ett tekniskt problem: NIS2-kraven gäller leverantörer av digital infrastruktur och, anmärkningsvärt, tillverknings- och industrioperatörer som kör OT- och SCADA-system, vilket gör en opatchad, oautentiserad HMI till ett efterlevnadsfel lika mycket som ett säkerhetsfel. Lösningen är inte exotisk - slå på autentisering, patcha på avslöjandedagen, anta att inget bakom brandväggen faktiskt är privat - men det måste ske innan exploiten gör det, och denna vecka mättes den klyftan i timmar.

Läs vidare: Ett dataintrång ert DORA-register inte kan förklara  |  Shell och Philips förlorade ritningar, inte lösenord