CVE-2026-59706: Kritisk sårbarhed i Mem0 AI
Mem0 afslører API-nøgler uden login og lader angribere misbruge din server til interne angreb.
Hvad er det?
Mem0 er et open source-bibliotek til at give AI-applikationer hukommelse. En fejl i Mem0 betyder, at to API-endepunkter (adgangspunkter til systemet) ikke kræver login eller adgangskode. Det første endepunkt udleverer gemte hemmeligheder — fx din OpenAI API-nøgle — til hvem som helst, der spørger. Det andet endepunkt giver en angriber mulighed for at ændre en serverindstilling, så din server sender anmodninger til interne systemer, angriberen normalt ikke har adgang til. Det kaldes Server-Side Request Forgery (SSRF), og det kan bruges til at kortlægge eller angribe dit interne netværk via din egen server.
Hvem rammer det?
Sårbarheden rammer alle virksomheder og udviklere, der:
- Kører Mem0 som en selvhostet tjeneste (dvs. på egne servere eller i cloud)
- Har Mem0’s API eksponeret mod internettet eller et netværk med uautoriserede brugere
- Bruger Mem0 til at bygge AI-funktioner og har konfigureret API-nøgler til tjenester som OpenAI, Anthropic eller lignende
Bruger du kun Mem0 lokalt på din egen maskine uden netværksadgang udefra, er risikoen markant lavere.
Hvad kan ske?
En angriber, der udnytter denne sårbarhed, kan:
- Stjæle dine API-nøgler — fx til OpenAI — og bruge dem på din regning, sælge dem eller misbruge dem til egne formål
- Kortlægge dit interne netværk ved at tvinge din server til at sende anmodninger til interne adresser (fx cloud-metadata-tjenester som AWS IMDS), hvilket kan afsløre yderligere hemmeligheder og adgangsoplysninger
- Eskalere adgangen til andre interne systemer, der normalt ikke er tilgængelige udefra
Konsekvenserne kan inkludere uventede regninger fra AI-udbydere, datalæk og kompromittering af dit bredere cloud-miljø.
Hvor alvorligt er det?
Sårbarheden er vurderet kritisk med en CVSS-score på 9.3 ud af 10. Det skyldes flere faktorer:
- Ingen login krævet — enhver med netværksadgang kan udnytte fejlen uden brugerkonti eller adgangskoder
- Lav kompleksitet — angrebet kræver ingen særlige tekniske færdigheder; det er blot et simpelt HTTP-kald
- Høj fortrolighedsskade — dine mest følsomme konfigurationsdata, herunder API-nøgler, afslører sig i klartekst
- Scope-udvidelse — via SSRF kan angrebet sprede sig fra Mem0-serveren til andre systemer i dit netværk
Hvad gør jeg nu?
Følg disse trin hurtigst muligt, hvis du kører Mem0:
- Tjek om du er eksponeret: Find ud af om din Mem0-instans er tilgængelig fra internettet eller fra netværkssegmenter med uautoriserede brugere. Forsøg at tilgå
/api/v1/config/uden login — kan du se data, er du eksponeret. - Bloker adgangen midlertidigt: Sæt en firewall-regel eller netværkspolitik, der begrænser adgangen til Mem0’s API til kun autoriserede IP-adresser eller interne systemer, til en patch er tilgængelig.
- Roter dine API-nøgler straks: Gå ind hos dine AI-udbydere (fx OpenAI) og opret nye API-nøgler. Slet de kompromitterede nøgler, og opdater din konfiguration. Tjek forbrugslogene for uautoriseret brug.
- Tjek interne logfiler: Gennemgå serverlogfiler for mistænkelige kald til
/api/v1/config/og/api/v1/config/mem0/llm. Ukendte kald kan tyde på, at nogen allerede har udnyttet fejlen. - Følg med i opdateringer fra Mem0-projektet: Hold øje med officielle sikkerhedsopdateringer og patch din installation, så snart en rettelse frigives.
Handl inden for 24 timer
Med en CVSS-score på 9.3 og et ekstremt simpelt angrebsmønster — et enkelt HTTP-kald uden login — bør du behandle dette som en akut hændelse. Rotér dine API-nøgler og begræns netværksadgangen til Mem0 i dag. Selvom din instans ikke umiddelbart ser ud til at være kompromitteret, er chancen høj for, at automatiserede scannere allerede har opdaget og afprøvet endepunkterne. Vent ikke på en officiel patch, før du beskytter dine nøgler og isolerer tjenesten.
Tidslinje
Konkrete eksempler
Stjæling af OpenAI API-nøgle
En angriber opdager en virksomheds selvhostede Mem0-instans via en simpel internet-scanning. Angriberen sender en HTTP GET-anmodning til /api/v1/config/ uden nogen form for login. Systemet returnerer al konfiguration i klartekst, herunder virksomhedens OpenAI API-nøgle. Angriberen begynder straks at bruge nøglen til egne AI-forespørgsler, og virksomheden opdager det først, da de modtager en uventet regning på tusindvis af kroner fra OpenAI.
Cloud-overtage via SSRF mod AWS metadata
En angriber sender en HTTP PUT-anmodning til /api/v1/config/mem0/llm og sætter parameteren ollama_base_url til http://169.254.169.254/latest/meta-data/iam/security-credentials/ — AWS’s interne metadata-adresse. Mem0-serveren, der kører på AWS, kontakter adressen og returnerer midlertidige IAM-legitimationsoplysninger (adgangsoplysninger til cloud-platformen) til angriberen. Med disse kan angriberen tilgå S3-buckets, databaser og andre cloud-ressourcer i virksomhedens AWS-konto.
Kortlægning af internt netværk
En angriber bruger SSRF-sårbarheden til systematisk at sende anmodninger mod interne IP-adresser i virksomhedens netværk via Mem0-serveren. Ved at variere IP-adressen i ollama_base_url og observere svar- og fejlkoder kan angriberen kortlægge hvilke interne systemer — fx databaser, administrationspaneler eller intranet-servere — der findes og er tilgængelige, og derefter målrette yderligere angreb mod disse.
Ofte stillede spørgsmål
Hvad er en API-nøgle, og hvorfor er det alvorligt at miste den?
En API-nøgle er som en adgangskode, der giver adgang til en betalt tjeneste — fx OpenAI’s sprogmodel. Hvis en angriber stjæler din nøgle, kan de bruge tjenesten på din regning, potentielt for store beløb, og du hæfter for udgiften. Nøglen giver desuden adgang til de data, du sender til tjenesten.
Hvad er SSRF, og hvorfor er det farligt for min virksomhed?
SSRF (Server-Side Request Forgery) betyder, at en angriber kan tvinge din server til at sende anmodninger til adresser, som angriberen angiver — herunder interne systemer i dit netværk, der normalt ikke er tilgængelige udefra. I cloud-miljøer (AWS, Azure, GCP) kan dette bruges til at hente midlertidige adgangsoplysninger fra metadata-tjenester og dermed overtage dele af din cloud-konto.
Hvordan ved jeg, om nogen allerede har udnyttet fejlen mod mig?
Gennemgå dine serverlogfiler for GET-anmodninger til
/api/v1/config/og PUT-anmodninger til/api/v1/config/mem0/llmfra ukendte IP-adresser. Tjek også dit forbrug hos AI-udbydere som OpenAI for usædvanlig aktivitet eller ukendte anmodninger — det er ofte det første synlige tegn på misbrug af en stjålet API-nøgle.Er jeg i fare, hvis jeg kun bruger Mem0 som en del af en større cloud-løsning?
Ja, potentielt i endnu højere grad. Hvis Mem0 kører i et cloud-miljø (AWS, Azure, GCP), kan SSRF-angrebet bruges til at tilgå cloud-metadata-endepunktet (IMDS), som kan udlevere midlertidige cloud-legitimationsoplysninger. Det kan give angriberen adgang til andre ressourcer i dit cloud-miljø langt ud over selve Mem0-installationen.
Skal jeg afinstallere Mem0 helt, mens jeg venter på en patch?
Det er ikke nødvendigvis nødvendigt. En mere praktisk løsning er at isolere Mem0 bag en firewall eller VPN, så kun autoriserede brugere og systemer kan nå API’et. Kombinér det med straks at rotere alle API-nøgler, der har været gemt i systemet. Overvej dog nøje om Mem0 er forretningskritisk nok til at holde kørende i en eksponeret tilstand.
Ramte produkter
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
mem0 contains unauthenticated config API endpoints that expose LLM API keys in plaintext and allow server-side request forgery via attacker-controlled ollama_base_url parameter. Unauthenticated attackers can retrieve stored secrets like OpenAI API keys via GET /api/v1/config/ or trigger SSRF attacks by setting ollama_base_url to internal addresses like cloud IMDS via PUT /api/v1/config/mem0/llm endpoint.
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.