To Open Source-Værktøjer Faldt På Få Timer

En Ingeniør Sætter Et Dashboard Op, Kun Til Teamet

En ingeniør hos en mellemstor virksomhed sætter en MLflow-tracking-server op på en intern VM, så data science-teamet kan logge eksperimenter og sammenligne modelkørsler. MLflow beder ikke om et brugernavn eller en adgangskode under opsætningen, så der bliver ikke konfigureret nogen, og serveren går i luften bag det, alle antager er et privat netværk. På en fabrik nogle hundrede kilometer væk gør en driftsingeniør noget lignende: han sætter FUXA op, en open source SCADA- og HMI-platform, for at give teamet et browserbaseret overblik over produktionslinjens tags. Ingen af systemerne blev bygget til at kunne nås fra det åbne internet, og intet team tjekkede det.

I ugen fra den 18. august 2026 viste begge antagelser sig at være forkerte samtidig. MLflow, en platform til at spore eksperimenter, hostet under LF Projects hos Linux Foundation, og FUXA, et helt urelateret værktøj til industrielle styresystemer, offentliggjorde hver en kritisk, som standard uautoriseret sårbarhed - og i begge tilfælde havde angribere fungerende exploits på få timer efter den offentlige offentliggørelse, ikke uger. To forskellige kodebaser, to forskellige brancher, to teams, der aldrig koordinerede med hinanden. Det, de deler, er en enkelt designbeslutning, truffet uafhængigt af hinanden, år fra hinanden, af samme grund: det er hurtigere at udgive et værktøj med godkendelse slukket end tændt.

MLflows Fejl Gør En Omdirigering Til Tyveri Af Legitimationsoplysninger

MLflow-sårbarheden, registreret som CVE-2026-64849, har en CVSS-score på 9,3. Det er en omgåelse af webhook-URL-validering: MLflow lader brugere registrere webhooks, der udløses ved hændelser som en afsluttet træningskørsel, og tjekker destinationsadressen, før den tillader det, for at forhindre serveren i at pege på interne adresser. Angribere opdagede, at de kunne omgå det tjek ved at kombinere en HTTP-omdirigering med DNS-rebinding - de registrerer en webhook til en adresse, der består valideringen, og lader den derefter, på anmodningstidspunktet, opløses til en intern IP, som validatoren aldrig så. GitLab udgav en sikkerhedsadvarsel om fejlen, og exploiten blev bekræftet uafhængigt af cybersikkerhedsmedier som cybersecuritynews, cyberpress og GBHackers.

Gevinsten for en angriber er server-side request forgery: MLflow-serveren selv bliver den, der foretager anmodningen, indefra det netværk, den befinder sig i. Det gør det muligt for en angriber at nå interne tjenester, der aldrig var beregnet til at vende udad, og afgørende, cloud-instansmetadata-endpoints hos AWS, Azure og GCP - de interne adresser, der udleverer midlertidige legitimationsoplysninger til den maskine, der spørger. Fordi MLflow-tracking-servere ofte kører uden godkendelse i virkelige installationer, er der intet, der forhindrer en ekstern angriber i at foretage den første anmodning. The Hacker News rapporterede den 18. august 2026, at aktiv udnyttelse begyndte på få timer efter offentliggørelsen.

FUXAs Fejl Lader Udenforstående Skrive Filer På Fabrikssystemer

FUXA er en open source SCADA- og HMI-platform - den slags software, der giver fabriksoperatører et browservindue ind til det udstyr, der rent faktisk styrer en produktionslinje. Sårbarheden, CVE-2026-25895, scorer endnu højere end MLflows med 9,5, og mekanismen er mere ligetil: manglende godkendelse kombineret med en path-traversal-fejl. En uautoriseret angriber kan sende en anmodning, der undslipper den mappe, FUXA forventer at skrive til, og placere en fil hvor som helst i det underliggende filsystem efter eget valg.

Vilkårlig filskrivning er ikke bare en dataeksponeringsfejl, det er et fodfæste. En angriber, der kan skrive filer, hvor han vil, på et system, der kommunikerer med industrielt udstyr, kan placere eksekverbar kode og opnå fjernkodeafvikling, hvilket betyder fuld kontrol over den vært, der kører HMI'en - og afhængigt af, hvordan den vært er forbundet til fabriksgulvet, en vej til selve styresystemerne. Ligesom med MLflow rapporterede The Hacker News og de samme bekræftende medier, at aktiv udnyttelse begyndte på få timer efter den offentlige offentliggørelse, i samme uge som MLflow-advarslen.

Den Fælles Tråd Er Ikke Koden, Det Er Standardindstillingen

MLflow og FUXA deler ingen kode, ingen vedligeholdere og intet marked. Det ene sporer machine learning-eksperimenter, det andet visualiserer industrielle styresystemer, og de blev offentliggjort uafhængigt af hinanden i samme uge af ren tilfældighed. Det, de deler, er en standardindstilling: udgive uden godkendelse, fordi det er den hurtigste måde at få et værktøj til at køre for et lille internt team, og fordi teamet antager, at netværket omkring det er privat. Den antagelse er hele angrebsfladen.

Den samme standardindstilling ligger bag en stor del af de interne værktøjer, som ejere aldrig selv inspicerer: MLOps-dashboards, overvågningsstakke, interne administrationspaneler og SCADA/HMI-systemer i hele fremstillingsindustrien. Hver enkelt blev sandsynligvis sat hurtigt op af en kompetent person, der løste et reelt problem, og som aldrig kom tilbage for at slå godkendelse til, fordi intet tvang vedkommende til det. Kløften mellem det, der antages at være privat, og det, der faktisk kan nås - enten gennem direkte internet-eksponering eller, som med MLflow, gennem en SSRF-omvej fra et system, der kan nås - er præcis der, hvor begge exploits landede, og det er der, den næste også vil lande.

Timer Til Udnyttelse Er Nu Det Reelle Patch-Vindue

For enhver virksomhed i EU eller Storbritannien, der kører MLOps-pipelines - stadig mere almindeligt, efterhånden som virksomheder udruller deres egen ML- og AI-infrastruktur - eller enhver industri- eller fremstillingsvirksomhed, der kører SCADA- eller HMI-systemer, er det praktiske svar en gennemgang, ikke et politisk notat. Hvert internt værktøj har brug for et direkte svar på et spørgsmål: er godkendelse faktisk aktiveret, ikke bare antaget, og er værktøjet faktisk uopnåeligt udefra det netværk, det formodes at leve i. MLflow og FUXA viser begge, at det ærlige svar ofte er nej, og at ingen opdager det, før det bliver udnyttet.

Den anden justering handler om uret. Begge fejl gik fra offentlig offentliggørelse til aktiv udnyttelse på få timer, ikke i de uger, som patch-cyklusser traditionelt har antaget. For EU-baserede industrielle operatører specifikt er dette ikke kun et teknisk problem: NIS2-forpligtelserne gælder for udbydere af digital infrastruktur og, bemærkelsesværdigt, for fremstillings- og industrioperatører, der kører OT- og SCADA-systemer, hvilket gør en ikke-patched, uautoriseret HMI til en compliance-fejl lige så meget som en sikkerhedsfejl. Løsningen er ikke eksotisk - slå godkendelse til, patch på offentliggørelsesdagen, antag, at intet bag firewallen faktisk er privat - men det skal ske, før exploiten gør, og denne uge blev den kløft målt i timer.

Læs videre: Et brud dit DORA-register ikke kan forklare  |  Shell og Philips mistede tegninger, ikke adgangskoder