Dify-feil åpnet for datalekkasje mellom AI-kunder

Dify-saken er en påminnelse om at AI-plattformer også er SaaS-plattformer. De har tenants, plugins, filområder, logging, tracing og interne API-er. Når disse lagene feiler, kan konsekvensen bli datalekkasje mellom kunder.

SecurityWeek omtaler fire sårbarheter i den åpne LLMOps-plattformen Dify, basert på funn fra Zafran Security. Dify brukes til å bygge, kjøre og overvåke AI-applikasjoner og skal ifølge omtalen drive over én million applikasjoner på tvers av mer enn 50 bransjer.

Sårbarhetene omtales samlet som DifyTap. De kunne ifølge rapporteringen gjøre det mulig å lese private chats fra andre kunders applikasjoner, utløse interne API-kall på tvers av tenants, forhåndsvise dokumenter lastet opp av andre tenants og lekke filer fra andre brukere i samme tenant.

Dify har sluppet versjon 1.14.2 med rettelser. Brukere anbefales å oppdatere raskt og vurdere WAF-regler mot den mest alvorlige plugin-daemon-feilen.

Dette er mer enn en vanlig CVE-liste

Den mest alvorlige feilen i tracing-funksjonen, CVE-2026-41947, fikk CVSS-score 9.1. Problemet lå i at relevante tracing-endepunkter ikke validerte avsenderens tenant godt nok. En angriper med Dify console-bruker kunne ifølge Zafran konfigurere sin egen tracing for applikasjoner vedkommende hadde klienttilgang til, inkludert offentlig tilgjengelige applikasjoner. Det kunne skape en vedvarende kanal for eksfiltrering av meldinger og svar.

Den andre feilen, CVE-2026-41948, fikk CVSS-score 9.4 og rammet plugin-daemonen. Den håndterer Dify-plugins, altså en type utvidelseslag mange virksomheter vil bruke for å koble AI-applikasjoner til egne systemer. Ifølge omtalen kunne angripere nå vilkårlige API-endepunkter via GET og POST-primitiver og blant annet bruke path traversal mot andre tenants.

De to siste feilene gjaldt filidentifikasjon og tilgangskontroll. Konsekvensen var at angripere kunne forhåndsvise filer lastet opp av andre tenants eller hente filer lastet opp av andre brukere i samme tenant.

Dette er en klassisk plattformfeil, men i en ny kontekst. AI-apper lagrer ofte prompts, svar, dokumenter, kunnskapsbaser, evalueringsdata og koblinger mot interne verktøy. Det er ofte mer følsomt enn en vanlig webapp-logg. En liten feil i tenant-isolasjon kan derfor gi innsyn i både forretningsdata og modellinteraksjoner.

Tracing og plugins er høyrisiko

Mange virksomheter ser på observability som et kontrolltiltak. Man vil logge prompts, svar, feil og kostnader for å forstå hva AI-applikasjonen gjør. DifyTap viser baksiden: tracing blir selv en sensitiv datakanal. Hvis feil aktør kan konfigurere eller lese den, får vedkommende tilgang til akkurat den dokumentasjonen sikkerhetsteamet håpet skulle gi kontroll.

Plugins er like krevende. De gir plattformen verdi fordi AI-applikasjonen kan kobles til eksterne systemer. Samtidig blir plugin-laget en privilegert bro mellom modellen, brukeren og virksomhetens data. En plugin-daemon med svak tilgangskontroll kan bli en intern snarvei for angripere.

For CISO-er betyr dette at LLMOps ikke kan eies av innovasjonsteamet alene. Det må inn i samme risikoregime som andre plattformer som behandler kundedata, dokumenter og integrasjoner.

Spørsmålene innkjøp bør stille

Første spørsmål er tenant-isolasjon. Leverandøren bør kunne forklare hvordan applikasjoner, dokumenter, plugins, tracing, modeller, secrets og brukerdata skilles mellom kunder og miljøer. Det holder ikke med en generell setning om at data er isolert. Be om konkrete kontroller og revisjonsspor.

Andre spørsmål er patch-SLA. AI-plattformer utvikles raskt, og mange er åpne eller delvis selvhostede. Da må virksomheten vite hvem som følger sårbarheter, hvor raskt nye versjoner kan testes, og hvilke komponenter som må oppdateres samtidig.

Tredje spørsmål er hva som faktisk logges. Prompts og svar kan inneholde personopplysninger, kontrakter, kildekode, strategidokumenter og sikkerhetsinformasjon. Hvis tracing er aktivert, må loggene behandles som sensitiv data.

Fjerde spørsmål er plugin-styring. Hvem kan installere plugins? Hvilke nettverk og API-er får de nå? Hvordan roteres tokens? Hvordan ser man hvilke handlinger en plugin har utført?

Konsekvensen for norske ledere

DifyTap er ikke nødvendigvis en grunn til å unngå Dify. Det er en grunn til å slutte å behandle AI-appbyggere som ufarlige sandkasser. Når en plattform brukes til kundedialog, dokumentanalyse, support, intern kunnskap eller automatisering, er den en del av virksomhetens databehandlingsflate.

Det viktigste tiltaket er å få oversikt over hvor slike plattformer allerede er i bruk. Mange AI-verktøy kommer inn via utviklere, produktteam eller forretningsenheter før sentral sikkerhet har rukket å etablere krav. Det er billig i starten og dyrt når dataflytene må ryddes opp.

Dify-saken viser også hvorfor selvhosting ikke automatisk betyr lav risiko. Selvhostede miljøer må patches, hardenes og overvåkes. SaaS-miljøer må levere dokumentert isolasjon. Begge modellene krever aktiv styring.

AI-applikasjoner er på vei fra demo til drift. Da blir tenants, plugins, filer og tracing like viktige som modellvalg. Det er ikke like sexy som modellbenchmarks. Det er bare mer avgjørende.

Kilder og medier

Kilde: SecurityWeek, “Data Exposure Flaws Threaten Dify AI Platform Used by 1 Million Apps”, https://www.securityweek.com/data-exposure-flaws-threaten-dify-ai-platform-powering-over-1-million-apps/

Kildekreditering: SecurityWeek / Zafran Security. Thumbnail: OpenAI Image 2 / hogby.ai